Chris Brandsma recently wrote an insightful post about how we shouldn’t coddle junior developers. It’s a good post and i can definitely understand Chris’ frustrations on the matter. There’s just one thing i don’t understand though: why do we even differentiate between junior and senior developers?
First of all, what’s the difference between a senior developer and a junior developer? Is it merely the number of years of experience? In previous client engagements, i’ve seen more than my share of bad developers who’ve had years and years of experience. Would i trust those developers more simply because they have the experience required to be called ‘seniors’? Hell no. Trust has to be earned, i don’t care if you just graduated or if you’ve been writing code for 5 years or more.
When i have to work with someone i’ve never worked before, i assess this person’s qualities and capabilities on two things: how he thinks about writing code (in general), and how easy he can pick up new concepts/practices/principles. That’s it. A junior developer with little to no experience can often be a lot more valuable than a developer who has 5 years of experience under his belt and just assumes that he knows it all.
With a senior developer, you have to be lucky that he’s learned from his previous mistakes (and every developer makes mistakes, no matter how good he is or how much experience he has), that he hasn’t picked up too many bad habits and that he is open minded. If you can get a senior developer like that, consider yourself very, very lucky because there really aren’t that many of them.
With a junior developer, you can easily mold them into the kind of developer you want them to be. They haven’t really had a lot of time to pick up bad habits, and they are eager to prove that they belong at your company so they will be very eager to learn and improve. All you need is a couple of people who are willing and capable of teaching these young developers.
Of course, with junior developers you do have to live with the fact that they will make rookie mistakes. You have to review their work a bit more, and make sure that they learn from their mistakes. If you do this from the beginning, you’ll quickly notice that the extra reviewing tasks will soon take up less and less work.
At my company, we don’t really differentiate between juniors and seniors. The last couple of years, we’ve pretty much only hired young developers who just graduated. And so far, it’s worked out great. They never get assigned easier tasks or anything like that, and they have to do the same kind of stuff that people with more experience need to do. The result is that we have a bunch of young developers (i think the average age of our developers is 24 or something) who already do a great job, and they’re constantly getting better.
How does this correlate to the ideas of apprenticeship | journey | master in software development?
never really thought about that… it’s more of a ‘you get in the deep end of the pool, but there’s a lifeguard on duty so don’t worry if anything goes wrong’ kinda thing.
I tend to think of myself as a “Junior” developer still, especially while learning new things, and I have been writing software for almost 5 years. Now that being said, I am comfortable helping and explaining things that I understand to other developers, and also happy to take the criticism and help from other devs when I don’t understand.
senior devs SHOULD not be based on experience, but more on vision, mentoring skills and leadership
For the most part Davy, I agree with what you’re saying AND I agree with what Chris is saying. It gets difficult since what matters most is talent; not experience or education. If I were hiring developers for a project, my job posting would include what I want them to know; not how long they’ve been doing “this” and what their degree is in “that”. If they can write good software and they understand the concepts that lead to good software, they’ll do a good job and they’re the fit for me. Just because somebody has “stuck around” for 10, 15 or 20 years doesn’t mean they have seniority over anybody else. It just means they’ve stuck to their profession for 10, 15 or 20 years. A TRUE senior developer (in my still growing book, as I don’t consider myself to be one…) is one who is willing to learn, research, mentor, train and discover alternative ways to develop and maintain software.
I feel that the openness to admit there is possibly another way to do it, in addition to being in a field where we’re continuously changing what works best, is a virtue that is often overlooked. This takes neither a Junior nor a Senior developer to recognize this. This leads to good software.
There is the situation where the person who has been coding for 5 years doesn’t have 5 years of experience. He has 1 year of experience 5 times. I meet a lot of these when I do interviews for my company. There are people who go to work and write code every day. Maybe they learn from their mistakes, maybe they don’t. Then there are people that actively study the craft and are working continuously at becoming better developers.
I could take someone right out of school that had the motivation and in one year’s time make them a better developer than some of these people I see with 5 years of experience. I know a guy who has been “programming” for 15 years…doesn’t know much. I am not even sure that Junior vs. Senior is the right argument. Maybe hacker vs. programmer is a better description.
Couple of points. This will of course vary by the culture within a given company (my own is in large, multi-billion $$ corps), so adjust as needed.
1) A person with merely 5 years of experience is still a junior, most likely. When we’re talking ‘senior’ we’re usually talking about a decade or more of experience.
2) Senior-ship isn’t just bestowed based on a number of years. A senior must show to have a number of leadership qualities that make the bump in pay grade worth the money. These are:
a) The senior must be able to successfully coach/mentor junior developers.
b) The senior must be able to successfully deliver multiple large-scale projects simultaneously.
Note that knowledge of programming languages isn’t mentioned, nor is the ability to learn quickly (these are assumed to be a part of the developer toolset). To be a senior what matters is LEADERSHIP backed up by enough experience to make success the norm.
jr vs sr doesn’t have anything to do w/ amount of experience. it refers to amount of knowledge / wisdom. Years of experience is supposed to an indicator of how much knowledge / wisdom someone should have gained. However as other people have mentioned it’s not always an accurate indicator.
Now, there are a number of differences b/w jr and sr that come out during an interview if you ask the right questions. like scenarios when your live app has a hardware, or bottleneck problems, or your http server fails etc. the difference between a jr and sr person is apparent here. Environment is great separator; a sr guy should be able to answer all comers and assist anyone in the team w/ regards to setting up IDEs, app servers, db servers, load balancing, continuous integration servers, source control servers, etc.
I’m not trying to insult your company, but in my experience companies that hire young do so b/c cost is a priority. I’m a big believer in of the mantra “You get what you pay for”….and not just as it applies to our industry but in everything whether its buying a ford vs BMW, mc donald’s vs. filet mignon , hotel rooms etc. Consultancies / service providers are even worst — they will always hire cheap and charge as much as they can — that spread is their margin.
I would have to agree.
Personally I haven’t even graduated yet and whenever I have to work with code from any sort of “senior” developer it just gives me a headache because it’s usually so full of crap. Seriously, it’s like these people think that just because they’re paid well just any old crap they toss out is wonderful.
However let me just mention at this point that although by regular standards I can’t even be considered a junior developer, I do have more than 5 years of real world experience under my belt.
I totally agree with the author. I work on a team with 3 “junior” developers and 3 “senior” developers. The junior developers are at least 5 times as productive as the senior developers. The senior developers refuse to use an IDE, and are resistant to Hibernate or web frameworks, “I can write HTML and SQL by hand, why would I use a framework?”
First let me state that I largely agree with you. Remove the “Senior” *title*. It is a waste of time (and money).
Next, let me state that I believe you make your case with a massive lack of self awareness. You are SPEAKING FROM THE POSITION OF A PROPER SENIOR DEVELOPER. Phrases like:
“…you can easily mold them into the kind of developer you want them to be.”
and
“You have to review their work a bit more, and make sure that they learn from their mistakes.”
Maybe what you are really saying is that the use of the Senior title is a joke. That is surely what I believe. “Real” Senior Developers make themselves; they are not made by titles… and yes, they DO require experience to move beyond just coding into molding and guiding, using leverage of other developers to take the project to the next level.
Plainly, you speak as a “Senior Developer” that sees sooo many others with the title that should not have it.
I’ve actually had experiences that are very similar to the authors experiences. When I first entered my development career, I was given tasks that were very similar to the tasks that the more senior level developers were assigned to. This brought me up to speed incredibly fast (I remember thinking back after a year or so and saying that I couldn’t remember even a single day where I hadn’t learned something new).
When it was time for me to move on, I was surprised at the level of treatment that junior level developers received at my new company. They were given nothing but hideous maintenance tasks that none of the senior developers wanted to take part in (mostly because they were screwed up by senior-level development staff that advanced to these roles only because of time in the field). As a result, most of those junior level developers learned painful habits that were difficult to shake.
I somewhat agree. However I have to wonder if the author himself considers himself a senior. Perhaps one of those guys that already knows it all and doesn’t want to hear anything different from his peers.
@Steve
i consider myself to be a software developer who continuously wants to improve, and who wants to work with people who also want to keep improving…. nothing more, nothing less
Once your devs are getting near 30, get rid of them they get lazy/full of themselves and turn into cunts.
Stick with talented 19-27 year olds for maximum creativity and speed.
I agree with Shaun regarding his comment that a Senior developer will have the leadership qualities for mentoring others and managing multiple projects at a time. The Senior developer I work with demonstrates leadership and communication skills much better than myself and is able to successfully lead multiple projects in our organization. He demonstrates both system analyst and software developer skills and is considered a role model for most technical and analytical skills. In a traditional waterfall-like project, a good Senior developer is needed by the Project Manager, the Stakeholders and the other developers to provide the leadership skills such as: communication, estimation, analysis, push-back of requirements, triaging issues such as performance testing and go-live issues, etc etc. A good Senior developer involves other developers in all activities such as estimation and often delegates many of those tasks.
I would agree about senior developers. At the last place I worked at, both senior guys that I worked with had 10 years of experience. And they both used Hungarian notation and visual studio at the same time. And there was no way I could convince them how retarded it was to use the two together. Seniors with bad habits that refuse to change will do more damage to a project than a junior willing to change but learn from their mistakes.
Senior developer usually is Corporate code. The meaning varies. In companies I have worked in, Senior means variously:
1. seniority.
2. influence/power.
3. the one guy who wrote everything we now ship or wrote version 1.0 of something single-handedly.
Junior developer means, varioiusly:
1. useless, or less highly productive.
2. unproven/green.
3. less seniority.
There is a natural ferment where the “junior” guys who can outperform the senior guys rise to the top quickly in healthy organizations, and in unhealthy ones, the mere seniority/years-of-being-here things tends to count for more than the actual capacity to do the work.
I have had guys with ten years more experience working underneath me who were nevertheless nearly useless at their jobs. These were guys I myself hired. Guys who passed my flawed hiring/screening process with flying colours but who turned out incapable of really doing the work.
I have also had a few guys fresh out of school who are head and shoulders above their peers. In some organizations, I have identified “alpha” programmers, who are an order of magnitude better at their jobs than the others they work with. In one organization of about 12 developers, there were two, who did all the work, and the rest were basically grunts. Years of experience were nothing. Native cleverness, and a solid work ethic, made these guys alphas.
Senior may mean something, or it may not mean something. It means I get paid more than the guys who report to me, and in my case, I’m okay with that.
W
The problem with handing out titles like Senior is that on many cases those senior guys think that by Senior it means that they don’t have to open their work for review/criticism, that whatever they write or tell people to do is The Law.
My company does adopt such naming conventions, but I for one would abolish that; when introducing a new dev into the team I wouldn’t even tell him or her who are the seniors and who are not, let respect be earned and re-earned.
I’m somewhere between a junior dev and middleweight dev.
In my mind you do need to separate the terms, simply because this terming – puts you in a particular mindset. Juniors need a goal to reach, they need to be able to comfortably ask questions of more senior members of staff – if everyone appears equal who are they going to turn to?
When is someone going to take on someone’s advice when they don’t know how good that advice potentially is?
A healthy organisation in my mind is one which drops people’s titles at the door when performing code reviews. Everyone walks into a meeting without prejudice, to allow creative solutions. Decisions are based on find the best possible solutions, not who bangs the drums the loudest., or the one who slams his fist with a simple “…but I’m the senior developer I know best” attitude.
Arrogance is inversely proportional to ability in my book.
The classification is pretty simple, junior developers don’t know what they don’t know, which explains some of the comments.
When evaluating senior v junior developers you have to consider the context. I would hazard a guess that if you are working on yet another, dead on arrival, social networking start up, the developers that claim to be senior are anything but.
%Pr