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 created this already

Senior developers know that many companies face similar if not identical challenges. So the first reaction to a new problem is usually 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 solution to a problem you are facing, chances are you will be better off learning to use that instead of writing something new from scratch.⁴

When in doubt, log

Senior developers want to know exactly what's going on with systems they create and/or maintain. This is usually done via logging or other forms of code/infrastructure monitoring such as dashboarding, alerting, etc.

This gives insights into how people systems you build and will help you when things go awry.

Tools

Senior developers know their tools well. They are curious about them and want to be on top of the latest developments.

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 generally 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)

• And of course programming languages of choice.

Notes to self

A senior developer knows his/her memory is limited and therefore likes to document code² as notes to their future selves, if for nothing else.

Raw Experience

Senior developers have made lots of mistakes and, for that reason alone, will very often be more effective.

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

Reading

The Senior developer reads to enhance his/her 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.