Traits of the Senior Developer

WIP Alert This is a work in progress. Current information is correct but more content may be added in the future.

Generalization VS Flexibility

Once novice developers have written some code, they learn the value of generalizing functions/classes/modules. So they start looking at everything through a "can this be generalized?" lens. In reality, there is a fine line between generalization and overengineering.

Overgeneralizing a particular piece of code is very often not worth the effort and can positively make software harder to understand and reason about.

Senior developers have developed a feeling for how far they should go in generalizing some specific piece of code, while not jeopardizing deadlines and/or giving way to overengineering.

Features VS Complexity

Clever code is usually a sign of overenthused (but inexperient) developers.

Senior developers think not only about how to achieve some objective but also try to do it in a way that is easy to maintain. And they know that the easiest way to write maintainable code is to write code that's obvious, code that's boring.

Constantly Fighting Entropy and Technical Debt

Entropy is a concept from physics¹ that roughly represents the level of disorder in a given physical system.

If you have worked with medium- to large-sized codebases, you will be aware that software systems are also prone to becoming disorganized very quickly unless attention is paid to the project structure.

Senior developers know that constantly reorganizing, splitting and merging parts of a software project are essential to keeping entropy³ low. The main reason for writing tests is to enable you to reorganize and restructure code.

Someone has probably alrady done this

Senior developers know that many companies face similar if not identical challenges.

When faced with a new problem, they will develop a gut-feeling for what types of issues have already been solved elsewhere.

"Maybe someone has built a tool for that?" instead of "We should build a tool for that".

They are humble and understand that, if there is an existing tool to solve a problem, chances are you will be better off learning to use that instead of writing something new from scratch.⁴

System observability

The Senior developer wants to know exactly what's going on with systems they create and/or maintain.

This is done via logging—could be simple logging, distributed tracing, etc, together with visualization tools: log search, dashboarding, alerting, etc.

Tools

The Senior developer knows their tools well. They are curious about them and want to be on top of the latest developmejk-edit subliments.

Good™ tools tend to follow best/recommended practices in a given area, so adapting your operation to good tools will probably help you, in addition to making it easier for onboarding new team members, etc.

Tools include:

• Operating System you work on (Linux, Mac, etc)

• Version Control Systems (Git, SVN, etc)

• CI/CD tools (Jenkins, CircleCI, etc)

• Issue tracking/Project management (Jira, Basecamp, Github/Gitlab issues, etc)

• Programming languages of choice

Notes to self

The Senior developer knows their memory is limited and therefore likes to document code² as notes to their future selves, if for nothing else.

Raw Experience

The Senior developer have made lots of mistakes in the past and, for that reason alone, will very often be more effective and avoid time-consuming traps.

Although it is not always obvious what should be done, what shouldn't be done usually is.

Reading

The Senior developer reads to enhance their craft. Oh yes.

Here are 5 books off the top of my head:

• Code Complete: 2

  • Fun book, can be read in any order. Buy it and keep it close by.

• The Mythical Man-month

  • Software development is more about people than it is about machines. This book explains why.

• Peopleware

  • Same as above.

• Design Patterns: Elements of Reusable Object-Oriented Software

  • Yes, there is a reason why it is so famous. But you should wait until you have 2 or 3 year's experience under your belt before reading it.

• Practical Object-oriented Design in Ruby

  • Simple, but it beautifully explains they how's and why's of object oriented programming, with the fun language that is Ruby.

1: Also plays a role in information theory

2: Comments explain the why's. The code itself should be clear so that the how is obvious.

3: Some people refer to this as Technical Debt

4: Writing things from scratch is tempting but senior developers have probably been bitten by this in the past so they know they should avoid this.