A look back at twenty years of writing code

In one way or another, I have been writing code for the last two decades. If I am being honest with you, dear reader, I can't pinpoint the exact time I wrote my first software, but it is close enough to twenty years to take some poetic license with this.

If you'll indulge me in this journey, I want to share how I got here and what I learned along the way.

My path is by no means unique, but I am sure it shares commonalities with many out there. This will be a longer post than most, so I will spare you the long-winded introduction and jump right in.

My first program

The first time I wrote code, I was ten. A good friend showed me his book on HTML while on the bus home. Being a jealous ten year old, I decided I wanted to do that too. It was petty, but I was a kid. With the generous financial assistance of my parents, I picked up a three hundred page introductory book on HTML and set it to work.

This was about as basic as you can imagine. Windows 98, notepad and me typing everything on one long line. The most visceral memory I have of that day was the first time I became angry at the computer. I'd typed some (probably unmatched) elements into notepad, hit save, and nothing came up. I had no concept of debugging at the time, so the code was in a binary state of working or broken.

I am not too proud to admit that I let the computer win that afternoon. I deleted the file in a rage and went for lunch with my family. The second visceral moment was sitting at lunch and realising why my site wasn't working. I quickly finished my lunch and set home to fix it.

I did manage to fix it in the end. From there, I get set on making something more interesting than my name on a page. The first non-trivial thing I made was a very simple game. Each page had two doors, pick the right one (as a hyperlink), and you moved to the next stage, pick the wrong one, and you'd see a game over screen. Not too bad for a kid, but I had a long way to go.

At some point, I made a follow-up program. I was pretty into turn-based RPGs, probably thanks to pokemon and final fantasy, so I made a simulated battle game. What I didn't know at the time was, well, everything. I could make pages with text and links, and that was about it—every button linked to a new page with some predefined state. No randomness. After creating a dozen or so pages, I got fed up and abandoned the game.

It was a small step but one that set me on a path that continues today.

High school

The first two years of high school were interesting for the usual reasons—a new school with a group of new friends and teachers. As far as software goes, the most important here was a friend, DS.

DS and I became friends through serendipitous nonsense that draws any two kids together. Laughs in a class, countless sleepovers and a handful of shared interests. One of those interests was Flash.

At the time, Flash was developed by Macromedia. Sites like Newgrounds and Miniclip were the source of both animation and simple games. DS's mum got him a copy of Flash and we set to work building small dumb projects.

We built a mad libs game and a breakout clone which was just a tutorial project with different colours. We submitted them to Newgrounds, got slammed for our low effort work and kept iterating.

DS, it turned out, was more into animation and had some success with some short videos. I made a few small games that were not well received but kept at it, convinced that I was going to make great software one way or another.

After I left to move interstate, DS and I lost touch. Years later, I went to look him up online to find he'd passed away in an accident. That's a terrible way to learn of someone's passing. I miss you mate.

High school part 2

Midway through high school my family moved interstate. Due to some odd schooling rules in Australia, I went from grade 8 to grade 10. It also meant that I would be taking dedicated programming subjects for the first time.

Our class, Information Processing and Technology, used Delphi as its programming language of choice. I have no idea why, but it served as good a tool as any to throw me into the deep end.

Formal education in software development was a big step up in my capabilities. I remember receiving harsh feedback on a math tutor program we created to help kids learn times tables. I had picked what I thought was a cool and edgy colour scheme and font but was put in my place when asked, "does this seem like a program for 4-7 year old kids?" My first experience realising I was making programs for real people.

Towards the end of high school, I was invited to participate in some competitive coding competitions. I formed a team with two other guys in my class and we set to work. We did not do particularly well, but the challenge of solving hard problems in a team unlocked something in me.

In our final year of high school, the three of us were allowed to take a first-year university course in place of our IPT classes for one semester. We took an introduction to C course as distance education students. I loved C. It felt as much like being a TV hacker as I had come so far. Our final project was a free choice program to demonstrate our skills. I remade my turn-based RPG battle game on the command line. It was far less linear but, judging by my grade, not much more fun.

Two other, somewhat disconnected, moments come to mind from my final years in school. First was another moment of jealousy. I was taking advanced math, and we were learning surface integrals. The teacher described a past student who wrote a numerical integrator in C because they couldn't solve the integral by hand. The teacher was impressed and awarded them the grade. I remember sitting there wondering how such a program could exist. One that solved maths problems with code.

The second moment was the 'launch' of my first public software. Around the time (2008), the iPod and iPhone became a lot more popular. Apple had just opened up the app store, and anyone could write programs and sell them. To me, this was newgrounds.com multiplied by a million.

I built a very simple app that randomly placed a tiny target on the screen. You tapped the target as quickly as possible, and it told you your reaction time. I put it on sale for 99c all over the world. To my surprise, people bought it. Not many people, I think I made just enough to repay my parents for the developer license fee, but I had sold software and made money. After this, my future was set.

Undergraduate engineering

After graduating high school, I began a degree in engineering. With a fairly standard first year, the main goal was to decide where to specialise. After several introductory subjects, I chose electrical engineering. Given I have spent so much time writing code, it would be reasonable to ask why not software engineering. In the end, it was pretty simple, I enjoy electronics, and there was plenty of software in electrical engineering but not vice versa.

Majoring in electrical engineering also allowed me to work on embedded programming. This was a few years before the Arduino was released, which meant we were programming AVR microcontrollers using serial ports on the back of some fairly dated desktop PCs. Our first lessons were in AVR assembly, writing OP codes and GOTO statements to light up simple LEDs. We used a tool called PonyProg, which played loud horse noises on startup. Strange times.

Later we learned embedded C, which was an interesting challenge in optimising memory and operations for such a tiny device. Bitwise operations abound.

In parallel, we learned python. The class assumed zero programming experience, so it was a back-to-basics walkthrough of variables, loops and eventually simple GIUs.

Second-year classes included C++, a deep dive into OOP and learning VHDL and Verilog for FPGAs. Several courses were also teaching us Matlab, but I didn't pay much attention as it seemed like a bloated tool for simple math. A naïve position, but I was young.

Around this time, I also got my first engineering job. I worked at a mining company as there were few local software jobs at the time. Given that I was studying electrical engineering, I was assigned to check cables against the sizing standards to ensure they were specified correctly.

I wrote some visual basic within excel to automate most of my job. It turned a 40-hour process into a 10-minute job. The code I wrote ended up being used by several teams in the company and eventually caused them to hire a full-time developer to turn my flaky spreadsheet into an Autocad extension.

In my second year, I also took a course in operating systems. We worked on adding new file systems and drivers to the Linux kernel. Work that peeled back the mystique of software I used every day. More than ever, I realised that the magic was becoming a science.

Learning to Teach

The second half of my undergraduate degree marked a shift into teaching. To supplement my time at the pub, I picked up tutoring roles in several first and second-year programming subjects.

There is a solid truth to the idea that you don't know what you know until you try and teach it.

Teaching helped me learn to communicate my ideas better and solidify many concepts in ways clear enough to pass on to others. I was also fortunate enough to learn that I also really enjoyed the work.

At the same time, I was learning new ways to apply my skills. Classes in photonics taught me to solve ODEs with code, and team projects taught me the delicate art of coding with others.

My final year thesis was a project to help kids with cystic fibrosis. I've written about that before here if you're interested.

I also spent time assisting professors at the university with experimental work. That work eventually led to my PhD in computational electrodynamics, bringing together my software and electrical engineering courses.

Grad School and professional development

Grad school was a combo of my PhD and my first fledgling startup. I was quickly reintroduced to the world of Matlab when inheriting a growing codebase living in a shared Dropbox folder. Like it or not, I had to become proficient in Matlab and given I had ample opportunity to write code in languages I preferred outside my PhD, I took on the challenge.

Pepster, my startup, was all about the gamification of physiotherapy to help kids comply with routine. This gave me an excellent opportunity to optimise for fun. Flashbacks to my high school math learning program quickly reminded me that my target user measured their age in single digits. This meant a UI with simple instructions and feedback mechanisms that were cute rather than earned through sacrifice. On top of this, given we had strict requirements on how the underlying physiotherapy was performed, controls became a significant constraint. The kids using the device had no hands free to tap the screen and had to control their breathing in a very rigorous pattern. We did our best to add enjoyable extra gameplay before and after the physiotherapy to keep them engaged.

During this time, the world peaked on gamification. This led to another project to try and tame the ever-growing first-year engineering courses. These subjects enrolled 1200+ first-year students, and disseminating information became tough. To help, a friend and I put together a tiny stack overflow clone for the courses. We built LMS integrations into blackboard and tried to reward active users with digital badges and points. The target was to centralise discussion, saving hours answering the same email to dozens of students.

This project went pretty well. We secured a small grant to continue working on it and eventually had it in use within around a dozen courses. It gave me some first-hand experience managing sites with daily visits in the tens of thousands. The transition from manual code changes and a quick restart to a more script-driven deployment setup was also a good lesson in managing software in the real world.

Given this section was titled 'grad school', you may be thinking a lot is going on here that isn't a PhD. Around two years into grad school, you, me, and my supervisor would all certainly agree. The startup reached the need to raise funding, and we couldn't justify the cost of hardware in the end. This was a sign to double down on finishing my thesis.

I spent some time revisiting the Matlab codebase. Little by little, trying to get the code into a more maintainable state. I slowly learned the art of turning papers into lines of code, and all the pieces from undergraduate fell a little more into place.

I learned a lot about software development during that time—some things as best practices, others as lessons and mistakes. I was at a point in my career where I could take scientific work and turn it into usable models for simulation or optimisation. A skill that would prove helpful in the years to come.

Startup two and coding less

These days, I write less code than I used to. Since starting my second startup, I have gone from primary contributor to almost full-time manager. It's a natural progression but not always one I have been comfortable with.

At the start, it was a matter of control. I had to learn how to be okay with people doing things their way. In the early years of Maxwell Plus, I am sure I got in the way just as often as I helped.

Later, it got into my head that I was taking my eye off the goal any time I was coding. As the CEO, I shouldn't be writing code, ever. This was a substantial swing in the other direction, and one I also learned was far too extreme.

Eventually, I've gotten to a point where I am reasonably comfortable. I sometimes work on small projects but don't put myself on the critical path. As our company has matured, we have more people knowing how all things fit together, and I am no longer the sole source of answers.

I've also recently come to realise the value of non-work projects. I can build or play with small things that I am happy to leave dormant for months if I can't find the time. Maybe one day I will make a game, maybe not. Whatever the case, I'm thankful for the odd series of events that have brought me here.

I am looking forward to at least another two decades of writing code.