On Good Software Engineers

Defining a “Good” Software Engineer

• Many see long trait lists as idealistic checklists that don’t match real workplaces; some call them vacuous or overthought.
• Others value them as directional visions and coaching tools, helping managers explain expectations and gaps.
• Concern that over-defining “good” leads to bad hiring practices and fetishizing labels (senior/staff/10x) instead of getting work done.
• Several note that expectations must fit domain and context; what’s “good” in one problem space can be inadequate in another.

10x Engineer Myth and Productivity Variance

• Strong disagreement about 10x engineers: some insist they clearly exist (and even 100x), others see the label as unhelpful or mythologized.
• Clarification that classic studies measured best vs worst (or minimally competent) performers, not best vs average.
• Some argue high output and high quality often coincide; the stereotype of the unmaintainable “rockstar” is overused.
• Others report seeing highly skilled but fad-driven engineers who harm the SDLC with flashy but fragile architectures.
• Multiple comments suggest focusing on 2–3x improvements and 10x teams, not heroic individuals; org friction and compensation systems often block this.

Problem-Solving Mindset, Grit, and Learning

• One core differentiator proposed: ability to navigate the unknown independently versus needing constant guidance.
• Teachers report a “click” where learners stop asking for every answer and start self-directed problem solving, but note some never reach it.
• Emotional barriers are seen as more limiting than raw intellect; tenacity/grit (“head against a brick wall”) is emphasized.

Complexity, Abstraction, and Simplicity

• Repeated theme: good engineers reduce unnecessary complexity and avoid dogmatic over-abstraction (SOLID/DRY/etc. misapplied).
• Counterpoint: complexity is often subjective and socio-political; abstractions are usually justified as simplifications, making removal contentious.
• Suggestions include YAGNI, careful timing of abstractions, and measurable metrics (cyclomatic complexity, dead code) as guides.

Business Understanding, Process, and Responsibility

• Many argue understanding real stakeholder needs and business processes matters more than pure technical elegance.
• Frustration with “process people” and business ops dictating technical solutions they don’t fully understand.
• Common anecdotes: rushed “business needs this ASAP” changes that create long-term messes, with maintainers later blamed.
• Some dislike expectations that engineers “drive big projects,” seeing it as unpaid project management; others see cross-functional influence as part of being effective.

Tone, Audience, and Missing Perspectives

• Some find the article manager-centric, tuned to “nice tech companies,” and less relevant in legacy/“atoms” industries.
• Desire for more grounded stories: survival through layoffs, working with internal clients, balancing family or sports, long careers in non-glamorous environments.
• Several stress that manager and PM quality can outweigh having a single standout engineer; modest, consistently responsible engineers often create more day-to-day value than any mythical 10x.