DEV Community

David Christian Liedle for DevRelopers.io

Posted on

The Value of a Senior Developer

You’ve seen the job listings: “Seeking Senior Full Stack Developer with 10+ years of experience for FAST paced job. Must be able to multi-task, do several things at once....and did we mention things move FAST around here?”

Now, I’m sure the person posting that job listing had in mind that this would somehow attract the interest of an extremely well-qualified individual. They’d meet over coffee, and realize that this was fate: the job is a perfect fit, and everyone works happily ever after.

That’s pretty far from reality, though. In my experience, companies that post this sort of aggressive warning sign about their corporate culture are actually scaring away talent. But what is the middle ground where both parties’ interests overlap? That magical place in the Venn diagram where expectations and reality converge?

What is the value of a Senior Developer?

Time is money, so it stands to reason that “fast” developers will take less time, and therefore cost the company less money. This means they are more valuable, and paying them twice as much as a Junior level Dev makes sense if they’re delivering two, maybe three times as much volume. An alluring fairytale, to be sure, but this is not the value of a Senior Developer.

Talent is, I suppose, considered valuable for two reasons: first, the efficacy of a talented Developer can yield consistent results for a business. Second, the rarity of talent imbues value. However, being a Senior Developer has nothing to do with talent. Just because a Developer has been developing for 10+, 20+, or even 30+ years does not mean they’re talented. It especially does not mean that they have been granted a raise in their talents every n years. Talent is not the value of a Senior Developer.

Some professions have some pretty obvious limitations. If you’ve been laying brick for two decades, you’ve probably picked up some muscle memory that beginners do not have. You’ve probably increased in speed and dexterity over time, and perhaps lost some of that again due to exhaustion or age. It certainly does not mean that now, after 20 years of laying brick, you should be expected to carry the weight of two workers. The passage of time does not change the ethical limits of the human mind, body, or spirit. Taking on the workload of what should be several qualified individuals is not the value of a Senior Developer.

So what is it, then? What is it about a Senior Developer that makes them desirable? What makes their sticker price higher, and what are the realistic expectations a hiring company should bring to the table? What do Senior Developers want to see in a job listing that will let them know their value is recognized, respected, and actually required in a given environment?

Experience.

I’m not a great musician. I wanted to be, and at times in the past I’ve practiced and perfected some songs on some instruments. I’ve played the violin since the age of 7, but I certainly don’t have many years of experience with it. Heck, I haven’t touched a violin in about a decade in recent years. I bought my first guitar and taught myself to play at the age of 16, but when my daughter was born I gave up my guitar to pay bills and haven’t had much opportunity to maintain that skill since. Certain aspects of my classical piano training are (hopefully) permanently embedded in my thinking processes, but when I recently stepped up to a piano I was rediscovering shapes my hands have not made for a while. That said, after the combined experience of many years of making music, I am confident that I can step into just about any jam session and make noises that, to a kind and tolerant ear, I know would sound like a proper part of the greater whole.

I haven’t been to every subway station in NYC, but after living here for the past 3 years, you’d probably find me a helpful companion if you’re trying to navigate our subterranean mazes and arrive at the correct stop at a reasonable time.

I haven’t read every article about software development ever written, nor every book, but with most topics you might bring up in a conversation I’ll be at least an active listener with what hopefully would be intelligent questions even if the subject matter is completely new to me.

The role of a Senior Developer implies many things, depending upon who you ask. The primary element all Senior Developers have in common is the title: “Senior Developer”. I’ve seen programmers who played with PHP a little bit in High School jump straight into a Senior Dev role because that’s what was listed on the company’s website, and that was the set of responsibilities required for the person who sat in that chair. I’ve seen extremely qualified, experienced, talented Developers get caught in the machinery of corporate steamrolling and remain in far more junior positions than I would judge them to deserve.

Personalities can strongly influence the perception of seniority, too. A pedantic braggart may seem to be quite senior, when in reality they’re just quite impressed with themselves. A humble, quiet Developer may be taking on more than they can handle with less than they can afford to earn.

Alright, this is a great diagnosis of some of the problems we run into when labeling Developers, but what’s the solution? How can we identify the value of Senior Developers, and understand what value they’re seeking in return?

The first thing we need to establish is a very, very firm concept of equality. I am not better, nor am I worse, than any other Developer in the world. Each of us have chosen a career that specifically deals with unknowns: we’re building things that don’t exist, and we can’t predict the future. I will make mistakes, you will make mistakes, and we can’t predict the rate at which either of us will make them.

You might have just finished Chapter 7 of an introduction to a programming language I’ve used for years, and could write a FizzBuzz faster than I can recall whether or not the language is installed on my current laptop. I might have the right set of eyes to catch a bug in your code that’s been driving you crazy in a language I haven’t touched since 2008 (oh Lua, it’s been too long! Call me; we’ll make a weechat plugin sometime.). The point is that we don’t automatically become rockstars, computer gods, or influencers just because time has passed.

Senior Developers are still learning; still growing. There are many things we cannot do, and even more we don’t know how to do.

I believe the fair, general assumption a hiring manager should be able to make about a Senior Developer is that they have experienced the struggles (and hopefully the victories) of solving problems to a greater extent than Developers who have only just begun their journey.

I’ve already stated that the value of a Senior Developer is their experience, but what does that translate into within the context of the goals and expectations a company should bring to their role?

To understand this, let’s unpack what it means to have experience.

You know those movies where there’s this one, invariably retired expert chopping wood in the mountains? The helicopter comes in, and you know shit’s about to get real when they say “I gave that up long ago.” We expect the helicoptee (it’s a word now, get on board) to offer the chopper-of-wood an impressive sum, and of course the recluse will decline. Then comes the big motivation: “Your husband was the scientist we called first, and he’s the one trapped by the baddies.” Buckle up — we’re about to see an impressive display of what an experienced, highly motivated professional does when highly motivated to implement the experience they profess.

Why does that matter? Why aren’t there movies about how an email was sent to notify them, and they sit by the fire waiting on the SWAT team to take care of the situation? We’ve romanticized the idea of the hero figure, but much of what seems to bring success in those movies can really be chalked up to blind, stupid luck.

In reality, much of what you’ll observe in an extremely experienced professional’s habits are the opposite of what hiring companies are looking for.

An experienced Developer that has worked in technology for many years is likely to be more cautious than their junior peers.

An experienced Developer is less likely to pull a wildly inaccurate time estimate out of thin air to wiggle out of an awkward planning meeting, but “I don’t know, but I’ll find out” doesn’t sound like a very “Senior” answer, does it?

An experienced Developer has likely dealt with many layers of management over the years, and very likely has more than a few battle scars from structural inefficiency and suboptimal organization of work; they may seem hesitant to go along with many decisions, strategies, or sudden changes that less experienced Devs would happily agree to.

A Senior Developer may have failed time and time again at exactly the same type of project, and here we come to the ultimate value of experience: outcome.

The outcome of a project is what we’re all busy working on, yes? The reason you’re a Developer, or the reason you’re looking to hire a Developer, is because you want to create, effect, and achieve a successful outcome.

This is what experience gives the Senior Developer: a collection of outcomes. Both successful and failed outcomes are immensely valuable to every organization. Knowing, remembering, or intuiting what will not work, what should not be built, or what is likely to require immense and unfulfilling effort to achieve can rescue a doomed project and save thousands of cumulative development hours across the organization. Bringing a collection of experiences to the table can help to set the direction of a project’s implementation, and may even fast-forward past some of the darkest parts of a project’s roadmap when the Senior Developer says “oh hey, I have some code that might work here.” Simply being aware that an SDK, library, plugin, or add-on exists can save a team from re-inventing the wheel time and time again.

The value of a Senior Developer is in their experience. The value of their experience is in the lessons learned, the knowledge gained, from achieving many outcomes (both good and bad).

But wait a tick... these same experienced Senior Developers have seen your job description many times. “Must be comfortable with unreasonable expectations and poor planning from surprisingly opinionated non-technical leadership.” Is that the message we want to send? Is that the bait we’re looking for on the hook?

What do Senior Developers want?

I’ve been writing to both Developers and Managers above, but let me just speak to the hiring managers here in closing. Senior Developers have not only experienced code, frameworks, and more than their share of memes. They’ve experienced having the floor fall out from under them in a project that really could have succeeded with proper leadership. They’ve experienced amazingly well-aligned teams where management trusts them and gives them the freedom to deliver software that works and doesn’t have to be rewritten every sprint. They’ve experienced boring phases where they wanted to be challenged, and they’ve experienced challenging phases where they were really quite bored of walking to the same gallows time after time.

If you want to attract a Senior Developer, I would encourage you to look into the mirror of truth below. If you find yourself basing the requirement for a Senior Developer on any of the following logic, I would encourage you to re-evaluate and try again:

  • DO NOT indicate that you expect the Senior Developer to do the work of 5 people
  • DO NOT indicate that you expect the Senior Developer to make less or no mistakes
  • DO NOT indicate that you value the Senior Developer because they are “fast”
  • DO NOT indicate that you value the Senior Developer because they are “good”
  • DO NOT indicate that you expect the Senior Developer to deliver value prior to a proper onboarding, as every new employee or contractor must receive

What can you do if you catch yourself describing the position you are trying to fill in these ways? I’m so very glad you asked:

  • ACKNOWLEDGE that your organization is under-staffed
  • ACKNOWLEDGE that technical debt needs to be prioritized in your organization
  • ADJUST your values from the speed of the Developer’s work to the nature of their work
  • RESPECT everyone on your team as equals
  • PROVIDE everything the Senior Developer needs to get up to speed within your organization; most especially a reasonable amount of onboarding time

Putting these things into practice, here’s an example of a job listing that I would find attractive as a Senior Developer:

“Initech is seeking a Senior Developer with experience in both front and back end development; database and DevOps experience a plus. Responsibilities will include development, planning, and architectural advice to our small-but-growing team, with 10% time reserved for mentoring Junior Developers. Our Agile Development approach will ensure that your workload is fair, but we also hope you’ll be able to help us improve our team’s efficiency to increase delivery throughput to clients as we’ve been struggling to keep up.”

Top comments (2)

Collapse
 
aeroradish profile image
Kyle Kelly

This post is spot on. Let's get the downer portion out of the way first: what struck home about this article was "they’ve experienced challenging phases where they were really quite bored of walking to the same gallows time after time". Senior Devs (SDs) get a lot of experience from a failed project that they have to take the hits on.

Going back to the positive, I'd point out that SDs provide a lot of value in that their architecture tends to allow flexibility, because we know that the project scope/requirement is going to change. We plan for it, and only express minor irritation when the inevitable happens. We're also more realistic about what has to be rewritten in a legacy system, what can be left alone, and how to take into account the budget (whether money or time) to make the decision.

I'd also like to say that, as a Senior Dev, I'd respond to a job advertisement like the one listed.

Good article.

Collapse
 
derekgreer profile image
Derek Greer • Edited

I found this article very interesting and engaging. Having been in the software industry for nearly 30 years, there are a lot of opinions expressed here with which I'd agree. I found, however, several statements a bit puzzling.

"The first thing we need to establish is a very, very firm concept of equality. I am not better, nor am I worse, than any other Developer in the world."

Often people end up disputing over words, rather than ideas, so I'm allowing for that possibly here. That said, there are so many variables that go into weighing the value of a developer that I'm not sure we could find 2 on earth that are truly equal. Pretend they're equal for the sake of forming a flat team? Perhaps. Even grouping all developers into the 2 extremely broad groups of seniors and juniors, however, it would be inappropriate to say that junior developers are, on average, equal to senior developers. I'm not quite sure what is meant here.

What I do agree with is that experienced developers won't necessarily produce what you expect from them faster than junior developers, but that statement should really be understood relative to the level of quality they are likely to produce. A senior developer might take longer to produce something, which on a quality scale of 1 to 10 might be an 8, than a junior will producing something which on the same scale would be a 2, but that's not quite the same thing as saying the junior developer is faster. An experienced developer should always be faster, on average, with respect to achieving the desired goal. The simpler the goal, of course, the less we'd notice a speed difference. Want a default npx create-react-app application? You're likely not going to see a difference. Want a maintainable SPA application which persists data on the backend with a test harness? On average, expect the exact same level of quality to be several factors faster. We have to compare apples to apples. Make it clear to both junior and senior that the goal is working at the expense of maintainable (i.e. do whatever dirty tricks you can to get it out the door as fast as humanly possible) and the experienced developer will, on average, be far, far faster. Certainly this is understood, so I assume perhaps what is meant is that seniors won't necessarily be faster than juniors because they will be producing something at a different level of quality.