blog/content/books/things-i-learnt/_index.md

+++ transparent = true title = "Things I Learnt The Hard Way (In 30 Years of Software Development)" +++

• Intro

• Disclaimer

• Programming

  • 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
    • Shortcuts Are Nice, But Only In The Short Run
    • Debuggers Are Overrated
    • Think About The Users
  • 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
  • Source Control
    • Always Use A Version Control System
    • One Commit Per Change
    • Gerrit Is A Mistake
    • Git-Flow Is The Way To Go
  • Project Organization
    • Organize Your Code by Data/Type, Not Functionality
    • Create Libraries
    • Paper Notes Are Actually Helpful
  • 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
    • Resist The Temptation Of Easy
    • Start Stupid
    • Always Use Timezones With Your Dates
    • Always Use UTF-8 For Your Strings
    • Optimization Is For Compilers
    • Units Makes Things Clear
    • If It Doesn't Run On Your Computer, You Have A Problem
    • Nothing More Permanent Than A Temporary Solution
  • Making Things Go
    • The Config File Is Friend
    • Command Line Options Are Weird, But Helpful
    • Not Just Function Composition, But Application Composition
    • Even for Application Composition, Start Stupid
    • Logs Are For Events, Not User Interface
    • Be Transparent With The User
    • One Version To Add, One Version To Remove
    • Learn To Monitor

• Community/Teams

  • A Language Is Much More Than A Language
  • Understand And Stay Away From Cargo Cult
  • "Right Tool For The Job" Is Just To Push An Agenda
  • The Right Tool Is More Obvious Than You Think
  • Code Reviews Are Not For Style
  • Code Formatting Tools Are Ok, But No Silver Bullet
  • Code Style: Follow It
  • ... Unless That Code Style Is The Google Code Style
  • Hero Projects: You'll Have To Do It Yourself
  • Global Changes Must Be Discussed With The Whole Team First

• Personal

  • Companies Look For Specialists But Keep Generalists Longer
  • Keep A List of Stupid Bugs That Took More Than 1 Hour To Solve
  • When It's Time to Stop, It's Time To Stop
  • Code of Conduct Protect YOU, Not THEM
  • Learn To Say No
  • Take Responsibility For The Use Of Your Code
  • Don't Tell It's Done When It's Not
  • People Get Upset About Code And Architecture Quality 'Cause They Care
  • You'll Learn About Yourself The Hard Way
  • Pay Attention On How People React To You
  • Don't Confuse Hero Project With Hero Syndrome
  • Beware of Toxic People
  • Beware of Microaggressions
  • Toxic/Aggressive People Are Not Fixable -- Unless It's You
  • Realize When It's Time To Quit
  • I.T. World Is Really Small
  • Blogging About Your Stupid Solution Is Still Better Than Being Quiet
  • Don't Hide Your Stupid Solution
  • Keep A List of Things I Don't Know
  • You Always Have The Time
  • Own Your Shit
  • Don't Defend Bad Code