Is "Reactive" logic an event-driven model with reused logic for column calculations/validation?
It has to be balance between the employer/employee for this thing to work. If the employee gets awesome compensation and the employer doesn't get something worthwhile in return, it doesn't work. Likewise, if the employee doesn't get decent compensation and the employer gets some valuable product, it doesn't work. If the employee and the employer both benefit, then everyone wins and there is balance in the give/take. In those unbalanced situations, either an employee quits or they're canned.
I suppose you could take advantage of the economy and low ball new hires and work them like dogs, but that's a pretty gruesome way to run a business.
i agree. part of me is also surprised his drive is lasting as long as it is.
Why is this professor, who values his 10 years of digital work, keeping all his eggs in one basket? That guy should be regularly backing up data that is irreplaceable. Theft, loss, hardware failure or even operator error could all lead to a devastating loss.
1. Attention to detail. It's amazing that new guys here who are veterans don't have that. A requirement will come in and they'll get 90% of it done, but either gloss over or not notice the 10% they didn't do. I take pride in my work and I would expect others to at least pay attention to detail in theirs.
2. Extra effort. I work in a small company so each cog that contributes to the team translates to a stronger company. If a customer who uses our software has an issue and it's critical, we expect someone to handle it in a timely fashion even if it means working on weekends or late into the night/morning.
3. Team player. We work in a team where I am at, and no single developer stands on their own. Everyone has their own area of expertise and we often go to each other looking for insight or help. People shouldn't be afraid to ask for help and others, time permitting, should give assistance to others. Also a big part of being a team player is offering *constructive* criticism. Don't be negative or if you do, have it lead to a positive outcome. I know a lot of developers may have foot-in-mouth syndrome (even if they don't know they do) or more destructive than constructive, but it's important to try to reach a positive result with everyone feeling better about the situation than before. Nothing destroys morale than a fly in the ointment or a nay-sayer... I do agree in logical discussions and hearing everyone out, but once a decision is made, people need to move on and not be petty.
4. Curiosity. It annoys me when someone asks for help without even trying. My general rule of thumb when it comes to helping is if you've tried solving a problem for an hour and have no measurable progress, outside help is advised. But curiosity also serves to improve something or to gain more knowledge.
5. Thoroughness. If a bug should resolve itself with a bizarre fix, why did it fix it? What is the real underlying cause? I've worked with people who say they've fixed an issue when they've just fixed the symptoms or have put a bandage on a wider problem. If you know the problem is bigger and it is important enough, why not spend the time (time permitting) and fix it the right way?
6. Take Notes!!! Nothing annoys me more than having to tell someone how to do something over and over and over again. I can understand once or twice. But beyond the 3rd or 4th is a waste of my time. If you know you're going to have a tough time remembering, take notes! Write something down or do something! Be creative!
Anyways, that's what I've come to value in developers here where I work as a lead developer.
Link to Original Source