31–40 of 139 posts
> You write up what you learned in an interesting, useful and persuasive way.
Very curious (and appreciative) that some company cultures allow this. I haven't had such experience (although I work in a parallel role). It's usually just grinding out tickets.
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…
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 ans…
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.
I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read. The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity.
Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.
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.
That does happen, and that junior level work is constructive, but what I've also experienced and noticed is that companies put a lot of effort into finding and hiring exceptionally skilled juniors (industrial placement schemes, graduate fast-tracks, etc.) where they can make safe bets on those people delivering significant value to their companies/projects. Some bigger companies do make an effort to build a mutually…
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…
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?
It's trendy in buisness culture right now to erase the individual. Zero accountability can also mean zero growth. I don't think it's honestly the most enjoyable situation to be in.
Earlier quoted context omitted.
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.
One thing is that the A's are watching how you treat the C's. They might not have a good gauge of the culture from their own experience because they take care of themselves.
There's something that is very pernicious in the government in Brazil (where I'm from) where in a department there's one person that does all the work while everyone else sits around. You can't fire the non-performing ones or push them because there is a very strong worker protection system for them. Back in college it took me a full week to get my grade history because the person that did all the work was on vacation and nobody else bothered to learn how to pull it or cared if students couldn't get the report.
These are the C's, people that have to be forced to do the work, and that will eventually cause all the work to pile on everyone else. There's no fun in working in an environment like that and its a quick recipe for a burnout.
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.
Stock options which vested over 5 years were meant to make it worth everyone's time.
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.
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.
I have never worked at a place where this was true. Either senior devs would pound through the tasks, or we’d cut them as unimportant.
The only reason we ever hired a junior was because we saw potential and thought they could grow into solid colleagues.