
Ask HN: When are you considered a “senior” programmer? - lollipop25
I have been doing web development for as long as I remember. I get by with tools that are needed for the job. I don&#x27;t fancy the new and shiny. I just get things done fast and done properly.<p>But I feel like I&#x27;m always a step behind the rest. There&#x27;s this guy in the team knows how to operate Amazon, or this guy who that knows how to use Spring, or this guy that knows how to scaffold a Java app in minutes. Sure, I can write in the Java language but I don&#x27;t know Spring by heart. I can build and run containers, but I don&#x27;t know how to launch them in the cloud.<p>When is one considered to be a &quot;senior&quot; developer? Is there a means to measure where I am? How do I get there?
======
misframer
I really liked this comment by @stray [0] from a similar Ask HN from a few
months ago. That thread was titled "Ask HN: What makes a Senior Dev".

    
    
        Mistakes, rewrites, late nights, firefights, and deadlines.
        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.
    

[0]
[https://news.ycombinator.com/item?id=11341567](https://news.ycombinator.com/item?id=11341567)

~~~
anexprogrammer
There was a question a week ago about junior developers.

mrmekon [1] gave an excellent answer:

It depends on when and why I'm defining it, but my guidelines are more based
on how they work than what they know:

* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.

* Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals.

* Senior developer - Will produce immediate business value if completely ignored.

The domain and language don't matter for these, really. A Senior Go developer
is going to produce immediate business value if you suddenly throw him/her
into a Lisp team, too. Just slower.

Between the two answers I think they have it covered. Now some businesses will
_call_ people senior after they've been there 5 years, but they might still be
a junior in capability.

[1]
[https://news.ycombinator.com/item?id=12557542](https://news.ycombinator.com/item?id=12557542)

~~~
oldprogrammer2
This is very much the perspective I have taken over the years. When I'm hiring
a senior developer, I'm looking for someone who will step in and own the
project they're given. If I had to pick a single expression, especially one
recognizable to this crowd, I would say it is someone who can execute. I also
tend to view senior developers almost as internal consultants (good ones)
because they should be willing and able to step away from they keyboard and
talk to a stakeholder to discern what the business really needs without
needing someone else to act as an intermediary.

Where I do disagree just a little bit with mrmekon, is that I tend to look for
people who have experience with the necessary stack. I would be hesitant to
hire a senior developer for a C#/MVC position if they have (broadly) never
used C# or never done web development, for example. Modern stacks have a lot
of moving parts, and I would prefer senior developers to understand how to
troubleshoot, tune, upgrade, test, and deploy on the needed stack. These are
things that a very strong developer could remediate within a few projects,
though, which is why I only slightly disagree with mrmekon.

~~~
rufius
With regard to your last comment about hiring senior devs with experience in
the stack: I would say it depends on what you're hiring for and your long term
vision for your team I think.

In my team's case, I was hired to do ML/BigData but had no prior experience.
My boss's philosophy is that he wants smart engineers with a desire to learn
more than he wants area experts. He's been burned more than once with area
experts who were unable to pivot well with the shifting priorities of the
team.

That said - if you're hiring someone to come be your ML expert then that
requires an expert. Tech stacks are less that way in my opinion and they're
rarely static. Even the debugging and troubleshooting tends to be similar if
you know the problem space.

------
jkingsbery
As others have said, if you're asking about the title specifically, it depends
on the company. I was one of those "Senior" developers when I was in my mid
twenties at a start-up, whereas for my current company it's actually pretty
hard to get the title "Senior Software Development Engineer."

My experience is generally the people I recognize as having deserved the title
don't _simply_ just code. Not only do they write code that works and delivers
the feature in a timely manner, they make it so the next 3 features to come
out in that area can be done quickly by junior developers. Not only do they
code, but they make everyone around them better coders. Not only do they code,
but they also think strategically about what the team needs to keep going two
years from now. Not only do they deliver the project, they get everyone
excited about delivering the project.

I once read someone say "there's a difference between having ten years of
experience, and having the same year of experience ten times." Time is a
factor, but it's also whether you've exposed yourself broadly and deeply to
new technologies, approaches and experiences so that when you are in a new
situation (technical or otherwise), you have patterns for how to deal (or the
self awareness to know that you don't know how to deal). So, part of it is
time, but part of it is spending that time wisely.

~~~
imaffett
I'll second this. Titles vary across company size, and even then are different
from company to company (e.g a Principal Engineer at Intel would not make PE
at Google). I was a Staff Software Engineer at Intel (level above Senior
Software Engineer) but now my title is Senior Front End Developer at a startup
;)

------
lmilcin
I think that people emphasize knowledge too much. I think knowledge is a by-
product of making senior developer.

Senior developer is about wisdom as opposed to knowledge. Juniors may learn
things quickly, but what distinguishes senior is that you can trust them to do
the right thing which is not always technical problem.

I like to compare this to asking children a question that they don't know the
answer to. Some children will feel they have to come up with some answer and
some will say that they don't know.

Junior developers too frequently feel pressured to produce a result and they
don't see how saying that they don't know something is making them closer to
producing anything. Senior developers know from their experience that this is
just as important to know when you don't know something as it is important to
know things. They will not feel too bad about not knowing something because
they know the alternative is even worse.

------
astdb
One aspect that would separate a 'senior' engineer from the rest would be
initiative, leadership and mentoring ability. These are the engineers who go
the extra mile to ensure that the team gets stuff done, and assistance and
guidance is provided where required. A senior developer isn't just someone who
knows a lot of stuff, but has a time-honed wisdom as well, which they can
parlay into their leadership and mentoring duties.

~~~
bbcbasic
I like your definition because it is timeless and rings true. The same
definition will apply in 10 or 20 years time when there are new fads in
development processes, programming languages etc.

I would add that the senior engineer has a mature approach to
selecting/recommending tools and frameworks, based on what is most valuable
for the business and the team, rather than was is cool, good for their career
or whatever.

~~~
CaRDiaK
"selecting/recommending tools and frameworks, based on what is most valuable
for the business and the team" This is so true, I would say it extends to
style amongst other things also. Having worked seniors on teams who had to
seemingly make problems "worthy" of their skill and time served. For example
working on a large OO Monoliths where a senior started to add lots of "clever"
functional code. When I started the question the reasoning behind it I got a
lot of instant defensive flack off them because "it's a better way" and "I'm
arguing against correctness" they didn't seem to want to understand that we
had 50 mid level to junior devs who also had to support this who would require
a lot of help to read or follow it, thus slowing the entire team. They didn't
seem to care for the reasoning of it being better "for the team" to just carry
on with the agreed OO standard.

It's not that I thought they were wrong in what they had to say, just there is
an appropriate time and a place and being able to make that call is just as if
not more important than the style of functionality being added. I find such
seniors can be toxic at times. In essence there is more to being a senior than
just being a great coder.

~~~
merb
> For example working on a large OO Monoliths where a senior started to add
> lots of "clever" functional code.

Adding a simplier design with functional code is a good thing. If there is a
mid level developer that can't follow the current state of the art, than he is
not a good mid level developers. Also "good" junior developers have mostly
zero problems in understanding more functional code. I mean you don't need to
understand Applicative Functors to use map/flatMap.

I mean there is a line which you should not cross too fast when introducing
functional stuff, however most people just don't even try to understand the
simple stuff even that it is way more simple than most while/for loops.

~~~
Nemcue
You need to realize most mid- and junior programmers simply aren't good.

~~~
marcosdumay
And that means _they_ aren't good, not that the person using good practices
isn't good.

If it is a business requirement that good developers must be slowed down for
bad ones to catch up, then do it by encapsulation and mentoring. Not by
decreeing that good developers must act exactly like bad ones.

------
TurboHaskal
When you are valuable and ask for a raise but they cannot give the amount
expected because it's already Q4 so they give you the senior title instead.

It can happen even with two years of experience.

~~~
wvh
That's also my experience. "Senior" is little more than a random title in most
companies I worked for. It can be someone in their early twenties who just
happened to have worked for 2 years on one product, even if it's their first
job. It's frustrating at first to join a new company as someone who is older
and has many more years of experience, then you remind yourself it's just a
random title and try not to get hung up over it. Like many symbols of status,
it's a pretty empty shell.

If someone like Donald Knuth would be forced due to economic circumstances to
join a trendy web start-up, he'd be a junior working under a twenty-something
senior with little more than some Javascript and MongoDB knowledge. The whole
thing's silly, really.

~~~
Shanea93
Anecdotally, I feel like this is how my older peers see me.

I've been working (professionally) in this industry since I was 16 years old,
I got my first job as a junior after tinkering with computers since I was 8
years old. At the age of 23, I've found it very difficult to earn the respect
of the people around me because of my age.

I have the title of senior developer because I've had experience working on
scalability issues and complex service based infrastructures, but many of my
peers who are my age and recently graduated university and are still in their
first junior roles often act like I haven't earned it - despite me graduating
with a part-time degree in software engineering (okay, it's not computer
science, but I'm still glad I did it.)

My point is that while age is generally a good indicator of knowledge and
ability, it's not the be-all-and-end-all.

~~~
rafaquintanilha
Curiosity: are you from US? Is software engineering seen as less valuable than
computer science? I'm asking this because for me software engineering is a
more complete discipline and would encompass pretty much everything computer
science does.

~~~
justinlardinois
In the US, degree programs actually called "software engineering" are few and
far between; most software engineers who are college educated have a computer
science degree.

It's also worth noting that the term "software engineer" isn't regulated here,
while other engineering titles are.

~~~
pitaj
> term "software engineer" isn't regulated here, while other engineering
> titles are

No they aren't. Unlike in Canada, you can give yourself any title without
actually having a license in that profession, as long as you aren't being
fraudulent in your claim.

~~~
justinlardinois
According to Wikipedia, some US states regulated some engineering titles. It's
not really specific but here:
[https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...](https://en.wikipedia.org/wiki/Regulation_and_licensure_in_engineering#United_States)

------
captn3m0
>The final stage of programmer evolution is the Finder. These folks are
considered experts in their chosen domain (and are prudent about others).
Writing Finder job descriptions is an exercise in futility. As my boss put it:
“I can’t tell you the specifics of what you’ll be doing here because your
first task will be to figure that out.” A Finder will be able to anticipate
problems before they happen, usually because they’ve been in that situation
before.

From [https://rkoutnik.com/2016/04/21/implementers-solvers-and-
fin...](https://rkoutnik.com/2016/04/21/implementers-solvers-and-
finders.html), which is a really great read.

~~~
Terr_
Reminds me of Cringely's metaphor of "Commandos, Infantry, and Police" [0].
Not quite the same, though: The military analogy assumes that there are a
fundamental tradeoffs between strengths and weaknesses (esp. getting-it-done
vs. doing-it-right.) In contrast, it looks like "Finders" aren't described as
having any particular weaknesses relative to Implementors.

[0] [https://blog.codinghorror.com/commandos-infantry-and-
police/](https://blog.codinghorror.com/commandos-infantry-and-police/)

------
peterkelly
It's a pretty arbitrary term, but based on what you've said, especially _" I
don't fancy the new and shiny. I just get things done fast and done
properly"_, would be enough for me to label you a senior programmer.

Our industry is _way_ too obsessed with fashion... sooner or later you realise
that most of the "new" stuff is largely existing ideas re-hashed in a slightly
different form. Senior programmers realise this and can pattern match to
understand the role of various new technologies, and learn the details _if and
when necessary_.

How do you get there? You already are, you just don't realise it yet.

~~~
DSteinmann
> but based on what you've said, especially "I don't fancy the new and shiny.
> I just get things done fast and done properly", would be enough for me to
> label you a senior programmer.

I think that's wild speculation. That phrase could mean a number of things.

It could mean they engage in the industry, explore new technologies and make
educated decisions which balance the risks associated with adopting new
technologies and, in some cases, choose to use technologies that are fit for
purpose but are not necessarily bleeding edge.

On the other hand it could mean they have failed to keep up with technological
advancements and are using the wrong tools for the job, tools that can't
deliver a modern web experience. He might be churning out shocking legacy code
that someone else will have to clean up one day. Perhaps his employers are
none the wiser and don't realize a different developer could deliver a better
quality product in a much shorter time using the tools available today.

Given OP's examples of not knowing "Amazon" or Java Spring, both of which are
ancient technology in web years, I would speculate the OP might fall into the
latter category. Another strong indicator of this: OP has been doing web
development "as long as [they] can remember". You'd think his coworkers or
employers would have told him he was a senior developer if he hadn't figured
it out himself.

Overall, insufficient information in the OP to make an assessment, but I would
be very wary of pandering to someone's ego as it can do more harm than good.

~~~
vacri
"done properly" means not taking the shortest, technical-debt-laden path to
success (amongst other things). It's a hallmark of a senior, in my opinion.

Also, why would you know Amazon operations stuff if your job duties don't
expose it to you? The OP was saying 'operate Amazon', not 'use Amazon APIs'.

------
jobvandervoort
At GitLab we have a formal definition for senior engineers [0] (where we
accept merge requests, of course).

1\. Technical Skills a. Great programmers: are able to write modular, well-
tested, and maintainable code b. Know a domain really well and radiate that
knowledge

2\. Leadership a. Begins to show architectural perspective b. Leads the design
for medium to large projects with feedback from other engineers

3\. Code quality a. Leaves code in substantially beter shape than before b.
Fixes bugs/regressions quickly c. Monitors overall code quality/build failures
d. Creates test plans

4\. Communication a. Provides thorough and timely code feedback for peers b.
Able to communicate clearly on technical topics c. Keeps issues up-to-date
with progress d. Helps guide other merge requests to completion e. Helps with
recruiting

[0]: [https://about.gitlab.com/jobs/developer/#senior-
developers](https://about.gitlab.com/jobs/developer/#senior-developers)

~~~
kewpiedoll99
I like this a lot. It's organized and measurable. Follow-on question, how do
you get there?

As an aside, I often feel that being senior involves _confidence._

------
edw519
Whatever it takes to best satisfy your customer. That's it.

No, I'm not being snarky, so hear me out...

I've met and worked with many developers over the years and lots of them have
become very good with technology and user domains, but still have struggled to
"crack the digital ceiling". These are brilliant people who have achieved
serious things, but are still not recognized by the big decision makers as
"senior", whatever that means.

Then there are a select few who always get the big gigs, big money, and big
reputations. Why? Because they best satisfy their customers. There are lots of
non-technical skills that help them, but I think the biggest is their ability
to separate the signal from the noise and zero in of the most important things
to work on and to get them done. It's almost like they have "satisfiability
radar". And this rarely requires any special technical or people skills. All
they really have to learn is a good grasp of the technology, a deep
understanding of the customer's domain and business, and the ability to get
things done through others. And how did they develop them? By good old
fashioned grunt work, whether digging into the bowels of the system or getting
up off their butts and relentlessly going around finding out whatever they
needed to know.

Once you've figured out the best thing(s) to work on to best satisfy your
customers, got them onto the decision makers' radar, and found a way to get
them done one way or the other, you are no longer a dev or even a senior dev.
You're now a digital rainmaker, the most senior dev of all.

~~~
ryandrake
Many companies have a separate "Product Manager" role for that business, so
that the brilliant engineers can brilliant SENIOR implementors. Have a
dedicated professional worry about the customer impact, product requirements,
etc., along with other non-programming tasks that many developers
understandably prefer not to get bogged down in.

~~~
angelbob
They do. But separating those two roles and having two different people make
those decisions tends to result in less-than-optimal decisions. It's the same
kind of problem as "let's have the tech done by engineers and the business
done by business people," and then your business gets bulldozed by a
competitor whose CEO _does_ understand engineering.

------
scotty79
I became a "senior" when my financial expectation were higher than the maximum
salary of non-senior developer at a company that tried to hire me.

They were forced to offer me position of senior developer and no other company
after that dared to offer me lower position.

------
Steeeve
My personal definitions:

Junior: Can do it with guidance and/or clear and non-transitional specs

Developer: Takes the ball and runs with it. Can walk a customer through
requirements gathering and make recommendations. Will help guide junior
developers.

Senior Developer: Can architect a system well. Can communicate equally well
between executives, salespeople, management, and end users. Can and will
mentor lower level developers. Can explain concepts on the fly to lower level
developers and walk them through the development process in terms they
understand. Takes initiative at learning new technologies.

~~~
voltagex_
> Can walk a customer through requirements gathering and make recommendations

Well yeah, I can do that, but isn't that normally the business analyst's job?

~~~
pjc50
Change it to "can walk the business analyst through requirements generation
etc"

(Yes, I am currently frustrated with our product management)

------
gibb0n
1) When you drop everything you are doing to mentor other developers

2) When you get asked by the business to do something you question what they
are asking and the motivation, and then determine the best course of action
based on their motivation rather than delivering the specific task they asked.

That's it really, it's nothing to do with your coding ability but more to do
with your mentoring ability and problem solving skills. This is what is
valuable to your colleagues and the business. Any answer related to coding
ability is missing the point, it's important, but after a few years most
people are the same programming level - it's just some people can help at the
team or business level which is what makes you senior.

------
intellectronica
A "senior" is a someone who provides about 10X in value and earns about 2X in
salary :)

More seriously, except for very big and very hierarchical orgs where tenure is
overly important, people will tend to give you the senior title when your work
is indispensable. To be indispensable you don't need to know by heart this
technology or the other - you need to identify what are the things that bring
the most value and work hard at delivering them.

------
jakecarpenter
To me, it is about what they are able to create independently, and the value
of the end product.

Senior people have made the right mistakes, wasted weeks of time, and know
what to avoid, what to embrace, and what to ignore. A senior dev can
understand the requirements and figure out what is important and deliver
something without a lot of external input.

~~~
zamalek
> Senior people have made the right mistakes

This really sums it up, _almost_ every other answer could be seen as a
consequence of this.

~~~
qznc
Do you have to make the right mistakes _yourself_?

~~~
rbanffy
It helps with getting the muscular memory in place.

You can learn from other people's mistakes, but the pain you feel yourself
will make you never forget it.

------
robotnoises
Fun story, I just found out yesterday during my annual performance review than
I am a Senior Software Engineer. No, not a promotion, but rather I have always
been one. It was simply an HR mistake that my title did not reflect it and no
one realized that I didn't know.

So to answer the original question: it is impossible to know.

~~~
jajern
Or, rather than have to give you a promotion HR said, "hey, let's just make
them think they were always a Senior Engineer this whole time!"

------
kasey_junk
None of those things sound like things I correlate with being a senior
developer. Knowing any particular set of skills isn't what I look for anyway.

To me the things that make a senior developer are: 1) you give them a project,
even an ambiguous or large ones, and expect it will work out fine. 2) they
have been around enough different situations that they likely aren't going to
be thrown for a loop by new challenges. 3) they mentor their fellow less
senior developers.

To get there you need 2 things: 1) bare time, you just _have_ to put in the
time 2) variety of projects - if all you have is a bunch of time on the same
problem you are unlikely to have developed the breadth of knowledge you need.

------
amcrouch
To me the senior title should be applied depending on the way you approach
your role and not how you code.

As others have mentioned as a senior you can be left to implement changes
without guidance, you will clean up issues as you come across them instead of
leaving it to others, you suggest improvements, you make time to mentor and
guide more junior members of the team, you know how to relate to muggles and
you act like a team captain.

Knowing lots of different hosting environments and languages comes with
experience. The approach you take to your role show's your all rounded skill
set.

------
mmirza984
Well usually companies have their own view on seniority, and it could include
how many years you have been there, but for what its worth for me a senior
developer is a person who has experience with all stages of application
development, which should imply that she/he can: \- design and understand
client/server architecture, \- write code using best practices that is clean
and maintainable, \- knows database design and programming \- understands
design patterns and knows how to not abuse them, \- knows how to deploy
application and has experience with CI. \- knows how to write proper unit
test.

To sum it up I will use .NET as an example, in my eyes when someone says I am
a senior .NET developer I assume that she/he has: \- used UMLs, \- knows how
to write proper OOP and understands SOLID, \- can use MS SQL and some kind of
ORM, \- uses some of the testing frameworks (e.g. NUnit), \- knows how to
deploy application whether on IIS, or install it with ClickOnce for example.
\- know how to handle source versioning (TFS or whatever is your poison)

I probably missed a few things, but that's about it for me. If a senor doesn't
have these skills I assume first that she/he has great knowledge of company
business which would make her/him a valuable asset, or that she/he got lucky,
or it's a crappy company :)

~~~
rjbwork
>\- used UMLs

Like unified modeling language?

~~~
mmirza984
Yes, UML diagrams. One should be able to read and understand them.

~~~
FLUX-YOU
How hard is that to learn though?

That seems like a fraction of the cost it takes you to learn OOP/SOLID/etc.

~~~
mmirza984
UML is pretty straight forward, and I rarely saw it being used in companies
because of many reasons (spaghetti monster being the one :D), but I mentioned
it because I'd expect that one showed now how to read them, since you will
find them in literature (if you read any book on design patterns they are
there).

------
philbo
This is kind of tangential, but a couple of jobs ago I decided to actively
purge all job titles from my CV/resumé. Officially, I'm currently a senior and
have been in the past, but there have also been jobs in between where there
was no "Senior" prefix in the title.

My main problem with thinking about developer roles in this way is that
there's obviously no standard for what constitutes seniority. It varies
between and sometimes within organisations. Advertising it, glorifying it,
striving to achieve it, all take the focus away from far more interesting
things that you can say about yourself and aim for.

Are you working on interesting projects? Are you learning new stuff? Are you
being challenged technically? Are the other people on your team good
developers? Do you enjoy what you do?

Seniority as an end in itself seems like a hollow objective to me. And making
a big deal about it in a recruitment context takes the focus away from more
meaningful topics.

------
jkot
In my experience:

\- you are technically competent

\- can handle design aspects of full stack (backend, persistence, frontend)

\- have enough credibility and confidence to say NO to business people

\- you can lead a small team of developers (2 to 5 people)

~~~
klibertp
> \- have enough credibility and confidence to say NO to business people

This is the most important part. Other points you mention are about your
skills and you can _learn_ them. This one, however, is in major part about
your reputation, which you need to _earn_.

Going a step further, I'd say you're a "Senior" as soon as people around you
start to treat you as one. You can be very knowledgeable but that won't be
enough if you can't _prove to others_ that your knowledge is _relevant_ and
solid.

------
source99
Check out this recent thread:
[https://news.ycombinator.com/item?id=12557149](https://news.ycombinator.com/item?id=12557149)

------
wmu
I like this joke: A junior programmer thinks he knows everything. An
intermediate programmer thinks he knows nothing. A senior programmer hates
computers.

> But I feel like I'm always a step behind the rest.

Don't look at things in this way, low self-esteem is the worst you can get.
There are always people better than us, but their skills and knowledge weren't
conjured up. Even extremely talented people need time to learn. And if you
don't feel like learning new things may make you better, why to feel guilty?
If you're not a Java programmer, why to feel bad because you don't know Spring
or other details perfectly? You wrote you do things fast and correctly. So
you're better than, say, 90% developers who work slow and produce crap. :)

------
aburry
I would say it is about sphere of influence. Are you inward looking and
focused on developing your own competencies? Junior. Are you mentoring people
on your team? Intermediate. Are you providing direction for the company or the
industry at large? Senior.

------
z3t4
I would consider you a “senior” programmer? Mainly because you know that you
do not know much. While a junior or intermediate programmer think they know
everything. There are of course more to it, like when you are stuck on
something; you ask the senior programmer, that will probably have solved it
ten times in the past. Or if you want to know what the best method is to do
this, you ask the senior programmer, that have done it hundreds of times and
thus found out the optimal way, with all edge cases included. So I would say
it's mostly about experience, and then expertise. Also, a senior programmer
should have gone though at least two paradigm shifts.

~~~
zumu
I'm interested in this 'two-paradigm shifts' rubric. Could you elaborate?

~~~
z3t4
Programming languages and best practices evolve. For example object oriented
programming, functional programming, goto instructions, global variables,
include files, module systems, classes, template languages, PHP, MVC, XML,
JSON, unit tests, test driven development, Git, JavaScript frameworks, SQL,
noSQL, sequential, asynchronous, multi-threaded, etc.

------
SpendBig
Being a senior developer is not just having a great skillset. You need to be
able to manage your work in a way the business values it. You need to interact
with all sorts of people in the company you work for and help other
teammembers rwaching the same level as you.

Our senior developer is always thinking about the business value when
estimates are made vs quality. He even does not do alot of softwae
development, but is always asked to help out other developers, system
engineers and even management to give advice.

To be able to do that in a professional way, your vision plus skillset makes
you a senior imo. Not just the years of experience and amount of skills you
have.

------
BurningFrog
It's mostly just a title on a business card and/or org chart.

Some times it's given to people instead of money.

Don't worry about the title. Worry about getting good at what you do, and an
asset to your team and organization.

------
dvcrn
I'm also agreeing with leadership and mentoring. Be able to make unbiased
technical decisions, troubleshoot systems / apps and get up to speed on new
projets independently fairly fast. Have confidence in what you do and don't
ask about everything.

A solid general code understanding is also needed in my opinion. This includes
things like using documentation over googling everything. If I pair with a
senior and he types "golang how to do x" on every problem, I probably wouldn't
consider him senior. (Not saying googling is bad. Just don't be a copy-paste-
from-stackoverflow engineer)

With that, I also hate the term "senior engineer". I got friends with 3 years
of work experience that are now "senior" because a company hired them under a
senior position (basically more salary) and the companies after that just did
the same because "well he already is a senior, right"? This also generates a
strong in-balance inside the team with a hierarchy that shouldn't be there. I
am usually advocating for getting rid of job titles and calling everyone just
"Software Engineer"

I am now 6-7 years into my career and don't consider myself senior. When
people in interviews ask me what my career goal is, I usually mention I want
to be able to consider myself senior as the next step.

~~~
croon
> Have confidence in what you do...

Heed your own advice. You might not like the current system of hierarchy,
that's fine. And change it when/if you get the chance.

But in the meantime, don't abstain from senior positions (and salaries) that
others get just because you don't like a concept. Play inside the system until
you can change it.

~~~
dvcrn
> But in the meantime, don't abstain from senior positions (and salaries) that
> others get just because you don't like a concept. Play inside the system
> until you can change it.

Oh yeah, I don't. I am also applying on "senior" positions, but this is just
my personal opinion on when I would consider someone / myself truly senior.
Paycheck and job description aside.

------
gambiting
I work at a major games company. For us, a "senior" is someone who can, on
their own, design, implement, document and maintain a feature. An
"intermediate" is someone who can do the above but with mentor help from a
senior.

Above that, it depends what you want to do. If you fancy managing people, you
can be a team/tech lead, or if you don't, then there is the title of
"expert"(only a handful of programmers who worked here 10+ years have those).

~~~
sjclemmy
I quite like that definition. It's based on the ability to independently
deliver value.

------
fowlerpower
I think a senior engineer has to know a few things.

They have to have the basics we all need as engineers simply to pass the
interview process. The data structures and algorithms, Big O and be able to
walk through systems they have worked on in the past and the trade offs they
made and why.

Then on top of the basics I look for a few more things. Usually the
understanding of multi threading, multi process, asynchronous programming is
very different between junior and senior folks. I dive into distributed
systems and see if they have any exposure. I dive into multi paradigms and how
deep their knowledge is in their respective toolset they have listed on their
resume.

I don't necessarily think you need to know multi threading in and out, or
distributed systems in and out, or your tool set in and out. You certainly
need to know one or two of those though. You need to have some body of work
you can speak very well to, this is a huge indicator of seniority. Mentorship
and all the other things that go with that help differentiate as well between
junior and senior.

I don't think there is a hard rule anywhere. Different folks will look for
different things and at least where I work those things I listed are very
important differentiators.

------
ilaksh
When they have to pay you more than the junior devs. Note that isn't
necessarily because of skills or knowledge.

------
ta998877
This is by far the best article I've ever read on the subject.
[http://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engi...](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/)

------
mping
Depends if its senior with a specific technology (ex: senior rails programmer)
or generally senior programmer.

I consider senior someone who: \- knows how to mentor juniors \- knows his way
around tech, even if he never used a particular product \- most important, can
communicate effectively with stakeholders and devs.

The best "senior" is the one who nags everyone to get stuff moving forward.
Doesnt mind getting his hands dirty and going by people's desks to make sure
the team delivers.

You may need to brush up your marketing skills in order to promote yourself as
senior. Don't get impressed by people that know stuff.

------
ghuntley
Leadership and mentoring. When they can write great documentation (without
prompting) and
[http://softwareleadweekly.com/](http://softwareleadweekly.com/) becomes their
favourite weekly read. When they come to you with improvements outside of the
technical domain on how to improve shop and even better when it's just a side
chat about what they have already improved and what went well, what didn't and
what they learned (self-awareness). When they stop treating promotions like
mechanical checkboxes.

------
chx
Sr can tell to jr: I have already made the mistake you are about to make.

------
k__
In Germany this isn't a thing, but when applying for a few jobs in the UK most
employers considered me senior after that interview. Still didn't get the
jobs, because I failed their programming tests.

Since I started programming my work-behaviour changed from asking people all
the time when I don't know what's happening to reading their code.

I think developers are considered senior if they can work on their own.

Like, if you get all the engineering practices of designing, implementing and
maintenance done without much help.

------
jwaldrip
A senior developer doesn't say things like "I don't know how", they simply
figure it out and do it. A true senior developer is fearless, but also
pragmatic.

------
vassilevsky
When you learn Erlang.

~~~
bshimmin
Do you become a lead developer when you've mastered K?

------
stevesun21
I think a lot of programmers stucked into programming language/framework trap
– keep learn new lanaguages and new frameworks to make yourself believe you
have more exp, but this just make your skill more like learn drive different
brand cars. Even myself in this trap for really long time.

The true power to make you senior is how you train your brain to think and
abstract. This will boost your capability of design rather than just coding

------
partycoder
Engineer seniority has a lot of variance. Some do it based on years of
experience, ranging from 5 to 10 years and that would differ from company to
company.

In my understanding, a senior engineer is an engineer that can contribute
without the need for technical supervision.

Now, not requiring supervision is different to leadership. A senior engineer
is often an individual contributor, not necessarily a team technical leader.

------
aisofteng
Based on my experience at about five different successful companies, a senior
engineer is not someone who has a title declaring them as such but is a person
you go to when considering something completely new that needs to be created
from scratch because you know he could do it if asked to, do it in a way that
will leave something another team can pick up if necessary, and do it well.

------
jjn2009
I read some where the definition to be as a software engineer who's primary
role is to reduce risk. This sounds like a solid benchmark to me since this
usually entails that although you may not have a lot of knowledge about the
latest JavaScript framework but instead have deep cs fundamentals knowledge
which would allow you to mitigate software risks in most environments.

------
christouphair
Assess the new and shiny technologies and learn the ones that seem promising.

1 year later new and shiny will become the standard, there will be thousand of
beginners and you'll be one of the few "senior" developers on that technology.

Of course you'll already be learning the new and shiny that will become the
standard 1 year later.

------
noonespecial
Skill is knowing how to operate Amazon, "senior" is knowing when you probably
shouldn't.

------
_Codemonkeyism
As a CTO or team lead senior programmers to me were those who understood the
business and the businesss side of things and could make trade offs (beside
the technical experience).

Another aspect that seperates seniors is their ability to talk and present to
senior or top management.

------
sakopov
In my experience a senior developer is someone with 10+ years of experience in
architecture and development and a pretty vast amount of accumulated
knowledge. There are exceptions of course, but this seems to be fairly
standard in my market in the Midwest.

------
Prad
Senior developer is just very difficult to define. You could define it based
on the amount of time worked at a certain job, your skills, your ability to
mentor. The definition could be different for various businesses and their
employees.

------
Nursie
When you have to talk to a customer.

Seriously, I worked for a place where thay was the rule.

Titles are somewhat meaningless. Apparently I'm a consultant these days...

------
chrisseaton
My very first developer job after graduating was a 'senior member of technical
staff' so who really knows.

------
sigi45
You have seen a few projects and different teams. A few years of practical
experience is necessary.

------
ohgh1ieD
I guess ... Once you realise that you don't want to be a senior or a developer
at all.

------
DracheZahn
When you salary demand exceeds the threshold of a standard programmer.

------
squozzer
Senior = most senior dev in the building. AKA Designated Survivor.

------
known
Depends on % of code you reuse.

------
balabaster
You will never have enough time to learn everything and be all things to
everyone. Get this idea out of your head right now or you will never find
happiness.

Senior is the difference between keeping your eye on the big picture and
helping to move your team forward to the objective in a timely manner to
achieve the business objectives that drive the company forward. It's the
ability to step up and lead your team when called for. It's the ability to
make decisions balanced between what's technically right in the short and
longer term without losing sight of the end goal.

Never forget that you're not paid to deliver software just to deliver amazing
software. The software you deliver is a tool, a means to an end. That may be
to cut costs, it may be to increase profits, it may be the lifeblood that your
company's stock price hangs on.

A junior developer may be amazing with the tools provided and may have some
good architectural sense. They may need some, or a lot of hand holding. A
junior developer generally has their head in the code most of the time and may
but probably shouldn't be expected to understand or care about the objectives
of the business as a whole. You give them a feature to develop and can largely
expect that they will need all of the dependencies to hand. They may have a
good handle on debugging and unit, integration and functional testing or this
may be something they need to learn. This is OK.

An intermediate developer can be given objectives regarding code and
architecture and left to their own devices and trusted to deliver on their
objectives in a timely manner. By this time, you should expect to at least
understand the business objectives and be able to think critically about the
code they're providing in order to meet those objectives. I would expect an
intermediate developer to have enough of a clue about architecture that handed
a feature requirement and some architectural direction for how to integrate
it, they could architect it competently and integrate it and know where to go
to ensure any dependencies are satisfied. They will have a good handle on
debugging and at least unit and integration testing. They may have a good
handle on functional testing and debugging production code.

A senior developer is someone in my mind who who can be trusted with the
business objectives, can chase down architectural advice, from an architect or
UX input or whatever else they need to get the job done; they can communicate
effectively with stakeholders and the business; they can be expected to dig in
and fill any gaps that would prevent delivery or cause problems in production.
They can delegate pieces appropriately and deliver what is expected in the
allotted time frame. They may be someone that can step up as team lead/team
manager, or lead from the back and be the glue that gives the team cohesion.
They can be expected to have the discipline to take care of things properly
when nobody is watching. They can be expected to help debug production issues
and be among the first to muck in when the shit hits the fan to help resolve
production issues.

So you see, the difference between junior, intermediate and senior doesn't
have an awful lot to do with code or tools. You will expected to either be or
become a master of your tools whether junior, intermediate or senior. You will
be expected to do this on the fly, on the job, regardless of everything else
that is going on around you. This is part of being in this industry. You will
be expected to keep up with the codebase and dig in and understand it at
whatever level you're at. These are all prerequisites for your job as a
developer, they are not a prerequisite for your title. There's a big
difference.

If you want to make the jump from junior to senior quickly, here's my advice:
Find the most gnarly difficult problems your company is having and dig in and
help solve them consistently. When you've put yourself through the wringer;
when you've suffered the late nights, the stress, the anguish about whether or
not you've got what it takes to do this job. Do this until you get to a point
where you think you've seen every last problem that could possibly occur, and
despite that, something else hits you out of left field and knocks you clean
off your feet. Do this until when this happens, you just get back up and keep
going. When you get knocked down and get back up when everyone else would say
fuck it, when you can be trusted to make shit happen when everyone else would
say fuck it - this is when you can call yourself a senior developer.

"Out of the 39 000 men and women that make up the United States Coast Guard
there are only 280 rescue swimmers. This is because we are the Coast Guard's
elite. We are the best of the best. When storms shut down entire ports, we go
out. When hurricanes ground the United States Navy, we go out. And when the
holy Lord himself reaches down from heaven and destroys his good work with
winds that rip houses off the ground, We. Go. Out." \- Ben Randall, The
Guardian

Live by example.

------
pastorelli
When you can build and operate a multiple-cloud system using only assembly and
gwbasic...

------
navyad
sometimes these title can be dangerous.

~~~
Grangar
Why?

~~~
tinix
I don't know what parent was thinking of... but titles, to me, are dangerous
because titles are not used the same between one organization and another, and
expectations and assumptions as to the proficiency of individuals may not be
met solely based on title alone. Titles can also be dangerous because people
who are undeserving of them think they know everything... when in reality they
don't know shit. Especially when someone is given a higher title in lieu of
higher compensation, when the title may not even be deserved. I've seen
"senior software engineers" that can't even write consistently styled code,
full of off-by-one bugs, and other noob shit. And I've seen "junior
developers" run circles around them. It's all subjective... Titles are
bullshit, basically...

------
anonymoose321
After 60?

------
supercoder
When someone gives you the title.

