The Worst Programmer I Know (2023)
368 comments
·March 23, 2025morsecodist
OnionBlender
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.
hi_hi
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.
linsomniac
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” ― John Ousterhout, A Philosophy of Software Design
paradox460
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
Aeolun
We kinda have this, but… At least we have a dedicated QA team. That spends their whole day literally just confirming that the shit we write is up to spec. We spend a lot of time resolving discrepancies between implementation, spec and test, but when things roll out the other end, they work.
renewedrebecca
I think just about everybody has had to deal with one or several of these guys.
epolanski
Then the other employees found that this is how the world works: don't promote people that deliver results or you may have to replace them.
red-iron-pine
people get promoted based upon their ability to conform to management culture, and their ability to deliver outcomes; in most places the former is far more important than the latter but not always
rvba
Well, I seen a fair share of "blind" programmers who just did their (very limited) scope, perhaps they did it well... yet the whole tool just didnt work and nobody cared.
I imagine that if the guy pointed out things like this - he wasnt popular with the developmemt team, but popular with management and users.
lisper
> 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.
jimbokun
I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time.
But not so much about maintaining and debugging all those lines of code once they’re created.
psychoslave
Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.
thesuperbigfrog
> 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.
** "No Code" or Nihilist Software Engineering **
No code runs faster than no code.
No code has fewer bugs than no code.
No code uses less memory than no code.
No code is easier to understand than no code.
No code is the best way to have secure and reliable applications. Write nothing; deploy nowhere.
One of my most productive days was throwing away 1,000 lines of code. -- Ken Thompson
The cheapest, fastest, and most reliable components are those that aren’t there. -- Gordon Bell
Deleted code is debugged code. -- Jeff Sickel
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -- Bill Gates
* Master Foo and the Ten Thousand Lines *
Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
Source: http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht...
vezcha
code is liability for both the business and the thinker at the end of the day. It's worth it to spend as much time as possible figuring out how to avoid writing it and keep it minimalized.
rottc0dd
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.
arealaccount
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.
oasisaimlessly
TBD = trunk-based development
jimbokun
This story tracks pretty closely with the Dilbert cartoon in the article. Except unintentionally.
mx_03
> 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
OnionBlender
Yes, it was an "increase code coverage" task. The same director wanted 100% code coverage so I had the intern write tests for existing code that didn't have many tests.
suzzer99
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.
lolinder
> 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.
suzzer99
Yeah, I've always worked at non-tech companies with pretty small teams and no roles like that. But it seems like any place with Staff+ engineers should know better than to try to stack them up against more junior devs based on some metric.
Aeolun
I have a decent number of commits as a staff engineer, but barely any are on ‘features’ as measured by story points.
We’re building the things that other people use to deliver features better and faster.
gopher_space
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.
winwang
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.
closeparen
A few years ago we started tracking both office attendance and PR count. Management swore up and down that they understood the nuances, and these metrics would only be used to follow up on outliers.
But then one middle manager sets a target. His peers, not to be outdone, set more ambitious targets. And their underlings follow up aggressively with whomever is below target. For a few months there was an implicit "no vacations" policy in much of the company, until they updated the attendance dashboard to account for PTO. And now an engineer's position in the stack rank is presumed to be her position in the PR count rank barring very strong evidence to the contrary.
The approach you outline is probably optimal, but I don't think middle management as a culture would be capable of pulling it off. You give them a KPI in a dashboard, they're going to compete on it, in a very open and simple way. Metrics are hard to argue with, and nuance requires constant vigilance to maintain.
null
null
__turbobrew__
> 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.
hamburglar
At my last gig I spent the last year and a half as staff engineer and made almost no commits because I was constantly writing proposals, defending them to execs, doing architecture reviews, doing design consultations, and planning long term responses to large incidents. I know for a fact that I brought a ton of value to the company but it was very uncoupled to commits. I didn’t really like it because I need to code, so I’ve moved on to a role where I commit like a maniac again. :)
xdavidliu
> 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?
elevatedastalt
Thanks to Goodhart's law, it's true for any measure that becomes a target.
closeparen
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.
nijave
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)
suzzer99
Lines removed should count like 5x lines added. I don't trust any developer who doesn't get a thrill out of removing code.
bob1029
> 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.
eek2121
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.
carlosjobim
Farming would be extremely effective if the crops would be plowed down into the ground when they're ripe, instead of bothering with all the work of harvesting, refining, packaging and distributing to customers.
But fortunately, software developers are not involved in architecting farming.
What I'm saying is that developing for developments sake is completely pointless. The purpose of software is to help in the real world. And every developer should understand that connection, no matter how shy or antisocial.
jasonkester
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.
slowtrek
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.
kragen
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.
ch33zer
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.
slowtrek
How was that society taught this? Or how did they come to know this?
ponector
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?
slowtrek
If we were to do this, we wouldn't just pick someone so out of the range of what's needed. So basically, if you reframe your question, would I hire a 70 average student on a team of 90 average students? Yes. We would not pick the 50 average students. This is all possible within reason, the kind of stuff being discussed in this thread is to purge people who are 80 average students (free riders in a 95 average class).
Will we need to tutor and support the 70 average student? Yes. Why would we do this? It's good for the soul. The stuff I'm talking about has no place in business, as far as we care to understand as a society at the moment.
tbossanova
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?
BobbyTables2
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…
fsndz
the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated
bitwize
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.
dragonwriter
“Your onboarding will be making collection calls.”
So, your AI debt collection startup onboards engineers by...having them work as human call-center debt collectors?
Is there really AI at all?
Oh, but after passing through the onboarding, your vibe-coding engineers will be be focussed on building product by vibe coding, right?
“(what you will be doing...) Onboard customers, talk to them and travel to visit them.”
So, a traveling sales rep. Your onboarding is pretending to be the product, and after that you are a traveling sales rep who vibe codes on the side?
stickfigure
This must be satire. It is a stretch even for Poe's Law. Someone is punking YC.
ykonstant
Fortunately, vibe coding skills are easy to demonstrate through vibe statements of such; recruiters should be skilled in judging the vibe of the statement claiming vibe coding skills and accepting or rejecting it accordingly.
If, however, you are having trouble doing that as a recruiter, I am offering professional vibe-rating services as well as a full-blown software solution, the first of its kind, Job Market Vibe-Rater™.
null
godelski
> +3 years of experience.
This seems like it was written by someone who loves Dystopian Sci-Fi. Loves in the way that it is the future they want to live in.
gabrieledarrigo
I honestly call this a scam position:
- Vibe coding "non negotiable" - 3 years of experience (of what, exactly? if the "Vibe coding" term was coined just the other day...) - 12 to 15 hours a day
No thanks...
fsndz
it's just a marketing stunt like prompt engineer with 200K salary back in the day. And the fact that you are talking about it and sharing the link to the company's profile means the stunt is working.
null
sanex
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.
yodsanklai
I never tried vibe code as described in this article, but I could see where it breaks. Initially, code works. Eventually, there's a bug, and the LLM isn't able to fix it. At that stage, you're on your own with a potentially large codebase which is totally new to you.
Even on small projects, sometimes I'm tired, I just try to get the LLM do some refactoring for me or write a couple of tests. First, whatever the LLM writes, it's going to code review and I'm not submitting code that I haven't read and understood just to have colleagues complaining. Second, if the code doesn't work, it gets frustrating. For LLMs to help, I like to have a pretty clear idea of what I want, how the "right" code looks like so I can give more indications.
android521
Vibe coding works for experienced developers who give very detailed instructions including edge cases and potential issues or solutions. It is almost code already as it has already included all important code business logic (leaving the simple parts for Ai to fill in ). It is a maintenance disaster for junior developers or non-coders.
fsndz
it's definitely nice for prototypes, but nothing more complex.
mrbadguy
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.
JohnMakin
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.
motorest
> 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.
bberenberg
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.
hansmayer
First off - please do not be offended by the following comment, there is zero bad intent in it and is only meant as a way of nudging you into a correct mindset about the problem you described. Based on your public profile, you seem to not have much in the way of hands-on technical background and I suspect you manage your team based on some set of scrum/agile techniques. It can work purely for project delivery I suppose. However for the deeper analysis of your team productivity, the problem is you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others etc. There is only two ways to go about it. Either you hire (or promote) a technical lead in your team, who can then actually make that call, or you learn programming yourself, accrue at least a year of real technical experience and then try to evaluate. I am saying this because I have seen people with background similar to yours usually struggle, because they try to infer something about engineer productivity based on various proxy measures, such as who talks the most in the chat, who has most commits or even based on activity in Confluence. The way I would recommend any scrum master/PO/agile coach/MBA to think this dilemma is: you would not be able to judge the quality of work of a medical doctor, lawyer or a mechanical engineer, without having a similar background, experience and competence. So what makes you think you can evaluate software engineers without the same preconditions?
metric10
Sounds like both a lack of trust and communication between you and the team.
> 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.
Oh boy...
edit: One issue might be they fear that bad news will lead to a knee jerk reaction that gets them or their teammates fired. They should feel comfortable to encounter problems and openly discuss them in the open with out fear of repercussions. In fact, I would argue this is one of the major advantages of a team; pooling collective knowledge and abilities. If people fear honest communication then the performance of the team is impacted. The manager has the greatest ability to fix this, IMHO...
whatshisface
It sounds like your employees believe that talking to you or amongst each other, where you can read it, will get their friends laid off or bad decisions made without advice. You might want to put a layer of management between you and them, if you can find someone with the skill of trust and relationship building.
marcosdumay
Formalizing a productivity metric won't help you with any of that. And I'm sure that one guy you mentioned will learn to game the metric faster than the other developers will learn to fit it.
bonesss
> "I keep begging people to have conversations in public channels... Guess what, devs refuse to do that."
So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.
On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.
> "Many cultures don’t allow for someone to say bad things about their coworker"
Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.
> "If you have better metrics or management skills than what everyone in the world has figured out"
This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.
Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.
bornfreddy
No offense, but it sounds like you have jumped to a conclusion (which you can't even prove) and are trying to change the process so that you could nail the poor guy.
What is your purpose? Making the team perform great, I hope. Will you achieve that by picking on someone? Hell no. Others will protect him, because they know they will be next in line. Do you think the "underperformer" (if he really is that, even) is doing that because he is lazy? It is more difficult to ask for help all the time than just to do something.
How about you try to find a way to help him achieve the level that others are at? THAT is what should be your goal. Instead of spying on them, award team members who help others, so that they won't feel the need to hide. And make weak members feel safe. Currently it sounds like the environment is pretty toxic with regards to admitting to any problems.
If, after all the genuine effort, you still fail and need to let go of the guy, because he is really bringing productivity of the team down and you can't motivate him to change, then you should know that this is still primarily your own failure. Which is ok, everyone is allowed to fail from time to time. But it is a signal that you should try harder.
(speaking as someone who had to let someone go because I wasn't good enough to make them better... on two separate occasions... so I'm not judging)
giantrobot
> For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels.
No one does this because it's a bunch of bullshit noise in a channel disrupting everyone. It also opens a conversation up to bikeshedding which drags down the entire discussion.
Small ad-hoc groups can be very effective at solving problems.
1. The more intimate the group the less friction there is in conversation. There's less need/desire to put everything in "business speak" so no one gets their feelings hurt.
2. Small groups don't need to dumb down conversations for less technical participants if there's no non-technical participants.
3. Private chats mean no one is hovering over the conversation demanding some useless status update. A problem is either solved and committed or the group is still working.
hnlmorg
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.
throwaway7783
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.
JohnMakin
In large org, i saw people quietly move up the ladder this way by being visibly effective even if their outright contributions may have been difficult for nontechnical or understaffed management teams can see. it’s an essential survival skill, not making any case whether or not it’s right to begin with - I often navigate these systems because I have to.
you will of course have people gaming the system but peers tend to realize what is happening there, and that’s a management problem IMHO
Izkata
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.
johnnyanmac
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.
TZubiri
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.
cyberax
> 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.
dedup
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.
compiler-guy
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.
johnnyanmac
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.
ryandrake
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.
neilv
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.)
ModernMech
Yup, I didn't play the metrics game, and I got burned because my metrics don't look as good against the co-worker who plays the game. The cost is having to remind everyone how much work you actually get done and how much you actually support the team when those "your metrics tell us you're not doing enough" talks come up.
jofer
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.
hyperhello
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.
taberiand
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
johnnyanmac
Yeah, Tim would be poached in days if he leaves for whatever reason. People with that kind of genuine talent or passion to just help make everyone around them be a better version of themselves don't worry about being out of work long.
franktankbank
Play the game and any number of management fuckends will prop themselves upon your shoulder. Unless youre into that sort of thing.. no judgment..
mystified5016
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.
JTbane
That doesn't work with automated metrics, whomever is assigned the work item gets all the points.
natnatenathan
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.
stronglikedan
According to TFA, that's exactly what the manager did.
Clubber
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.
BigGreenJorts
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].
throwaway7783
Agree on silly games, but this is simply acknowledging others' contributions. I think this should be encouraged in general, metrics or not
Clubber
I agree. I think it's pretty absurd that the manager was all set to fire him just based on metrics. There's a quote that I'm going to horribly paraphrase that goes like, "when you can measure something, that ends up being the only thing that matters."
At least he asked the author his opinion first.
Having said all that, if he took it upon himself to be a mentor to other developers and didn't do any tickets himself, that seems a bit odd, unless it was explicitly decided/communicated that would be his role. I would think roles like that are half time mentoring and half time doing tickets, but I don't know enough about the team to judge it. Like I said, I'm assuming the manager was new to the team.
MarcusE1W
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 ?
TheRealPomax
Both "trivially" and "fixed" are doing an incredible amount of heavy lifting here.
NalNezumi
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.
bipson
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
YZF
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.
dilyevsky
Google started using okrs at under 50 people because one of the board members was intel veteran. Not sure about the early years since i wasn’t there for that regrettably but in 2011 when i joined my impression of okr process was that it’s complete and utter bs and giant waste of everyone’s time. iirc google+ hit their okrs swimmingly…
jrs235
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.
crazygringo
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.)
move-on-by
> 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?
crazygringo
> 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.
johnnyanmac
>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.
wavemode
> 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?
crazygringo
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.
lapcat
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.
grayhatter
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.
lapcat
> 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.
throwanem
Advice from the world where things always go as well as they could is of limited value in this one.
bee_rider
It seems hard for us to say, from the outside, how the deal ended up for them. They spent the experienced programmer’s time setting up a team of five. If they’d had GP train one person and work on code as well, they’d have one good new engineer and some code. Now they have five good new engineers.
I mean, it depends on how long it took, how much code GP could have produced in the meantime, and how sticky the lessons were. There’s certainly room to believe GP is right and it was a good trade for the company.
grayhatter
yeah, what the company should have done, is only hire experts! Hiring new grads is definitely a mistake they're making!
...except then I never would have been willing to work there. I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people. One that doesn't treat life as a zero sum game, where someone else has to lose so the company can make money.
I get it; for most people the line on the graph must go up! And it must keep going up, forever! But I reject that meme as the direct cause of the enshittification of reality, and refuse to play any negative sum game. "The only winning move...." and all that.
BTW, that project would have died with just a team of two because I did eventually leave that company. So that suggestion would have killed that project. System resilience matters too.
edit:
> Gee, go figure.
This isn't a given. If their manager was as good at teaching and understanding code as I was, they shouldn't have been missing deadlines. Proven by the fact that I admit I didn't contribute a significant number of lines of code. So what is this trying to say? New grads are bad?
motorest
> 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.
lapcat
> 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.
motorest
> 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.
I don't think your opinion is educated, or based on any experience working on a functioning team, let alone a high-functioning one. Any team working on non-trivial projects does stumble upon critical bugs that are hard to catch or features that are faster to roll out if a subject matter expert sits down with someone to show them the ropes. If you care about performance and time to market, this is your baseline already. You are not better off with a dozen cowboy developers who wouldn't even piss on a team member if they were on fire.
inetknght
> because that's an unacceptable level of blockage.
You shound like a manager. Let me know when you identify and quickly solve all the reasons that the team frequently gets blocked. Until then, we have Tim.
rsynnott
Depends what they’re doing, and how junior the team is. For something relatively involved, with a few new-ish grads, or people inexperienced with the problem domain, on the team, it wouldn’t be surprising. Shows up particularly often in rapidly-growing companies, where by necessity teams are often mostly new-ish.
Now, ideally you do not lean on a single Tim to make this work; that’s kind of a failure mode (I’ve occasionally been a sort of a temporary Tim, but the goal would always be to move the team more towards self-sufficiency to avoid becoming a perma-Tim.) A part-time Tim, who consistently spends part of their time unblocking others, is IME a fairly common phenomenon, and probably necessary.
Vampiero
It's cheaper to hire 5 juniors and to give Tim a mental breakdown than it is to hire 5 Tims.
Realistically though, if you really did hire 5 Tims you would deliver in 1/5th of the time and the software would actually be decent on the first iteration.
It seems to me that consultancy companies actually want inexperienced developers because they can bill their inexperience to the client as they train them to become useful. Awful and, as stated, a major source of mental breakdowns for the Tims who have to put up with their bullshit. And also for the juniors who are always running from fire to fire as they try to fix the clusterfucks they created.
This is not how you should do stuff, but it's how everyone does it. At some point it's just the blind leading the blind, because Tim also has other shit to attend to and can't review every LOC on every PR by himself.
I didn't become a senior by being mentored by other people, btw. I became one because I've always loved doing what I do, and nothing more. The internet and physical books mentored me impersonally. So I'm sure that they can mentor other people just fine, and I don't see why I should waste my time just because my boss is stingy and can only hire a couple of people with my experience or drive to learn outside of work.
And let's be clear -- mentoring and being taught something are two very different things. I'm not anal about the latter. I'm anal because I want to write code, I don't want to tell people that they should learn to fucking read the error messages and google them every 5 seconds.
Though right now I'm being very brutally honest. I'm actually nice and friendly to them in person, and I'm very patient. But that causes me to break every once in a while because I secretly loathe it!
kcoddington
Why is it unacceptable? And wouldn't the time/productivity loss from on-boarding an entirely new team completely outweigh the time/productivity loss of the 100% pairing with a Tim?
infinghxsg
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.
UK-AL
In a lot of companies the definition of senior engineer helping others develop technical skills.
sally_glance
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.
dmoy
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
Atotalnoob
Problem on a lot of teams is people skip over #2 in my experience.
Good devs always do #2, bad devs skip it.
nedt
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.
ChrisGammell
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
iamleppert
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.
nijave
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.
YZF
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.
johnnyanmac
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.
Waterluvian
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.
bsindcatr
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...
khazhoux
> 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.
bsindcatr
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.
khazhoux
You're arguing a different point. I never said a manager should simply count the number of LOC changes as a productivity metric.
I said that good developers write a lot of code. And I'm not talking about senior developers who now do mostly advising/review/architecture work (and don't code much anymore). And sure, sometimes someone takes a long time for a critical few-line change, but that does not happen every day.
I find it exhausting, frankly, how much pushback this simple concept gets around here. It seems to be a reflection of the gigantic team sizes that are common these days, and the modern tolerance for low-output (but still highly paid!) developers. Maybe the popularization of 2-week sprints 15-20 years ago corrupted everyone into thinking that everything should take that long, minimum.
People are shockingly ok with taking 3 days to add an argparse block to a python script, or half-week to implement a single HTTP call. It's nuts!
andix
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.
snapetom
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.
johnnyanmac
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.
croes
So the real metric is the manager who knows their team and what each member brings in.
peterldowns
Yes, absolutely — and can effectively communicate that to their manager.
mjburgess
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.
catlover76
[dead]
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.