From Personal Trainer to Coder to Software Engineer: What I’ve learnt - Part 1
May 22, 2019 • ☕️☕️ 12 min read
Hi, I’m Matt and I’m a software engineer here at Flock. We’re an insurtech startup operating at the cutting edge of the data analytics and insurance space.
Here at Flock, while we love what we do and have fun doing it, we take software engineering seriously.
We are firm believers in type systems, functional programming, and continuous delivery.
We constantly seek to optimise our agile processes and aren’t afraid to try new things.
We’ve taken big bets on innovative technologies such as React Native (it’s worked out so far). And we’ve experimented with languages such as Haskell and ReasonML.
We support and teach each other as well as hold each other accountable. After all, one of our core values at Flock is growing, together.
Now, having been the first software engineer at Flock (hired by our glorious Tech Lead, Abe), you could assume that I’ve been programming since my time in the womb. And that I built a robot to be my best friend by age 3.
But that’s not the case.
Only 4 years ago, I barely knew what a computer program was, let alone what it took to be a software engineer.
Late in 2017, I was first hired as an intern a few weeks before we released our first product, Flock Cover, into the app store. Despite being an intern, I was given a substantial amount of responsibility, ownership and autonomy. In fact, I was shipping code into production on day 2. This allowed me to thrive and develop into the confident full stack engineer that I am today.
Over the course of this journey, I’ve had a ton of fun and learnt a lot. It’s my hope that some of this will be helpful. Or at least a little interesting.
This three-part blog series will explain:
1. How and why I first learnt to code
2. How I developed into a professional software engineer at Flock
3. What I’ve learnt working in a small but ambitious and fast growing startup.
I will distill each of my major learnings into a few key takeaways at the end of each article.
Whether you’re an aspiring software engineer, startup enthusiast or are in the insurtech space, it’s my hope that there’ll be something for all.
Ready? Let’s do this dance.
Part One: How and why I first learnt to code
My initial foray into programming was almost accidental. In 2015, I had been living and working in Dubai as a personal trainer, nutritionist and fitness writer.
To say that I wasn’t a geek as a teen would be going too far, my comic book collection and Warhammer figurines would suggest otherwise. But I definitely wasn’t a ‘computer guy’.
Computers were for homework, chatting with friends on MSN messenger and using LimeWire to download songs into Windows Media Player. Computer programmers were “hackers”. They lived in movies and spent most of their time breaking into the systems of various government agencies.
I more or less held the same belief throughout university. Except homework was now called ‘assignments’. Sure, I was aware that some students studied something called “computer science”, but I didn’t know what that meant. I didn’t understand why you needed to go to university to fix a printer, or why universities would teach you to “hack into banks n’ stuff”.
My chosen degree at university was Sport & Exercise Sciences. A mishmash of subjects including biomechanics, physiology, biochemistry and psychology. I aspired to become an elite strength and conditioning coach, working with elite athletes.
Upon graduation, I moved to Dubai to be with my then-girlfriend (now fiancee). I’d decided to put the athlete coaching on hold for a while. I was going to spend a couple of years working with general-population clients. That means normal people like you and me.
I did pretty well for a couple of years. I set up my own business called Cleary Theory Fitness, enjoyed moderate success and became a writer for Men’s Health magazine. I even had an African King as a client (the world’s youngest ruling monarch, as a matter of fact), but that’s a story for another time.
And then late in 2015 I had a business idea, and no, it had nothing to do with fitness.I wanted to take down Facebook and the other social media giants with my own platform. Simple right?
My product was named Troop and it would initially be built as a mobile app, and its vision was to create a level playing field so that all voices could be heard. This stems from the belief that it shouldn’t matter that you aren’t a pop star, athlete, journalist or “influencer”. If you have something of value worth saying, then you deserve to have your voice heard.
But back then, having an idea and making it happen were worlds apart. Even if I had known of startup mantras such as “build, measure, learn”, I was lost. I didn’t know where to start.
My first step was reading a fantastic book called, “How to Build a Billion Dollar App” by George Berkowski.
Spoiler Alert #1: I didn’t achieve this but it was an invaluable primer for understanding how apps and tech startups work.
Close to 4 years later, much of what this book taught me about software products and startups rings true. Though it gave me a game plan for the company I wanted to build, I still didn’t understand software or computers. And I certainly didn’t understand what software engineering was.
I wasn’t quite sure what a server was, but I had a sneaking suspicion that not all of Facebook’s 2 billion users’ worth of data was stored on my phone. If it was, how did I download the app so fast? I really wish this was a humorous exaggeration.
Once I’d formulated my game plan, I conducted market research, wire-framing, user interviewing and high(ish) fidelity prototyping. Then, I decided to embark upon the search for the Holy Grail:
An all-powerful, genius-level computer person who shared in my vision, who could be my new best friend and join me in co-founding my new startup. They would also build the whole thing. I would do marketing and stuff.
Spoiler Alert #2: This also didn’t happen.
But I was adamant this was possible. I told all who would listen that if I didn’t source this talent within 3 months, then I’d drop all my clients, sell all my things, kiss my girlfriend goodbye and move to Silicon Valley.
I went to a bunch of startup meet ups, scoured LinkedIn and met for coffee with over 30 developers. I found some who loved the idea, some who I’d hit it off with and some who were dizzyingly smart. And they assured me they could build it. The problem was, I couldn’t find the person who had all three qualities.
Though Dubai is a fast growing and innovative startup hub, after a few months, I was convinced that my problem was Dubai itself. For better or worse, one of the habits I pride myself upon is doing what I say I’m going to do. Or I at least try.
So like any rational person would, I moved to Silicon Valley. I was sure I was now on the road to success. For those who aren’t in the know, Silicon Valley is like Hollywood but instead of movies, it’s for tech startups. It’s where you go to get your dreams crushed. I promise you, I’m not crying over this keyboard. Honestly.
Within a few weeks, I’d moved out of my beachfront, high-rise skyscraper apartment in Dubai, flown 8,072 miles and was now living in the middle of Silicon Valley: Palo Alto.
FYI, due to the tech companies, Silicon Valley is one of the world’s most expensive places to live.
Now, if I have one criticism of the TV show, Silicon Valley, it’s that it’s perhaps too spot on. Enough so that it’s rather painful to watch. If anything, they don’t go far enough.
I was now living in what’s known as a ‘hacker-house’. Typically, this is a shared house, jam-packed with early-startup founders and programmers who need to save cash.
In my particular case, it was a 3-bedroom bungalow (and a garden shed) shared with 14 other dudes. I slept on a bunk bed in a room with 7 of them, and a bulldog, named Benny.
All for the low, low price of US$1500 per month. A bargain. It was fine though, it turns out that 2-for-1 instant noodles have more calories than I’d previously thought.
While this wasn’t the optimum sleeping environment, I couldn’t have been in a better place to get my head in the game and to focus on doing what I needed to: Building my startup and changing the world (sigh).
I was surrounded by other ambitious, like-minded individuals. After every conversation, I would come away feeling like I’d gained a few more IQ points. Startups, technology and making a dent in the universe were all we talked about.
Once I’d gotten settled, I’d thrown myself back into networking. Like Dubai, I met many smart people who owned some of the qualities I desired in a co-founder.
This time, I had another problem. You see, it’s rather hard to tempt the smartest people away from Google, Facebook or Apple if they’re making $250,000 per year. And even then, if they liked the idea, why wouldn’t they just build it themselves? What did they need me for?
After 3 months of burning through my savings and luckless searching, I went back home to the UK to visit my parents for a couple of weeks. It was then that I gave myself another, frustrated ultimatum. I was going to go back to Silicon Valley and if I didn’t find this magical co-founder within a fortnight, then I’d learn to build the damned thing myself.
Needless to say, I ended up having to do the latter. Since then, I’ve decided to rein in this ultimatum-making.
Luckily, despite my paltry living conditions, I was living with some incredibly smart “computer people”. Even if they weren’t going to build my product, they loved that I was willing to try building it myself and they gave me some pointers.
Here’s three of them:
1. You can try to build it fast, or you can try to build it right.
If I had wanted to just throw together an app then there were a few ‘quick’ options.
I could have enrolled in a ‘Learn to build iOS apps in a weekend’ course on Udemy. I could’ve followed along and ended up with a basic codebase that I could tweak some customisation into. Or, seeing as I was trying to build a social network, I could have followed along with one of those ‘build a twitter clone’ videos on youtube to get started.
The issue was, I didn’t know what I didn’t know. Sure, maybe I could have ended up with an ‘app’ within a month or so, but just because you write (or copy) code, it doesn’t mean you know WHY you’re writing what you’re writing. Or how it actually works.
The last thing I wanted to do was launch my product, gain a little traction and then not know how to fix critical bugs, ensure the service scaled, or build new, user-requested features. I knew if I took this route then I could end up in way over my head, far too soon. And I’d be stuck up a proverbial creek without a proverbial paddle.
Instead, I decided to utilise a ‘first principles approach’. I wanted to understand what writing computer programs involved and what the heck this ‘Computer Science’ really was. If I was going to do it at all, I was going to do it right.
So to start with, I enrolled in Harvard University’s online computer science 101 course, CS50. This was the full recorded lectures, workshops and assignments used at the college.
Much more valuable than teaching me to code in any one language, it taught me how to be a programmer and how computers actually worked.
2. Don’t start building it. Yet.
Once I’d learnt to write some basic code, my first intuition was to dive right in and begin building my app. I was told this would be a big mistake.
First of all, I hadn’t yet learnt the difference between good code and bad code. I knew that more code certainly wasn’t better than less code, but that was about it. I was told, very wisely, that in just a few months I’d cringe at the quality of the code I had first written.
Though I hadn’t yet learnt what code maintainability or tech debt was, I understood I should practice on the nursery slopes before trying the black run.
To get some practice in, I put together a few little projects that gradually increased in both complexity and scope. My first few included a calculator, a tic-tac-toe game and a movie rating search app. Eventually, I even built a pseudo-twitter clone with a facebook login feature (oh, the irony). By this time, I knew why I was building what I was building.
By doing this necessary practice, I learnt from a ton of mistakes early on, and avoided the same mistakes being built into my production app codebase.
This has another benefit. You will also start to develop the grit and discipline needed to push through, grapple with bugs, and not give up until you find a solution.
3. There’s more you DON’T need to know than what you DO need to know. Focus on the 80/20.
When I first attempted to learn to program I had a wildly inaccurate picture of what I needed to learn. Not knowing what I didn’t know, and feeling a large pang of paralysis-by-analysis, I was tempted to employ a shotgun approach to learning.
The biggest challenge was identifying what I didn’t need to learn. After all, I only had so much time.
This is where learning to program through first principles was especially useful. By focusing on C as my first language while working through CS50, I was able to get a grasp upon what the code I was writing was really doing.
The other modules within the course touched lightly on each subject, such as machine learning. By quickly learning the broad concepts, it taught me enough that I didn’t need to go much deeper. I could then focus on what truly mattered.
Employing a first-principles approach to learning, combined with the 80/20 approach is akin to developing the ‘branches’ of your knowledge tree first.
Only by developing an understanding of how everything connects and how things really work, can you pull everything together and create something.
By attempting to learn multiple, disparate skills at once, without focusing on depth, you’re merely grasping at the colourful leaves of knowledge, without giving them anything to hold onto.
1. Don’t rush, learn how computers work and what programming really is first. I recommend starting with Harvard’s CS50 course.
2. Again, don’t rush. Once you have some basic programming knowledge, practice building little tools/projects so you can cut your teeth first. Start small and simple. Ideally these projects advance in scope and complexity, towards your final goal.
3. You can’t learn everything and you don’t need to. Identify the 20% of knowledge and skills you need to garner 80% of the results. Grow your branches of knowledge first (broad concepts) so that when you identify which leaves you need (details), they will have something to hold onto.
That’s it for Part One.
In Part Two, I’ll start off by quickly telling you how I failed to build a billion dollar startup (it happens). I’ll then talk about how I came to join Flock as an intern and rapidly developed into a full-stack software engineer. I’ll distill my 3 biggest learnings at the end too.
Matt Cleary's musings on fitness, startups and tryin' to live the good life. You should follow him on Twitter