Ask HN: What is the difference between a junior and senior developer?
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?
92 comments
[ 4.8 ms ] story [ 156 ms ] threadExperience. 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.
- 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 don't actually post "+1" or any variation whatsoever. Just click the triangle.
It all sounds so vague, so it's best summed up as "experience" and "people-skills"
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/
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.
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).
- 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.
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.
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.
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.
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!
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.
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?...
Choice quote: "I expect a “senior” engineer to be a mature engineer."
He elaborates at length about what that means in the post.
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.
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.
"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.
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!
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)
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.
A jr. engineer, not yet.
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.
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.
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.
"Dev 2": Mostly works independently, knows when to ask for help
Senior Dev: Provides more help / guidance
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.
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.
Ability to communicate (hopefully) without offence.
Skin thickness.
/* amusing, yet inspiring and educational comments */
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.
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.
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.
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.
Also communication ability. Most coders cant.
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.
Essentially the number of battle scars.
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.
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?