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).