My programming career started in 2012 after a break-up, flush with money and time I would have otherwise spent on the relationship. I attempted to build a gesture-based interface device inspired by my childhood struggle with typing and writing. Scaling down this naively ambitious goal was necessary to get started. First step: debouncing five buttons in software. Hello world. Ultimately, after three years of working unusually long weeks, I accomplished creating a 10-key chorded keyer with a one-to-one key-to-output haptic display. In simple terms, you can type into the device, and it can type back to you. One can put the device in a mode to access a limited selection of terminal commands. I would set it to output a file, Alice.txt, put people’s hands on the keyer, and tell them, “It’s reading you Alice in Wonderland,” and watch their eyes widen. The haptics came about in looking for ways to acquaint users with the device after a failed attempt to embed modern (to today) auto-correction onto an 8-bit microcontroller. I won’t talk about the machine learning open courseware of the time or the absurdity of the embed target. It suffices to say I was very green and needed to grow quickly to produce a working result. Pivots were necessary.

Several years before my proclaimed start of programming, I flunked an Into to Programming course in high school. I found the fundamentals first approach to be tedious and pointless feeling. So this course wasn’t so much an intro to programming as it was an exercise and rapid eye blinking. The exact opposite was true when it came to the problem-first approach. The more I ran into roadblocks in an actual project, the more exciting the fundamentals became. If there is any distinction between an inventor and an engineer, it’s somewhere along these lines for me. I’m much more fascinated with why things work than how.

Until this point, we have talked about low-level embedded programming. It was a fundamental place to start, but as mentioned above, it was more of a matter of the target platform for me than starting with fundamentals. The next inflection point in the story came in 2015 when I got a bit burned out from those long weeks, and consumer market entry was far out of sight. I should backfill a bit to a trend pattern that I see retrospectively. During the keyboard years, I had gotten into another relationship, progressively putting in more and more resources. When she got an internship at a zoo in another state, I moved on campus with her. Waving to the Buffalo outside our front door and visiting the wolves was novel for a time. However, I quickly became homesick, and there wasn’t much other than my laptop and a fiber connection to keep me occupied. Having grown disenchanted with the hardware aspect of the business, given the scale of my operations, I started to think about the root of the problems I was trying to solve. Empowering people to communicate was the through-line.

With my early Intro to Programming experience, I never thought software would be my path. I was going to be more involved with the hardware, and I would hire developers. However, there I was, writing software with most of the product development time and loving it despite the mountainous challenges. Lackluster results burnt me out, not code. I reasoned that if I limited myself to software, I might be able to stick with bootstrapping. I came up with an idea based on my predicament. I set out to create a way to connect people of similar interests in real-time conversation. The implementation started with real-time text and graduated to video later on. Before that, I taught myself web development in the way I know best. Jumping right into implementing product features. Users would be part of the product. So, I built an authentication system from scratch after watching a video about properly hashing passwords. Initially, the variety of solution approaches in the ecosystem was intimidating. I knew I would focus on one thing at a time. Authentication was less of a step-change than debouncing the buttons. Those early lessons in asynchrony feed right into the web world.

I refocused my efforts again after a break-up. I moved back to my home state, completed a minimal viable product of the app I started at the zoo, got involved with the early stages of a makerspace, and mentored at an after-school robotics club. Going into 2016, I began to see the impending runway cliff. All the efforts thus far had been funded from the money saved to build a Tiny House for the first relationship and the generosity/mutually beneficial residence with my grandparents. I should have been stressed and focusing on nothing but job searches. Instead, I accidentally roped myself into building the makerspace’s electronic key entry access-control system from scratch on a zero-dollar budget before the grand opening. Prospective members donated pieces of hardware.

Given my lack of formal education, I wrongly reasoned that the title of Software Engineer was out of my league. However, I had a conversation with a meetup organizer that showed me how naive I still was. Retrospectively, He was actively recruiting but had a genuine interest in my experience, so I didn’t recognize the hiring motivation initially. He asked if I had thought about working at one of the local tech companies sponsoring the event. I mentioned my reserves about hiring requirements I’d seen. He gave me advice that I’ve heard many times since. Paraphrase; “People hiring care more about your capabilities and how well you’ll mesh with the team than anything specific in the listing.” I figured that was promising, emphasized how many practical things I had already created, and lamented having talked to a recent Computer Science grad who asked me what version control was. He laughed and asked me how much I was looking to make. I told him I had no idea; my last paying job was merchandising at a home improvement store. I quickly followed up and asked how much the base pay would be for a recent CS grad. He told me, and I was dumbfounded. “Wait… You’re telling me you would pay the guy who’s never used version control more than three times what I saved to work for free for the last three years?” It was not a strong negotiating position but an invaluable perspective. One that I took to an actual negotiation sometime after applying and getting an offer from a company interested in my web development experience gained with the handful of projects I’d been working on since I started at the zoo. The start date was the day after the makerspace grand opening.

Other than my self-assuredness, there wasn’t much belief in the access control project. Technically, I was not the father of the project. As with the makerspace, I literally and figuratively got in on the ground floor and opened the doors. Initially, I had offered to assist with a member management system. A neighboring makerspace had a fully built open-source system powered by everybody’s favorite single-board computer. Given ego and the practical limitations of one-off projects, we decided also to develop our own. The project’s initial advocate had started designing a modular system using the hottest new wireless Internet of Things chip. Unfortunately, life threw him a curve ball that limited his time on the project, and the makerspace Board grew concerned about the project’s deadline. At this point, I roped myself into taking responsibility for the whole project. It was a bit ambitious, but I had already started key parts of the system based on what I said I would help with. The initial advocate/lead gave me some test hardware, and I filled all of the software gaps until the last day before opening. The board meeting before opening was heated. The hardware was still not ready. I recruited the initial lead for the whole day before opening. I had a plan for at least deploying a minimal viable setup. I told the board that we would keep going until we finished it. One Board member motioned to budget for cutting keys for the founding membership. I pointed out the irony that more money was budgeted for the backup plan than the actual one. The board approved the budget; it wasn’t a risk we could take. On the day of the opening, I unlocked the front door with my electronic key fob for the person who showed up with a bag full of keys. “I can’t believe you did it,” he said, “Well, you wouldn’t believe what we had to do,” I replied, “I don’t want to know,” he said as if I couldn’t open the door with a paper clip and screwdriver. I laughed.

The next day, I started my first official job as a software engineer. I wasn’t sure what to expect, but I was startled by how hard it was yet easy-going at the same time. I had never so explicitly worked with other people’s code in such a vast array of microservices. On the other hand, I had never been responsible for such a minuscule part of a project. The company used a ton of tech that I had yet to explore, such as front-end frameworks, queueing systems, email delivery, etc. Along with new tech, I learned a lot about culture and process, primarily because of the contrast with my prior exposure. Catchphrases like “Get $h!t done” and “Ship it!” were plastered all over the office walls. Some people seriously embodied it, and others had a good laugh. I came in with an impression of how fast I could iterate on a project and was humbled by how complexity changes that. I was also caught off guard by the styles of working. Going in, I was used to putting my head down into a code base for 5 to 10-hour stretches. Interruptions like productivity ceremonies, foosball sessions, lunch breaks, team chat rooms, meme chat rooms, and “focus” groups were now challenging my workflow. Regardless of the negative implication of breaking my focus into chunks of 1-3 hours, I enjoyed the social aspect of the interactions and appreciated the people I was working with. I could have never played a game of foosball and just been a stick in the mud. Regardless, the biggest culprit was the ceremonies, which led me to an interesting observation that has continued since. Most developers express a distaste for meetings because of the disruption to their workflow. I found it ironic that the process efficiencies I had codified in my workflow came from the same principles driving those disruptive meetings. The process was out of touch with the original principals and not mindful enough of timing around contributor efforts. It was like an automatic motion, where no one knows why the motion exists, but it has always been there. Everyone does it, so it’s assumed to be best practice. I was too busy keeping up with the technical learning curve to shift focus to the issue. Do it again; my insight in that area would have been more valuable than my code contributions. Not that it was my responsibility, but bringing things back to “why” and strategically redeploying resources to align is my jam. So, said the “strengths finder” test the company paid for all of us to take, another “if I have to” write-off meeting for many. Sometimes, you need to take ownership when no one else does. Regardless of the difference in perspective, I got on well with my teammates, and we commiserated over the challenges and shared humor.

In the evenings, I was chiseling out the reliability of the access system. Battery backups, data caching, and system process management were essential to real-world use. At the same time, I was taking up responsibilities in the space as a Board Member or the Member Relation Manager. One might assume that Member Relations was a de facto position because I had the keys, but not so. That might have helped my case, with other board members less excited to acquaint themselves with the early minimally viable admin panel. However, even when I handed off that part of the system to another ambitious budding programmer, who streamlined it into a Customer Resource Management system, the other leadership struggled to match my enthusiasm for bringing new people into the space we built. It’s not a knock on them. Sometimes, they had other focus points, and I had a lot of enthusiasm. The different responsibilities revealed other problems that deserved other software-based solutions. Overfocus on member count drove me to create a reporting tool based on door use that showed activity as a leading indicator. Manually handling payments and constant communications about dues drove me to refine subscription payment notifications and database updates. My colleague working on the CRM inevitably implemented a fully automatic payment system. In the meantime, I paved the way by systematically creating associations between member preferred communication, their payments, and their key access: big problems and the smallest pointed solution to match.

At the moment, I didn’t think I was juggling too much until the engineering role changed to have an on-call schedule. Retrospectively, My first job as a software engineer ended due to inevitable burnout. After that time, I rearranged my roles at the space, becoming the Education Manager after stepping down from the Board and Members Relations. I created a calculator for teachers to quickly figure the price of their classes because I found discussions about per-student prices would soon become confounded by what they ideally wanted it to be. I knew if they lost money, it would be challenging to have the motivation to teach more. Slowly, volunteer work lost its luster as I found my original ambitions, giving technical learning opportunities to those who had difficulty finding those opportunities elsewhere at odds with the focus on a shared workshop. Increasingly, I found new life in the mountains. After three years of involvement, I resigned from my last position at the makerspace.

This is the first of my two-part programming story, which covers late 2012 to early 2019, when I resigned as Education manager. Some of the story is out of order because of overlap, so it picks back up in late 2017 while I was still working with the space. It is the first of a two-part essay.

Part 2