A really good listen if you have the time, but if not I’ve summarised some of the main points below:
- Reverse engineering – it’s hard, and you can’t really teach it (although I don’t actually agree with that point, you can teach it, it just takes time).
- Software design and decomposition: build the smallest useful pieces of software.
- Always write documentation in addition to writing ‘good code’. Coming back 3-6 months later and you will have forgotten how it works no matter how good your code.
- Definition of Done is nonsensical – there is no definition of done. However make sure that you can prove the quality of a piece of code.
- On technical debt – if you’re not working on it then “go to your boss to ask for time to work on refactoring/technical debt”.
To make sure your code is maintainable:
- Build in small increments
- Refactor to remove debt regularly
- Set an example for others to follow – lead through good coding practice
Aside: I love the sound of John Ousterhout’s course at Stanford, where he claims to teach the only undergraduate course on software design. I’m not sure this is a credible claim or if I understood it right, but I love the chutzpah!
I would also add that software testing and building towards a quality target is an undervalued skill.