Things I Learnt The Hard Way (in 30 Years of Software Development)
This is a cynical, clinical collection of things Julia Biason learnt in 30 years working with software development.
Again, some things are really cynical, others are long observations on different jobs.
Before you start writing code…
- Spec First, Then Code
- Write Steps as Comments
- Gherkin Is Your Friend to Understand Expectations
- Design Patters Are Used to Name Solution, Not Find Them
- Thinking Data Flow Beats Patterns
- The Magic Number Seven, Plus Or Minus Two
- Cognitive Cost Is The Readability Killer
- Learn The Basics of Functional Programming
Testing Software
- Unit Tests Are Good, Integration Tests Are Gooder
- Testing Every Function Creates Dead Code
- Tests Make Better APIs
- Make Tests That You Know How To Run On The Command Line
- Good Languages Come With Tests
Documenting your code
- Documentation Is A Love Letter To Your Future Self
- The Function Documentation Is Its Contract
- If A Function Description Includes An “And”, It’s Wrong
- Good Languages Come With Integrated Documentation
Writing code
- Be Ready To Throw Your Code Away
- Future Thinking Is Future Trashing
- Don’t Use Booleans As Parameters
- Beware of Interface Changes
- It’s Better To Let The Application Crash Than Do Nothing
- If You Know How To Handle It, Handle It
- Types Say What Your Data Is
- If Your Data Has a Schema, Use a Structure
- Don’t Mess With Things Outside Your Project
More: