It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
In a remote world, can that person exist?
The worst programmer I know
31–40 of 668 posts
Re: The worst programmer I know
#32Like, for someone in tier 1 / tier 2 helpdesk, or the regular developer pushing relatively normal tickets through, simple ticket or story throughput is one indicator of productivity. As long as you pair it with some success measurement, like re-reports from people within a short time, or work caused by the implementation. Or just feedback from the rest. Someone has to put down code to make the feature work in the end.
But this changes when you get more specialized and overall more experienced. If we bring a new technology into the team, my productivity based on the first metric will drop to zero. I'll be busy supporting other people. Or, the incidents on my desk will be far more weird ones. Other people get clear click paths and an exception. I had to debug JVM crashes due to faulty hardware. That took a bit longer than an afternoon in a debugger and adding an if-statement, if I may embellish a bit.
But that's why soft skills become important. It's concerning how little that manager knows about his team. But it's also concerning how Tim didn't make sure his manager knows what's going on. For example if we're bringing in new tech, I'm informing superiors first that I'll prioritize support of team-members with the new tech just below business critical incidents and I most likely won't do any regular work for some time.
Re: The worst programmer I know
#33Well, I like the story here, but it's kinda against a bit of a strawman. Don't get me wrong, I'm not losing the overall point of the piece, a point I agree with, but that said a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer. Ultimately the best way of measuring programmer productivity is by the ass…
So I used to kind of think like you, but I think that's just not a practical approach. Yes, you could alter the system in this 1 exact situation if you know exactly what to change, but there will be dozens of other failure modes too (engineer releases code that breaks in 2 months, engineer deliberately mis-estimates story points, engineer doesn't comment their code so that nobody else on team can do certain work, etc…
Re: The worst programmer I know
#34Re: The worst programmer I know
#35It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
In a remote world, can that person exist?
Re: The worst programmer I know
#36It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
Re: The worst programmer I know
#37It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
Re: The worst programmer I know
#38Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell…
Re: The worst programmer I know
#39Well, I like the story here, but it's kinda against a bit of a strawman. Don't get me wrong, I'm not losing the overall point of the piece, a point I agree with, but that said a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer. Ultimately the best way of measuring programmer productivity is by the ass…
I believe that’s the conventional approach in Python, though? It is a duck-typing language, try-except is a legitimate way of seen if an operator works on an object, and objects should do sensible things with operators. The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
Re: The worst programmer I know
#40It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
In a remote world, can that person exist?