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.
Yes. Protecting the company. As long as anyone's paycheck doesn't have a slur actually written on it, that's roughly where HR's interest ends in the matter.
Don't feel too called out. If I thought you were wrong on anything else here, I would say so.
HR generally gets a secondary job of checking with other companies are paying someone for similar work. The primary job is protecting the company as you noted. (though paying someone a competitive wage protects the company from people leaving for too little, or the from paying more than they must)
Do you have experience being a tech lead and/or a manager? Tech leads and people managers are two explicitly different roles in many organizations, for good reasons, including, but not limited to them being both full time jobs. It certainly depends on the company and the size of the team and other things, but many many tech leads are not at all comfortable hiring & firing, nor with interviewing and prioritizing work and product managing and meeting with management and approving time off requests and dealing with complaints and deciding raises and promotions and dealing with equipment and managing budgets… the degree to which you’re downplaying these roles is what leads me to have to assume you might not know what’s really involved.
So your mind is made up that someone fictional who is not described in a blog post does not contribute to an org you know nothing about? Is your point that all management is useless? Or something else? And why are you certain, what is your experience running a team or a company? Maybe the sarcasm isn’t communicating your point effectively?
> 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.
If you can automation that job good for you. However some people work in a regulated industry where not getting FDA/FAA and their equivalent for every other country in the world before shipping software means someone will go to prison.
> I'm curious what input the manager has into this besides reading through a list of engineer curated items.
They better have a lot. You might call it product owner (in scrumm), or some other title. Every project I've never worked on has more great ideas than they can invest in today and so you need to figure out what the priority is. It better not be only engineering that has input to this - marketing (a very different skill from engineering) needs to have input, as does finance...
> Tim seems to be handling that. [training]
It is normal to handle more than one management task. I doubt Tim is handling harassment training. This is the main job of HR (not making sure people are paid as you seem to think)
> Hey Tim can you id the asshole? How comfortable are you hiring/firing?
probably not. As one manager of mine told me, he always knew long before the team if someone would work out. The team is close, knows that person is nice (most people are nice), and seems to be smart. If you are the first to notice someone isn't getting up to speed quick enough you are the "asshole" that needs to be removed from the team, an outside manager will be much quicker because they are removed from personal contact with the person in question.
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.
A lot of people seem to have zeroed in on "the manager's decision" and completely missed that it referred to the department manager, not the team manager, and the story is told from the perspective of the team manager.
Not sure the story is even real but apparently that was going on long enough without his manager knowledge that the manager was dead set on making tims exit preparations
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.
It could be a big company. There might be some layers of C-levels, the a layer of managers to listen to them and turn their commands into concrete things, and then a couple crumple-zone layers of management to make sure that the concrete bricks from the top don’t damage actual productivity when they hit.
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.
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.
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 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.
> 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.
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
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.
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.
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...
> "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.
With this attitude you will grow a very specific kind of team. They will be very productive according to your metrics, fiercely loyal, and lethal to anyone who doesn't fit in. However, $diety help you if you ever need to innovate.
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.
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)
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?
I think lots of the other comments are making wild assumptions leading to responses that don’t align with reality. Yours is actually the absolutely correct one. I agree with the solution wholeheartedly. The only difference is I have been trying to promote the tech lead from within vs hiring externally. I want the team to know that we value their contributions and that we’re going to do everything we can to promote internally. I have various challenges with this internally related to seniority, language skills, etc but I’m working to resolve that.
But in the meantime, I still have a team to manage.
One of the members of the team is barely doing anything and survives by constantly asking others to help with doing the job. This reducea productivity of other employees.
A known archetype in many jobs, not only programming.
Yet we get comments like this:
> you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others
Wow.
In any other job, a manager ir HR will just read your chats, emails + demand to document calls - and guess what. It can be found. In a very not very subtle way.
Also the problem above is like managememt 101?
For all the talk about "no technical competence" you dont seem to have any managerial competence.
Also the agile idea that developers keep each other to professional standars is a nice fairy tale (like whole agile in general).
Sorry but what is your point? I feel like you got offended by identifying yourself in it, but did not really understand it. My point being, as a non-engineering manager, you can be great at 1) approving holidays 2) doing a bit of project management 3) doing formal 1:1s . But it does not mean much because you don´t understand the work being done and you are just doing performative actions, e.g. busywork. Or we just say, f*ck it, let MBAs and scrum masters keep running our critical engineering businesses and at the end of the day the doors fall off of Boeing airplanes and astronauts end up spending 9 months instead of 9 days in space.
Why the /s? You're mixing apples and oranges I am afraid. Being a consumer of some product, is not the same as engineering the product. So you have the latest iPhone, good for you - still does not make you an engineer, nor do you have a clue what goes into designing, conceptualising and building a product. And yes, those of us with a bit more experience in the field, remember the times when engineering was done by people who had passion for it, not people desperate to make a career and income upgrade through bullshitting in meetings. For engineering a great product, as we can see with the great entshittification of pretty much everything today, Boeing being the most dangerous example, it's not just that the performative workers are being a drag on productivity and profitability, they are now also endangering everyone. I sure hope some idiot MBA does not come up with an idea of a medical PO or scrum master.
One does not need 20 years of programming experience to identify and fire a shitty employee that coasts by constantly asking others for help with their job. There are tons of bad programmers just like there are tons of people bad at other jobs. Those employees are often a net negative for the team by constantly wasting someone elses' time.
On a side note, your constant whining about "MBAs" and "scrum masters"... it does not make you sound like a professional or reasonable person.
This black-white view of world, that "all MBAs are bad". Whoa.
(Just because I know where you will take it: (sadly?) I dont have an MBA. I am also not a scrum master)
No, please, instead of pointing out everything that is wrong in your reasoning: Please read a referent book about managing software development teams. For example "Peopleware", or "Dynamics of Software Development". Both a bit older, but valuable classics. The second one actually written by a relatively less technical author, a product manager at Microsoft. Maybe then you'll understand a bit more. By the way - I am not the only one complaining about the MBAs. Remember when that plane door fell off? US Congress was holding a hearing about that. And a number of US Congressmen (or were they senators?), people who literally never have the discussions that you and are having, kept asking one simple question: "How come the CEO of Boeing is not an ENGINEER"? It's so natural, that even those disconnected politicians made the obvious connection. Look it up in the archives.
Random books, schizophrenia? I am the one not pointing out anything? Perhaps read your own replies slowly and reflect again :) I won´t dispute your medical competence, as I don´t have any and you seem to be an expert obviously, but for your own good, the two books are classics in their category, which you´d know if you approached your managerial duties with a tiny bit of sense of responsibility towards self-development.
> 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.
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.
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.)
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.
I've resigned myself to the reality that every employer is basically the same in this regard. You need to be spending 25-50% of your time doing your actual work and 50-75% of the time doing all that political and self-promotion and metrics-chasing work so that you can "show your impact" or whatever the hell your company calls it. This has been the case at literally every job I've ever had. If you just go in as an expert and do the technical work you were hired to do 100%, you're going to have a bad time career-wise.
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.
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.
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
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.
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.
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.
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 ?
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.
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.
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.
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.
> Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives
But, it doesn't. It filters for something orthogonal to development, which is ability to obsess over clever algorithmic solutions. Ok, well my company does HackerRank instead of LeetCode, maybe LeetCode is magically better, but I'm not seeing anything that tells me someone who grinds LeetCode is actually going to be useful on my team.
Look, you want an idiot check to make sure someone is actually able to code, fine. That's probably a good idea. But the number of stories on here about people being turned away because they hadn't run into a particular tricky algorithm problem is concerning.
> 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.
But they aren't indistinguishable. The author of the blog post was perfectly able to distinguish them. That's my point. There are plenty of ways to be able to distinguish them, this metric just isn't one of them. Because it's a bad metric.
It may not be legible to the higher ups, but good lower level managers have no problem distinguishing good unconventional people, and under-performers.
> We need to empathise with our managers and the processes in our organisations to understand their purpose and how they came to be.
I do empathize with the managers, at least the lower level ones. That's why I advocated for putting them in complete control and giving them unilateral firing privileges and increasing their pay.
> the best organisations that I’ve worked with used metrics in a very effective way (mostly in start ups). The worst did too.
You're really making it sound like metrics (at least as traditionally practiced in software) are orthogonal to being a good organization. If that's true, we might want to re-think how much time we spend on them and how much money we spend capturing them.
Now, if you want to use profit, adoption, or user satisfaction as metrics, I'd love to talk about that, but I've seen nothing in my experience in the corporate world that tells me that the way we're currently using them is even net positive value.
It only appears that HackerRank/Leetcode isn’t good at filtering because you’re viewing it from your perspective, and not the perspective of the entire population that is tested. To you, the predictive power at the top tail end of the distribution is low, because you’re thinking of two strong developers Alice and Bob. Alice happens to know algorithm X and would pass the test, whereas Bob does not. But that’s not the population we’re testing. Think more along the lines of Alice and Bob and your grandmother were the test population. It’s absolutely fantastic at filtering the lower 95% of applicants because they will _never_ be able to pass. Yes, inadvertently 2.5% of “good developers” are filtered too, but that doesn’t matter to the outcome of your company. They just want someone competent, and they don’t care if it’s Alice or Bob.
The same logic sort of applies to Tim and his performance. The bias of having an imperfect metric is probably much better than the bias of letting an army of middle managers go with their cut. Besides, it doesn’t have to be a hard filtering function at this stage, but a metric to indicate that we need to look a little closer at Tim
> It’s absolutely fantastic at filtering the lower 95% of applicants because they will _never_ be able to pass.
This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.
> but that doesn’t matter to the outcome of your company
It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough. We actively moved away from what you're describing and turned the interview into a 2-3 hour pair programming session where the person completes a mini version of a ticket.
This has much more predictive power than what you're describing.
> This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.
It certainly still is true today. Anybody who is sufficiently motivated to cheat can pass it. It was true prior to ChatGPT, and it still remains true today. And yet they don’t. Most people completely fail these screens
> It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough.
Then your industry is atypical in the type of applicants that you are getting. So to accommodate you’ve had to increase your false positives to reduce false negatives. That’s completely fine if it’s what you need to do, but it’s not the typical experience for a tech company.
We also do a pair screen after the code test and we still reject around 80% who make it to that stage. How do you scale interviewing everyone if you don’t pre screen?
> Then your industry is atypical in the type of applicants that you are getting
Based on the quality of candidates that get through at other companies, I'm guessing our problem isn't atypical. Or at least, good devs often aren't getting through their pipelines at all. It's possible that in trying to reduce the false positive rate, they screened out all of the actual positives, but that doesn't paint a good picture of the industry.
> How do you scale interviewing everyone if you don’t pre screen?
We do pre-screen. The fact that they haven't encountered a tricky algorithm before isn't a problem. For ones where the syntax is valid, a dev at my company does a code review on it.
> 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.
>> 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.
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
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.
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!
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.
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.
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 ?
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
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.
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.
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.
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…
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.
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.
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.
> 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.
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?
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!
>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.
depends on how the tims mesh. Every company thinks that hiring only experts leads to a superior product, despite software being a collaboarative effort.
>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 good mentors I had definitely helped. If anything, they reeled me in to realizing that being a good SWE is not about solo diving into problems and expecting to come out with solutions everytime. It's to understand who owns what and who to consult when landmines inevitably come up. Even if I could solve it all by myself it just wastes time compared to a quick Slack message or a 15 minute meeting.
> 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.
It's a reference to "scientific management" aka Taylorism, the pejorative name by which that now-universal practice was rightly known the last time labor had something resembling the power we deserve in this country.
Taylor is a famous management researcher, that created an entirely new school of management, which by its turn evolved even before his death to become something completely different from the theories held by Taylor himself.
Just to point out in reference to the sibling comment, Taylorism is not a pejorative term, it's the correct name of a school of management. Any pejorative implication on that name is a perfectly deserved result of the quality of the ideas in it.
Respectfully, this is being the exact opposite of smart. Pay attention to the fact that by all accounts the Tim role is actually a force multiplier and output booster for the team. Pay also attention to the fact that you're arguing that Tim should be fired as should the whole team just because... Your Jira metrics are off? This is not what I would call being smart, by far.
You assume management optimizes poorly for desiderata you share.
You also assume by "smart" I intend no pejoration.
Were you to hear me speak these words, rather than read them as here typed, the latter point at least would need no clarification. Unfortunately, text like this is salt without savor.
> 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.
> I don't think your opinion is educated, or based on any experience working on a functioning team, let alone a high-functioning one.
That's an incredible assumption about me. What is your empirical justification for such an insulting claim?
> 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.
Again you're arguing something that I never disagreed with. Indeed I explicitly advocated spending some % of time pairing.
Not really. You introduce yourself to the world by the statements and opinions you express. Advocating for firing everyone in a hypothetical team because of a hypothetical scenario where hypothetical team members help each other out is a business card of your level of experience, expertise and awareness.
> Advocating for firing everyone in a hypothetical team because of a hypothetical scenario where hypothetical team members help each other out
That's not the hypothetical scenario described. Rather, the hypothetical scenario is that all of the other engineers are in constant need of babysitting by the one adult in the room, Tim. There was no indication given that, other than Tim, team members are helping out "each other", or that anyone else is helping Tim. If the team members are peers, then why is Tim disproportionately pairing, 100% of his time?
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.
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.
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?
> yeah, what the company should have done, is only hire experts!
I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".
> I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people.
Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in people. It sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
> 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.
And you could not be replaced because.. why? People leave, other people are hired. Life goes on. The new grads may leave too.
> Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in people. It sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
Nah, this was a pet project of my skip level, and I joined after he asked my boss for solutions to the delay. The manager who owned the project had all of his experienced eng working on direct contracts.
This company had a lot of contracts in where the number of engineering hours allocated are specified. This was an internal project, without a hard cap on number of hours, and they were assigned because it would have been malpractice otherwise. This was very much a team built out of the resources available, rather than intentionally selecting only new grads.
I couldn't be replaced because it being an internal project, it would have been killed once it had no active development. And I suspect internal politics would have prevented it getting restarted after the first delay/failure. Turns out stuff is way more complicated than the easy assumptions people like to make.
> sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
It's easier to predict failure than success. That's that same zero or negative sum game though. Usually a cheap way to feel superior instead of doing the harder things. My previous edit already addresses that though. Failure wasn't actually a given like you want to predict.
edit:
> I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".
Right, of course I know you didn't say that, nor do I think you'd actually advocate for it. But taking something to the extreme to see where it fails is a useful rhetorical tool. The point being, that only hiring experts is obviously bad, for the same reason that only hiring new grads is bad.
I think we agree that there is a balance to be struck?
I think 5 noobs to 1 expert is fine, just like 5 to zero is bad, just like 1 to 1 is bad. The point being, there's no magic line where one is right, the other wrong. This team had no problem once the missing puzzle piece was added. And it was able to be successful in ways that 1 and 1 wouldn't have been. There is no reasonable way to say "what you should have done" when describing a puzzle where you can't see most of the pieces.
> they were assigned because it would have been malpractice otherwise.
I don't know understand this means.
> This was very much a team built out of the resources available, rather than intentionally selecting only new grads.
Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700
> it being an internal project, it would have been killed once it had no active development.
I'm having a hard time understanding why this project needed to exist at all.
> But taking something to the extreme to see where it fails is a useful rhetorical tool.
I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:
> I think 5 noobs to 1 expert is fine, just like 5 to zero is bad
It means, this team was very much a team built out of the resources available, because the existing experts in the company who could have been mentoring new grads were already working full time doing something with a direct contractual obligation to the company. I would have been negligent to pull them from an existing inprogress contract to mentor newbies, and the contracts had a hard limit on number of hours, (not years of experience), so placing a new grad on one of these contracts, replacing an experienced engineer would have degraded the success of the contract.
> Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700
Right, they're not conflicting statements. The company would hire a pool of engineers that can do engineering, then a different part of the company would sign contracts to complete work, than a middle part would place the engineers in the company onto contracts.
> I'm having a hard time understanding why this project needed to exist at all.
Well, because it was a really cool project that the company did end up marketing and selling to it's various clients. It was also a perfect project to put a bunch of new grads who otherwise wouldn't have been doing any work at all given the projects had contracts that stated they couldn't accept more engineers.
> I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:
I didn't retract anything? Are arguments bad? I actually enjoy being able to arguing interesting points and topics. If you're willing to be wrong, you can learn things. As an example I didn't think my previous examples were so controversial. Nor did I remember that contract based engineering work isn't a common thing the most people already have intuition for.
> [just like 5 to zero is bad...] But the team was 5 to zero.
The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.
> [just like 1 to 1 is bad...] Why?
I already answered. Because of politics a project that small would have died with a team with just a single new grad. It also would have been boring as fuck. So if I left, I'm sure the new grad would have also left. Which means the company who hired us both, would then have to hire two new people. This was years ago, but I assume some of those original new grads are still there. In part because that team was actually fun to work with. They were good people, and the team was just fun to be around. A team of just 2 is boring... I know because I've also been on that team with me doing all of the work, and it was soul crushing, and contributed to why I left.
> The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.
>> [just like 1 to 1 is bad...] Why?
> I already answered. Because of politics a project
I was confused because I thought you were trying to make general points, but apparently you're mired in the minute details of one company and its extremely specific projects and politics.
I'm getting the impression that there were so many idiosyncratic constraints on the project that it simply couldn't have gone any other way, and thus there's no real way to critically evaluate whether things would have gone better with a different arrangement. Be that as it may, I'm not sure what kind of general conclusion we're supposed to draw from such a constrained example? Going back to the linked article, the case of Tim didn't appear to be so constrained:
1) They were thinking of getting rid of Tim, which presumably wouldn't have killed the project entirely.
2) They expected Tim to make more individual contributions, which presumably wouldn't have killed the project entirely either.
3) The team already had a mix of junior and senior engineers, not simply Tim and a bunch of new grads.
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.
this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering.
Yah. I also just wanted to make the meta point or whatever—this is your anecdote, technically there’s room for you to be wrong or right, but we don’t have any connection to the underlying reality to argue against your interpretation… so why not just go along with your story?
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.
I think that’s overly cynical. It should always be part of the job (except in places where title inflation has hit the level that it really doesn’t mean anything at all) and usually is.
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.
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 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.
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.
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?
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 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.
384 comments
[ 3.3 ms ] story [ 239 ms ] thread> 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.
Yes. Protecting the company. As long as anyone's paycheck doesn't have a slur actually written on it, that's roughly where HR's interest ends in the matter.
Don't feel too called out. If I thought you were wrong on anything else here, I would say so.
If you can automation that job good for you. However some people work in a regulated industry where not getting FDA/FAA and their equivalent for every other country in the world before shipping software means someone will go to prison.
> I'm curious what input the manager has into this besides reading through a list of engineer curated items.
They better have a lot. You might call it product owner (in scrumm), or some other title. Every project I've never worked on has more great ideas than they can invest in today and so you need to figure out what the priority is. It better not be only engineering that has input to this - marketing (a very different skill from engineering) needs to have input, as does finance...
> Tim seems to be handling that. [training]
It is normal to handle more than one management task. I doubt Tim is handling harassment training. This is the main job of HR (not making sure people are paid as you seem to think)
> Hey Tim can you id the asshole? How comfortable are you hiring/firing?
probably not. As one manager of mine told me, he always knew long before the team if someone would work out. The team is close, knows that person is nice (most people are nice), and seems to be smart. If you are the first to notice someone isn't getting up to speed quick enough you are the "asshole" that needs to be removed from the team, an outside manager will be much quicker because they are removed from personal contact with the person in question.
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.
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.
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.
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 like that approach. Now you can not only have peer recommendations, but also tangible records.
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
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.
> 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...
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.
Yeah, the next day they'll start updating their resumes and sending out feelers to their network.
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)
But in the meantime, I still have a team to manage.
A known archetype in many jobs, not only programming.
Yet we get comments like this:
> you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others
Wow.
In any other job, a manager ir HR will just read your chats, emails + demand to document calls - and guess what. It can be found. In a very not very subtle way.
Also the problem above is like managememt 101? For all the talk about "no technical competence" you dont seem to have any managerial competence.
Also the agile idea that developers keep each other to professional standars is a nice fairy tale (like whole agile in general).
On a side note, your constant whining about "MBAs" and "scrum masters"... it does not make you sound like a professional or reasonable person. This black-white view of world, that "all MBAs are bad". Whoa.
(Just because I know where you will take it: (sadly?) I dont have an MBA. I am also not a scrum master)
I will point out something else: get tested for schizophrenia.
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.
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.
They're suggesting working around the case tracker, not around the metric.
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.
if you can't throw out the game you may as well adjust the rules.
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.)
This really isn't true. At least it's not true of companies I have worked for in Europe.
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.
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.
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.
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.
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.
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.
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.
But, it doesn't. It filters for something orthogonal to development, which is ability to obsess over clever algorithmic solutions. Ok, well my company does HackerRank instead of LeetCode, maybe LeetCode is magically better, but I'm not seeing anything that tells me someone who grinds LeetCode is actually going to be useful on my team.
Look, you want an idiot check to make sure someone is actually able to code, fine. That's probably a good idea. But the number of stories on here about people being turned away because they hadn't run into a particular tricky algorithm problem is concerning.
> 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.
But they aren't indistinguishable. The author of the blog post was perfectly able to distinguish them. That's my point. There are plenty of ways to be able to distinguish them, this metric just isn't one of them. Because it's a bad metric.
It may not be legible to the higher ups, but good lower level managers have no problem distinguishing good unconventional people, and under-performers.
> We need to empathise with our managers and the processes in our organisations to understand their purpose and how they came to be.
I do empathize with the managers, at least the lower level ones. That's why I advocated for putting them in complete control and giving them unilateral firing privileges and increasing their pay.
> the best organisations that I’ve worked with used metrics in a very effective way (mostly in start ups). The worst did too.
You're really making it sound like metrics (at least as traditionally practiced in software) are orthogonal to being a good organization. If that's true, we might want to re-think how much time we spend on them and how much money we spend capturing them.
Now, if you want to use profit, adoption, or user satisfaction as metrics, I'd love to talk about that, but I've seen nothing in my experience in the corporate world that tells me that the way we're currently using them is even net positive value.
The same logic sort of applies to Tim and his performance. The bias of having an imperfect metric is probably much better than the bias of letting an army of middle managers go with their cut. Besides, it doesn’t have to be a hard filtering function at this stage, but a metric to indicate that we need to look a little closer at Tim
This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.
> but that doesn’t matter to the outcome of your company
It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough. We actively moved away from what you're describing and turned the interview into a 2-3 hour pair programming session where the person completes a mini version of a ticket.
This has much more predictive power than what you're describing.
It certainly still is true today. Anybody who is sufficiently motivated to cheat can pass it. It was true prior to ChatGPT, and it still remains true today. And yet they don’t. Most people completely fail these screens
> It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough.
Then your industry is atypical in the type of applicants that you are getting. So to accommodate you’ve had to increase your false positives to reduce false negatives. That’s completely fine if it’s what you need to do, but it’s not the typical experience for a tech company.
We also do a pair screen after the code test and we still reject around 80% who make it to that stage. How do you scale interviewing everyone if you don’t pre screen?
Based on the quality of candidates that get through at other companies, I'm guessing our problem isn't atypical. Or at least, good devs often aren't getting through their pipelines at all. It's possible that in trying to reduce the false positive rate, they screened out all of the actual positives, but that doesn't paint a good picture of the industry.
> How do you scale interviewing everyone if you don’t pre screen?
We do pre-screen. The fact that they haven't encountered a tricky algorithm before isn't a problem. For ones where the syntax is valid, a dev at my company does a code review on it.
> 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?
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.
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.
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
>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.
- # 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...
> # 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 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.
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!
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.
> any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.)
Why ever do that kind of stuff though ;__;
Have no idea on the second, other than a visit from HR.
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 ?
I had not come across "measurement dysfunction" before. Useful phrase.
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.
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
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.
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.
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.
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.
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!
depends on how the tims mesh. Every company thinks that hiring only experts leads to a superior product, despite software being a collaboarative effort.
>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 good mentors I had definitely helped. If anything, they reeled me in to realizing that being a good SWE is not about solo diving into problems and expecting to come out with solutions everytime. It's to understand who owns what and who to consult when landmines inevitably come up. Even if I could solve it all by myself it just wastes time compared to a quick Slack message or a 15 minute meeting.
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.
Yeah, I think that's a good read.
Give management credit for being smart. They mostly do manage only to promote the most egregiously avid Taylorites from among us.
Just to point out in reference to the sibling comment, Taylorism is not a pejorative term, it's the correct name of a school of management. Any pejorative implication on that name is a perfectly deserved result of the quality of the ideas in it.
Respectfully, this is being the exact opposite of smart. Pay attention to the fact that by all accounts the Tim role is actually a force multiplier and output booster for the team. Pay also attention to the fact that you're arguing that Tim should be fired as should the whole team just because... Your Jira metrics are off? This is not what I would call being smart, by far.
You also assume by "smart" I intend no pejoration.
Were you to hear me speak these words, rather than read them as here typed, the latter point at least would need no clarification. Unfortunately, text like this is salt without savor.
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.
That's an incredible assumption about me. What is your empirical justification for such an insulting claim?
> 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.
Again you're arguing something that I never disagreed with. Indeed I explicitly advocated spending some % of time pairing.
Not really. You introduce yourself to the world by the statements and opinions you express. Advocating for firing everyone in a hypothetical team because of a hypothetical scenario where hypothetical team members help each other out is a business card of your level of experience, expertise and awareness.
That's not the hypothetical scenario described. Rather, the hypothetical scenario is that all of the other engineers are in constant need of babysitting by the one adult in the room, Tim. There was no indication given that, other than Tim, team members are helping out "each other", or that anyone else is helping Tim. If the team members are peers, then why is Tim disproportionately pairing, 100% of his time?
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.
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.
> 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.
...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?
I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".
> I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people.
Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in people. It sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
> 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.
And you could not be replaced because.. why? People leave, other people are hired. Life goes on. The new grads may leave too.
Nah, this was a pet project of my skip level, and I joined after he asked my boss for solutions to the delay. The manager who owned the project had all of his experienced eng working on direct contracts.
This company had a lot of contracts in where the number of engineering hours allocated are specified. This was an internal project, without a hard cap on number of hours, and they were assigned because it would have been malpractice otherwise. This was very much a team built out of the resources available, rather than intentionally selecting only new grads.
I couldn't be replaced because it being an internal project, it would have been killed once it had no active development. And I suspect internal politics would have prevented it getting restarted after the first delay/failure. Turns out stuff is way more complicated than the easy assumptions people like to make.
> sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.
It's easier to predict failure than success. That's that same zero or negative sum game though. Usually a cheap way to feel superior instead of doing the harder things. My previous edit already addresses that though. Failure wasn't actually a given like you want to predict.
edit:
> I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".
Right, of course I know you didn't say that, nor do I think you'd actually advocate for it. But taking something to the extreme to see where it fails is a useful rhetorical tool. The point being, that only hiring experts is obviously bad, for the same reason that only hiring new grads is bad.
I think we agree that there is a balance to be struck?
I think 5 noobs to 1 expert is fine, just like 5 to zero is bad, just like 1 to 1 is bad. The point being, there's no magic line where one is right, the other wrong. This team had no problem once the missing puzzle piece was added. And it was able to be successful in ways that 1 and 1 wouldn't have been. There is no reasonable way to say "what you should have done" when describing a puzzle where you can't see most of the pieces.
I don't know understand this means.
> This was very much a team built out of the resources available, rather than intentionally selecting only new grads.
Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700
> it being an internal project, it would have been killed once it had no active development.
I'm having a hard time understanding why this project needed to exist at all.
> But taking something to the extreme to see where it fails is a useful rhetorical tool.
I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:
> I think 5 noobs to 1 expert is fine, just like 5 to zero is bad
But the team was 5 to zero.
> just like 1 to 1 is bad.
Why?
It means, this team was very much a team built out of the resources available, because the existing experts in the company who could have been mentoring new grads were already working full time doing something with a direct contractual obligation to the company. I would have been negligent to pull them from an existing inprogress contract to mentor newbies, and the contracts had a hard limit on number of hours, (not years of experience), so placing a new grad on one of these contracts, replacing an experienced engineer would have degraded the success of the contract.
> Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700
Right, they're not conflicting statements. The company would hire a pool of engineers that can do engineering, then a different part of the company would sign contracts to complete work, than a middle part would place the engineers in the company onto contracts.
> I'm having a hard time understanding why this project needed to exist at all.
Well, because it was a really cool project that the company did end up marketing and selling to it's various clients. It was also a perfect project to put a bunch of new grads who otherwise wouldn't have been doing any work at all given the projects had contracts that stated they couldn't accept more engineers.
> I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:
I didn't retract anything? Are arguments bad? I actually enjoy being able to arguing interesting points and topics. If you're willing to be wrong, you can learn things. As an example I didn't think my previous examples were so controversial. Nor did I remember that contract based engineering work isn't a common thing the most people already have intuition for.
> [just like 5 to zero is bad...] But the team was 5 to zero.
The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.
> [just like 1 to 1 is bad...] Why?
I already answered. Because of politics a project that small would have died with a team with just a single new grad. It also would have been boring as fuck. So if I left, I'm sure the new grad would have also left. Which means the company who hired us both, would then have to hire two new people. This was years ago, but I assume some of those original new grads are still there. In part because that team was actually fun to work with. They were good people, and the team was just fun to be around. A team of just 2 is boring... I know because I've also been on that team with me doing all of the work, and it was soul crushing, and contributed to why I left.
> The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.
>> [just like 1 to 1 is bad...] Why?
> I already answered. Because of politics a project
I was confused because I thought you were trying to make general points, but apparently you're mired in the minute details of one company and its extremely specific projects and politics.
I'm getting the impression that there were so many idiosyncratic constraints on the project that it simply couldn't have gone any other way, and thus there's no real way to critically evaluate whether things would have gone better with a different arrangement. Be that as it may, I'm not sure what kind of general conclusion we're supposed to draw from such a constrained example? Going back to the linked article, the case of Tim didn't appear to be so constrained:
1) They were thinking of getting rid of Tim, which presumably wouldn't have killed the project entirely.
2) They expected Tim to make more individual contributions, which presumably wouldn't have killed the project entirely either.
3) The team already had a mix of junior and senior engineers, not simply Tim and a bunch of new grads.
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.
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.
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.
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.
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.
https://medium.com/heroicpresence/the-super-chicken-study-pa...
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.
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.
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.