1710 Words, 8 Minutes
My two lives as a Programmer
I’ve had two lives as a programmer. Two very different lives.
I’ve “learned to code” to code about a decade ago. Yet, most of my growth in skill and ability has happened in the last two years. This isn’t by chance — I’ve had a substantial shift in how I approach programming and learning in general.
In this post, I want to talk you through what made these two lives different and I hope you can profit from the lessons I learned the hard way.
Baby Steps
I had my first touchpoints with programming in high school, programming Kara the Ladybird to navigate through mazes. However, it wasn’t until my second or third semester of university that I put any proper effort into it. As a bored sociology major, I stumbled upon Udacity’s CS101, a course that taught programming using Python 2.7.
Initially, I had little use for my newfound skill. But a little later, probably for the same reasons that made me seek to learn to code, I switched my major to physics. Here, Python became a valuable tool for data wrangling, analysis, and some machine learning.
My first Life as a Professional programmer
I enjoyed programming but was unsure if I wanted to make it a career. How do you figure that out? Correct! You try.
I landed an internship at a SaaS startup that built a mobile and web application. At that point, I had never touched JavaScript, HTML, or CSS, let alone React or Node.
However, my experience in scientific computing with Python was enough for them to take a chance on me. And I didn’t want to disappoint them, i wanted to ship features fast.
Sadly, optimizing for speed derailed my whole approach to programming and I more often than not found myself copy-pasting partially understood code snippets from Stack Overflow, stirring the codebase until at least something worked.
Working like that was not only unsatisfying, it was overwhelming. At no point do you know how long you will take, you cannot estimate complexity, and you don’t really grow in your ability.
Unsurprisingly, I did not enjoy software engineering. I stayed with the company part-time for another year after the internship ended, but solely to finance my studies, switching to a test engineer role, and writing end-to-end smoke tests. This was unchallenging and repetitive work, but it paid the bills. I could finance my studies and use any remaining cognitive capacity for science.
This marks my first death as a professional software engineer. I decided that this was not for me and turned away.
Rebirth
Time passes, I finished my degree and worked as a quantitative analyst, researcher, data scientist, and later an MLOps consultant.
My company had an opinionated approach to MLOps. We were seeing it, for the most part, as an engineering exercise. Proper SWE systems and processes may have a small cost in time to set up, but they are well worth it a couple weeks down the road. Your work will be of higher quality, code reusable, and results reproducible.
The engineers who took our trainings consistently provided good feedback. But I had a problem! How could I talk the talk, if I wasn’t, in principle, able to walk the walk?
That’s what sparked my resurrection. On November 29, 2022, I decided to give this software engineering thing another shot (I looked up the commit date).
I found a great course by the University of Helsinki that started exactly from the level I was at. There were no expectations but my own. I delivered my MLOps workshops and training to engineers who seemed happy with the results.
It was solely my own ambition to not be a yapper, to know my stuff, to be competent (sprinkled with fear of being called out for lack of engineering skills). This time, I would be learning software engineering on my term and from the ground up.
My Second Life
Without the pressure of external deadlines, I learn on my terms. Working through the course became a daily habit and a few months into it, I joined Buildspace Nights & Weekends, a (sadly now defunct) six-week program where you ship a product to real users.
Granted, I built a glorified to-do app, but I was proud of it and proud of the fact that I got it to the app store in week one. During the next few weeks, I got my mom and about 150 others to download the app and submit feedback that I could incorporate to make it better.
After Nights & Weekends finished, I came back to the Helsinki course. To some extent because I value finishing things I start, but mostly because I was genuinely curious about TypeScript, SQL, and Containers — the contents of the later chapters
This feeling was a small self-revelation followed by a conviction. This time around, I enjoyed software engineering and at work, petitioned to switch to the engineering team. Not easy, but after a couple weeks of back and forth I secured a new role. I was a professional software engineer, yet again.
A couple things were different, however.
First, by now I’ve taken enough time out of my evenings studying software engineering and seen enough other grass to know that this is the career I want to build my life around. Second, I have learned how becoming good at my craft makes the work enjoyable. I’ve experienced the value of taking a step back, looking around, and understanding before you dive into the heat of the moment.
Fundamentals benefit you implicitly. You don’t feel them day-to-day, but the long-term payoff is monstrous.
Diving right in may give you the first success, that closed ticket faster. But someone with strong fundamentals will soon catch up.
Fundamentals equip you with a vocabulary and associations that make you more efficient in solving new problems, they make your search for solutions faster and improve the quality of your first attempts.
Since I’ve finished that course, I am reading textbookst to make up for my lack of a CS education. I enjoy learning new tools such as Kubernetes or Terraform, I’m implementing a Fast Fourier transform in Haskell, or learning C and C++ to get closer to the metal with the goal of understanding what CUDA is about.
This is eclectic, but that is the point. Learning is a free exploration. I may need Azure IAM for work, but in my free time, I can parallelize learning with figuring out what I am naturally drawn to. What do I enjoy?
I can only answer this by spending time learning outside working hours. Otherwise, I feel the pressure to take shortcuts. Enjoyment is paramount. Without it, you are not consistently willing to spend your free time.
Of course, I build myself a loose roadmap, a general idea of what I want to learn. This curriculum is surely inspired by what is needed at work. I probably wouldn’t have read a textbook on Python (read it, it’s good) if it weren’t for the fact that we use Python at work. However, to keep studying enjoyable, the curriculum can’t be too strict. I allow myself distractions and rabbit holes (Haskell, cough).
Even though it may seem like it, this is not a wasted effort. First, it’s fun and fun is worthy in and of itself. Secondly, because of a simple truth: Learning compounds.
The more you are capable, the more you can connect new stuff to what you already know. Even if not directly, your self-study implicitly makes you more competent in what you need at work as well. And you can use your dabbling to shape your job and career to increase the overlap between what you want to do anyway and what you get paid for.
What is the difference?
It’s hard to put into words how different my two attempts at software engineering feel. My first time, work was overwhelming, brittle, unpredictable, and boring. Today I feel competent, I feel growth, I have agency.
I am eager to take on challenges and I have taught myself that it is not only okay, but necessary to take a step back, orient yourself, and survey the options before you jump in to solve the problem at hand. You learn more, deliver better work, and enjoy your craft more.
If I were to drill down what’s different in my two lives as a software engineer, it’s acknowledging and acting according to the following simple truths:
Fundamentals are the Shortcut: Taking the time to build a solid foundation and learning from first principles pays off exponentially in the long run. You’re not only learning a new framework. You understand concepts you can build upon for the rest of your career. If you patch together stuff you don’t understand, you’ll walk on eggshells fearing that your work will eventually break into an unfixable mess until it does.
Growth Compounds: When you learn and study a lot, you’re not only getting good at what you study, you’re getting good at learning and studying itself. You can embed new knowledge with what you know already and accelerate your learning.
Curiosity Drives Progress: Follow the fun. There is a stark difference between learning because you want to or because you have to. This is not only about building skill, it serves as a compass, a tool to listen into yourself and hear what it is that you are excited about. Some say you don’t have to love your job to be successful as a programmer. Sure, probably. But you’ll have a hard (and probably pretty unpleasant) time keeping up with people who do.
Competence is Fun: The main reason I didn’t enjoy programming the first time around was because I was not good and not getting better. This is a miserable existence. Luckily, it’s also something that is in your control. You can choose competence. Competence gives you agency, and self-efficacy, makes you good at your job, and gets you the fun projects. In short, it’s what makes your job enjoyable.
Building strong fundamentals helps you find a craft, makes you good at your job, and your job enjoyable to you.
Software is a career that compared to others is incredibly accessible, even without formal qualifications. Resources are abundantly accessible online and if you use GPTs as a tool for tailored feedback instead of letting it do the bulk of the work, you have a personal tutor always by your side.
The odds have seldom been more in your favor.
Make it count!
cheers