Principles of Learning Tech Stuff, Fast

This, like many other pieces of writing, is a love letter to my younger self. I was given a lot of bad advice that was dressed up as "conventional wisdom" throughout my career, especially in the early years. "Put in that extra 10% and the company will reward you..." "Stay late to finish your part of the project and your boss will notice how dedicated you are..." "Never say 'no' to an extra shift because people will stop asking..." It all led down the same path of disappointment, resentment, and burn out (I shared my own example of this downhill tumble in a previous blog - see the section "A pandemic of mediocrity"). The aim of what follows is to provide someone, somewhere with a bit of hope that there's another, much more sane way to get a lot out of their career, in terms of both money and mastery.

I had a meteoric rise in my engineering career. Within a year of leaving academia, I had more than doubled my annual income, and tripled it within the first three years. To put this in perspective, I was making more in the first year of my start as a data engineer than most academics make at the end of their careers (e.g., Senior Lecturer or Associate Professor). I highlight this not as a brag, but as a proxy for how much I had improved my skills as a technician. I've set down some context on my personal situation at the end, including my experience prior to starting my official transition to engineering for those who are interested, but I'll first get right to the interesting stuff and lay out my principles and strategies for learning stuff in tech.

Three Principles for Learning

1. Learn how you learn, and then learn

No one really takes the time in school or post secondary education to help us figure out how we learn. The best chance we're offered is getting exposed to a bunch of different teaching styles, but it's up to the learner to grasp at one that works for their brain. Teaching is definitely tough. From a weekend first aid course to high school and university classrooms, it's a massive cognitive and emotional challenge to support people while they're trying to learn. And what used to fit nicely into the age-old "rote learn whatever might be tested" pedagogy is now all fucked thanks to LLM chatbots. But my main argument here is that most people would benefit from a framework that helps them sort out how they learn. In the absence of a systemic approach to helping people determine how they learn, I chose the trial-and-error strategy to learn about software, data, and computing as quickly as possible. These things worked for my brain, but they don't work for everyone. Two of my co-founders, for example, have said they would rather stab a nail in their eye than pick up a textbook, but they find other ways to study intensely. So, don't feel bad, younger self, if any of this sounds like the most painful thing a human could do to themselves. We are free to ignore any advice we're given.

Pique your interest

There is a ton of scientific evidence that learning is way more effective when you enjoy what you're learning. At the time of this writing, the perceived most-employable thing in software engineering is React. But if web app development bores the hell out of you, don't start with learning React! There may be more job opportunities if you're good in this space, but you won't get off the ground with anything if every online tutorial puts you to sleep. It's better to focus on something that you find interesting or immediately useful.

One of the earliest apps I developed was to help me generate a strength workout with the structure I like, without the cognitive load of dreaming up supersets or exercises every time I went to the gym. I was comfortable with Python and didn't want to scale, so a locally deployed Django and JavaScript/HTML app with Postgres was fine. It allowed me to get into web app development without the need to figure out load balancing and networking and security and distributed computing. The fact that I could get a working product within a week¹ that I could actually use was a springboard to learning how to deploy secure workflows in the cloud.

I've had so many false starts with learning new programming languages and framework. The source of each one was that I started with a tool instead of an idea. Following a tutorial on how to write the Fibonacci sequence is the absolute worst strategy for learning to program. Start with something you enjoy and build from there.

Look it up

We've flamboyantly taken for granted what it really means to be in the Information Age. Notwithstanding the current LLM-craze, it's been bafflingly easy to find the answer to virtually any question that pops into our minds within seconds for the past 19 years. Telling someone to "Google it" has become an insult instead of a helpful suggestion - because the first step should be to take your phone out and Google whatever question you had before asking someone else for an answer.

We used to just listen to our friend's crazy uncle when something we didn't know came up, or just blindly believe that Marilyn Manson had his bottom ribs surgically removed so he could suck his own dick. But now, we can laugh off the stories that crazy Uncle Pat tells because everyone has a computer in their pocket with access to almost every piece of history we know. And unfortunately we choose to believe a chatbot that regurgitates whatever gets shitposted on Reddit. What I'm getting at is that we have answers to questions right at our finger tips. That means we can learn virtually anything we want and those things are incredibly accessible.

I don't have a guide to wading through all the shit on the internet, but I've found a pretty good starting point. There's a reason the phrase "textbook $whatever" is a thing. Good textbooks (and I'll qualify "good" shortly) are an excellent source for ground truth. It takes a lot of effort to write a textbook and they are perfect starting points if your brain works that way. I really enjoy reading textbooks (I know, ick, right?) and I absorb the information very well. So this mode of learning has worked for me. I don't, however, tolerate my time being wasted on a bad read. I've stopped reading many books (and even more research papers) part way through and I emplore everyone to do the same if the piece they're reading sucks.

My strategy for vetting books is pretty simple. I start with seminal text(s) in the area I'm interested in and start reading¹⁰. Doing analytics? Read up on data warehouse design from Kimball and Inmon (I actually found Adamsons' Star Schema: The Definitive Guide to be much more enjoyable and applicable to today's platforms). Starting out in software? Pick up a copy of The Pragmatic Programmer. These are excellent gateway resources that will put learners in the right direction. They all have bibliography lists sprinkled throughout their pages, so they act as roadmaps as well. If a concept doesn't make sense, find a reference and look that up, too.

Blogs have become a mind field. Like your grandpa (read: me) always says, don't believe everything you read on the internet. Go through 3-4 articles on the same topic before adopting whatever an author is peddling. And stay the fuck off Reddit. Very few respectable developers spend time posting on Reddit threads and you're likely to get an idiot's uninformed opinion instead of a useful engineering pattern - and the very nature of being a beginner is that you can't discern the useful communities from the harmful ones anyway.

Learn by doing

The next principle covers this in more detail, but I want to stress that the answers don't all lie in a textbook. Online courses, half day workshops, and hackathons are awesome ways to accelerate learning. They're super cheap relative to other forms of education and typically include enough detail to end up with a working widget.

Early in my data engineering career, I got the most out of courses that guided me through developing a pipeline for a fictitous project that I could relate to. I always read the course description to ensure it wasn't just a regurgitation of what I could learn from a textbook or by reading the docs. For instance, I got good with Azure Data Factory, Databricks, and the Azure platform in general thanks to a AUD60 course on udemy that showed me how to ingest Formula 1 data for the purpose of monitoring race results and driver performance over a season¹¹. It was interesting and forced me to figure out how a dozen Azure services work and interact with one another. But don't fool yourself - a 6-week bootcamp does not qualify anyone as an expert, despite what the sales guy tells you. So keep learning.

2. Find a project

This one is a bit obvious, but there are practicalities around it. It's a lot easier to learn something technical by doing it. The "project" can be a fun exploration of doing something cool, like making a game for your niece or nephew, or scratching an itch, like writing an app that makes a grocery list for the meals you want to cook this week. But a far more effective way to rocket-fuel your learning is to get a job developing software / working as a data engineer.

For starters, getting paid to learn is way better than not getting paid to learn. It's silly to say it out loud, but some people need to hear it. I, for one, needed to hear it back when I started my PhD². But instead of heeding that advice, I racked up a quarter of a million dollars of debt and a piece of paper that's still sitting in a box six years later³. Don't be like me from the past and make smarter decisions.

On the flipside, when I decided to leave academia for a career in tech, I got a job that paid more than my postdoc and I got to work on big data with a live database and real consequences for fucking up. I knew enough SQL, enough Python, and enough about systems that I secured a well-paying job to hone those skills and pick up new ones. All the while paying my mortgage.

Working in a software development or data engineering team also exposes you to all the crazy things other people have cooked up to make things work. Like most engineers, I have a plethora of horror stories - and I use 'plethora' from its dictionary definition meaning overabundance to the point of having way too fucking many. But let's take a useful approach here (after all, raising a problem without proposing a solution is simply complaining) and highlight opportunities when you see something crazy at work.

One environment

Recently, my team was consulting at a medium-to-large organisation that, at the time, had about 700 employees. Their data engineering department was small with a head count of five and they fielded requests from all over the org (which is pretty standard, in Australia anyway). Like many organisations I've worked with, this company did not have a test environment for its data engineers. This isn't necessarily damning. A lot of tech shops indeed survive (and some even thrive) without a test environment. And so this isn't necessarily damning - in isolation. (Dear reader, please take a deep breath before proceeding...) To deploy any change to their codebase, however, whether it was a new process for ingesting a data source for the first time or fixing a typo in a comment, an engineer would have to wait between 50 minutes and 2 hours every single time. That means that the team could only make between 3-6 changes at the very most to a single process in one day. And while this seems like good numbers on paper, everything moves at a glacial pace in practice. The reality is everyone makes mistakes (I've bene grtaeful for tow readers poitning out tpyos in my wiriting). It becomes a problem when an honest-to-goodness typo costs an organisation 1/4 of your work day.

So the first thing we did was give our client's engineering team a local dev environment and test suite. In just 10 seconds, they were able to determine whether any code they wrote would work, cutting their deployment cycle time down to - let me check the math - 1.4% of their original wait time. And this was for a single iteration. Any programmer knows that we mess something up (albeit it minor, like a typo), like, 3 to 5 times when we're writing new code⁴. This was a great personal experience because I got to work with my team to figure out the best way to create, test, and deliver a dev environment for an Airflow deployment to a staff that's never considered what a dev environment is⁵.

Understanding something different

Engineers love to bitch about how shitty someone else's codebase is. It has turned into a silly rite of passage: you're only good at what you do if you can point out something that sucks. I'm definitely guilty of this and I've been working hard to have more humility over the years. I love Joe Reis and Matt Housley's take on what is meant by 'legacy' when it comes to software and data engineering. Regardless of how disastrous things seem, the lights are still on, no one has died (hopefully), and the sun will still rise tomorrow. Of course there are risks and consequences that need to be considered and addressed, but if people are being paid 6-figure salaries to write code for a company, the company is probably doing all right for the moment.

When I was first learning, I tried my best to take the opportunity to understand why a codebase was the way that it was. What did the team look like eight years ago when architecture was being planned and what tools were available back then? What were the company's financial goals over the past five years? Has the company been able to grow towards its goals in spite of the state of its engineering practices? Leadership and the C-Suite rarely care whether their dev teams have a test environment so long as the company is profitable. And never forget that the goal is almost always to make money. Besides, a company needs money to pay your salary.

There's also an opportunity to pick up technical skills with unfamiliar patterns. Sure, a formal orchestration system is way sexier than using a jump-box to run a pipeline. But what does an engineer need to do to configure a VM so that it can safely and securely run workflows against a production database? The answer is: a lot! And learning how to design and develop that type of solution is super badass. In a similar vein, you can start to identify ways not to design a system by examining what a company is currently running off. As an aside, this also goes for treating other people. I've learned how to never treat another human being thanks to several of my former managers.

I cannot stress this enough: get paid to develop your skills and then develop your skills.

3. Become part of a community

Of the three principles I believe in, this one is by far the most important. Software engineering and data engineering are often very lonely careers. Yes, there are daily standups, weekly huddles, sprint planning, and retrospectives, but these are mostly soul-sucking interactions led by people who don't understand what engineers do. Today's popular ways of working encourage siloing and isolation. If this doesn't resonate with you, I count you among the lucky ones. If this does strike a familiar chord, the good news is luck favours the prepared. So start preparing!

The community I found was thanks to the right mix of luck and preparation.

Luck

One of my good friends brought together some red-hot engineers from virtually every discipline in tech - software, data, security, network. Whenever I have a question about a pattern I haven't tried, a platform I'm using for the first time, or something that's far enough outside my expertise, there's someone in this community that's willing to pair program on it⁶. The people I've had the absolute privilege to meet are simply great human beings. They also happen to be ex-Amazon staff engineers and contributors to the Rust standard library.

Now, you might be thinking: "Where does this asshole get off recommending I just jOin A coMmuNIty Of sTaFF eNgiNeErS?! Go fuck yourself!" And you'd be fully within your right to be thinking that. It's hard. It can be super hard. It's extremely rare for a workplace to actually allow true collaboration. Everywhere I have worked or contracted treated each person as capacity on a Gantt chart that was given a set of tasks to do every two weeks, on their own, with a job description that boasted a "highly collaborative environment" as its main selling point. Sound familiar? And so the place you spend half your waking life every week is likely to be a dead-end towards the goal of being part of a high quality engineering community.

But, if you feel it's impossible to find a community in the connected world we live in today, that's on you. They exist and are accessible. It just might take a few months to find one that'll open its doors to you and isn't full of grifters. So, prepare.

Preparation

Here are a few resources that I've found useful. Some might not work, so I encourage anyone serious about finding themselves a community to just keep swimming. You'll eventually hit an island paradise.

Hackathons

1. Look for a hackathon near you - there are a bunch of opportunities for students and junior engineers to enter 1- or 2- day competitions in cities as small as the Gold Coast in Australia
2. Try universities, community colleges / TAFEs / CEGEPs, and tech companies (e.g., Atlassian used to host one every few monts in their Sydney office)

Meetup

1. Recommended search strategies:
   1. Start with words that relate to your current interest: "data engineering", "software engineering", "AWS" or "Databricks" or "Rust" or "Ruby" or whatever tools / platforms you like working with - you might get lucky and find a group of cool humans
   2. Hackathons are also commonly listed on Meetup
2. Warning: most Meetup events in my area are AI slop shops run by bros who go cross-eyed at the mention of anything remotely technical, so beware
3. Small meet-ups with industry veterans are a lot better than large ones, which are overrun by job-seekers
4. In-person is often better than online, but play to your strengths - if in-person interactions with strangers leave you with crippling anxiety, just don't do it

Conferences

1. Warning: you will have to talk to real humans in real life
2. DataEngBytes is an option for data engineers in Australia and New Zealand
3. Gartner - there's likely one near you
4. Something Fest is a fucking blast for anyone keen to travel to Brisbane in August - great people, plenty of coffee, lots of drinking opportunities, and only a handful of grifters / I'm aN AI exPeRt losers, but this group can be easily repelled by asking them what their favourite optimiser is (bonus points for anyone who says anything but Adam)
5. Conferences often organise a Meetup before the event kicks off, so if cost is a barrier this can be a great option Stack Overflow
6. Contribute where you can
7. Ask questions
8. Vote and comment on answers and questions (when you get enough cred) Reddit
9. Don't do it. Use Stack Overflow instead.

How do you know the community you've found is leading you the right way? Doing things in Principles 1 and 2 will help you answer that question. After you've done some honest study, it's easier to sniff out a grifter - and there are a lot of them.

Patience as a Virtue (PaaV)

Chill out, younger self. You don't need the job title you aspire to hold right this minute. The human brain needs time to formalise and organise all the garbage we take in on a daily basis. I've been learning tech stuff for long enough that I've even gone back and revisted textbooks I've already read because I needed to read the same thing again, in a new light, with new intention. If you feel stuck (like I did in my academic career), you'll find plenty of motivation to do something different. So start small. And, again, learn something that you're interested in. Take your time and do what you like at first - there will be boring bits but it's easier to overcome those when most of it is something that you think is cool. After all, Romania wasn't built in a day, amaright?!

And now for some context for how I landed where I am today.

My Previous Experiences

I had been writing software (poorly) for 12 years before I officially jumped ship to engineering. The programs were developed in Visual Basic (but like, I recorded my clicks in an Excel macro and then fucked around with the VB code that was generated because I couldn't be bothered to re-record the 30+ different clicks I made) and then later in MATLAB, to essentially copy columns and rows from one spreadsheet to another. Like I said, poorly written software. This gave me a very small insight to what computers can do. Despite this glimpse of what was possible, I never bothered to learn about version control, testing frameworks, or even modularity (my scripts were often 2000+ lines of gobbledygook). I was so steeped in my endeavour to be an Academic^TM that I didn't even notice the amazing wonders that hid below the surface I was scratching. Still, I was hailed as "the expert programmer" at virtually every university I worked. Hilarious.

Back in 2018, I was exposed to this thing called "neural networks" from conferences I was attending. Everyone was talking about it in sport science research but no one could explain to me exactly what the hell this was. After a one week hurricane trip to the US for one of these conferences, I knew I needed to get on this "neural network" wave. I got my hands on and read as much as I could about machine learning, deep learning, computer vision, artificial intelligence (AI⁷) - I must have read a dozen 15- to 40-page long research papers in a span of two weeks. I was obsessed with finding out how to harness this dark magic known as "machine learning". The concept, in its simplest form, was straightforward and extremely logical - you feed a bunch of stuff into an equation and use the output of that calculation as part of the input into the same equation, then loop through that cycle a bunch of times. I read enough of the early research papers in sport science to have a clear idea for how this approach to modelling can be used as jet fuel for data analysis (and subsequently published some work doing exactly this)⁸.

I was so enthralled with the potential that AI could unlock that I convinced my employer at the time to fly me from Sydney to Melbourne to attend a one-day workshop on neural networks and deep learning (As a quick aside, it's wild to think about the things we covered. Zhen He was teaching us to build our own convolutional and recurrent neural networks, with forward and backpropagation, for the purpose of speech-to-text conversion from scratch). I had no idea how much this simple trip would change my life. I definitely learned a lot about developing neural networks, but the biggest impact of attending this course was that I just happened to sit down beside a guy who has become my business partner and one of my closest friends, Nik⁹.

Nik and I grabbed dinner after the course and gelled immediately, so we swapped numbers and did the "let's stay in touch" promise when we parted ways. Luckily, we did! One of our earliest sales calls was with a video analysis company that aimed to improve kicking performance in youth AFL players. It's embarrassing to remember that we quoted them $30K to build out a deep learning AI model that could automate event detection in their videos. Oh, the naivety...

A few years after we met, I expressed to Nik that I needed a drastic career change. He put me through a bootcamp in SQL, databasing, data modelling, version control, Python, Linux, Docker, CI/CD, ETL, and a boat load of other things. We sat down together over video chats for 2 hours every week and tackled simple problems that produced sophisticated products, and all the while I was learning best practices and developing strong mental frameworks for creating technical solutions. He put me onto a few textbooks and a handful of websites¹⁰ that would accelerate my software and data engineering skills in the right direction. We naturally chose resources that worked for my brain (Principle #1) and built an app that generated and handled mock data (Principle #2; in addition to mucking around with a phoney app, I started applying for jobs and secured two offers in three weeks).

Over time, Nik got famous thanks to his skillful and elegant writing. He created an incredible and wonderful community of fucking kickass engineers (Principle #3). It wasn't that he leveraged having a large audience - he brought together disparate people who had similar values. I was lucky enough to be friends with Nik at the right time to be included in this community and I will be forever grateful.

That's all about my experience that applies to the topic of learning tech stuff fast. Through Hermit Tech, I've learned an incredible amount about business development, sales, marketing, and the sheer volume of conventional wisdom that's complete and utter bullshit. But rants about those topics are beyond the scope of what I wanted to talk about here. So again, if you've gotten this far, thanks for reading. I had fun and I hope something in here helps you in some way, shape, or form.

1. Of course, Claude and ChatGPT can cobble together a bunch of Python and HTML files. But that isn't learning. And you don't know what Quality is until you understand how to make something.↩
2. In truth, I'm confident enough people screamed this at me but I clearly thought I was smarter than all of them. Unfortunately, at the time I was applying to doctoral programs, I valued the idea of having a PhD over my long-term financial well-being. I chose the idea of becoming an academic and accepted an offer from a univeristy on the other side of the world with no confirmed grant funding and, what turned out to be, a bunch of empty promises. So, learn from my mistakes and get paid to learn instead of paying someone else for the grand favour.↩
3. I actually recently took it out of that box with the intention of hanging it in my home office. It's currently sitting on the desk hidden behind my monitors.↩
4. Yes, yes, yes - Claude Code and ChatGPT dOn'T mAkE sPeLlInG mIsTaKeS. I am not the only one who's seen an LLM recommend the use of a semicolon at the end of a line of Python code or, you know, making mustard gas as a form of 'aromatic water' ↩
5. The Principal Engineer of the org told my team that a dev environment was a waste of time and no one would use it. The General Manager disagreed and we upskilled the entire data engineering team in one week. The opinions expressed by the Principal Engineer was another one of those I'm With Stupid moments.↩
6. Before going to ask someone their opinion, take an hour of unpressured time to simply read. You'd be amazed at the knowledge you can gather from reading through official documentation and half a dozen Stack Overflow threads.↩
7. And more AI, because the algorithms get you more hits on your blog when you include the term AI. AI.↩
8. I was the senior author on a cool paper that demonstrated how we were able to process videos of human movement 233 times faster than doing it manually thanks to some simple transfer learning.↩
9. I knew him before he became Angry Guy on the Internet.↩
10. Hermit Tech has put together a collection of the resources that we've found incredibly useful in our pursuit to be the best engineers we can be.↩
11. I'm not a Formula 1 guy at all, but I am very interested in how teams work together in the background to produce performance from my years as a track and field coach. This course kept me engaged with this aspect of the context.↩

If you liked this essay, subscribe to our blog to get notified when new essays come out. We're focused on writing helpful, entertaining, and human writing, and we simply trust that the marketing will handle itself. We won't flood your inbox with trash. We will never, ever share your email with a third party.