Ask HN: What is the difference between a junior and senior developer? | Hacker News Reader

Ask HN: What is the difference between a junior and senior developer?

101 pointsnchuhoai89 comments

I'm about to graduate from college and have been contemplating about this question a lot lately, especially in regards to specific languages/frameworks (ruby/rails in my case)

I know that I'm not that most raw-engineering talented, but I believe I have dabbled a lot with web development (full-stack and again, Rails) that should give me a significant competitive advantage, so i was curious:

How do you specify/categorize junior/senior developers? Is it production-experience, language/framework knowledge, knowing best-practices or just raw engineering talent?

View on HN

Most of the important skills have nothing to do with technology

- Requirements gathering

- Customer interaction

- "Managing upwards" (dealing with PMs, product people, designers)

- Estimation and planning

- Becoming a team player (Most college students only do a few, short-term group projects. This does not adequately prepare graduates for tight-knit teams in a professional setting.)

Anyone with a little bit of coding background can learn rails in a few days. The hard-won assets are all "soft skills:" professionalism, teamwork, planning. As far as I know, there's no substitute for real industry experience. (It would be awful nice if there were!)

You see that little triangular arrow pointing up next to his post? When you think "that's a good post", "I agree" or "other people should see this" you click it.

You don't actually post "+1" or any variation whatsoever. Just click the triangle.

You see that little triangular down arrow?

pearjuice wasn't just saying "-1", he was helpfully explaining why asah was downvoted.

Nicely put. I would only add that a senior developer is able to grasp the "big picture" of a project, and would have the ability adapt and influence (not just with words, but with actions and well-researched presentations) the rest of the team and management to create the best outcome for the project.

It all sounds so vague, so it's best summed up as "experience" and "people-skills"

I want to add self-awareness to the list.

When I was reasonably new, but had a project or two behind me, I thought I knew everything that was worth knowing. Slowly, as projects, responsibility and, most importantly, failures, all grew in size, it dawned on me that there was _a lot_ one could know about development.

Today, I know vastly more than I did a few years ago, yet now I feel like I know very little, because I understand how much else there is still to learn.

Now that I've done some technical interviewing for my employer, I see the same thing in others. Some of the best people are those that are humble enough to say that they don't know everything.

And on the flip side I've interviewed someone who rated themself 9/10 with git. I asked for an explanation of the term rebase, and got "huh?" as a response. I also see it in some vendors I cooperate with, young business' with young developers who think they can solve everything simply because they lack experience with failure.

So in short, knowing something of ones own limitations is important. Relevant comic: http://old.onefte.com/2010/06/19/i-am-legend/

On the technical side, I will add "experience with systems as a whole, and knowing what's likely to fail in the future and how to design extensible and maintainable systems". I see junior developers who make things that work, but then are not easily extensible, cleanly abstracted, etc.

Senior developers know what to plan ahead of time, what to leave until later, what questions to ask, etc. It doesn't have much to do with the language itself as with the design of the system as a whole.

I like the analogy of the false summit (https://en.wikipedia.org/wiki/False_peak). The hill that you're currently climbing is obscuring the mountain ahead. :)

This is also true with me...everything I've learned over the past few years has only gone to show me all that I don't know.

And I'm the type of guy that would be totally honest about my shortcomings but unfortunately it also seems like this thruthfulness is seen negatively by most employers (but just because I don't know right now doesn't mean I'm incapable of learning or don't have other skills that are similar and applicable to the new skill).

Maybe he was just so badass with git that he never fucked up master and had to rebase.

Great list. Another that separates the wheat from the chaff is by making yourself replaceable. To an insecure person (in any profession) this is anathema to maintaining a job; to a confident and professional person it is simply a requirement of the job.

- Documenting what you do. If you hoard knowledge or hide it in e-mails or IRC logs you're not helping anybody. If you're guy who changes something that affects other developers but don't send a courtesy e-mail or present your charges (your action being proportionate to the change you're making) -- you're that guy.

- Teaching others your skills. Being a font of knowledge, wisdom and ideas is also important. If the product owner, PM or a junior dev can approach you and get a straight-laced answer tailored to the skill-level individual you're doing really well indeed.

- Every team and company do things differently. Being able to contrast how you're going to do something against what you have done before is another useful skill.

- Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

> Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

This. This this this. I just took a senior-level gig as a devops/productivity engineer where pretty much my entire job is figuring this stuff out. It is not stuff that juniors often think about, but it can take up a ton of management and seniors' time to get right so they don't have to.

it is taking up most of my time - but boy the series of blog posts are shaping up awesome :-)

Man. We haven't yet ramped up on devops blog stuff, but already "bloggable" has become shorthand for "valuable and interesting".

yes, it has - strange. I guess it's a function of if you don't have anything worth saying, don't say anything.

>Caring about the 'boring stuff': release management. configuration management. proper continuous integration. simplifying your build steps. cleaning up hairy code or removing redundant files and gunk from older projects.

Sigh careful there. I just got the evil eye from my boss for doing just that.

Only care about this kind of maintenance and future-proofing if you work in a tech-savvy company. In other environments where the suits have no understanding of things like technical debt and the value of maintaining a high quality, they will see this as procrastination.

I would argue that something that comes with experience expected of a senior engineer is the ability to communicate the cost of technical debt in terms 'business guys' understand.

I agree with you, but it is also important to understand when these things are important to the business.

Nice list. One thing I would add I noticed is that good senior engineers have an eye for, and a healthy fear of complexity. This usually comes from (painful) experience. Junior people on the other hand like to go and create more moving parts than necessary using the very latest tech/library versions.

A good senior person is not afraid to solve something using a short shell script running from cron. A junior person might be insecure about using something so antique and come up with a Ruby or Node or what have you solution instead.

Antique? Try right tool for the right job. That's far more a distinction.

Weird, I thought it's just 5-10y of experience in the industry that upgrades you to a senior. Isn't it??

My experience (with smaller companies) is that a couple years of experience and either asking at the right time and right way or switching companies is what it takes to upgrade your title. I've always said that early in your career you need to change jobs every year or two to keep your salary, title, role, etc. moving. If you're at a great company, large or small, you might not have to, but for the rest of us, keep that resume out there. Any time you wrap up a good project or solve a big problem, that's the time to ask for at least a token raise and a change in title.

I'm writing from my iPhone so excuse the shorter message.

I agree that the soft skills are very important but if that's true it doesn't seem to be fully appreciated I. The startup arena and seems to rely more on particular skillets more.

For example I've applied to companies that use Rails and even though I know I can learn it within a short while I've always received a thanks but no thanks message even though my resume, and associated accomplishments short list, show how I've excelled at a wide variety of projects within my organization and been able to work well with a range of different personality types.

So I feel because I'm not a "Rails" guy it holds me back. The other thing possibly, could be I can't really quantify the other usual requirement I see..."building at web scale". Since my organization doesn't really deal with that sort of traffic volume.

Of course keeping on trying is always a good thing, but it's also a bit of a bummer to get the feeling that the skills and experience one has already acquired aren't really appreciated.

If anyone would like to chat further I'll go ahead and check this thread a little later from my machine to give a thorough reply!

I expect a Sr Engineer Candidate to have dabbled in the language/framework before applying for a position. If you haven't put forth the effort of playing with the technology beforehand, ESPECIALLY with such a popular framework, I don't even see your resume... I've asked our recruiters to not bother.

Same with 'Web Scale'. There are SO MANY different ways to gain experience with maintaining high-volume sites. You can generate the load yourself, you can volunteer for your favorite non-profit, you can find a startup that is facing these problems and needs cheap labor.

A Sr. Engineer sees problems to solve, and finds creative solutions. Lack of experience in a specific realm is one of those problems.

Your comment got me thinking about my personal situation.

I switched to development about half a year ago. Before that, I worked in the industry 7 years as a game designer, producer and created a startup (even found some seed investment) which gruesomely failed.

So, I'm confident that I have the skills that you listed, but calling myself a senior?...

Another crucial soft skill to add to the list: being able to separate important from less important tasks and investing your time accordingly.

Here's the best take I've read on the subject, by John Allspaw of Etsy: http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engi...

Choice quote: "I expect a “senior” engineer to be a mature engineer."

He elaborates at length about what that means in the post.

Doh! You posted that link while I was writing up my response. Fantastic essay.

That is an utterly fantastic article.

One thing I'd like to add is that a senior engineer works to build a culture and team where anyone--especially themselves--is replaceable. If you document your high-level thinking, if you break projects into lots of small manageable chunks, and make sure that at least one or two other people know everything you know, you will find that progress is a lot faster and that lots of bottlenecks magically disappear.

And ironically, for working to make yourself replaceable, you will probably find that you are treated better.

At times in my career, I've hesitated to do exactly this due to fear of being replaceable. Yet every time I've given up a cool responsibility, I've been rewarded with something even cooler. So I've learned to never fear making myself obsolete.

So, the way I look at it (paradoxical as it sounds):

If somebody is not replaceable (and hence a potential bottleneck), they are by definition a risk. Therefore, it is in everyone's best interest to replace them and the system that enabled them, in order to harden everything against bad luck.

The cowboy coder who wrote most of the MVP in PHP in a month, for example, should be replaced forthwith if she can't document her work and get the rest of the team up to speed--if for no other reason than that she is a liability as the team grows and more things depend on her not failing.

It's kind of a counter-intuitive way of looking at it, but it makes sense.

Absolutely. If you're not replaceable, then you won't be able to take on cool new opportunities without leaving your team on a lurch. Always be automating yourself out of your own job and mentoring your successor.

I particularly like this one:

"Mature engineers are empathetic"

Which to me means that most engineers are not mature, and not senior. Considering how much poor behavior I've seen by so-called "Sr" engineers I am hardly surprised. In a world where people are infrequently called to answer for their anti-social behavior directly, of course it will continue.

Ultimately I blame the internets for that. Cant easily have empathy online, no emotional feedback loop.

In terms of getting a title of "Senior Engineer" at most companies, it is mostly a function of experience. It is highly unlikely you will be hired as a Senior Engineer straight out of college.

Don't focus on getting the title. Instead, focus on what you can control, and the titles and career advancement will take care of themselves.

There's a well-known, well-written essay on the qualities that a Senior Engineer possesses: http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engi...

Technical maturity comes from working on and finishing large projects. As with anything else, you can work for years and have lots of "experience", but if you are not critically thinking and learning during the journey, you won't get anywhere. Learn the pros and cons of high-level, architectural decisions so that you can be prepared to make those decisions someday in the face of uncertainty.

Personal maturity means working effectively on your own and especially with others. Pay attention to the highly respected engineers in your organization, and observe how they work with others.

Good luck!

Spot on. I'd also recommend having a mentor to help you grow. Someone whose work you admire and want to be like when you grow up :) Mentors are invaluable for your growth as an engineer and as a leader.

You guys all seem so altruistic. I never focus on titles. I focus on maximizing my income to effort ratio with a side of trying to do work that interests me. If someone wants to pay me more and call me a junior developer with no responsibility? That'd be just fine by me.

Let's be honest.

The qualifications for being a Junior developer are (1) familiarity with new frameworks (2) nimbleness with polyglot approaches (3) ability to code considerably more than sit in meetings (4) an approach towards getting things done, rather than spend time considering getting things done.

Not every developer has the chops to be a Junior developer, but if a Senior developer has the interest and is willing to work hard at it, they can make it.

This is silly. Few places seriously expect a junior developer to be familiar with new frameworks. They expect to get a Java kid fresh out of school. And the fixation on getting things done rather than careful consideration can--and does, I did it as a junior, it's part of becoming not-a-junior--leads to getting the wrong thing done. Spending a week moving mostly sideways is no different than spending a couple days thinking and discussing and a couple days moving mostly forward, except you might make more progress depending on exactly how far the cowboy missed the mark in their haste to just write code, bruv. (And the cowboy will miss. Everyone does, even if you're a genius. Not that groups of developers can't miss, too--but after a while you start to realize that they usually miss much closer.)

The role of junior engineers is that they are teachable and can generate value while they are being taught; the role of senior engineers is that they are teachers while both generating value of their own. There is no rarity to junior developers, there's potential plus inexperience. And that's it.

Nice dream.

The new crop of developers can push up a full stack app in 3 days, play with it, and iterate the whole process in the following day.

It's a whole new world.

To answer your question directly ... a senior engineer MUST absolutely have had the responsibility of taking several systems to production and maintaining it there for some period of time.

Ultimately there is just a whole area of experience that you cannot short circuit. While we laud genius programmers who brought something to the world (eg: Bram Cohen of bittorrent fame), there is a lot of luck involved, and ultimately no one is an island, there is a lot of supporting work to make something truly successful and widely adopted.

Good luck in your job hunt, but my best advice is to have patience, be humble and realize that your experience is a starting point, and you have much to learn.

I haven't seen the term "pragmatism" in this thread. Thats a major difference I've noticed over the years. Something that used to drive me nuts when I was a junior dev, and something I get torture my underlings with these days.

I've found most junior debs I've worked with over the years (and have memories of my own behavior) of being too cock sure of approaches, to keen on new techniques etc...

Over engineering is a major problem I see from younger people, often leading to fragility and bugs, blowing out support in 6-12 months. The other issue is using frameworks for everything, which I've found on questioning reveals fundamental lacks of knowledge about the domain they are experts with (being instead framework experts). Using massive library packages for access to one util class is very very common.

Sometimes I deliberately ask for nonessential 3rd party framework changes, or the utility class to return it slightly different just to make sure that juniors have to look into the framework and understand the domain they are working with. Quite entertaining at times, even if you have to throw out there code and rewrite for them :)

You are now an expert in College. What do you know now that a freshman does not? Not just the schooling, but the ability to use the school more efficiently. The people you know, the places with which you're familiar, and the little nuances of college life are all part of your achievement. Similar processes happen in the software world. With time, your toolset grows, your professional capability grows, and your ability to produce higher quality with less effort grows.

One of my first mentors once said to me - the junior developer solves easy problems with complex solutions. The regular (simply) developer solves complex problems with complex solutions. And the senior developer makes problems disappear.

I am CTO and 20+ years: Difference is just the role assigned, sometimes 10K hours of hands on, mostly not. Jr. dev is sometimes there just to fasttrack to manager roles.

A Sr. Dev. role is the one that people go to when an issue is not resolved for a period, one example is a month long intermittent bug. They are Sr. because Jr. ask for this bug to be assigned to Sr.. Sometimes Sr. do the real training new people.(I'll show you how it should work, go to X to show you how it works).

And here is the effect: If Sr. dev. has the tile to go w/ role, has to train and fix strange bugs, they use their position to KISS. Sadly, in most orgs, Sr. dev. is a role, not a title, it's just as common that Jr. dev. has a higher org. rank.

A role test: so lets say you want to add another 3rd party library. Who'll fix the bugs? Now you know who the Sr's are.

These roles are not new, this is very old: "Fools ignore complexity; experts avoid it; geniuses remove it."

When I was a manager, I had a stack of job descriptions for different "levels" of engineers as I prepared a case for promoting a couple of my people. To generalize from what I saw: The formal levels are based on things like autonomy, authority, and interaction. A senior engineer is expected to do things like choosing best practices rather than simply following them. Making presentations to non-engineers, including customers. And so forth.

Granted, making out this rule in an actual workforce might be a challenge, because job titles are affected by a number of practical factors such as the lack of other options for retaining people. A business can become top-heavy with senior titles, but people will seldom be demoted to reflect disparities between their job descriptions and their work. A hot candidate will be hired into a senior level, to put them into a more favorable salary range.

It's useful to consider developer maturity in terms of the maximum project complexity they can handle:

A junior developer can effectively build a software solution to something, given some advice about the interfaces and algorithms to be used.

A senior developer just needs a high level description of the desired technical solution. They can be trusted to instrument, refactor, collaborate, rewrite, invent, and get the problem solved.

A lead developer can be given bigger problems and organize an entire team of developers to tackle it.

This line of reasoning still works if you keep going:

A product manager can be given a metric to improve or a customer to satisfy. No further direction is required. They can be relied upon to do research, come up with a plan, hire staff (technical and nontechnical) and organize it all.

All CEOs have the same problem to solve: "Grow the business."

It's a bit of both, but it's mainly about experience rather than knowledge.

A senior is expected to be able to handle anything that comes up during the course of a project (including when things are on fire), to be able to delegate, to be able to mentor juniors and quality-control their work.

Juniors are expected to be learning as they go (to a greater extent) and likely to make mistakes or need help now and then.

In particular, a senior will know when they have something wrong or it's not good enough. A junior is reliant on others to tell them what's expected in a given situation.

If you are a recent graduate you are, by definition, a junior. After a few years you might have the experience necessary to become a senior, if you have earned the trust of your peers, especially those in charge of that decision.

FIrst of all, thanks everyone for chipping in, great insights here.

It seems to me that the majority of people here have defined "seniority" with professionalism and a large repository of social skills acquired over the years.

I guess independent from that issue, the reason why I originally asked the question is when it comes to job postings. When companies advertise positions marked as senior, do they then actually mean it in the above definition?

Call me naive and unexperienced, but I'm somewhat surprised by the heavy emphasis on experience over knowledge. Is someone with more domain-knowledge but less experience more junior than someone with little to zero domain-knowledge but more experience?

> When companies advertise positions marked as senior, do they then actually mean it in the above definition?

It entirely depends on the company. Ones that talk about X years with tool Y are probably using a time-based definition that they hope will translate into "this person has to have enough experience to come onboard and not break everything...right?" (In my experience, this is rarely effective.)

> Is someone with more domain-knowledge but less experience more junior than someone with little to zero domain-knowledge but more experience?

I generally will trust the latter more for one big reason: they (usually) have a better grasp of their known unknowns. Every project is a backyard full of rakes to step on and while someone with more domain knowledge with regards to, say, the tech stack will definitely have valuable contributions, I personally trust more experienced folks to ask better questions and to be able to leverage the folks with domain knowledge in the formulation of a plan of action.

(This obviously is flexible. A "senior" who can't do this and a "junior" who can may very quickly swap positions in my estimation and in how I do things.)

When they advertise for a senior position it mostly means they want to have someone able to get things done on their own without creating problems down the road. Experience is generally a better indicator of this than domain knowledge[1]. There's very little reason not to apply for a job you think you can do regardless of the requirements. Just don't be surprised if you're filtered by HR for not having the correct buzzwords.

The best way to actually get a job is to go out and meet people. Meetups, user groups, conferences are all good. Talking to other developers directly generally gives you a more accurate picture of what it's like to work somewhere and what's actually required. As a bonus if they like you and pass on your resume you avoid getting HR filtered.

[1] Software design and maintenance are language/domain portable and are difficult to teach without direct/repeated exposure to examples, which comes over time. Unless the domain is about specialized knowledge (e.g. security) it's generally faster to teach someone the quirks of your business than it is to teach them how to design software and deal with them making mistakes.

Ability to understand not just the language and project you are working on, but the system and how to adapt or troubleshoot when met with challenges you don't understand. The ability to convey concepts and mentor people when they are in a bind. Knowing when to take a step back, look at the problem a new or ask for help.

Some of that comes through experience, but I've met people with time put in that can't get their head around more than their niche. (I'm talking general programming here, not deep specialization)

To me, the most important distinction between a "junior" and a "senior" developer is that a senior developer isn't afraid to work with and maintain legacy code.

When I first started out, I was obsessed with only using the latest and greatest technologies, but I've come to realize over the course of my career that this is simply infeasible for many organizations.

To you. When I first started, I wasn't afraid of maintaining legacy code at all. It's an entirely different set of things that made me go from "junior" to "less junior".

For us a junior is someone who is starting, possibly a graduate or even just out of school. This is someone who is still learning the craft of programming (gathering real world experience) rather than the text book skills.

After a year they should no longer be junior. They are just a plain old developer, if not then perhaps programming is not for them.

Senior developers are simple those people who have a say in planning the direction that the company will take with their software. Strategic thinking in relation to the business needs of the company.

Developers tend to have a very flat hierarchy so senior is just as likely a management position rather than a recognition of outstanding skills.

In our company at present we have no juniors as everyone has been there more than a year, but we also have no seniors. To be honest I think that senior developers only appear when the head count gets into double figures and management cannot hold meetings with everyone over every little thing. Hence senior as a management position / title.

Junior Dev: Needs more help / guidance

"Dev 2": Mostly works independently, knows when to ask for help

Senior Dev: Provides more help / guidance

> How do you specify/categorize junior/senior developers?

Experience. A very skilled young programmer with "raw engineering talent" won't automatically be described as a senior developer on that basis alone. Also, keep in mind, in a very ageist profession like programming, being called a senior developer can be taken as an insult.

A major difference is that a senior developer does not limit themselves to just software development. They learn something about ops, they learn about tuning a database (whether SQL or noSQL), they learn about business problems and so on. The most important difference is that a senior software developer is evolving into being an engineer who understands the total solution space, not just the software. By choice, some people stick with software development rather than moving into software engineering or devops, but a senior person makes that as a choice, not because they are ignorant of engineering and devops.

What is the difference between a software developer and many other professions? A software developer is constantly learning new techniques, new languages, new technologies. Therefore a senior software developer knows a lot more than a junior one and has more hands on experience with more aspects of the trade.

As a senior developer, you've got some war stories under your belt and hopefully learnt from those. When people use senior developer, I suppose they only mean dev with some years of experience. I.e. There's a big difference between the theory in school and working on a real project with various stakeholders.

Just to add my 2 cents worth:

Sometimes companies consider a 'junior' to be someone with "at least x years experience".

I've seen this situation play out at least 3-5 times now. I'm not exactly sure where someone who is a 'junior' is meant to get experience for a year (real work) and then apply for a 'junior' position that has shitty pay just so that you can add up more exp.

I've also seen a lot of intern positions saying "work for us, slog your guts out for 3 months with no pay, you will compete with at least 5 others and at the end we will use any valuable code/work you've done, not hire you all and give the guy with the most hours/productivity the job and the rest of you can fuck off".

This industry is fucked... For a skill like programming I'd expect even a junior with no exp. to earn at least $5-$10 dollars per hour.

Different companies have different definitions for junior, senior etc. Like other comments mention, it's mainly length of professional experience.

Many places defines senior developers as having +5 years of professional experience (i.e. excluding college). But it varies a lot from company to company.

At my previous company, I liked their ranking system. Basically, you moved up as you became responsible for larger and larger systems.

A brand new junior employee is responsible for very little--most of what they do is going to be reviewed by more experienced engineers.

A senior engineer might be able to be tech lead a small month long project, a principal engineer might be responsible for a large subsystem, an architect would be responsible for an entire product.

Finally a distinguished engineer (essentially a VP-level position, but on the tech side of things rather than the management side) would be responsible for the technical direction of the entire company and be a strong input to the overall design of brand new products.

> A senior engineer might be able to be tech lead a small month long project,

Hmm. While I really like your definitions, I'm surprised that a senior engineer can only be considered responsible enough for a small, month long project.

I say this because I've only ever seen the first two titles ever.

New career goal: be a distinguished engineer. What company was your previous company?

If I were to be cynical, I'd say age and wage (and the feeling of knowing it all).

However, contrary to some of my previous experiences, a senior is that person that has an answer to most of your questions (and the disposition to answer them). It's that person in the office that can pull a project or a team on his own on the long term, without major fuck-ups and with a clever solution for all unexpected problems.

And if you're interested in the more superficial description: human resources would call a senior someone who's been mastering his domain for at least 3 years.

I think it depends on the particular individuals and the company. Sometimes the only difference may be salary. There's already a bunch of different responses here on what the difference could be. My own rough heuristic is that a person in a senior position should have a clear sense of the influence on business value that they and their decisions make. A junior developer is engrossed with solving a problem, a senior developer is engrossed with the business improving on some metric by means of solving a problem.

The difference is how much they want to pay you, and how much scope and accountability you get.

The same person could be reasonably senior at one place, and reasonably junior at a different place.

To me, the differences between a Jr. and a Sr. Dev are the experiences gained from getting burnt by bugs, quick estimates, production issues, etc.

Essentially the number of battle scars.

A senior developer has the sense of carrying the responsibility of the project forward, a junior developer does not and relies on the senior to carry that load.

I can tell you what the difference isn't. It's neither about age nor experience. And I'm saying this as an old fart who has been doing this for 25+ years.

Sure, time helps, if you learn from your mistakes, both in engineering and life itself.

But I've seen 40 year old developers who I would consider juniors in every way that matters, and 20-somethings who I would trust to take the role of lead developer.

One problem is sometimes people who have 10 years of experience really have 1 year of experience repeated 10 times.

Also communication ability. Most coders cant.

Would like to know how you would differentiate.

I think the simple answer is being able to make decisions and think more critically about the problem and the business implications. Junior developers usually require very specific and structured directions to achieve something ( even though they may be incredibly smart), senior developers on the other hand can work with fewer requirements and fill in the gaps when requirements are not clearly define.

I definitely don't think it's just raw engineering talent. I agree that there's most certainly a social aspect to it. I think it has to do with professionalism, architecture chops and experience, a sense of good workflow and process, a sense of accountability, and a proven record of getting projects done and done right.

Dabbling a lot does not make you a Senior Dev. It's the part where you create and debug complex systems, such as you don't see while doing your small school projects. That, plus hopefully a little more wisdom when deciding which frameworks or design patterns to use and how slavishly to adhere to them.

You can tell a senior engineer what needs to happen, and the engineer can manage the rest.

A jr. engineer, not yet.

A senior developer has to be able to lead a team of engineers in the creation of a product (or maintenance of an existing one).

What this requires depends on the job, but it is a mix of technical virtuosity, social skills, and ability to navigate the corporate environment.

The real difference between a junior and senior developer? A senior developer was able to convince a manager to give him the title and pay raise. It's more of a political distinction than anything else.

Ideally, a senior developer should be somebody whom "been there, done that".

However, most "senior" developers were made by political fight.

I'll share my coaching criteria as a manager:

an acceptable Junior Software Engineer... uses tools to make properly formatted code

produces readable code, mostly self-documenting

becomes a 'goto person' on code after spending 2 total weeks in it.

rarely goes 3 days without obvious progress or output to the sprint team

is comfortable making estimates about new work

is comfortable re-using existing patterns for new work, even in unfamiliar code

can explain the 'why' of processes and rules, and be able to see situations where they may not apply

understands agile development and participates effectively

----------------

a Senior Software Engineer... is also a Software Engineer with everything that comes with it

is a team representative of code, projects, and end-users

has a running list of 5 things the team or the team's code is weak in, and could be doing better

considers edge cases well, writes bulletproof code

understands integration points with other teams and projects

reliably resolves tickets in team's estimated timeframe.

does code reviews and design reviews that are kind and instructive

is able to refactor code to improve maintainability without being too aggressive and causing additional problems

is able to help any other dev with problems in any of the team's code

is capable of teaching a new employee about all of the team's code, projects, and end-users

brings innovative ideas back to the team from reading, experimentation, and conversations in addition to normal work

is a student of agile development and can effectively coach and mentor others in agile development

maintains good relationships among cross-functional team members

can boldly estimate very low or very high for new work, keen prediction for the very easy and very hard

can sense CPU, memory, and computation time problems in code invents new patterns and solutions rather than always using existing patterns

sees the give and take in processes and rules, uses them as a tool for guidance not to be followed rigidly 100% if not best for the company

understands feelings and history about codebases and projects, not just the immediately apparent facts

is not just extremely knowledgeable, but also with passion and proper application and improvisation of concepts

There is only one thing that makes you a senior developer: years in the industry. That's it. Ask your manager the minimum amount of time on the job for promotion. They'll use a formula to figure out if you're ready for more responsibility, but the gating factor is years on the job.

Competency at negotiating.

experience. and price :) (which, IMO, is 90% of the reason why older devs have trouble finding jobs, and not so much the supposed difference in ability. young = cheap.)

also, to me it seems that it's more about your position in a company, than skill. i.e. being a senior does not mean being better, it means having more responsibility. being a senior is a position, not a level of skill. although, they would normally correlate.

you certainly won't be a senior as soon as you get out of college.

Experience. Time-served in a startup/dev environment.

Ability to communicate (hopefully) without offence.

Skin thickness.

/* amusing, yet inspiring and educational comments */

I delete your amusing, yet inspiring and educational comments because they are at best useless and in the way and at worst a potential way to lose a lot of money.

I've seen this one cause an actual, measurable financial loss:

//customer type X cannot purchase product type Y.

The code said another story, but someone trusted the comment. I only trust code.

a senior knows why.

> What is the difference between a junior and senior developer?

10 years.

Two things I expect a senior developer to understand: threading and some details of networking. Examples: effectively making some operation run concurrently in another thread without adding too much or not enough locking. Understanding how HTTP keep alive works. Being able to troubleshoot TCP connection issues using WireShark. Even if you're a Rails developer and never see the details of the HTTP implementation, they can be valuable to know and can save you a ton of time when troubleshooting production issues.

I don't. That's very specific and not really indicative of ability to manage a software project. It does give a measure of how deep a developer might have gone, in that domain.

Someone else might care about pointer arithmetic, for example, I bet your clients don't, though.

But your clients care about not having the bugs that the junior dev wrote because he/she didn't really understand pointer arithmetic...

Senior devs know a lot more about how to avoid causing problems in the code they write.

Reply on news.ycombinator.com