On Good Software Engineers
What makes a “good software engineer” is far less clear-cut than many hiring checklists suggest, argue commenters reacting to a blog post that tries to define the role in terms of proactivity, stakeholder focus and team alignment. Many push back on idealized traits and the reframing of “10x engineers” as mere high-output coders, emphasizing instead the ability to navigate ambiguity, reduce unnecessary complexity, deliver real business value and work sustainably with others. Several note that effectiveness is highly context- and domain-dependent, and that managers should design processes and expectations around the actual people they have rather than a mythical perfect engineer.
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.