- Keep it simple(KIS): I have seen (and participated) in some projects which failed because of over engineering. This is just so painfully common with the egos of many highly talented programmers and for some reason allowed by their lackluster manager’s. Sometimes the best solution won’t lead to real customer value if the code is not maintainable because it is too complex. Create some easy approach which works, ship it and gain feedback and iterate based on that feedback. Maybe the easy approach is already sufficient. Otherwise you develop stuff which might not be delivered any time.
- Test driven development (TDD): Testing your code is one of the most important things to ensure code quality. If you want to do it even better work test driven. This also forces you to think about the functionality and edge cases upfront and ensures a better test coverage. No one want to touch untested code and I assure you: Someone will need to touch it one day.
- Single responsibility: Every module, class, function, method should have a single responsibility. If you have a method called “convert_and_persist” you have done something wrong. it should be one function to convert the date and one handling persistence.
- Immutable data: This is not really a concet of developing, but code design, but I think immutable data have a huge advantage over mutable ones. Yes, sometimes it is necessary to boost the performance by directly manipulating stuff in memory. But to reduce bugs immutability is a good tool. Some languages are immutable by default like Clojure (see and scroll down)
- Don’t reinvent the wheel: If there are libraries used by thousands of other developers, then use it as well and don’t write the stuff yourself. Open source libraries are in 99% of the cases more efficient than what you would write because a huge bunch of people smarter than you optimized that code.
Organization – make your code easily readable. this will change based on the language, who you’re working with, and other factors. this is not hard to do if you make it a constant practice. Write in such a way so that the next programmer picking up your project can actually read and understand your code
Documentation – if your code is worth anything at all to you, your employer, or whomever, it’s extremely likely that down the line (when you retire, leave for another job, get fired, etc) someone else will have to work with your code. Do them a favor and document your code well, and learn how to document effectively (there are bad styles to this, too!). In addition to helping the poor saps who inherit your code, this will be extremely useful to you when you do updates, forks, and so on.
Function Composition – learning to write functions is absolutely essential.
Debugging – every programmer needs to be able to debug what goes wrong with their work. additionally, you need to be able to do this for other’s work.
Design – by this I mean being able to take spec from your employer, or a group you’re working with, and turn it into functioning code that achieves the goals desired, in addition to being organized and well-documented.