Steve McConnell wrote Code Complete—a 900-page definitive guide to software construction—early in his career, about five years out of college, after discovering no comprehensive book existed on the actual practice of writing code, despite many books on requirements, design, testing, and project management.
He initially planned a 250-page book but, after creating a detailed outline, realized it would be closer to 900 pages; he committed to the project anyway, taking a year off work to write it full-time while living frugally.
The book was published by Microsoft Press, which expected it to be a modest “sleeper” title for their catalog, but it became a long-running bestseller in software engineering, with the second edition released in 2004—20 years ago—and still widely relevant today.
What is software construction?
Software construction refers to the full set of activities involved in turning design into working, shippable code—not just typing code, but also detailed design thinking at the class or module level, readability, testing strategy, debugging, iteration, and long-term maintainability.
It is distinct from higher-level software design (e.g., system architecture) and from the broader software development lifecycle (requirements, project management, etc.).
Before Code Complete, the literature largely ignored this space, treating coding as the “ignorant cousin” of software development.
Top-down vs. bottom-up design approaches
Some developers work top-down (deductive): they think abstractly about design first, then implement. Others work bottom-up (inductive): they learn by writing code in small increments and build up to general principles.
Steve deliberately wrote Code Complete inductively—starting with specifics and building to general principles—because he believed most programmers are detail-oriented.
He later realized the gap between these two modes is larger than he initially thought: many people are genuinely only capable of one approach, not both, and often cannot imagine the other way working.
This has practical implications: design documents frustrate engineers who think bottom-up, while top-down thinkers may struggle without upfront specs. Both approaches can produce good outcomes.
The case for rewriting code multiple times
Rewriting code—even two or three times—often produces better results than trying to get it right the first time, because each iteration incorporates lessons learned from previous attempts.
A famous Microsoft programmer was known for rewriting everything three times: a rough first version (learning), a second version (applying lessons), and a third (polished and correct).
Even accidental data loss can lead to better code upon rewrite, since you internalize mistakes and avoid them the second time.
The industry has largely moved away from rewrites due to continuous delivery models and version control, but the underlying principle—that iteration improves quality—remains valid.
Steve’s career philosophy: the career pyramid and avoiding “lily pad hopping”
Early in his career, Steve felt programming was “just a job” because hopping between projects didn’t accumulate into greater value—he called this lily pad hopping: moving from project to project without building compounding expertise or marketability.
To counter this, he created a career pyramid mental model:
Base: all programmers.
Middle layers: those with degrees, publications, leadership roles, or advanced degrees.
Top: individuals with lifetime significant contributions to the field.
He used this pyramid not as a rigid goal but as a directional compass—choosing projects and skills that would make him increasingly valuable over time, rather than just different.
He advises engineers to ask: Does this choice make me more valuable to my organization or the world? Even small decisions (project A vs. project B) should be evaluated for long-term compounding value.
Three areas of knowledge for software engineers
Steve identifies three domains engineers should develop:
Technology knowledge – strongest in junior engineers; necessary but not sufficient for career growth.
Business domain knowledge – critical for moving into architect or company-level roles where technical decisions are made on business grounds.
Software best practices knowledge – Steve’s own path; leads toward coaching, consulting, or training roles; less common as a standalone career path inside companies.
Going “all in” on technology alone is the most career-limiting unless you’re in a purely technical organization.
Moving into management requires embracing business needs—even when they conflict with what seems like the “best” technical decision—and many technical people struggle with this transition.
Management as a career path: patterns and pitfalls
A common pattern among technical people entering management: try it for a year or two, dislike it, return to IC work, reflect, then try again later—often becoming highly effective managers on the second attempt.
Unlike general business leaders, most technical managers don’t aspire to CEO/COO roles; they aspire to be VP of Engineering at a “cooler” company.
The zero-interest-rate era (2010s) made management seem like a low-risk, high-reward path, but now that growth has slowed, some former managers find themselves in awkward positions: not technical enough to return easily, and their scaling experience is less in demand.
Some engineering leaders (e.g., Mitchell Hashimoto of HashiCorp) have stepped back from executive roles to return to individual contributor work, highlighting that deep technical contribution remains a valid and fulfilling path.
The role of energy and focus in high-performing teams
Steve emphasizes focused personal energy as an underappreciated factor in team success—more so than process or tools.
Small, highly focused teams (5–15 people) consistently outperform larger teams, regardless of era or technology: Doom (core team <10), Instagram (11 people at acquisition), WhatsApp (50 at acquisition), Bluesky (12 engineers), early OpenAI.
High energy enables rapid correction of mistakes; low-energy, process-heavy environments let errors linger and compound.
This energy cannot be mandated by management—it emerges when the right people are hired into exciting, mission-driven contexts (e.g., early Microsoft, where staff averaged age 27 and were intrinsically motivated).
As companies age and staff age (e.g., Microsoft’s campus average age rising from 27 to 40 over 15 years), sustaining this energy becomes harder, and organizational needs shift from innovation to reliability.
Sustainable pace vs. burst mode
Steve and his long-time CTO rejected the idea of a steady 40-hour work week; instead, they worked in bursts—intense periods followed by recovery.
Like athletic training, a sustainable career includes sprinting, endurance work, and rest—not constant maximum effort.
Engineers should feel permission to coast after intense projects; the stigma around “coasting” is misplaced if it’s part of a sustainable long-term pattern.
The Agile movement’s evolution toward “sustainable pace” mirrors this insight.
What Steve would add to Code Complete today
The second edition (2004) aged well because Steve spent 11 years between editions, allowing him to distinguish lasting principles from fleeting trends.
Topics that remain highly relevant: managing complexity through abstraction and conventions, cohesion and coupling, iterative development.
Agile/XP were emerging during the second edition; Steve deliberately limited direct discussion, using XP in only one example—a decision he feels good about.
The convergence of technical iteration (for learning and error containment) with product delivery (CI/CD, mobile, web) has been a major shift since 2004.
AI’s impact on software development
AI is clearly going to change software development, but the nature of that change is still unclear.
AI enforces good fundamentals: To get reliable output from AI, you must write clear requirements, define test cases, and specify edge cases—essentially doing the disciplined software engineering we’ve long advocated but often skipped.
AI excels at the “happy path” but struggles with essential complexity: real-world messiness, off-by-one errors, subtle corner cases, and exception handling—the core of what Fred Brooks called “essential complexity” in No Silver Bullets.
AI is non-deterministic, unlike all prior programming tools, which makes it powerful but risky—especially when errors are subtle rather than glaring.
Code review becomes more important, not less: as AI generates more code, human oversight is critical to catch subtle flaws, unnecessary changes (e.g., an agent adding $800/month in unnecessary logging), or deleted tests.
AI can accelerate design exploration (e.g., pseudocode → multiple language implementations, brainstorming class designs) and is excellent for explaining unfamiliar technologies.
Engineers are becoming more full-stack across languages and platforms, aided by AI—where once specialists knew one language, now breadth is expected, and AI helps bridge gaps (e.g., backend engineers generating mobile PRs).
Historically, each programming innovation (assembly → C → OOP → etc.) added a layer of abstraction; AI may represent the next level of aggregation, though its non-determinism makes it fundamentally different.
The defining role of a programmer—figuring out what is exactly right—may not change even if AI handles more implementation; the job shifts to vetting AI output rather than writing from scratch.
Closing advice for a durable career
Steve’s core principle, applied both to writing Code Complete and to career development: “Does this make you more valuable to your organization or to the world?”
Avoid purely idiosyncratic pursuits that don’t compound; choose projects and skills that open doors and increase your ability to contribute.
Craftsmanship, curiosity, and continuous learning are timeless traits of great engineers—not because they’re trendy, but because they align with the intrinsic motivations that draw people to programming.
The goal isn’t just personal success—it’s increasing your capacity to make the world better through your work.
