243 points by nsavage 1 day ago | 143 comments | View on ycombinator
sajithdilshan 1 day ago |
swiftcoder 1 day ago |
I've interviewed several great senior engineer candidates over the last few years, and then had to watch do this and walk themselves right out the door inside of 6 months. I've developed a marked preference for promoting internally, because you get longer to head this sort of thing off.
Incidentally, this sort of thing is why software engineering desperately needs some sort of formal levelling criteria and/or mentorship programs. It's really hard for senior folks to calibrate themselves against their rapidly shrinking peer group.
slowin 1 day ago |
The best advice I can give on moving your career forward is to not try and get a promotion at your current job. Apply for better positions at other companies while you still have your current role. You'll have maximum leverage and unlimited time to choose the best possible option. Trying to claw your way up the ladder in a single company is the least efficient (and more often than not hopeless) strategy.
Dizcorded 1 day ago |
I’ve yet to decide if that’s what I actually want or if there is another solution out there. Is leaving the only real solution?
sheepscreek about 16 hours ago |
Perhaps I am lacking context on the “seniority” of this individual. Unless they are a Principal engineer, or operating as an architect/staff engineer, or as a “tech lead”, I would absolutely expect them to be solid engineers delivering code.
They would have clear deliverables in sprints that would typically be heavier and more complex than their junior peers.
Take this from someone who has worked in all of the above roles and subsequently in management.
hsbalanxvxjsmab 1 day ago |
b0rtb0rt 1 day ago |
atom_arranger about 15 hours ago |
In a place operating with SCRUM you're often expected to be shipping things every sprint, and sometimes with a large and important piece of work the experimentation, and the building of the thing, doesn't fit in a sprint, and if you tried to ship incrementally you'd just be shipping junk.
So you're going to end up giving some standup updates that do not inspire confidence for a bit. "I tried this thing, didn't work out", "still working on X, tried another thing", etc.
It's possible at the end of it you figure it out, and the result justifies the time investment.
The spiral is friction with a system that disincentivizes taking on ambitious goals.
I wouldn't just blame the engineer for not shipping smaller things, being less ambitious, talking more instead of working, I'd blame the company culture for disincentivizing deep work and ambitious goals.
Obviously there's a limit to this. You do need to ship something useful eventually. It's possible you spend extra time and still fail to accomplish the thing you wanted. It might be damaging to your reputation. You win some you lose some.
With AI there's less time between having the idea to do something or try something, and it being done or ruled out, so I see this being less of an issue now. The main barrier is knowing what to do and describing it.
kwertyoowiyop about 11 hours ago |
ab_io 1 day ago |
Instead, just communicate with your stakeholders asap. Chances are they already know the project is at risk, and they'll be amendable to either descoping or pushing back the deadline.
derf_ 1 day ago |
It is not just about what you are working on. You need to understand what everyone else is working on, and more importantly, what they could be working on (their capabilities) and what they should be working on (the org's priorities). When you find yourself being dragged in to meetings to write roadmaps, estimate schedules, and contribute paragraphs to the annual budgeting process, you know you're on the right track.
He does have one thing right, that this is about reputation, because you cannot just go out and unilaterally take this authority. It has to be earned. Having a large number of lines of code written, commits landed, and tickets closed can be a means to that end, but it is not in and of itself the goal.
plexor-labs 1 day ago |
I wish that I could travel back in time and tell my 25-year-old self this information.
ungreased0675 1 day ago |
docheinestages 1 day ago |
jacobgold 1 day ago |
This is probably an example of the Peter principle:
The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.
https://en.wikipedia.org/wiki/Peter_principle
There's a huge amount of title inflation going on in the industry. We're now seeing the "Principal Engineer" title being given to people with 3 years of professional experience.
Unfortunately, this is simply not enough time to be very good at all, no matter how much raw talent you have. It takes a decade of experience just to know how to manage yourself effectively, let alone mentor others and lead large projects.
runamuck about 7 hours ago |
Answer: No.
geoffbp 1 day ago |
obviously, more senior ICs should be creating/defining/delivering their own work. But either way, alignment with director or TL seems like a good idea to reduce anxiety
BatchJob 1 day ago |
Also there isnt much above senior/lead engineer these days, there is no straight line career progression above that. You can try to get into architecture but thats mostly paperwork, or management which is mostly dealing with people.
If you want to call your own shots as an engineer the world is your oyster, start your own company and build it. There is not much worth "being in charge of" in corporate dev shops that I can see or would want to be a part of. Most of it is retread, make work including FAANG.
gabrieledarrigo about 7 hours ago |
It's simple: just don't do it.
comrade1234 1 day ago |
tamimio about 6 hours ago |
malux85 1 day ago |
As a senior its your responsibility not to disappear into a cave but to do the opposite - show what you are doing, show your thought processes so juniors can learn. Discuss openly your problems and encourage discussion and feedback and show the juniors that its ok to be vulnerable and not know everything.
Then you have to keep management informed exactly whats going on, where your Blockers are, what intermediate goals you have and progress towards them.
jatins 1 day ago |
wickedOne 1 day ago |
msteffen about 10 hours ago |
Avoiding status updates, needing to “prove yourself,” things like these, were all products of a deeper lack of trust for me. TFA alludes to this with “imposter syndrome”. I was so used to this that it took a long time to figure out. What helped me (and I wouldn’t say I’m better, but better than I was) was a few ideas:
1. Trust is equal parts competence and communication. Trust is lost when you expected X and didn’t get it, which means half the problem is not getting it and the other half is expecting it in the first place.
2. So trust requires clear communication, and clear communication requires trust in the other direction. At a totally dysfunctional company, all of engineering doesn’t trust leadership, so they're not honest with leadership, and soon enough leadership doesn't trust engineering, if that hasn’t happened already. So lack of trust in one direction breaks down trust in the other direction.
3. If you don't feel comfortable saying something that's true (anything! “I got nothing done yesterday because I still don’t really understand the problem I’m solving,” or whatever kind of thing you’re afraid to say), it means you don't trust whoever you're talking to. This is a problem—see #2. In the context of TFA, this is the problem that leads to you skipping status updates or going off and building without prior discussion.
The solution is building your own trust, which can actually be hard to do and requires some self-knowledge (e.g. did you have a bad experience at a prior job? Are you dispositionally a nervous person? Did your boss/leadership break your trust in some way already—large or small?).
This is IMO what TFA is really about, and the strategy it suggests is a great one if a bit of positive feedback and encouragement is what helps you extend trust (which is fine! It's worth knowing that about yourself) and grunt work earns you that feedback (which it might, though you can't control what other people do—it may also help to communicate that you're looking for that, e.g. "I want to see what kind of contributions are celebrated here, and I thought these might be." A small trust exercise in the context of the larger one.)
It might be something else. Off the top of my head: will work respect my needs if a life event temporarily interferes with my work? If I'm missing context on a project, will I be given help or hostility? Am I being given a clear explanation of the expectations for the role?
(Finally, I think it's worth mentioning the version of this where your boss or leadership isn't building trust in you, and IMO it looks like you stuck in a marginal role and not given a path to larger ones, even though you're clear that you want them. Sometimes you can convince them to trust you, but you can't control what other people do. In particular, if you're building something without prior discussion, consider that a lack of trust from the company to you is now creating a lack of trust from you to the company. Maybe it'll be fixed, but no guarantees.)
LargeKakapo about 22 hours ago |
Sadly in many organizations it really does come down to a “consensus” within the environment about if you are succeeding in the role and fit. Woof.
godelski 1 day ago |
> the thing they do is they tell themselves they need to almost cosplay being a more senior engineer than they are.
Isn't this explicitly written in every promotion guide? Every one I've ever read says you need to be working at X level for Y months before getting promoted to X. Thats not delusion, that's codified. There's good reason people work like that. > like, for two, three weeks, you won’t hear anything from them.
Two might be fine, three is probably pushing it, but a lot of times this is just bad communication (which I think is more the point). But also our field is extremely rushed for some reason, especially with AI. Sometimes things do take time. Honestly, I think the whole industry could move a heck of a lot faster if we just cooled our jets for a bit. Innovation doesn't happen by slamming your head against the wall, it happens in the quiet moments after lots of head banging. But our culture acts like we can brute force our way.We constantly say "I'll fix it later" and we never do or do it when the problem has turned from a small one into a big one. Why can't we fix problem while they're still small? It's penny wise and pound foolish. Does your manager actually know if it will become a big problem? More than you, the person in the weeds? How would they even know? Would you even tell them? Are you afraid to tell them?
We're constantly jumping from bandwagon to bandwagon, not taking any time to even check where we are or look up to see where we're going. And we attack anyone who pokes their heads up like we're afraid we'll get hosed reaching for a banana.
Is it really any wonder people burn out? You can't operate at high anxiety forever.
hluska 1 day ago |
codedump about 17 hours ago |
JonathanCross 1 day ago |
almapater about 19 hours ago |
ls-a 1 day ago |
alembic_fumes 1 day ago |
But I suppose the message, hard to read as it is, is something that some people need to hear. I've seen this first hand a few times, mostly in people who got promoted by working really hard and the more they got promoted the harder they felt like they must work to keep proving themselves. This often led into burnout.
I don't know; I don't really want to blame the people themselves or say that they're the ones responsible of their own condition. People, and I want to say technically minded people in particular, are each rather fallible when it comes to our own humanity and the psychology underneath. And so, I'd much rather see this same advise be targeted to managers and senior teammates: when you notice a colleague who seems to have gone in too deep, have a friendly chat. They might very well be blind to it, or trying to ignore it to push through just that one more time.
plexor-labs 1 day ago |
Unfortunately, this is something you have to learn through experience and cannot be taught by someone else.