Learning and Doing

A retrospective of my past three years in software

I want to start this retrospective with my experience in school, and then slowly transition to work. If you don’t want to hear the school bits, just scroll down to the work section where there’s a fancy laptop photo.

In school, there is no scope creep. You are given a self-contained unit of work and you are expected to complete it or understand it within a time frame. There is a clear rubric on how you will be assessed.

If you didn’t study or put enough effort to an assignment, it simply showed on your mark. Your mark was the key indicator that captured all your effort. There was little ambiguity on what you needed to do, what textbook chapters or lectures to read, how to do assignments, when assignments were due, and what the exams would assess. The work was carefully adjusted to your level of experience. Sometimes, it would get challenging but it was never unclear what one had to do to break that barrier. Sure, there was some courses had more unclear expectations such as research-oriented ones, but you could always discuss with your professor and have checkpoints to make sure you were completing requirements.

I excelled at school and I argue that it was not because I was good at computer science per se but rather, the fact there was always a clearly defined problem for me to reach to succeed.

Due to this feedback loop of marks from effort, I was extremely motivated and honestly, quite happy. I would complete my assignments as soon as I got them so I could focus on the more involved tasks like studying for exams. I would organize all my tasks on my calendar, and just check them off. I would never let something linger close to the due date. If I was under performing in a certain class, I would schedule additional time for the material. Additionally, I enjoyed the subject matter. I felt I was learning the field in a holistic sense. Concepts were coming together and I was getting better at tackling complex problems. I wasn’t bogged down by process, and ambiguity. I felt like a rock star (I realized later, I definitely was not).

But as graduation neared, I looked ahead into the next chapter of my life — work. At that time, it was still a black box to me and to be honest, still is. I had many questions mainly; would things be as concrete as it was in school? From what I had gathered from pop culture and media (Office Space!), was the idea that work was going to be monotonous. You go to work for 8 hours, get your paycheck, and then try to use the other hours of your life doing something fun. There wasn’t much problem solving or discovery, rather just solving.

But what surprised me was that it was the exact opposite. After working two professional jobs in software and hitting my 3 YOE —school was cake.

When I started working, I found out what I didn’t know to just increase, and there simply wasn’t enough time for me to learn everything at a single job or even task. Every rabbit hole that I would have to take to solve a problem would lead to more rabbit holes. After hours of digging, I’d find myself entrenched into deepest pits of the internet with dozens of open chrome tabs. There was simply just too much to understand. The tasks or projects I’d work on had little pit holes of depth that if I’d fall into and not pull myself out of immediately, I would never finish the task assigned to me. I simply didn’t have enough time to digest the research paper or the blog post or the documentation to understand how this new technology I’m using works. This is in direct contrast to when in school, the scope was carefully limited and meant to be understandable. During work, I simply had to learn what I could to make it work and hand-wave the rest of it off or carefully wrap what I didn’t know into an assumption. I did this countless times, and I say it’s a skill in itself. Specifically, the skill is “knowing how deep you need to understand a technology in order to use it”.

During downtime, you can try to spend your time learning that new tool you used. But will you ever really understand? Your mental modal of the tool probably has gaps and will always do since at work, you’re going to get paraded to the next thing and then use yet another tool. Even in a specific project, your scope never ends. There’s bugs, there’s new feature requests, integrations, and changing environments. Libraries and protocols become deprecated or obsolete. Business has more requirements so they make a new feature set and stamp 2.0 on it, security audit shows some vulnerabilities… suddenly your CTO wants to use machine learning. Work is chaos! Whatever the state of the project is, it’s never going to be “perfect”. Every decision you will make will be a series of trade offs, and you’re going to lose out on something. You will rarely get that fulfilled feeling. But that’s ok, you got shit done, business and users are happy (hopefully).

What worked for me to try and organize all the knowledge being dished out to me through my daily discoveries, was to simply ask myself ”is this an alternative to something I know or is this a new thing”. If it is an alternative, put it in the same category as the alternative, or if it isn’t, put it into a new category. There usually always is alternatives for the same type of tool, so make sure you get the generic category name right for it. For instance, you have language tools, request-response tools, relational database tools, serialization tools… and remember specific tools are just instances of these generic categories. I use the word “tools” graciously, because it’s simply the most generic word used to describe all these things. Within tools of the same category, try your best to keep track of the “diffs” between them and ensure that these “diffs” are not esoteric or minute details about the tool but rather the details that probably led to the tool being created. The details that no existing tool could solve. That’s all you need to know! You can always just look up the rest. Sometimes, these diffs are extremely tiny and it becomes more of a preference thing. You also won’t always know which tool to pick, so then try to use what works best with the rest of your stack and/or base the decision on you and your teams familiarity.

On the contrary, if you just tried to learn all these tools without categorization and comparison, it would be an overload of information. It is impossible for one to list line by line, the spec each technology has and what type of context it works in — that is something you can always look up. What is truly important is that you don’t get lost in details of one tool or even one stack. Keep your mind open, and keep studying the entire system. If you don’t do this, you’re going to be SOL eventually since you prematurely capped your learning scope. Those who study only one or a few technologies, and are hesitant to try new things, severely limit themselves. These folks will then try to solve every problem with the same familiar tools they know, and are likely to confuse familiarity with proficiency. The moment this type of engineer hits new pastures, they will hit rock bottom since they didn’t practice learning enough, and instead just focused on doing.

There’s reasons why we have a plethora of tools in software. One reason is because someone down the line, ran into a problem in which an existing tool could not solve well, so they had to either fork an existing tool and modify it to match their use case or it was different enough, so they had to build it from scratch. This is why there seems to be an excess amount of tools and why you get choice overload similar to when you try to choose a cereal at a grocery store.

This diversity is not a negative thing! If there is one complete truth, it is that change is inevitable. Whatever we need to build will change, and so the tools must too. And there is only so much we can do to modify something until it becomes bloated with features (You want modules, not monoliths), or it really has morphed into something else entirely so we might as well call it something else. There is no such thing as a tool that can fulfill all use cases.

There has never been a point in my career so far, where I’ve seen the end of how much I need to learn. I’ve learned that I’m not ever going to get that “complete” feeling that I had in school, at work. It’s just not going to happen. It’s better to do your best, close that ticket and move on. Be glad you were able to deliver.

I just know that I need to get better, and I need to solve larger, more difficult, and more unknown problems. My appetite has only grown.

Take my humble advice: Don’t be afraid of the ambiguity, instead bask in it. Get comfortable with being uncomfortable. Change is not going anywhere, it’s just entropy at work.

I like to build things

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store