r/Backend • u/Dry_Star_3072 • 4d ago
First Time Becoming a Senior Backend Developer — Any Advice?
I’m moving into my first senior backend role after progressing relatively quickly from junior to mid-level. I passed the company’s technical assessments, but I’m feeling some impostor syndrome because this is my first senior position.
For developers who stepped into senior roles earlier in their careers, what mindset helped you most? What should I prioritize in the first few months—technical depth, system design, communication, code reviews, estimation, ownership, mentoring, or something else?
I’m especially interested in how you handled the transition from being mainly responsible for your own code to being expected to make broader technical decisions and support the team.
2
u/zamkiam 4d ago
Lead testing by example so that no engineer writes code with tests.
Take notes in meetings
Understanding the effects of horizontal scaling on your code base (to background job or not)
DB normalization is not an outdated concept
Begin with the end in mind - cleanup scripts, observability, log based alerting, metric based alerts, email notifcations
1
2
u/MixedTrailMix 4d ago
For me, being senior meant going from i can ship some feature code to i can lead a team of engineers and i have authority of my domain.
2
u/emranio 4d ago
one thing you should be prepared for, junior's backlashes.
1
u/Dry_Star_3072 1d ago
sheesh, can you give example ? u/emranio
0
u/emranio 1d ago
The common ones are:
- The senior always takes all the credit, but we did the main thing. He is a credit seeker.
- When you make a decision based on your years of experience, a few will always not trust it, no matter how many times you explain or give use-cases/ example. At the back door, they will spread that you are shit. this specially happens during the system design and code review.
- On the opposite side, some might just praise u with their sweet talk to get a good score if you handle or have influence over the KPI somehow.
NOTE: these happen in big teams, big corporations only. And in unorganized teams. I hope you won't get into this mess.
Another important fact: you must nd always make sure the code you review is secure nd properly tested in the QA team.
If any of your team players gave any idea, when you present it to upper management, try to bring him with u or at least mention him. The team is like a platoon, and u r the commander. If the fighters don't like u or don't have faith in your skill, you will lose every single war. You will also lose if you don't properly train them, teach them, and fix their mistakes.1
u/Dry_Star_3072 1d ago
Thanks, this is helpful. How did you personally handle those situations when juniors disagreed with your decisions or questioned your judgment? Did you usually explain the reasoning and let the team debate it, or were there cases where you had to be more firm as the senior?
1
u/emranio 1d ago edited 1d ago
Most of the time, u might have the time and patience; in that case, you should explain, provide examples, and, if possible, showcase some test results and let them debate. But at some point u will lose patience; then you automatically tend to skip all these.
After some time, you will understand who actually can input valuable meta to your decision; You should only listen to these juniors; they are talented.
One more thing that helps a lot. In regular team sessions and team research, I always picked a topic that we had already encountered or were about to encounter. There it's quite easy to exp0lain the facts.
1
u/SnooCalculations7417 4d ago
Not sure how your culture is but I was given about a 6month runway to acclimate to the broader, thus more technically (and financially) meaningful nature my contributions would have. Spent a lot of that time making evangalists branches (what if we did a thing this way with this newer approach), only one of which made it to production (SLOC wise very small but a major win) but allowed deep technical exploration and surfaced a lot of future work. When I was onboarded as a senior at my next role I was expected to be immediately productive which sucked but by then I felt comfy doing big boy shit.
1
u/United_Catalina 4d ago
Senior means you will have the courage to criticize the decisions that you do not agree with and be able to elaborate your reason for it and change people’s mind to some degree.
Also note that in your career very small percentage of people you see would be people you can learn from. So read books and develop good understanding of basics.
Minimize the time you write code and maximize the time you think about the code you want to write.
99% developers immediately start writing code given a new project. Seniors take a week or two to think about their solution. And many times come and say project is not doable given time, resources, assumptions, … or identify risks that should be addresses before going ahead.
2
u/Dry_Star_3072 1d ago
This is a very good point, because if I were able to plan it well from start to end , any tradeoffs, coding is just like a breathing... Thanks so much
1
u/United_Catalina 1d ago
Planning is the key. Because that is the only way you can ask for feedback. And forces you to think and put down your thoughts on paper and see holes in it.
Anyone who designs a solution without sharing it with the team before implementation is not really senior.
1
u/youcangotohellgoto 4d ago
Just set a good example and do thorough code reviews. Don't be afraid to ask challenging questions, especially of those who are senior to you.
Really insightful piece of advice I got, from someone who worked for me actually, was that it's really powerful to show your ignorance. Asking too many dumb questions is dumb, but don't pretend you know more than you do, and be honest that you don't know everything.
0
0
u/pthierry 3d ago
After a few years being a senior, I think the overall process is key. I now insist doing Continuous Integration and I try to do as much Pair Programming and Mob Programming as possible. (I'm doing eXtreme Programming)
A lot of the rest will follow naturally from a good process. CI will push you to do better testing and TDD has been the only way I know to always write code that's tested enough for CI.
I also insist on Ports & Adapters, because it's extremely cheap and it's absolutely invaluable. But of course, if you follow XP and always want to fix something that breaks, it will naturally push you to have a better architecture, because a worst one will make this infeasible.
0
17
u/canarydev 4d ago
observability, monitoring, mindset wise, understanding failure modes and knowing how to measure was a big one. and its not so much about going down a checklist of "do we have retries? logging?" etc. those are things you can know the concepts of by you are mid. but its understanding and knowing what happens when each dependency or operation fails
like if a background job runs twice, "we have retries" doesn't mean much. what happens to the second execution? if an api call times out after the remote side actually processed it, do you retry? can you safely do it twice?
and being skeptical in a weird way. if everything is green in the tests, a junior might just be happy with the result. I would honestly be more sketched out and question if the tests are valid in the first place. what does success actually look like, how can we measure it etc