All good examples (such as excessive importance to deadlines, a big no-no).
My question: can they be truly good programmers of they write bad code? Isn't the essential product of a programmer SLOC and functionality via software? And if they do that in a manner inferior to another dev, isn't that objectively a measure of inferiority in their craft?
I've met far too many 'good' programmers who were a net detriment to a project not to be wary of the term.
Under insufficient time constraints, a good developer will either produce bad code or no code at all (he will resign from the company). This is extremely common. The stuff the author said about too much emphasis on deadlines is spot-on.
Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs.
For example, if a lead developer doesn't choose the right framework or plan/design the API correctly, then the consequences of that will keep piling up over time.
It's really easy to put the blame on people who are doing the 'small work' but in reality, they might be doing the best work possible under the terrible constraints imposed on them.
> Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs.
This is very prevalent at my job. There are a couple of developers who have a reputation of being really fast. "Wow, he closed 25 tickets the last hour!". In reality he mainly rejected them or made quick fixes which didn't work or created new bugs. A not insignificant amount of time in a recent project I had was focused on rewriting code said developer had written.
Yes and no. Crazy, made up deadlines will throw even the best developer off. They want to, fist and foremost get it done. If everything else is irrelevant, then that's what you will get. Of course that ends up being bad for everybody, but many businesses still don't have a clue on how to operate their most important department. Sometimes you have a hard deadline that you just can't help like a mission critical bug, or the VP of sales promised your most important client an impossible date and there are fines involved.
I'm a firm believer of setting aside time for refactoring every X number of releases. That solves a lot of this.
Impossible and strict deadlines simply because of cost control is shooting yourself in the foot.
Impossible deadlines because of a really important deal worth actual money, is probably worth sweating over,at the risk of code quality. If all projects tend to be the latter case, it's probably actually the first case packaged as the second...
Sure, sometimes it's just a matter of survival. Get this code released by this date or we sink. That's an unfortunate place to be in, requires a lot of focus under stress and is rarely rewarded. It's gratifying for me to be successful in those circumstances, but too many of them and I have to find a saner place to work. Management starts to take miracles as the norm by planning them (if they even do) and it leads to burnout.
Even good developers have to initially poke at a problem to get it in their head. Once there, then they can write beautiful code to solve it. Therefore, if time is constrained, even good developers will have to ship ugly (but working) code.
So true. A 'good' programmer who commits terrible code is a bad programmer. In other words, one trait of a senior developer is knowing to pick your battles.
I think is is true at the earlier stages of one's career. One you get older and have to start feeding a family, the idealism wears off and you start finding yourself compromising your morals and coding shit to make a deadline. But the company you work for pays you so well, coupled with the expert domain knowledge that makes you nearly irreplaceable, you become complacent. You are a fixed cog in the system. At this point "get out" is not in your best interests.
My question: can they be truly good programmers of they write bad code? Isn't the essential product of a programmer SLOC and functionality via software? And if they do that in a manner inferior to another dev, isn't that objectively a measure of inferiority in their craft?
I've met far too many 'good' programmers who were a net detriment to a project not to be wary of the term.