Discussing Architecture

July 10, 2016

The Most Important Engineering Lesson I Ever Learned

Let me tell you about something that completely changed how I think about software engineering. It didn’t happen in a computer science class or during my first job - it happened in a dusty metallurgy lab back in college. I was studying production engineering in the 2000s, and I had to take this hands-on materials testing class. Honestly? I hated it. The professor was this eccentric guy who’d lost a finger tinkering with CNC machines (and was weirdly proud of showing it off). The whole class was practical work - measuring things, testing materials - and I was struggling from day one.

But here’s the thing that stuck with me.

During one of our first sessions, after we’d spent the morning learning how to properly test steel samples, the professor asked us a simple question: “Why are we here? What are we really trying to learn?”

I figured it was about understanding materials, learning the vocabulary, you know, the obvious stuff. But he kept pushing us. “There’s something more fundamental happening here,” he insisted.

Finally, he laid it out for us: “Engineering has one overarching rule that you need to be mindful of in everything you do. Today we learned about measuring steel strength, but think about this - why don’t we build every bridge out of titanium instead of steel?”

The answer, of course, is that steel is good enough, but cheaper. Titanium might be stronger, but for most bridges, steel gives you the strength you need at a fraction of the cost.

“Engineering,” he said, “is about trade-offs. Almost every technical decision you’ll make has both pros and cons. If you don’t understand both sides, you’re not making an engineering decision - you’re just guessing.”

Now, years later as a software engineer, I think about that lesson constantly. Because here’s what I’ve noticed: we don’t always think like engineers in our field.

Have you seen this happen in your work? Someone encounters a performance problem and immediately says, “We should have built this in Go instead of Python.” Or they hear about Redis at a conference and suddenly every caching problem becomes a “Redis problem,” even when a simple in-memory cache would work fine. Or worse, someone reads about a shiny new technology and somehow it becomes the solution to whatever the company is struggling with, regardless of whether it actually fits. Don’t get me wrong - I’m not saying these are always bad decisions. But ask yourself: if you were working on building a skyscraper, would you be okay with someone walking into a design meeting and saying, “Hey, I just read about this new construction technique on BuilderNews - the team downtown is using it, so we should too”?

You’d want to know: What problem does it solve? What are the trade-offs? How does it compare to our current approach? What are the costs, risks, and benefits?

The Microservices Example

Take microservices, for instance. A few years back, it felt like every project was starting with a microservices architecture by default. But if I asked you right now, “Should you use microservices for your next project?” and you feel like you need more context to answer - that’s actually perfect. That means you’re thinking like an engineer.

Because the only correct answer to “Should we use microservices?” is always: “It depends.”

It depends on your team size, your deployment capabilities, your performance requirements, your organizational structure, your experience with distributed systems. It depends on whether you’re building a simple CRUD app or a complex system with multiple bounded contexts. It depends on your tolerance for operational complexity versus development simplicity.

That’s what real engineering decisions look like - they start with understanding the trade-offs, not with picking the technology first and justifying it later.

So next time you’re in a technical discussion, try asking: “What problem are we solving, and what are we trading off to solve it this way?” You might be surprised how often that simple question changes the entire conversation.