1.
Intro
2.
Disclaimer
3.
Programming
3.1.
Before You Start Writing Code
3.1.1.
Spec First, Then Code
3.1.2.
Write Steps as Comments
3.1.3.
Gherkin Is Your Friend to Understand Expectations
3.1.4.
Design Patters Are Used to Name Solution, Not Find Them
3.1.5.
Thinking Data Flow Beats Patterns
3.1.6.
The Magic Number Seven, Plus Or Minus Two
3.1.7.
Cognitive Cost Is The Readability Killer
3.1.8.
Learn The Basics of Functional Programming
3.1.9.
Shortcuts Are Nice, But Only In The Short Run
3.1.10.
Debuggers Are Overrated
3.1.11.
Think About The Users
3.2.
Testing Software
3.2.1.
Unit Tests Are Good, Integration Tests Are Gooder
3.2.2.
Testing Every Function Creates Dead Code
3.2.3.
Tests Make Better APIs
3.2.4.
Make Tests That You Know How To Run On The Command Line
3.2.5.
Good Languages Come With Tests
3.3.
Documenting your code
3.3.1.
Documentation Is A Love Letter To Your Future Self
3.3.2.
The Function Documentation Is Its Contract
3.3.3.
If A Function Description Includes An "And", It's Wrong
3.3.4.
Good Languages Come With Integrated Documentation
3.4.
Source Control
3.4.1.
Always Use A Version Control System
3.4.2.
One Commit Per Change
3.4.3.
Gerrit Is A Mistake
3.4.4.
Git-Flow Is The Way To Go
3.5.
Project Organization
3.5.1.
Organize Your Code by Data/Type, Not Functionality
3.5.2.
Create Libraries
3.5.3.
Paper Notes Are Actually Helpful
3.6.
Writing code
3.6.1.
Be Ready To Throw Your Code Away
3.6.2.
Future Thinking Is Future Trashing
3.6.3.
Don't Use Booleans As Parameters
3.6.4.
Beware of Interface Changes
3.6.5.
It's Better To Let The Application Crash Than Do Nothing
3.6.6.
If You Know How To Handle It, Handle It
3.6.7.
Types Say What Your Data Is
3.6.8.
If Your Data Has a Schema, Use a Structure
3.6.9.
Don't Mess With Things Outside Your Project
3.6.10.
Resist The Temptation Of Easy
3.6.11.
Start Stupid
3.6.12.
Always Use Timezones With Your Dates
3.6.13.
Always Use UTF-8 For Your Strings
3.6.14.
Optimization Is For Compilers
3.6.15.
Units Makes Things Clear
3.6.16.
If It Doesn't Run On Your Computer, You Have A Problem
3.6.17.
Nothing More Permanent Than A Temporary Solution
3.7.
Making Things Go
3.7.1.
The Config File Is Friend
3.7.2.
Command Line Options Are Weird, But Helpful
3.7.3.
Not Just Function Composition, But Application Composition
3.7.4.
Even for Application Composition, Start Stupid
3.7.5.
Logs Are For Events, Not User Interface
3.7.6.
Be Transparent With The User
3.7.7.
One Version To Add, One Version To Remove
3.7.8.
Learn To Monitor
4.
Community/Teams
4.1.
A Language Is Much More Than A Language
4.2.
Understand And Stay Away From Cargo Cult
4.3.
"Right Tool For The Job" Is Just To Push An Agenda
4.4.
The Right Tool Is More Obvious Than You Think
4.5.
Code Reviews Are Not For Style
4.6.
Code Formatting Tools Are Ok, But No Silver Bullet
4.7.
Code Style: Follow It
4.8.
... Unless That Code Style Is The Google Code Style
4.9.
Hero Projects: You'll Have To Do It Yourself
4.10.
Global Changes Must Be Discussed With The Whole Team First
5.
Personal
5.1.
Companies Look For Specialists But Keep Generalists Longer
5.2.
Keep A List of Stupid Bugs That Took More Than 1 Hour To Solve
5.3.
When It's Time to Stop, It's Time To Stop
5.4.
Code of Conduct Protect YOU, Not THEM
5.5.
Learn To Say No
5.6.
Take Responsibility For The Use Of Your Code
5.7.
Don't Tell It's Done When It's Not
5.8.
People Get Upset About Code And Architecture Quality 'Cause They Care
5.9.
You'll Learn About Yourself The Hard Way
5.10.
Pay Attention On How People React To You
5.11.
Don't Confuse Hero Project With Hero Syndrome
5.12.
Beware of Toxic People
5.13.
Beware of Microaggressions
5.14.
Toxic/Aggressive People Are Not Fixable -- Unless It's You
5.15.
Realize When It's Time To Quit
5.16.
I.T. World Is Really Small
5.17.
Blogging About Your Stupid Solution Is Still Better Than Being Quiet
5.18.
Don't Hide Your Stupid Solution
5.19.
Keep A List of Things I Don't Know
5.20.
You Always Have The Time
5.21.
Own Your Shit
5.22.
Don't Defend Bad Code
Light (default)
Rust
Coal
Navy
Ayu
Things I Learnt The Hard Way (In 30 Years of Software Development)
Personal