Where the Software Ends

Where does your software end?

It wasn’t that long ago when the answer for me was simple. Software ended at the limitations of its own reach. At my first job out of college, I didn’t have access to my work email unless I was at work. I didn’t have a laptop to take home to finish up things on nights and weekends. We didn’t have a VPN, online email access, or the technical infrastructure to support a remote working policy until years later. So, I squeezed as much out of software as I could—whatever new opportunities it offered, I usually wanted.

Courtesy CommonLit.org
Courtesy CommonLit.org

These days, software’s reach often extends far beyond what I need to make it useful for the way I like to work. Granted, part of this belief is rooted in my own stubbornness (Because you see, back in my day…). Eventually, I’ve accepted and embraced many newer forms of technology.

But, another part of it is rooted in mindfulness. I try my best to separate the two.

For instance, I’m not a big fan of notifications on my iOS devices. I don’t get a ding every time someone sends me an email. My phone doesn’t buzz around my desk each time I get a Slack notification. These events happen frequently enough that the added sensory acknowledgment would merely make me stop paying attention to notifications altogether—and likely dismiss the really important ones (AWS alerts, calls from home, etc.)


“The purpose of software engineering is to control complexity, not to create it.”

Dr. Pamela Zave

Automation also has its limitations of effectiveness. I use a rudimentary online to-do list app that doesn’t sync to anything. Instead, I spend a few minutes at the end of the day manually transcribing tomorrow’s events from my calendar to my to-do list. To some, this might feel cumbersome. But, this gives me a moment to envision how I’ll spend my next day.

It’s also an opportunity to reconsider. Maybe that recurring Wednesday regroup isn’t valuable this time around. Maybe the goals of the meeting I set up last week were largely met since then. Perhaps I need to block out my afternoon to focus on writing code. I would lose that opportunity to evaluate my next day if software automatically synced things for me.

Whether it’s writing code on good principles, automated testing, refactoring early and often, continuous integration, or sprints, all of the techniques that software teams champion converge on one goal: To deliver new features faster. We’ve largely done a tremendous job of that. Software provides people with options—but, as consumers, we should actively decide which ones to take and which ones to leave behind.