I love a good law. Not the legal kind, but rather ideas like "Murphy's Law" or
"Occam's Razor".
This GitHub repo has a fantastic collection of such laws:
dwmkerr/
hacker-laws.
These are principles, heuristics, and observations about specific situations or
subjects. They are not set in stone; there are always exceptions, caveats, and
"it depends" qualifiers. At worse they may be misapplied, or only serve as pithy
references to make yourself sound smart, but at best they provide useful
insights and real, actionable approaches to problem solving.
Here is a running list of my personal favorites.
Pareto Principle AKA 80/20 Rule - 80% of the effects come from 20% of the
causes
- Pareto observed this with respect to
Italian landowners
- Today the 80/20 distribution can be applied to many things, such as
prioritizing work that has the most impact
Maker's Schedule vs Manager's Schedule - "makers" and "managers" operate
best with different schedules
- Paul Graham introduced this concept in a
2009 blog post
- "Makers" are folks whose role requires deep focus and creativity, e.g.
programmers, writers, designers; their optimal schedule includes large,
distraction-free blocks of time
- "Managers" need to gather information and coordinate with various
stakeholders; their optimal schedule involves a series of meetings, e.g. a
day could be partitioned into eight 1-hour blocks, with eight completely
unrelated meetings
- These two schedules are at odds; understanding this is the first step to
fostering a productive and desirable work environment
- E.g. if leadership assume their ICs operate on the same "manager's schedule"
as them, and fill workdays with meetings and adhoc interruptions, it can
lead to a frustrated and inefficient team
Brooks' Law (Mythical Man Month) - adding manpower to a late software
project makes it later
- Based on
a book by Fred Brooks,
published in 1975 about his experience at IBM, but still relevant today!
- Software development in a team is a complex endeavor, requiring
communication, coordination, lengthy onboarding, etc.
- Therefore, it is a mistake to measure such work in man-hours (or
"man-months") and assume that adding more personnel will compress the
timeline
- This kind of thinking is only applicable to labor that is highly divisible
and where the skillset required is standardized, e.g. data entry, assembly
line work, harvesting crops
Goodhart's Law - when a measure becomes a target, it ceases to be a good
measure
- Once subjects know the metric, they will be incentivized to "game" the
system for that metric
- E.g. if you measure developer productivity by lines-of-code, devs will
simply write more code, which is not necessarily better (and often
worse!), nor does it actually accomplish underlying business goals of the
dev team
- Nuance: it is still good to use quantitative metrics to measure outcomes,
but avoid over-reliance on such metrics, as most often they are proxies for
something deeper
Code is Read 10x more than it's Written
- Therefore, strive to produce code that you and others will understand weeks,
months, years after it is written
- Investing in clarity, comments, docs, PR descriptions, commit messages, will
pay dividends to the future devs who need to maintain, debug, refactor, or
extend the code in the future