In praise of “normal” engineers

Value of “normal” engineers and mature systems

• Many agree that sustainable products and “mature” services are best served by reliable, “normal” engineers working in well-designed systems.
• The best orgs are framed as those where average developers can consistently do good work, not places dependent on a few “rockstars.”
• Great engineers often start as good ones; healthy orgs nurture this progression and allow people to cycle between “great” and “good” as they learn new domains.

What is productivity? Business impact vs long-term risk

• A major disagreement centers on “the only meaningful measure is impact on the business.”
• Critics argue this drives short-termism, since avoiding disasters and long-tail risks is hard to quantify; they give examples where deferred fixes looked “high impact” until a public failure flipped the score.
• Some propose a more “holistic accounting” of effectiveness, recognizing invisible wins and human judgment instead of purely legible metrics.
• Others insist that avoiding landmines is itself major business impact, but note that leadership must already think this way for it to be rewarded.

Team composition, “10x” engineers, and hierarchy

• Multiple comments stress that orgs need a mix of people: specialists, strong generalists, and solid executors; too many “tigers” (brilliant but intense) or too many “penguins” (needing support) both fail.
• There’s broad skepticism of the “10x engineer” buzzword, but general agreement that some people are much more valuable, especially in leadership, systems design, or invention roles.
• Others counter that all engineers are “normal” and that fetishizing outliers distorts hiring and culture.

Management, culture, and ownership

• Strong emphasis on management quality: technically competent, trusted managers can recognize long-term value and shield teams from bad incentives.
• Some argue engineering managers/VPs/CTOs must be or have been real engineers; others note that taste and judgment matter more than simply having coded.
• Debate over whether the “smallest unit of ownership” should be the team or an individual:
  • Pro-team: resilience to attrition, illness, vacations, and fewer single points of failure.
  • Pro-individual: real ownership and agency often boost productivity and quality; team-only framing can reduce engineers to interchangeable resources.
• Several note that many engineers don’t actually want deep ownership; they see it as extra stress without equity-level upside.

Code quality, rewrites, and “art vs shipping”

• One axis of conflict: “software as art/design discipline” vs “software as just business output.”
• Some argue that high-quality code and thoughtful design dramatically reduce long-term costs and headcount needs, citing lean, high-performing firms with very small teams.
• Others respond that most businesses operate under hard constraints: limited budgets, uncertain futures, need to ship fast. From that vantage, “artistic” engineering is a luxury, especially in early-stage or low-margin contexts.
• There’s support for rewrite-heavy, prototype-first workflows (sloppy first draft → better second draft) as genuinely more effective, but many say management rarely allows the second draft once something “works.”

Diversity, resilience, and sociotechnical systems

• Several connect the article’s “build systems for normal people” to platform work and golden-path approaches: make the right way the easiest way so average engineers can ship reliable systems.
• Some push back on the claim that demographic diversity alone yields resilience; they argue real resilience comes from mature processes, role clarity, and adaptability—though mixed backgrounds can help teams handle life events and turnover.

Critiques of framing and incentives

• The term “normal engineer” is criticized as clumsy and potentially stigmatizing; “average” or “mid-curve” might fit better.
• A few see the piece’s de-emphasis on individual merit and outliers as aligning conveniently with AI/“anyone can be trained” narratives.
• Others highlight that poor internal documentation and knowledge sharing often prevent “normal” engineers from being effective, regardless of theory.