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…
Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.
The worst programmer I know
41–50 of 668 posts
Re: The worst programmer I know
#42I sometimes wonder if developers should do an end run around all this bullshit and come up with and start measuring management productivity metrics. I dont see a downside to doing this.
Managers don't stay in the same role long enough to have their productivity measured.
Re: The worst programmer I know
#43I often wondered why s/w development is always a rush at the expense of quality. Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.
How on earth, you might wonder, did we ship software that worked?
I then saw all these things come down the pike one after another during the last half of my career.
Clearly to me every one of these benefit management who found themselves apparently unable to function without numbers, graphs, data of some sort. It has been a very obvious (to me) power struggle: management trying to get the upper hand and wrest any and all power (and autonomy, and decision making) from engineering.
It has been sad to me to have heard some new engineers come on board who like these things. It's just as well I retired when I did: it's probably me that is the odd man out now.
Re: The worst programmer I know
#44I dislike the just-so aspect of these sort of stories. I'd expect exceptional programmers to do unusually well on most metrics. But that is balanced by the threat of people trying to use metrics to measure developer productivity. It doesn't seem to be possible, any metric falls apart. If people are focusing on a metric, the greats aren't going to be leading any more. It'll be some junior who has misunderstood the sys…
> I'd expect exceptional programmers to do unusually well on most metrics. ...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible. Product team: Hmm, we need to do a thing that looks very complex and difficult. Senior dev: I'll start making a project plan and story breakdown. Very senior dev: That sounds like a special case of a thing we already have.…
I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution.
This makes their code easy to read and therefore easier to debug.
It’s worth noting that the less you type, the fewer bugs you’ll create.
To be fair, this is often due to the coder having significant experience.
Re: The worst programmer I know
#45Earlier quoted context omitted.
The logical conclusion to that argument is that we should do away with the lot of them.
We all feel like management contributes nothing, right? But they seem to always be around successful companies. I dunno, correlation isn’t causation, but I think there must be something there.
There are also plenty of successful companies and projects without management too. Basically every 1-to-5ish-man consulting shop has zero managers and some of those do wildly well. Some of the best indie games, produced by teams of 3 or 4, had zero dedicated management. Most open source projects have effectively 0 management.
Valve, famously, kept a flat organizational structure for a long time, and certainly was somewhat successful.
Re: The worst programmer I know
#46Well, 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…
The story includes a part where they dropped the crappy metric and changed to a better one.
Re: The worst programmer I know
#47Reminds 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.
Re: The worst programmer I know
#48Stories like this happened is because managers want to treat software development as a manufacturing process.
"OK, last sprint the team did 150 points, so we should do 160 points this sprint."
The funny thing is that point estimates just went up to compensate for productivity gain demands. "More productivity" yay!
Re: The worst programmer I know
#49It 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…
I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.
Re: The worst programmer I know
#50Well, 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.