The Most Valuable Lessons I've Learned Never Came from the Building Code

When I started Slate Drafting, I thought the hardest part of the job would be learning the building code. Every time I opened the Virginia Residential Code, it felt like another mountain to climb. Braced wall panels, wind loads, header sizing, stair geometry, fire separation, energy compliance, footing requirements—it seemed endless. I figured that if I could just become technically proficient enough, everything else would fall into place. Good drawings would produce good projects, and good projects would naturally produce satisfied clients.

Over the past several years, I've learned that I had it backwards.

The building code is actually the easy part. Difficult, yes, but easy in the sense that it's objective. It doesn't have moods. It doesn't care whether you're having a good day or a bad day. It doesn't hold grudges, make assumptions, or change its expectations halfway through a project. If you're willing to spend enough time with it, the code will eventually give you an answer. It may not be the answer you hoped for, but it will be consistent.

People don't work that way.

The most valuable lessons I've learned since starting my business haven't come from studying code books. They've come from difficult projects, uncomfortable conversations, unrealistic expectations, and the countless situations where something didn't go according to plan. Every one of those experiences has forced me to rethink not only how I design buildings, but how I run a business. Looking back, I realize those moments have shaped Slate Drafting far more than anything I ever learned about beam spans or wall bracing.

Recently, I found myself in the middle of one of those projects.

Ironically, the technical issue wasn't particularly extraordinary. It involved a narrow residential building with a front vestibule that had been incorporated into the design. During plan review, the City raised concerns about the wall bracing. Anyone who has spent much time working with the residential code knows that narrow homes can become challenging very quickly. Window placement, door openings, wall lengths, and overall geometry all begin competing with one another until there simply isn't enough wall left to satisfy the prescriptive requirements.

When the review comments arrived, I did what I always do. I went back to the code.

I wasn't looking for someone else to solve the problem. I wasn't looking for an engineer to bail me out. I wanted to know if there was still a prescriptive solution hiding somewhere in the calculations that I had overlooked. I evaluated continuously sheathed wall panels. I revisited alternate bracing methods. I recalculated portal frame options. I examined different braced wall lines and explored every code provision that appeared remotely applicable. Each time I found another possibility, I worked through the numbers.

Eventually, I reached the conclusion that there simply wasn't another prescriptive answer.

The project needed a structural engineer.

That conclusion didn't bother me.

What surprised me was everything that followed.

Somewhere during the process, the discussion quietly shifted. The focus stopped being, "How do we solve this?" Instead, it became, "How did we get here?" Before long, even that question transformed into something else entirely.

"Who is responsible?"

That single shift changed the entire tone of the project.

It's amazing how often this happens in construction. As long as everything is moving forward, everyone is collaborating. Owners, contractors, designers, and consultants all feel like they're pulling in the same direction. The moment a project encounters an obstacle, however, there's a subtle temptation to begin reconstructing the past. Everyone starts looking backward instead of forward. We stop asking what the next step is and begin asking whether someone should have seen this coming.

At first glance, that seems like a reasonable question.

Shouldn't an experienced designer know from the beginning whether a project will require engineering?

The more I've reflected on that question, the more I've realized it rests on a misunderstanding of how design actually works.

People often imagine that a building springs fully formed from the designer's mind. The owner has an idea. The designer creates the drawings. The plans go to the City. Construction begins.

Real projects are almost never that linear.

Design is an iterative process. Clients change their minds. Windows move. Doors get relocated. Stair locations change. Rooflines are adjusted. Rooms grow. Rooms shrink. Additions appear. Vestibules get added because someone realizes they prefer the way it functions. Every one of those seemingly isolated decisions changes the assumptions underneath the design. Structural behavior isn't determined by one feature. It's determined by the interaction of all of them.

That distinction is incredibly important because it explains why design isn't about prediction. It's about analysis.

One of the more interesting moments during this project came when the City's reviewer suggested trying another prescriptive bracing method. It was a reasonable suggestion. In fact, another engineer independently suggested the same approach. The problem was that I had already evaluated it. The calculations showed that it still didn't provide enough equivalent bracing length to satisfy the code.

That detail fascinated me because it illustrated something larger than this particular project.

If the answer had been obvious from the beginning, none of us would have spent time evaluating that option. The reviewer wouldn't have suggested it. Another engineer wouldn't have suggested it. I wouldn't have run the calculations. The reason multiple professionals considered the same solution is because the answer wasn't something you could simply assume. It required analysis.

Engineering doesn't begin where competence ends.

Engineering begins where analysis determines the prescriptive code no longer applies.

That may sound like a subtle distinction, but I believe it's one of the biggest misconceptions in residential construction.

Somewhere along the way, we've developed this odd belief that requiring an engineer somehow means the original design was flawed. I don't know exactly where that idea came from, but I've become convinced it's fundamentally wrong.

If a homeowner wants a twenty-four-foot opening across the back of their house, no one is surprised when an engineer sizes the beam. Nobody concludes that the architect failed because the beam wasn't prescriptive. We simply recognize that the design exceeded what the residential code addresses directly, so another professional becomes involved.

Wall bracing is no different.

The residential code is intentionally limited. It provides solutions that work for the overwhelming majority of homes. It also recognizes that there are situations where those solutions stop working. That's precisely why structural engineers exist. Their involvement isn't evidence that someone made a mistake. It's evidence that the project has reached the edge of the prescriptive code.

I've begun to realize that one of my professional responsibilities isn't just knowing the code. It's recognizing when I've reached the limits of the code.

That realization has changed how I think about responsibility itself.

Early in my career, I felt personally responsible for carrying every project across the finish line no matter what obstacle appeared. If something wasn't getting resolved, I assumed it somehow belonged on my shoulders. Looking back, I don't think that mindset came from arrogance. It came from wanting to provide exceptional service. I wanted clients to know I would do whatever it took to help them succeed.

There's nothing inherently wrong with that mindset.

The problem is that if you're not careful, "I'll do whatever it takes" slowly becomes "I'm responsible for everything."

Those are very different ideas.

As designers, we have a responsibility to produce competent drawings. We have a responsibility to understand the applicable codes, coordinate our documents, and recognize when another discipline needs to become involved. We do not have a responsibility to become the structural engineer, the surveyor, the geotechnical consultant, the contractor, and the permit expediter all at once.

Professional boundaries aren't barriers to helping people.

They're what allow different professionals to contribute their expertise effectively.

Another lesson emerged from this project that had nothing to do with engineering.

It had to do with revisions.

Clients naturally view revisions individually. Move this window. Shift this door. Add a vestibule. Enlarge this room. Each request seems small because it's evaluated in isolation. What often goes unseen is that construction drawings aren't a collection of independent sheets. They're a coordinated system. Change one element and dozens of other details may need to change with it. A relocated window can affect wall bracing. A moved door changes header calculations. A modified roofline affects elevations, framing, sections, and energy compliance. Every revision sends ripples through the entire project.

That realization has fundamentally changed how I think about revisions.

I've stopped viewing major revisions as edits to completed drawings. They're really a reopening of the design process.

That's an important distinction because reopening a completed design always carries more risk than designing it correctly from the beginning. Not because the designer becomes less competent, but because every additional change creates another opportunity for something to become disconnected from the larger system.

One of the practical changes I've already begun implementing is documenting those realities much more explicitly for my clients. If significant revisions occur after a drawing set has been completed, I want clients to understand that we aren't simply editing a few sheets. We're introducing new variables into an already coordinated design. That's a very different level of effort, and it deserves a different conversation.

Perhaps the most unexpected lesson from this project involved communication.

For years, I've gradually moved toward handling technical discussions through email whenever practical. Some people interpret that preference as avoiding phone calls. In reality, it's motivated by something entirely different.

Memory is unreliable.

Early in this project, I had a phone conversation regarding one of the design decisions. Months later, that conversation became part of the disagreement. Different people remembered it differently. I don't think anyone was intentionally misrepresenting what happened. I think we were simply experiencing one of the most common characteristics of human memory: it changes over time.

A two-minute follow-up email after that conversation would have eliminated the disagreement entirely.

That realization reinforced something I've been learning for years.

Email isn't about avoiding conversations.

It's about preserving them.

Written communication creates an objective timeline that memory simply cannot compete with. It protects everyone involved, not because it assumes conflict, but because it acknowledges that people are human.

Looking back, I don't actually consider this project a failure.

Far from it.

Technically, the project reached the correct conclusion. The prescriptive options were evaluated thoroughly. When they were exhausted, engineering became the appropriate next step. That's exactly how the design process is supposed to work.

The real value of the experience came afterward.

It forced me to examine my own business.

It made me realize that clients need better education about how design evolves. They need to understand that revisions have ripple effects. They need to know that engineering isn't evidence of failure. They need to hear early in the process that certain layouts may approach the limits of the prescriptive code. Most importantly, they need to understand where my professional responsibilities begin and where they end.

Those aren't drafting lessons.

They're business lessons.

People often ask what it takes to build a successful company. They expect conversations about marketing strategies, software, pricing, websites, or social media. Those things certainly matter, but I don't think they've been the most valuable teachers in my career.

The real education has come from difficult projects.

One challenging client teaches you to write a better contract. Another teaches you to define your scope more clearly. Another teaches you to document important conversations. Another teaches you to recognize when to stop redesigning and bring in another professional. Every uncomfortable experience leaves behind something useful if you're willing to examine it honestly.

That's the real school of hard knocks.

The tuition isn't paid in classrooms.

It's paid in long evenings, uncomfortable conversations, difficult permit reviews, and projects that don't unfold the way you hoped they would.

The tuition is expensive.

But unlike college, those lessons continue paying dividends for the rest of your career.

Looking back, I'm actually grateful for this project. Not because I enjoyed it, and certainly not because I would want to repeat it, but because it forced me to improve. The next client will benefit from clearer expectations. The next revision will begin with a different conversation. The next project approaching the limits of the residential code will include an earlier discussion about the possibility of engineering.

The building code didn't teach me those lessons.

People did.

And in the end, I suspect those lessons will have a much greater impact on the future of Slate Drafting than anything I ever learned about wall bracing.