Project considerations

Above all else, it has to work.

System design hints. Elegant and simple design.

• Keep it simple (stupid), don’t be Richard Hendricks from Silicon Valley trying to explain electrons to a user. Sometimes the strawman or brute force solution is good enough.

• Fail faster, build one design to throw it away, you arent going to get it right the first time. Google spends years getting things wrong too (it took them ~seven years to make Google Spanner).

• Avoid the anti-patterns.

• Narrow the waistband when many components connect to all other components. Create a common ground (e.g LLVM, Kafka, LSP, FIRRTL).

Choose boring technology and choose fewer and simpler technologies with better known failure models.

Research what the right tools (and protocols) are for the job.

• Research what’s been done and what solutions have been made.

• Study what has worked and what hasn’t worked.

• DON’T REINVENT THE SQUARE WHEEL. Avoid NIH syndrome.

• DON’T be an architecture astronaut, pick the proper technology to solve a problem, don’t make up a problem just to use some technology.

Code style, quality and readability.

• Write good specifications and documentation (both for internal and external usage).

• Write good comments that describe WHY, not WHAT, you’re doing. Imagine the person knows where you live that has to read it.

• Use style guides and linters.

• Good abstractions and separation of implementation.

• Maintainability and Serviceability. How easy is it to ship new features? What bogs you down?

• Keep it DRY.

Scalability.

Advocate for Devs and Customers, not one or the other. Helping improve one leads to helping the other.

• Explanation in this video.

UI/UX are very important, which i18n is a part of.

Ship features, not code.

Exercise good programming taste.

Good, quality automated tests.

• Write tests while developing (TDD).

• Keep it DAMP (descriptive and meaningful phrases).

• CI/CD.

Automation.

• Spend time automating what is worth automating, not something you’ll do once.

Instrumentation, logging, and monitoring are all crucial. Insight into what your system is doing is key. Don’t fly blind.

Easy, testable, reproducible, quick builds. Quick builds are essential for short iteration cycles.

Choose micro services (if you need it) and reasonable number of smaller implementations as opposed to one monolith.

Performance.

Correctness.

Fault-Tolerance and error handling, do the end-to-end principle where appropriate.

Software development methods (choose agile)

Keeping track of bugs in a database.

SECURITY

• It’s a mindset not a feature. It’s not a destination that is ever reached unfortunately, it’s a journey that always has to be followed. Adopt the security mindset.

• Rational paranoia vs analysis paralysis.

You have to be ethical, professional, and excellent.

• Acknowledge the Dunning-Kruger effect, four stages of competence, and Blub programmers.

Database for your equipment.

Licensing (gpl, mit, bsd, Creative Commons).

From Bryan Cantrill, we should have a Bias towards observation, not rash actions.

• To debug, ask questions, then form a hypothesis.

Any of Joel Sposky’s various tips.