4 ms·
> Second, if someone in a big company generates 250 LoC/day reliably over years, it doesn't always mean that person is a great programmer; it could mean that, o
by vorg 15y ago
> Second, if someone in a big company generates 250 LoC/day reliably over years, it doesn't always mean that person is a great programmer; it could mean that, or it could mean that he's always taking the fun, "green field" projects and passing the legacy maintenance (on which 10 LoC/day is a typical clip) to others.
This is what I call the Dirty Little Secret of Corporate IT shops: The mediocre programmers spin a story and slag off others to get the jobs developing new systems or rewrites in new technology to pad their CV; the programmers with aptitude end up in maintenance roles digging deep through the said code to fix all the bugs afterwards and make that software usable, while the mediocre programmers who wrote it are already in their next jobs doing it again.
- geraldalewis 15y agoWhy would ones ability to "spin stories and slag off others" be exclusive to their programming ability? I almost want to argue that they're demonstrating some form of communication skills, which may translate to more readable/maintainable code? ... Maybe that's a stretch.
- chipsy 15y agoThere are people who hustle for the business, and people who hustle only for themselves. We're talking about the latter.
- gaius 15y agoI absolutely agree with this. One of my more flighty cow-orkers sent round this link yesterday - calling maintenance programmers "the residue". Yeah, him and his mates have been talking non stop about how shit systems X, Y and Z are, how they could do so much better etc. Meanwhile, that system, that I maintain is paying all of our salaries. And those boys have produced something approximating... sod all. While getting paid by the revenues generated by that old code. http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
- bartwe 15y agoInversely I have had experiences with maintenance coders going like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it.
- Flow 15y agoI've been afraid of this too. I wrote a system in C# that used immutable data and actually used that to do rollbacks when evaluating a scenario failed. My fears was that since there are no "val" and really bad immutable collections in C#+.Net the maintenance coder would probably remove list.AsReadOnly() and putting in public on setters as part of fixes to bugs. That didn't happen though, the maintenance guy was really smart and got the ideas without me explaining much more than mentioning immutability. But this is why languages like Scala are important. Immutability and similar design(patterns) are a result of discipline and sometimes convention in languages like Java and C#. It's bound to fail due to humans being humans.
- gruseom 15y agogoing like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it This is a problem even when the maintenance programmer is not a mercenary. Check out the essay by Peter Naur (the N in BNF) called "Programming as Theory Building". It's one of the best things ever written about software (albeit in disappointingly bloodless language) and explains this masterfully. http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22 http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn... The essential point is that source code and documentation, no matter how well-written and extensive, are insufficient for understanding a large system. You have to have the "theory" (the article explains what this means) and for this you have to have someone who knows the theory.