The Gift of Beginner’s Mind, Part 2
This post is the second in a series of posts about my beginner’s mind as a software engineer. The first post is “Part 1: Making Sandwiches with Martians”. Read the bolded text for a 30 second summary.
It’s the end of week 6. I can already notice my brain rewiring. Every night when I come home after a 12-hour day at Hack Reactor, I feel an energized feeling, as if I can sense the new clusters of information zipping through the newly formed neural connections in my brain. I haven’t felt this feeling on such a consistent basis since my language immersions in Brazil and Peru. After 2 months of part-time prep for Hack Reactor and 5 80-hour-weeks in Hack Reactor, what do I notice that’s different?
I am no longer as bothered by bugs in my code. When I first started coding, any bug got me incredibly frustrated, because I wasn’t sure what to do. Now, I often enter a methodical mind state when I encounter a bug. It’s less a feeling of “why won’t this work?!?!?!?! Noooooooooo… drops to knees and shakes fists at the sky” and more a feeling of “OK, what can I do to get the information I need to solve this?” Of course, I still have moments where I want to throw my computer out the window. Our instructors tell us that unfortunately, these feelings never go away. However, my now countless experiences of encountering a mysterious error that I literally could not even attempt to guess, logically stepping through code and finding the error, and having my program work afterwards, have given me the confidence that I’ll figure out any bug eventually.
In fact, when debugging, I’m almost as excited by finding new bugs as I am by finding a solution. That’s because a new error means that I’m that much closer to getting to the root of the problem and solving it. To give you an idea of the emotions you experience during this process, it’s like you are preparing for a dinner party, and trying to bake a cake, but your cake keeps tasting terrible. You bake 20 cakes, and each one sucks. Finally, you realize that you were adding tablespoons of salt instead of teaspoons of salt. Your next cake tastes amazing. At that point, you realize that your next “bug” in your party preparations is that your salad dressing doesn’t taste very well. But you solved the mystery of the cake and are that much closer to throwing an epic party. You also have this legit cake that you can marvel at and snack on while you’re debugging the salad dressing. The idea that I would get excited by finding a new error is mind-blowing, but makes total sense now that I’ve been through the process many times.
A personal analogy is learning to read and write in Portuguese. At first, all of the words tended to be one barely intelligible mass on the page, but as I learned more words and phrases, I started to recognize more of what I read, until I noticed typos in newspaper articles. Like native Portuguese speakers, I had gained the ability to thin slice the page into words. As a result, I interact with web and mobile applications in a completely different way. A useful analogy for my new perception is surfing. When you first learn to surf, you look at waves breaking and think, “OK, those waves look decent. I think I could surf those.” After more experience, you would look at the same waves breaking and think, “the waves are about head high, about 5 minutes in between sets, and 5 waves in each set. The waves aren’t pushy enough for a shortboard, so I’ll take my longboard. There are slight whitecaps and it’s 10am so I’d better get out there before the wind picks up further and the water gets too choppy.” You notice details that previously you weren’t even aware you were missing. It’s fascinating.
When I think about how I’ve dealt with bugs I’ve encountered lately in other people’s software, it’s not that my troubleshooting is different. For example, last night my Facebook iPhone app was abruptly closing whenever I opened it. I tried opening several other applications, determined that it was just a problem with Facebook’s app, and deleted the app and re-installed it. Prior to learning to code, I would’ve done the same thing. The difference is my process and my mindset. One specific example of how my process has changed is that I now ask myself the “debugger’s question” that we’ve been taught at Hack Reactor: “what component(s) of the program justifies my unmet expectation that the currently broken program should in fact work?”
I know more about the process of being a good software engineer, not just the content. Being a software engineer is not so much learning a concrete set of rules and procedures, as say an accountant or a lawyer might do, but rather learning how to find a decent solution to a problem you may never have seen before, given tools that you may have never seen before that may not always work, unclear guidelines, and sometimes no previously completed example to build on, as say a special forces operative might do. Yes, I’m aware that Navy SEALs end up in slightly more chaotic situations than software engineers, but the analogy nonetheless provides a useful mental model.
Finally, I have more fun coding, because I experience more frequent successes. As I mention in a previous post on “Following Your Passion”, learning a useful skill involves persevering through hours of frustration and confusion as a beginner. Sure enough, as I learn to use more frameworks, idioms, and techniques, my abilities as a programmer improve, along with my enjoyment of the process. As a result, it’s been surprisingly easy to put in long hours. I predict that when I start building larger applications, I’ll have even more fun!
Originally published at www.shanemkeller.com, April 2014.