Software Engineering is just another job now

A reflection on what changed in software engineering and how leadership must adapt

I spent every summer of my childhood in my father’s woodworking shop. He’s a craftsman: everything that came out of that workshop started from raw material and slowly took shape through an almost obsessive attention to detail. My father always invested heavily in learning and spent a lot of time experimenting: new technologies, materials, hardware, varnishes.

When I started working as a software engineer, I realized I was very similar to him. I studied constantly, spending nights reading and experimenting to understand the why behind things. It was a passion, and I always believed that was the right way to approach the craft.

Twenty years ago, being a software engineer was still something unusual. Most of the people entering the field were those who had been tinkering with computers since childhood. We were labeled as “nerds”, and it was hardly considered a real job.

But it was also a time when people would meet after work to talk about code. Heated debates about the “right” way to structure a module. We read software architecture books together for fun and aspired to become at least as good as the engineers we admired. I loved that energy. The feeling that we were all in the same boat, pushing each other to improve.

Today it’s one of the most popular career paths in the world. It pays well and is accessible through bootcamps and online courses. That’s a positive thing: it means the field is more diverse, more inclusive, and more representative of the real world.

But it also means the average motivation has shifted. The plumber doesn’t read fluid dynamics on the weekend. The accountant doesn’t study tax law for fun after dinner. We don’t consider them lazy or uninterested because of that. They do their job, they do it well, and then they go home.

Software engineering has reached the same point. People who spend their evenings exploring new tools, who genuinely enjoy going deep into infrastructure, still exist but they are far fewer. They’ve gone from being the norm to being the exception. You can see it even in the fact that nowadays it hardly takes more than a couple of words to explain what you do for a living.

This article isn’t meant to be a nostalgic moment or, as older generations sometimes complain, an “in my days…” kind of story. It’s more a reflection on how, over the years, this normalization has led many people to take on this role with a much lower level of curiosity about how things work, what lies behind them, and why they work the way they do. Today, people are often drawn to this job for different reasons.

But above all, it’s a reflection on how, because of that, leading teams made up of these kinds of professionals is very different compared to a few years ago. Different, but not worse.

We’re much less special than we think

My best friend works in the window and door industry. Last year he received a promotion within his company, becoming the head of the installation department. Among his responsibilities, along with many others, are training and developing the people in his team. It’s a priority for the company, because having independent employees makes it possible to parallelize the work and serve multiple clients at the same time.

He often talks about how difficult it is to find people who are truly interested in learning the craft, understanding how things work, and taking on responsibility.

Not long ago, a friend of my wife who works in the pharmaceutical industry received a similar promotion. One evening at dinner she was describing very similar challenges.

Even though those industries are completely different from each other, and different from the one I work in, the dynamics of leading people are often the same. Many of the problems you face are surprisingly universal.

Those two jobs, however, have something in common with the plumber and the accountant I mentioned earlier: no one expects their employees to spend their evenings studying how the hardware of a window frame works, or the chemical composition of the latest drug they have to sell.

Conversations like these made me realize that, all things considered, we’re not as special as I felt we were for many years while doing this job. And that, as a consequence, the expectations we set for the people we work with every day also need to change.

The myth of the passionate developer

A few years ago, while I was leading a team in a mid-sized company, we were releasing a feature that required significant changes to the infrastructure. During development, I asked the team if anyone wanted to take some time to dive deeper into how the new setup worked and what the architecture looked like under the hood. In my mind, it was a great opportunity to learn.

The response wasn’t what I expected. I remember feeling a mix of surprise and, honestly, a bit of judgment. In my head I was thinking: aren’t you interested in understanding the system you work on every day?

It took me some time to realize that the real question was a different one: why did I assume they had to be interested in it?

Over time, the answer I came to was that I was still looking at this job through the eyes of the person I had been fifteen years earlier. I was assuming that anyone doing this work today would naturally share the same approach, the same hunger for knowledge, and the same willingness to invest their free time to learn.

For me, that realization wasn’t easy to accept. For a long time, I interpreted a lack of curiosity as a lack of care. If someone wasn’t interested in understanding the infrastructure their application ran on, I assumed they were cutting corners. If no one wanted to discuss system design, I thought there was something wrong with the team’s culture.

What I was actually doing was projecting my own relationship with the craft onto everyone else. I was measuring engagement with the yardstick of passion, and anyone who didn’t reach my level of interest seemed like they weren’t trying hard enough.

The trend, objectively, is consistent: fewer and fewer people are interested in going beyond their immediate scope because they see this as a job, not as a calling. And that’s perfectly fine.

The myth of the leader who must build passionate teams

For quite some time, I told myself that it was also my responsibility if people didn’t have that same “hunger” to keep learning and digging deeper. That it was the leader’s job to create passionate teams, to spark that light in everyone, and that this was essential for a team to truly thrive.

When I started placing this job on the same level as many others, I realized that the perspective I had been looking from was fundamentally flawed. A leader’s role is to create the conditions for good work with the tools and the people they have. It is absolutely their responsibility to invest in the growth of the team and the people within it, and to help each of them find their own path. But that doesn’t necessarily mean everyone will be interested in doing so.

Reading this back, it might sound as if I’m saying that a lower level of curiosity or involvement is becoming the new normal. That’s not the message I want to convey. Passion for the craft still exists, it’s just not evenly distributed across every team.

What I mean instead is that it’s both unrealistic and outdated to assume that everyone in a team wants to reach the same level with the same level of interest. And that doesn’t mean we should judge them negatively if, in the end, they are still doing their job well.

I’ll admit that I still complain to my team sometimes when, for example, they don’t know the basic Git commands from the command line and do everything through their editor. But as long as that doesn’t create problems in the day-to-day work, it’s something I also need to learn to accept.

And when I feel frustrated that my team doesn’t share the same love for the craft that I do, I pause for a moment and ask myself: Is this really a problem, or is it simply different from what I’m used to?

Passion is optional. Competence is not

Despite everything I’ve said so far, we still have to deal with reality. The people you work with need to be able to make autonomous decisions in their day-to-day work. And to do that, they need knowledge you simply can’t afford to be missing.

You can’t accept a situation where no one on the team understands how the infrastructure behind the product works, or where no one can grasp the implications of an architectural decision.

Once you accept that passion is not a requirement, competence still is. And the question becomes: how do you help people develop the necessary knowledge when they don’t have the natural drive to dig into things on their own?

Here are a few things I’ve seen work.

Connect knowledge to a real problem and not to an abstract concept
People who work with me know my approach to problems: I let the “pain” be felt so that solutions can emerge. This situation isn’t any different.

Helping people understand the risks of not knowing something, or showing how a specific piece of knowledge solves a real problem they are facing, works much better than theoretical discussions about best practices. People invest energy when they see that the knowledge will help them solve a problem they can actually touch.

Make learning part of the job
We can’t expect people to spend their free time diving deep into technical topics. Instead, give them the space, time, and resources to do it during working hours. Learning is part of the job, and everyone ultimately benefits from that growth.

Distribute responsibility
When you have one or two people who naturally “figure things out”, the temptation is to let them handle all the deeper work while everyone else simply follows instructions. This works in the short term. In the long run, it creates a team that depends on one or two people for every non-trivial decision.

Instead, assign the responsibility of understanding a specific area to someone who normally wouldn’t own it. When ownership is yours, the incentive to understand things tends to appear much more naturally.

Protect the people who are still curious
The engineers who are genuinely passionate can easily end up in an uncomfortable position. They become the go-to person for every complex problem, the ones who always volunteer for the hardest work. That’s the fastest path to burnout and resentment.

Your job is to make sure their curiosity becomes a strength, not a trap. Give them space to explore, but don’t allow the team to dump every complicated task on them just because “they enjoy it anyway.”

Stop measuring commitment through passion
This is probably the most important point. A developer who works their eight hours, writes solid code, participates in reviews, and then closes their laptop at 6 p.m. is not contributing less than the one who stays late because they enjoy it. They are giving exactly what they are paid for: consistent, reliable work.

The fact that they don’t read technical blogs at night or attend meetups on the weekend says nothing about the quality of their work.

TL;DR

Software engineering has become normalized. Most of your team treats it as a job, not a calling and that’s perfectly healthy. Passionate developers still exist, but they are the exception. Passion is not a requirement, competence is.

Our job as a leader is to ensure that the necessary knowledge is acquired without relying on passion as the driver: connect learning to real problems, make it part of the work rather than an extra, and distribute responsibility instead of always leaving it to the same people. Protect those who are still curious, and stop confusing commitment with enthusiasm.

Credits: Illustration 1