Comment by lapcat
1 month ago
Was Tim hired as a teacher or trainer? What I find strange is that it sounds like Tim was not doing any individual work.
As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approximately 20% of my time pairing with others and 80% on individual contributions. (That's a rough estimate; it could be 25/75 or 30/70.) The article said that Tim was "patient", but perhaps he was too patient, wasting a lot of his time that could be spent accomplishing other things.
I've been the TL for a team of effectively 5 new grads before. Effectively all of my time was spent teaching them how to solve problems, fixing (preventing) bugs in their code from getting committed, and writing boilerplate, or infra code that would never be listed on whatever a story point is. But constrained their responsabilities into a format and structure that would play well with each other's so they would stop constantly rewriting each other's code every other week.
I enjoy teaching so that was a much more enjoyable way for me to spend my day, than drinking caffeine and cranking code the rest of the team couldn't understand. I joined that team because they were constantly missing deadlines. When I left that team they were finally ahead of schedule, but much more importantly they had a code base they all understood. That wouldn't have been true if I'd just written all the code myself. I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself. But true or not, when I left I would have no confidence the team could continue without me.
Could I have spent more time writing code? Probably, but what delivered the most businesses value? I was hired as a glorified software engineer but instead of delivering code, I delivered a team that could produce code. Their manager was *never* gonna do that. So should I have prioritized doing what my job title said? Or doing what's in the best interests of the long term mission? Every situation is gonna be different, if teaching is soul crushing for you, or more importantly, the team refuses to be taught, I would suggest just deliver code. In this case, everyone wanted to learn, so that was the easiest path forward.
> a team of effectively 5 new grads
> they were constantly missing deadlines
Gee, go figure.
> I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself.
> what delivered the most businesses value?
What the company should have done is hire you and one new grad (rather than five), who you could mentor without spending all of your time mentoring, and get the same amount of work done with two people for less money.
Advice from the world where things always go as well as they could is of limited value in this one.
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.
2 replies →
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?
5 replies →
> Was Tim hired as a teacher or trainer?
Do you think that's any relevant? Software development engineers in general are hired to work on projects as part of small teams, and their goal is to deliver projects. It's not story points, it's not burn down charts, it's not PRs, it's not LoCs touched. It's how many projects are delivered, and keep everything and everyone problem free. This means that if you are struggling, your team will struggle as well until you unblock yourself. If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
> If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team.
I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.
> 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.
3 replies →
> 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.
6 replies →
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.
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!
1 reply →
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?
Yes, obviously it’s relevant you have a fundamental misunderstanding about what software engineers do. We don’t “build systems” we diffuse risk for the managers. If someone is “helping build something” they can spend their own money doing that. This is business, the less work you do the more money you make.
In a lot of companies the definition of senior engineer helping others develop technical skills.
In a few of those companies, so also is the job.
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.
1 reply →
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.