3 ms·
I have personally followed the same strategy, but at the expense of my ‘career development’. Trying to perform well or getting a promotion can be a lot of unpro
by whazor 1y ago
I have personally followed the same strategy, but at the expense of my ‘career development’. Trying to perform well or getting a promotion can be a lot of unproductive effort.
I think the only downside of 100% uniformity is that you don’t hire and train junior engineers, which should also be like a duty. While you could pay juniors the exact same salary, this might give that person a lot of stress (“
concerned that they aren’t doing enough“). One solution could be to offer traineeships, where the you offer actual coaching for a fixed duration. While clear goals like: finishing first small task, first doc, led first initiative. Then automatically completing after one or two years.
- hinkley 1y agoI’ve worked with a lot of engineers who punch down and what they all have in common is that they don’t have a clue how to make lemonade from “lemons”. They just want people who can read their minds. Tough shit. Never going to happen. New people ask questions and make mistakes that reveal organizational problems that would help everyone if fixed. As a company grows there are more parts added to the system and at some point senior staff are going to feel like newbies doing something they haven’t touched in two or three years. All that work you did for newbies now pays off as lower overhead for putting projects into maintenance mode or scaling them up for a big initiative. The worst outcome for everyone is if you hire a new employee and then let them alone. That’s short changing everyone.
- JonChesterfield 1y agoThere's a really sad failure mode for talented raw engineers that get no feedback in the first few years. They write a lot of code, and it's trash, but noone steers them in a better direction. Wait maybe three years on zero feedback and they've convinced themselves that their work is great and this new critical feedback they're getting can't possibly be right. You end up with clever and productive and shite, all mixed up in one indignant bug farm.
- hinkley 1y agoOne of my most memorable “this interview is over” moments was I used to ask people to reflect on their last project and ask what they would do differently if they knew then what they know now. One fellow, sitting with both myself and the owner, answered with a single word, “nothing.” And that was a very awkward silence. I’ve been asked this question myself, which is why I stole it. Even on a project that went exceptionally well, where you pick the right tech and don’t spend a lot of time working around issues, there is usually at least one question you should have asked a little sooner to save some rework or avoid blocking issues. And I had to answer that way once. I had a feeling we should check on this thing but I or someone else talked me out of it, and three weeks later I regretted it. It reflects on your capacity for continuous improvement. If you can’t think of anything then that’s less about how the project went and more about your opinion of yourself, and your ability to notice feedback from others, or from the situation.
- JonChesterfield 1y agoIf you picked the junior carefully they'd be fine in terms of added value. Training useless junior engineers is excruciating. There's a strong sense of pouring time into the void. Good juniors are a different game. Someone that understands new stuff on the first try and asks piercing questions about what stops a given approach from working is great.