Three Rules for Developers
2 comments
I agree with all of your points.
I also think software development has changed from being creative and fun to being competitive and up-tight.
But isn’t that just a function of time? 15 years ago software development, in many places, was “something “those strange guys down at IT” did. There wasn’t any higher level manager anywhere that even knew what to expect semi a development team. They didn’t even understand what it was, except that it was probably important to have. Today, software is the business itself. Everywhere. Even banks proclaim, in their strategies, that they are going to be “IT first”.
Software taking a more central role. Software being better understood. More people going into software related jobs.
I also think software development has changed from being creative and fun to being competitive and up-tight.
But isn’t that just a function of time? 15 years ago software development, in many places, was “something “those strange guys down at IT” did. There wasn’t any higher level manager anywhere that even knew what to expect semi a development team. They didn’t even understand what it was, except that it was probably important to have. Today, software is the business itself. Everywhere. Even banks proclaim, in their strategies, that they are going to be “IT first”.
Software taking a more central role. Software being better understood. More people going into software related jobs.
15 years ago was 2004, meaning there were Linux distributions, Java, Python, all that stuff already existed. I was eagerly awaiting Gears of War not Doom 2, for example. Yea, sometimes I forget that 15 years ago was in fact already 2004.
1) You don't need to validate yourself by diminishing others. If you are criticizing operational code then you are doing this. If you are gossiping about others then you are doing this.
2) Clinging to a particular style of coding, a particular methodology, or worse a particular technology/tool doesn't make you a good programmer. The value of what you create is what makes you a good programmer. Keep your mind on getting work done. At the end of the day take pride in what you have done.
3) When doing performance evaluations of developers remember that the nature of our work makes it very hard to do fair evaluations. If you are not consciously trying your best to judge fairly then you are probably not judging fairly at all. This goes for judging peers and subordinates alike.
I'd like to believe that if these things are taken to heart then development environments can be fun again. For the past 15 years I've noticed that development environments have gone from fun and creative environments to competitive and toxic environments full of bias and different forms of pride, chauvinism, and prejudice. I hope we get back to our fun-loving, collaborative roots.