As a kid, I’d always dreamed of having my own arcade machine. For years I talked about building one, but this spring, I finally made that dream a reality. My wife and I are new homeowners who have recently delved into woodworking among other crafty endeavors. After purchasing several pieces of construction equipment, I thought, “Now’s the perfect time to finally make my dream into a reality.”
What I didn’t anticipate when building an arcade machine was how eerily it resembled my early days of programming. So much so that I thought it was worth writing a blog post about. I think as time goes on, we can forget just how stressful and intimidating learning to code can be. Hopefully my experience can encourage new developers as well as remind seasoned ones about the process of learning something new.
With that in mind, I’ve put together a list of a few things I encountered when working on my arcade project that resemble what it’s like to be an early developer. I hope these are insightful to you as well!
Remember those early days of programming when you would type into Google, “How to build a website?” You’re overwhelmed with options, which are only growing as time goes on. Ruby on Rails, Node.js, React, Elixir. Then there’s all the services like AWS or Azure who promise an “all in one” solution to help you build your site. Well, that’s the same feeling I had during my million and one trips into Lowes to buy tools I needed to finish my arcade project. Like programming, I didn’t find “one tool to rule them all,” but rather a patchwork of reusable solutions. I learned I needed a jigsaw for carving out the sides of the arcade. I needed a miter saw to perform basic straight cuts. Then there were the drill bits: countersink bits, Forstner bits, paddle bits. Almost as many bits as a computer!
It’s honestly scary how similar religious wars over construction tools are to those of the software world. Go to YouTube or Reddit, and you’ll find doctrinal debates over why Craftsman or DeWalt are either overrated or the best things ever. There’s even debates about where to buy tools. (P.S. Be prepared to hear everyone’s opinion about Harbor Freight.) Or people will tell you heartwarming stories such as how their father passed away and gave them some tools that they’ve been using for twenty years.
I’d nearly forgotten how intimidating it is to enter into a world with so many options and opinions. It’s helped me tweak my advice to younger developers coming in: “There are a million tools out there. Everyone has an opinion, and some people will fight you over theirs or make you feel bad for making the ‘wrong’ choice. In the end, you just have to pick something that’s simple, has broad support, and helps you get the job done. If it doesn’t work the way you want, try something else. There’s no single ‘right’ answer here, only tools to help you solve problems.”
Just like in software, I learned that there’s not simply one solution to a problem. Generally, there are three or four “acceptable” solutions most people go with, but creativity and invention are an option, too! For instance, in mounting my monitor to the cabinet, I learned that I could build or buy one of several different kinds of VESA mounts. The actual plans I followed used backer blocks to hold the monitor in place, but since my monitor was 2 inches smaller than the one in the plans, I went with the VESA mount option. Much like in software, the right answer to a problem is often answered with, “it depends” or “here’s what’s worked well for me.” And, just like in software, I’ve learned to trust the opinions of people who have been doing this for a while. I intentionally sought out the silver haired associates at the hardware stores to ask their advice, and they were always happy to give it.
When building my arcade, I bought some blueprints to help me along the way. The maintainer of the site was even kind enough to make some a YouTube video explaining how to do it. But even with all those resources at my disposal, I relearned a valuable lesson: the best plans in the world won’t prevent you from having to think for yourself. While the plans and YouTube video described the “what,” they often left out the “how.” For example, the first step of assembling my cabinet involved attaching the side panels to the bottom panel. These sides are made of heavy MDF board that need to be either glued or screwed to the bottom. In theory, that sounded simple. In practice, however, simultaneously holding the sides in place while drilling them into the bottom proved an arduous process.
At first I thought I would naively hold the sides in place while I drilled. But after about a dozen times of a side falling down or slipping out of alignment, I realized brute force was not doing me any good and was likely going to damage the wood. I thought this through some more, and realized that the actual problem was that I needed a stationary buttress to hold the sides in place while I attached them to the bottom. This made for a far less physically exhausting and quicker experience. (Remember, kids, physics is your friend. Use it to your advantage!) Had I continued with my brute force approach of “try and hold it all together,” I may have eventually gotten it, but I would have been utterly exhausted and the result likely wouldn’t have been as precise.
This has some obvious analogs to software development. Stack Overflow can give us developers technical answers. User stories can tell us “what” needs to be accomplished. Ultimately, though, WE are responsible for solving the problems in our projects. Sometimes when we’re stuck on a problem, we’re just going to need to sit down with pen and a paper (or our tool of choice) and think about how to solve it. Or, if that triggers anxieties harkening back to college, consider rubber duck debugging. As my dad used to tell me when working on something as a kid, “Don’t get yourself into a bind.” Take a step back and reorient yourself. You can only bang your head against the wall so long before you exhaust yourself.
This brings me to another point: take breaks! Just like programming, building an arcade cabinet was mentally exhausting with a bonus round of physical exhaustion. As I was saying above, skipping breaks and “powering through it” is rarely ever a good approach to solving problems. When we get exhausted, our mind isn’t as sharp as it was when we started our session. This problem also gets worse the longer we ignore it. Ever code late into the night and notice you start making more and more mistakes? The exact same thing happened to me on my arcade cabinet. I would come back the next day after a long session and realize I made dumb measuring mistakes requiring me to recut a piece of wood. Or I’d realize I’d wired the arcade buttons backwards so that they wouldn’t light up.
It’s tempting to think that powering through something will help us conquer it faster. Ironically, it will slow us down. It reminds me of an adage I once heard: “If you want to go fast, go slow.”
By far my most frustrating experience with my arcade cabinet was how the paint job turned out. In order to fill some screw holes, I applied some wood putty to the sides. However, I didn’t realize how important it is to sand down the surface in order to get the putty even with the wood. After I applied the first coat of paint, I realized how uneven the surface was. “No problem,” I thought, “I’ll just apply some more coats of spray paint.” But after about 5 layers of spray paint, I had only made the problem worse. I’d sprayed the paint unevenly, and there were lots of streaks and drip marks all over the sides. In frustration, I decided to just sand down the surface and paint by hand instead. While that did improve the streaks, the ugly patches of wood putty were still visible underneath. My wife warned me that if I kept trying to fix it, I’d be stuck in an endless cycle of sanding and painting. She was right. I wasted two days of work trying to make the sides perfect. In the end, however, there was a very simple fix: stickers! I decided to hide a lot of the putty spots by sticking fun video game characters over them. As an added bonus, I learned how to print vinyl decals on my inkjet printer and computer at home.
What lesson did I learn from this? Total perfection isn’t realistic and at some point becomes counterproductive. My neighbor knows many carpenters, and he mentioned that even the best ones are only highly skilled at hiding, not eliminating, all mistakes. I learned this lesson with code several years ago, but apparently I needed to relearn it with woodworking. At some point something has to be “good enough,” and we need to move onto something else. We need to take our mistakes in stride and use them as learning experiences instead of beating ourselves up over them.
Last night my wife and I played a round of Tetris Attack. We had a great time, and you know something else? Not once did I stare at the slightly janky sides of my arcade. I didn’t think about how the button labels were slightly misaligned, or how if I had used a different tool I could have built the machine faster. Instead, I just had fun enjoying the toy I’d created. Don’t get me wrong, I’ve pocketed all those lessons to apply to future tasks. But at the end of the day, most of what we makers create isn’t some pristine work of art designed to be housed in a museum and never touched.
Whether it’s software or an arcade machine, our creations are intended to be used and enjoyed by real people in the real world. That’s ultimately why we software developers do what we do.