For small companies, engineering managers & direngs should be aware enough through working with the team members individually & through PR review who is performing and who isn't, and not need to deploy metrics.
The worst programmer I know
121–130 of 668 posts
Re: The worst programmer I know
#122Earlier quoted context omitted.
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.
Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.
Re: The worst programmer I know
#123> He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses. I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run…
Quite simply, no. You're not going to learn from being handed an answer on a silver platter. You'll implement it, get on with your day, and not at all think about why the answer is what it is.
this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding.
all this method is doing is forcing multiple people to go through the discovery process, when all that should be needed is for one person to do so. its a waste of business resources. person A can share with person B, then person B can go on to make their own discoveries. we dont need to force every employee to discover EVERYTHING on their own. thats just a huge waste of time. it would be like forcing everyone to discover Pythagorean theorem on their own, instead of giving them that tool and letting them use it to create other stuff.
Re: The worst programmer I know
#124But it's usually contained to someone like a junior calling me up and saying "can you help me?". The answer is always "yes of course!" and I share as much as I possibly can. But it ends there.
I just want to sit down and show them things. Teach them in a way that makes things "click" the way I found they clicked with me. But I don't think management really values this approach. We get siloes of knowledge and then when someone leaves it's all hands on deck to transfer that knowledge.
I'm often brought onto projects as a firefighter because I'm seen as productive. But I think the more important thing for the team would be to have me upskill everyone else below me. But for whatever reason, it's hard to get that point across to management. I can see myself in a few people and that they have potential, they just need encouragement.
Re: The worst programmer I know
#125I 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.
How would coming up with good metrics for "management" be any easier than coming up with good metrics for "programming"? At least programming has some verifiable realities that can be witnessed objectively by multiple observers. Not that such things are often used on "metrics", but they could be. The quality of someone's management is hard to assess from outside, much less objectively verify. Has your manager increas…
Measuring is an aggressive act intended to invoke control that has a veneer of innocence.
That said I'm now wondering if there wouldn't be some metrics which might prove useful to workers either way.
Re: The worst programmer I know
#126Earlier quoted context omitted.
Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.
It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more sub…
Re: The worst programmer I know
#127It 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 saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.
Later, I care much more about avoiding accidental complexity and having a great technical foundation.
Re: The worst programmer I know
#128Earlier quoted context omitted.
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…
The most impressive thing about this story is that they figured out the answer . They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.
Re: The worst programmer I know
#129It is also possible if they fired this guy, and replaced him with another developer that only did points that the organization would be more productive. Without quantifying it or comparing to an alternative, this is just feel good commentary. If you deliver any value, that does not consequently make you a good business decision. You have to pit your value against your cost and the companies best alternative option. A…
The argument here is which metric, or are metrics good for anything? [1]
[1] Except ditch digging and children. It is well known that 9 people will dig a ditch in 1/9 the time one person will, and 9 women will make a baby in 1 month instead of 9.
Re: The worst programmer I know
#130It 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…
Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...