What makes a good engineer also makes a good engineering organization (2024)

Original Article ↗ Hacker News Discussion ↗

Tool mastery and the camera/filmmaker analogy

  • Several commenters dispute the article’s suggestion that deep knowledge of how tools work doesn’t strongly correlate with output quality.
  • They argue great filmmakers (or violinists) must understand parameters like lenses, exposure, lighting, etc. in depth, even if they don’t know how to build a camera or instrument.
  • Others defend the original point: you need to know “which parameters affect output and how,” not the physics or manufacturing details; knowing internals alone doesn’t make you a good artist.
  • Some note the phrase “how the camera works” is ambiguous and caused much of the disagreement.

What is “engineering” vs “typing” and where creativity comes from

  • One view: engineers measure, follow processes, and discover via conscientiousness and persistence; many software developers are just “typists.”
  • This is strongly challenged as elitist and unrealistic: much real engineering is correctly assembling known parts and designs, not reinventing or re‑measuring everything.
  • Creativity is seen by some as emergent and not reducible to persistence + IQ; simple ideas like Docker/Terraform are cited as counterexamples.

Software vs traditional engineering and standardization

  • A recurring theme: software feels “magical” and unprofessional because it lacks the codes, standards, and specializations found in civil/mechanical engineering.
  • One long thread argues most software is still bespoke, akin to pre‑code construction, and that tightly defined “ways of building” would reduce cost and chaos.
  • Others counter that languages, ecosystems, and backward compatibility constrain standardization, and that software’s diversity/fad‑driven nature makes heavy standardization both hard and, to some, undesirable.
  • There is broad agreement that software complexity can scale far beyond physical systems and that senior work is largely “managing complexity.”

Discovery, abstraction, and comparisons to other fields

  • Some see the essay as underplaying how much all engineering disciplines already use abstraction and discovery.
  • Defenders reply that the intro was a framing device, not a denial that other engineers discover things, and accuse critics of nitpicking side points instead of engaging the core argument.

Organizational design, Conway’s Law, and “black‑box” teams

  • Commenters like the idea that good organizations, like good engineers, deeply understand their own systems rather than treating every team as an opaque black box.
  • Conway’s Law is reframed: rather than doom, you can deliberately design the org to match the software you want, and continuously adapt structure as the product evolves.
  • A concrete example: separating fast‑moving UI/AI feature teams from slow, capacity‑planning infra teams greatly reduced frustration; grouping work by similar “velocity” made both sides more effective.
  • Many endorse the article’s core claim: vision and implementation should co‑evolve, and cross‑team understanding is crucial for large, non‑incremental change.

Funding, conventions, and constraints on “radical” orgs

  • One thread notes that external funding (especially VCs) pushes companies toward conventional structures and metrics, limiting how radical org design can be in practice.
  • Others speculate that AI‑enabled small teams might soften these constraints, making non‑standard orgs more viable, but this is presented as uncertain.

Engineers, business, and what to optimize for

  • There’s a long, conflicted debate about whether engineers should “focus on product” and let business people focus on profit.
  • One camp: the engineer’s duty is to product quality and solving customer problems; profit focus leads to “enshittification” and shipping garbage.
  • The opposing camp: it’s dangerous for engineers to ignore profit; code is ultimately a means to solving paying customers’ problems, and being involved in making that profitable is part of the job.
  • Replies try to reconcile this: caring about customers is caring about the product; the real tension is sacrificing product for short‑term profit vs sacrificing profit for long‑term product quality.

Signal as credibility test and lightning rod

  • Multiple comments invoke the author’s track record building a widely used secure messaging system as evidence that the organizational/engineering views are hard‑won, not naïve.
  • A large subthread then debates that system itself:
    • Supporters see it as a high‑quality, non‑VC, open‑source‑driven success and a positive model.
    • Critics highlight battery usage problems, disputes over openness (server code delays, F‑Droid/reproducible builds issues), centralization vs federation, and alleged ties to US government funding.
    • There are sharp disagreements over whether these issues are mostly “nerdy details” vs serious trust‑breakers.

Games, volume, and quality as analogy

  • The article’s Steam/Metacritic chart (more games, not more top‑rated games) sparks debate.
  • Some accept it as evidence that making creation easier increases output but not necessarily excellence.
  • Others argue ratings are relative and capacity‑limited (finite reviewers, shifting standards), so the flat line might reflect reviewer bottlenecks or rising expectations, not stagnant quality.
  • A side thread notes many once‑groundbreaking games age poorly as later titles refine their innovations, raising the bar.

Miscellaneous reactions

  • A few readers focus on the essay’s key takeaway: systemic change is impossible if every team treats every other as an abstraction layer; broad organizational self‑understanding is prerequisite to big leaps.
  • There’s appreciation for the color‑cycling landscape GIFs used in the post, with links and discussion of that animation technique.
  • Some lament the site being excluded from the Wayback Machine and share personal archiving strategies (PDFs, self‑hosting, alternative tools).