Thoughts on why becoming more technical can make you better equipped to solve problems and handle situations.
Let’s start by defining what I mean by becoming more technical. “Becoming more technical” is relative to each individual and their profession. For example, if you are a salesperson, it may mean a better understanding of how the CRM integrates to your email, or writing a script to remove duplicates from a spreadsheet. As a CEO, it may mean understanding your company’s technology stack and how it contributes to the company’s bottom line. Being technical has different meanings for everyone. But for a CEO, the goal is to better understand how technology works and what it takes to create it. But writing a little code is always a major plus!
Problem solving is hard. Startups are hard. Managing people is hard. Heck, most things in life are hard.
I confirm this feeling more and more everyday. As a curious person, I would find myself trying to solve every little problem with creative, or even outrageous solutions. Most of the times, I get blank look from friends and family because the idea I came up with was over the top, fantastical or just dumb.. I found my intentions were always good but my execution was unrealistic. But that has changed a lot since I began my journey as a front-end developer.
My background started out a non-technical, business-minded sales and marketing person. I found a good amount of success on what some of my colleagues call the fuzzy side. Not to say that it is any easier or less important to be in a non-technical business focused position; but there are less roadblocks to face as opposed to achieving technical goals. As a business minded person, there are not as may the limitations on the materials and resources you are using to solve a problem. Sure, you can be limited by time or money. But for the most part you have the ability to change messaging, branding, emotion in any way to reach a goal. Becoming more technical has provided me with the understanding that there are limitations to what can be built with code and and how difficult it is to execute those concepts. That key understanding has changed the way I handle many different situations such as problem solving. Here is a brief list of observations I have made:
This one is important to me because it really hits home. When I was younger, I used to find myself solving every problem I encountered with unrealistic and fantastical solutions. Many of those times, I found myself ecstatically discussing a far fetched idea with a close friend or family member. You know what I am talking about; that energy packed discussion where you and your best friend gets lost in a conversation where you think you have solved the Los Angeles traffic problem with some underground tunnel system… oh wait..
Joking aside, this is a common occurrence and it can cause a false sense of problem solving and a complete lack of real execution. After becoming more technical, I can catch myself when I start thinking or acting this way. At the end of the day, talk really is cheap and it’s really about the understanding that execution is vital when combating these world problems
I really don’t want to get started on bugs and debugging. It is quite possibly the worst part of a software engineer’s job. However, it is so important. When those two things come together (horrible but important), you know it is a perfect time to become efficient and to focus on process. The process of breaking down the problem and meticulously changing the environment one variable at a time in order to find that hidden root cause provides us with some great life lessons. Troubleshooting is all about finding the root cause. Constantly testing and guessing and trying to find why the heck this snippet of code doesn’t get triggered when it should is a perfect metaphor for our problems in life.
The more I humble myself with debugging, the more I find that this common process improves the way I deal with challenges in other parts of work and life. Whether it is car problems, bad habits or even emotional issues,
breaking down a problem and testing one variable at a time can help you really understand what the issue is and how to fix it.
In technology, disappointments and frustration are all too common. This is especially true for products in their early development cycle where they will rarely meet expectations. Things will break down and projects will never go as planned. After learning that the hard way, I have found that tempering expectations is important. No one ever got in trouble for promising less and delivering more. With practice it becomes really powerful when you can provide enough of an expectation that draws excitement and motivation, but is safe enough from being a waste of time or a disappointment.
This one is a little dangerous if my wife were to hear but it is absolutely necessary if you want to avoid let downs. Let’s look at a simple example of a dinner date.. The restaurant you decided on is amazing, you wouldn’t choose anything less for your significant other. But when it comes to describing it to your significant other, it may be worth downplaying its greatness. This way it only needs to be a bit better than the expectation to bring on feelings of fulfillment and happiness.
Before I started on the path of coding, I was a salesperson making endless cold calls hoping to close deals. I knew that it was a numbers game, the more I called the better I would do. What I didn’t realize was that not every profession works this way. While working on one of my first software projects, I relied on an external team of developers to build an app for our team. I couldn’t understand why there were bugs and how nothing would come back the way we spec’d them. My initial reaction was that they should just write more code; it was the same way I handle making sales. Since then, I’ve realized I was completely wrong with my assumptions. If I had taken the time to become a bit more technical, I could have offered some help to make that project a success. Not to say that all things in life can be brute-forced. There are plenty of achievements in this world that are not quantifiable and difficult to predict, let alone complete. I am not sure that I would have as strong an understanding of empathy, without writing some code myself. All of these observations are completely based on my own technical journey. I understand that this may not be the same path for everyone and there may be some disadvantages to the journey I have embarked on to be more technical. In my case, I am now better equipped for the challenges that are thrown my way and I strongly advise others to at least understand technology and how it is built.
