Today I’m sharing three important lessons I learned since I started working in 2019. They each look self-evident, but I have a deep appreciation for each that I can only begin to explain through personal experience. These are generally career-oriented but they carry over to my everyday life.
I started my first job as a junior engineer in 2019 on a startup cloud team. It was only a few days after I turned 22. My first six months were a tough adjustment because I developed a fear of being assigned work that I did not immediately know how to do. It sounds silly now, but I came into the office every day feeling anxious at the thought of being assigned something new.
Our team had weekly planning meetings where we’d review the work backlog and hand out new tickets to everyone. I walked into these meetings fearful I would be assigned something that I could potentially fail. I thought, “I don’t know what this task is about, so I better keep quiet and hope I don’t get this one.”
Engineering work at its core deals with constant unfamiliarity, something I just wasn’t prepared for at 22. I felt I was rocking the boat for constantly asking questions and spending large amounts of time looking things up, and believed I was hired by mistake. I occasionally asked about how I was doing and was told I was doing fine, but I always genuinely believed they were white lies and I was only barely scraping by.
I thought about quitting a lot in those first six months. In an ironic twist which I promise really happened, I was reading about whether engineering was the right job for me and I discovered that the etymology of the word engineer originated from a Latin word for invent.
This was an epiphany about the nature of this kind of work. I realized you can take any technology engineering job and reduce it to its essence and find that it exists simply to invent solutions. These are solutions to business problems that relatively few people can solve, and they hire you as one of those few people to magically resolve them. Part of that magic is not always immediately knowing what to do but rather using your existing knowledge and logic to come up with a new one. Therefore, not immediately knowing what to do should be accepted as a completely normal part of the job.
I started approaching all of my work with the mindset that I was going to be tasked every day with tough intellectual challenges, and soon, the fear of the planning meetings disappeared and I took on projects in larger scopes. I soon found myself volunteering for things I had no idea how to do. I began to prefer the “unknown” work to the “known” work. I recognized an underlying pattern for approaching problems and began to genuinely love the challenge. I still feel this way today.
To succeed, you need to approach problems from a starting position of how they could be solved. Your success hinges on being unintimidated by challenging problems.
For anyone who struggles today like I did back then, know that all sufficiently hard problems in your job should look insurmountable. You’re going to constantly encounter bespoke problems that will never have been solved anywhere, so they’re not something you can just Google or open a textbook for. Sometimes you truly have zero idea where to even begin. When you’re not used to this type of work, don’t fall into the trap of attributing yourself to being naturally incapable of doing it. If your job is manageably hard, that is actually a good thing.
I didn’t understand at age 22 that my job was not to primarily do things I already knew how to. Our job descriptions say we develop software and build servers, but these are only incidental implementations of the same thing: invention.
I attribute my initial struggle to the culture shock coming from a school setting. I think I thrived at school because it was rigid, structured, and predictable. Most school assignments are just variations of the same thing assigned to students for generations. A math problem is a math problem. A video on the internet explaining what you need to learn likely exists. At school, it’s rare to find yourself in uncharted territory, because a course textbook and syllabus will generally describe what you will be learning from start to finish.
School mindset prepared me to see my professional work in that context. I defaulted to some belief that I was incapable of doing something simply because I didn’t immediately know, as if it were some exam. I shook free from the mindset after I changed the way I approached everything in my personal and professional life by starting from a position of “I can figure that out, eventually”.
Your purpose is to invent. The sooner you accept and embrace invention as the core of what you do, the sooner you will love the profession and see your career growth take off.
Now I’ll talk about some personal epistemology. At some point, I started visualizing my knowledge like blocks of a pyramid. The blocks at the base represent the basic facts of a domain. A smaller layer of blocks representing slightly more advanced concepts is placed above. These layers continue upward until a pinnacle block is reached, which represents any one piece of knowledge. This describes the obvious concept where advanced knowledge requires prerequisite knowledge.
To relate this to technology: when you try to understand a tool without learning the very thing it abstracts, you are building a pyramid from the top down and will never have stability. At best, you are wasting your time and at worst, you are actively setting yourself up to do your job poorly.
I believe that most new subjects you are trying to learn should be understood with intuition and quickness. People who grasp new things faster than you might be naturally gifted, but it’s more likely that they’re also normal people who just know the fundamentals better. I find now that if new topics don’t “click” relatively quickly for me, it’s a signal that I haven’t mastered some concept which underlies it and the most time-efficient thing to do is identifying what it is.
Let me say again: you should be grasping new topics with relative ease. The optimal way to learn is probably not to brute force your way into understanding but rather to find the fundamental subject knowledge that would reduce friction to learn it. Take a step back down the pyramid to learn about the concepts you are missing, then build up from there. I said previously you should approach every problem with a belief that it is eventually solvable. Likewise, approach all new subjects with the belief that it is eventually learnable.
Another more important point is you really need to be aware of when you are actively working with something without knowing what it abstracts.
You might be building superfluous skills and not even realize it. Genuinely think about what composes your own pyramid. You might have one year of surface-level knowledge repeated for n years of experience. Understand if your core skill set is something that someone else could learn relatively quickly.
Ask yourself, are you truly a subject matter expert on something, or are you actually mediocre and happen to be the best of those immediately around you? Am I a “cloud engineer” because I actually possess deep knowledge of underlying system technologies better than others in the organization, or do I have the title because I happen to be the person with business permissions to use the cloud?
I have two other examples:
I self-taught myself how to program when I was a teenager by repeatedly searching “how to do X” for project tasks (I didn’t major in computer science). Learning in this way was a mistake, because for the longest time I wrote programs without properly studying the language (not knowing all syntax available to me) or without studying a single thing about algorithmic complexity (not knowing how to design programs to run in the most efficient way possible). I spent a long time in ignorance believing I was better at coding than I actually was, so I wasted a lot of time gaining superficial knowledge of coding syntax without gaining much skill in using it most effectively. In other words, I hardly practiced the underlying core skill transferable to any other language.
I got my first cloud administration job despite having no cloud experience. I had zero interview questions directly relating to the cloud and was solely tested on fundamentals, namely Linux, computer networking, and system security. This is because my interviewers understood that the cloud is just an abstraction of physical IT core technologies and using the cloud without knowing them will not get you very far. Since then I’ve held that studying the provider itself is still mostly an exercise of vocabulary and trivia, sort of like knowing names of ice cream flavors which generally taste the same (EKS vs. GKE vs. AKS). What happens when the provider is replaced? To work with the cloud, I say the best use of your time is spent directly learning IT fundamentals or agnostic system design, skills which carry over and beyond any one provider.
There are limits to how deep one’s knowledge really needs to go because there is an eventual usefulness disconnect. We work at different levels of abstraction and a React developer probably won’t find much practical application studying CPU architecture. I’m saying you need to know at least one level beneath yours, but it wouldn’t hurt to go deeper.
Master your domain by learning the domains which directly underlie it. Be aware of your true skill level.
Finally, I believe the most characteristic differences between my past (immature) self and my current self is the ability to host two completely opposing viewpoints in my head, with a genuine understanding of why someone would believe either, without necessarily endorsing either.
When I debated with people I remember becoming emotional. People would ask me questions that appeared to poke holes in my ideas and I would become defensive. There was this one time at work I presented an idea to a group which I thought would be quickly accepted. Afterward, someone instead began a series of questions in the form of “did you consider doing x instead of y?“. The conversation became heated because I took their questions personally and saw it as them torpedoing my work. I lacked the introspection to feel comfortable with the possibility that I was wrong. Instead of using their questions to improve, I felt the need to engage in an intellectual battle and defend my idea as-is.
Sometime after, I read Nassim Taleb’s Fooled by Randomness, a book which influenced how I think of risk, psychology, and science. It introduced me to the idea that scientific theories can never be considered ultimate truth. Instead, a real theory is one which is falsifiable i.e. open to the potential of being proven wrong. The engineer’s job is to invent, while the scientist’s job is to disprove their own belief, not dogmatically defend it as certain reality.
Humanity’s current scientific understanding of the universe is not necessarily the real truth. For example, when I was young I naively believed that ancient scientists like Ptolemy who believed the universe revolved around the Earth only believed so because they must have been stupid. After all, how could one believe something opposed to facts so clearly understood? That was my immaturity. I made zero effort to understand how that view arrived at its conclusion. No ancient scientist’s theories could be fairly assessed using our modern knowledge because all of the evidence available to them at the time did support their theory. To the ancients, looking at the sky was clear as day (wordplay intended) evidence for geocentrism. To tell them heliocentrism was a better model would have been met with a response that, by all indications of their time, was completely true in the scientific sense: “there is no evidence the Earth revolves around the Sun”.
My realization was that, in the same way scientific progress is made by falsification, any idea I could possibly propose is also subject to being wrong. I can collect hoards of data in support of my theory but it only takes a single refutation to disprove it. If I am genuinely after the truth, then my defensiveness is not a correct response to constructive criticism. Instead it should be openly invited in good faith to help refine my ideas. Real science is practicing self-skepticism, deliberately finding flaws with my own arguments to the best of my ability, and changing when they are proven wrong.
Today, I really make an effort to fully understand those who disagree with me. I try to drop all personal attachment no matter my bias. I also remind myself that a debate is a win-only situation, where any outcome will only drive me closer to the truth by changing my mind or refining my understanding. I also give as much empathy as possible to the opposing argument until I can genuinely understand how someone could possibly believe it. I put myself in their shoes and imagine myself completely as that person. I try to defend their own arguments myself. Only after re-stating the argument to confirm it is correct do I begin to compare viewpoints. I can tell very easily when people have this objectivity versus those who have yet to learn it.
I started applying this to everything and I found myself with insight into why anything happens. Virtually every viewpoint has an explainable logic, which we may or may not endorse. There is nuance to everything and I stopped assigning the most cynical explanations to things. In general, as I think I calmed down a lot as a person and I gained more empathy for others.
Fully understand all viewpoints with objectivity without necessarily endorsing them. Your opinions are always subject to being wrong.