
What Makes a Senior Software Developer? - beekums
http://blog.professorbeekums.com/2016/12/what-makes-senior-software-developer.html
======
marktangotango
I also had the pleasure of arguing for a team members promotion once. The
domain our team of 5 worked in was pretty challenging (heavy algorithmic
stuff). I spent a year trying to train up my team, and although they improved,
I still felt like I had to do the hard stuff myself. With the exception of one
developer. For example if a project was particularly hairy or the time frame
was too short, it was either me or him doing it. And I couldn't give him all
the hard stuff so I ended doing a lot more coding than I had time for.

I went to my boss and said, X is carrying my team, he does more than any two
other developers combined. He needs a raise, I can't lose him! And he got it.

To me that's what senior boils down, they can do the hard stuff, they keep the
ball moving forward, and not get bogged down in the irrelevant stuff.

~~~
thebent
_" Every measure of a good developer is qualitative. That makes them all
subjective."_

^ This post scratches the surface on a timely and relevant question many teams
face, but the author seems to throw hands up and say everything is subjective.

Our work suggests otherwise: [https://blog.gitprime.com/check-in-frequency-
and-codebase-im...](https://blog.gitprime.com/check-in-frequency-and-codebase-
impact-the-surprising-correlation/)

~~~
ktRolster
If you use a metric like that to affect my pay, I will happily maximize the
metric to ensure I get paid as much as possible.

As a bonus for you, I will also try to write good code.

~~~
wccrawford
So true! I have yet to see a metric that wasn't gamed somehow, even by people
who are generally honest and upright otherwise.

If you base someone's livelihood on a number, expect them to attempt to
maximize that number, probably at the expense of other numbers that you may or
may not be considering.

------
sytse
At GitLab we have the following criteria to be a senior:

Senior Developers are experienced developers who meet the following criteria:

Are able to write modular, well-tested, and maintainable code

Know a domain really well and radiate that knowledge

Begins to show architectural perspective

Leads the design for medium to large projects with feedback

from other engineers

Leaves code in substantially better shape than before

Fixes bugs/regressions quickly

Monitors overall code quality/build failures

Creates test plans

Provides thorough and timely code feedback for peers

Able to communicate clearly on technical topics

Keeps issues up-to-date with progress

Helps guide other merge requests to completion

Helps with recruiting

[https://about.gitlab.com/jobs/developer/](https://about.gitlab.com/jobs/developer/)

~~~
mikekchar
Every team has their own criteria and their own definitions, but I have to say
that this is the level I attribute to an intermediate developer. Similar to
the original article - If I leave this developer alone to do their work, they
will get it done. Honestly, I want every single developer on my team to be at
this level. It takes time to get there, but not an inordinate amount of time
in my experience. Somewhere between 2-7 years, anyway. If someone doesn't get
there in 7 years, then I see it as a pretty big problem.

If you think that my estimate is not totally out of whack, that leaves all
people with a 4 year degree hitting this level before they are 30 (assuming
they start out in this field).

If this is "senior", in what way do you expect your employees to improve in
the next 35 years of their career (assuming they retire at 65)? And what title
would _that_ have?

~~~
irq11
they're cloning github. it isn't rocket surgery. most of the hard technical
work was done by github itself, when they built and released libgit and the
other core pieces of their stack.

in many ways, that's the whole problem with this conversation: coding doesn't
have much room for professional advancement, because 99% of the available work
can be done by inexperienced kids.

~~~
skuzye
I know you are trolling but for the sake of educating both you and someone not
acquainted with Gitlab, they offer:

* CI/CD * Docker Registry * Testing Pipeline * Self hosting option * I'm sure there's more

So I don't think you are being fair here.

PS: I'm not affiliated in any way with Gitlab, just an user

~~~
Tomis02
I'm not sure he's trolling. For the sake of discussion, are the features you
mentioned actually "hard technical work" or is it just work that can be done
by anyone with some experience in that field? I'm not sure how to define "hard
technical work" but I would say that it has more to do with the rarity of
people capable of solving a problem rather than the time it takes to solve it.
That's not to say Gitlab's work doesn't have value, the only question being if
it really falls under the "hard problems" category.

~~~
irq11
I am definitely not trolling. I'm stating an defensible opinion that happens
to be unpopular here.

Arguing that an open-source project is cloning _multiple_ pre-existing
projects doesn't make the software any more innovative.

------
eaq
I like the table that 18F uses to distinguish between the federal pay scale
levels[0]. I.e. Comparisons like

> Your supervisor reviews your work from an overall standpoint to ensure its
> effectiveness in meeting requirements

Vs.

> The results of your work are considered technically authoritative and can be
> used to establish best practices

0: [https://pages.18f.gov/joining-18f/pay-
grades/](https://pages.18f.gov/joining-18f/pay-grades/)

~~~
Matthias247
There were similar tables at a large german corporation I worked for. These
were basically agreed upon with the worker union for the different job levels.
On paper it sounded good, because there seemed to be an exact definition on
what the pay grade for the given job tasks should be.

However in reality nobody cared about this official tables. People were just
promoted when there was money to promote anyone and when there was noone in
line waiting for a promotion in front of them.

------
franze
Junior Dev: knows how to do stuff ... in a way, kinda. Hopefully asks a lot of
questions.

Mid. Dev: Knows Best Practices and how to implement them. Knows what questions
to ask.

Experienced Dev: Understands why best practices are best practices. Can give
insightfull answers.

Senior Dev: Pushes the boundaries of best practices and when to ignore them.
Questions him/herself a lot.

And then there are D. Knuth level developers which I still have to figure out.

~~~
cfontes
This is my current view as well, I just add tests to it.

Junior: doesn't know how to create tests for their code

Mid: Creates the tests but leaves some important parts untested or tests have
bad practices.

Experienced: Creates the right tests but might overdo.

Senior: Tests only the stuff that matters and knows when it's not worth it.

------
alistproducer2
I'm dealing with something similar to what the article talks about. I've been
with my company for 3 years. I wa shired as a "new college hire." I am ~6
years older than a typical grad and had worked in the industry prior to
joining my company.

Ever the course of my time I've:

1\. Learned C# in order to rewrite an app I wrote in Java 2\. Self-organized a
team to implement a UI in HTML/CSS using a JavaScript tool I wrote myself that
allowed different team members to work on components a layout and have the
partials dynamically reconstructed. 3\. wrote a connection pool class in C#
from scratch that has been in production for 2 years without a hiccup.

The list goes on. I suppose I've been rewarded by my manager with substantial
raises and he always says he notices my work but in 3 years the only
responsibility I've had was when I took it on myself to bring coworkers
together to implement the UI (which we delivered in 2 weeks as opposed to the
3 months they had blocked for it).

Am I wrong to feel slighted when far less capable people have been promoted to
leadership positions? My boss does stuff like take me to events where I'll
meet big wigs, but I don't care about that stuff. I just want to be in charge
of producing good, maintainable code.

~~~
click170
> Am I wrong to feel slighted when far less capable people have been promoted
> to leadership positions?

Does your boss _know_ you're interested in a leadership role?

It sounds like you should have a 1 to 1 chat with your boss to express an
interest in leadership roles and to ask what you can do in their eyes to
demonstrate that readiness.

I would also ask yourself what specifically makes the other person less
capable? Speaking personally, I've found that sometimes someone will be
promoted due to better soft-skills and/or project management even though their
technical skills may be below their peers IMO, which in hindsight can - but
not always does - make sense for a management role.

It could be as simple as a misunderstanding where your boss thinks you're more
interested in technical-path career advancement instead of a management-path
career advancement. Since you mentioned that your boss is trying to
acknowledge your work by inviting you out hobnobbing with big-wigs, this seems
plausible.

------
delegate
> You follow your gut. The problem is that this approach can be prone to
> favouritism.

What's wrong with favouritism ? If a person does his job well and helps you
(the manager) do your job better AND you get along well - that's the silver
bullet right there.

Like it or not, this is how groups of humans tend to coagulate. All the other
considerations are secondary.

Promote the ones you personally like (avoid idiots of course). This how you
build a 'gang' of friends and you get promoted yourself.

"Moral Mazes" is a great book which explains the nitty gritty details of
corporate power structures (warning: I quit my job after I read this book!).
It all boils down to personal relationship between people in an organisation.
Technical skills and everything else are complementary but not mandatory
(except geniuses - maybe in 0.1% of the cases).

"Corporate confidential" is another interesting book, which is more about the
HR side of things, but it also gives some pointers about how teams are
assembled

~~~
dpark
> _What 's wrong with favouritism_

Because "guy I like" isn't a meaningful qualification for a senior engineer. I
like everyone on my team. They're not all senior engineers, and I wouldn't
promote them all even if I could.

If you promote someone to senior just because you like them, not only are you
doing a disservice to the company, you're doing a disservice to the engineer,
because at some point you won't be their manager and they'll find themselves
failing to actually work at a senior level.

> * If a person does his job well and helps you (the manager) do your job
> better AND you get along well - that's the silver bullet right there.*

If a person does his job well and helps you do your job better, whether you
want to hang out with them seems pretty irrelevant. There is real value in
interpersonal/social skills, but that's not at all the same as wanting buddies
on your team. If you've got someone on your team that you _don 't_ like, but
they do great work and work well with the rest of the team, they should be up
for promotion before the person you do like who does mediocre work or doesn't
work well with the rest of the team. Being a manager isn't about your personal
wants.

------
muse900
Anyone with 5+ years of writing production code should be a Senior Software
developer.

Then obviously you can say he is an average developer or a very good developer
or a genius or whatever. I don't really get why developers should have
different qualifications than other fields.

If you are working e.g in finance for more than 5 years you'll be prolly a
senior something, what does it matter? Of course then someone can evaluate how
good you are or not at what you do but thats it.

Now what makes a senior developer? Well someone that can take on a project and
complete it from start to finish, for me is a senior developer or developer or
whatever you wanna call it. Its very vague question, usually if you understand
the whole lifecycle of a program and can understand the bigger picture then
you are a senior software developer.

~~~
btdiehr
A lot of people in finance spend their entire life doing the same work over
and over. Same goes for programming. There is more to work than years of
experience. Though no doubt there is a correlation, not everyone gets better
with age.

------
chasenlehara
> _The other problem with checklists is that they only work well if you have
> quantifiable metrics for being a senior developer._

Checklists can combine qualitative and quantitative data in this scenario too:
when judging the experience of a developer, you can incorporate how many times
someone has displayed a quality in your checklist.

I really like Matt Briggs’ take on senior developers:
[http://mattbriggs.net/blog/2015/06/01/the-role-of-a-
senior-d...](http://mattbriggs.net/blog/2015/06/01/the-role-of-a-senior-
developer/)

Once you get a good feel for what qualities you’re looking for, you can
measure how many times someone displays those qualities. When you’re hiring,
you’re depending on the interviewee to show they’ve demonstrated those
qualities; when someone’s been at your company for a while, you might depend
on their team members to confirm whether they’re showing the qualities you’re
looking for.

I think the article is right in saying that it’s mostly subjective, but that
doesn’t mean you can’t break up those subjective feelings into smaller parts
to judge them better.

------
somecallitblues
TLDR: "To me, what makes a senior developer is when you can trust them to get
things done without you."

This is a good conclusion. I've seen people write some amazing code, implement
innovative solutions and build something really solid, but they simply can't
take the customer's requirements and run with them. I have to explain every
single requirement in great detail.

~~~
YCode
That's the definition my work uses.

A critical differentiator is understanding not only the technical side of
things but the business and politics of getting a project completed.

In essence a junior can give you a widget, an intermediate can give you an
application and a senior can give you a satisfied customer.

------
xamuel
An intermediate developer knows how to abstract things.

A senior knows when not to.

~~~
rjain15
:) what about principal developers.

~~~
nowbacktowork
They build frameworks. ;)

~~~
deepaksurti
And they also know when not to build frameworks :-)

~~~
kabdib
Principal devs are about scope, too. So they convince other people not to
build frameworks.

"What are you doing? Stop stress-testing your interface compiler and write
some code!" :-)

------
thefastlane
moving beyond entry-level is about learning to do your job without any
handholding. this usually doesn't take that long.

but any title progression beyond that depends on getting good at navigating
the politics of your work environment. you won't get far without people
skills. banks actually do a good job of mapping out what this looks like for
analysts coming in, in terms of leadership skills etc expected for different
titles. technical organizations, however, tend to leave their staff in the
dark about this sort of thing -- which is a political move in itself, i
suppose.

~~~
mediocrejoker
Can you elaborate on what titles at banks you're referring to, and what sort
of skills are generally expected for them?

~~~
Spooky23
I don't recall the titles, but I remember at a bank recruiting event at my
college they basically laid out the career tracks and were upfront about how
you needed to quack to reach them.

In informal settings, they also talked about other things as well. If you're
driving a civic, you will not be a VP.

------
scotty79
I became senior developer when my financial expectations didn't fit into
regular developer salary bracket at the company that wanted to hire me.

No one has offered me lower position ever since.

~~~
tn13
That is a very honest answer and rings very true.

------
m0llusk
The sombrero indicates a senior developer.

~~~
underikar
That would be a señor developer.

------
tn13
Only if "Senior Software Developer" meant something that is universally
acceptable. In our organization we had a Program Manager who was responsible
for 9 large projects each with several sub-projects. His job was to ensure
they all these projects co-ordinate properly, have sufficient resources and
provide leadership to ensure we eventually have a good cohesive product suite
(thus the Program). Then I met a 20 something kid on flight who was a Program
Manager for Microsoft. He organized campus recruitments or something like
that.

I am small organization. We upgrade titles of our developers almost every 2
years of their service. Why ? Because firstly they all are good and we want
them to stay. Also, if they want to go someplace else we want them to find a
better position instead of starting bottom up again. If a person does not get
an upgraded title we would like such person to actually leave our organization
and find a better fit instead.

If a person is working 2 years and has not evolved significantly in your
organization you are probably running a bad work environment. Asking such
developers to show "Architectural perspective" and "communicate effectively
the technical aspect" is all BS-talk. These developers are not going to work
for 10 years for you, they are going to leave for some other place. There is a
good chance you are losing many good capable people because of this.

------
cerrelio
These modifiers are always a touchy point with me. They aren't applied
consistently and imply greater experience and ability, when they often signify
time spent at a company or political acumen. Over my 15 years in engineering,
I've seen several engineers without senior or lead titles who provide more
value than those with the modifier.

I prefer "staff engineer" for engineers who are capable of producing useful,
working systems with a team. "Lead" should not be a modifier to a title, just
an indicator who makes final technical decisions on a team.

On my resume I only have "software engineer." If I have to negotiate a higher
salary after an offer, I point to my accomplishments and not my title.

~~~
clifanatic
At my last job, my title was "Vice President" (against my preference). There
were five of us. I was Vice President over nobody, and spent all my time doing
the same things I do (programming computers) at my current job with the title
"software architect". If titles didn't used to be meaningless, startup culture
has rendered them so.

------
drawkbox
\- Someone that can get hard things done and ship, preferably multiple times.

\- Someone that can build products that run after ship and be maintained.

\- Someone that can take something from start to finish and make it better.

\- Someone that also knows about business and product side and that is the
ultimate product not just the tech.

\- Someone that has been developing long enough to know that good ideas and
input/feedback come from customers, team members and stakeholders.

------
brightball
Ability to weigh non-technical factors in technical decisions, such as time
cost, cost of technical debt, potential risk and business need.

And the critical skill to go along with all of that is the ability to
communicate those factors to different groups of people as needed.

------
adamlett
The article fails to address the fundamental question: What is the purpose of
the title? Without answering that, any definition of what makes a senior
developer is meaningless.

In my own experience, having worked in consulting, the answer to the question
is that the title enables the company to charge a higher hourly rate for a
particular developer, with the client's understanding that this developer's
time will be worth more, because she is more experienced. If the client
insists that a project should include a certain number of "senior developers",
and if the consultancy is short that amount, then magically the most
experienced junior developers will find the title bestowed upon them.

Outside of consulting, I have a hard time seeing any legitimate purpose to the
title, unless it is formally attached to a bump in salary.

------
bitwize
Look for the gray hair and the world-weary look in their eyes.

------
wellpast
This post self-admittedly fumbles as do many efforts at trying to tackle this
question. The question is wrong: What makes a Senior Software Dev? That's a
_title_ , subject to the vagaries, needs, politics, and culture of a specific
business or organization.

We can and should be more precise. The real question is, what are the
professional skill sets? And what do they look like at varying levels of
competency?

This post reminds me of the famous Joel Spolsky post from over a decade ago
where he says the Senior Engineer is one who (1) is smart; and (2) gets things
done. That's all you need is the gist. But these should be the table stakes,
not the criteria. There's a whole bunch of acquired skills that are missing in
these kind of answers.

It's pretty easy to be smart and get things done. It takes years of practice
to not make a mess of your work. To not build a money pit of a house whose
plumbing is leaking behind the walls, whose structure is buckling. But the
market is so short on these kind of professionals with real skills that we
feel lucky if we've found one who meets this paltry criteria of smart, gets
shit done, makes me not stress when I go on vacation...

------
mcv
A senior developer doesn't even have to be a great programmer. They need to be
good of course; they need to write code that works and is suitable for
production, but I've heard of plenty of excellent, talented coders who can
solve complex problems and rapidly stamp out a prototype, but can't finish the
job, and end up with badly tested, hard to maintain code that still needs
someone else to finish up the loose ends.

On the other hand, a friend of mine recently retrained to become a programmer,
joined a startup where he's clearly the least experienced programmer, but he
is now their lead developer, because he has the right attitude. He's honest
(unlike their previous lead who left a mess) and he listens to to and learns
from other developers, and he can make sure the code is actually finished in a
way that doesn't fall apart when the customer pokes at it. He may not be the
fastest or most knowledgeable, but he does deliver what's needed, and
ultimately, that's what counts.

------
pjc50
I got promoted _en passant_ in my first job, three months after graduating. My
employer was putting together a consultancy proposal including a list of team
members and decided to inflate our seniority...

~~~
fredley
I worked at a place where the developers were all underpaid (due to it being a
'startup', and there being the promise of more down the line...). When annual
reviews came round (after the company posted strong profits), nobody got their
raises, and promptly handed in their notices. In an attempt to scramble to
save the company, management agreed to bring them up to much more reasonable
salaries, but could only do so with a promotion - since the payrise was too
big for the board to approve without one. So everyone in the company became a
senior developer at once...

------
latchkey
Not a huge fan of the blog post as it left things in a nebulous state.

The thought of a senior person being someone who finishes tasks on his/her own
time seems like a bad metric in the world of pair programming. As a senior
developer, I prefer to get input from all of my coworkers rather than work
alone. Two or more minds is always better than one, no matter how senior you
are.

The thought of someone taking on more responsibilities than the rest also
seems like a bad metric. A junior person has the potential to do just as much
as a senior person. It can also create an environment where you are encouraged
to work hard and not smart.

In software engineering, there is always 10+ ways to solve a problem, but
there is typically only one or two actual correct solutions. I like to think
of a senior person as the person who can evaluate all the options quickly and
chooses the right one. This is a skill that takes a lot of experience to
master.

------
amcrouch
I have always worked along the lines of most people here and the article. A
Senior Developer is one that has amassed not only solid development experience
across multiple projects but also has a solid knowledge of your product code
base. Someone that can just get stuff done and leads by example. Applies best
practices and is pragmatic and always add's value to the code base.

I agree that titles are handed out too easily however, developers are partly
to blame here. I have held numerous titles over my career but they are
meaningless. Experience is built over years for learning and applying your
trade and for those that want to continue doing that where do they go after
"senior"? If developer's were not so desperate for the title then this
discussion and the questions being raised would be moot and we'd all be back
coding.

~~~
JesseObrien
I read a great article a few months ago talking about how success as a
developer could be looked at from a more wholistic POV which I agree with
quite a lot these days.

It breaks down the "title" mentality into smaller responsibilities across
three areas: _Technical Skills_ , _Leadership_ and _Community Involvement_.
You can fairly easily isolate what _your_ company values from employees in
these three groups and measure any individuals performance inside each group
to weigh them accordingly. I think it would work very well with peer-review
processes as well.

[http://frontside.io/blog/2016/07/07/the-conjoined-
triangles-...](http://frontside.io/blog/2016/07/07/the-conjoined-triangles-of-
senior-level-development.html)

~~~
amcrouch
That is a very interesting article.

------
blindhippo
A couple metrics I've come to look for in seniors:

\- knows when to push back on stakeholders/management, especially on
technology decisions

\- knows when to adhere to industry best practices, and when to ignore it
because it doesn't apply to the domain/problem at hand

\- fights, strongly, against cargo-cult programming

\- actively seeks to improve the knowledge and skills of his/her team members

\- delivers solid, reliable, working code that can be trusted to work when
they say it works

\- is able to work effectively with peers who they disagree with

Promoting anyone to the senior title when they aren't remotely close to the
bar is damaging to the team and to the company overall. It's especially
damaging since if you promote the wrong seniors, they will effectively put a
lock on the capabilities of your team, preventing team members they disagree
with from achieving the same title, leading to a talent drain.

------
HeavyStorm
How do you buy a car? Do you look at fact sheets and compare, and choose the
one that has the list that fits your interests best?

I hope not.

I buy cars talking to people who own that car. I read reviews. I test drive it
multiple times. I do check the facts sheet, of course, but them I go and see
if it's accurate.

And then I compare. Most cars are identical on the surface, but there are
details - this one has a softer clutch, that one looks better (to my taste),
and that other is said to do wonderful mileage.

I usually end up ranking them, and if they tie, I go for the cheaper one.

That's how you promote people. You take a few, compare them extensively
(talking to others, checking facts, "test driving") and choose the one you
feel it's the best.

So far, so good. The missing point here is WHY promote people. The author
seems to forget about that.

------
ronreiter
For us, a Senior Software Engineer is someone who can finish tasks on his own
and on time, and make good architectural decisions for his tasks.

~~~
charliesome
I think you mean 'their'

~~~
err4nt
I think 'one' would be better than 'their' as one is undoubtedly singular,
where 'their' hints at being plural.

The entire sentence could be rewritten to use 'their', but I think simply
swapping our 'his' with 'their' could change what is being said.

------
lmcnish14
They'll tell you.

~~~
toodlebunions
Bingo.

------
_ao789
I have found it to be often nothing more than just a title unfortunately. So
many developers I work with have the 'senior' title but struggle to do actual
development, often spending most of their time talking or 'pair programming'
which has completely put me off the concept as they hide behind others helping
them all the time but claim they are 'senior' purely because the hiring
manager filled that gap. Pathetic.

------
Francute
The common thing i can see about seniors developers are the length of his
code.

A junior developer doesnt divide too much his code, repeat himself, the avg
length of his code is high, etc.

A semi-senior developer knows how to divide his code, have a good analysis and
design, knows some common patterns, try to have good practices, and repeat
himself a little. (Sometimes takes bad decisions trying to not repeat without
sawing his design) Normally have some methods with too much lines of code but
not too much.

Seniors developers are embrace testing a lot, even test his tests (mutation
testing), are carefull about decisions who impact on architecture, and the
average of the lenght of his code is between 5 and 8 lines of code (and always
simply readable). Cares a lot of dependencies and really knows how to use all
of his tools. Specially when talking about refagtorings. Normally, they loved
the job/books of some of these guys: Robert Martin (uncle Bob), Sandi Metz,
Kent Beck, Martin Fowler, The Gang of Four, Alistair Cockburn and/or Alan Key.

Of course this seems a bit qualitative too, but its like a pattern i noticed.

Anyway, the preferred method here is: Developers categorize others. Between a
team, or a company.

------
roysvork
It's a meaningless term. Senior implies 'qualified' which is not an end-state.
Developers are always learning, our journey does not end.

------
MPiccinato
As always it depends on the organization or team.

I have worked on teams where the title was nothing more than a title and
didn't relate to their skill level or work ethic.

One of my favorite posts on the subject comes from John Allspaw:
[http://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engi...](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/)

An important part of the equation is a companies engineering structure.
Camille Fournier has a great set of slides about creating structure earlier
rather than later and why it is needed:
[http://www.slideshare.net/CamilleFournier1/how-to-go-from-
st...](http://www.slideshare.net/CamilleFournier1/how-to-go-from-
structureless-to-structured-without-losing-your-vibe)

------
CSMastermind
For me it's pretty straightforward:

Dev 0 - For companies that hire college graduates. A developer fresh out of
college who has a lot of theoretical knowledge but not practical knowledge.
They might still be learning the tools of a professional software developer
(source control, testing suites, the debugger, building and deploying
environments, etc), technologies (Linq for .Net, Angular for a web dev, etc),
techniques (dependency injection, how to write clean code, the value of good
logging, etc.), and/or how to operate in a professional environment (stand-
ups, interacting with coworkers, dealing with having a manager, etc.)

Junior Dev - I expect you to have learned the things listed above. You should
be proficient in the language or framework. You should understand the software
development process and reliably write "good" code. Meaning correct,
efficient, simple, readable, and maintainable. Junior developers are still
learning design, architecture, domain knowledge, and when to break "the
rules".

Senior Dev - The best way I can explain what I look for is, "I can give them
any assignment and trust they'll get it done, well, with little to no help
from me." Set it and forget it. Domain knowledge is underrated as a skill but
it's a super important one. A senior developer should know the 'gotchya's of
the particular type of software you make. (If you make billing software they
should have a cursory knowledge of accounting as well as compliance issues).
The code they write should account for not only the particular module they're
working in but the system as a whole. It will follow best design patterns, fit
inside of our architecture, but won't be so dogmatic that it sacrifices
performance or maintainability. You should be able to stay in the senior role
for the rest of your career if you want.

\----

As concisely as I can put it: new hires will as you how to do something.
You'll need to ask junior devs, "have you considered..." Senior devs you don't
need to think about at all.

\----

Careers diverge after the senior dev level depending on your preferences. If
you want to stay pure technical and just write code all day some companies
offer an independent contributor or technical expert role. If you really like
the design and framework aspect of software you can move into an architecture
position. If you want to explore management you can move onto technical lead
which is a pseudo-management position.

------
raz32dust
The question "What Makes a Senior Software Developer?" would only make sense
given the context of what grades of engineers are present in a company. The
definition will be different for a company with just 3 levels compared to one
with 6 levels. I side with more levels. This is because, while we may argue
that a "senior" engineer should have these 10 qualities, an engineer with 6 of
those qualities is still better than one with just 2 of those qualities. So it
makes sense to have the engineer with 6 qualities at a higher level than one
with 2 of those qualities.

The question then becomes what are these N traits of a good engineer. The
whole process of promotion and "senior"ity is irrelevant to that discussion.
And I think most people here would already agree on those traits.

~~~
IndianAstronaut
>would only make sense given the context of what grades of engineers are
present in a company

I'm at a major bank and the senior and principal title gets used a lot for
devs that are clearly in junior or mid level roles.

~~~
_ao789
I couldn't agree more with this statement. I contract for numerous banks and
find myself dealing with many "senior developers" who clearly have no idea
what they're doing. It seems to be more of an ego thing as opposed to a
capability bettering. I even have a "senior developer" who currently sits
right next to me who falls under this "problem group".

~~~
IndianAstronaut
I hope that's not me...I have a senior title and I _know_ I am not at a senior
level.

------
jonstewart
I disagree with the article. Perhaps I'm too strict of a grader, but a
developer who meets the qualitative criterion here--essentially, a developer
you don't have to manage much--is not yet a senior developer. She is on her
way, but to me the distinguishing factor is the extent to which the developer
can mentor junior developers.

If a developer meets the criterion of TFA, then she helps her manager grow the
team linearly, as the manager can then focus more on others. But if a
developer can effectively mentor junior developers, then the team can scale.
This is not to say that a senior developer must be a "manager", but a senior
developer not only understands the importance of craft and can practice it,
she helps apprentices appreciate the craft as well.

------
alkonaut
The definitions will vary, and imho even having these titles is useless. If
you don't know who is senior without having to print it on business cards you
are in trouble. To me being a senior developer means, when faced with a hard
problem I prefer to

\- not solve the hard problem. Make it go away instead. \- buy an existing
solution to the hard problem. \- make a simple solution to part of the hard
problem

Making a "simple solution to the whole hard problem" is of course the end
game, but most of us never reach that level. Seniority is basically just a
measure of battle scars and cynicism ("experience" also a nicer ring than
aggregated cynicism).

------
khazhou
I always use the simple rule: Senior means you can finish a complex task on
your own, without being told how to solve it.

Of course, now we have to define "complex", but the salient part is being able
to work independently.

~~~
TheOtherHobbes
One small addition: you _can_ do all the work on your own if you have to.

But you also know how to delegate it to a team to get it finished more
quickly. And how to keep the team on track so technical debt is minimised,
while reliability and user usefulness are optimised.

Really, there are two definitions and two different skill sets.

One is "competent experienced professional developer". The other is "competent
manager of other developers."

------
alfredxing
Similar discussion from a couple of months ago:
[https://news.ycombinator.com/item?id=12603303](https://news.ycombinator.com/item?id=12603303)

------
brudgers
The programmer competency matrix:

[http://sijinjoseph.com/programmer-competency-
matrix/](http://sijinjoseph.com/programmer-competency-matrix/)

~~~
AstralStorm
As worthless as any. How do you apply it? Which items are arbitrary and which
are necessary?

------
SatvikBeri
I use several levels for my team (1 is a new grad, 3 is somewhat experienced,
5 is senior, 7 is principal.) When evaluating someone, I rate them on 4
competencies (which depend on the exact role.) If they're currently being paid
at level n, but the average of their competencies is >= n+1, I recommend a
raise.

This approach still involves some subjectivity, but I find that it avoids many
of the problems, such as not properly rewarding people who are fantastic on a
few dimensions and weak on others.

~~~
lostcolony
I think it would depend on what those competencies are. Is it possible to be a
7 in two, and 2 in two? Because then by your criteria they'd not even be
senior, even though in half the specified areas they are the best you could
have.

~~~
SatvikBeri
That's theoretically possible, but in practice the biggest gap I've seen is
when someone was a 6 in one and 3 in another.

I work at a startup though, where I need everyone on the team to be something
of a generalist. If I was working at a larger company that benefited more from
specialists, I would use a different scheme, e.g. dropping the lowest score or
something.

~~~
lostcolony
Do you think that might be self selection bias then? You might be able to
benefit from one or two specialists, but if you even make them an offer, it's
as a 4 (or whatever), but another company might be willing to make them an
offer as a 6 or a 7, because they have a place for specialists. Not that
that's necessarily a problem if you do indeed need generalists, just an
interesting possibility to think about if you ever find yourself needing
specialists.

~~~
SatvikBeri
I use this framework for giving raises/promotions/feedback to existing
employees, not for new hires. With actual employees you have a lot more
information, so I believe companies should generally hire cautiously but give
promotions and raises aggressively (most do the opposite IMO.)

I did actually have a case similar to one you described, where someone was a
very advanced specialist in a narrow area, and relatively weak in others. I
was willing to make him an offer at a 5, another company hired him at a 7. I
think that was the best outcome.

In another, less extreme case, we used to have one "data scientist" role. We
found that this required too much breadth, and people with the same role ended
up doing very different things. So I've advocated for separate "data analyst"
and "data scientist" roles, each with their own set of 4 competencies.

------
poorman
I've recently been looking into this topic. Sales teams have fairly straight
forward metrics for measuring performance as they can track calls made,
revenue, etc...

Developer performance metrics are not as immediately obvious. Can anyone
suggest some reading on the topic? I'd love to know how managers are tracking
developer performance.

------
ausjke
It means you need know how to architect, integrate and hack/debug/write/patch
whatever software, in the meantime you also need to do bitwise and shift of
integers, balanced binary tree algorithm algorithms fast. The former you need
for the real work, the latter you need for interview. You need cover both
ends.

------
Teichopsia
Could someone lay out what is, and the difference between a junior(beginner)
and an intermediate developer?

~~~
rjain15
I would say if the programmer can show progression in coding, design and
independently working on modules they can move up the junior, intermediate,
senior ... ladder

~~~
Teichopsia
Then knowing algorithms and data structures would be intermediate -> senior?

~~~
phamilton
Algorithms and data structures are correlated but not causal.

Do they build things that work well and are easy to maintain and scale?

Rookies tend to make, well... rookie mistakes. N + 1 problems, O(n^2)
algorithms, etc tend to creep in. This could be as simple as a missing index
in the database.

Intermediate avoid the rookie mistakes, but design for the problem at hand.
Their foresight is either lacking or they overbuild. Either way, new
requirements often lead to being painted into a corner.

Senior developers try to minimize regret. They don't build unnecessary
features, but they keep future requirements in mind.

This isn't an exhaustive description, but I feel it underscores why data
structure and algorithms matter. Persistent data is probably the hardest to
adapt to new requirements. Knowing how to structure data so that it can be
accessed properly is a huge part of the difference.

~~~
Teichopsia
Thanks. I was wondering at what level I could be considered. I'm still a
rookie :)

> but design for the problem at hand.

Could you elaborate on that part?

~~~
phamilton
Suppose I need to track whether items are in a processed or unprocessed state.

The intermediate developer would create a boolean field on the item, allow
constant time lookup on that flag so we can easily fetch all unprocessed
items.

A Senior developer would recognize a few core assumptions that would make the
boolean field a problem. (1) It assumes there are only 2 possible states (2)
It assumes that an item will only have one state at a given time. They would
seek out ways to relax those assumptions without increasing complexity. They
would likely use an Enum with two states rather than a Processed boolean. That
would remove the first assumption with an almost negligible cost. As far as
the second assumption, they might decide the cost of removing that assumption
is too high compared to the likelihood of it mattering.

A month later, we have to track which items are assigned for processing. The
intermediate engineer has to invalidate a previous assumption and convert the
field from boolean to enum. The senior engineer just adds an enum.

A month after that, we find out we need to track multiple assignments. Both
engineers have a lot of work to do (you can't win them all).

That's the difference I frequently see. Senior engineers can see problems down
the road and recognize their implicit constraints. They aren't always right,
but more often than you'd expect some decision they made pays off.

~~~
AstralStorm
A senior developer would also know to not use an enum instead of boolean when
not useful and just wasting performance. (because Java and C# make you pay a
lot for abstractions you don't use)

What you described is an intermediate programmer trap. A senior programmer
would make a design easy to refactor if such a change is needed, but not pay
the unnecessary cost up front.

~~~
phamilton
First, it's hard to come up with useful examples on command. :)

Second, I was thinking more at the data persistence level. Which is harder to
change than a simple refactor, and depending on the data store has zero cost
(for example in MySQL booleans are just ints). They might then treat it as a
boolean on the application side if there are indeed costs there.

Either way, a Senior programmer has that conversation and recognizes the
potential costs down the line. Then makes decisions about the tradeoffs.

------
lucb1e
Sorry for off topic, but this text is illegibly huge. It reads nicely after
zooming out until 50%, or at least 67% (though that's still a bit big). I
think 55% or so is close to the text size that my task bar, tabs and hacker
news also uses.

------
sbensu
Another essay answering the same question: [https://hackernoon.com/senior-
engineers-reduce-risk-5ab2adc1...](https://hackernoon.com/senior-engineers-
reduce-risk-5ab2adc13c97#.oebwciiom)

------
limeyx
To me, the chain from developer to senior to lead to principal etc is mostly
driven by the desire to change from being "reactive" to "proactive" and
offloading other people (higher and parallel etc) in the chain.

------
hunterloftis
Nobody wants junior engineers (or: get "senior" in your title as soon as
possible):

[https://www.youtube.com/watch?v=ccxrFmIEAmQ](https://www.youtube.com/watch?v=ccxrFmIEAmQ)

------
ChicagoDave
A senior software developer is one thing.

A person that voluntarily and passionately stands in front of a project to
ensure its success and has the capability to do so.

------
cdevs
In my area it's 10 years of experience and can lead a team or you work like
you've had 10 years of experience and can lead a team.

------
kensai
I really like the "Software Inc." simulation's approach. Looks awfully lot
like real life, although it's a game.

------
NTripleOne
If my current employer is anything to go by, absolutely nothing - at least,
nothing that differentiates them from junior devs.

------
earthly10x
When they understand the difference between software engineering and software
development.

A senior software developer understands what it means to scale and align
software engineers, as a unit or team. This along with understanding that the
code is not what matters but rather what the algorithmic design, innovation,
invention or discovery that can be done with a particular language or code (or
notation in mathematics or music).

~~~
mathgeek
That sounds more like the difference between an engineer and a developer.

------
omouse
0\. someone who stands up to management.

------
aryehof
Ideally real experience, but often just longetivity.

Competence and good communication skills assumed.

------
jpkeisala
Senior by definition means older person. I might be wrong but in other than
software industry Senior usually means 20+ years experience from the field? I
think person than is valuable for development perhaps should be called
something else if s/he is young?

------
chx
I have already made the mistake you are about to make.

------
known
You write less code and debug more code.

------
BJanecke
it depends

------
Noseshine

      because 99% of the available work can be done by
      inexperienced kids.
    

Now spend some time thinking about the qualifications necessary for commenting
and where you stand in that field, and what's the difference between what you
produced and what a Senior Commenter would produce.

~~~
irq11
Are you seriously suggesting that a senior person wouldn't use the words
"inexperienced kids" to describe inexperienced kids? Or are you just trying to
make a low-brow insult look intellectual?

Come on. Being "senior" doesn't mean that you start blowing smoke to please
random strangers.

~~~
Noseshine
I am seriously suggesting that a Senior Commenter would produce more
intelligent and more enjoyable content compared to the no-effort nonsense you
managed to come up with.

Have a nice day.

~~~
dang
This sort of uncivil comment will get your account banned on HN, so please
post civilly and substantively from now on.

~~~
Noseshine
Don't pester good contributors like me needlessly with childish and useless
threats (my comment history is open for all to see). You can tell that to the
OP (as you already did). My reply is not "uncivil" but perfectly appropriate,
and my comment history suggests you are doing yourself no favor
indiscriminately throwing ban-warnings around.

~~~
dang
No doubt most of your comments have been fine, but "the no-effort nonsense you
managed to come up with" was a breach of HN's civility rule. The commenter you
were replying to broke the rule too, but under such conditions we need to be
_more_ civil, not less, to avoid a downward spiral.

------
fdsaaf
I'm going to take a different tack: a senior developer is a developer with
enough experience that if you subject her to the bullshit processes that work
on lower-level developers --- things like scrums, status updates, architecture
reviews, and other command-and-control measures --- she either performs badly
or quits.

Developer seniority is developer autonomy, and autonomy must be matched to
skill level and scope.

------
m23khan
The answer is simple: a software developer classified as 'senior' by the
Government (e.g. age of 65 in Canada) :-)

