The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables.
Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The value of them saving that work from knowing another way is high but hard to measure.
What you want is measuring business outcomes but those are hard to attribute to a particular developer.
I think unfortunately we're left with our subjective judgement here. I think we'd do better admitting to ourselves that we can't measure this than to pretend we have some sort of science here.
I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code.
One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem was that this intern was bad, so we had him write unit tests. However, he was also bad at writing unit tests. He would run the code and then write tests that enforced the current results, instead of considering that the current behaviour might be incorrect. Thankfully we didn't hire him after myself and others explained why the intern had so many commits and lines of code written.
Reminds me of an old joke about a policeman who pulls over a poor driver. The driver complain "But I haven't been in a single accident", the reply from the policeman, "Yes, but you've caused dozens".
Some people are just oblivious to the trail of destruction left in their wake.
Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance).
Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of being skipped for promotions and left the company, creating a minor staffing crisis
There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.
> ...It's a common story and an interesting angle, but the "best vs good enough" formulation misses something. It sounds as if there's a road towards "the best" – towards the 100%. Engineers want to keep going until they actually reach 100%. And managers force them to quit at 70%:
> > There comes a time in the life of every project where the right thing to do is shoot the engineers and ship the fucker.
> However, frequently the road towards "the best" looks completely different from the road to "the good enough" from the very beginning. The different goals of engineers and managers make their thinking work in different directions. A simple example will illustrate this difference.
> Suppose there's a bunch of computers where people can run stuff. Some system is needed to decide who runs what, when and where. What to do?
> * An engineer will want to keep as many computers occupied at every moment as possible – otherwise they're wasted.
> * A manager will want to give each team as few computers as absolutely necessary – otherwise they're wasted.
> These directions aren't just opposite – "as many as possible" vs "as few as necessary". They focus on different things. The engineer imagines idle machines longing for work, and he wants to feed them with tasks. The manager thinks of irate users longing for machines, and he wants to feed them with enough machines to be quiet. Their definitions of "success" are barely related, as are their definitions of "waste".
> The "good enough" is not 70% of "the best" – it's not even in the same direction. In fact, it's more like -20%: once the "good enough" solution is deployed, the road towards "the best" gets harder. You restrict access to machines, and you get people used to the ssh session interface, which "the best" solution will not provide.
Probably not the point but committing every day is one methodology for TBD and it’s great for generating productivity. Not so much useful for measuring productivity though.
I can’t imagine how miserable it would be to try to measure dev productivity by quantifying commits on a daily basis. What a waste.
Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure.
That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.
> at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits.
This works for Junior through Senior level roles, but it falls apart quickly when you have Staff+ roles in your company. Engineers in those roles still code, but they write a fraction of what they used to and that is by design—you want these people engineering entire initiatives, integrations, and migrations. This kind of work is essential and should be done by your top devs, but it will lead to many fewer commits than you get out of people who are working on single features.
With a few exceptions for projects with a high degree of source-level complexity, a Staff+ engineer who's committing as much as your Senior engineers is probably either misleveled or misused.
I've worked on projects where every single ounce of enthusiasm is coming out of one mediocre developer. Nobody pays attention to team dynamics like this, but they're all over the place.
With my minor dabbling in game theory, I've considered funny angles like secret-ish internal metrics and punish those who simply game the incentives. Example: bot detections and banwaves in MMOs. Instead of instantly banning plausible bots, the company has to hide its (ever-changing) internal algo and ban in waves instead.
Basically, treating (non-)productivity like bot detection, lol.
> That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits
Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones who crank out code, albeit maybe as not as much as a senior engineer. Staff engineers who only commit 1 a month are usually the ones who don’t bring value to the company, especially given their high pay.
> The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure.
Related to Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".
I'm wondering if this is only true if the act of measurement is transparent (so that the people being measured can game them). If the act is opaque enough such that the form of the metric cannot easily be guessed SEO-style, then maybe wave function collapse can still be avoided?
You probably can't do it observationally. You could give several developers the same project, and probably see pretty big differences in timeline and quality. But no one is going to put in the work to run that kind of assessment at scale with the level of realism and time duration (probably several weeks) to make it meaningful.
I like looking at lines removed and, in context with, lines added or PR count. Someone more experienced will be refactoring and removing old stuff while adding new stuff and will have some balance (barring vendoring or moving file trees between repos)
> What you want is measuring business outcomes but those are hard to attribute to a particular developer.
I think we could solve this by eliminating some middle tiers and putting the developers on the actual customer calls every week. Each senior developer owns at least one customer. That sort of thing.
It's a completely different ball game when you are a developer on some B2B/SaaS and you are answering directly to the customer regarding your work. There's no one to hide behind - your teammates are now aside you and can only render supplemental aid. Once you have developers answering directly to the customers, you have a simple, ~boolean, qualitative metric that virtually any manager/investor can get behind: Is the customer happy?
If the developers are keeping the customers happy, then they are performing. If the customer is unhappy, then there is a performance issue. Whether or not most or all of it can be attributed to blockers on the customer's side is irrelevant at the senior levels of play. Developers should be helping the customers get unblocked. Offer meetings & screen share time. Generally, make yourself as available as possible. If you do this correctly, the customer is likely to take note and provide you with some amount of cover (i.e., not be in a raging fit when they call your CEO).
There is no reality in which you can inject more middle management or process to get developers to take more accountability. The only thing that works is to get them out of the bullshit matrix and in front of the customers. They need to experience how it feels to work directly with a happy customer and then realize how important it is to keep them that way.
This path also happens to solve a whole host of other maladies in technology business, most notably shiny rabbit chases. When you have the fear of god in you regarding the client, you aren't going to be as inclined to play in traffic with a NuSQL engine on their watch.
lol no, I have worked with companies that do that. Many developers have very specific personality types, and they also think in technical terms rather than customer terms. It isn’t a bad thing, it is why they are good at what they do.
The most successful companies I have worked with have a good product manager that can take customer input and work with a technical manager to balance priorities/effort. The technical manager consults the team before making decisions (such as SCRUM meetings if using that)
Issues come into play when folks start distrusting developers. When we say it will take 4 weeks or 8 weeks to implement something, there is a reason for that. We know the code. We know how much of a PITA it is to work with, and we aren’t being misleading. On the flip side, we have been trained to give conservative estimates thanks to crap management and unexpected pitfalls, so we try to understand promise and over deliver. If management could recognize this, everyone would be happy, provided they recognize that 8-week timeline is fine and they don’t promise something different to the client and trust devs to do their thing.
EDIT: Managers also tend to forget that we aren't a machine in a factory. We have good days, bad days, and everything in between. We excel with using our brains, however our brains suffer from anything between lack of sleep, depression, and other nonsense due to just plain having a bad day. I feel like it is more noticeable with us because we rely on our brains so much more than other folks in other professions do. Shoot, even random noise in an office, whether working at home or at an office, can hurt productivity.
Now I have myself missing dev work. Hoping to go back soon. Currently unemployed.
Could a company keep a subjective poor performer on for the lifespan of the company? As in, what is the plus or minus in overall revenue or profit from this charity? What if all companies did that? Could we distribute the "burden" of the charity across all companies for a better society? My point is, I don't even know if metrics are good or bad, we may need to look at why we see each other like this. Is it so offensive to the mind of the captain of a ship that they may have a few of not the best sailors? It's a chance for them to be on a ship, go on a journey. The concept of a "free ride" appears to be a serious moral hazard for us, but I can't figure out why.
Sure, as long as they don't have any responsibilities. I've been a great performer at some companies and a poor performer at others, including one that kept me around without letting me have any responsibilities. It was not good for me. But I have been through worse.
A better alternative I've seen is to help the poor performer hunt for a new job.
This is what Japan does. Employment is presumed to be for life. There are games companies play to get out very poor performers but most people get approximately lifetime employment.
Are you going to accept such free rider in your team? You will eventually do both your and his tasks but for the same or worse pay. Given you have a fixed budget for the team - do you want to split it more ways?
This reminds me a bit of how VCs bet on a bunch of startups in full knowledge that many will fail. The failures in some sense get a “free ride”. Why not the same with people?
Where I work, the CI pipelines measure changes in code coverage.
If I refactor repetitive code into something more concise and maintainable —- code coverage goes DOWN! (Now the proportion of untested code is larger!)
Vibe coding is now a skill requirement for real, actual jobs but, thankfully I guess, no place I want to work (yet). The other day I saw a YC24 company in the "financial services industry" with a "vibe coder position". A prerequisite for the position was at least 50% of your current code being generated by AI; vibe-coding experience was "non-negotiable". Traditional programmers need not apply. And you'd better be ready to grind, 12 hours a day up to 7 days a week. It pays up to $120,000 a year plus squat for equity and relocation to San Francisco is required. That's like, McDonald's money in San Francisco, so guess they figure running a vibe-coding sweatshop is a huge savings for them.
Oh, and the cherry on top? The "financial service" this startup provides? Automated robocalls demanding money from debtors on behalf of debt collectors.
I've been writing code professionally for a decade but I've never written so much code in my free time because I can just vibe code it all. I wouldn't do it at work and I probably wouldn't trust a juniors vibes as much as my own but no tools have made me feel quite so powerful.
Well said. There’s a noticeable lack of judgement in many places these days; people think they can abdicate it to metrics and data but this is mistaken.
Kind of meaningless statement though. Even if they do, which Im not sure is true in general case because you have to be good yourself to know who’s really good, they are not telling you anyway.
This is the key. Ask all the developers for a ranked top-3 list of who they would most prefer to go to for help with a programming problem. Put that data together and you know who your best are.
Before the inevitable protest: I believe the ability and willingness to communicate with other developers is a vital skill in this business.
I don't think productivity itself is absurd but it's definitely a hard thing to do, especially in small time intervals.
I think it's important to measure employee performance and you can definitely can a macro look and say "what have you accomplished in the last year" which might be measured of delivery of "t-shirt" sized projects
I don’t think it’s that we _can’t_ accurately measure developer value/productivity, it’s that doing so isn’t feasible with any methodology we currently have. As you said, we’re not doing magic, therefore our value is measurable. Measuring just requires an impractical degree of time and energy.
but also, the reason we come together to work as groups is so that we can achieve more than we would as the sum of the parts. The same is true for horses, two horses that work well together put out more power than two individual horses. So the problem becomes when you identify one of your horses has 1.5x the output of the other, and think firing the weaker horse will lead to minimal productivity gains, you end up with egg on your face when you realise you are not left with a horse that works 1.5x, but rather a horse now working at 0.5x what what it was in a team. The exact same thing is true for team work, team sports, etc. There is no one person 'holding it all together' if there is, then that person needs way better support and realistically, should get the entire departments pay when the remaining department is let go.
> The idea of measuring individual developer productivity is kind of absurd to me.
It is absurd to do in a lot of settings. The other day we had a similar story with the measurement of "value" just the other day[0]. I think there's been a big bureaucratic takeover where people are measuring for the sake of measuring rather than recognizing that these things are proxies and you need to be careful to ensure your proxy is properly aligned with the actual thing you want to measure.
You see this in research and academia by trying to measure by number of papers/citations/venue/novelty. You see this in the workforce with things like lines of code, story points, and any of that other bullshit. You see this with how people think about money. Like just think what a million dollars a month would mean what you __*couldn't*__ do wit that money.
The problem is that we've created scoring systems and people see the ultimate goal as maximizing their scores. This doesn't matter if the score is actually meaningful or not, but we'll sure as hell passionately argue that they do. I'll refer to my comment to [0] for more[1].
I've been calling this concept: Goodhart's Hell
The truth is that every system has noise in it. I completely understand wanting to remove all possible noise from the system, but after a certain point, attempts to remove noise are actually ignoring noise. Maybe the problem is that people don't recognize that randomness is itself a measurement of uncertainty. There is no measuring device that is without uncertainty. Embrace the noise. Remove as much as you can, but you need to embrace what is impossible to remove. You create more noise by ignoring the noise.
> The idea of measuring individual developer productivity is kind of absurd to me.
that idea is very attractive to every manager on planet earth. they seem to quickly lose their ability to maintain contact with reality and they start using metrics to track everything, rewarding those who game the metrics best.
It is not absurd. From manager's point of view, when they are deciding to let someone go or promote them, they often need some arguments. And since software is invisible, it is often hard to just say straight away who is over/underperforming and why you think so apart from a "vibe" you are having. Measuring some relevant metrics can strengthen your argument and/or your overview of the situation.
I don't think that the blog makes a compelling argument why measuring productivity is bad per se. It makes a compelling argument that metrics should not be interpreted blindly, but the metrics in this case identified a guy that was doing something unusual, and the managers managed to interpret why this is the case. But if it was an IC that is supposed to deliver, or if you did not want "Tim" to spend his time coaching people, this could still have been valuable info.
I don't think it is absurd to reason about individual contributions, just to focus on measuring them with metrics. I have been on the management side as well though I admit I am much more of an IC. But the way I think that should go is laddering up to business value by describing what the person did and why that contribution was important.
So for example I would say something like: X deserves a promotion because their work was important to delivering project A on time. Project A was difficult but worthwhile because it allowed us as a business to meet goals 1 and 2.
That said I mostly work in smaller orgs. I have never been in a situation where a manager would be so removed from a team they would need a sort of proxy metric to direct them where to focus their attention to understand what the people on their team are doing day to day. I can see how this would get more difficult as a company grows.
Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team against obtuse velocity metrics like this.
productivity metrics aren’t entirely worthless. if I come into a team, for instance, and I see they have 1 PR mapped to roughly every 1 jira ticket, and I see a guy on a 3 person team that’s got 70% of the PR’s in a year, that isn’t a clueless piece of info. he’s probably the lead. not always, and people game stuff like this, but it is a data point you can make note of.
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on.
I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by any metric.
In the end you're building up a system where everyone participating in it knows it's a fraude but just keep gaming it because they become too heavily invested in it.
I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do?
I have a person who I highly suspect isn’t doing much work, and is basically rotating through other team members to help him get unstuck. Not a bad guy, but probably not up to our standards. Just ask people you say? Many cultures don’t allow for someone to say bad things about their coworker even if it would help to improve the team.
I’m not arguing for any one solution because I don’t know of any magical solution. If you have better metrics or management skills than what everyone in the world has figured out, myself and many others would gladly adopt these approaches.
I have managed a team in an organisation that used Jira heavily to measure velocity and having all contributors record time on tickets, even if they were just supporting, did actually help lots:
1. It allows for more accurate estimations (ie this is not a multi-day task but it is a multi-person task)
2. It showed where knowledge transferring was happing
3. It showed that people were busy so that it meant we were making accurate estimates to begin with.
I do think Agile can get overly prescriptive. But if you do happen to work in a company that operates that way, pushing back might be impossible. So having multiple participants record their effort against the same ticket then allows a more organic way for the team to operate despite the rigid structure of a stricter scrum dynamic.
Or in other words: sometimes you cannot change the system entirely so you’re next best option is to tweak it so it at least better works for you. And that’s what the GPs suggest achieves.
More like bug/case tracking is crap on this. All the ones I've ever used only support one assignee, so even in equal pair programming you have to choose who officially gets the case.
They're suggesting working around the case tracker, not around the metric.
In a company or any business you need to deliver something, if you are being paid X amount of money, the payer needs to know they are getting something in return, and it's not a management problem that they ask what was done this week.
GP is orking off the assumedly common premise of peopel raising complaints of metrics and getting shrugs from management or Product. Who have their own incentives to keep them up.
if you can't throw out the game you may as well adjust the rules.
That's how you get individuals who insist that you attach their name to your ticket (or better yet, do it themselves) after they helpfully inform you about an automated test failure in your commit. "Relentlessly mentoring team members on culture of quality" et cetera.
Exactly. If you don’t consider how people might game the system, you are in trouble. Little fixes like this open other possibilities for gamesmanship and now people fight over whether their contribution was good enough to be included in the ticket.
I mean, all of this is gamable by those who want to minmax. But this is a workplace and those kinds of abuses can be solved with a slap on the wrist 80% of the time.
You're absolutely right, but some people just refuse to play silly games. It's odd that the manager isn't ever in the room with the team and doesn't understand his team's dynamics. Giving the benefit of the doubt, he must have been new, but any manager worth his salt will ask people on their team what the team dynamics are.
My understanding is that metricizing like this is a tangible way for managers to defend "underperforming" team members to upper management. Your manager can always say you're a valuable member of the team and that will certainly go quite a way, but it's even more powerful if your manager can say, XYZ is an I valuable team member, if you need evidence of that, they provide a lot of value in supportive roles like on these tickets. [Listing tickets].
I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.
Some people will just find the metrics dumb and depressing, and avoid them. (As might've happened in the article.)
Some assume it will go away in time, or that their manager will cover for them. (As eventually happened in the article.)
Some have behind-the-scenes talks with managers+execs+HR, to end bad metrics.
Some will melt the metrics with the intensity of their look of disapproval. (Management ProTip: this level of will is better harnessed to solve business and engineering problems.)
That's a very personality and culture related phenomenon. A lot of folks will, but also a lot of folks won't.
Pointedly not playing the game when you have the political power to do so is often the most effective way to point out issues in the system that folks are being evaluated under. It can be a very wise move in some cases, as well.
Tim probably realizes that if he tries to get on tickets he’s helped with, he’ll probably end up on maybe 30-50%. If he never asks for credit, and yet is seen constantly working, people will inflate the zero to hallucinatory levels of productivity.
I consider myself a Tim here. My value is not primarily in my individual contributions, but how I eleveate the rest of the team.
If my manager demanded this type of bean counting, I'd just take my talents elsewhere. I'm not interested in that kind of game. I'd take the severance and go find a new team to make better.
Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games
Tim's problem is that he has a bad manager. One of a manager's core jobs is to communicate upwards the value that each team member is providing (or not providing). His job was to ensure that Tim's contribution were reflected and visible.
In football you track not only the goal scorers but also the assist (the person who passed the ball to he goal scorer). That still does not cover all contributions, but maybe that's a way to create more transparency for Tims case ?
In one of the systems I worked with each ticket had an "assignee" (who did most of the work), a "tech lead" (who knew what's going on and could provide status and guidance), and an "executive owner" (the person you'd escalate to if needed). I suspect those were custom fields and schema could be extended further if desired.
Glad to hear that Tim stayed and author managed to steer the entire process towards the right direction. Which requires a listening manager.
I experienced the "bad ending" of this productivity metric trickle down: OKR. This startup wanted not just team-based 3-month review Objective Key Result but also individual one, and on top of it, tied stock option to OKR. It was a robotics startup so very cross-domain teams (Software, Hardware, Embedded, DevOps, HW design, HW testing, HW maintenance etc etc).
The result? Developers became lonely islands. There were no "Tim" anymore. When I (Software Integrator) encountered an issue, that I just couldn't figure out but had a hunch it must be a deep-rooted issue, went to the expert (control/kinematics) for feedback. The answer I got was "I'm sorry I really want to help you but my OKR deadline is very close, and I simply don't have time". He could've probably fixed it in a day or less, but it ended up taking 2 weeks.
The problem turned out to be quite deep: inside layer upon layer of C++ mega monorepo, I found that boost library and a custom kinematics library had implicit struct copy and the different libraries (more than two) used different order for representing translation & rotation (xyz, rpy, Euler, Quaternion) and all of the ordering of each components were different. Somehow over 2 years of operation nobody got troubled by this until our new team had to use it.
Afaik I reported it to the Software team, but again, because OKR, nothing was done about it.
My sense was OKRs came later for both Intel and Google. Do you know around what year/size they started?
I worked with some ex-Google person who tried to get us to use OKRs. That totally didn't work. Larger company.
Like many things I don't think they're necessarily a bad idea it's just that good ideas always lose to culture. With the right culture/leadership it's not the process that matters. I.e. OKRs aren't going to fix an organization that isn't aligned and conversely there are infinite other ways to align an organization with the right culture and leadership. So in practice, like other things, it just ends up making things worse because it's never a real fix.
100% this. Want to sacrifice team output? Have team members be concerned about individual goals. Team alignment and synchronization will be off affecting the efficiency and effectiveness of that team's performance.
I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping.
A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.
Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?
Or if you really do have an insanely lopsided team where everyone is straight out of school with no experience, and a single super-senior dev, then... shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?
The post here is not a good example at all of metrics failing to capture work. In reality, it is surfacing the fact that either Tim's job title and metric are totally wrong for him individually, or else that Tim is failing to contribute the hardest code, and the team is failing to distribute the "helping" workload. In both cases, the metric is working as intended, and it is surfacing something very important than needs to be fixed. (Remember, "fire Tim" is not the only possible action you can take because of a metric.)
> when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.
I agree this would be healthy for an organization, but I don’t think that is often possible. In this example, the organization is clearly NOT tracking mentor activity. So, anyone who helps someone else, is getting zero recognition for it.
I work with a lot of people where ‘ruthless prioritization’ is considered a good quality. That means no one gets any help. All taking. No giving. Pure selfishness really.
Back to the example. Tim is stepping up and filling in a major gap for the company. People need help. He has decided to go against the grain and help. However, instead of doing it with the help of leadership, he is just doing what needs to be done and it almost cost him his job.
Frankly, I identify with Tim. I love helping people figure out problems. Be it build env issues, failing tests, or some design gap. I help people all the time on top of my other work. While my immediate manager knows that and is good with it, upper leadership doesn’t care and just wants everyone to act like what they are working on is more important then what their peers are working on. Ruthless prioritizing is a seed of toxicity.
I got a bit off topic…
How to encourage helping peers and juniors when helping isn’t tracked and isn’t rewarded or encouraged? How do you maintain a healthy culture despite all the metrics?
> So, anyone who helps someone else, is getting zero recognition for it.
Where I've worked, this is what 360 peer review during performance reviews is.
If your colleagues all say you're super-helpful, that's part of what it takes to get promoted.
If your colleagues all say you're selfish and never help out, this is something that needs to be addressed immediately.
It's a metric like any other, it's just collected twice a year rather than bimonthly, and it's qualitative rather than quantitative. But it's analyzed at the same time and given lots of weight when it comes to promotions.
>this is a bizarre model where one programmer does no individual work and does all the helping.
Sounds like a lead or manager. He definitely works like a lead in spirit. Cheaper for the company to delineate it like this.
>Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?
difficulties don't signify priorities. Maybe all the hard stories are low priority. Maybe the energy is focused on onboarding newer hires. Maybe there was a semi-looming headline and getting others' tasks done was more important than his individual module (or perhaps he was ahead of pace already).
I can see a dozen of scenarios this comes up in organically. I experienced a few of these firsthand.
> shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?
It sounds like this was precisely the situation, and the author's company did indeed take this very action, in response to seeing the data. So, what is your complaint?
No they didn't. They dropped the metrics for everyone entirely, and Tim's job title is unchanged. The article is arguing metrics are bad and shouldn't be used; I'm arguing metrics are a valuable signal and Tim should have been given a different formal role of mentor.
Was Tim hired as a teacher or trainer? What I find strange is that it sounds like Tim was not doing any individual work.
As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approximately 20% of my time pairing with others and 80% on individual contributions. (That's a rough estimate; it could be 25/75 or 30/70.) The article said that Tim was "patient", but perhaps he was too patient, wasting a lot of his time that could be spent accomplishing other things.
I've been the TL for a team of effectively 5 new grads before. Effectively all of my time was spent teaching them how to solve problems, fixing (preventing) bugs in their code from getting committed, and writing boilerplate, or infra code that would never be listed on whatever a story point is. But constrained their responsabilities into a format and structure that would play well with each other's so they would stop constantly rewriting each other's code every other week.
I enjoy teaching so that was a much more enjoyable way for me to spend my day, than drinking caffeine and cranking code the rest of the team couldn't understand. I joined that team because they were constantly missing deadlines. When I left that team they were finally ahead of schedule, but much more importantly they had a code base they all understood. That wouldn't have been true if I'd just written all the code myself. I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself. But true or not, when I left I would have no confidence the team could continue without me.
Could I have spent more time writing code? Probably, but what delivered the most businesses value? I was hired as a glorified software engineer but instead of delivering code, I delivered a team that could produce code. Their manager was *never* gonna do that. So should I have prioritized doing what my job title said? Or doing what's in the best interests of the long term mission? Every situation is gonna be different, if teaching is soul crushing for you, or more importantly, the team refuses to be taught, I would suggest just deliver code. In this case, everyone wanted to learn, so that was the easiest path forward.
> I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself.
> what delivered the most businesses value?
What the company should have done is hire you and one new grad (rather than five), who you could mentor without spending all of your time mentoring, and get the same amount of work done with two people for less money.
Do you think that's any relevant? Software development engineers in general are hired to work on projects as part of small teams, and their goal is to deliver projects. It's not story points, it's not burn down charts, it's not PRs, it's not LoCs touched. It's how many projects are delivered, and keep everything and everyone problem free. This means that if you are struggling, your team will struggle as well until you unblock yourself. If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
> If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.
Yes, obviously it’s relevant you have a fundamental misunderstanding about what software engineers do. We don’t “build systems” we diffuse risk for the managers. If someone is “helping build something” they can spend their own money doing that. This is business, the less work you do the more money you make.
Very interesting topic and as you say the ratio should very much depend on what his designated role in the team was.
For tech leads, I think the ratio should be heavily skewed towards enabling other team members (by pairing or working on cross-cutting concerns, usually devops/infra). Something like 20/80, where the 20% individual contributions are only the toughest nuts which can't be done in a reasonable timeframe by anyone else.
For senior developers, I'd say it depends on team composition. If there is one senior and 3 juniors, training them should be his primary concern. If there are 5 heavily specialized seniors, I'd say the ratio should lean towards individual contributions.
Yea the best teams I've ever been on have always had someone like Tim.
The best best teams I've been on, Tim's helpfulness osmoses onto other people, and instead of Tim always being the one, the process goes like this:
1. Dev gets stuck
2. Dev attempts to unstick self for appropriate amount of time given problem and probability of self-unsticking given resources (e.g. some stuff is easier to search for internally, or dismantle and go piece by piece)
3. Dev announces "hey I'm blocked on XYZ thing"
4. Whoever knows the most about that topic (not always Tim, but often Tim) puts that as like their highest priority thing, and almost always jumps in right away to help (unless they're like ignoring chat cus they're in the zone)
Works great especially if you do #4 at some break time (like say lunch or standup), and everyone has enough things to work on that they can do their own internal CPU pipelining and work on other stuff until someone has time to help unstick them
That's easy to solve. When they ask me it might take an hour or two until I come back to them. If they were just trying to us me as a rubber duck the problem will have been solved by then.
And it's not only devs. Also PMs have this behaviour. Sitting it out before asking what they need makes most question vanish.
Counterexample: Not everything needs to be a group activity or social. If a developer of average skill can't manage to deliver a feature without the constant help from a "Tim", it says something about your code, processes, team. I've worked at places where they used pairing as a signal the team was working well together, when the reality was the code was so brittle and full of hacks it took the combined help (usually moral support) of a Tim to help support through every little change.
Every team is different, but software development needs the time and space for individual work just as much as group work. A small team who needs a dedicated person for pairing, who also doesn't (or won't) do any IC work, is a huge red flag.
Don't forget about the type of software. Something really specialized or algorithm heavy (science or math heavy) might be harder to do solo than a CRUD app.
My experience is the opposite. Easy stuff is simpler to pair up. Really hard stuff is solo. E.g. I expect Ph.D. work to be mostly a solo project.
Not that it's impossible to do hard work collaboratively but I think a lot of heavy thinking is solo (Einstein, Newton e.g.) and it's hard to keep other people synchronized.
Most of us work in decade+ legacy code made from a lot of people who are no longer at the company. So most of the code is brittle by default. That's simply the trend that emerged from a workforce that stopped incetivizing retention.
As such, I'd argue that 80+% of your problem solving for the first few years (AKA the only years before you hop or get laid off) is in fact asking other people what the quirks of the code-base are. Maybe that is bad, but it doesn't seem like the retention culture is shifting anytime soon.
When you look at damage per second graphs and conclude that all your healers need to be kicked from the raid.
It’s so difficult to quantify the value of “support” but they’re indispensable. I have yet to really find a sensible way to quantify it. It’s ultimately just something that you need to trust leaders to get right.
Some things that don’t measure whether a developer is “good”:
- # LoC added, changed, removed
- number of points earned in a sprint, when those points aren’t quantitatively indicative of business value, and they never are
- number of on or off-the-clock hours schmoozing with others to solidify relationships with the business and “play the game”
- number of times they “sound like good developers / intelligent people” in meetings or presentations
- number of weeks they spent on really complex problems they worked to solve when they could have provided more incremental value earlier much more quickly
- number of solutions they provided the company quickly while leaving many times more LoC to maintain
- number of hours they spent honing code, formatting, updating to the latest versions but doing so for their own edification and preferences rather than focusing on the team and the business and what would help them
> Some things that don’t measure whether a developer is “good”:
> # LoC added, changed, removed
Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code. High quality, performant code.
And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python.
"Oh, but khazhoux, those 100 lines were really very complex!" No, not actually.
"But won't people just pad their code with comments to increase their LOC?" 1) I've never seen anyone bother, 2) I'm not saying "managers should count LOC"... I'm saying managers should look to see how much code each developer is actually committing to the codebase. If someone isn't committing much code, but talks like they're writing a lot of code, then you may have a problem.
Honestly, somewhere along the way people seem to forget that software is made from code.
I would never suggest a manager stack-rank their team by LOC, but the notion that the code people write means nothing, is preposterous.
You can make massive LoC changes by reformatting everything or just adding superfluous code or changes.
You can rip out a lot of code rewriting it to simplify and then losing a ton of business functionality that was used, or causing the need for a lot of business changes in process that might not be for the business’s benefit.
You can, on your own or with AI, write many LoC, and maybe it provides business value, which seems to align with being a “good developer”, but someone has to maintain those LoC, so then you have to weigh the business value to the end user and the team. Is it ok to the team to have all the extra LoC to maintain? How often will those changes eventually result in valid further changes to get that code to work? Will other devs just rewrite it and are their changes good?
So in the end, no, LoC added/changed/removed is not a good indicator of added overall business value when weighing both the business value to the user and the ongoing maintenance time that ensues, even though “good developers” along with “average developers” and even “bad developers” may have high LoC added/changed/removed counts.
During what some come to think as their peak years, they still don’t think of things this way. But as we get older and more experienced, we realize that sometimes new or old crappy code is ok, sometimes we should do a better job if it makes sense for the business and team, that many can contribute in their own way if those are the people and resources we have, things may change, and overall there is a limited amount that humans can do.
If you base performance on LoC and alter the team accordingly, you may lose great developers. You may also introduce volatility and risk later having a codebase that is higher cost to the business.
But embracing change and working fast and loose may also be important, so it depends.
The title should be: Why measuring developer productivity by story points is bad.
I was once part of a team that had a zero-storypoints developer too, let's call him Zero. He always refused to get any stories assigned during planning, his goal was always zero. He felt responsible for delivering all the planned stories and helped the people who struggled. He often came to me and told me to help someone on a specific task, because it was too much for him to help everyone.
This was well understood by management though. Zero took a 4-6 week vacation every year, and management always pushed important releases back if Zero was not there. The team could've done it without him, and it might've been better for the team not to have Zero around for all important releases. But management was scared something could go terribly wrong without him.
When I hear stories about Tim or Zero, it makes sense... with the caveat of whether they are actually transferring knowledge to teammates, and whether the other team members are capable of taking over the function of Tim/Zero. If not, then Zero is just covering for low performers, and your bus factor is still a liability.
In Zero's case, it sounds more like there is knowledge transfer but there's this cult of personality from management's perspective. Almost the opposite of Tim.
It can be scary, but you gotta pass the torch at some point and accept there will be turbulence compared to Zero smoothing out the landing. That's how you get future Zeros/Tims who very likely had their own turbulence to handle.
I've had some thoughts on programming practice somewhat related to Tim's role, and some on language design this morning.
I write code for others to read a lot, to explicitly teach them how to do something. This code has always been overly verbose, "decompressed" and teaches people the thought process behind a solution above being a "neat" solution. I was dragged a little reluctantly into this style, by being forced to anticipate all the ways the code may be misunderstood ahead of time -- by all the ways it was misunderstood previously. Its much less work for me to be verbose up-front, than fix misunderstandings later.
After watching and looking at some of the best systems programming code/coders -- I've come to think this is just the best way to program in general.
The latest program I wrote this way, and the quality of code is vastly higher. No abbreviations, any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.) I noted briefly in comments to highlight it's unexpected. Any functions which are domain/app-specific have execessively long names which fully describe that step/asepct of the solution. Extensive design comments where my thinking is noted. etc.
Programs which teach their readers how to think about the solution, rather than how to understand the code -- and teach it to a "smart junior" rather than to an expert. I think this is different than literate programming, and of the maxim "code is read more than written" -- it's a specific "educational ethic": code isnt clean, or literate, or readable -- its educational.
If this is the best way for "programming in the large", then a property of programming languages follows: languages which enable the programmer to "decompress" their thoughts over many lines are preferable to ones which hinder this. This I think then explains something about the uptake of functional languages -- which resist this decompression of thoughts over lines of code. They are often sold on their conciseness -- as if a 200 line C++ ought be reduced to a 10 line F# program. This trades the wrong sort of productivity: long-lived large programs require programmers to build mental models of them far more often than they require them to add to them at-scale. A programmer self-teaches the code base more often than they write it: this isnt about reading.
This goes somewhat to the role of Tim in OP. Perhaps the right software engineering programming practice is to write code as-if you are pairing with a new programmer in the future. To verbalise everything Tim would say, already, in the code.
There are different types of managers. I'd use the term technical lead for tim. Someone needs to maneage product delivery. Someone needs to manage the backlog. Someone needs to manage the training of everyone. Someone needs to ensure people are getting setup for their next job. Someone needs to ensure everyone is paid right. Someone needs to handle it when two people don't get along. The above is a small subset of the full list - I don't know everything on the full list.
Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution.
That's not a management activity - that's the kind of coaching you would expect from a senior IC ("Individual Contributor" - I still hate that term.)
Generally I would expect a "manager" to have authority over other people in the company: run performance reviews, handle promotions and hiring and firing.
I think it's important for companies to provide a career structure that allows for influence, decision making and leadership roles that don't also require taking on those management tasks. Management tasks are extremely time consuming and require a substantially different set of skills from being a great team coach or force multiplier like Tim in the story.
I can't quite tell what the manager in this story should have been doing though. Where is their value add? If its just MBA fluff playing psycho games with metrics then I'd argue they can get fucked.
Clearly performing another under appreciated task: to act as a buffer for Tim, allowing the team to flourish even when they don’t adhere to company policy. And all other managerial stuff apart from coaching.
Honest Question: Are there any metrics around developer productivity that actually work? Reading stories like this and others over the years I've come to the conclusion that you simply can't measure developers productivity on a granular level, it's just about the final product. However, I would love to be proven wrong.
I don't think there are realistically any good "individual" productivity measures that work across a broad spectrum of employees, even when all of those employees are in the same role. Every team I've ever been a part of, even before being a developer has been made up of people that all contributed to the overall project in different ways. Imagine trying to measure all workers on a car assembly line by the number of screws they insert per day, or the number of welds they make per day. Anyone who's primary job on the line isn't inserting screws or making spot welds is instantly a low performer by this metric, and yet you can't assemble a complete car with only screws and welds. And it's worse I think in something like software development, where the specific way a team member contributes might be more nebulous. Very rarely do you hire someone just for their code review skills or the design capabilities. The team member that somehow always manages to recall the tiniest of details about the system that no-one else recalls from the feature work done 5 years ago is not exactly a skill you can find on a resume or even one you could build a good metric for even if you had hand tailored metrics for all employees.
And it's a hard problem to solve. I don't envy the job of anyone in management trying to figure out how to determine who (if any) of your employees is a drag on the team. Sometimes it's obvious and there are concrete problems, but other times it's just someone "everyone knows" is a drag, but without hard metrics, you're left with awful things like having employees stack rank each other.
It's prone to its own biases, but I always figured the best metric was simply to ask how others on the team (or coworkers you need to work with) think of you. Your lead obviously has a bigger sway on this, but overall the idea is that you're generally doing a good job if the people around you overall see you as productive and feel more productive when working with you.
I can only really see an exception for some gnarly Principal who's off deep into some very specific problem where this evaluation would fall apart. But such an individual problably isn't one you're worried about productivity with.
See https://en.wikipedia.org/wiki/Goodhart's_law - _in general_ once you start using metrics to reward and punish people, that will break down. It’s by no means limited to software engineering.
> You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates.
I'm very glad this essay turned out to take this position, because when I read the first couple paragraphs, I was ramping up to write a mean internet comment about how stupid measuring developer productivity through story points is.
A friend of mine is exactly like this Tim guy he talks abou: he spends time helping other people fix their problems, or takes extra time doing things the right way. His personal velocity suffers, but the team and the code base is greatly improved on net. He was put on a Performance Improvement Plan at one company, and told his job was at stake at another as a result. No question it's kept him at a Senior level when he should be higher at this point in his career. I sort of take it personally, because I worked with him at the company that gave him the PIP, and both he and I quit as a result.
When I see companies trying to measure developer productivity (and tying it to employment and advancement) I think about Seeing Like a State by James Scott, and the concept of legibility: imposing by force a set of rules on a complex, messy system to make it easier to steer from some office far away. Makes it very convenient to managers, and often leads to disaster.
It never occurred to me that a rebuttal to "not using lines of code or bugs solved because it can be gamed" is just to point out productivity is literally always gamed
These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community.
We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints.
We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem. We’re too good for that. Another engineer chimes in: “I don’t test my candidates. The best people I worked with were hired over a beer and a chat at the local pub”
We’re told of the MBAs who destroy the organisation, by introducing evil metrics, and how that the work we do are immeasurable and that the PHBs don’t understand how great we are. 10x engineers aren’t a real thing, everyone is equally productive in our digital utopia.
Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.
Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.
Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.
To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.
> We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories
> Meanwhile in the real world, hordes of awful engineers deliver no story points
Do you think the point here is that not delivering on one specific metric is a good thing, or that not delivering one specific metric can't be assumed to be the whole picture?
It’s the latter, but my point is that’s a tired and weak argument to make.
The blog poster could’ve asked, why does the manager want me to deliver the story points? It’s because Jake is also delivering zero story points and he’s a terrible engineer and it’s a good canary metric.
Agree in 1st and 2nd “meanwhile”. On the metrics thing though I have the opposite experience - mild distraction at best, total disaster and productivity killer at worst. Most orgs couldn’t even implement metrics fully (or at all) because in reality it is always much more work than they usually anticipate. Instead they larp as google and waste your god damn time.
Having said that i do think that there are a bunch of senior folks who think they are Tim but meanwhile they’re just hiding their laziness/incompetence by getting involved in other people’s shit
People of a revolutionary (or "innovative") temperament are those who are going to say, "this system doesnt work, these processes are broken, the wrong outcomes arise" and ignore them. In doing so they just "do the right thing" in their judgement, and in so doing, develop the next iteration on the processes that others will follow.
If these innovators are operating in a niche where innovation is required, they are solving different problems than most others and have different self-defined standards ("narcissism"), and so on.
Probably many people who visit HN have this temperament, and a significant number are in niches which need to evolve this way (eg., this applies to all startups). HN is a small sample of engineers: most don't go to websites to conceptualise their own activity, reflect, etc. These are indications of people with a desire to innovate, or to solve novel problems in their profession.
If you are in a highly stable environment, with effective processes, etc. then people of this temperament can be trouble if left entirely to their own devices: good managmenet would place them in projects/areas where there is some unknown unknowns to figure out.
In many cases however, people without this temperament (say, "it works, dont break it, conservatives") find this behaviour unsettling, arrogant, disruptive, isolating -- because it is. There isn't any thing to "communicate" when you havent figured out what the solution is -- you can air your thought process every day, but that will just unsettle more people when they see how much it changes (in response to more thkning, information, etc.). And the values by which this change takes place are not conservative, they're radical and imposed by a person who sees a route out of a predicament and so on. It's quite arrogant to place yourself in that position, or think it's yours by some invisible duty that no one else has.
In any case, if you operate in this niche, esp. eg., if you're in a start up environment -- then you arent going to care a jot about this "real world". They are acting against the real world, to improve it.
Thanks for responding. I see your point, but I think it is responding to something slightly different than the point I was making.
If I may latch on to your first paragraph, my point is that we are saying this first bit “this system is broken” and are happy to throw out the baby with the bath water and tear it all apart, on flimsy evidence and generalisations.
And yes, there’s definitely something to be said about the HN crowd having a temperament toward innovation, but I don’t think that’s in any way orthogonal to my point. In fact, this community is far more rational than most others, so I would sort of expect us to rationally look at company processes too, but for some reason we seem to have a blind spot when it comes to our managers and executives and the ‘horrors and hoops’ they make us jump through every day.
>> To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.
Exactly.
Looks to me like Tim was really good at hiding his incompetence behind other people's backs. Also looks like a problem of the others, particularly senior others of not telling him "Fuck off, Timmy" when he sat uninvited beside them to "pair program" together.
So on one hand, you're kinda right. HN is filled with exaggeration (imo often justified) from people venting because they have to deal with the bad parts of this system all day. That seems natural in a dev filled space.
But I don't think your comment is fair.
> We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem.
Because this is a bad way to judge engineers. Or, rather, it's a great way if they don't know how to invert a binary tree. Most of the job is to figure out something you don't know yet and do it. Giving an engineer a random wikipedia page on an obscure algorithm and having them implement it is a great interview tactic. Having them regurgitate something common is bad, there will be a function for it somewhere, and you just need to call it.
> Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.
I agree with you on this one. Those people need to be fired. That doesn't mean story points are a good metric, often 90% of long term value can come from the kind of people who are like Tim, and losing them can destroy projects. Just because something bad is happening, it doesn't justify killing 90% of value for a team.
The only thing I've seen that works is to give team managers more discretion and rigorously fire managers who regularly create poor preforming teams (you often have to bump manager pay for this, that's fine, good managers are worth their weight in gold).
> Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.
You do need to filter for people that can code. That doesn't mean filtering for inverting binary trees is a good idea. Having people submit code samples that they're proud of is a much better approach for a first filter.
> Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.
Bullshit. Basically all companies use metrics, and most companies are garbage at delivering useful software. A company being years behind and a million over budget on a software project, and eventually delivering something people don't want is so cliche that it's expected. And these companies regularly get out competed by small teams using 1% of the resources, as long as the small teams give half of a shit. In fact, if you want my metric for team success, what percentage of the team actually cares is a good one.
You're proposing a solution with a <20% success rate. Don't act like it's a gold standard that drives business value to new heights. With the system as it is today, most companies would be better off getting out of software and having a third party do it for them.
My wider point is not that the way companies are run is perfect and that we should stop the “innovators” (to quote the sibling comment). Each of these examples speak of corporate dysfunction, but we never give any weight to the constraints that force them in place. Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives - the cheaper of the two errors. The alternative is worse.
Giving Tim the benefit of the doubt in this story, it still holds true that for every extraordinary and invisible superstar like Tim there are 99 under-performers who are indistinguishable from him.
We need to empathise with our managers and the processes in our organisations to understand their purpose and how they came to be.
We, software engineers, keep picking out singular data points of evidence to point at a flawed and unfair world, that go against our self inflated egos.
The brew guy inverting the binary tree and Tim being great, does not invalidate the practices of whiteboards and story points as a general practice.
To your final point, the best organisations that I’ve worked with used metrics in a very effective way (mostly in start ups). The worst did too. Just because some do it poorly, does not mean that it’s bad across the board.
What is tiring, is the unfair, and low expectation of the quality of evidence demanded of the anti-establishment notions in software development, before they are taken as gospel by this community.
And, in my experience, the people who are the strongest proponents of sidestepping or dismantling these processes overlap strongly with those who also do not deliver value to their teams.
There are a couple important things to also keep in mind:
First: just like there can be individuals who lift up an entire team but are not ticking off tasks themselves, there can be apparently individually productive team members who slow the entire team down for any of a number of reasons. In my experience it's usually either that they are a) fast but terrible, b) have really weird coding styles that might not be bad but are very difficult for others to work with (architecture astronauts and people who barely speak the language often fall here), or c) are process bullies who try to set up the entire review system to enforce their preferences in a hardline way that suits them but delays everyone but them. Each needs to be dealt with very differently, to varying degrees of success, but my honest opinion at this stage is that no matter how productive these people seem by themselves it's mostly harmful to have them on a team. Behavioral issues in senior people tend to be really tough to adjust, and take a lot of energy from a manager that is better spent helping your top performers excel; that said, if you can get them to adjust sometimes it's worth the effort.
Second: pair programming works great for some people, but it is terrible for others. I've measured this on teams by trial and error over fairly long periods, and unfortunately it's also the case that people don't segment neatly based on their preferences, so the obvious "let them choose" method isn't ideal. There are pairs of people who really love pair programming and desperately want to do it all the time who are almost fully 2x as productive when split apart instead (yes, including downstream bugs and follow-ons, meaning that they really are just having two people do the job of one), and there are people who hate pairing who see similar multiples by being forced into it even though they hate it. My rough intuition is that there are two independent variables here, a social factor that measures how much you enjoy pairing, and a style factor that determines how much benefit you derive from it, with the two not correlating much at all. There might even be a slight anticorrelation, because the more social people who love it have already naturally done as much knowledge sharing as is helpful, and the people who hate it are underinvested there and could use some more focus on the fact that they're part of a team.
There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.
There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.
> There’s... folks that pair because they’re a crutch for one or two other engineers [who] never improve.
I can imagine this happening if neither pair is all that good a communicator, and if the seniormost never employs a little Socratic dialog every now and then.
Agile methods are often applied wrong and then are a disservice. There is no one-size-fits-all method to manage people and teams. Leadership naturally buys into those method as they are promised an easier life, but there is no shortcut to management and leadership. It's always situational.
At my (very large) company Scrum and SAFe is applied to all kind of projects. Even to manage organisations with highly heterogeneous responsibilities and workloads. Think of 2 people doing dev, 2 conceptional work for various larger projects, 3 are basically consultants for other orgs, 4 are data analysts and 1 is doing some spreadsheet work all day long. Now our manager had the great idea to manage us with Scrum.
There are 4 methods of determining developer quality: Empirical metrics which can be misleading, or gammed. Team consensus which can devolve into a popularity contest. Manager "impression" which can be manipulated with strong people skills and "impression management", or letting an AI algorithm decide who is the most productive. No evaluation system is perfect and most are very flawed which is why management is both an art and a science and those that can do it well are very rare and in very high demand and therefore often deserve the compensation they receive.
I love a good pairing ladder. While there is no absolute good measure of productivity, a suite of thoughts observation can provide at least tripwires.
One major problem with tools that ask crafters to do data entry to show their value is that best people are most likely to refuse. You really need to focus on tooling to help capture what’s going on without toil.
For example, if your folks are remote and they use software to aid in pairing (eg Tuple), script the system to log the tuple sessions and perhaps even capture the pairing in the commits made together.
This can be used as an input to bring visible to be best leaders in your org.
Hm. In the agile world, non-coders don't typically sign up for stories. So maybe this person shouldn't have been expected to land stories, or possibly there wasn't room in the budget for someone to be just a peer coder. I personally like the story paradigm as a way of working out (and then sticking to) priorities, and I love it when managers and principals work on stories like everyone else. Also, in the remote work context, everyone has to work harder on figuring out the right thing to work on, and stories are a decent way to achieve that.
I was let go from a position in a similar situation... I was pressed to enter Jira tickets and get them over the line. Didn't matter I was working with my team, acting as an SMA with two other teams, participating in planning meetings 20+ hours a week. I wasn't getting enough points in Jira across the line and had to go.
Aside: I wasn't actually fired, when I went under "review" status, whatever it was called, I lined up another job and left.
In my company I would have told him to start doing some work and getting stories delivered or he's gone. Yes, he's being useful in assisting others but I can easily find someone who can do that and their own work at the same time. He doesnt need to be sat there with others the whole time. What is likely going on there is Tim is playing his boss, playing up his pairing role and its benefits in order to sit being idle watching others work while providing commentary.
I get the point that they are trying to make, but Tim should try to find a way to ship things. It sounds like he could ship a lot and make the codebase better for everyone if he did.
So there wasn't a way to capture the fact that Tim was helping with so many JIRA stories in a way that makes Tim's work more visible? Like maybe pair programming stories that Tim owns and moves on the board (assuming Tim's time is best used in a mentorship capacity)?
It kind of rubs me the wrong way that Tim can just fly under the radar and do whatever he wants without any paper trail or accountability while the rest of the team has to clearly convey what they are working on
You can put subtasks under stories, and Tim can have his own subtask that represents his contribution. You can also (with an extension) put time against subtasks if leadership/management want to get really pedantic. Each team member should have at least 1 assigned story/task/bug in each sprint, and Tim should have at least x hours logged against subtasks off stories in the sprint.
Or you can, you know, trust your team to deliver the stories they said they could do in a time window, as a whole. Let them figure out the how at the team level.
How did the manager not know Tim didn't have tickets slated for him ? How did Tim not even pick up some (at a lower capacity) and then still helped with the remaining time ?
I guess as someone who does a lot of the same that Tim is doing,and I bet others can resonate, I still "have to" pick up tickets and I think that's always the expectation in any job I've had as an IC. Is Tim managing his time well ?
Tim would do well in these times of LLMs. They can write code faster than anybody but also need more guiding and coaching than anybody. They don't learn anything no matter how much we call it machine learning. These days what we most need is a Tim of Tims - somebody who coaches software engineers into becoming Tim.
I would guess at least 80% of the people who look like this Tim are contributing zero if not negative. I think there are good odds the actual Tim in the story was too. I mean I'd certainly love to do just the fun part of my job and duck out of all the scut work, if I could find a team that let me.
I've never worked on a team where story points aren't translated into time. I've found story points to be a completely useless level of indirection. Genuine question, has anyone here ever found them useful?
The worst programmer I know literally could not go a day without either checking in code that did not compile or saying something creepy and sexual in a large open plan office, and we all worked together to get them fired.
I like casually hanging around and telling people what they can do better. This usually results in me seeming unlikable, since I am so often pointing out mistakes.
> This usually results in me seeming unlikable, since I am so often pointing out mistakes.
"comms diff" as the kids say. Communicating is a skill, it is possible to get better at it and help people in a way that they enjoy your presence as well.
This just seems like you performed a social engineering attack on your boss to keep someone on the team who was objectively performing poorly but happened to be doing something that is valued in western culture.
In short you replaced one well defined metric with an adhoc one following your bias.
You are a peon. For all you know your local improvement has a negative effect on the whole company. Listen to your boss and let the company fail fast if it has an unfit system.
This is an awfully bad reply. The person described in the essay is basically an L6 and an L5 moving to L6 at AWS. Our L6s don't write code, they build PoCs, work on designs, estimates, and scale through others. They use their experience and knowledge to scale out, and the L5s and L4s do the work.
Every metric bas unintended side effects. Sure capitalists tend to think the greatest stuff happens from competition, but for real competition you need redundancy -and pay multiple people for writing functionally the same code.
Competition within teams selects for the people who invest most time into looking as if they produced worked punishes those who are good team players.
On top of that, how do you compare a guy who produces 100k lines of unmaintainable boilerplate code versus a guy who in the same timeframe hunts down a particularly nasty and hard to fix race condition and changed 1 line in the end? Any programmer knows the latter is much more exhausting and provides lasting value, while the former might actively hurt the project down the line.
If you manage software development either you trust your team or you have to understand the program yourself and micromanage them. Best would be to trust and understand the program and only inject yourself when it is really needed.
I worked at a company with very similar performance metrics and it was as counter-productive as you would expect. The surprising thing is that the management wasn't that bad overall but they worshiped at the altar of data and metrics for everything. That works great for some things, but not everything.
The Jira-focused performance metrics led to a lot of short term work and fixes since everyone was heavily incentivized to get the immediate task done as quickly as possible without much long term thinking. This created an increasingly large amount of tech debt and caused some real messes. But hey, we could loudly proclaim our love of iterative innovation and data driven decision making processes!
I suppose one benefit was that it became pretty easy to get a stellar performance review since it was completely based on a few metrics that could be managed.
I think a lot of this idiotic thinking about measuring productivity through "stories" is to pin on the "Agile" industry overselling their low value "methodologies" to the MBA-type managers, which are now unfortunately just about everywhere. Hence you have some clueless person deciding who has to go, based on how many tickets get moved on the board. As Joel Spolsky once said, no software company can succeed unless a programmer is at the helm.
I mean, I've worked on some companies where management would've seen what Tim was actually doing and nonetheless reply with "We're not paying him to hang out with other developers, we pay him to sit at his desk and code!"
Vox Jira, Vox Dei. Make sure you're not working in a company with such kindergarden-like approach at managing people before attempting anything like that.
I had a sort of similar situation. I was one of two senior developers at a company making utility software for Windows and Mac in the late '90s and early 2000's. The other senior developer was the owner and CEO of the company and had to spend most of his time doing owner/CEO things so was only able to spend maybe one day a week developing.
The way we organized most of our Windows programs is that I'd write a non-GUI core that implemented all the underlying system level stuff we needed, and then the junior developers would write a nice Windows GUI that used that core. If the product needed anything like a VxD, a filesystem hook, an LSP, or any other Windows kernel extension I'd write that too.
We were profitable and there would be profit sharing bonuses quarterly (I think...might have been monthly but that doesn't significantly change what follows). The owner was always tinkering with how to decide how much profit sharing each person got.
One scheme, which he was sure was going to be great, was to take the total amount available for profit sharing for a quarter and divide that by the number of employees. Call that amount "1 share". So if there were N employees there were N shares available.
He wanted those shares to be allocated so that 25% of the employees got 2 shares, 50% got 1 share, and 25% got 0 shares. Who is in what group would be determined by a company wide vote.
Ballots were distributed that listed all N employees in alphabetical order, and we were told to write a 2 next to N/4 names, a 1 next to N/2 names, and write a zero next to the remaining N/2 names.
For each person their numbers from all the ballots were totaled, and the 1/4 with the highest totals got 2 shares, the 1/4 with the lowest totals got 0 shares, and everyone else got 1 share.
In addition, the people with the 8 highest votes would be put on a committee that would advise the owner on the direction of the company.
The owner's expectation when he launched this was that I would be the top vote getter nearly every time, and would always be in the top 8 so be on the committee of 8 which he was planning for me to run.
I ended up not being in the the top 8. I wasn't even in the top 25%. I don't remember for sure, but it was either somewhere in the bottom half of the 1 share group or it was in the 0 share group.
The reason was simple. Although I wrote the core functionality of all our products my role was not really visible to people other than other developers. It was the junior developers who wrote the GUIs. It was the junior developers who did most of the interaction with the testers. When a test found a bug they'd report it to the junior developer who was, to the testers, the face of the project. If the bug turned out to be in code the junior developer would let me know.
So every developer put me down for 2 on their ballot, but to everyone else I was just some guy in development doing some unknown work so I didn't get many votes from anyone else.
At least the owner immediately recognized that this profit sharing scheme was flawed and dropped it. Since he reacted so quickly I didn't gloat too much over the fact that this was exactly what I told him was going to happen when he first proposed this scheme.
(Some gloating was necessary because the owner and I had been best friends since we met in college about 15 years earlier, and the obligation to rip on your best friend when they do something stupid after you told them it would not work is stronger than the rule that you shouldn't tell your boss "I told you so!").
The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables.
Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The value of them saving that work from knowing another way is high but hard to measure.
What you want is measuring business outcomes but those are hard to attribute to a particular developer.
I think unfortunately we're left with our subjective judgement here. I think we'd do better admitting to ourselves that we can't measure this than to pretend we have some sort of science here.
I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code.
One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem was that this intern was bad, so we had him write unit tests. However, he was also bad at writing unit tests. He would run the code and then write tests that enforced the current results, instead of considering that the current behaviour might be incorrect. Thankfully we didn't hire him after myself and others explained why the intern had so many commits and lines of code written.
Reminds me of an old joke about a policeman who pulls over a poor driver. The driver complain "But I haven't been in a single accident", the reply from the policeman, "Yes, but you've caused dozens".
Some people are just oblivious to the trail of destruction left in their wake.
7 replies →
Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance).
Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of being skipped for promotions and left the company, creating a minor staffing crisis
10 replies →
> who was writing the most code
There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.
19 replies →
https://yosefk.com/blog/engineers-vs-managers-economics-vs-b...
> ...It's a common story and an interesting angle, but the "best vs good enough" formulation misses something. It sounds as if there's a road towards "the best" – towards the 100%. Engineers want to keep going until they actually reach 100%. And managers force them to quit at 70%:
> > There comes a time in the life of every project where the right thing to do is shoot the engineers and ship the fucker.
> However, frequently the road towards "the best" looks completely different from the road to "the good enough" from the very beginning. The different goals of engineers and managers make their thinking work in different directions. A simple example will illustrate this difference.
> Suppose there's a bunch of computers where people can run stuff. Some system is needed to decide who runs what, when and where. What to do?
> * An engineer will want to keep as many computers occupied at every moment as possible – otherwise they're wasted.
> * A manager will want to give each team as few computers as absolutely necessary – otherwise they're wasted.
> These directions aren't just opposite – "as many as possible" vs "as few as necessary". They focus on different things. The engineer imagines idle machines longing for work, and he wants to feed them with tasks. The manager thinks of irate users longing for machines, and he wants to feed them with enough machines to be quiet. Their definitions of "success" are barely related, as are their definitions of "waste".
> The "good enough" is not 70% of "the best" – it's not even in the same direction. In fact, it's more like -20%: once the "good enough" solution is deployed, the road towards "the best" gets harder. You restrict access to machines, and you get people used to the ssh session interface, which "the best" solution will not provide.
Probably not the point but committing every day is one methodology for TBD and it’s great for generating productivity. Not so much useful for measuring productivity though.
I can’t imagine how miserable it would be to try to measure dev productivity by quantifying commits on a daily basis. What a waste.
1 reply →
This story tracks pretty closely with the Dilbert cartoon in the article. Except unintentionally.
> The problem was that this intern was bad, so we had him write unit tests.
Please tell me you assigned this person a "increase code coverage" task and not "I wrote a new feature, write the unit tests for it" task
1 reply →
Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure.
That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.
> at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits.
This works for Junior through Senior level roles, but it falls apart quickly when you have Staff+ roles in your company. Engineers in those roles still code, but they write a fraction of what they used to and that is by design—you want these people engineering entire initiatives, integrations, and migrations. This kind of work is essential and should be done by your top devs, but it will lead to many fewer commits than you get out of people who are working on single features.
With a few exceptions for projects with a high degree of source-level complexity, a Staff+ engineer who's committing as much as your Senior engineers is probably either misleveled or misused.
3 replies →
I've worked on projects where every single ounce of enthusiasm is coming out of one mediocre developer. Nobody pays attention to team dynamics like this, but they're all over the place.
With my minor dabbling in game theory, I've considered funny angles like secret-ish internal metrics and punish those who simply game the incentives. Example: bot detections and banwaves in MMOs. Instead of instantly banning plausible bots, the company has to hide its (ever-changing) internal algo and ban in waves instead.
Basically, treating (non-)productivity like bot detection, lol.
3 replies →
> That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits
Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones who crank out code, albeit maybe as not as much as a senior engineer. Staff engineers who only commit 1 a month are usually the ones who don’t bring value to the company, especially given their high pay.
6 replies →
Thanks to Goodhart's law, it's true for any measure that becomes a target.
> The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure.
Related to Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".
I'm wondering if this is only true if the act of measurement is transparent (so that the people being measured can game them). If the act is opaque enough such that the form of the metric cannot easily be guessed SEO-style, then maybe wave function collapse can still be avoided?
You probably can't do it observationally. You could give several developers the same project, and probably see pretty big differences in timeline and quality. But no one is going to put in the work to run that kind of assessment at scale with the level of realism and time duration (probably several weeks) to make it meaningful.
I like looking at lines removed and, in context with, lines added or PR count. Someone more experienced will be refactoring and removing old stuff while adding new stuff and will have some balance (barring vendoring or moving file trees between repos)
1 reply →
https://en.wikipedia.org/wiki/Goodhart%27s_law says (almost) exactly this.
This is true for more than dev productivity.
[dead]
> What you want is measuring business outcomes but those are hard to attribute to a particular developer.
I think we could solve this by eliminating some middle tiers and putting the developers on the actual customer calls every week. Each senior developer owns at least one customer. That sort of thing.
It's a completely different ball game when you are a developer on some B2B/SaaS and you are answering directly to the customer regarding your work. There's no one to hide behind - your teammates are now aside you and can only render supplemental aid. Once you have developers answering directly to the customers, you have a simple, ~boolean, qualitative metric that virtually any manager/investor can get behind: Is the customer happy?
If the developers are keeping the customers happy, then they are performing. If the customer is unhappy, then there is a performance issue. Whether or not most or all of it can be attributed to blockers on the customer's side is irrelevant at the senior levels of play. Developers should be helping the customers get unblocked. Offer meetings & screen share time. Generally, make yourself as available as possible. If you do this correctly, the customer is likely to take note and provide you with some amount of cover (i.e., not be in a raging fit when they call your CEO).
There is no reality in which you can inject more middle management or process to get developers to take more accountability. The only thing that works is to get them out of the bullshit matrix and in front of the customers. They need to experience how it feels to work directly with a happy customer and then realize how important it is to keep them that way.
This path also happens to solve a whole host of other maladies in technology business, most notably shiny rabbit chases. When you have the fear of god in you regarding the client, you aren't going to be as inclined to play in traffic with a NuSQL engine on their watch.
lol no, I have worked with companies that do that. Many developers have very specific personality types, and they also think in technical terms rather than customer terms. It isn’t a bad thing, it is why they are good at what they do.
The most successful companies I have worked with have a good product manager that can take customer input and work with a technical manager to balance priorities/effort. The technical manager consults the team before making decisions (such as SCRUM meetings if using that)
Issues come into play when folks start distrusting developers. When we say it will take 4 weeks or 8 weeks to implement something, there is a reason for that. We know the code. We know how much of a PITA it is to work with, and we aren’t being misleading. On the flip side, we have been trained to give conservative estimates thanks to crap management and unexpected pitfalls, so we try to understand promise and over deliver. If management could recognize this, everyone would be happy, provided they recognize that 8-week timeline is fine and they don’t promise something different to the client and trust devs to do their thing.
EDIT: Managers also tend to forget that we aren't a machine in a factory. We have good days, bad days, and everything in between. We excel with using our brains, however our brains suffer from anything between lack of sleep, depression, and other nonsense due to just plain having a bad day. I feel like it is more noticeable with us because we rely on our brains so much more than other folks in other professions do. Shoot, even random noise in an office, whether working at home or at an office, can hurt productivity.
Now I have myself missing dev work. Hoping to go back soon. Currently unemployed.
1 reply →
Could a company keep a subjective poor performer on for the lifespan of the company? As in, what is the plus or minus in overall revenue or profit from this charity? What if all companies did that? Could we distribute the "burden" of the charity across all companies for a better society? My point is, I don't even know if metrics are good or bad, we may need to look at why we see each other like this. Is it so offensive to the mind of the captain of a ship that they may have a few of not the best sailors? It's a chance for them to be on a ship, go on a journey. The concept of a "free ride" appears to be a serious moral hazard for us, but I can't figure out why.
Sure, as long as they don't have any responsibilities. I've been a great performer at some companies and a poor performer at others, including one that kept me around without letting me have any responsibilities. It was not good for me. But I have been through worse.
A better alternative I've seen is to help the poor performer hunt for a new job.
This is what Japan does. Employment is presumed to be for life. There are games companies play to get out very poor performers but most people get approximately lifetime employment.
4 replies →
Are you going to accept such free rider in your team? You will eventually do both your and his tasks but for the same or worse pay. Given you have a fixed budget for the team - do you want to split it more ways?
Where can I send a CV?
8 replies →
This reminds me a bit of how VCs bet on a bunch of startups in full knowledge that many will fail. The failures in some sense get a “free ride”. Why not the same with people?
This is why I like working on my own stuff. All that nonsense goes away and I’m left with just the two numbers that matter to me:
- how much money did it bring in this month, and
- how many hours did I have to work to make that happen.
The goal is to make the first number as big as possible while keeping the other as close to zero as possible.
Where I work, the CI pipelines measure changes in code coverage.
If I refactor repetitive code into something more concise and maintainable —- code coverage goes DOWN! (Now the proportion of untested code is larger!)
Yeah, measurement is hard…
the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated
Vibe coding is now a skill requirement for real, actual jobs but, thankfully I guess, no place I want to work (yet). The other day I saw a YC24 company in the "financial services industry" with a "vibe coder position". A prerequisite for the position was at least 50% of your current code being generated by AI; vibe-coding experience was "non-negotiable". Traditional programmers need not apply. And you'd better be ready to grind, 12 hours a day up to 7 days a week. It pays up to $120,000 a year plus squat for equity and relocation to San Francisco is required. That's like, McDonald's money in San Francisco, so guess they figure running a vibe-coding sweatshop is a huge savings for them.
Oh, and the cherry on top? The "financial service" this startup provides? Automated robocalls demanding money from debtors on behalf of debt collectors.
https://www.ycombinator.com/companies/domu-technology-inc/jo...
YC has entered its villain arc.
11 replies →
I've been writing code professionally for a decade but I've never written so much code in my free time because I can just vibe code it all. I wouldn't do it at work and I probably wouldn't trust a juniors vibes as much as my own but no tools have made me feel quite so powerful.
14 replies →
Perhaps give it some time before judging too harshly?
2 replies →
Well said. There’s a noticeable lack of judgement in many places these days; people think they can abdicate it to metrics and data but this is mistaken.
Everyone on a programming team knows who the good and not-so-good programmers are.
Kind of meaningless statement though. Even if they do, which Im not sure is true in general case because you have to be good yourself to know who’s really good, they are not telling you anyway.
12 replies →
This is the key. Ask all the developers for a ranked top-3 list of who they would most prefer to go to for help with a programming problem. Put that data together and you know who your best are.
Before the inevitable protest: I believe the ability and willingness to communicate with other developers is a vital skill in this business.
I don't think productivity itself is absurd but it's definitely a hard thing to do, especially in small time intervals.
I think it's important to measure employee performance and you can definitely can a macro look and say "what have you accomplished in the last year" which might be measured of delivery of "t-shirt" sized projects
I don’t think it’s that we _can’t_ accurately measure developer value/productivity, it’s that doing so isn’t feasible with any methodology we currently have. As you said, we’re not doing magic, therefore our value is measurable. Measuring just requires an impractical degree of time and energy.
but also, the reason we come together to work as groups is so that we can achieve more than we would as the sum of the parts. The same is true for horses, two horses that work well together put out more power than two individual horses. So the problem becomes when you identify one of your horses has 1.5x the output of the other, and think firing the weaker horse will lead to minimal productivity gains, you end up with egg on your face when you realise you are not left with a horse that works 1.5x, but rather a horse now working at 0.5x what what it was in a team. The exact same thing is true for team work, team sports, etc. There is no one person 'holding it all together' if there is, then that person needs way better support and realistically, should get the entire departments pay when the remaining department is let go.
It is absurd to do in a lot of settings. The other day we had a similar story with the measurement of "value" just the other day[0]. I think there's been a big bureaucratic takeover where people are measuring for the sake of measuring rather than recognizing that these things are proxies and you need to be careful to ensure your proxy is properly aligned with the actual thing you want to measure.
You see this in research and academia by trying to measure by number of papers/citations/venue/novelty. You see this in the workforce with things like lines of code, story points, and any of that other bullshit. You see this with how people think about money. Like just think what a million dollars a month would mean what you __*couldn't*__ do wit that money.
The problem is that we've created scoring systems and people see the ultimate goal as maximizing their scores. This doesn't matter if the score is actually meaningful or not, but we'll sure as hell passionately argue that they do. I'll refer to my comment to [0] for more[1].
I've been calling this concept: Goodhart's Hell
The truth is that every system has noise in it. I completely understand wanting to remove all possible noise from the system, but after a certain point, attempts to remove noise are actually ignoring noise. Maybe the problem is that people don't recognize that randomness is itself a measurement of uncertainty. There is no measuring device that is without uncertainty. Embrace the noise. Remove as much as you can, but you need to embrace what is impossible to remove. You create more noise by ignoring the noise.
[0] https://news.ycombinator.com/item?id=43448860
> The idea of measuring individual developer productivity is kind of absurd to me.
that idea is very attractive to every manager on planet earth. they seem to quickly lose their ability to maintain contact with reality and they start using metrics to track everything, rewarding those who game the metrics best.
If you are not committing any code that is a problem. But software development is more than just code. It is also more than just the individual.
It is not absurd. From manager's point of view, when they are deciding to let someone go or promote them, they often need some arguments. And since software is invisible, it is often hard to just say straight away who is over/underperforming and why you think so apart from a "vibe" you are having. Measuring some relevant metrics can strengthen your argument and/or your overview of the situation.
I don't think that the blog makes a compelling argument why measuring productivity is bad per se. It makes a compelling argument that metrics should not be interpreted blindly, but the metrics in this case identified a guy that was doing something unusual, and the managers managed to interpret why this is the case. But if it was an IC that is supposed to deliver, or if you did not want "Tim" to spend his time coaching people, this could still have been valuable info.
I don't think it is absurd to reason about individual contributions, just to focus on measuring them with metrics. I have been on the management side as well though I admit I am much more of an IC. But the way I think that should go is laddering up to business value by describing what the person did and why that contribution was important.
So for example I would say something like: X deserves a promotion because their work was important to delivering project A on time. Project A was difficult but worthwhile because it allowed us as a business to meet goals 1 and 2.
That said I mostly work in smaller orgs. I have never been in a situation where a manager would be so removed from a team they would need a sort of proxy metric to direct them where to focus their attention to understand what the people on their team are doing day to day. I can see how this would get more difficult as a company grows.
Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team against obtuse velocity metrics like this.
productivity metrics aren’t entirely worthless. if I come into a team, for instance, and I see they have 1 PR mapped to roughly every 1 jira ticket, and I see a guy on a 3 person team that’s got 70% of the PR’s in a year, that isn’t a clueless piece of info. he’s probably the lead. not always, and people game stuff like this, but it is a data point you can make note of.
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on.
I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by any metric.
In the end you're building up a system where everyone participating in it knows it's a fraude but just keep gaming it because they become too heavily invested in it.
I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do?
I have a person who I highly suspect isn’t doing much work, and is basically rotating through other team members to help him get unstuck. Not a bad guy, but probably not up to our standards. Just ask people you say? Many cultures don’t allow for someone to say bad things about their coworker even if it would help to improve the team.
I’m not arguing for any one solution because I don’t know of any magical solution. If you have better metrics or management skills than what everyone in the world has figured out, myself and many others would gladly adopt these approaches.
20 replies →
I have managed a team in an organisation that used Jira heavily to measure velocity and having all contributors record time on tickets, even if they were just supporting, did actually help lots:
1. It allows for more accurate estimations (ie this is not a multi-day task but it is a multi-person task)
2. It showed where knowledge transferring was happing
3. It showed that people were busy so that it meant we were making accurate estimates to begin with.
I do think Agile can get overly prescriptive. But if you do happen to work in a company that operates that way, pushing back might be impossible. So having multiple participants record their effort against the same ticket then allows a more organic way for the team to operate despite the rigid structure of a stricter scrum dynamic.
Or in other words: sometimes you cannot change the system entirely so you’re next best option is to tweak it so it at least better works for you. And that’s what the GPs suggest achieves.
While a number measuring productivity may not work, I read the GP as simply recording contributions.
I like that approach. Now you can not only have peer recommendations, but also tangible records.
1 reply →
More like bug/case tracking is crap on this. All the ones I've ever used only support one assignee, so even in equal pair programming you have to choose who officially gets the case.
They're suggesting working around the case tracker, not around the metric.
> This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work
It's just like in physics: "all models are wrong, some are useful". All metrics are wrong, but some are useful when they are correctly applied.
In a company or any business you need to deliver something, if you are being paid X amount of money, the payer needs to know they are getting something in return, and it's not a management problem that they ask what was done this week.
GP is orking off the assumedly common premise of peopel raising complaints of metrics and getting shrugs from management or Product. Who have their own incentives to keep them up.
if you can't throw out the game you may as well adjust the rules.
That's how you get individuals who insist that you attach their name to your ticket (or better yet, do it themselves) after they helpfully inform you about an automated test failure in your commit. "Relentlessly mentoring team members on culture of quality" et cetera.
Exactly. If you don’t consider how people might game the system, you are in trouble. Little fixes like this open other possibilities for gamesmanship and now people fight over whether their contribution was good enough to be included in the ticket.
I mean, all of this is gamable by those who want to minmax. But this is a workplace and those kinds of abuses can be solved with a slap on the wrist 80% of the time.
You're absolutely right, but some people just refuse to play silly games. It's odd that the manager isn't ever in the room with the team and doesn't understand his team's dynamics. Giving the benefit of the doubt, he must have been new, but any manager worth his salt will ask people on their team what the team dynamics are.
My understanding is that metricizing like this is a tangible way for managers to defend "underperforming" team members to upper management. Your manager can always say you're a valuable member of the team and that will certainly go quite a way, but it's even more powerful if your manager can say, XYZ is an I valuable team member, if you need evidence of that, they provide a lot of value in supportive roles like on these tickets. [Listing tickets].
Agree on silly games, but this is simply acknowledging others' contributions. I think this should be encouraged in general, metrics or not
1 reply →
I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.
Not everyone will play the metrics games.
Some people will just find the metrics dumb and depressing, and avoid them. (As might've happened in the article.)
Some assume it will go away in time, or that their manager will cover for them. (As eventually happened in the article.)
Some have behind-the-scenes talks with managers+execs+HR, to end bad metrics.
Some will melt the metrics with the intensity of their look of disapproval. (Management ProTip: this level of will is better harnessed to solve business and engineering problems.)
3 replies →
That's a very personality and culture related phenomenon. A lot of folks will, but also a lot of folks won't.
Pointedly not playing the game when you have the political power to do so is often the most effective way to point out issues in the system that folks are being evaluated under. It can be a very wise move in some cases, as well.
Tim probably realizes that if he tries to get on tickets he’s helped with, he’ll probably end up on maybe 30-50%. If he never asks for credit, and yet is seen constantly working, people will inflate the zero to hallucinatory levels of productivity.
I consider myself a Tim here. My value is not primarily in my individual contributions, but how I eleveate the rest of the team.
If my manager demanded this type of bean counting, I'd just take my talents elsewhere. I'm not interested in that kind of game. I'd take the severance and go find a new team to make better.
Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games
1 reply →
Play the game and any number of management fuckends will prop themselves upon your shoulder. Unless youre into that sort of thing.. no judgment..
Both "trivially" and "fixed" are doing an incredible amount of heavy lifting here.
That doesn't work with automated metrics, whomever is assigned the work item gets all the points.
Tim's problem is that he has a bad manager. One of a manager's core jobs is to communicate upwards the value that each team member is providing (or not providing). His job was to ensure that Tim's contribution were reflected and visible.
According to TFA, that's exactly what the manager did.
In football you track not only the goal scorers but also the assist (the person who passed the ball to he goal scorer). That still does not cover all contributions, but maybe that's a way to create more transparency for Tims case ?
That's an intersting point. I don't recall ever seeing a ticketing system where you could assign a ticket to multiple people.
In one of the systems I worked with each ticket had an "assignee" (who did most of the work), a "tech lead" (who knew what's going on and could provide status and guidance), and an "executive owner" (the person you'd escalate to if needed). I suspect those were custom fields and schema could be extended further if desired.
Ah, the "Quentin Tarantino presents" pattern. Nice.
[dead]
Glad to hear that Tim stayed and author managed to steer the entire process towards the right direction. Which requires a listening manager.
I experienced the "bad ending" of this productivity metric trickle down: OKR. This startup wanted not just team-based 3-month review Objective Key Result but also individual one, and on top of it, tied stock option to OKR. It was a robotics startup so very cross-domain teams (Software, Hardware, Embedded, DevOps, HW design, HW testing, HW maintenance etc etc).
The result? Developers became lonely islands. There were no "Tim" anymore. When I (Software Integrator) encountered an issue, that I just couldn't figure out but had a hunch it must be a deep-rooted issue, went to the expert (control/kinematics) for feedback. The answer I got was "I'm sorry I really want to help you but my OKR deadline is very close, and I simply don't have time". He could've probably fixed it in a day or less, but it ended up taking 2 weeks.
The problem turned out to be quite deep: inside layer upon layer of C++ mega monorepo, I found that boost library and a custom kinematics library had implicit struct copy and the different libraries (more than two) used different order for representing translation & rotation (xyz, rpy, Euler, Quaternion) and all of the ordering of each components were different. Somehow over 2 years of operation nobody got troubled by this until our new team had to use it.
Afaik I reported it to the Software team, but again, because OKR, nothing was done about it.
I think just because this startup botched OKRs they still make a lot of sense.
Intel and Google apparently relied on them heavily in their formative years. But:
- they should be cascading (so conflicting OKRs between departments should not happen)
- you should never, ever tie them to individual performance results/compensation/rewards
My sense was OKRs came later for both Intel and Google. Do you know around what year/size they started?
I worked with some ex-Google person who tried to get us to use OKRs. That totally didn't work. Larger company.
Like many things I don't think they're necessarily a bad idea it's just that good ideas always lose to culture. With the right culture/leadership it's not the process that matters. I.e. OKRs aren't going to fix an organization that isn't aligned and conversely there are infinite other ways to align an organization with the right culture and leadership. So in practice, like other things, it just ends up making things worse because it's never a real fix.
1 reply →
100% this. Want to sacrifice team output? Have team members be concerned about individual goals. Team alignment and synchronization will be off affecting the efficiency and effectiveness of that team's performance.
I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping.
A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.
Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?
Or if you really do have an insanely lopsided team where everyone is straight out of school with no experience, and a single super-senior dev, then... shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?
The post here is not a good example at all of metrics failing to capture work. In reality, it is surfacing the fact that either Tim's job title and metric are totally wrong for him individually, or else that Tim is failing to contribute the hardest code, and the team is failing to distribute the "helping" workload. In both cases, the metric is working as intended, and it is surfacing something very important than needs to be fixed. (Remember, "fire Tim" is not the only possible action you can take because of a metric.)
> when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.
I agree this would be healthy for an organization, but I don’t think that is often possible. In this example, the organization is clearly NOT tracking mentor activity. So, anyone who helps someone else, is getting zero recognition for it.
I work with a lot of people where ‘ruthless prioritization’ is considered a good quality. That means no one gets any help. All taking. No giving. Pure selfishness really.
Back to the example. Tim is stepping up and filling in a major gap for the company. People need help. He has decided to go against the grain and help. However, instead of doing it with the help of leadership, he is just doing what needs to be done and it almost cost him his job.
Frankly, I identify with Tim. I love helping people figure out problems. Be it build env issues, failing tests, or some design gap. I help people all the time on top of my other work. While my immediate manager knows that and is good with it, upper leadership doesn’t care and just wants everyone to act like what they are working on is more important then what their peers are working on. Ruthless prioritizing is a seed of toxicity.
I got a bit off topic… How to encourage helping peers and juniors when helping isn’t tracked and isn’t rewarded or encouraged? How do you maintain a healthy culture despite all the metrics?
> So, anyone who helps someone else, is getting zero recognition for it.
Where I've worked, this is what 360 peer review during performance reviews is.
If your colleagues all say you're super-helpful, that's part of what it takes to get promoted.
If your colleagues all say you're selfish and never help out, this is something that needs to be addressed immediately.
It's a metric like any other, it's just collected twice a year rather than bimonthly, and it's qualitative rather than quantitative. But it's analyzed at the same time and given lots of weight when it comes to promotions.
>this is a bizarre model where one programmer does no individual work and does all the helping.
Sounds like a lead or manager. He definitely works like a lead in spirit. Cheaper for the company to delineate it like this.
>Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?
difficulties don't signify priorities. Maybe all the hard stories are low priority. Maybe the energy is focused on onboarding newer hires. Maybe there was a semi-looming headline and getting others' tasks done was more important than his individual module (or perhaps he was ahead of pace already).
I can see a dozen of scenarios this comes up in organically. I experienced a few of these firsthand.
> shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?
It sounds like this was precisely the situation, and the author's company did indeed take this very action, in response to seeing the data. So, what is your complaint?
No they didn't. They dropped the metrics for everyone entirely, and Tim's job title is unchanged. The article is arguing metrics are bad and shouldn't be used; I'm arguing metrics are a valuable signal and Tim should have been given a different formal role of mentor.
Was Tim hired as a teacher or trainer? What I find strange is that it sounds like Tim was not doing any individual work.
As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approximately 20% of my time pairing with others and 80% on individual contributions. (That's a rough estimate; it could be 25/75 or 30/70.) The article said that Tim was "patient", but perhaps he was too patient, wasting a lot of his time that could be spent accomplishing other things.
I've been the TL for a team of effectively 5 new grads before. Effectively all of my time was spent teaching them how to solve problems, fixing (preventing) bugs in their code from getting committed, and writing boilerplate, or infra code that would never be listed on whatever a story point is. But constrained their responsabilities into a format and structure that would play well with each other's so they would stop constantly rewriting each other's code every other week.
I enjoy teaching so that was a much more enjoyable way for me to spend my day, than drinking caffeine and cranking code the rest of the team couldn't understand. I joined that team because they were constantly missing deadlines. When I left that team they were finally ahead of schedule, but much more importantly they had a code base they all understood. That wouldn't have been true if I'd just written all the code myself. I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself. But true or not, when I left I would have no confidence the team could continue without me.
Could I have spent more time writing code? Probably, but what delivered the most businesses value? I was hired as a glorified software engineer but instead of delivering code, I delivered a team that could produce code. Their manager was *never* gonna do that. So should I have prioritized doing what my job title said? Or doing what's in the best interests of the long term mission? Every situation is gonna be different, if teaching is soul crushing for you, or more importantly, the team refuses to be taught, I would suggest just deliver code. In this case, everyone wanted to learn, so that was the easiest path forward.
> a team of effectively 5 new grads
> they were constantly missing deadlines
Gee, go figure.
> I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself.
> what delivered the most businesses value?
What the company should have done is hire you and one new grad (rather than five), who you could mentor without spending all of your time mentoring, and get the same amount of work done with two people for less money.
10 replies →
> Was Tim hired as a teacher or trainer?
Do you think that's any relevant? Software development engineers in general are hired to work on projects as part of small teams, and their goal is to deliver projects. It's not story points, it's not burn down charts, it's not PRs, it's not LoCs touched. It's how many projects are delivered, and keep everything and everyone problem free. This means that if you are struggling, your team will struggle as well until you unblock yourself. If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
> If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.
15 replies →
Yes, obviously it’s relevant you have a fundamental misunderstanding about what software engineers do. We don’t “build systems” we diffuse risk for the managers. If someone is “helping build something” they can spend their own money doing that. This is business, the less work you do the more money you make.
In a lot of companies the definition of senior engineer helping others develop technical skills.
In a few of those companies, so also is the job.
2 replies →
Very interesting topic and as you say the ratio should very much depend on what his designated role in the team was.
For tech leads, I think the ratio should be heavily skewed towards enabling other team members (by pairing or working on cross-cutting concerns, usually devops/infra). Something like 20/80, where the 20% individual contributions are only the toughest nuts which can't be done in a reasonable timeframe by anyone else.
For senior developers, I'd say it depends on team composition. If there is one senior and 3 juniors, training them should be his primary concern. If there are 5 heavily specialized seniors, I'd say the ratio should lean towards individual contributions.
Yea the best teams I've ever been on have always had someone like Tim.
The best best teams I've been on, Tim's helpfulness osmoses onto other people, and instead of Tim always being the one, the process goes like this:
1. Dev gets stuck
2. Dev attempts to unstick self for appropriate amount of time given problem and probability of self-unsticking given resources (e.g. some stuff is easier to search for internally, or dismantle and go piece by piece)
3. Dev announces "hey I'm blocked on XYZ thing"
4. Whoever knows the most about that topic (not always Tim, but often Tim) puts that as like their highest priority thing, and almost always jumps in right away to help (unless they're like ignoring chat cus they're in the zone)
Works great especially if you do #4 at some break time (like say lunch or standup), and everyone has enough things to work on that they can do their own internal CPU pipelining and work on other stuff until someone has time to help unstick them
Problem on a lot of teams is people skip over #2 in my experience.
Good devs always do #2, bad devs skip it.
That's easy to solve. When they ask me it might take an hour or two until I come back to them. If they were just trying to us me as a rubber duck the problem will have been solved by then. And it's not only devs. Also PMs have this behaviour. Sitting it out before asking what they need makes most question vanish.
Extra points for the ones that sit down at step 4 and lay out all the things they've already tried so the context on the problem is clear
Counterexample: Not everything needs to be a group activity or social. If a developer of average skill can't manage to deliver a feature without the constant help from a "Tim", it says something about your code, processes, team. I've worked at places where they used pairing as a signal the team was working well together, when the reality was the code was so brittle and full of hacks it took the combined help (usually moral support) of a Tim to help support through every little change.
Every team is different, but software development needs the time and space for individual work just as much as group work. A small team who needs a dedicated person for pairing, who also doesn't (or won't) do any IC work, is a huge red flag.
Don't forget about the type of software. Something really specialized or algorithm heavy (science or math heavy) might be harder to do solo than a CRUD app.
My experience is the opposite. Easy stuff is simpler to pair up. Really hard stuff is solo. E.g. I expect Ph.D. work to be mostly a solo project.
Not that it's impossible to do hard work collaboratively but I think a lot of heavy thinking is solo (Einstein, Newton e.g.) and it's hard to keep other people synchronized.
Most of us work in decade+ legacy code made from a lot of people who are no longer at the company. So most of the code is brittle by default. That's simply the trend that emerged from a workforce that stopped incetivizing retention.
As such, I'd argue that 80+% of your problem solving for the first few years (AKA the only years before you hop or get laid off) is in fact asking other people what the quirks of the code-base are. Maybe that is bad, but it doesn't seem like the retention culture is shifting anytime soon.
When you look at damage per second graphs and conclude that all your healers need to be kicked from the raid.
It’s so difficult to quantify the value of “support” but they’re indispensable. I have yet to really find a sensible way to quantify it. It’s ultimately just something that you need to trust leaders to get right.
Some things that don’t measure whether a developer is “good”:
- # LoC added, changed, removed
- number of points earned in a sprint, when those points aren’t quantitatively indicative of business value, and they never are
- number of on or off-the-clock hours schmoozing with others to solidify relationships with the business and “play the game”
- number of times they “sound like good developers / intelligent people” in meetings or presentations
- number of weeks they spent on really complex problems they worked to solve when they could have provided more incremental value earlier much more quickly
- number of solutions they provided the company quickly while leaving many times more LoC to maintain
- number of hours they spent honing code, formatting, updating to the latest versions but doing so for their own edification and preferences rather than focusing on the team and the business and what would help them
and so many more...
> Some things that don’t measure whether a developer is “good”:
> # LoC added, changed, removed
Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code. High quality, performant code.
And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python.
"Oh, but khazhoux, those 100 lines were really very complex!" No, not actually.
"But won't people just pad their code with comments to increase their LOC?" 1) I've never seen anyone bother, 2) I'm not saying "managers should count LOC"... I'm saying managers should look to see how much code each developer is actually committing to the codebase. If someone isn't committing much code, but talks like they're writing a lot of code, then you may have a problem.
Honestly, somewhere along the way people seem to forget that software is made from code.
I would never suggest a manager stack-rank their team by LOC, but the notion that the code people write means nothing, is preposterous.
You can make massive LoC changes by reformatting everything or just adding superfluous code or changes.
You can rip out a lot of code rewriting it to simplify and then losing a ton of business functionality that was used, or causing the need for a lot of business changes in process that might not be for the business’s benefit.
You can, on your own or with AI, write many LoC, and maybe it provides business value, which seems to align with being a “good developer”, but someone has to maintain those LoC, so then you have to weigh the business value to the end user and the team. Is it ok to the team to have all the extra LoC to maintain? How often will those changes eventually result in valid further changes to get that code to work? Will other devs just rewrite it and are their changes good?
So in the end, no, LoC added/changed/removed is not a good indicator of added overall business value when weighing both the business value to the user and the ongoing maintenance time that ensues, even though “good developers” along with “average developers” and even “bad developers” may have high LoC added/changed/removed counts.
During what some come to think as their peak years, they still don’t think of things this way. But as we get older and more experienced, we realize that sometimes new or old crappy code is ok, sometimes we should do a better job if it makes sense for the business and team, that many can contribute in their own way if those are the people and resources we have, things may change, and overall there is a limited amount that humans can do.
If you base performance on LoC and alter the team accordingly, you may lose great developers. You may also introduce volatility and risk later having a codebase that is higher cost to the business.
But embracing change and working fast and loose may also be important, so it depends.
1 reply →
The title should be: Why measuring developer productivity by story points is bad.
I was once part of a team that had a zero-storypoints developer too, let's call him Zero. He always refused to get any stories assigned during planning, his goal was always zero. He felt responsible for delivering all the planned stories and helped the people who struggled. He often came to me and told me to help someone on a specific task, because it was too much for him to help everyone.
This was well understood by management though. Zero took a 4-6 week vacation every year, and management always pushed important releases back if Zero was not there. The team could've done it without him, and it might've been better for the team not to have Zero around for all important releases. But management was scared something could go terribly wrong without him.
Wouldn't Zero be a hero in disguise, then?
When I hear stories about Tim or Zero, it makes sense... with the caveat of whether they are actually transferring knowledge to teammates, and whether the other team members are capable of taking over the function of Tim/Zero. If not, then Zero is just covering for low performers, and your bus factor is still a liability.
In Zero's case, it sounds more like there is knowledge transfer but there's this cult of personality from management's perspective. Almost the opposite of Tim.
It can be scary, but you gotta pass the torch at some point and accept there will be turbulence compared to Zero smoothing out the landing. That's how you get future Zeros/Tims who very likely had their own turbulence to handle.
So the real metric is the manager who knows their team and what each member brings in.
Yes, absolutely — and can effectively communicate that to their manager.
I've had some thoughts on programming practice somewhat related to Tim's role, and some on language design this morning.
I write code for others to read a lot, to explicitly teach them how to do something. This code has always been overly verbose, "decompressed" and teaches people the thought process behind a solution above being a "neat" solution. I was dragged a little reluctantly into this style, by being forced to anticipate all the ways the code may be misunderstood ahead of time -- by all the ways it was misunderstood previously. Its much less work for me to be verbose up-front, than fix misunderstandings later.
After watching and looking at some of the best systems programming code/coders -- I've come to think this is just the best way to program in general.
The latest program I wrote this way, and the quality of code is vastly higher. No abbreviations, any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.) I noted briefly in comments to highlight it's unexpected. Any functions which are domain/app-specific have execessively long names which fully describe that step/asepct of the solution. Extensive design comments where my thinking is noted. etc.
Programs which teach their readers how to think about the solution, rather than how to understand the code -- and teach it to a "smart junior" rather than to an expert. I think this is different than literate programming, and of the maxim "code is read more than written" -- it's a specific "educational ethic": code isnt clean, or literate, or readable -- its educational.
If this is the best way for "programming in the large", then a property of programming languages follows: languages which enable the programmer to "decompress" their thoughts over many lines are preferable to ones which hinder this. This I think then explains something about the uptake of functional languages -- which resist this decompression of thoughts over lines of code. They are often sold on their conciseness -- as if a 200 line C++ ought be reduced to a 10 line F# program. This trades the wrong sort of productivity: long-lived large programs require programmers to build mental models of them far more often than they require them to add to them at-scale. A programmer self-teaches the code base more often than they write it: this isnt about reading.
This goes somewhat to the role of Tim in OP. Perhaps the right software engineering programming practice is to write code as-if you are pairing with a new programmer in the future. To verbalise everything Tim would say, already, in the code.
Interesting, cool insight
> any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.)
Why ever do that kind of stuff though ;__;
Sounds like Tim was the manager. What exactly was the paid for manager doing?
There are different types of managers. I'd use the term technical lead for tim. Someone needs to maneage product delivery. Someone needs to manage the backlog. Someone needs to manage the training of everyone. Someone needs to ensure people are getting setup for their next job. Someone needs to ensure everyone is paid right. Someone needs to handle it when two people don't get along. The above is a small subset of the full list - I don't know everything on the full list.
Not to be a total fucking asshole... but:
> Someone needs to manage product delivery:
You mean the 2-week delivery cycle into an automated CI/CD? Good lord I hope they don't have a useless scrum master too.
> Someone needs to manage the backlog:
I'm curious what input the manager has into this besides reading through a list of engineer curated items.
> Someone needs to manage the training of everyone:
Tim seems to be handling that.
> Someone needs to ensure people are getting setup for their next job:
Tim seems to be handling that.
> Someone needs to ensure everyone is paid right:
HR has but one fuckin job as far as I can tell.
> Someone needs to handle it when two people don't get along:
Hey Tim can you id the asshole? How comfortable are you hiring/firing?
Obviously IME non-technical management has done nothing but played politics and prevented firing of shitheads who were wrongly hired.
7 replies →
Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution.
That's not a management activity - that's the kind of coaching you would expect from a senior IC ("Individual Contributor" - I still hate that term.)
Generally I would expect a "manager" to have authority over other people in the company: run performance reviews, handle promotions and hiring and firing.
I think it's important for companies to provide a career structure that allows for influence, decision making and leadership roles that don't also require taking on those management tasks. Management tasks are extremely time consuming and require a substantially different set of skills from being a great team coach or force multiplier like Tim in the story.
I can't quite tell what the manager in this story should have been doing though. Where is their value add? If its just MBA fluff playing psycho games with metrics then I'd argue they can get fucked.
1 reply →
I would agree, but the manager probably should be in touch enough that they could see the teaming behaviour themselves.
3 replies →
Clearly performing another under appreciated task: to act as a buffer for Tim, allowing the team to flourish even when they don’t adhere to company policy. And all other managerial stuff apart from coaching.
Honest Question: Are there any metrics around developer productivity that actually work? Reading stories like this and others over the years I've come to the conclusion that you simply can't measure developers productivity on a granular level, it's just about the final product. However, I would love to be proven wrong.
I don't think there are realistically any good "individual" productivity measures that work across a broad spectrum of employees, even when all of those employees are in the same role. Every team I've ever been a part of, even before being a developer has been made up of people that all contributed to the overall project in different ways. Imagine trying to measure all workers on a car assembly line by the number of screws they insert per day, or the number of welds they make per day. Anyone who's primary job on the line isn't inserting screws or making spot welds is instantly a low performer by this metric, and yet you can't assemble a complete car with only screws and welds. And it's worse I think in something like software development, where the specific way a team member contributes might be more nebulous. Very rarely do you hire someone just for their code review skills or the design capabilities. The team member that somehow always manages to recall the tiniest of details about the system that no-one else recalls from the feature work done 5 years ago is not exactly a skill you can find on a resume or even one you could build a good metric for even if you had hand tailored metrics for all employees.
And it's a hard problem to solve. I don't envy the job of anyone in management trying to figure out how to determine who (if any) of your employees is a drag on the team. Sometimes it's obvious and there are concrete problems, but other times it's just someone "everyone knows" is a drag, but without hard metrics, you're left with awful things like having employees stack rank each other.
It's prone to its own biases, but I always figured the best metric was simply to ask how others on the team (or coworkers you need to work with) think of you. Your lead obviously has a bigger sway on this, but overall the idea is that you're generally doing a good job if the people around you overall see you as productive and feel more productive when working with you.
I can only really see an exception for some gnarly Principal who's off deep into some very specific problem where this evaluation would fall apart. But such an individual problably isn't one you're worried about productivity with.
See https://en.wikipedia.org/wiki/Goodhart's_law - _in general_ once you start using metrics to reward and punish people, that will break down. It’s by no means limited to software engineering.
Discussion 2 years ago: https://news.ycombinator.com/item?id=37361947
> You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates.
I'm very glad this essay turned out to take this position, because when I read the first couple paragraphs, I was ramping up to write a mean internet comment about how stupid measuring developer productivity through story points is.
A friend of mine is exactly like this Tim guy he talks abou: he spends time helping other people fix their problems, or takes extra time doing things the right way. His personal velocity suffers, but the team and the code base is greatly improved on net. He was put on a Performance Improvement Plan at one company, and told his job was at stake at another as a result. No question it's kept him at a Senior level when he should be higher at this point in his career. I sort of take it personally, because I worked with him at the company that gave him the PIP, and both he and I quit as a result.
When I see companies trying to measure developer productivity (and tying it to employment and advancement) I think about Seeing Like a State by James Scott, and the concept of legibility: imposing by force a set of rules on a complex, messy system to make it easier to steer from some office far away. Makes it very convenient to managers, and often leads to disaster.
It never occurred to me that a rebuttal to "not using lines of code or bugs solved because it can be gamed" is just to point out productivity is literally always gamed
They even have a fancy title, "measurement dysfunction", and a smug "if you know you know" nickname, Goodhart's Law
and Campbells Law, and the CObra effect.
I had not come across "measurement dysfunction" before. Useful phrase.
1 reply →
These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community.
We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints.
We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem. We’re too good for that. Another engineer chimes in: “I don’t test my candidates. The best people I worked with were hired over a beer and a chat at the local pub”
We’re told of the MBAs who destroy the organisation, by introducing evil metrics, and how that the work we do are immeasurable and that the PHBs don’t understand how great we are. 10x engineers aren’t a real thing, everyone is equally productive in our digital utopia.
Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.
Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.
Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.
To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.
> We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories
> Meanwhile in the real world, hordes of awful engineers deliver no story points
Do you think the point here is that not delivering on one specific metric is a good thing, or that not delivering one specific metric can't be assumed to be the whole picture?
It’s the latter, but my point is that’s a tired and weak argument to make.
The blog poster could’ve asked, why does the manager want me to deliver the story points? It’s because Jake is also delivering zero story points and he’s a terrible engineer and it’s a good canary metric.
Agree in 1st and 2nd “meanwhile”. On the metrics thing though I have the opposite experience - mild distraction at best, total disaster and productivity killer at worst. Most orgs couldn’t even implement metrics fully (or at all) because in reality it is always much more work than they usually anticipate. Instead they larp as google and waste your god damn time.
Having said that i do think that there are a bunch of senior folks who think they are Tim but meanwhile they’re just hiding their laziness/incompetence by getting involved in other people’s shit
> We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree.
>Meanwhile in the real world, hordes of awful engineers deliver no story points
These two seem linked; if hiring practices are bad, then you would expect to end up with many bad hired developers.
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
People of a revolutionary (or "innovative") temperament are those who are going to say, "this system doesnt work, these processes are broken, the wrong outcomes arise" and ignore them. In doing so they just "do the right thing" in their judgement, and in so doing, develop the next iteration on the processes that others will follow.
If these innovators are operating in a niche where innovation is required, they are solving different problems than most others and have different self-defined standards ("narcissism"), and so on.
Probably many people who visit HN have this temperament, and a significant number are in niches which need to evolve this way (eg., this applies to all startups). HN is a small sample of engineers: most don't go to websites to conceptualise their own activity, reflect, etc. These are indications of people with a desire to innovate, or to solve novel problems in their profession.
If you are in a highly stable environment, with effective processes, etc. then people of this temperament can be trouble if left entirely to their own devices: good managmenet would place them in projects/areas where there is some unknown unknowns to figure out.
In many cases however, people without this temperament (say, "it works, dont break it, conservatives") find this behaviour unsettling, arrogant, disruptive, isolating -- because it is. There isn't any thing to "communicate" when you havent figured out what the solution is -- you can air your thought process every day, but that will just unsettle more people when they see how much it changes (in response to more thkning, information, etc.). And the values by which this change takes place are not conservative, they're radical and imposed by a person who sees a route out of a predicament and so on. It's quite arrogant to place yourself in that position, or think it's yours by some invisible duty that no one else has.
In any case, if you operate in this niche, esp. eg., if you're in a start up environment -- then you arent going to care a jot about this "real world". They are acting against the real world, to improve it.
Thanks for responding. I see your point, but I think it is responding to something slightly different than the point I was making.
If I may latch on to your first paragraph, my point is that we are saying this first bit “this system is broken” and are happy to throw out the baby with the bath water and tear it all apart, on flimsy evidence and generalisations.
And yes, there’s definitely something to be said about the HN crowd having a temperament toward innovation, but I don’t think that’s in any way orthogonal to my point. In fact, this community is far more rational than most others, so I would sort of expect us to rationally look at company processes too, but for some reason we seem to have a blind spot when it comes to our managers and executives and the ‘horrors and hoops’ they make us jump through every day.
>> To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.
Exactly.
Looks to me like Tim was really good at hiding his incompetence behind other people's backs. Also looks like a problem of the others, particularly senior others of not telling him "Fuck off, Timmy" when he sat uninvited beside them to "pair program" together.
So on one hand, you're kinda right. HN is filled with exaggeration (imo often justified) from people venting because they have to deal with the bad parts of this system all day. That seems natural in a dev filled space.
But I don't think your comment is fair.
> We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem.
Because this is a bad way to judge engineers. Or, rather, it's a great way if they don't know how to invert a binary tree. Most of the job is to figure out something you don't know yet and do it. Giving an engineer a random wikipedia page on an obscure algorithm and having them implement it is a great interview tactic. Having them regurgitate something common is bad, there will be a function for it somewhere, and you just need to call it.
> Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.
I agree with you on this one. Those people need to be fired. That doesn't mean story points are a good metric, often 90% of long term value can come from the kind of people who are like Tim, and losing them can destroy projects. Just because something bad is happening, it doesn't justify killing 90% of value for a team.
The only thing I've seen that works is to give team managers more discretion and rigorously fire managers who regularly create poor preforming teams (you often have to bump manager pay for this, that's fine, good managers are worth their weight in gold).
> Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.
You do need to filter for people that can code. That doesn't mean filtering for inverting binary trees is a good idea. Having people submit code samples that they're proud of is a much better approach for a first filter.
> Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.
Bullshit. Basically all companies use metrics, and most companies are garbage at delivering useful software. A company being years behind and a million over budget on a software project, and eventually delivering something people don't want is so cliche that it's expected. And these companies regularly get out competed by small teams using 1% of the resources, as long as the small teams give half of a shit. In fact, if you want my metric for team success, what percentage of the team actually cares is a good one.
You're proposing a solution with a <20% success rate. Don't act like it's a gold standard that drives business value to new heights. With the system as it is today, most companies would be better off getting out of software and having a third party do it for them.
My wider point is not that the way companies are run is perfect and that we should stop the “innovators” (to quote the sibling comment). Each of these examples speak of corporate dysfunction, but we never give any weight to the constraints that force them in place. Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives - the cheaper of the two errors. The alternative is worse.
Giving Tim the benefit of the doubt in this story, it still holds true that for every extraordinary and invisible superstar like Tim there are 99 under-performers who are indistinguishable from him.
We need to empathise with our managers and the processes in our organisations to understand their purpose and how they came to be.
We, software engineers, keep picking out singular data points of evidence to point at a flawed and unfair world, that go against our self inflated egos.
The brew guy inverting the binary tree and Tim being great, does not invalidate the practices of whiteboards and story points as a general practice.
To your final point, the best organisations that I’ve worked with used metrics in a very effective way (mostly in start ups). The worst did too. Just because some do it poorly, does not mean that it’s bad across the board.
What is tiring, is the unfair, and low expectation of the quality of evidence demanded of the anti-establishment notions in software development, before they are taken as gospel by this community.
And, in my experience, the people who are the strongest proponents of sidestepping or dismantling these processes overlap strongly with those who also do not deliver value to their teams.
5 replies →
There are a couple important things to also keep in mind:
First: just like there can be individuals who lift up an entire team but are not ticking off tasks themselves, there can be apparently individually productive team members who slow the entire team down for any of a number of reasons. In my experience it's usually either that they are a) fast but terrible, b) have really weird coding styles that might not be bad but are very difficult for others to work with (architecture astronauts and people who barely speak the language often fall here), or c) are process bullies who try to set up the entire review system to enforce their preferences in a hardline way that suits them but delays everyone but them. Each needs to be dealt with very differently, to varying degrees of success, but my honest opinion at this stage is that no matter how productive these people seem by themselves it's mostly harmful to have them on a team. Behavioral issues in senior people tend to be really tough to adjust, and take a lot of energy from a manager that is better spent helping your top performers excel; that said, if you can get them to adjust sometimes it's worth the effort.
Second: pair programming works great for some people, but it is terrible for others. I've measured this on teams by trial and error over fairly long periods, and unfortunately it's also the case that people don't segment neatly based on their preferences, so the obvious "let them choose" method isn't ideal. There are pairs of people who really love pair programming and desperately want to do it all the time who are almost fully 2x as productive when split apart instead (yes, including downstream bugs and follow-ons, meaning that they really are just having two people do the job of one), and there are people who hate pairing who see similar multiples by being forced into it even though they hate it. My rough intuition is that there are two independent variables here, a social factor that measures how much you enjoy pairing, and a style factor that determines how much benefit you derive from it, with the two not correlating much at all. There might even be a slight anticorrelation, because the more social people who love it have already naturally done as much knowledge sharing as is helpful, and the people who hate it are underinvested there and could use some more focus on the fact that they're part of a team.
You get what you measure. If your metric is claimed completed story points, you'll get people good at claiming story points.
Every system can and will be gamed, either directly or indirectly through osmosis and attrition.
The only way to win is not to play. Put people in charge that know how the pie is made, then trust them to make the right calls.
This btw is one of the major reasons why non-technical founders/managers so often fail.
Maybe.
There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.
There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.
Pairing makes them feel valuable.
> There’s... folks that pair because they’re a crutch for one or two other engineers [who] never improve.
I can imagine this happening if neither pair is all that good a communicator, and if the seniormost never employs a little Socratic dialog every now and then.
Agile methods are often applied wrong and then are a disservice. There is no one-size-fits-all method to manage people and teams. Leadership naturally buys into those method as they are promised an easier life, but there is no shortcut to management and leadership. It's always situational.
At my (very large) company Scrum and SAFe is applied to all kind of projects. Even to manage organisations with highly heterogeneous responsibilities and workloads. Think of 2 people doing dev, 2 conceptional work for various larger projects, 3 are basically consultants for other orgs, 4 are data analysts and 1 is doing some spreadsheet work all day long. Now our manager had the great idea to manage us with Scrum.
Moral of the story:
Anyone that looks for the metric to find the weakest link, is the weakest one at heart.
There are 4 methods of determining developer quality: Empirical metrics which can be misleading, or gammed. Team consensus which can devolve into a popularity contest. Manager "impression" which can be manipulated with strong people skills and "impression management", or letting an AI algorithm decide who is the most productive. No evaluation system is perfect and most are very flawed which is why management is both an art and a science and those that can do it well are very rare and in very high demand and therefore often deserve the compensation they receive.
> an AI algorithm
In reality this is just some secret combination of the above metrics (assuming there are no "bugs", which there surely are).
I love a good pairing ladder. While there is no absolute good measure of productivity, a suite of thoughts observation can provide at least tripwires.
One major problem with tools that ask crafters to do data entry to show their value is that best people are most likely to refuse. You really need to focus on tooling to help capture what’s going on without toil.
For example, if your folks are remote and they use software to aid in pairing (eg Tuple), script the system to log the tuple sessions and perhaps even capture the pairing in the commits made together.
This can be used as an input to bring visible to be best leaders in your org.
Hm. In the agile world, non-coders don't typically sign up for stories. So maybe this person shouldn't have been expected to land stories, or possibly there wasn't room in the budget for someone to be just a peer coder. I personally like the story paradigm as a way of working out (and then sticking to) priorities, and I love it when managers and principals work on stories like everyone else. Also, in the remote work context, everyone has to work harder on figuring out the right thing to work on, and stories are a decent way to achieve that.
I was let go from a position in a similar situation... I was pressed to enter Jira tickets and get them over the line. Didn't matter I was working with my team, acting as an SMA with two other teams, participating in planning meetings 20+ hours a week. I wasn't getting enough points in Jira across the line and had to go.
Aside: I wasn't actually fired, when I went under "review" status, whatever it was called, I lined up another job and left.
In my company I would have told him to start doing some work and getting stories delivered or he's gone. Yes, he's being useful in assisting others but I can easily find someone who can do that and their own work at the same time. He doesnt need to be sat there with others the whole time. What is likely going on there is Tim is playing his boss, playing up his pairing role and its benefits in order to sit being idle watching others work while providing commentary.
Might it be that he’s so good everyone comes to him first and not you?
I would not hire him in my business regardless of how 'good' he thinks he is. I'm interested in people who can get work done.
2 replies →
You still employ developers? You said AI made them irrelevant.
I get the point that they are trying to make, but Tim should try to find a way to ship things. It sounds like he could ship a lot and make the codebase better for everyone if he did.
So there wasn't a way to capture the fact that Tim was helping with so many JIRA stories in a way that makes Tim's work more visible? Like maybe pair programming stories that Tim owns and moves on the board (assuming Tim's time is best used in a mentorship capacity)?
It kind of rubs me the wrong way that Tim can just fly under the radar and do whatever he wants without any paper trail or accountability while the rest of the team has to clearly convey what they are working on
You can put subtasks under stories, and Tim can have his own subtask that represents his contribution. You can also (with an extension) put time against subtasks if leadership/management want to get really pedantic. Each team member should have at least 1 assigned story/task/bug in each sprint, and Tim should have at least x hours logged against subtasks off stories in the sprint.
Or you can, you know, trust your team to deliver the stories they said they could do in a time window, as a whole. Let them figure out the how at the team level.
How did the manager not know Tim didn't have tickets slated for him ? How did Tim not even pick up some (at a lower capacity) and then still helped with the remaining time ?
I guess as someone who does a lot of the same that Tim is doing,and I bet others can resonate, I still "have to" pick up tickets and I think that's always the expectation in any job I've had as an IC. Is Tim managing his time well ?
Tim would do well in these times of LLMs. They can write code faster than anybody but also need more guiding and coaching than anybody. They don't learn anything no matter how much we call it machine learning. These days what we most need is a Tim of Tims - somebody who coaches software engineers into becoming Tim.
I would guess at least 80% of the people who look like this Tim are contributing zero if not negative. I think there are good odds the actual Tim in the story was too. I mean I'd certainly love to do just the fun part of my job and duck out of all the scut work, if I could find a team that let me.
This reminds me of the chicken problem:
https://medium.com/heroicpresence/the-super-chicken-study-pa...
I've never worked on a team where story points aren't translated into time. I've found story points to be a completely useless level of indirection. Genuine question, has anyone here ever found them useful?
The worst programmer I know literally could not go a day without either checking in code that did not compile or saying something creepy and sexual in a large open plan office, and we all worked together to get them fired.
The first problem can be fixed by CI/CD, and proper branching strategies. Each IC should have their own branch, then PR into appropriate branch
Have no idea on the second, other than a visit from HR.
I was the ci/cd guy. I am not exaggerating when I say this person's code just would not compile and they would not test locally.
4 replies →
I don't think this demonstrates the whole system and premise was wrong, you can just adjust so that Tim gets some credit whenever he helps a teammate.
Measuring stories/features/issues solved seems sensible to me
Reading this is similar...
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
Tims job seems perfect for me.
I like casually hanging around and telling people what they can do better. This usually results in me seeming unlikable, since I am so often pointing out mistakes.
> This usually results in me seeming unlikable, since I am so often pointing out mistakes.
"comms diff" as the kids say. Communicating is a skill, it is possible to get better at it and help people in a way that they enjoy your presence as well.
A much easier solution is just assign a team improvement ticket to him and call it a day.
I doubt he never worked on any tasks though, so maybe something for him once for a while.
It's hard to believe, but this person's code is so convoluted, it makes my head hurt. I've seen a lot, but this takes the cake.
Very good article, managers just want short summaries of what's going on and sometimes these summaries come in the form of bad metrics.
even though this post puts in a good word for tim, calling him out and putting his linkedin in a post with this title is crazy
This just seems like you performed a social engineering attack on your boss to keep someone on the team who was objectively performing poorly but happened to be doing something that is valued in western culture.
In short you replaced one well defined metric with an adhoc one following your bias.
You are a peon. For all you know your local improvement has a negative effect on the whole company. Listen to your boss and let the company fail fast if it has an unfit system.
This is an awfully bad reply. The person described in the essay is basically an L6 and an L5 moving to L6 at AWS. Our L6s don't write code, they build PoCs, work on designs, estimates, and scale through others. They use their experience and knowledge to scale out, and the L5s and L4s do the work.
It seems strange that there is zero commits from Tim. Does he do code review instead perhaps ?
Damn. Now that I read this I realize why my current team feels like nothing gets done and the reason is the team has no Tim.
That’s not a good excuse
It's not even an excuse.
There is a Tim for every successful team. Sounds like a solutions architect.
Hmm, I wonder what Paul Erdos was doing in mathematics
Was he the cross-pollinating bee of math?
Every metric bas unintended side effects. Sure capitalists tend to think the greatest stuff happens from competition, but for real competition you need redundancy -and pay multiple people for writing functionally the same code.
Competition within teams selects for the people who invest most time into looking as if they produced worked punishes those who are good team players.
On top of that, how do you compare a guy who produces 100k lines of unmaintainable boilerplate code versus a guy who in the same timeframe hunts down a particularly nasty and hard to fix race condition and changed 1 line in the end? Any programmer knows the latter is much more exhausting and provides lasting value, while the former might actively hurt the project down the line.
If you manage software development either you trust your team or you have to understand the program yourself and micromanage them. Best would be to trust and understand the program and only inject yourself when it is really needed.
Real bummer the dilbert link in the story is broken, so much lost history.
Goodhart's law is not a joke. There is no standin for value.
previously on hacker news: https://news.ycombinator.com/item?id=37361947
I worked at a company with very similar performance metrics and it was as counter-productive as you would expect. The surprising thing is that the management wasn't that bad overall but they worshiped at the altar of data and metrics for everything. That works great for some things, but not everything.
The Jira-focused performance metrics led to a lot of short term work and fixes since everyone was heavily incentivized to get the immediate task done as quickly as possible without much long term thinking. This created an increasingly large amount of tech debt and caused some real messes. But hey, we could loudly proclaim our love of iterative innovation and data driven decision making processes!
I suppose one benefit was that it became pretty easy to get a stellar performance review since it was completely based on a few metrics that could be managed.
I think this was posted here a year or so ago.
I love this story.
What i like the most is how it describes the more senior engineers in my team.
I think a lot of this idiotic thinking about measuring productivity through "stories" is to pin on the "Agile" industry overselling their low value "methodologies" to the MBA-type managers, which are now unfortunately just about everywhere. Hence you have some clueless person deciding who has to go, based on how many tickets get moved on the board. As Joel Spolsky once said, no software company can succeed unless a programmer is at the helm.
I mean, I've worked on some companies where management would've seen what Tim was actually doing and nonetheless reply with "We're not paying him to hang out with other developers, we pay him to sit at his desk and code!"
Vox Jira, Vox Dei. Make sure you're not working in a company with such kindergarden-like approach at managing people before attempting anything like that.
Kinda concerned the author thinks story points correlates with biz value....
These articles are so predictable and always have a smug aura around them.
"Reports showed me the absolute worst programmer on my team. Did I fire him? No. I actually gave him a 20% raise.
Do you know why? He was the best programmer on my team (in disguise)."
I had a sort of similar situation. I was one of two senior developers at a company making utility software for Windows and Mac in the late '90s and early 2000's. The other senior developer was the owner and CEO of the company and had to spend most of his time doing owner/CEO things so was only able to spend maybe one day a week developing.
The way we organized most of our Windows programs is that I'd write a non-GUI core that implemented all the underlying system level stuff we needed, and then the junior developers would write a nice Windows GUI that used that core. If the product needed anything like a VxD, a filesystem hook, an LSP, or any other Windows kernel extension I'd write that too.
We were profitable and there would be profit sharing bonuses quarterly (I think...might have been monthly but that doesn't significantly change what follows). The owner was always tinkering with how to decide how much profit sharing each person got.
One scheme, which he was sure was going to be great, was to take the total amount available for profit sharing for a quarter and divide that by the number of employees. Call that amount "1 share". So if there were N employees there were N shares available.
He wanted those shares to be allocated so that 25% of the employees got 2 shares, 50% got 1 share, and 25% got 0 shares. Who is in what group would be determined by a company wide vote.
Ballots were distributed that listed all N employees in alphabetical order, and we were told to write a 2 next to N/4 names, a 1 next to N/2 names, and write a zero next to the remaining N/2 names.
For each person their numbers from all the ballots were totaled, and the 1/4 with the highest totals got 2 shares, the 1/4 with the lowest totals got 0 shares, and everyone else got 1 share.
In addition, the people with the 8 highest votes would be put on a committee that would advise the owner on the direction of the company.
The owner's expectation when he launched this was that I would be the top vote getter nearly every time, and would always be in the top 8 so be on the committee of 8 which he was planning for me to run.
I ended up not being in the the top 8. I wasn't even in the top 25%. I don't remember for sure, but it was either somewhere in the bottom half of the 1 share group or it was in the 0 share group.
The reason was simple. Although I wrote the core functionality of all our products my role was not really visible to people other than other developers. It was the junior developers who wrote the GUIs. It was the junior developers who did most of the interaction with the testers. When a test found a bug they'd report it to the junior developer who was, to the testers, the face of the project. If the bug turned out to be in code the junior developer would let me know.
So every developer put me down for 2 on their ballot, but to everyone else I was just some guy in development doing some unknown work so I didn't get many votes from anyone else.
At least the owner immediately recognized that this profit sharing scheme was flawed and dropped it. Since he reacted so quickly I didn't gloat too much over the fact that this was exactly what I told him was going to happen when he first proposed this scheme.
(Some gloating was necessary because the owner and I had been best friends since we met in college about 15 years earlier, and the obligation to rip on your best friend when they do something stupid after you told them it would not work is stronger than the rule that you shouldn't tell your boss "I told you so!").
[dead]
[dead]
[dead]
[dead]
A nice write up.
But our AI overlords will need metrics that they can use.