DevOps Zone is brought to you in partnership with:

David Green is a developer and aspiring software craftsman. He has been programming for 20 years but only getting paid to do it for the last 10; in that time he has worked for a variety of companies from small start-ups to global enterprises. David co-founded the London Software Craftsmanship Community ( - a group of professional programmers who meet regularly to exchange ideas and improve their craft. David is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Who is a senior developer anyway?

  • submit to reddit

What makes you a “senior developer”? Everyone and their dog calls themselves a senior developer these days. From fresh graduates to the CTO, everyone is a senior developer. But what the hell does it even mean?


Some developers are avid technologists. They got into programming really because they like tinkering. If it hadn’t been 7 languages in 7 weeks, it would have been a box of meccano or they’d be in their shed busy inventing the battery operated self-tieing tie. These people are great to have on your team, they’ll be the ones continually bombarding you with the latest and greatest shiny. If you ever want to know if there’s an off the shelf solution to your problem, they’ll know the options, have tried two of them, and currently have a modified version of a third running on their raspberry pi.

The trouble with technologists is more technology is always the answer. Why have a HTTP listener when you can have a full stack application server? Why use plain old TCP when you can introduce an asynchronous messaging backbone? Why bother trying to deliver software when there’s all these toys to play with!


Some developers naturally gravitate towards providing tools for the rest of the developers on the team. Not for them the humdrum world of building some boring commercial website, instead they’ll build a massively flexible website creation framework that through the magic of code generation will immediately fill source control with a gazillion lines of unmaintainable garbage. Of course, that’s assuming it works, or that they even finish it – which is never guaranteed.

There’s a certain kudos to being the tools guy on the team: you don’t want the most junior member of the team creating tools that everyone else uses. If he screws up, his screw up will be amplified by the size of the team. Instead one of the smart developers will see a problem and start sharpening his tools; the trouble is you can spend an awful long time creating really sharp shears and somehow never get round to shaving the yak.

Backend Boys (and Girls)

Another common pull for a lot of developers is to get further down the stack, away from those messy, annoying users and nearer to the data. Here you can make problems more pure, really express your true artistry as a developer and an architect. It’s true: as you move down the stack you tend to find the real architectural meat of a system, where you want the developers who can see the big picture of how everything interacts. The seasoned professionals that understand scalability, availability and job-security.

It’s pretty easy to put off outsiders (project managers, customers, sniveling little front end developers) – you start drawing diagrams with lots of boxes and talk of enterprise grade messaging middleware and HATEOAS service infrastructure, before you know it their eyes have glazed over and they’ve forgotten what they were going to ask you: like perhaps why this has taken six months to build instead of six days?


Some developers just Get Things Done. Sure their methods might be a little… slapdash. But when you’re in a crunch (when aren’t you?) and you need something done yesterday, these are the people you want on your team. They won’t waste time designing a big complex architecture; they won’t even waste time writing automated tests. They’ll just hammer out some code and boom! problem solved.

Sometimes they can come across as heroes: they love nothing better than wading into a tough battle to show how fast they can turn things around. Of course, that also lets them quickly move from battlefield to battlefield, leaving others to clean up the dead and wounded they’ve left behind.

Front End Developers

For some reason Front End developers never seem to be considered the most senior. As though hacking WPF or HTML/CSS was somehow less worthy. In fact, I think the front end is the most important part – it’s where all your wonderful n-tier architecture and multiple redundant geegaws finally meets users. And without users, everything else is just intellectual masturbation.

The front end developers are responsible for the user experience. If they make a mess, the product looks like crap, works like crap: it’s crap. But if the front end developers create a compelling, easy to use application – it’s the great, scalable architecture underneath that made it all possible. Obviously.

Team Lead

Your team lead probably isn’t a senior developer. Sorry, bro: if you’re not coding you can’t call yourself anything developer. Go easy on your team lead though: the poor sod probably wrote code once. He probably enjoyed it, too. Then some suit decided that because he was good at one job, he should stop doing that and instead spend his life in meetings, explaining to people in suits why the product he’s not writing code for is late.


Your architect probably isn’t a senior developer either. Unless he’s actually writing code. In which case, why does he need the label “architect”? Architecture is a team responsibility. Sure, the most senior guy on the team is likely to have loads of experience and opinions to share with the team – but it doesn’t mean his pronouncements should be followed like scripture. But if instead of writing code you spend your time drawing pretty pictures of your scalable messaging middleware one more time, I will shove it up your enterprise service bus.


There are lots of different types of senior developer. That’s probably why the term has got so devalued. Once you’ve been in the industry for a few years, you’ll have found yourself in at least one of these roles and can immediately call yourself senior. The truth is you spend your whole life learning, only in an industry this young and naive could someone with 3 years experience be called “senior”. I’ve been programming professionally for 13 years and I’m only just starting to think I’m getting my head around it. I’m sure next year I’ll realize I’m an idiot and there’s a whole new level to learn.

So, go ahead, call yourself senior developer. Just make sure you keep on learning. Change jobs, wear a different hat. Be the tools guy. Meet like-minded developers. Play with different technologies. Become a middle tier developer. Then switch to work on user experience.

Senior developer: it’s just a job title, after all.

Published at DZone with permission of David Green, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Erin Garlock replied on Thu, 2013/10/24 - 8:36am

Very tongue in cheek observations - I love it.  My definition of senior developer includes a minimum number of years experience, the ability to tackle (and solve, and in a timely fashion) complex problems you would not otherwise be able to without that minimum number of years experience, and above all - three or more of the categories you listed.


Java Guy replied on Fri, 2013/10/25 - 4:59am

Great points, esp about Front end developers.  This quora post was really good re: the front end developer

When I'm hiring, I can find many suitable candidates who are senior developers up and down the server side stack.  But its much harder for me to find a really good front end UI / UX developer who knows all the browser compatibility issues including mobile...those guys are golddust

Lund Wolfe replied on Sat, 2013/10/26 - 10:23pm

I think you have to use years of experience to mark junior, developer, senior.  That said, I don't think it means much by itself, even considering area of experience.

I used to think a junior could contribute with assistance, a developer could work alone and do more difficult parts, or even do the whole project with a sacrifice in quality, and a senior could do a good design or do it all alone at high quality.  A senior would ideally have good people skills, as well as skill in each stage of software development.

I would still hesitate to have a junior design the whole project, but I've seen enough nontrivial projects built by senior developers that were but ugly and small example code samples by no experience graduates that were elegant to know that intelligence or ability or talent is far more important than time experience in building quality, maintainable applications.

"Senior" developers have enough experience and know enough tools and libraries to build it and get it barely functional, but at what cost in quality ?  Don't hire based on years of experience.  Two years experience can be far more rewarding and less risky than twelve.

Kerr Schere replied on Wed, 2013/10/30 - 6:39am

This was an entertaining read.  In the last 15 years or so, I've played all of these roles to varying degrees.  I'm real thankful for having the opportunity to work on many facets of app dev.  People filling all these roles on a team is ideal, though I've been on teams missing some ingredients.  All things said, the most dangerous yet client-centric of these personas is GTD.  I can't tell you how many times I've seen technical debt snowball due to poor strategic vision and shoddy quality from the GTD guy.  He's needed in a pinch, but be sure to sandbox him as much as is practicable.

Amy Schultz replied on Wed, 2013/10/30 - 12:21pm

Really good and funny observations, but I do think the article was diminished by your attempts at humor done in poor taste. Please consider writing as though there were a lady in the room, because there is.  We'll all benefit if the developer community is a more welcoming for all.  I'm sorry, but tacking on "and Girls" in parentheses, and referring to "intellectual masturbation" and "shoving it up" anything really put me off and shouldn't have made it past the moderator.


A sniveling little front end developer (and yes, I get it, that part was written as a joke, I do have a sense of humor)

Bryan Copeland replied on Thu, 2013/10/31 - 12:20pm

 What I've discovered:  
- don't be a Technologist (aka. dreamer) if the company already has licenses in place or prefers to contract with typical big name providers for support
- don't be a Toolsmith if the project/company has low budget (time or money)
- don't be a Backend Warrior if the project/team/company is client-focused
- don't be a GTD if everyone else is change/risk adverse
- don't be a Front End Dev if the backend or middleware is still shaky
- don't be the Team Lead unless your project/team lacks PM or experienced devs
- don't be an Architect if the project/team already has a well-defined process and/or Business Analysts to help with requirements gathering, design decisions and documentation along the way

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.