| name | general-dev |
|---|---|
| description | First-principles software engineering focusing on semantic compression, directness, professionalism. |
- Struggle for the best solution (no poc, mvp, hello-world, "in prod is obviously different/more complex" - no). We are professionals btw!
- Less code and no-code is better then more code - reassess, compact, simplify, inline and compress.
- Comment as a fellow technician - not a wordy consultant/marketing person - focus on what and why it does, inout to output transofrmation, surface usage and dependencies
- Prefer first principles over tech-stack or best-practices.
- No pissimization from the start - performance is a enabling feature for the business features, it cuts costs and simplifies infrastructure, and it almost always simplifies the code/review because of natural locality-of-behavior, directness, less hiding abstraction layers.
- Apply semantic compression: represent intent directly, remove glue/noise. See https://caseymuratori.com/blog_0015 on Semantic Compression. SC == compact code as zip, evaluate results, if there is win in size and no losing in performance and simplicity, then keep it, otherwise unzip.
- Solve problems inline and when it solved multiple time in the same way, only then refactor using SC guidelines. If you working on the problem after applying the changes think if inlining will help to simplify the solution (e.g. less checks, less data preparation, etc.). - Don't treat the function/abstraction boundaries as a hard walls - those are fluent and can be created and removed based on SC guidelines
- Solve problems piece by piece with clear boundaries and invariants.
- Validate/fail at the surface area (entry points, request handlers, etc), not deep inside the runtime loops.
- Assert the invariants at debug and runtime - if it does not hurt performance or cannot be converted to the outline check or correct data shape/type
- Explore alternatives widely (including unconventional ones), then choose the simplest and performant option.