Comment by motorest
1 month ago
> 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.
> 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.
2 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.
> You sound like a manager.
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.
5 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!
>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.
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.