proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FameDan McKinley20158 min readintro

Choose Boring Technology

Read on mcfunley.com

Summary

The essay argues that engineering teams should spend their limited “innovation tokens” on business problems, not on novel infrastructure, by choosing mature, well‑understood technologies. Boring tools like MySQL, Postgres, Python, or Cron reduce unknown unknowns and keep system complexity low.

  • Treat technology choices as limited innovation tokens and spend them on business value, not on reinventing infrastructure.
  • Prefer mature, well‑understood tools (MySQL, Postgres, Python, etc.) whose failure modes are known.
  • Adding new tech adds hidden costs across the team; weigh marginal utility against added complexity.
  • New tech expands the space of unknown unknowns (e.g., unexpected GC pauses), increasing risk.

Team leads and architects should care because tech choices affect delivery speed, operational risk, and long‑term maintainability.

5/10
devopsarchitecturedatabasescareer

Related reading

  1. Everybody's Lost Their Minds

    The author argues that the AI hype wave is draining engineering resources without improving security, and that basic practices like inventory and automated patching are far more valuable. He warns that over‑reliance on AI‑generated code erodes understanding and makes debugging harder.

    Lobstersnetmeister.org6 minHN368338lobste.rs193

  3. Use Curiosity, Craft, and Care to Decide What AI Should Write

    The post proposes a three‑principle framework—Curiosity, Craft, and Care—to decide how much AI should author each artifact in a software development workflow. It argues that AI can be used aggressively for exploratory, disposable outputs (Curiosity) but should be limited for artifacts that commit the team to decisions (Craft) and for communications that require personal ownership (Care). The auth…

    Atomic Objectatomicobject.com4 min

  4. The pursuit of excellence does not need justification

    Opinion piece arguing that engineers should pursue excellence without needing to justify it, using anecdotes about a fast terminal emulator and a WordPress menu cache to illustrate how over‑engineering can yield unexpected downstream benefits, while also acknowledging the practical need for “good enough” decisions.

    Bjørn Johansenbjornjohansen.com2 min

  5. No Silver Bullet: Essence and Accidents of Software Engineering

    Brooks argues that software development’s fundamental difficulty lies in essential complexity—conceptual design, conformity, changeability, and invisibility—rather than accidental implementation issues. Consequently, no single technology or management trick will yield an order‑of‑magnitude productivity boost; progress must come from disciplined, incremental improvements.

    Hall of Fameunc.edu34 minpaper

  6. Small Programming Tricks

    A grab‑bag of command‑line, SQL, and JavaScript shortcuts – from fuzzy‑searching shell history with fzf to using `SELECT` without a `FROM` in Postgres, `git log -S`, and keeping an HTTPS agent alive in Node. The author argues that such bite‑size tips boost daily productivity and suggests sharing one per day on a team channel.

    Lobsterswill-keleher.com3 minHN661289lobste.rs62