Hacker News new | past | comments | ask | show | jobs | submit login
What Makes a Senior Software Developer? (professorbeekums.com)
536 points by beekums on Dec 12, 2016 | hide | past | web | favorite | 238 comments

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.

"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...

Im currently working on performance optimization. Often my job is days (even weeks) of running tests and reading metrics, followed by a 5 line change one day that significantly speeds things up. This is one reason why metrics cant hope to capture everything. Maybe its not all subjective but a lot of it is - especially for more senior people, its about how much contribution they have to the overall business goals rather than any data you might find in the codebase.

Ofcourse there are people who do this much better/faster than me, but the nature of the job still means the actual code output is pretty low.

I can imagine many other functions where code output is super high (adding lots of text of any kind - blogs, templates, new library/config) or super low. I don't think code output correlates well to productivity.

I have a longstanding suspicion that these issues are why there are so many different 'measurement' structures for programming, which don't ever converge to a few winners. I totally believe the GitPrime result is accurate, but my first thought was "I wonder which teams this doesn't apply to?"

'Programmers' is a coherent grouping in terms of "people who write code as a job", but it doesn't generalize well to "people whose daily work is similar". At the extremes, it's a bit like calling a typist, a copy editor, and a poet all "writers" because they produce text. That's a useful grouping when you're designing Microsoft Word, but it's a lot less useful when you're judging everyone on "lines written today". (I worry that there's a value implication in those three careers, and it's not intended; I just wanted vastly different daily workflows.)

And so the GitPrime result seems useful to know about, but there are clear cases like yours where its inapplicable. I suspect it would also run into issues with things like embedded or critical-failure code - NASA's commit patterns might have nothing in common with the industry standard. Even in my largely standard work, I realize that of my last two projects, one had ~50 commits and the other had ~3. The 3-commit one was a tech-debt project with lots of reading and documentation work, and I'm skeptical the two are at all comparable.

Even within similar work, I imagine things like branching strategies and test coverage alter commit frequency. For the near future, we'll probably continue to see the value of a given assessment stay company-and-role specific.

My entirely subject opinion.

Those that self-identify as programmers may or may not be current HS or undergrad students. They often know a single language moderately well, maybe a second. Though they know the language, they often don't know what is available to them in the language of choice's standard library, so they often fall victim to re-inventing the wheel.

A developer has a few seasons under their belt. They may know several languages, and even have a fair grasp upon what the standard library of those various languages offer and so less likely to reinvent the wheel (although they still sometimes do). They're more likely to have a larger toolbox and decent grasp on when it's reasonable to use a certain tool (language or framework to tackle a new problem).

An Engineer is more likely to involve tools to solve problems. Got a performance problem? Going to profile instead of running by gut feel. If your company can afford it, vTune is a great tool here. Engineers are more adapt and comfortable using tools such as gdb, valgrind and strace on Linux or say Windbg on Windows. Bonus: they usually don't need to refer to the manuals to specify the correct commands or interpret the results. This doesn't come from accident or pure reading - you have to have real world practice and experience to know when and which tool is appropriate for the problem at hand.

The Senior Engineer knows all of the Engineer as I've briefly outlined above, but also takes the time to teach/mentor/coach the juniors around him or her when they see room for improvement in the junior. And this should not be in the form of "you're doing it wrong, do this instead", but there should be a "why" component in the "you're doing it wrong".

Your description of senior engineer fits me reasonably well - eight years experience, have had 'senior' in my title for the last three jobs, routinely teach the people I'm working with - but I identify as a programmer, not an engineer, because there is no such thing as software engineering, and if by some chance there is and I've missed it, I'm certainly not doing it.

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.

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.

If you use a metric like that to affect my pay, I will go find a different job, where I am treated with respect.

Gamification at its finest. I copmpletely agree with you. :)

“to affect my pay” ← totally agree with you here.

This is a big part of why we think engineering metrics are a tough nut to crack: there’s a fair bit of research that suggests tying KPIs to compensation is a huge anti-pattern for certain types of work (chiefly those involving lots of novel problem solving).

Highly recommend Daniel Pink’s “A Whole New Mind” on this topic; it’s pretty fascinating stuff.

Highly recommend Daniel Pink’s “A Whole New Mind” on this topic

Correction, the Pink title I was referring to was "Drive: The Surprising Truth About What Motivates Us"

Pink does a great job unpacking research that demonstrates how this type of 'affect my pay' dynamic backfires for engineering.

Reminds me of a good essay - "You are what you measure"

I agree with the overall message of the post but not the analysis behind it. It depends completely on the codebase and where you as an engineer are assigned to work in that codebase. There's so many potential ways for bias to be introduced into that kind of analysis (e.g., what if I am a junior dev assigned to copy edits to the static sections of the website?). There's a qualitative perspective to commits that's going completely ignored in this post.

This ties into what I was talking about above with respect to "heavy algorithmic stuff". Most developers can work with intricate legacy code by adding an if here and there to handle special cases. Very few can recognize that it's encoding a state machine with state transition function Y, and rewrite it. Even then, very few have enough 'attention to detail' to do the rewrite, and NOT lose any legacy functionality. This is an example of what I consider to be 'hard stuff'.

This is why I like when people contribute to major open source projects - chances are good they will be exposed to some of these hard problems, which can help them solve future ones.

@debaserab2 100% agree, well said.

Engineer happily using GitPrime here. After sitting in on a Skype session we had with your team once upon a time, I took your earlier (pre-Impact) observations on the correlation between commit volume and overall performance to heart and consciously focused on chunking my work more. It will come as no surprise to you that this strategy's helped me stay consistently in the upper right of the 2x2 chart. Thanks, Ben!

> I took your earlier observations on the correlation between commit volume and overall performance

What does this mean? The best developers tend to have the most commits?

I can believe that there's _some_ correlation.

From what I've seen, a high frequency of commits means either:

  - Has very little understanding and churns out code one day and removes it the next.
  - Thinks a lot about their code, and divides them into digestible, independent chunks.

So it correlates either to a lazy developer or a really good developer? That isn't much of a correlation.

It's some correlation, and it's more useful than the full spectrum.

Ah nice, @Eiriksmal — 'once upon a time…' and 'pre-impact', sounds like this was a while ago now :) Encouraging to hear that this has been helpful for you.

This is really interesting, thank you.

It's one of the only clear-metric breakdowns that actually makes sense in light of my programming experiences. I'm hesitant about the idea of using it as a management tool (easy to game, and high commit count or even 'high impact' isn't proof of quality). And, as some other people noted, it's quite role-specific - a performance engineer's commit count won't be comparable to a line engineer.

But as a personal insight, or a mentoring tip? This seems excellent. I know I want to write good code, I'm not going to game my personal metrics, so a clear guideline like "break up code more" is a great thing to have.

@Bartweiss thanks for the feedback. The thing about “gaming the system”, is that it presumes an adversarial relationship between engineers and non-engineers. That’s pretty unfortunate, and it’s our view that a good portion of this is due to non-engineers not really understanding what happens software development.

But yeah, my co-founder has a pretty interesting take on gaming the system.

TL;DR: So, can you game the system? Absolutely. The point is to game the system: https://intercom.help/gitprime/general/cant-you-just-game-th...

Thanks, that was a great quick read.

Adversarial work does seem like it's largely a sign of communication breakdown. I think 'gaming' isn't always as adversarial as it seems, though. I was considering it in terms of Goodhart's Law, where even with good intentions, representative metrics become less representative as you organize around them. The "active days" entry in your link seems like an example; if everyone pushes most days for the sake of pushing, then active days isn't feedback on programmer skill.

Of course, your link touches on that. "Everyone pushes every day" is a great outcome, even if the metric is no longer clear. The common trend is to pick good metrics, then struggle to keep them relevant. I really like the alternative of just setting metrics that will be good after people optimize.

The other side of this is it is likely if the engineers are optimising for a metric that is important enough to be tied to compensation, the companies' non-engineers are likely to place a high value on that metric too, exacerbating the issue.

This is a situation where I feel gaming the system is not an inherently adversarial relationship.

Love this, in my experience also, good programmers make a lot of small commits. While less experienced people do ocasional commits regardless if they are big or small.

Something your chart doesn't show is people who make a lot of commits/work but the quality is subpar. They behave as prolific programmers but still need to improve.

Thanks for checking it out @gaastonsr — yeah, you make a great point. we've figured out some ways to account for that in the software itself.

surely this assessment introduces false positives? Someone that implements a poorly specified feature exceptionally well suffers rework, not because their code is poor but due to outside factors. Someone who cherry picks easy items is reflected as prolific where a perfectionist might just be given more difficult problems.

Idk, I worry that people will interpret this backwards and rather than having characteristics of a good developer ape those characteristics to appear as a good developer.

I think Goodhart's Law is in effect here.

As a management metric, I would find this concerning - perverse incentives and false positives all over the place. But as a personal observation, I'm going to take it to heart.

This (like most other metrics) seems most useful from a starting point of "while doing my daily work and seeking to write good code, I will apply this". That doesn't make a good tool for deciding who's talented, but I'm still going to remember it.

Whatever you measure, when people know it, will affect how people act. People will try to move the needle in the direction they see profitable, even unconsciously.

That's actually fascinating. Is the formula for the mentioned "developer impact" a hush-hush trade secret, or can you go into more detail on how you calculate it? Would be really interested in hearing more!

@shandor — yeah, there's some secret sauce happening in that impact metric, but this post breaks it down so you get a sense of how it's calculated and how teams are using it: https://blog.gitprime.com/impact-a-better-way-to-measure-cod...

The danger of developing a qualitative metric for work/job performance, is you now have a recipe to game the system for anyone that is so inclined. Of course, if this metric is used as an indicator for promotion and raises, nearly everyone will be inclined to game the system.

It might not even be as overt as that. It is a well known phenomenon that what you measure, you improve.

So as soon as you have a quantitative metric for work performance, almost by definition, it can become problematic to use, unless you are very careful how it is used.

This is not to say that finding a qualitative method is useless, far from it. It can lead to valuable insights and improve overall quality of the team/business.

Oops messed up my qualitative and quantitative. All references should have been "quantitative". This is what happens before the first coffee!

You guys maintain an excellent blog - I would really like to keep up-to-date, but I don't want emails sent to me.

Can you guys supply an RSS feed link? If you have one, I wasn't able to find it.

@cbcoutinho appreciate that. i think this should work: https://blog.gitprime.com/rss.xml

Nice article indeed, thanks for sharing. I'm currently struggle to go from perfectionist with low frequency to high frequency.

I've also noticed that experienced programmers do their commits more frequently and they do the right job - they spend less time on unimportant details.

It also depends on the codebase. A programmer who works on similar codebases for 10 years is more likely to have a high impact than the one who work less and consider these codebases rather new. While their approach and skill set may be similar.

Quantitative information can only ever be used to inform qualitative valuation. It should not be absolutely linked (in other words, you should not make hire/fire decisions solely based on metrics of any sort). Your work is definitely interesting, though.

Note that every metric can be gamed, by the way.

So you are not measuring the value delivered by the developer or his team to the business, but rather the amount of work done.

What was the dataset you guys used? Was it open-sourced or closed source?

So you're basically in agreement with the post - "To me, what makes a senior developer is when you can trust them to get things done without you. "

That's the general industry definition. Here's the ones I've learned (I have a CTO title, but I don't believe it is well issued)

Junior Developer isn't an insult, it's just someone who may need about 1/3 of your time to showing them around.

A "Developer" without Junior or Senior should require 1 day out of 14 for advice/assistance.

A Senior Developer should only require assistance when the building is on fire.

I can see where you're coming from but personally I don't like the idea of grading the seniority scale equivalent to how much help you need/ask for. Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process.

In my mind the difference between a junior developer and a senior developer is the ability to recognize tasks/issues and accurately prioritize them in alignment with organizational objectives. In particular I've found that when left to their own devices junior engineers tend to focus on irrelevant items and metrics such as lines of code or genericness for genericness' sake where senior engineers target important bugfixes and features that bring highest benefit to the company and customers. There are parallels with this statement and the premise of the parent comment but I think the latter draws with too broad of a brush.

> Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process.

Intellectual strength isn't the same as senior developer. There might be correlation but it's probably not super strong. I agree that someone not asking for help is definitely junior. But I might also argue that someone who does need to ask for help probably isn't as senior as you seem to think they are.

In an ideal world, this is probably the case. Unfortunately, there are a lot of non-ideal codebases in the world.

Even the worst developer can eventually develop fluency in a poorly-designed codebase and seem much more competent than they actually are, compared to a new hire.

I think grandparent meant specifically taking the CTO's time, not a peer's time.

A lead developer starts the fire by gathering kindling.

A principle engineer invents new kinds of fire.

"Do people want fire that can be fitted nasally?"

(Douglas Adams, https://books.google.co.uk/books?id=YKHJ6WQKD3YC&pg=PT142&lp... )

And someone in AWS gets the 2AM pager wake up call.

Kindle. Fire. I'll see myself out.

Product manager calls for more wood.

Sales figures out how to pitch the fire as a feature.

Lawyers provide a solid defense from the locals who for some reason don't enjoy being neighbours of the new wood-burning power plant.

That metric strongly discourages asking questions - which is a critical part of a Senior Engineer's job.

When someone is at the level of SE, they have proven they have skills beyond slinging well-formed code - that's entry stakes for second-tier. They demonstrate a wider understanding of how their work fits into the overall product development, an understanding of customer perspective, and many other attributes. Most if not all of these derive from knowing the right questions to ask, the right people to ask them of, and the right time to do so.

The biggest differentiator is that the Senior developer should know when she needs to ask questions to proceed.

I disagree. I think everybody needs assistance every now and then, and it's important that you will ask for assistance when you need it. I strongly prefer a programmer who asks for assistance over one who will get stuck on his own for days or even weeks.

But a senior will definitely ask when he needs help, and won't wait until someone comes to him. And even without the right help, he'll still figure out some way to move forward. Usually, he can figure out his own problems while also offering assistance or guidance to others.

I can't quite put my finger exactly on what it is, but it feels like there's a difference between the kind of assistance that a senior developer asks for and the kind that a junior developer requires.

I mgiht guess that a senior developer asks for assistance when it will save them time - they could work it out, but it'll be more efficient for everyone involved if they get some assistance - whereas a junior developer would be lost without it.

I think the difference is that a senior developer will ask for help when it is a multiplier on productivity, whereas a junior will ask/need help when it is a linear gain in productivity (ie the difference is knowing how useful that help will be).

To some extent, absolutely. A junior is more likely to not know where to start, or to get stuck on a wrong path. A senior is more likely to need someone to bounce architectural ideas off, or some pointers on how to get started with some new technology.

But ultimately, anyone can get stuck hunting for a typo causing an inexplicable problem. Sometimes you just need someone to explain your problem to, just to help your own head to solve it.

> A Senior Developer should only require assistance when the building is on fire.

Senior developers require assistance all the time. Once problems are complex enough there isn't much that can be done as a solo ninja.

By that definition I should have been a senior dev when I was 22 in my first job

Well, there's also a difference between "able to solve a problem" and "able to solve a problem correctly, in ways that won't cause future pain". The latter one is the only one that can be trusted to work on a problem themselves.

That said, it's totally possible you were there, yes. The pacing of promotions vs the abilities needed for them are not always correlated appropriately.

Some people are senior when they are 22. Some people are senior when they are 44. Some people are never senior.

Age is not a good predictor.

So basically there is no way to ever become a senior developer if you work for a control freak micromanager.

Leaving and being hired as a senior may be the easiest way out.

Yes, Dice.com / Glassdoor.com / Linkedin.com

I wish this happened more often in companies. Unfortunately I usually see the following happen.

A mid-level developer, let's call him Dave, becomes a critical employee after a few years with the company. He silently become "senior" without anyone really asking him to. Other developers notice this and often come to him for help. Management, however, doesn't notice, because nobody in management is exposed to Dave's actual contributions to the team. All they see are completion metrics – story points, etc. – and a project moving forward. Dave is too humble to point out that he did 80% of the work, and he doesn't have regular meetings with his supervisor anyway, so the subject would never come up. After a few years with the company, Dave gets bored and finds another job.

The company now has to pay recruiting costs and the ramp-up time that comes with a new person on the team. Dave, meanwhile, gets what he wanted – a promotion, and a higher pay check. The company could have saved money by giving Dave a 20% raise and a promotion (even a nominal promotion, to make him feel valued) but the management structure wasn't there.

This is how it normally goes, and this is exactly why there is such a short length of tenure in the tech industry compared to other industries.

What would you have done if he didn't get the raise?

This is a great story by the way. For me this is a good way to keep your staff loyal while signaling to others that they aren't performing up to snuff while not making it completely awkward.

It looks like: we are dependent on this guy, we need to raise him to keep him with us. I can't see a company rising someone just because he "deserve" it, the company don't wanna spend more money if not necessary... IMHO.

I think that that criteria heavily leans on an assumption of the quality of the other engineers on the team though. If there is a team composed of 4 engineers who are in the bottom 10% of performers in the company, it won't be hard for them to see a very mediocre engineer as a "senior" because that person does so much more than they can; yet to the other 89% of the company, it's absurd that that person would be considered a senior.

Granted, many would say it's equally absurd to have so many members of the bottom of your engineering talent on one team, but I've seen it happen over and over again in real life.

"Carrying the team" certainly seems risky, and calls to mind the endless problems of Microsoft's stack ranking (especially the fights to get on a team with losers to "fund your raise").

I do think that the self-directed criterion is an excellent one, though. With that standard, you could promote an entire team if they're doing good work, or have non-senior engineers stretching up into your top decile. That makes the 'senior' title a clear assertion of "can handle these tasks without substantial oversight".

I think it's a mistake to think that developer ability is static, "quality" isn't a constant thing, by any means. Certainly we're supposed to keep learning and progressing. But there are plateaus. For example, I don't think myself or the person I championed for the raise/promotion were exceptional, it was simply a situation where what we were doing really "clicked" with both of us.

Later on, I had a member assigned to the team. They were going to fire this person, but asked me if he could have a chance on our team. I said sure. Turned out that this person needed a bit more guidance than they had received before, and when they got it, really began to shine. This person went from almost being fired to being a really valuable contributor on our team.

Myself, I left that company long ago, looking back I think it was a high point of my career. Never before or since have I had that level engagement with the domain or company.

But normalizing a developer's performance across an entire organization is no easy feat. If the subject is performing well enough under the role and team he was placed, then he probably deserves a promotion.

> 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.

How much was the raise?

Because giving 10% is easy. But when it comes to giving 50-100% there is suddenly zero support from the organization.

Only in dumb organizations.

I transitioned away from engineering to data science in 2008. FreshBooks took a risk on me but they obviously were going to pay me as a junior data analyst.

I got 2 bonuses and 2 real raises in a year and a half because they could tell I was drastically improving my skills and had much more of an impact than they had originally anticipated.

If your organisation can't identify who is making a difference and do what it takes to keep them, then they're not going to win. That being said, most people asking for a 100% aren't being realistic.

Well. 100% is a tad high. I find 50% to be incredibly common.

It's not enough to identify the "talent". You have to identify it AND admit that you failed at identifying him earlier AND admit that other companies will poach him if you don't try anything AND you gotta know market-rate right (it can be really hard to find out, even for recruiters in your companies) AND you need to actually pay market rate (most companies don't) :D

By the way, if you get 2 bonus and 2 raises, if likely means that you were incredibly underpaid and it's possible that you still are.

>you need to actually pay market rate (most companies don't) :D

Most companies don't pay market rate? That's a tad incoherent? If most companies aren't paying 'market rate' then what should we all call the rate the market is paying?

Hint: what most companies pay is by definition 'market rate'

As another commenter is saying, though, there's a big difference between what most companies pay and what are the visible offers in the market.

Offers at or above the average rate appear, get filled, and disappear. Unrealistic offers below the market rate stay "on marked" for a long, long time - so if you're looking at "what's on offer today" you're seeing a very different list of numbers from the actual prices at which deals are getting closed.

It's same as in stock market - the 'market price' is the average of closed deals, but the visible company job offers is the equivalent of outstanding 'ASK' bids which are not really representative of market price.

Think in terms of offers. You looked for jobs and you had multiple offers at ¤10, ¤11, ¤12, ¤15 (you may have more options with more numbers if you keep looking).

You took the job at 15 => Your market rate is 15, all the other companies didn't pay market rate.

Usually, your market rate is the best you got. There aren't many "best" by definition.

Assuming that the ¤10 company failed to recruit but ¤11 and ¤12 companies did manage to get a fitting candidate at that price, the market rate for that position is ~¤13, as that is the average rate at which the deals are happening - yes, offers that don't result in deals aren't relevant to the market rate, but at the same time someone asking for a raise to ¤15 and not getting it also isn't relevant to the market rate.

I'd say it's the profile that is 15. The market rate is defined for a specific profile, not for a generic job ad.

The 11 and 12 accepted offers were for other people, that maybe couldn't get better than 11 and 12. Maybe they are less experienced? maybe the 15 company would have hired them both too... but only at 11?

We could say that the cheap companies are under market or that they're only in the market for junior level <profile> (even though they don't advertise it).

We both agree we have to look at the closed deals and the details of the deals =)

Oh that was years ago. IIRC, I was started at $55k / yr plus stock options in 2008, which at the time had similar exchange rates to the USD. Seems low on these days, but was around $10k more than what I'd been earning as an engineer.

50-100% is always going to be extremely organizationally difficult, and it doesn't come down to evil managers being penny pinchers.

- Even if the individual in question had 2x the productivity of the other developers on the team, doubling their salary relative to other employees trades that one developers risk of leaving with the entire rest of the teams.

- If you have enough divergence in compensation that two people at the same level of the hierarchy doing the same role (i.e. an intermediate vs. a senior) can have pay differ by 2x or more, you should be absolutely sure there's no bias to your decisions, whether it's along an identifiable group, or just plain ol' favouritism.

- Frankly, I haven't seen much need for such lavish differentials in salary in the first place. Most people are only motivated by salary to a point. Star performers want to be recognized, and not just with a pat on the back, but give people a good place to work and pay well in general, and you shouldn't need to worry about crazy raises like that.

Lemme explain how it works.

The first thing you need to be in a > 50% raise situation is an employee that was acquired for incredibly cheap. (Epic combination: one of this first jobs + don't know the market + just came from abroad). [That makes your first two points moot because that guy is the one making significantly less money and he's not identified at the right level].

The second thing is that he's actually good and he's been working for 1 year here, doing valuable stuff. He's gained a lot of value in the meantime and he can totally leverage the job he's done to sell himself in an interview.

Let's give some numbers. The dude started at $80k base with little advantage. Over time, maybe he's gone up to $90k and you got an incredible healthcare plan. It's fine from your point of view.

From the point of view of your competitors. Your guy has been vetted by your company. He's proven and he may even have rare skills that are now easily noticeable. They will offer "market rate" and fight each other mercilessly. The package will be around $150k base (which is nothing extraordinary for that position) + $40k in yearly bonus/stock that he didn't have at your company + various other advantages + they'll also pay $50k in recruiter fees cuz he went through a recruiter.

Now, you've got a guy that is paid $90 at your place that other companies are willing to pay upfront $240k to acquire. Hope they'll never find out about your gold ;)

That's really a great point. The title should relate to what the developer can effect for the organization, not the length of employment or other like factors.

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


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?

Senior is the new intermediate (a title I haven't seen in ages).

At my last several employers, people would go from associate/junior/entry/whatever directly to senior. Usually within 1-2 years from coming out of college (sometimes 2 years-ish out of coding bootcamp for particularly bright folks).

That meant basically everyone was Senior if they weren't fresh out of school. And then getting to the next step up (which had various names... Lead, Principal, Staff, level 3, whatever), is always excruciatingly hard, because it's where people start expecting more than "We didn't fire you for 2 years" and actually look at performance, and there's no title in between.

I've seen companies promote people to senior from being out of school without internships in just a few months, then need 7-10 years of experience to get to the next level. For anyone who actually cares about career tracks, that seriously kills it.

At the company I work at we recently changed the titles and I believe we're calling junior devs "associate developers" now. Seniors are still "senior." Everyone in between it just "developer" or possibly "staff developer." Seems reasonable to me. We did also add a role above senior called "principle developer" but I'm not quite sure how their responsibilities differ from senior devs.

I think you're on to something. At Microsoft we don't stop at senior. It goes further to principal, partner, distinguished.


Super Senior



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.

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

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.

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.

> coding doesn't have much room for professional advancement

Coding is like 30% of a developer's job. And I'm being generous.

There is still enough work in the 1%, but you have to make yourself known.

Which of those do your non-seniors not have to have?

Are your ordinary developers unable "to write modular, well-tested, and maintainable code"?

(for me) it's your last two points: "well-tested", and "maintainable".

It's one thing to get the feature / bug fix in the current branch, its another know what well-tested means and to be able to do well-tested without assistance.

Maintainable - this one takes insight. Again, the more junior person just wants to cross the task off their list and move onto the next. Having insight into what is Maintainable (as it relates to the project / client / company) takes time.

They just don't teach that stuff at Uni...

This may be an acceptable list _for a senior_ to grant a senior title to a junior - but it provides little help to juniors, because to make sense of the list, you have to first be a senior yourself. Otherwise, how can you tell what is "well" in "well-tested", etc?

That's one of the points of code reviews - as you get feedback on how you should improve tests in your commits, over time you learn what "well-tested" means.

Just FYI your calculator's cost of living adjustment makes it completely uncompetitive for the Memphis, TN market. Possibly you are already getting good leads from other countries, but I wanted to point that out all the same.

I think the calculator is out of wack for the anything but the coasts in the US. A GS-12 government worker (entry level tech position) would make more than Lead with Lots of experience in Cincinnati, OH; and a GS-13 would make more in most places.. with a GS-14 (what would be 'lead') completely blowing the scale.

I think the issue is their base salary is completely off.. Especially when the 'rent index' is based in NYC. A Junior Dev w/average experience would make 87k in NYC. A comparable government GS-13 position (average experience) in NYC would make 95k.. that 8k difference compounds a lot when multiplying.

Also I don't believe the rent index. Who cares where your employee lives (at least country by country) - if they want to live in the midwest, why not pay them the same as somebody who chooses to live in California, especially if you are an entirely remote company.

I think this is a really great list. It makes it very easy to measure the outputs of a productive engineer. However, I think there is important value in humility and reflection, which this list doesn't capture. This is why I would suggest including something like:

- Ability to identify gaps in own knowledge and willingness to discuss those limitations with peers.

I find that traits like this tend to promote a healthy engineering culture. It's very difficult to grow such a culture, and it needs to come from the top.

So, wrt the article, by my estimate the quantifiable criteria you listed are:

* Fixes bugs/regressions quickly (time spent)

* Creates test plans (number of plans created)

* Helps with recruiting (number of candidates interviewed)

* Keeps issues up-to-date with progress (number of issues updated)

* Helps guide other merge requests to completion (number of merges)

* Provides thorough and timely code feedback for peers (time between commit and feedback)

Just curious if you track any these metrics or if this is mostly a "qualitative" feeling of how the developer is performing?

Here is the incentive system you're advocating.

>Fixes bugs/regressions quickly (time spent)

Do the least possible to make it work again, don't investigate or fix the underlying confusion or low-quality subsystem that made it break. Volunteer for bug fix tasks that look easy, stay away from the ones that look hard.

>Creates test plans (number of plans created)

Write low-effort test plans.

>Helps with recruiting (number of candidates interviewed)

Give lots of interviews without really paying attention.

>Helps guide other merge requests to completion (number of merges)

Get your friends to split all their changes into the smallest possible merge requests so you can accept as many as possible.

>Provides thorough and timely code feedback for peers (time between commit and feedback)

Provide rapid but low-effort feedback.

Metrics-driven management is cancer and you should run, not walk, from any organization that expresses any inkling of interest in it.

You (in general, not parent specifically) are almost certainly not smart enough to create an quantitative incentive system that actually produces the behavior you want, rather than the appearance of it. Respect the difficulty of the task, and don't.

This exactly nails the point in the article about checklists and how you can't really create effective quantitative metrics for developers.

I have read in the past about developers using various quantitative measures (number of commits, for example) to measure their own work. I think in that scenario it's different because the extrinsic reward is driven by intrinsic motivation -- you're unlikely to try and game your own metrics I suppose?

> you're unlikely to try and game your own metrics I suppose?

You'd be surprised.

Makes perfect sense, actually. Well said.

[edit] I will add that much of the responses to the metrics are quite cynical -- assuming people will game the metrics. Therefore, I agree.

Some people will consciously game the metrics and some people will unconsciously game the metrics. Some people might not game them at all, but if a chunk of the team is gaming them, then its already game over.

I would add (personal opinion of course):

  * the ability to communicate
  * play well with others
  * plan, schedule and estimate

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


> 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/

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.

That's fine until you get an asshole supervisor that micromanages your work and never uses it as technically authoritative, even though it clearly is.

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.

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.

I think the last set of qualities is fine for Knuth level developers - they're that off the charts you have no idea how to classify them.

You're off by one there. Your "junior dev" should be "apprentice" or "student".

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.

> 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.

I agree with the other comment that you should probably talk to your manager about getting a promotion if you haven't.

Networking is also not an insignificant thing. You may want to take those events your boss takes you to a little more seriously. I shunned networking the first few years of my career to my detriment. I am playing catch up now, but I've found that a strong network can also help you grow in your career... it just may be with a different company.

You want the skills to do a great job, but a network will help you get the opportunities to fulfill your potential.

Are you me?

I'm almost in the exact same situation after being hired basically straight out of college a little over 6 years ago. When I joined I was one of 3 total developers in a company with about 20 total employees. My hands have been in basically every part of our monolithic code base. Our team has now grown to 14 developers and about 70 total employees.

Earlier this year one of the other original developers who was hired 4 months before me was made "Software Development Manager". The boss and owner of the company used to look at he and I as equals, but now this other dev my superior. This superior is the same guy who once threatened physical violence on me years ago, and recently drove one of our other developers to quit over a personal squabble.

He doesn't give me orders or check up on my status or do any real managing of me -- I still get all that from the owner of the company (along with also being brought around to "meet big wigs", conventions in Vegas, being told how much value I bring to the company and being called the "MVP" of the programming team).

Where do we go from here? I could quit and try to find more money and room for advancement elsewhere (though I feel like my skills are not particularly strong). Or I could stick it out and collect a paycheck in (what appears to be) a very secure but boring position and hope that the management mess above me doesn't grow in a way that negatively impacts what I do.

This is the debate I have daily. Sorry for the stream of consciousness.

It sounds like you and your boss haven't had a conversation lately about what you each have in mind for your career.

I just want to add that it may be time to start thinking about transitioning to a new job if necessary. That is often (sadly) the best way to increase your pay and advance your career.

> 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

> 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.

  What's wrong with favouritism ? [...] Promote the ones
  you personally like (avoid idiots of course).
Because I can use introspection, look at the gut instincts that make me like someone, and tell that following them wouldn't serve my interests or the company's interests.

I like cycling and drinking cider, and a bunch of my friends are cyclists who also drink cider.

But if there's a guy who works for me and he wants to get paid more, it doesn't help me if he takes up cycling and cider drinking. It helps me if he does his job better and produces more business value.

What you describe is how social circles form, not how working groups designed around producing some objective are formed.

When you're looking for a more "freeform", "directionless" (in the sense of not having a "deliverable") social environment, you tend to gravitate towards people you enjoy being around. This is normal. Ideally, you try to expand yourself some by also looking for people you wouldn't gravitate towards, so that you can gain a wider perspective -- but that ideal is starting to get objective-oriented.

In a business, there is a "direction" and a "deliverable". It's the thing people pay for that the company does/produces, whatever that thing is.

So then companies should recognize that their raison d'être is to deliver that thing as best as possible. That means that a company should seek to comprise itself those who most aid it towards its goal of delivering the thing. Which in turn means that companies should be incentivized to retain those individuals that it finds highly capable of delivering the thing.

How well people get along within the company is a factor, insomuch as having a group of people who get along well (read: "culture fit") incentivizes the people currently comprising the company to remain at the company, so that the decision of whom to retain and whom to release is more often in the company's hands.

It's an ugly cold truth, but it provides some security to people willing to work hard: if you work hard, and you endeavor to aid in the company's goals, you'll be rewarded.

This prioritizes ability and skill over the straight-up nepotism you described, rather than ignoring ability/skill in favor of such nepotism.

The approach you describe sounds like one my current tech lead would cook up to rationalize his every-so-often decision to fire someone that he just doesn't "gel" with socially.

> Technical skills and everything else are complementary but not mandatory (except geniuses - maybe in 0.1% of the cases).

Depends on the environment.

On the one extreme, there are the consulting companies, they just buy whatever human meat shows up and sell it back at $1000 day. Who cares about technical skills, they'd sell ANYTHING, they're insanely good at that.

One the other extreme, there are the hardcore tech companies, where skills matter. A new HFT company just recruited a guy with previous experience in finance that seemed promising and let him handle the trading strategy, well that was fun seeing them loose $10M on the first day :D

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.

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.

> 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...

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.

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.

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.

An intermediate developer knows how to abstract things.

A senior knows when not to.

:) what about principal developers.

They build frameworks. ;)

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

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!" :-)

I do hope that's not the only requirement.

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.

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

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.

I can agree with Spooky23. Financial firms in general seem to have career progression well defined and progression timelines are almost written in stone. In fact, it's usually an "up and out" atmosphere where if you are falling behind the promotion timeline, you should probably be looking elsewhere.

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.

That is a very honest answer and rings very true.

The sombrero indicates a senior developer.

That would be a señor developer.

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.

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.

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.

- 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.

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.

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.

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

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...

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.

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...

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...

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.

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.

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.


That is a very interesting article.

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.

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.

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.

I think you mean 'their'

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.

Urgh, gender bias much?

In english you can use the male form for cases where gender isn't specified. This still works for either a man or a woman.

Yeah, but you have to say her now or you get bitched at for being biased.

Such "bitching" is seen very badly on HN and will get down voted. There is no need to be wary of such comments because they will simply turn grey and fade out.

They'll tell you.


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.

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.

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

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...

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...

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.

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.

>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.

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".

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

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.

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).

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.

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."

Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=12603303

The programmer competency matrix:


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

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.

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.

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.

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.

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.

The place where I work has two separate 'tracks', Senior Engineer and Specialist, and both are considered to be on the same level. Employees can chose which level the want to aim for and then be evaluated accordingly.

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.

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.

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

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

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

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.

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?

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.

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.

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.

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.

Another essay answering the same question: https://hackernoon.com/senior-engineers-reduce-risk-5ab2adc1...

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.

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


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.

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.

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

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

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).

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

Developing experience is orthogonal to engineer experience, so your statement can be reworded as "A senior developer ... junior developers ...".

Just my 5c.

0. someone who stands up to management.

Ideally real experience, but often just longetivity.

Competence and good communication skills assumed.

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?

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

You write less code and debug more code.

it depends

  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.

We detached this subthread from https://news.ycombinator.com/item?id=13156608 and marked it off-topic.

So I checked in an anonymous window to see what you did - you moved the parent post and some of its sub-posts, but my reply to the guy still is here, now as top-level comment without context. That makes no sense!

That's how we handle off-topic subthreads on HN. It has context because we provide a link to the place it originally was.

That's not what I meant. You didn't detach the subthread - you detached the thread and a sub-subthread but left another sub-subthread - my post - and now it has become the top-comment, replacing the former comment it was a reply to. You destroyed the thread structure and now it's an incomprehensible mess - who responded to whom? Now the original post that I replied to is available as link BELOW the reply! Why not shift the ENTIRE sub-thread instead of parts of it?

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.

This comment breaks the HN guidelines. Please post civilly and substantively, or not at all.



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.

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

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.

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.


This sort of personal attack will get your account banned on HN, so please don't do this.

You've posted a lot of unsubstantive comments already, and some uncivil ones too. That's not good. Please (re)-read the site rules and post civilly and substantively, or not all, from now on:



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.

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact