3 ms·

Also draws a poor comparison between e.g. a 20-years-experience coder who was writing C++ until a year ago and someone fresh out of college whose been writing n

Also draws a poor comparison between e.g. a 20-years-experience coder who was writing C++ until a year ago and someone fresh out of college whose been writing node.js nonstop in the three years since getting their degree. There may be one you have more fun playing ping pong with, but (and I say this as a youngster myself) the professional choice is the one where the value for dollar is best and the code is something you won't dread maintaining.

zbentley 9y ago
> the professional choice is the one where the value for dollar is best and the code is something you won't dread maintaining. That's very true, but might not necessarily favor either of your two examples. The choice between "20yr C++ veteran and 3yr node coder" is not always obvious or clear-cut, and the quality differential does not, in my experience, clearly favor either side based on that information alone. I've seen people who left school and coded like crazy for a few years on flaky and fad-oriented stacks--because that was where they could get employed in a hurry with zero experience and a lot of debt. I've seen those people emerge from those environments with an incredibly solid understanding of software design principles and how to do things professionally while balancing time/money/legacy/human/etc. concerns. They learned those lessons not by refining their craft over 20 years of working on an old stack, but in just over 2 years of working on a stack where every day they had to ask their "rockstar" colleagues questions like "Why is this simple thing so hard to do? Why do you keep writing the same kind of bug over and over? What alternatives exist to these tools/strategies?" and not getting good answers. These folks didn't code much outside of work, but they did read about other tools/practices in their free time. By the time they left, they learned excellent techniques (and professionalism) out of acute, concentrated discomfort at what they were made to work on, even while everyone else was taking shots of the piss and calling it brandy. (And yes, I've seen people in that same situation internalize the cancer and become "X. It's the future!" zombies.) And I've seen 20+ year veterans who were extremely proficient in a very few (one or two) methodologies, who tried to apply those methodologies to everything--even use cases where it didn't make sense, confused their colleagues, and directly induced bugs ("Making a chat app prototype/mockup for management next week? JavaScript doesn't have CORBA support? Let's write low-level TCP code in Node so we can emulate CORBA using a library I'll write for you. Thrift is too new, I don't care if it's already supported; WebSockets are the 'wrong model'; you need a proper brokered architecture for this . . . proof of concept . . . wait, why is my TCP reading code corrupting data because of off-by-one errors in my read loop?"). I've seen very senior programmers whose "breadth" of tools understanding consisted of re-implementing very specific design patterns from e.g. Java or C in a dozen languages, rather than learning to use the tool that was correct for the job. I've seen extremely experienced people whose expert understanding of a few things concealed intense insecurity about their knowledge in other areas, and who defensively tried to fit many square pegs in round holes--anything from "we need to use this email collaboration tool I'm super good at that everyone (happily using $other_solution already) has never heard of", to crazy implementations of object/factory patterns in functional languages, to bizarre architecture review and management practices. These people were all competent, and very experienced. They were also scared--not of learning new things, but of being inferior in any single way to their colleagues, even after decades coding. That's a shame, since those folks had the most to teach others, if they'd taken time to have a sense of perspective and/or face their fears. (And yes, I've seen people with that experience be refined into amazing teachers and stellar coders over the years--people who could get deep understanding of a totally unfamiliar tool in a week, be teaching others to use it in two, and be teaching others when not to use it in three.) TL;DR the choice is not that simple. But I haven't seen a clear correlation either way between time-spent-in-industry alone and professionalism or output quality. Every industry has old deadweight and young cocky rockstar-wannabes.
- hawkice 9y ago
  To clarify: yes. I've seen veteran coders produces piles of C++ templates of templates and Java reflection and configuration nonsense that seemed to solve no problem I've ever been aware of. I've seen technical leads write code where every single field in a class has a one-letter name. And I've seen clear, thoughtful code from people not too experienced (although never a total novice). But that's my whole point. Age discrimination isn't the only reason 'technical half-life is 3 years' is bogus (not [only] morally outrageous but wasteful of the discrimator's own dollars) -- but also because we should have actual standards. And not just any standards! Things like code cost and quality vs price. I feel like we've gone a bit through the looking glass because explicit knowledge of how to program well is maybe 15% of the actual craft. [Unrelated side note: I've heard of people using flash cards to try and learn programming. This is deeply weird to me! But I think it also reflects this 'half life of programming knowledge' way of thinking.]

zbentley 9y ago

> the professional choice is the one where the value for dollar is best and the code is something you won't dread maintaining. That's very true, but might not necessarily favor either of your two examples. The choice between "20yr C++ veteran and 3yr node coder" is not always obvious or clear-cut, and the quality differential does not, in my experience, clearly favor either side based on that information alone. I've seen people who left school and coded like crazy for a few years on flaky and fad-oriented stacks--because that was where they could get employed in a hurry with zero experience and a lot of debt. I've seen those people emerge from those environments with an incredibly solid understanding of software design principles and how to do things professionally while balancing time/money/legacy/human/etc. concerns. They learned those lessons not by refining their craft over 20 years of working on an old stack, but in just over 2 years of working on a stack where every day they had to ask their "rockstar" colleagues questions like "Why is this simple thing so hard to do? Why do you keep writing the same kind of bug over and over? What alternatives exist to these tools/strategies?" and not getting good answers. These folks didn't code much outside of work, but they did read about other tools/practices in their free time. By the time they left, they learned excellent techniques (and professionalism) out of acute, concentrated discomfort at what they were made to work on, even while everyone else was taking shots of the piss and calling it brandy. (And yes, I've seen people in that same situation internalize the cancer and become "X. It's the future!" zombies.) And I've seen 20+ year veterans who were extremely proficient in a very few (one or two) methodologies, who tried to apply those methodologies to everything--even use cases where it didn't make sense, confused their colleagues, and directly induced bugs ("Making a chat app prototype/mockup for management next week? JavaScript doesn't have CORBA support? Let's write low-level TCP code in Node so we can emulate CORBA using a library I'll write for you. Thrift is too new, I don't care if it's already supported; WebSockets are the 'wrong model'; you need a proper brokered architecture for this . . . proof of concept . . . wait, why is my TCP reading code corrupting data because of off-by-one errors in my read loop?"). I've seen very senior programmers whose "breadth" of tools understanding consisted of re-implementing very specific design patterns from e.g. Java or C in a dozen languages, rather than learning to use the tool that was correct for the job. I've seen extremely experienced people whose expert understanding of a few things concealed intense insecurity about their knowledge in other areas, and who defensively tried to fit many square pegs in round holes--anything from "we need to use this email collaboration tool I'm super good at that everyone (happily using $other_solution already) has never heard of", to crazy implementations of object/factory patterns in functional languages, to bizarre architecture review and management practices. These people were all competent, and very experienced. They were also scared--not of learning new things, but of being inferior in any single way to their colleagues, even after decades coding. That's a shame, since those folks had the most to teach others, if they'd taken time to have a sense of perspective and/or face their fears. (And yes, I've seen people with that experience be refined into amazing teachers and stellar coders over the years--people who could get deep understanding of a totally unfamiliar tool in a week, be teaching others to use it in two, and be teaching others when not to use it in three.) TL;DR the choice is not that simple. But I haven't seen a clear correlation either way between time-spent-in-industry alone and professionalism or output quality. Every industry has old deadweight and young cocky rockstar-wannabes.

hawkice 9y ago
To clarify: yes. I've seen veteran coders produces piles of C++ templates of templates and Java reflection and configuration nonsense that seemed to solve no problem I've ever been aware of. I've seen technical leads write code where every single field in a class has a one-letter name. And I've seen clear, thoughtful code from people not too experienced (although never a total novice). But that's my whole point. Age discrimination isn't the only reason 'technical half-life is 3 years' is bogus (not [only] morally outrageous but wasteful of the discrimator's own dollars) -- but also because we should have actual standards. And not just any standards! Things like code cost and quality vs price. I feel like we've gone a bit through the looking glass because explicit knowledge of how to program well is maybe 15% of the actual craft. [Unrelated side note: I've heard of people using flash cards to try and learn programming. This is deeply weird to me! But I think it also reflects this 'half life of programming knowledge' way of thinking.]