Don't Be Precious About Code

If there is one good lesson from writing code in a team, it is that it is best not be too precious.

There’s obviously much satisfaction that can be derived from completing a complicated bit of functionality or finding an elegant solution to a particular problem, but don’t underestimate the benefits of sometimes starting again.

KISS

The key to coding manageable and maintainable code is to keep it slim and adaptable - keep classes focused with a single responsibility and keep aspects like business logic or interactions with third-party services separate. By doing this, and thus keeping individual files and methods lean, it makes potential rewrites simple and quick.

A similar consideration is code complexity, even for a relatively simple, singularly focused task. Code that works well while looking complicated might seem cool at first, it can quickly become a problem later. You might understand it while working on it, and it might even appear intuitive while your mind is focused on it - looking back with a fresh pair of eyes (i.e. a colleague) - might throw a light on it in a very different way.

Only the lonely

There might also be the temptation to try to keep it “to yourself” - to tell yourself that it works and that others are just not understanding it as you do. It may also be the case that you’re accepted the “best” coder in the team, and your colleagues respect and trust what you do, and even come to you when they’re having a problem. In this case, try not to be arrogant; if your colleagues cannot read or understand your code, then this is more indicative that your code needs a rewrite than their understanding. Code should always be clear, precise and follow logically.

A good way to check if you’re getting it right is to ask someone else to read your code and tell you what they think it is doing. Also note with this that comments should be sparse, and only be used to explain specific things, like complex algorithms, odd lines of code added for specific edge cases, or perhaps some specialist knowledge or business logic. At our work we occasionally will run through code alongside a domain specialist who are very much not programmers, but they should be able to follow along enough to understand that the code is correct according their understanding of the subject.

No sir, I don’t like it

Conversely, you may be working with someone who prefers to work on their own, and may be reluctant to share code or explain it with others. This is a bad sign, and an indication that perhaps their code may not be maintainable, and certainly will not be suitable for others to simply jump in to and work with.

Some companies will encourage or require some pair programming - i.e. working on a set of code together with another individual. This can work extremely well, and I do believe that it can encourage much better attidutes towards the code and towards openness and sharing of ideas. There is a caveat though that some individuals may find it difficult working together, so care must be taken not to demotivate or demoralise members through poor matches or pushing them too hard.

Conclusion

Simple is good with programming. The simpler the better, and with clean, understandable code with lean functions and files, you will find it much easier to adapt it when circumstances change.

It will also make it easier for others to pick up where you left off. There is really no excuse to have code that no-one else is able to understand. Elitism will not make you popular, and (deliberately) obfuscated or complicated code will only come back to bite you.