Comment by grayhatter
1 month ago
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.
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.
1 reply →
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.
4 replies →