If you take a look at our team page today, you’ll see a little chart showing that almost all of our makers have a college degree, save one very small slice.
That slice is me.
My journey to becoming a software developer at Atomic is quite distinct because I chose that unique path. And I believe the confluence of each Atom’s unique paths and experiences create tremendous value for us and our customers.
Baby Steps
My journey started at age five, when my parents bought me a Texas Instruments 99/4A home computer. This was back in the 1980s, a time when the personal computer revolution was front-and-center. (It was also a very unequal time; personal computers were being marketed as things for boys, which left women at a major disadvantage when they reached college age.)
At that time, this machine that I could make do my bidding became an addiction. I remember my mother setting limits lest I lose entire days in front of the old TV set we’d connected to it. I saved my programs on a Radio Shack cassette player plugged into the side of the machine.
As I grew up, I moved from computer to computer, and once I started working and had spending money, I began to acquire my own hardware instead of depending on my parents. I strung cable through my parents’ basement to create a network, started playing with Slackware Linux, and used my slow modem to connect to the internet and find out what opportunities that presented me.
I did go to college—at Grand Valley State—while Carl was teaching there, no less. But because I didn’t learn well in the classroom and was much better working and discovering on my own, I typically found myself in the computer labs, developing my own programs and exploring the internet instead of going to class. My grades were suffering to a point I felt was beyond repair, and I decided to move on.
Learning to Walk
The first job I had in technology wasn’t a programming position, but rather the outgrowth of a high school job in shipping and receiving that presented an opportunity to build and administer a computer network. The electronic catalog for the sales team was designed to work on only one machine, but I helped build a solution that would let multiple people use the catalog at the same time.
From there, I moved to my first real job in the technology industry: technical support at one of the myriad local internet service providers springing up to take advantage of the beginning internet boom. I built a tool that helped us keep track of customers’ call history, a CGI script written in Perl. This was my very first business application used by others.
After doing all I thought I could do at the ISP, I moved to a startup that had hoped to get into offering high-speed internet. My job was to work on their networks and develop tools to keep the technical side of the business running smoothly. Here, I would learn firsthand the need for maintaining a sustainable pace, before I knew what to call it. (These days, I’m one of its biggest champions.)
As we were serving residential customers, we needed to be able to handle support requests late into the evening. But we hadn’t hired anyone who could handle more than simple cases except me. My workday was nominally 8 to 5, but I carried a pager. That pager went off almost every night, and I’d end up spending time working with customers.
I had just been married, and the stress of the few hours I had at home being compromised by work on a regular basis was doing harm to my new family life. Both my spouse and I felt resentment toward the company, and that led to yet more stress. The job was the definition of unsustainable.
Eventually, we hired more people to help with the load, but the stress had already taken its toll. While the nature of technology work sometimes requires us to step up and handle emergent issues outside work hours, asking people to sacrifice their lives as a matter of course is unhealthy for them—and will eventually harm not just the people doing your work, but the company as well.
Picking Up Speed
Shortly after, I moved on to a position doing internal application development and IT for a local manufacturer. They had a problem: A consulting company had delivered a solution for their warehouse operations, but they were unable to enhance it without paying the same company to develop enhancements.
I knew one of the key technologies, so I was able to get in and start helping immediately. The first thing I did was hack in a few enhancements, but it rapidly became clear that the parts of application code we could modify had serious architectural issues. I pitched a rewrite.
The rewrite went rather well; I was able to continue maintaining the old application and spend the time I needed to build its replacement in the best way I knew how. While the new application was architecturally sound, I learned one more very important lesson here about the inherent risks of rewrites.
Rewriting an application can help free an organization bound by technical constraints. It can open new possibilities. The thought of the shiny, new system making everyone’s lives better is often heady for everyone involved. But, as I learned, rewrites almost uniformly need to encompass every feature in the previously-deployed system, and they need to do it perfectly. It’s extremely challenging to dig up every case and do every one justice.
I made the serious mistake of assuming that I had entirely covered the needs of the rarely-used annual physical inventory application. I was wrong, my mistake idled a dozen people who couldn’t complete their work without key features I’d missed, and we had to roll back.
It was an expensive mistake, and very humbling. But I learned that day that a developer cannot go it alone. Working hand-in-hand with users and stakeholders, understanding their needs, involving them in the development process, and—most importantly—communicating to understand both advantages and risks is critical.
Standing Still
I continued to work at that job for quite some time. I also worked on a company intranet, which gave me plenty of interesting learning opportunities and the opportunity to work closely with users and stakeholders on a variety of projects. But I also got comfortable—perhaps a little too comfortable.
I realized I was important, and everyone, including me, felt I was needed to maintain the systems. But I wasn’t going anywhere in my career. I continued to work with software that slowly became more and more obsolete. Eventually, I figured out that I probably needed to move on, but I didn’t feel any particular urgency to do so.
Standing still in technology not only leaves you behind when the world continues moving forward. It also limits the breadth of experience you can get. Of course, depth is very important, and I don’t think I’d be quite as good at some parts of my job today if I hadn’t had the opportunity to really plumb the depths of my job back then. But the breadth I was missing cost me context.
I could confidently work with, intuit, and talk about the kinds of systems I’d come to know so well, but I couldn’t compare technologies, or even find my way effectively outside my comfort zone. And I stayed there a long time—too long.
Eventually, I did find another job in product development. It used more modern technologies, which I thought would solve my problem—and, frankly, it felt really good for a while. It did offer me a few new opportunities, but once again, there was depth, but too little breadth.
On top of that, a heavy wall between product ideation and development made both roles significantly less effective. And I was finding myself isolated in my development silo, unable to work with peers, unable to vet ideas, unable to cooperatively take inspiration on the best ways to do things.
I needed to find another place to be my best.
Me? A Consultant?
I knew I wanted to work on a team with peers. I knew I wanted in on the process of creating a product hand-in-hand with everyone involved. I knew I wanted to have more breadth in my career. Everywhere I knew to look, I found people who wanted someone with a lot of depth in an area where I didn’t have a lot of depth.
I’d been attending some more user groups in the area, getting more active in the less-toxic Twitter of that day, and making a few acquaintances who worked for Atomic Object. These people impressed the heck out of me. They were smart, well-educated, and seemed to know so much about a little bit of everything. I thought I’d love to work with these people, but I didn’t think I was qualified.
In reality, I’d made the classic impostor syndrome mistake of assuming that everyone around me was an expert, both in what I did and a lot more besides. A dear friend listened to my fears, gently explained that I knew much more than I gave myself credit for, and gave me the push I needed—a push for which I’ll always be grateful.
I visited Atomic’s then-fledgling Ann Arbor office and interviewed. I found people doing really interesting things. But I also talked a lot about the experiences I’d had, the lessons I’d learned, and the kind of person I was. It was quite a unique interviewing experience—different than any other I’d had before.
I had one serious concern. I said I didn’t know, exactly, how to be a consultant. But, as it turned out, I had some seeds already planted through the roads I’d traveled, listening to customers’ needs, and using my skills to help them do their jobs better. I found people who espouse Atomic’s core “teach and learn” value ready to help those seeds grow while I worked alongside them.
A Stranger in a Strange Land
Becoming a consultant wasn’t the only challenge I’ve experienced at Atomic, of course. I discovered that lacking a classic computer science education created one of the key problems I’m still working on: I don’t speak the language particularly well.
What I knew of computer science concepts, I’d learned from writings on the internet and experience tearing apart others’ software and making my own. Open source was a great mechanical teacher, but not such a great communication teacher. When it came to explaining concepts and understanding others, I found it challenging.
But that didn’t mean I couldn’t succeed. Throughout my career and especially as an Atom, I’ve learned a tremendous amount about how to communicate with my fellow developers as well as with other makers and customers. On this track, I discovered that my unique experience made me uniquely valuable inside Atomic, just as everyone else’s experiences has made them similarly valuable.
Every one of us brings a diversity of experience to Atomic, whether we were one of Carl’s students who transitioned into a job, we came in as a degreed graduate in a lateral move from another organization, we joined Atomic as an Accelerator straight out of college, or—yes—even if we made our way up to this point learning exclusively through decades of industry experience.
Walking on Toward a Bright Horizon
Unlike the work I’d done at that manufacturer, resting on my laurels for years, I’m still challenged four years and change into my tenure at Atomic. I’ve been on several different kinds of projects, learned many new things, worked alongside all kinds of different, wonderful people.
I’ve also started looking at new dimensions of work as well as self, made possible by the accepting environment I’ve found here. I never would have dreamed even five years ago that I’d be involved in helping shape Atomic’s future, building on our history of being a welcoming place to work for all kinds of people.
I can confidently say that it’s been a heck of a journey getting here, and I think necessarily a long road to get me to a point where I had the computer-science-equivalent background I needed to be an effective consultant. But everyone at Atomic has their own path that led here.
Some are long and lonely, others well-populated and well-traveled, but all of them offer unique experiences that have shaped us and made us integral parts of a company that draws strength from the unique offerings we each bring to the table.
I’m glad my road led here. I can’t imagine getting here another way. And as I look off to the horizon, I see that my road hasn’t ended, either. It’s just that now, I’m traveling with a fantastic group of people I’m proud to have along on my journey.