Write Great Code, Volume 3: Engineering Software

So what if I told you that, over the entire lifespan of a you know, multi million dollar app, the average software engineer only produces about ten lines of final code per day.

Yeah, just ten lines.

Ten lines. I mean, it sounds completely impossible, right, It's it's like someone building a house by laying literally a single brick every afternoon.

It really does sound absurd when you frame it like that, right.

But the digital infrastructure that you rely on every single minute, like your banking app or the computer's keeping your car on the road, you know, global financial networks, it's not built like a physical house or a suspension bridge.

Exactly because we can't see the steel cables, we can't measure the concrete.

Yeah, it operates by these invisible, almost bizarre rules.

It is the ultimate invisible infrastructure. Yeah, and I think because we can't physically watch it go up piece by piece, we just assume it's manufactured on some kind of you know, digital assembly line. Right, But the rules governing how software actually comes into existence are totally alien to traditional manufacturing.

Completely alien. So welcome to our deep dive today. We are exploring the fascinating and honestly just wildly misunderstood world of how software is actually built.

It's such a great topic, it is, and.

We're pulling our insights today from a really incredible source. It's called Write Great Code, Volume three, Engineering Software, and that's by Randall Hyde.

Yeah. Hi does just an incredible job pulling back the curtain on the entire industry here.

He really does.

And what makes this exploration so valuable is that he looks at the psychological and human elements of coding just as much as the technical frameworks.

Absolutely, so, our mission today is to decode the hidden processes, the crushing productivity traps, and those really radical management frameworks that software engineers use to construct the digital world around.

You, right, giving you a shortcut to being a much more well informed consumer of this.

Stuff exactly, or maybe even a creator of complex projects, because look, you interact with software all day, but tracing how it goes from just a vague idea in someone's head to a perfectly functioning tool on your screen, it reveals a staggering amount of human friction.

Oh massive amounts of friction.

So okay, let's unpack this.

To start unpacking it, I mean, we first have to look at the fundamental, unique nature of software itself. Right. Unlike a physical bradge or a car engine, software doesn't wear.

Out, right, there's no rest exactly.

Friction doesn't degrade code over time, and it's also highly customed. We don't have the equivalent of a standard universal integrated circuit that you can just snap together to instantly build any app you want.

Yeah, it's not legos, it's not.

And crucially, once the design is finished, it costs literally pennies to duplicate it a million times. The actual manufacturing cost is practically zero.

Right, So the real cost is entirely in the intellectual design and the implementation precisely, which means before we can understand how software is built, we really have to understand the peace people building it.

Yeah, the human element is everything here, it is.

And the source outlines four distinct historical metaphors for a programmer, and they perfectly track how the industry has had to evolve as the stakes got higher they do. So let's start with the first one, which is the programmer as artist.

Right. So the artist dates back to the very early days of computing, where coding was viewed as this mysterious, almost god given.

Talent, you know, like magic.

Yeah, like magic. The artist bends the rules, relies on pure natural aptitude, and often does their absolute best work when they are completely unconstrained by corporate oversight.

Just left alone in abasement somewhere exactly.

They're fantastic for solo, highly creative, intensely focused projects.

See. I always picture the artist like a solo musician recording a track in their bedroom.

Oh, that's a great way to look at it, right, Like, they.

Play all the instruments, they mix it themselves, they don't care about standard time signatures. The final product is pure personal expression and it can be totally brilliant. But a solo artist in a bedroom can't build a global banking system.

No, definitely not.

The stakes are just too high. When software started impacting human safety and you know, managing billions of dollars, the industry had to evolve. Someone needed to see the big.

Picture exactly, and that necessity birth the second metaphor, which is the programmer as.

Architect the architecture.

So if the artist is the bedroom musician, the architect is the composer writing complex sheet music for an entire symphony orchestra. Oh I like that right. The architect exercises large scale creative control. But they leave the actual building, the you know, coding of individual components to other people.

Got it.

They're focused entirely on the structural integrity of the big picture, because a badly designed building falls down and hurts people, and a badly designed software architecture can crash a hospital's life support.

System, which is terrifying. But the industry couldn't stop at architects either, because the demand for software just exploited. It really did, which leads us to the third metaphor, the programmer as engineer, And this one has a very specific, almost panicked origin story from the late nineteen sixties.

Right, Yes, the nineteen sixty eight NATO conference. Right at the time, the world was facing what they literally called the software crisis.

The software crisis.

Yeah, the demand for complex software was vastly outpacing the number of naturally talented artist programmers available. Yeah, I mean, budgets were spiraling, projects were failing left and right.

So they needed a reliable system exactly.

So NATO sponsored a conference and officially coined the term software engineering. The explicit goal was to take the predictable, standard building block approach of civil or mechanical engineering and just force us onto software development.

Okay, so, keeping with our music analogy, then if the engineer steps in, they are like the studio executive trying to mass produce pop hit.

Yes, exactly right.

Like they use standardized coord progressions and heavily enforced production schedules to just guarantee a baseline of financial return regardless of who is actually in the recording booth.

That is a perfect way to describe it.

But wait, if we treat programmers entirely like engineers on an assembly line, strictly following predetermined procedures, don't we completely kill the creative greatness of the code.

Well, what's fascinating here is that this is the exact historical tension highlights in the book. Oh really Yeah, software engineering was invented specifically to make less talented programmers reliable. Okay, it raises the floor of quality, ensuring a baseline of safety and function across a massive team. But by enforcing rigid bureaucratic rules, it inevitably lowers the ceiling.

Oh I see, it brings the top down exactly.

It restricts the truly great programmers from doing their best work. It actively discourages divergent thinking because in an engineering pipeline, divergent thinking is view as a schedule risk.

Which makes sense from a management perspective, but it's terrible for innovation, which brings us to the ultimate ideal. Right, the programmers.

Craftsmen, Yes, the craftsman.

This is someone who operates in that sweet spot between the artist and the engineer.

Precisely, if we finish the musical analogy, the craftsman is the master luthier building a custom strata areas violin.

Oh wow.

They intimately understand the strict physics and engineering of the wood and the acoustics. But they use that rigid knowledge to create something of profound artistic beauty.

That's a beautiful way to think about.

It, and their lifelong learners. They start as an apprentice, move to a journeyman, and eventually become a master craftsman by creating a masterpiece that proves their skills.

So they know all the rules basically exactly.

They know all the rules of the engineer, but they have the earned wisdom to know exactly when to bend them like an artist.

You know, think about your own workplace right now. Understanding these identities helps you recognize the different types of problem solvers, you're actually collaborate reading with Polly. If you are managing a team and you treat a highly creative artist like a factory line engineer, they are going to fail or they're just going to quit.

Oh, they'll quit in a heartbeat.

Right. Recognizing whether a specific task requires an artist's flare, an architect's vision, or an engineer's discipline is really the secret to unlocking any collaborative project, and.

That actually leads directly into the most dangerous trap in the entire industry.

Let's hear it.

If we increasingly view coding through this engineering lens, where we need to manage large teams, management naturally wants to measure their productivity.

Oh right, and this is where the industry's attempts to measure human output become almost comical, truly comical. First of all, the baseline skill gap is just mind boggling. The book points out there is a staggering ten to twenty times difference in productivity between average programmers and grand master programmers.

Yeah, just think about the mechanics of that. In literally any other field, you don't usually find a plumber who can pipe a house twenty times faster than the plumber and the next nameborhood.

Right, physical limits exist.

Exactly, but software is pure intellectual leverage. A grand master can look at a problem, synthesize the logic, and solve it in one elegant line of code, while an average programmer might take three weeks and five hundred lines of code to clumsily force the computer to do the exact same thing.

So how on earth do managers measure output when the gap is that wide?

Well, it's right, right.

For decades, the most popular metric has been lines of code, or LOC, and it is a wildly dangerously flawed metric.

It is, and it became popular solely because it's.

Easy to count, because it's just a number.

Right. You literally just run a script that counts the lines of text in a file. But measuring productivity by lines of code assumes every single line requires the exact same amount of intellectual effort, which is fundamentally false.

It's totally absurd.

A programmer might spend three agonizing days conceptualizing a really complex cryptography algorithm, but the final result is just two lines of code. Meanwhile, someone else could write four hundred lines of simple, repetitive formatting text in a single hour.

So using lines of code to measure a programmer is like judging the quality of a book strictly by its page count. Imagine a brilliant editor spending an entire day meticulously cutting a ten page rambling draft down to one single, devastatingly perfect paragraph. If you judge them by line count, that editor had a heavily negative productivity day.

It completely punishes elegance. I mean, in software, often the most productive, valuable thing a programmer can do is actually delete.

Code, making the system lighter and faster.

Precisely so, to get around the sheer absurdity of loc computer scientists develop more sophisticated metrics like cyclomatic complexity.

Okay, explain the mechanics of that, because this dives right into the psychology of coding.

Yeah, so, cyclomatic complexity abandons bulk size entirely. Instead, it measures the number of distinct logical paths through the code. Okay, it counts the decisions. You know that if this happens, then do that otherwise?

Do this branches right the actual logic?

Yes, And the reason this works is that it measures cognitive load. Yeah, the human brain can only hold so many competing threads in its working memory before it drops one and makes a mistake. Makes sense. So cyclomatic complexity measures how hard the human brain had to work to map out that specific piece of logic.

That makes so much more sense than just counting lines. But even utilizing better metrics, we have to circle back to that shocking reality check we started with.

The ten lines a day.

Yes, over the lifetime of a major software project, if you average out the total output, a typical programmer produces only ten lines of debugged, documented code per day.

It's wild.

I really want you to walk me through the math on that, because when I first read it, my brain just rejected it. How is ten lines a day mathematically possible?

Well, it sounds absurd until you map out the actual life cycle of a multi year project. On day one, a programmer might sit down and hammer out one thousand lines of code. It feels incredibly productive, right, they're in the zone. But that code doesn't exist in a vacuum. On day two, they have to write tests for it. On day three, they find bugs and have to untangle their own logic.

Oh okay.

On day four, they sit in six hours of meetings to discuss how their code interfaces with a database. Someone else is building always the meetings, and then on day thirty the client changes the requirements, so they have to throw out half of what they wrote and start over.

Right, the code is constantly rotting and needing maintenance.

Exactly, and eventually they have to rigorously document every function so the next person hired can actually understand it.

Wow.

So by the time that product is officially retired, maybe five or ten years later, the sheer crushing overhead of coordination, meetings, rewriting, and fixing mistakes dilutes that initial thousand line burst down to an average of about ten finalized lines a day.

That is just incredible. So the realization here is that the real way to speed up a project isn't typing faster. Typing speed is completely irrelevant, totally irrelevant. The bottleneck is the mistakes in the communication overhead. But when a project starts running late, management usually panics. Right always, they fall into the trap of confusing man hours with real time, which leads to something called Brooks's law.

Yes, Brooks's law is a fatal flaw in project management across the board.

What is it?

The assumption is physical? You know, if one person can dig a hole in sixty minutes. Two people can dig it in thirty minutes. Right, But software is intellectual, highly intertwined work. If you have a project that is running late, doubling the staff on that project does not have the time it takes to finish.

It doesn't.

No, it almost always makes it take longer.

Because every new person adds an exponential number of communication nodes. Exactly, the original programmers, who are already behind schedule have to literally stop working to explain this complex, invisible architecture to the new folks. The communication overhead absolutely skyrockets, dragging everything to a complete halt.

And when throwing bodies at the problem fails, managers predictably trigger what we call crisis mode. Oh no, they demand sixty to seventy hour work weeks. They order everyone to work through the weekend.

Which sounds productive on paper, right, But cognitive data proves this is mathematically counterproductive.

You aren't just getting diminishing returns, you are creating negative work.

Because of the cognitive load we talked about earlier.

Precisely, a tired brain cannot hold complex logic paths in its working memory. No way, a programmer operating on four hours of sleep on a Friday night at eleven pm is going to write a bug guaranteed, And because the logic is so intersigned, that single bug might cascade, taking three senior engineers four entire days to track down and fix the following week.

So they actually went backwards.

Yes, that friday night coding session literally destroyed a week future productivity.

This is such a critical takeaway for you listening right now. No matter what industry you operate in, if you are doing collaborative knowledge work, throwing more bodies at a late project just makes it later every time, and grinding your team for seventy hours a week destroys their net output.

Well, they survive by relying on structural models. They map out what's called the Software development life cycle THELC SDLC. Right, this is a framework broken down into phases conceptualization, gathering, requirements, design, coding, testing, deployment, maintenance, and eventually retirement.

That's a lot of phases, it is, and.

How a company forces its team to move through those phases dictates their entire working culture.

Which brings us to the models. The most primitive approach is the informal model, which is basically just hacking.

Yeah, just winging it.

You get an idea, you sit down and you just start banging out code. You skip the design phase completely. Now, it is incredibly fun and it's perfect for tiny, throwaway prototypes, but if you try to build a commercial banking app this way, it is an unmintainable disaster that will just collapse under its own weight.

Oh totally. And to avoid that disaster, the industry created a granddaddy of all formal structures, the waterfall model.

The waterfall model.

Yes, it is rigid, it is highly sequential, and it is heavily documented. First you spend months figuring out exactly what the requirements are. Okay, Then you spend months designing the architecture. Then you hand it to the coders, then you test.

It so step by step exactly, you.

Flow down the steps like a waterfall, and gravity dictates you never ever go backward.

It's exactly like building a skyscraper. You dig the foundation, you pour the concrete, you weld the steel, frame. You absolutely cannot get to the fifteenth floor and suddenly say, you know what, but we should really move the elevator shaft to the outside of the building.

Right, it's physically too late.

But software isn't concrete, it's totally malleable. Applying physical engineering constraints to a digital medium seems I don't know, fundamentally arrogant. It as soons you can perfectly know what you are building before you pick up a tool.

And if we connect this to the bigger picture, that arrogance is Waterfall's fatal flaw.

Right.

It assumes you know exactly what the end user wants before they have ever seen, touched, or interacted with the.

Product, which never happens never.

So to solve this, the industry invented the iterative and spiral models. Instead of pouring concrete, it's more like sketching with a pencil before applying ink.

Okay, I like that.

You build a minimum viable product and MVP, you give it to the users, immediately, watch how they actually use it, and then loop back to redesign based on their real world feedback.

Now I understand the logic, but I have to push back here, isn't it terrifying to start building something and when you don't even know what the final product will look like. Doesn't that just invite chaos into the budget and the timeline.

Well, it feels terrifying to traditional management because it requires a radical mental shift. How so you have to accept that you aren't building a finished, static product, You're cultivating an evolving system. You're managing uncertainty rather than trying to pretend uncertainty doesn't exist. I see, iterative models are entirely about risk mitigation. You don't spend two years and ten

Okay, that makes sense. And this intense desire to manage uncertainty to finally ditch those rigid waterfall factories sparked a huge revolution in the industry, the Agile revolution.

The famous agile. Right.

We hear agile used as a corporate buzzword all the time now, But at its core, agile is about straight sprints of work. It values functional working software over sick binders of theoretical documentation, and it demands constant face to face communication. But Inside the Agile framework, there's a fascinating, almost extreme offshoot. It's literally called extreme programming or XP.

Extreme programming takes the best, most effective practices of software development and dials them up to eleven.

It really does.

It relies on a set of strict rules that actively challenge almost everything traditional management stands for.

Okay, let's run through some of the wildest ones, starting with the concept of JBGE just barely good enough.

Oh, this is a great one.

In XP, heavyweight documentation is explicitly banned. You only write exactly enough documentation so the next person can pick up the code and understand it. No more five hundred page specification binders. But wait, if Agile bans heavy documentation, how on earth does a new employee know what they're supposed to be doing. Doesn't institutional knowledge just vanish?

Well, it forces the code itself to be the documentation. What do you mean if you have to write a ten page manual to explain what a single piece of code does? That code is too complex. JBGE forces programmers to write simple, elegant, readable logic.

Oh, so the code is so clean you don't need a manual exactly. That makes total sense, which brings us to TDD. Test driven development. Now, this is the one that completely broke my brain.

It's so counterintuitive.

It is. In traditional coding, you write the software and then you write a test to make sure the software works. In TDD, you literally write the test first.

Yes, it completely flips the psychology of coding. You write a strict test for a feature that doesn't exist.

Yet, which means the test fails.

Naturally the test fails, then your only job is to write the exact minimum amount of code required to make that specific test pass. Wow, not a single line. More. It ensures that every single piece of logic in your system is constantly automatically verifiable.

That is brilliant, and that leads right into the rule of simple design, which has just the greatest acronym. Ever, ya aga, you aren't gonna need it. The rule is you never ever write code for a feature you anticipate needing in the future. You only solve today's immediate problem, right like, don't build a complex data portal just because the marketing team might want to track analytics next year. Yag and I.

It aggressively stop speculative coding, which is honestly one of the biggest time wasterers in the industry, I bet. But the most controversial rule in extreme programming, without a doubt is pair programming.

Okay, I have to stop us dead right here. Pair programming. The rule states, you have two programmers sitting at one single keyboard.

One keyboard.

Yeah. One is the driver who physically types, and the other is the navigator, who reviews every single line in real time as it appears on the screen.

That's the rule.

Wait, hold on, you are paying two highly expensive six figure engineers to sit at one computer and do one job. How on earth does a manager justify that labor cost to the finance department.

Well, on a traditional spreadsheet, it looks absolutely insane.

It really does.

But the math is incredibly counterintuitive, and it goes right back to our discussion on the crushing cognitive load of debugging. Okay, finding and fixing a bug is exponentially more expensive than writing the code in the first place. When you use pair programming, it takes about fifteen percent more total man hours to write a feature, but it produces fifteen percent fewer defects.

So it's essentially buying an insurance policy against crippling bugs.

Exactly the navigator catches typos before the file is even saved. They suggest better, cleaner design patterns on.

The fly because they aren't bogged down on the typing.

Right, a solar programmer might get stuck for two days chasing a cascading logic error. In pair programming, that never happens because you have a second set of eyes constantly auditing the logic.

That's huge.

Plus, the institutional knowledge is instantly shared. If one of those programmers leaves the company, the other knows exactly how that entire section of code works.

So no single point of failure exactly. But XP isn't perfect, right, It has a fatal Achilles heel.

It does. XP requires an on site customer, oh right, Because you aren't writing five hundred page requirement documents. Someone officially representing the end user has to be sitting in the room with the development team available at all times to answer questions and steer the ship.

And that's the problem.

Yeah, in reality, clients have their own day jobs. Getting a customer to ship with an engineering team forty hours a week almost never happens.

Yeah, that seems like a massive roadblock. But you know, even if you never write a single line of code. Taking these concepts out of the software world for a second provide some really brilliant life acts.

Oh absolutely, think.

About how you operate in your own daily tasks. Yah, G and I you aren't going to need it. Stop over complicating the future and just solve the problem right in front of you. Yes, and jbge just barely good enough. How often do you overplan, overdocument, and overthink a project instead of just doing the work. You can use these exact frameworks right now to start procrastinating and start executing.

It really is a methodology entirely built around confronting reality exactly as it is, rather than how you planned it to be on a whiteboard.

Well said, We've covered a tremendous amount of ground today, from the solo artist hacking code in their bedroom to the rigid, factory like waterfall models, all the way to the nimble, paired up, test driven world of extreme programming.

It's been a journey.

It reveals the staggering human effort, the philosophical battles, and the psychological friction behind the digital tools we blindly take for granted every time we swipe the screen.

It serves as a great reminder that software isn't just cold math and logic. It is deeply human. It is organized, messy, brilliant human collaboration.

It really is, which leads me with one final kind of provocative thought for you to chew on.

Let's hear it.

We've talked extensively about how measuring a programmer's worth by lines of code is a terrible, outdated metric. Well, right now, artificial intelligence is getting in incredibly proficient at churning out bulk lines of boilerplate code.

It really is.

So if AI eventually takes over the manual labor of actually typing out all those lines, what happens to the human software engineer? Do we revert all the way back to the beginning of our metaphor list?

Oh?

Interesting, well, human programmers go back to being pure architects or artists, where we just dream up the concepts and structural safety and the machine acts as our master craftsman doing the building.

That is the exact frontier we are standing on right now. The tools are shifting rapidly, but the need for human vision, risk mitigation, and system level thinking is only getting more critical.

It's gonna be fascinating to watch. Thank you so much for joining us on this deep dive. Next time you look at the apps on your phone or check your bank balance online, we hope you have a whole new level of respect for the invisible suspension bridges holding it all together. Keep questioning the structures around you, and we'll see you next time.