a
a
aizatto.com
Build.myGitHubLinkedinNotion
Search…
aizatto.com
Table of Contents
Portfolio, Projects, Tools, Toys
Interview Guide
Engineering Code
Communication
Different Types of Coding
Commit Messages
Reviewing Code
Writing Code
Consistency
Writing for a code base of 1,000,000+ Lines
Write Code Knowing It Will Be Refactored
Naming
Commenting
Make It Easy To Reproduce
Scripts
80 character limit
Exit Early
Be careful of enum in switch statements
Be careful about chaining conditions
Be careful of chaining ternary operators
Write Code Knowing You Will be Blamed
Hacks
Bad Practices
Logs
Time
Other rules
Engineering Code
Engineering Data
Pipelines
Configuration Files
Site Reliability Engineering (SRE)
Best Engineers
Engineering Management
Why GitBook?
Getting into Tech
Personal Goals
Daily Drivers
Contacting Me
Notes
AWS
JavaScript
Node.js
Software Engineering
Technical Due Diligence
Web Development
Archive
More on Notion
Powered By GitBook
Writing Code
  • The moment you write code, it is already technical debt.
  • Every new line of code is an investment
    • How do you manage your investment?

Balance writing for longevity.
  • How long will your code last?
Write for clarity.
Write for simplicity.
  • For the long term: simplicity out lives complexity.
Write knowing that it will be read later.
More time will be spent reading and understanding code, than writing it. Reading to writing ratio is really high.
Write so that it is easy to understand.
Write to reduce "WTFs/minute". source: WTFs/minute is the only valid measurement of code quality​
Write with the aim to reduce surprises.
Write code that is easy to test and reproduce.
Write code that is meant to be read, and not meant to solve a problem.
Don't write complex code. Write simple code.
Becareful of death by a thousand cuts/commits/diffs. It is very easy to lose track of the architecture.
Reduce create technical debt.

  • Easy to read
  • Consistency
  • Naming
  • Conventions
  • Trust
Goals:
  • Increase signal. Reduce noise.
  • Reduce petty philsophical disagreements. Avoid bike shed problems.
  • Save time, energy and resources for the larger technical problems.
Examples:
  • You should not be wasting time, energy, and resource discussing style. Quickly come to an agreement and stick with it. Use a linter. Don't increase noise.
Previous
Requesting Changes
Next
Consistency
Last modified 2yr ago
Copy link
On this page
Goals for writing code
What is clarity?