Every software engineer should spend a week doing the job their software supports. Not shadowing. Not sitting in on calls. Actually doing it. Badly.
I just did. We're short-staffed on the sales side, so I've been jumping in — fielding inquiries, quoting customers, following up on leads, trying to close deals and ship steel out the door.
I am terrible at this.
The Disaster
My inbox is a war zone. I have threads with customers that I've lost track of entirely. I'll find an email from Tuesday that I was sure I responded to and realize I just... didn't. I have quotes out that I forgot to follow up on. I have follow-ups that I followed up on twice because I forgot I already did.
Sales people manage dozens of these threads simultaneously and keep them all moving. I can't keep six straight.
And the phone calls. I'm introverted. Genuinely introverted — not the internet version where you're shy at parties. The version where picking up the phone to call someone I don't know requires a small pep talk first. Every time. The anxiety doesn't go away just because I've done it ten times today. It resets with every dial.
I watch our sales guys pick up the phone like it's nothing. Mid-conversation with me, phone rings, they grab it, switch context instantly, handle it, hang up, pick up right where we left off. I could never.
The Part That's Actually Fun
Here's the thing though — when I actually close a deal? When I quote a customer, they say yes, and I'm coordinating with the warehouse to get material on a truck?
That rules.
There's something about selling a physical thing that hits different. This isn't a SaaS subscription or a digital download. It's steel. It's heavy. It goes on a truck, drives to a job site, and becomes part of a building or a bridge or a machine. I helped make that happen. Me, the guy who normally stares at a terminal all day.
I get why sales people love this. The dopamine hit of closing is real, and it's amplified when the thing you sold is something you can go touch.
Why I Keep Volunteering for This
This isn't the first time I've stepped into a role that isn't mine. And I always volunteer when the opportunity comes up. Not because I'm good at it — I'm clearly not — but because every time I do it, I come back to my actual job fundamentally better at it.
When you build software for a sales team, you make a thousand assumptions. How they track leads. How they follow up. What information they need at what point in the process. How their day actually flows.
Most of those assumptions are wrong.
You don't find out they're wrong by reading a requirements document or sitting in a meeting where someone describes their workflow. You find out by living it. By being the person who loses track of an email thread and thinking "why doesn't the system surface this for me?" By being the person who dreads a phone call and thinking "what if the system gave me a reason to call that isn't just 'follow up'?"
I built an entire ERP system for this company. I'm now experiencing, firsthand, every place where it could be better. Not in theory. In practice. Because I'm the one stumbling through the workflow it was designed to support.
That's worth more than any user interview.
The Missing Ingredient
I think there's a gap in how software engineers in certain industries develop. And I want to be specific about what I mean by "certain industries."
I'm not talking about building software for the digital economy — social platforms, games, streaming services. The users of that software are often engineers themselves, or at least people who live on computers. The empathy gap is smaller.
I'm talking about industries where the end users are people who fabricate things, farm things, build things, haul things, sell physical materials. Industries where the software is a tool in service of work that exists in the physical world. Steel. Construction. Manufacturing. Agriculture. Logistics.
In those industries, the people using your software often didn't ask for it. They have a job that existed long before computers showed up, and your application is something that got added to their day, not something that is their day.
If you've never done their job — even badly, even for a week — you are guessing at what they need. And your guesses are filtered through the lens of someone who thinks in systems and interfaces, not someone who thinks in phone calls and truck schedules and "the customer needs this by Thursday or we lose the job."
The best features I've ever built came from moments where I was doing someone else's job and thought "this is broken." Not broken in the software. Broken in the experience of the person using it.
The Actual Point
I'm not saying every engineer needs to go work a sales desk. I'm saying that if you build software for people who do physical work in the real world, the best thing you can do for your career is to go struggle at their job for a while.
You'll be bad at it. Your inbox will be a disaster. You'll dread the phone calls.
But you'll come back to your codebase and see it completely differently. You'll see the form that has three fields too many. The notification that fires at the wrong time. The workflow that makes perfect sense in a flowchart and no sense at 7am when you're trying to get a truck loaded before the driver leaves.
You can't build great software for people you don't understand. And you can't understand people by reading their ticket descriptions.
Go do the job. Be bad at it. Build better software because of it.