This post is the first of many posts to follow describing my journey from a programmer to a businessman. I have been a programmer for 10 years now, and recently I decided to join my family’s business full-time. I saw that transition coming at some point and I always envisioned myself how I will handle this transition. My current role in our business is to make it tech-enabled for smoother and human error-free operations. When you work closely with non-programmers you realise the stark difference between the thinking process. You have an indispensable tool at your hand which others don’t have - Programming.
While I want to talk about how I am handing and feeling about this whole transition but I want to focus this post on how a decade of programming experience changes your perspective. So here we go -
I just want to get it out there that right now knowing programming as a skill is no less than having a superpower. No matter where you are and what you do technology is touching lives in many shapes and forms. If you are from non-programming background technology feels magical and off-the-limits. People often forget that all the websites and apps are made by humans and they have more control over it then they realize. If you know how to code, then you know how to make it bend to its knees for you and make it work for you rather thinking of it as a BlackBox.
As a software engineer whenever you come across a workflow with lots of manual stuff involved, it’s hard for a “this-can-be-easily-done-by-this-app” or “i-can-make-a-software-for-this” thought to not cross your mind. Heck, I even did two side-projects for my dad’s business back when I was in college for smoother operations and accurate book-keeping.
As a programmer, you are always asked to think of edge-cases, cases when your solution will fail. Thinking of edge-cases makes you a better engineer which leads to better and resilient system design. Often in business, you find yourself evaluating the risk of a business move, here worst-case scenario thinking(which kinda like edge-case thinking) often helps to evaluate risk.
When a programmer writes code, she always makes sure her code can be extended easily (Trivia: I haven’t forgotten my principles yet :p). Similarly, when you are designing a new workflow you always make sure that this solution is future-proof(sorta) and would also accommodate evolution as the business expands.
When you dabble around other fields than programming, you realize how abstract things can get. Programmers, usually know what their output would look like. It can be a set of APIs, UI from mockups or a level of optimization to achieve. But when you walk down the path of building your own business, you are always not sure of what exactly will the output look like unless you are visionary like Steve Jobs.
When you build software you can distribute it across the globe easily. But when you work on selling things which do not travel at speed of light, things move a lot slower. You always look for ways through which you can allow more people to use your products. And sometimes this slow-moving process might be frustrating.
Programmers love documenting, or at least some do. Like it or not documenting is an essential task in a programmer’s daily chore. Documenting something is great for looking back to learn from mistakes and creating playbooks for scale. I feel documentation in business is important too, as it helps to trace why a decision was made and its implication when it was executed. Ray Dalio talks a lot about documenting in his trading firm.
If you want to be a good programmer, you have to learn to dig deeper and understand the root-cause of problems. I put this habit into use after wasting the first year of my professional career stack-overflowing extensively without actually digging deeper. If you have a knack to understand concepts at a core level you will come up with more creative and natural solutions. I am not surprised why the 5-whys rule is so famous in the business world.
Most small-business are ran with intuition, no one asks “Does data support this decision?” question. This ties back to my point 5 where it is hard to connect dots to end-result without data supporting it. I often find myself in a situation where I am collecting data and trying to make sense out of it to make informed decisions. The biggest challenge I feel when depending on data for decision is to gather data in the first place.
In conclusion, I am so grateful that I came across programming and acquired it as a skill. I am excited to make impact in our business by infusing technology deeply and making it accessible to everyone.
I will definitely write more about my interesting transistion and please feel free share your thoughts too.
UPDATE - As Parijat pointed if I were to sum this transistion in one sentence it would be - “From Jira to Jeera”
Jeera - Hindi word for cumin seed which we deal with primarlily in our business
Jira - Software management tool which is ubiquitous in software industry