Lessons learnt in the trench as a software engineer

One of the most obvious ways to become a better programmer is to read code. The other ways are to actually code and read the documentation. I was lucky enough to be a full-stack developer of product teams dealing with huge projects early In my career. My first task, when in a new team is usually to understand the project architecture and then read the existing code base. It gave me a sense of the rigor of the project and the coding style.

 It has also enabled me to have a nose for code smells. As you gain experience you can read the source code and easily grasp the problems occurring frequently with it.

 The important lessons I learnt during my journey were:

1. Test coverage: If you do not have complete test coverage, it becomes difficult to identify what breaks on changing code either written by yourself or by others.
2. Common standards and tools: Developers on a single project have to adhere to common specifications like using spaces vs tabs, naming conventions, when to use switch vs if/else etc. It's necessary that all developers use the same tools and stylistic preferences while coding for consistency. You wouldn't want to scroll through commits containing stylistic changes like addition and removal of blank lines and spaces when comparing code changes.
3. Usage of design patterns: Some usages are obvious from the outset. Some are realized after writing bloated code. I learnt more about using design patterns while reviewing my own written code.
4. Interfaces: Use them liberally. Never accept a concrete object as a parameter, build on abstractions.
5. Reduce dependencies: Use minimum dependencies as you can.
6. Reduce bloat: Simplify, Simplify, Simplify! The more unused code that builds up, the more difficult it is to understand and debug issues. Do not try to over-generalize solutions. It only leads to bloat and confusion in the minds of the developers.
7. Naming: Use relevant names that goes for both methods and variables. It makes reading easier. As someone said, naming is the biggest challenge in programming
8. Re-read: Read and re-read what you have written. The first draft is always the worst one.
9. Write for clarity first and cleverness later: Do not try to be clever to skip a few additional lines. Remember you may have to edit later what you have written now.
10. Test all outside data in a class/method: Test all inputs to a method and class.
11. Log all exceptions. Do not catch what you can't handle: It is better not to catch all exceptions. When writing exception handling code be as specific as possible so as to make the lives of the ones coming after you easier.
12. Commit messages: Commit Messages should contain information on why the change was made rather than just the changes
13. Using code quality tools: Controlling Code quality is one of the ways of achieving all of the points mentioned above.

If any of these resonate with you or you wish to add to it, please leave a comment. I would love to hear from you!!