Friday, May 23, 2014

Software developers and the generation gap

Today I have a rather unusual topic because it's not that technical as usual. But something that has bothered me for a while.

I want to talk about different kinds of developers - but as the topic might imply it is less about the actual age but more about the mindset of software developers.

On the one side there are people that are open minded to new ideas and experiencing new technologies. I don't mean those hipsters that follow every new trend just to find that antiquated the next week. I am talking about those that are not stuck in the 80s or 90s when it comes to how software development is done in 2014. Those that care about their software because they don't want to pull their hair out the next time they have to implement a new feature or find and fix a bug. They also care about their coworkers because usually they are part of development team and like to share opinions and get feedback.

On the other hand I sometimes see people that have the attitude of a caveman when it comes to learning new things and breaking out of their habits. They are still coding like in TP 5.5 or Delphi 3 (I randomly picked these versions and my deepest sympathy if you are stuck with an old version for some reasons). If someone mentions things like clean code, principles or even design patterns (unless its the singleton pattern, that one is awesome! /sarcasm off) they run away or start an argument on how this is over-engineering stuff. But when it comes to unnecessary (i.e. premature) performance optimizations to squeeze out the last CPU cycle by using unreadable code they are unstoppable.

OK, I hear some of you screaming already - because I am exaggerating here. Of course you need to care about performance and optimizations. But in the right places. If your server uses gigabytes of memory and all cores just because you did some sloppy programming but optimize a routine that uses like 0.0001% of your CPU then probably did something wrong.
Also some people tend to solve every problem by using patterns and in the end their fizzbuzz looks like this. Principles and patterns should be used to write code that is testable and maintainable and not just because.

Also when it comes to new language features especially when they remind you of C# or Java some people seem to have an allergy to these things. If anything does not look pascalish it's probably something evil from a "low level" language like C++ (did someone say '98? No its '14!).

Oh and because it always worked well some of course still put all their code into the event handlers of forms and frames that not only contain hundreds of controls that are made visible when necessary. Data is stored in fixed length format files of course because that's super fast and databases are just overhead. They also don't need unit tests because their code works (which only they understand of course)!

That was a lot of ranting but the question that follows is: What can you learn from each other?

Be open minded. Question yourself if you are doing things the way you are doing them just because you always did. Try out suggestions you read or hear. Don't treat everything as a nail just because you only have a hammer. Use the tool that is the best for the task. Develop software that you still like to maintain and improve two months from now. Or make the one you hate working on less painful.
Learn from the seniors. They had their reasons to code in particular ways in the past because times were different (that sounds like a long time but a few years can be like eternity in IT). Don't just use algorithms and data structures but also try understand them. It will help choosing the right one for the task.

As always I am interested in your opinions - especially since this time I picked a very controversial topic.