8 coding lessons from almost three decades of software development

1. Write code for your colleagues (or your future self)

I still remember the days when I challenged myself to write code that did as much as possible in as few lines as possible. I thought this was impressive and demonstrated my skills as a professional developer. How wrong and naive I was. These days, I know that I should write code that is easy for my colleagues to understand, and that colleague might be me, six months from now. Such code should be intention revealing, use clear naming, be properly structured, and, if necessary, include documentation. In other words, it should be “clean” code that looks like it was written by someone who cares. How do you tell? Just ask your colleagues…

2. Superficial code reviews are as bad as no reviews

Code reviews have a lot of value:

• Find common mistakes
• Find inconsistencies with similar solutions elsewhere in de code base
• Identify new or updated NuGet or NPM packages that don’t meet the standards
• Identify unwanted coupling
• Identify constructs that are non-trivial to other developers (which can be you in the future)