Ask HN: What makes a Senior Dev
What makes a entry level, mid level senior dev?
Core dumps, memory leaks, hardware faults, and plain bad luck.
Big O, data flow, always learning -- or out you go.
Manager metrics, schedules hectic, methodology hegelian dialectic.
Taking the heat, feature creep, open office, uncomfortable seat.
Holy wars, revolving doors, carpal tunnel, all you can take? There's always more.
Fucking suits, random reboots, and the ever present "thousand language stare".
Oh yeah, pressure -- lots of pressure. And time, time, time.
Metric shitloads of time.
Time, man. You gotta do your fucking time.
"The thousand-yard stare or two-thousand-yard stare is a phrase coined to describe the limp, blank, unfocused gaze of a battle-weary soldier."
It's the look of someone learning yet another "teh shiny" just to stay current -- with full knowledge that it's yet another idea from the 1970s, repackaged to appeal to a modern audience.
The look of someone who simply lacks the energy to resist the zeitgeist. Who has to listen to everybody oozing religious zeal over the flavor of the week.
The look of someone who is thinking "cool, monads -- now can we roll up our sleeves and ship this product? Remember our product? We get paid for shipping product"
I would say the difference between a junior and a mid is experience breadth of knowledge. Knowing what tools, patterns or architecture to use and when.
The difference between a senior and a mid, is that a senior knows when NOT to use them.
In other words, juniors and mids tend to focus their attention on technology. Seniors tend to focus on delivery.
A mid-level developer is mostly autonomous within the confines of a planned out project. Given a specific scope and criteria, they mostly get the job done with some help from a senior. Their errors and bugs are typically of the architectural and performance type, though a lack of foresight can plague the less savvy mid-level.
A senior should be nearly completely autonomous. You tell them the general thing that needs doing and they are able to do it on their own. They can see the impact a decision would have far enough down the road to accurately weigh pros and cons. On top of that, they are able to help the mid-levels and juniors get better at their craft as well.
https://www.quora.com/How-do-engineers-get-promoted-at-Googl...
Imagine your company has a programming problems that is a shaped like a vague cloud.
With a junior developer, you need to do the work to dig into the cloud, define its boundaries, segment the work, and write it all up as tickets. Then you give it to the junior dev who focuses on each one independently. They are not responsible for the end result, though they may be asked to verify the parts they coded in production.
With a senior dev you say "solve this problem" and walk away to do other work. You know they can just dig in, figure out the right solution, code it, test it, and maintain it.
To ask your direct reports where they want to be in 5 years and help them get there - without disregard of what that means to the day's need
How far out you can spot your mistakes, and the multiplier affect you have on the people working around you.
> Junior devs use libraries, senior devs write the libraries
Exactly. For company A it means you have 6 years experience. For company B it means you can lead a team and mentor people. For company C it means you know so much about Java you can write the book. For company D it means you can type and open word. Coming up with a precise definition is futile. It is just going to be anecdotal.
It feels a bit like True Scotsman territory.
Company to company the specifics certainly don't hold constant but one could argue that the progression from junior to senior involves more responsibility, autonomy, and accountability at most places.