Skip to content

Instantly share code, notes, and snippets.

@sethatwood

sethatwood/MANIFESTO.md

Last active September 15, 2023 03:12
Show Gist options
  • Save sethatwood/44a1c832a24570e7a3485ce37bbd6fb1 to your computer and use it in GitHub Desktop.
Save sethatwood/44a1c832a24570e7a3485ce37bbd6fb1 to your computer and use it in GitHub Desktop.
Download ZIP
WIP: An Engineering Manifesto
Raw
MANIFESTO.md

seeing

  • Code is a liability, not an asset
  • Own code added
  • Own code altered
  • Own code removed
  • Own code reviewed
  • Double-check things. Twice.
  • Dead code is live code
  • Never ship new errors
  • Never code before required
  • Never code more than required
  • Favor subtraction over addition
  • Favor reduction in scope
  • Favor explicitness
  • Avoid reinventing wheels
  • Avoid cleverness
  • YAGNI (You Ain't Gonna Need It)
  • Beware scope creep
  • Beware premature optimization
  • Beware premature abstraction
  • Beware the sunk cost fallacy
  • It takes as long as it takes
  • Revisit original premisses
  • First Problem != Real Problem
  • DX+ = UX+
  • 👁️
  • You are not your code
  • Forget everything

Work in progress - the following is an outline of the above, generated collaboratively with ChatGPT

I. Introduction

  • A. Overview of software engineering philosophy

  • B. The importance of code quality and maintainability

II. Code is a liability, not an asset

  • A. The cost of maintaining and updating code over time

  • B. The importance of minimizing code debt

III. Own code added, altered, removed, and reviewed

  • A. The importance of understanding and documenting your own code

  • B. The benefits of peer review

IV. Double-check things. Twice.

  • A. The importance of thorough testing and debugging

  • B. The consequences of skipping these steps

V. Dead code is live code

  • A. The cost of maintaining unused or unnecessary code

  • B. The importance of regularly reviewing and removing dead code

VI. Never ship new errors

  • A. The importance of thorough testing and debugging

  • B. The consequences of releasing code with errors

VII. Never code before required

  • A. The dangers of over-engineering and over-complicating solutions

  • B. The benefits of only coding what is strictly necessary

VIII. Never code more than required

  • A. The dangers of over-engineering and over-complicating solutions

  • B. The benefits of simplicity and minimalism in code

IX. Favor subtraction over addition

  • A. The benefits of removing unnecessary or redundant code

  • B. The dangers of feature bloat

X. Favor reduction in scope

  • A. The benefits of focusing on smaller, well-defined problems

  • B. The dangers of trying to solve too many problems at once

XI. Favor explicitness

  • A. The benefits of clear, concise, and self-explanatory code

  • B. The dangers of implicit or ambiguous code

XII. Avoid reinventing wheels

  • A. The benefits of leveraging existing solutions and libraries

  • B. The dangers of re-creating existing solutions from scratch

XIII. Avoid cleverness

  • A. The benefits of simple, straightforward solutions

  • B. The dangers of over-complicating solutions with clever tricks

XIV. YAGNI (You Ain't Gonna Need It)

  • A. The benefits of only implementing features that are actually needed

  • B. The dangers of over-engineering and over-complicating solutions

XV. Beware scope creep

  • A. The dangers of continually adding new features or requirements to a project

  • B. The importance of clearly defining and sticking to project scope

XVI. Beware premature optimization

  • A. The dangers of optimizing code or algorithms before they are actually needed

  • B. The importance of measuring performance and optimizing where necessary

XVII. Beware premature abstraction

  • A. The dangers of abstracting code or solutions before they are actually needed

  • B. The importance of only abstracting when it provides clear benefits

XVIII. Beware the sunk cost fallacy

  • A. The dangers of continuing to work on a project or feature due to previous time and effort invested

  • B. The importance of evaluating the costs and benefits of continuing versus starting fresh

XIX. It takes as long as it takes

  • A. The importance of taking the time to do things correctly and thoroughly

  • B. The dangers of rushing or cutting corners

XX. Revisit original premisses

  • A. The importance of regularly revisiting and reevaluating the assumptions and goals of a project

  • B. The benefits of adapting to changing circumstances or requirements

XXI. First Problem != Real Problem

  • A. The importance of accurately identifying and addressing the root cause of a problem

  • B. The dangers of solving the wrong problem or treating symptoms rather than causes

XXII. DX+ = UX+

  • A. The importance of considering the development experience (DX) and user experience (UX) of code and solutions

  • B. The benefits of optimizing for both DX and UX

XXIII. 👁️ (open your eyes)

  • A. The importance of staying open-minded and receptive to new ideas and approaches

  • B. The benefits of actively seeking out new knowledge and perspectives

XXIV. You are not your code

  • A. The importance of separating personal identity from code and technical work

  • B. The dangers of becoming too attached to code or solutions

XXV. Forget everything

  • A. The importance of regularly learning and adapting to new technologies and approaches

  • B. The dangers of becoming too attached to old ways of doing things

@sethatwood
Copy link
Author

https://github.com/sethatwood/wip-manifesto

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment