A couple of years ago, I participated in a story-telling program at my company. The final result was me on a stage in a real theater. I told the tale of how circumstance plus my refusal to accept a slow, painful pace of work took me from being a competent but standard mid-career developer to becoming an advocate for the developer experience on every project I am a part of. It’s a good introduction to my “why” in all this work, so I am going to rework it into a post here.

A decade ago I changed jobs, and states for personal reasons (that resulted in marriage, yay!) so I had spent the back half of 2015 papering Colorado’s Front Range with resumes. When I finally landed an offer, I did not know that I was soon to be starting on a project that hadn’t “gone to prod” in 2 years.

I was hired to be the new web frontend guy, but I saw too many issues that I couldn’t look away from. There were a couple devs playing the old Looney Toons “Duck Season” “Rabbit Season” with git push -f on the main branch, and the looming “production build” that was a pivot away from dev to configuration and installation on the system.

Oh, and that production build was set to happen inside a server room, where it’s a max of 60 on one side and a minimum of 80 on the other, all while sounding like a jet engine spinning up. You go in to start a process, then retreat to the calmer, quieter world, only to forget about your process and leave it waiting for far too long. “Toilsome” is putting it mildly.

I had been sold enough on the importance of the system that I didn’t understand what felt to me like built-in delays in getting this system out the door. After a few weeks of trying to sort out what felt so off, I started to dig back through my time at my previous job, and figure out what was so different

---

I moved up to New Jersey to take a new position in my company in 2010. On day one, I was introduced to Hudson (old heads know) and was enthralled with the power of the pipeline. A week before, I had been logging on to the prod box and running cvs update to get the latest copy of a site pushed out. Looking back, I love the fact that my first commit to the pipeline was a sub 30s failure run because I didn’t set up checkstyle right. The codebase was also modular with good domain separation, and would the pipeline would fail you if you violated the primary architectural patterns.

Working with a pipeline was the first time I felt like I had a superpower at work. I couldn’t make a lot of the mistakes I had been making because of this new system. I of course found ways to make new ones, but I also learned how to experiment safely. Almost nothing about the work we did felt painful, and so we were able to push the limits in a lot of ways throughout my time there.

---

So after having spent my formative development years in a place where development didn’t hurt at all, I was thrown into a place where it hurt a lot. But being the newest member on the team, I didn’t feel like I had the authority to push changes on everything. At the time, though, the web work was dry, and I asked if I could take a stab at making some process improvements. I spent a lot of time trying to piece together dependencies and deployment steps, and I ran across way too many readme’s that should have been runthis.sh’s. Once I got the technical in place, I had to start convincing people of its utility, which was surprisingly made much easier when I pointed out we always had a demo box ready, instead of needing someone to set something up when the need arose (usually eating up a few days of dev time)

Once I had the simple build-and-deploy going, I started to hear other squeaky wheels. The machine we were deploying to was bespoke. The dependencies were tied to OS-level packages. And so it went. I started collecting knowledge on how to improve every piece of this puzzle, bit by bit, and when we got something in place, I listened for the next squeaky wheel. If not for the pandemic, we would have implemented automated hardware detection on the backplane network by mid-2020.

If that were it, I don’t know that it would have changed my working life too much, but in the midst of making that transformation happen, I was asked to come help out other programs and spread the knowledge. And every time I did, I felt like I was unlocking something for the people in the room. The Agile Manifesto leads with “uncovering better ways of developing software by doing it and helping others do it”. Figuring out the balance between “doing it and helping other people do it” has been my mission ever since. This space will be hopefully be part of “helping other people do it”.