Over the last couple of weeks I dealt with a programming problem that was extremely difficult for me to solve. In total it took me about 70 man hours of work to conquer something that I initially figured would take a day, at most. After 70 hours of work, I had finally overcome this beast of a problem, and I was overjoyed. I’m not exaggerating when I say that I literally teared up when my program worked. Over the course of solving the problem, I discovered a lot of different things about the nature of what it means to learn, and to solve problems in general. Here are some of the lessons I learned along the way.
You may learn more than you bargained for.
Without getting into a ton of technical detail, the problem I was trying to solve involved websockets, HTTP traffic, and a lot of binary mathematics. Before I dove into it, I knew virtually nothing about any of the aforementioned topics. If you’re a programmer, you know that a lot of the low level stuff gets obfuscated, so you’re left with just the details of your program instead of having to reinvent the wheel on some already existing technology. So, like a lot of us, I knew that network traffic was a thing, but I paid little attention to how it actually worked.
Over the course of this endeavor I learned (in no particular order) how to read and understand hexadecimal values, bitwise operators, rudimentary binary math, how HTTP headers work, how to use Wireshark to understand network traffic, the entire process of websockets from handshake to data framing, and how to use Fiddler. There’s probably more, but I figured you got the point. None of that stuff is what I set out to learn. I just wanted to try and use some new-fangled technology called websockets.
At this point I would say that I’m proficient in a variety of new skills, and that I have an expert-level understanding of websockets. Those are skills I never expected to pick up, and while they may not be ones I use every day, they’re important for growing my overall skillset. Plus, because programming encompasses such a vast array of different underlying concepts, I can now say that in the websockets niche, I’m on the upper end of what the average programmer knows. It’s weird little niche skills like that that could someday prove useful in a job hunt, or in finding the right person for my own company.
The main point here is that learning often takes the path you’d least expect. It also tends to take the past of most resistance. This isn’t always true, but it’s true often enough that it’s worth mentioning. This fact is one that is often viewed negatively, and in a lot of ways it is, but the silver lining is that the past of most resistance also yields the most in terms of knowledge.
You need to be stubborn.
There are times when you need to let go of a dream. I’m 5’6”, white, and could stand to lose a few pounds. I’ve let go of my dream of following in Michael Jordan’s footsteps. When it comes to problems that you believe there is an answer to though, that’s where you dig your heels in. While I was making my way through the programming odyssey that was my problem it started to dawn on me just how stubborn I was being. What I wanted to implement had to do with adding a multiplayer facet to my game, and I could have just ditched the idea entirely. What began as a whim soon turned into an afternoon, which turned into a few days, which turned into almost two full weeks. I worked tirelessly on the problem during that entire time. I thought about when I laid down at night, when I walked my dog, when I was pretending to listen to my wife (just kidding…or am I?). It consumed me. I even go to a point where I felt legitimately depressed. I was saddened by the fact that there something that I was sure I could figure out, and yet nothing I did seemed to work.
I made a choice somewhere along the road that I wasn’t going to give up. I’m not sure when it happened, how it happened, or why, but I became stalwart in my decision to figure this issue out. Whatever amount of researching and tinkering it was going to take to make it work, that’s what I was going to do.
For the last several days of the problem, I was dealing with one seemingly minor issue that was causing havoc in everything I was trying to accomplish. It felt as though I was putting up a beautiful Christmas tree, but every time I tried to put the star on top, everything would crash down. The funny thing is that the solution was really simple. As it turns out, there was one byte of data in the wrong place. One single byte. Once I found the issue it took me a matter of five minutes to have the entire thing running perfectly. I say all of this because if at any point during the entire two weeks I had given up, I would never have gotten to that final five minutes of glory. Sometimes it pays to be stubborn.
What I said above might be completely wrong.
At many points during my quest to figure out websockets I wondered if I was wasting my time. Two weeks is a long time for 100% of your dev team to be working on a single issue. I kept asking myself the same question every time I felt like quitting; “What is the value of solving this issue?” The answer I came up with was that there was an immense amount of value in solving the issue. If, however, there had been less value, perhaps it would have been a better idea to just cut bait sooner.
It can be extremely difficult to let go of something that you’re working hard on. If you’re like me, you often believe that every intricate detail of your project is 100% necessary. Every part is the highest priority, and there can’t be any negotiation about it. Many times during the development of different projects I’ve worked on, I’ve had to let go of things that I thought were critical to the project. More often than not I was upset about letting go. Usually there was wailing and gnashing of teeth. The truth is that there has to be a formula though. Value must be greater than effort plus time. If the amount of time and effort it takes to solve a given problem isn’t valuable enough, then you have to let go of it.
So what I said above about being stubborn is true, but only when it makes sense. As a quick example, one of the things I often hear about programming is how most programmers over-optimize. Often times we’re guilty of going back and rewriting code that already works because we believe we can do it better. Most of the time this ends up being a lot more work than we thought, with a lot of extra bug fixes that end up offering performance benefits that are far less than what would be worth fretting over. Spending time fixing problems that matter is important, but just as important is identifying which problems are worth fixing and which aren’t.
So I ended up solving my problem, implementing my fancy new websocket technology, and I’m quite pleased with the results. It was a much bigger ordeal than I expected, but it was well worth the effort. If anything, it only cemented my love for tinkering and research.