S2E7 - What makes a Senior Developer?

Season 2, Episode 7

Show Notes:

In this episode we talk about what makes a Senior Developer.

It is Experience?
Is it Merit?
Is it Office politics?

The answer to each of these can easily be both ‘yes’ and ‘no’. Let's dive in!

Show Script:

Today we’re going to talk about what makes a Senior Developer. It is Experience? Is it Merit? Is it office politics? The answer to each of these can easily be both ‘yes’ and ‘no’. Let me explain!

I’ve been in the Industry for about 12 years now and I’ve worked in a wide variety of sectors. I’ve been part of companies with 20,000 people and companies with 8 people. In all my time, I’ve yet to see a common yardstick for what defines a Senior! Titles and levels aren’t standardized across companies. I’ve seen devs get the title because of a variety of different reasons:

Years experience in the Industry is one, but: Years experience isn’t a good indicator, as there’s a huge difference between someone with 5 years across 3 different companies, vs someone who has their first year experience 5 times. What about someone who’s given a Senior title after 2 years vs after 10 or 20?

It can happen for office politics

maybe as a pacifier to keep a member of staff who wants to leave,
or as a way to get a favored direct report onto a higher salary track.
It can be argued for when doing salary negotiations.
It can also be something that just happens - A junior may be bumped up to Senior to stop them leaving, and even though they may be talented - they would never had had the mentoring required.

It’s controversial, as there’s just no consistency with how it’s chosen. Between different company sizes, industries, sectors, etc... there’s a huge divide! Even within the same org and department, it can effectively be comparing apples and oranges.

For example: Lets look at the world of Javascript: Take

Senior React Developer vs
Senior Javascript Developer vs
Senior NodeJs Developer vs
Senior Fullstack Developer vs
Senior Web Applications Developer vs
Senior Software Engineer vs a that happens to use Javascript as their primary language

Some might be self thought, or have a degree/masters, or just started out a bootcamp. Out of the above list, you might have views on who would know more, or be more effective or valuable, but the truth is that that comes from clever marketing and misdirection from companies.

Title Manipulation is a thing, and it’s used by employers to tightly control what they pay their staff, even though (regardless of title) they may all be performing to the same high standard. The title’s above certainly do not indicate the abilities of the developers who may have them!

Instead of looking at it from a title perspective, lets look at it from an ability and responsibility perspective. I’ve compiled a list of abilities/responsibilities, that seem to be common with people who are worthy of the moniker Senior. I think it’s important to state that these are not tied to years experienced. They’re are many young developers that exhibit these qualities, and there are many with 20/30 years exp in the industry who do not.

There are 3 Soft-skill qualities, and then 1 technical double-whammy.

Soft Skills abilities/responsibilities of Seniors:

1 They understand the business’s needs

All technical requirements/actions are viewed through the lens of the business

They understand that they’re not paid to write code, but to provide solutions to the business and/or their clients. This can include writing code, but can also mean that the solution can be:

Deleting code.
Recommending an off-the shelf or open-source solution
- These can be self-managed/hosted by the client, or deployed via a one-click install.
- Possibly with a thin integration layer around it, but also possibly not
Dividing requirements into progressive phases instead of going on multi-month or year crusades
Pushing back on tasks that are not high priority.
E.g. Sales person pushing for something vs long awaited V2 going through final stages.

2 Provide Mentoring and Guidance

Achieved though a few actions

1. Code/Peer Reviews.
- Capitalizing on teachable moments. Gently guidance in the right direction
- If they see bad patterns, implementations or workflows in the code, they’ll lead juniors and mids to the right solution
- If they’re REALLY good, they won’t hand over the answer directly. They’ll ask pointed questions in order for the mentee to critically think their way to the right solution.
2. Planning/Workshop sessions
- Leans into our previous point of understanding business vs technical requirements.
- Turning client or product owner requirements into actionable technical tasks and workflows.
- Breaking down existing workflows and explaining/documenting them
  - Drawing diagrams is a must here!
3. Share
- Interesting articles
- Recommend books
- be able to point to the relevant parts of docs when juniors or mids come with questions
  - Never underestiamted a Senior’s well-curated bookmarks and reading lists!
The overall theme here is Upskilling and empowering the team. Instead of being the ‘go-to’ person for fixing things, they teach the team how to fix it themselves.

3. Challenge & Question requirements

They don’t just accept features or requests at face-value
They’ll go back to Product Owners or Clients and ask deliberate/pointed questions, like:
- What’s the ideal workflow?
  - How does the client get from A to B?
  - Have they thought of every case?
    - What if it isn’t going form A to B? What other outcomes or views can come out of it? A - C, C - D?
  - What’s that legal compliance angle here?#
    - What data do we store? How long do we store this data?
    - Is it expected to be exposed some way via an admin portal or reporting?
    - Is there an SLA or technical requirements we have to meet/exceed here?
      - Uptime % or Estimated concurrent users?
      - Minimum throughput or maximum expected time for a server response, etc?
  - What happens when it doesn’t work?
    - Error cases, exception handling
      - What if the user Can’t get from A to B in the product?
      - What happens if the network drops?
        
        Do we save the current state and allow them to come back where they left of?
        
        Or does the client have to start all over again?

A good senior knows to tease out the details. This helps them to:

build a mental model of a solution before actioning
nail down as much of the requirements as possible before starting so the client or product owner can’t blind-side with some new discovery mid-way through implementation.

Technical abilities/skills of Seniors

1. Abstractions

Able to think in layers, and break a single feature down into its individual implementation components.
Discerning use or Inheritance, Polymorphism, knowledge of the Liskov Substitution Principle (one of the SOLID principles), Interfaces
- A great example of this is that instead of directly using or calling a 3rd party API in code, the they’ll wrap in an integration layer instead and expose an interface for it.
  - This means if they change one API for another, they’ll only need to change it one one place instead of everywhere it’s called in the code.
  - Calling code doesn’t need to know ANYTHING about the underlying implementation – only what functionality and information to expect.

2. Generic solutions

They’ll implement features in clean, generic, reusable ways, and keep an eye on keep an eye on possible future enhancements or expansions.

Example: Image Upload
If a client comes and asks for an Image Upload feature,
- A Good Junior or Mid would write a solid image upload module.
  - They’ll test for the right extensions, maybe do some validation like filesize, name length, etc.. and then pop if all foes well, pop it onto the disk or in a specific AWS S3 Bucket or Azure Blob Storage
- A Senior to write a generic file upload module, NOT an image upload module.
  - They’ll do everything as per the junior, but have configuration options for the instance in terms of what file or mime types it accepts, validation options in terms of and where the uploads will be stored.
  - So for an image, it can be configured with relevant file extensions or mime-types, validation limits and path for where to store the files.
  - This means that later if the client wants a PDF upload, it’s trivial to reuse the file upload module and just apply a different configuration to account for the new use case!

There we go. We’ve discovered that the title doesn’t automatically make a developer worthy, and that there are 3 key soft skills and 2 key technical skills that a developer needs to develop in order to successfully carry the moniker.

Got something you’ve like to add? Drop me a mail or a DM and I’d love to discuss with you 😁