91–100 of 124 posts
One thing that baffles me in corporate IT is not just the snake pace of development but rather the fact that nobody seems to be bothered by the snake pace. There is zero effort to measure or speed things up. The only important thing is to be nice to everyone, any mention of productivity is considered hostile behaviour. (For reference, I am talking about cases where a team of 5 devs takes 2-3 months to deliver a featu…
You mean snail or like moving in an "S"?
There is a critical error in this statement that some would label as 'subtle' but it's about as subtle as a rusty axe to the forehead. Judging people by lines of code doesn't 'incentivize [] practices that are counter to building good software'. It punishes you for writing good software.
While we do need to be aware of the negative consequences of inaction, that's a problem to be solved once you have stopped actively digging a hole. That's a problem to be solved once you have stopped pushing people into that hole. That's a problem to be solved once you've stopped publicly congratulating people for not being pushed into the hole. By you. With an audience. There is nothing remotely subtle or nuanced about that distinction.
There's an old adage that if you make laws people can't respect, then they will stop respecting the law. This is but one route to that problem.
Decision making purely based on such metrics is wrong. It's management by numbers, and similarly like coloring by numbers, while relatively easy, will not produce great results. At the same time, metrics do have a place. Even flawed metrics, like the ones this article describes can provide value. When used together with qualitative evaluation and thoughtful analysis, it provides a more complete picture of what is goi…
Metrics are for asking questions, not answering them.The problem with all of these metrics is that they assume that there's an engineering team, or someone on an engineering team, somewhere that's not doing shit . Whether the business believes they're not doing shit because they refactor more than they write features, because they release twice a year instead of every week, or because they have less frequent merges. The entire emphasis of measurement is squarely a tech…
I’ve worked with teams and individuals that do nothing. Like literally nothing, they do shit. I once had to wrap up a product release for contract close out or something and it involved getting all the code and commits from developers who were rolling off. It amazed me how many had zero code they had written in months. I had one developer that had never committed anything in the three months he was there. Obviously t…
Having some metrics here can help sort this out before you call some senior dev at 12:30 in the morning for code they didn't even write.
Earlier quoted context omitted.
But then how will non-technical managers justify their salary?
I know the question is probably sarcastic. But being serious: Simply by being good at their jobs of helping the people they manage and having those people want them to be part of the team. And then on the flipside as well where higher ups trust them to help be a good translation layer that enables teams to meet organizational objectives.
I've said it before and I'll say it again: finding ways to characterize people as bad at their jobs is about keeping salaries down, whether by accident or on purpose. Because those are metrics your boss's skip level manager looks at. And they 'work' until they don't, by which point the manager can move up or out and get a reset on the numbers being used against them.
Earlier quoted context omitted.
So how do we measure it?
Why do we need to? No, seriously, why? I have yet to see any meaningful increase in a team’s productivity after they start tracking “developer productivity”. Each time it results in a blow to developer morale and a pretty dashboard that management uses to retroactively justify their decisions.
It's a terrible answer, in no small part because it's true.
How do you manage people when you're bad at managing people and can't/won't look at it? You manage safe, crisp, numbers instead.
Now, I would contend that the rest of the productivity metrics depend on what the team and its parent structures are trying to achieve, and should be DIFFERENT over teams and over time. Maybe a team with a spaghetti-like legacy project will want to track LOC or cyclomatic complexity for a while. Maybe some other team will want to track the amount of transitive dependencies. Maybe some will want to optimize for onboarding (time-to-10th-PR or something like this). 1 size will not fit all, and the team and its management must work to figure out what success looks like w.r.t productivity based on the context at hand.
Earlier quoted context omitted.
Are you a manager at Amazon employing these or seeing your peers employ these metrics? I've never heard of such a thing. It's leadership principles only AFAIK.
I worked there for a bit over 2 years, pretty recently. I heard this from other engineers and from managers not directly in my chain. The iterations per MR metric is one I know for a fact is used in PIP docs. Heard this directly from a friend that was PIPed.
OK so this is hearsay, your original post did not frame it as such, and you walk it back further here.
In addition other Amazon people seem to not agree, maybe don't post something like this next time.
Earlier quoted context omitted.
So you’re becoming “aware of what each other is doing” by half reading the pr title and going straight to approve button? I think “legitimately “ is doing a lot of lifting here too
You seem to presuppose that the people involved in the team conversations about these metrics are stupid or clueless to a point of willfulness or intentionally bad actors. If that's the case, as with the case where you're somehow able to approve your own CR's, you face problems unrelated to the numbers. If those are the kind of problems you face, you need to fix them well before you try to bring in any processes desi…