Inspiration as a Way to Growth - How deliberate exposure to inspiring inputs helps engineers mature professionally

In this episode of The Agile Software Engineering Deep Dive, Alessandro Guida explores the role of curiosity and inspiration in engineering growth.

Software engineering is often treated as a purely technical discipline — focused on frameworks, programming languages, architectures, and tools. Yet many of the ideas that shape engineering innovation originate far outside the software field.

Throughout history, engineers and scientists have drawn inspiration from mathematics, physics, philosophy, literature, and even science fiction. These disciplines expand how we think about problems, systems, and possibilities.

This episode reflects on why curiosity should be considered a professional capability — not just a personal trait. Engineers who explore widely often develop stronger problem-solving skills, more creative thinking, and a broader understanding of the systems they build.

The conversation also touches on the role of engineering leadership. Creating high-performing teams is not only about processes and tools, but also about cultivating environments where curiosity, learning, and intellectual exploration are encouraged.

Because innovation rarely comes from repeating what we already know.

It comes from exploring what we don’t.

If curiosity gives you the energy to push the limits of what others believe can be done, you are probably already on the right path.

If you enjoy thoughtful discussions about how engineering ideas evolve — beyond frameworks and buzzwords — this conversation is for you.

Please subscribe to this podcast — it’s the best way to support it.

If you are interested in the original article behind this episode, you can also subscribe to the Agile Software Engineering newsletter.

Transcript

SPEAKER_00 0:29

Welcome to the Agile Software Engineering Deep Dive, the podcast where we unpack the ideas shaping modern software engineering. My name is Alessandro Guida. I've spent most of my career building and leading software engineering teams across several industries. And today I want to talk about something that sits quietly behind many of the best engineering ideas. Inspiration. Software engineering is a discipline that often focuses on tools, new frameworks, new languages, new platforms. And while those things matter, they are rarely where the most interesting engineering ideas actually originate. Many of the concepts that shaped engineering thinking came from completely different domains mathematics, physics, history, sometimes even science fiction. The engineers who push the boundaries of what is possible are often the ones who are curious far beyond the immediate technical problem they are working on. They read widely, they explore ideas outside their field, and they bring those perspectives back into engineering. In this episode, I want to reflect a little on why curiosity is such a powerful driver of engineering creativity. Why inspiration often comes from unexpected places, and why one of the responsibilities of engineering leadership is to create environments where that curiosity can thrive. Because when curiosity gives you the energy to push the limits of what others believe can be done, you are probably already on the right path. So let's talk about inspiration in engineering. Let's dive in.

SPEAKER_02 2:14

Absolutely.

SPEAKER_03 2:15

Because whether you're prepping for a big meeting, or maybe you're just trying to avoid info overload, which is real, or you're just fiercely curious, this deep dive is custom-tailored for you.

SPEAKER_01 2:25

Yeah. The goal is really to give you those high-yield aha moments, but uh completely without the fluff.

SPEAKER_03 2:32

Aaron Powell Exactly, no fluff. And today's grounding material is I mean, it's a really fascinating one. We're looking at issue number 24 of an agile software engineering newsletter, and it's titled Inspiration as a Way to Growth.

SPEAKER_01 2:44

Aaron Powell Which sounds a bit like a corporate poster, but it's not.

SPEAKER_03 2:48

Right. It really isn't. The mission of our deep dive today is to explore this genuinely radical idea that uh inspiration and lifelong learning aren't just these buzzwords or like optional team-building exercises.

SPEAKER_01 3:00

No, no, no.

SPEAKER_03 3:01

The author argues they are deliberate ethical obligations for professional maturity. Which is a huge claim. So, okay, let's unpack this because it completely flips the modern tech industry's obsession with speed just entirely on its head.

SPEAKER_01 3:14

It really does. Because I mean, if you picture a modern software engineering team at work today, what do you see?

SPEAKER_03 3:21

Uh basically a high-speed digital assembly line.

SPEAKER_01 3:25

Exactly. The whole culture is built around velocity. You've got your two-week sprints, your daily stand-ups to report on blockers, you know, burned down charts tracking literally every minute.

SPEAKER_03 3:34

Everyone from the junior dev to the CTO is just hyper-focused on shipping that next feature as fast as humanly possible.

SPEAKER_01 3:42

Right. The entire system is optimized almost exclusively for motion. Like the prevailing anxiety in the room is always, are we moving fast enough?

SPEAKER_03 3:52

Which leaves like zero oxygen to ask if you're actually moving in the right direction.

SPEAKER_01 3:56

Yes. But imagine if, right in the middle of all that chaos, a senior manager walked into the open plan office, unplugged the routers, and said, Stop coding. Today you're gonna sit in a quiet room, listen to a lecture on, say, the history of bridge architecture, and read a book that has absolutely nothing to do with next week's launch.

SPEAKER_03 4:15

I mean, in most tech companies today, that manager is getting fired by lunchtime.

SPEAKER_01 4:19

Well, marched right out the door. Instantly.

SPEAKER_03 4:22

Derailing the sprint timeline is the ultimate sin. But uh the author points out that 20 years ago, that exact scenario was actually considered a foundational best practice.

SPEAKER_01 4:33

Yeah, they used to call them inspiration days.

SPEAKER_03 4:35

Which feels like such a lost art. Because modern agile methodologies, they're great for predictability, sure, but they essentially commoditized the engineer's time. A developer's week is sliced up into story points now.

SPEAKER_01 4:48

Right. Everything is a ticket.

SPEAKER_03 4:49

So how did these inspiration days mechanically work back then without completely halting the company's output?

SPEAKER_01 4:55

Well, they worked because the organization treated inspiration as a strategic long-term responsibility. It wasn't viewed as a short-term loss. On an inspiration day, the mandate was strict zero code gets shipped. Wow, zero. Zero. You completely disconnect from feature delivery. They would buy these profound, challenging books in bulk. They'd invite people who literally shaped the software profession to come speak.

SPEAKER_03 5:19

And they'd record the talks, right?

SPEAKER_01 5:21

Yeah. So engineers could revisit those ideas years later when they finally had the context to actually grasp them. The goal was deliberate exposure to ideas way bigger than whatever microservice they were debugging that week.

SPEAKER_03 5:34

Aaron Powell That is such a stark contrast to today, because if a company today wants to, you know, inject some innovation into the team, they don't give people a day to read.

SPEAKER_01 5:43

No, they throw a hackathon.

SPEAKER_03 5:44

Exactly. A hackathon or a time box design sprint. They lock everyone in a room with a bunch of energy drinks and say, hey, build something disruptive in 48 hours.

SPEAKER_01 5:54

Aaron Powell Which is inherently high pressure and totally output driven.

SPEAKER_03 5:58

Let me let me put an analogy to that. I feel like modern hackathons are basically like a sugar rush or fast food.

SPEAKER_01 6:04

Okay, like that.

SPEAKER_03 6:04

Like they optimize for speed and novelty and this immediate, highly visible output, right? You get a cool demo on Sunday night, but you crash afterward. Inspiration days are more like slow cooking, a really hearty meal.

SPEAKER_01 6:18

That's a great way to frame it.

SPEAKER_03 6:19

Right. You don't get that instant gratification, but it provides the sustained nourishment you need for long-term growth.

SPEAKER_01 6:26

That analogy is spot on, and it perfectly aligns with the source's most crucial distinction. The author states plainly hackathons produce artifacts. Inspiration produces engineers.

SPEAKER_02 6:43

Oh man, hackathons produce artifacts, inspiration produces engineers. That's powerful.

SPEAKER_01 6:49

It is. Because true engineering maturity isn't about how fast your fingers fly across a mechanical keyboard. It's about your capacity to reason deeply. It's your ability to make complex trade-offs and appreciate the long-term consequences of whatever architectural decision you're making today.

SPEAKER_03 7:04

Which you just can't hack together in a weekend.

SPEAKER_01 7:07

But okay, if true engineering maturity relies on this slow long-term reasoning, where did we lose the script? Like why did the industry shift so heavily away from this?

SPEAKER_03 7:16

Well, the author traces the shift back to something we almost never talk about in tech anymore.

SPEAKER_01 7:21

Which is Ethics. Ethics, really.

SPEAKER_03 7:23

Yeah. Specifically the Software Engineering Code of Ethics and Professional Practice. This was jointly published by the IE Computer Society and the ACM, the Association for Computing Machinery, way back in 1999.

SPEAKER_01 7:34

Wait, 1999.

SPEAKER_03 7:36

Yep. 1999. I gotta play the skeptic here. A code from 1999. That's uh that's before smartphones. It predates social media algorithms, AI, the gig economy. Shouldn't a code of ethics be totally rewritten to keep pace with modern tech?

SPEAKER_01 7:53

You know, that's the most common pushback. But what's fascinating here is why it hasn't been completely rewritten. It speaks to professional identity, not the tools.

SPEAKER_03 8:02

Oh, I see.

SPEAKER_01 8:02

Tools change constantly. The ethical obligations of building systems that impact human lives, those do not. The code outlines eight fundamental principles that govern the profession.

SPEAKER_03 8:13

Let me guess. Things like public safety.

SPEAKER_01 8:16

Exactly. The responsibilities to the public, the client and employer, the product, judgment management, the profession, colleagues, and crucially, the principle of self.

SPEAKER_03 8:25

Let's zero in on that last one, the self principle. Because the newsletter makes a really bold claim here. It says participating in lifelong learning isn't just an aspiration or some nice corporate perk.

SPEAKER_01 8:34

Right.

SPEAKER_03 8:34

It is a written professional obligation.

SPEAKER_01 8:37

It's a duty. If you're not actively expanding your mental models, you are technically falling short of the ethical standards of your profession.

SPEAKER_03 8:44

That's intense. So under that framework, reading a dense architectural textbook on a Tuesday afternoon isn't stealing company time.

SPEAKER_01 8:52

Not at all. You're fulfilling a mandate. And this ties directly into a vital safety clause found in the judgment principle, which the author details in the appendix.

SPEAKER_03 9:03

What does the safety clause say?

SPEAKER_01 9:05

It states that engineers must only approve software if they have a well-founded belief that it is safe and meets specifications.

SPEAKER_03 9:13

Let's put that in a real-world context for a second. Say you are a back-end engineer. Your product manager is just breathing down your neck to push a new payment integration live by Friday.

SPEAKER_01 9:23

A tale as old as time.

SPEAKER_03 9:24

Right. The PM says, look, it passes the happy path tests. Let's just ship it for the quarterly goal and we'll patch the edge cases next sprint.

SPEAKER_01 9:31

If you cave to that pressure, knowing the failure state handling is brittle, you are explicitly violating the judgment principle.

SPEAKER_03 9:38

But here's the catch. How do you even develop that well-founded belief in the first place? If you haven't been given the time to say, study how cascading failures work in distributed systems, you don't actually know if it's safe.

SPEAKER_01 9:51

Exactly. You're just guessing.

SPEAKER_03 9:53

And guessing isn't engineering.

SPEAKER_01 9:55

No, it's not. That's why the self-principle mandates learning. You need the vocabulary in the historical context to look that PM in the eye and say, no, if this API times out, it'll double charge users. We do not ship.

SPEAKER_03 10:08

Knowledge gives you the authority to push back.

SPEAKER_01 10:10

Precisely. And briefly, I should mention the author does map out some broader context in the appendix. Software engineering is still a young profession trying to define itself.

SPEAKER_03 10:19

Right. There are other codes too.

SPEAKER_01 10:21

Yeah, the ACM released a broader one in 2018 for all computing professionals. The UK has the British Computer Society's code, and the IEEE has a broader one for electrical engineers. The point is, the deepest thinkers in the field all agree. Building systems for the real world requires continuous, deliberate cognitive growth.

SPEAKER_03 10:42

Okay, but if we accept that continuous learning is an ethical obligation, how does a modern organization actually measure its success?

SPEAKER_01 10:50

That's the million-dollar question.

SPEAKER_03 10:52

Right. Because if it isn't producing immediate tangible artifacts, finance is going to have a fit. The source argues that sustainable innovation is widely misunderstood. It isn't just this steady stream of creative breakthroughs. You can't just lock people in a room and demand three disruptive ideas.

SPEAKER_01 11:08

No, you can't. Because innovation is actually a natural byproduct of raising an organization's cognitive baseline.

SPEAKER_02 11:16

The cognitive baseline. I like that term.

SPEAKER_01 11:18

Yeah. When you expose engineers to stronger mental models and better abstractions, their baseline capability rises. Capability becomes the decisive factor, not forced creativity.

SPEAKER_03 11:30

But the measurement problem's huge. Modern learning in corporate environments is evaluated so poorly.

SPEAKER_01 11:35

Oh, it's dreadful.

SPEAKER_03 11:36

We track attendance numbers at 50 people show up to the lunch and learn, or we send out those satisfaction surveys. Rate this workshop one to five. None of that proves that engineering judgment has actually improved.

SPEAKER_01 11:47

Because you can't capture improved foresight on a multiple choice survey.

SPEAKER_03 11:50

Exactly. So what does this all mean for us today? We can't go backward. We can't nostalgically copy the 1990s and buy everyone physical textbooks. How do we implement this?

SPEAKER_01 12:05

We need a modern blue kit for cultivating this judgment. And the author lays out four specific principles for what inspiration should look like in 2026. Let's hear them. First, it must be asymmetric.

SPEAKER_03 12:18

Meaning one really strong, deep idea vastly outweighs 50 shallow 10-minute tutorials.

SPEAKER_01 12:25

Exactly. Quality over volume. Second, it must be replayable.

SPEAKER_03 12:30

Because ideas need time to resurface and mature, right? You might read something as a junior dev, and it doesn't click until three years later when you face that exact bug.

SPEAKER_01 12:40

Spot on. Third, the inspiration must come from outside the immediate team.

SPEAKER_03 12:44

Growth dies in an echo chamber.

SPEAKER_01 12:46

Always. You can't just endlessly recycle the same assumptions with the same five people. And fourth, and this is the big one, the organization must respect that reading, listening, and thinking are legitimate work.

SPEAKER_03 12:57

That is a huge cultural shift. Staring out the window, thinking about an architecture problem has to be seen as working, even if the keyboard isn't collecting.

SPEAKER_01 13:04

Without that respect, the whole thing falls apart.

SPEAKER_03 13:06

And to facilitate this, the author shares this incredibly unconventional reading list for building interdisciplinary curiosity. I was enthusiastically reading this part because it is so eclectic.

SPEAKER_01 13:18

It really is. It stretches the brain in completely new directions.

SPEAKER_03 13:21

Right. Like they recommend Leonardo da Vinci's notebooks.

SPEAKER_01 13:24

Proving that art and engineering genuinely belong together.

SPEAKER_03 13:28

And Dan Brown novels.

SPEAKER_01 13:29

I know. That one sounds like a beach read distraction.

SPEAKER_03 13:31

It totally does. But when you think about it, those books are masterclasses in interdisciplinary puzzles and managing intersecting timelines. It's basically asynchronous, event-driven architecture, but in fiction.

SPEAKER_01 13:45

That is a perfect way to look at it.

SPEAKER_03 13:47

They also recommend studying the Apollo program. I mean, it achieved the moon landing with less computing power than a modern coffee machine.

SPEAKER_01 13:54

Which is humbling, frankly. It teaches you how severe resource constraints force elegant, highly optimized logic. You can't just buy more cloud servers to hide your sloppy code.

SPEAKER_03 14:04

Exactly. And math history, recognizing our modern algorithms stand on ancient ideas. Plus classic sci-fi Asimov, Clark, Stanislaw Lem.

SPEAKER_01 14:13

They were imagining the ethical constraints of the future decades before it even existed.

SPEAKER_03 14:18

It's all about building that cognitive baseline.

SPEAKER_01 14:20

And if we connect this to the bigger picture, if you're listening to this and you happen to be a manager, it is your core responsibility to create an environment where this kind of wide-ranging curiosity can thrive.

SPEAKER_03 14:33

It is the ultimate fertilizer for productivity. We just have to stop treating deep abstract learning as a distraction from real work.

SPEAKER_01 14:42

It's the foundation of professional engineering judgment.

SPEAKER_03 14:44

Well said. So, to distill this entire deep dive for you today, curiosity is not a luxury. It's a necessity. The fast food of a hackathon might give you a quick burst of visible output, but it will never build the architectural wisdom you need for the long haul.

SPEAKER_01 14:59

And I'll leave you with a final lingering thought that builds on all of this. Okay.

SPEAKER_03 15:02

Lay it on us.

SPEAKER_01 15:03

If the best ideas truly come from the most unexpected directions, what if the key to solving the most complex, insurmountable technical problem you're facing at work right now isn't hidden in a new software framework?

SPEAKER_03 15:16

Oh, wow, where is it?

SPEAKER_01 15:17

What if it's actually hidden in the pages of a 200-year-old philosophy book?

unknown 15:22

Yeah.

SPEAKER_01 15:22

Or, you know, in the structural design of a classical symphony.

SPEAKER_03 15:25

That is a wild, brilliant thought. And it's entirely possible.

SPEAKER_01 15:30

It really is.

SPEAKER_03 15:30

Well, thank you all for joining the conversation today. We're going to encourage you to do something radical. Step away from your code base today, just for a bit. Go feed your brain something completely unrelated to your job.

SPEAKER_01 15:42

Give some time to slow cook.

SPEAKER_03 15:43

Exactly. We'll catch you on the next deep dive.

SPEAKER_00 15:58

Thank you for listening to the Agile Engineering Deep Dive Podcast. If you found this episode valuable, feel free to share it with someone who might benefit. A colleague, your team, or your network. You can access all episodes by subscribing to the podcast and find their written counterparts in the Agile Software Engineering newsletter on LinkedIn. And if you have thoughts, ideas, or stories from your own engineering journey, I'd love to hear from you. Your input helps shape what we explore next. Thanks again for tuning in, and see you in the next episode.