https://news.ycombinator.com/item?id=31438741 Do you want to be an engineering leader? This is what you are, regardless of your official title at your company. Engineering leaders are judged by how much better they make everyone else. You may hear the term force multiplier used. Say you are really a 10x engineer, how much more effective are you if you could improve the efficiency of 350 developers by 10%? Mentor, teach, help establish culture, make systemic changes to help your peers become more effective.
impostor syndrome
-
Become a serious mentor. Not just in passing code review, but actually spend time teaching.
-
Try documenting your processes and thinking to get to the right code answer. Like a company coding manual. This way it scales your knowledge rather than being stuck as the ‘doer’.
-
Consider taking on different challenges, like management, either at your company or another company.
-
Reflect on what it would be like to really be in a room with other 10x developers - you will all think you have the right answer which is different from each other. Does that really sound like fun to work through on the daily? It was fun when you weren’t so sure you were right, it gets less fun the more sure you are.
-
Most round B/C startups have ~50 developers. If you have 350, you’re in a massive machine. You may think your 10x everywhere, but it’s possible your only 10x in your locality, where you know the entire code base. It may simply be time for new challenges at a new company.
-
Ask if you can start writing for some open source project you like (new or existing) as “developer relations” for the company in some way. Yes, you will need to reduce your in house tickets - but it will keep you happy and working and contributing and still probably doing 50% of the work. And the company gets other benefits from it.
-
Along the same lines, you can start writing technical articles to publish as dev relations/marketing. Theres a lot of value in those seo posts for a lot of companies.
Theres like a million ways to go with this, but hopefully these ideas help a bit. Best of luck and I hope you find some meaningful company to hang out with.
…
. #
Gergely Orosz - 29 June 2022
As a tech lead or eng manager, you so frequently get request from above or from other teams to drop what you are doing and work on this thing they need, now.
During my 4 years at Uber after asking these questions, 9 out of 10 times it turned out it wasn’t really urgent:
- “What is the impact of this work you’re asking for?” If the impact is unclear: sorry, but we can’t do the work. Why would we?
Just this question made the requester realize half the time they just think it’s urgent, but don’t know what the work will actually result in.
- “Do you have a spec that is agreed with stakeholders?” A writeup answering the “why” and the “what” that is signed off by relevant business folks.
I’ve seen so much engineering work thrown out as later the business goes “that’s not what we wanted, why didn’t you tell us?”
- “We’re not committing to any work before we have done a rough estimation.”
With #1 and #2 done, many stakeholders will come and say “drop what you’re doing, this is a 3-day work we need ASAP.”
Hold your horses. You don’t make estimates: the team doing the work does…
- Make the cost of dropping what you’re doing very clear.
This cost is always forgotten by the person coming with the request. But it’s a relevant one: wrapping up work, onboarding to the new work, then later onboarding to the old work. Plus a hit on morale for a sudden change!
Uber has some very hectic times when there were reasons we needed to do some new work ASAP. Like a regulation change that means the company would be banned from operating in a region if not building something.
Even in such a place, most “urgent” things turned out to be noise.
The way I always approached these requests was to educate the person coming with them, and have them realize their work is actually not as urgent or as important or as impactful of what the team is already doing.
Doing so meant building empathy both ways, and less hard feelings.
A huge upside of this approach: when committing, you can commit with a very high certainty that you will not be interrupted with your work.
The alternative: take on this “super urgent” work, then someone else comes along saying " I need you to drop what you are doing now…"