Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I work at a place that is actively hiring juniors. While they don’t have an explicit rating system I feel like we unconsciously follow a similar pattern with new coders and it’s unfortunate.
Given that older staff generally have a legacy of responsibility they don’t always have the time required to coach people who lack that self-starting spark. The quality of the questions and how much effort they have put in to answer things themselves are what differentiates a C from a B.
Mostly you can quickly answer something a B asks. But a C who sponges up your day quickly gets categorised into not being given fun or difficult work.
With funding and resources this wouldn’t have to happen but the industry treats mentoring time as lost time. You aren’t getting your story points done if you’re helping somebody else do theirs.
The stupid agile bollocks management style has no eyes on the future of an organisation.
by smackeyacky - How is the place you’re at approaching AI in this context?
As a senior I worry about the juniors coming in — Claude can do what I would have previously tasked to a junior.
I guess the shape of the junior role just changes.
by Fr0styMatt88 - Not to sound soulless but why would you want to invest on the C’s?
Unless we have no options I don’t see why so that. I’ve had to deal with people like that and it’s a tar pit.
by mlinhares - > You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change).
The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one time matters a lot
by logankeenan - The flip side of this is the "high performer" who is constantly refactoring legacy code because they can only understand code that they wrote. And then add overly DRY refactors all over the place that is a pain to then make specific again.by adamors
- As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases.
It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.
by Fr0styMatt88 - I don't think this reductionist view of colleagues (dividing them into categories rather than discerning individual strengths and weaknesses, team-building, empowering) is very success-oriented.by foobarbecue
- I have known a lot of people who think they are (the only) As and spend all their time bike shedding and generally dicking around with tooling and griping about patterns that they prevent everyone around them getting anything done.by jswelker
- > That stack of tasks you have to do? Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them.
I just don't find this to be true and if this is true then the company should rethink how they use juniors. Maybe stop micromanaging them as much and expecting them to do thing your way. Or maybe give them lower stakes or easier tasks. Or maybe let them figure out some stuff by themselves. I dont know what the exact issue in this hypothetical company is, but if they are slowing you down so consistently, something is wrong.
I also find this expectation that a person should do the listed "A" improvements from the get go weird. Juniors, but actually also new seniors, employees grows from just closing tasks to suggesting bigger improvements over time. The people doing A things grow from people doing B things, as they gain experience with particular code base, experience with local politics and mainly gain confidence - or loose excessive confidence.
> You include solid unit tests. (I wish this was a B signal, but baby steps...)
Like, for christ sake, tell them in the first code review. It is not that deep.
by watwut - I sure wish I could relate to this but I haven't been at a company that hired juniors since i was the junior being hired 15 years ago.
- Same. This does not align with my experiences working with early stage startups at all.by ethagnawl
- So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem.
Yes, the noobs are noobs, but the goal isn't to exercise your status over them. Or even to waste that much time trying to categorize between A, B, C. The goal should be to boost everybody's productivity instead of treating them like a game.
by asveikau - Yeah, the author clearly has his head up his own arse.by IshKebab
- The seniors are superior to the noobs. Kind of by definition.by eudamoniac
- I agree. A more modest way of speaking would be welcome. It takes effort to get through but the content is quite interesting: it gives pragmatic milestones.by solannou
- I think the article is explicitly saying, "Ok, you're green, we know that. We're spending extra time with you to make you productive. You can help that process or hinder it, and if you're unteachable or uninspired, we'll probably end up letting you go. So here's some attitudes that get people singing your praises at this early stage."
I'm not sure if this is the last gasp of this type of thinking as AI changes the landscape. There's a good chance that the future is just noobs, perpetually begging LLMs to do better until it works.
by projektfu - So, these self-proclaimed seniors... are they the one who signed the employment contract with the juniors? No? Then you're not their boss, you're a colleague. So stop confusing the two. Take some classes in employment law first.
Guys like this are exactly the reason I don't work in big orgs. They might want their ass kissed, I'm not the one who is going to do that.
by rambambram - No offense but you sound like you’d be a huge pain to work with.by titanomachy
- For a B level: > * You did not cause other people unreasonable amounts of work.*
I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t a problem if you can engage with the team to recover and learn from it.
- I would as well. If you didn’t stop it at the review stage, it’s the team’s problem. It’s not “X’s code broke prod.” In at-will, X can up and leave before you have time to give them shit for it. Then it’s the team’s problem anyway. Make sure you collectively own what you merge.by teeray
- The article sounds like a company with toxic blame culture. If critical aerospace can be no-blame, software can too.
Sure, try not to be useless, but if the company doesn’t have guardrails that’s not on them. If an intern deletes something: why did they have access in the first place? Why wasn’t there a backup?
- A lot of this article reads like an egotistical toxic senior dev. I agree with your take. I tend to agree that "not generating unreasonable work" is not a good signal. If I do 0 work I can fall in the "not generating unreasonable work" category - thats not a good signal.
Also the "Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them." suggests that he is not hiring talented juniors.
It is also a good senior dev's job to architect and scope tasks so that juniors dont bring the whole system crashing down.
by accurrent - This makes complete sense in an environment where people transition from noob to senior engineer within the same company.
It makes less sense in an era when tenure is better measured in months than years.
It makes even less sense in an era of LLMs.
One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they are transferred.
It might also be thought of as a guide as to when to jump ship. If you have managed to get yourself categorized as a C, then leave. Start fresh somewhere else, take the learning with you, and discover if you have what it takes to make it as an A or B.
- > It makes less sense in an era when tenure is better measured in months than years.
Is this common though? Most places I have worked have had people with pretty long tenures. Maybe Silicon Valley during peak ZIRP where you could just keep jumping as long as you could pass the leet code... but then why aren't you staying for RSU vesting?
by ecshafer - I completely disagree with you and it seems like your assumption is that the transition times are years.
I've seen a B player on my team turn into an A player in just the last couple of months
But I do agree with you about the C thing, if youre a C you need to move immediately to at least a B, otherwise leave
by malux85 - > It makes less sense in an era when tenure is better measured in months than years.
If a person's tenure in companies is measured in months then they're signalling they're a C by your logic, or is at least raising a red flag to whoever's hiring. I may be showing my age but that sounds wild to me if that's the norm now.
by luipugs - > It makes even less sense in an era of LLMs.
I would argue that out makes even more sense in the era of LLMs. LLM shaped tasks are tasks that we would hand out to junior engineers. Now, I can implement one of these tasks in 1hr instead of waiting for a junior engineer to finish this in 1-3 days. This means the equation for investing in junior engineers has shifted towards disfavoring investment.
by znkr - This is an interesting perspective(and a great roadmap for juniors to try to improve), but I think for the most part the thesis is wrong, at least in my experience.
Companies do not hire juniors as some long tern play to develop them into good engineers. They hire juniors because they have junior level tasks that need completed.
by LPisGood - Not anymore. We give those tasks to genies and hire juniors as apprentices
- We used to hire explicitly to train junior engineers in the days before the dotcom boom.
Stock options which vested over 5 years were meant to make it worth everyone's time.
by SanjayMehta