Northern Lights of Code: Insights from a Prairie Startup Triumph

My journey at Neofinancial has been an exhilarating blend of late-night coding sessions, critical deadlines, and a relentless pursuit of innovation that catapulted us into the Canadian fintech spotlight. This story is about how an idea of making banking a little better grew into Canada's quickest rising unicorn. This was my first start-up, and there was a lot I didn't know. I was one of the first devs and I absorbed as much as I could from the insanely talented team of senior+ developers at Neo. It has reshaped my understanding of high quality code and what it means to build something extraordinary from the ground up.

I joined in 2019 and it has been an intense four years. While the code itself is under wraps, my GitHub contribution graphs record an epic saga of startup life. Sure, contribution graphs carry their weight in controversy, serving as a double-edged sword in the tech world. Yet, I can't help but harbour a sense of pride when reflecting on the monumental volume of work I've poured into this venture. It's a testament, not just to the hours logged, but to the indomitable spirit and tireless dedication that defines the very essence of startup culture. This kind of persistence can only come from a tightly knit team. Hard work is contagious.

I started at the company pre-investment and with no customers and was lucky enough to be there when we reached "unicorn status" and grew to over 2 million users (also 150 micro services, 1500 containers, 700 million queue messages between them each week, 300 million API requests per month, 800 deploys a week). I don't mean to boast, only to highlight the scale. Growing from zero to those numbers was exciting.

We celebrated the wins, but we were far from complacent. I worked on production bugs during holidays and weekends and was accessible 24 hours a day. Each round of funding was a sign that what we were doing was valuable and that we should keep pushing forward. Canadians responded and our customer base grew from just friends and family to something that looked more like a successful business with its eye on the Big Five banks (The top six banks in Canada control 93% of all banking assets in the country [ref]).

When the company started to get larger, with lots of teams working on different things at the same time, it felt like we were sailing inside a classic thought experiment about a ship that had all its parts replaced before arriving at its destination. If all of the code was eventually replaced, was this still the same ship? Every time you looked, something new had been added or changed, and it was hard to keep track of everything. It was like playing a game where the rules and pieces keep changing, but in a fun way. I really learned to enjoy the momentum. If you work in software, you should try working at a startup at least once. Some people I met there say they can never go back. It's a really exciting adventure and there's nothing else quite like it!

The Importance of High Quality Code

I worked alongside veterans of code, their wisdom hard-earned through many battles with the machines. They taught me, in their quiet, determined way, that the essence of code isn't just in the typing - it's in the crafting. "Quality," they said, "is your speed."

Slow is smooth. Smooth is fast.

Slow down, find your rhythm, because smooth is fast. It was a very zen koan type of advice, but I think most people knew what it meant - be fast, but be careful. Don't mess up production. It was Hemingway meets Hunter S. Thompson, but with keyboards instead of guns - each line of code a bullet, each epic a campaign, where patience and quality were not just virtues but necessities for survival. I took note of what the seasoned developers around me did.

Avoid Unfinished Work - Partially finished tasks pile up over time. When you don't finish things all of the way, you are creating new work in progress (whether you document it or not). Experienced devs have merged lots of code in their lives, and know the value of not having to return to the same place again because of a missing feature or incomplete work. Leaving TODOs in code is not something they are willing to do. They don't take shortcuts, and they build code to be ready for growth and new features bloom in the nurtured soil.

Build for Growth - When scope begins to inevitably creep and new features are needed, early shortcuts get exposed quickly. That's why, when writing code, we should try to anticipate what might be coming next and make sure that our contributions are easy to change and update for times we can't. DRY (Don't Repeat Yourself) is a noble pursuit, but shouldn't come at the cost of making future changes difficult. Sometimes it is okay to repeat yourself now if you expect two parts of the codebase may need different behaviours later on. One simple example is not coupling your data storage types to your data request object types or DTOs.

Refactor as you Go - In the high-speed, caffeine-fuelled world of startups, the luxury of time for a leisurely code refactor is about as common as a moose trotting down Main Street (even in the Prairies). Let's be honest, it's not the flawless code that fills the coffers. Nonetheless, the best senior devs who I worked with all maintain quality as they go. Write clean code on the fly and make every keystroke count. If you are touching some code and a refactor makes sense, do it now and do not wait.

Document Patterns - Development cycles can move fast (esp. in a startup) and documentation often gets left behind. You could be crafting the something great, but if your team's in the dark about how to wield it, it's as good as dead - another ghost in the machine. Experienced developers leave crisp, clear documentation that acts like a treasure map for the rest of the crew. These ensure that when a good pattern is established, it can proliferate throughout the codebase.

Document Code - From reviews to re-writes and refactors, it is likely that code will be read much more often than it will be written. Sure, we love to chant the mantra "great code documents itself," but let's get real. When you're juggling micro-services and your teams are potentially in different cities, socializing a change in Slack or whatever chat tool you haunt can make all the difference. Make it easy, make it accessible, and your code won't just live; it'll thrive, spreading through the codebase like a warm chinook wind.

Keep a schedule- For two of the four years, we were quarantined and working from home. I learned what it is like to sit in a room at home and work extreme hours and lose track of time. My (now) wife would insist that I go for walks and eat at normal times and it forced me to maintain a bit of normalcy during a time when it was easy to get lost in work for full and long days. I would often solve bugs in minutes that had been harassing me all morning after a brief 30 minute walk in the fresh air. Quality time away from screens is ultimately helpful for maintaining quality work inside them.

Sleep - I don't always listen, but sleep matters. We celebrate the all-nighter, hackathons, the rush of creating something new while the world sleeps. I love it. But the cost is real. Less sleep, less than six to eight hours, and you're not as sharp the next day. Consider that before deciding to code through the night or to rest.

I'm on the outside for now - on the other end of an epic journey from the a tiny co-working space where we began to the high-flying unicorn status of a Prairie Tech Darling. It's been a mad dash, a relentless sprint through a minefield of code, lessons, and life hacks that hit harder than two Java Monsters on ice in a Stanley cup on a Monday morning. I am grateful for my time and can't wait to see what Neo develops next.