- Generalization VS Flexibility
- Features VS Complexity
- Constantly Fighting Entropy and Technical Debt
- Someone has probably created this already
- When in doubt, log
- Notes to self
- Raw Experience
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 physics1 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 entropy3 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.4
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.
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.
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 code2 as notes to their future selves, if for nothing else.
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.
The Senior developer reads to enhance his/her craft. Oh yes.
Here are 5 books off the top of my head:
- Fun book, can be read in any order. Buy it and keep it close by.
- Software development is more about people than it is about machines. This book explains why.
- Same as above.
- 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.
- 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.