Why I broke up with software development

When people hear that I have twenty years of experience in software development, they look at me strangely and ask, “Then why are you working as __________ (fill in the blank with my current position)?”

I think the underlying thought is - are you crazy? Software developers make big bucks, and with that comes influence and freedom. Plus, if you have a technical skill, you should use it. Why would you walk away from that?

I asked myself that too.

I have searched my heart to try to understand why I can’t bring myself to go back into a field with amazing people, challenging work, and worthy rewards. I think I’ve finally figured it out - I am passionate about the intersection of problem solving and technology. When the ability to make the best decisions to solve business problems is taken away, my passion for the work is destroyed.

I fell into software development in the 1990s because people would come to me with problems, and we often realized when digging deeper that software was the solution. Over many years I realized that the ability of that software to solve someone’s problem, whether it was creating Access databases to manage communication for victim services organizations in Ohio or building a SaaS solution to handle millions of job applications a year worldwide, was not just in the hands of the coder. The software’s success relied on the design (graphic designer), functionality (coder), usability (UX’er), training & help documentation (trainer), publicity (marketer), network (IT), support (ops), and many other technical experts. My team of software developers, engineers, DBAs, and testers could code a functionality accurate and reliable piece of software, but if it was dropped on an end user with no thought as to how it would fit into their day to day work, they would reject it as quickly if it was filled with errors.

Through many failures in my early development years, I learned how to foresee some of those problems. For more than fifteen years I led teams that worked hard to integrate marketing, operations, training, usability, and design into our software solutions. We collaborated on decision making regarding the roll-out AND functionality of the software. We built alpha and beta testing processes that integrated ongoing feedback loops into our software design and delivery process.

When our small startup was acquired we moved into a large organization that implemented textbook agile. The company took it to heart that the product owner made the business decisions and the software developers made the technical decisions. Software developers were there as experts, but they were assumed not to know much about the end user experience. Specs were dictated by end user requests instead of a true understanding of the business problem. In the rare times that the UX (end user experience) team was engaged, they were shipped the specs and without much discussion, shipped back wireframes. Training, instead of joining ongoing team meetings and strategizing about how to best support the end users, wanted to wait until “everything was coded and tested” so that they wouldn’t have to make changes to their training materials. Alpha user testing was purely for bugs, not usability. Integrated agile teams became just a method of outsourcing functions of the development process to various departments. Collaboration was limited to the development and testing teams. Product owners dropped in and out to make a decision when a sticking point was reached.

My passion was the artistry and technicality of software design with a focus on problem solving for business needs and end user experience. While being a technical expert is an important role, what I cared about most is how the end user is impacted. Many of the software engineers that I highly respect are motivated by the technical challenge. That’s just not the way I’m motivated. User satisfaction motivated me to answer the dreaded data center calls in the middle of the night. Solving problems was the part about software development that I loved. When you know that user satisfaction is impacted by a lot of non-technical decisions that are out of your control, it is demoralizing to build something you sense has business integration and usability flaws. That is why I left software development.

This is my story and I am not trying to imply that this is a flaw in the industry. I had a certain relationship with software development that is hard to find. I needed time to mourn the loss of that relationship. And I think my heart for software was broken. After I resigned, I made a few half hearted attempts to find roles in which I thought I could use my coding skills to solve problems. None of them seemed to be the right fit.

I look forward to the time when I have the heart to get back into the saddle again. And if you ask me why I am not in software development anymore, I can finally say that I have figured out my answer.