But I wonder the cost of having a poor programmer do something that has high maintenance costs but is available right away as opposed to wait for a good programmer to be available to do it. My guess is you are still better off waiting, but I think people find themselves in this spot more than any. They know that good programmers write code that is easier to maintain, but they feel there is an urgency to get something done and they can't find a 'good' programmer to do it now. The compromise is, get a not so good programmer to do it and potentially make a mess and if the system lives long enough, get the good programmer to come along when they are available to make it better or fix it.
Obviously I consider myself a good programmer. In my 12+ year career, I have spent less time maintaining a system wrote well than I have maintaining/fixing one that someone else wrote poorly.
Early in my career, I spent most of my time maintaining code that I had written poorly. So for the first 3-4 years, 'I' was the not so good programmer whose code I maintained. But at some point I started getting better and I spent more time dealing with fixing other systems than ones I wrote. My code was still not 'great' since it was difficult for me to hand off to anyone but the bugs were much lower than my first few years coding and when bugs came up, I could find and fix them more readily.
After my 6th year (or so) I started following some 'Agile' development practices. Not 'processes'. I used "Agile Developer" techniques geared toward making the code I wrote more easy to change and more easy to keep in a working state. This also facilitated working with other developers more.
I started writing code that junior developers could take a run with it and I moved on to other things. This happens a lot with "Senior" devs handing off work to "Junior" devs but not always in a manner that enables the junior devs to be productive. I think a truly senior developer's main task is to write code that is easy for someone else to modify. Getting it to 'work' is assumed and means little when you are supposed to me a senior software engineer.
Some senior software engineers justify the complexity in their code to "It's hard stuff." "I'm smarter/senior so that is why I understand it and you don't." This is bull. More often than not though, that same senior developer subconsciously is 'protecting' their code with complexity. If you don't want some sharp young developer to come along and show you up, make their job hard. Hand them overly complicated code to maintain and prove you are smarter than they are.
Yes, some things by their nature are complex, but a truly good dev lead can boil it down so that someone else can be empowered by the design to be productive. If you are 'senior' and a 'junior' dev can't maintain/modify your code it is YOUR fault 9 times out of 10. Even if they are not necessarily very experienced or skilled. You should be enabling them and building up their confidence with well designed code. You should not be crushing their spirit by dropping a pile of crap in their laps and saying, "This code is about 99% done. I just need you to plug the database in."
No comments:
Post a Comment