Professional Development

I began programming in my spare time in the spring of 2019. I had been working as a personal trainer for a few years, so naturally the first website I decided to build was a fitness app which could not only track workouts but also recommend new ones. This initial scope was way beyond anything I could achieve at the time, and this quickly became clear as I worked on it (not only due to my inexperience but also because recommending workouts would require AI).

Over the next year I created increasingly complex iterations of my workout tracker but was stuck in what is commonly referred to as tutorial hell. Despite reading constantly, watching tons of videos, and completing numerous courses, I remained unable to really apply what I was learning and unaware that this was the case. A breakthrough occurred in the summer of 2020 when I purchased a Spanish language programming course and decided that instead of simply following along with the instructor, I would translate both the code and the UI to English in real time. This forced me to debug issues which arose from the translation process without the safety net of being able to simply find the correct code in the video or the accompanying repo.

The culminating activity of the course was a clone of Product Hunt, and I realized that I could alter the basic structure of this app to create a project I'd had in mind for a while: a social media site for sharing solutions to programming challenges. I'd been grinding LeetCode and Codewars for months, so this new app would provide me with both a new portfolio project and a way to showcase my coding skills to potential employers. It took me less than a month to finish, and is still featured on my portfolio (the original version of which was also based on a project from the same course). I began blogging as well, publishing a new article each Saturday throughout the fall.

I landed my first job as a web developer in November 2020, almost exactly eighteen months after I wrote my first lines of code. Like many companies, the startup which hired me had received an influx of capital during covid, meaning they'd expanded from roughly five permanent employees to a dozen (I was the twelfth). There was only one other frontend dev at the company, an international contractor named Filipe. It became apparent almost immediately that he did very little work, but he was able to provide guidance when I needed it.

An advertising management platform called AdButler had recently been incorporated into the eCommerce modules of the app, and the very first ticket I was assigned was to add keywords to its requests to help display targeted ads to individual users. I thought I'd done a good job on it, but then in a meeting with the entire engineering department my boss pointed out that I'd misunderstood the requirements. He then proceeded to rewrite everything I'd done over the past week in about five minutes, despite not knowing JavaScript. This was certainly a rude awakening for me, and to be honest I was more than a little concerned that I'd be let go for incompetence.

Fortunately, the next task I undertook was to localize the entire site into French. It was not very technically challenging, allowing me to focus more on gitflow and learning about the structure of the app. The codebase used Angular.js and es5, and this was quite an adjustment for me after always using React and es6+ during the learning process. The QA team and I used spreadsheets to verify that translations were comprehensive and accurate, and it was during this time that I began to really take stock of how unreliable and unproductive Filipe was, as he was frequently AWOL and I wound up having to do the overwhelming majority of the work. At the time I was unsure if he had other responsibilities of which I was unaware, since otherwise it was astonishing that any professional would conduct themselves in this way.

I was then tasked with creating a new page known as the Product Details Page, or PDP for short. It had complicated requirements including intricate responsiveness, so it was quite a challenge for someone as green as I was. Fortunately, the designer and product manager were both easy to work with and we met frequently to ensure we were aligned and all of our decisions were well documented. Once again, Filipe no-showed most meetings and the small amount of code he contributed was of very poor quality. From then on I always attempted to take full ownership of whatever needed to be worked on, since otherwise it felt like a school project where I did almost all the work but we both got an A.

Next up were several redesigns of existing widgets, since the app had never been responsive. I remember being asked to hop on a call with the product team, wherein the CEO asked if the new product cards which I'd built could be incorporated globally instead of just in the one section which had been specified. I felt immense pride as I assured him that I'd intentionally built them in a modular way in case we ever wanted to reuse them elsewhere, and shared my screen to demonstrate this to the team. It was at this point that I knew I was a real developer, although of course bouts of imposter syndrome would continue to crop up from time to time.

Converting the inventory filters widget from a persistent modal to a toggleable slideout proved to be shockingly challenging since the widget was generated by third party software, and I needed to perform a lot of CSS sleight of hand to make it look like the specs. It was also the first time I'd had a legitimate use case within an SPA for traditional JavaScript like querySelector. I realized that my beliefs about code quality and best practices would sometimes need to be overridden for the sake of getting the job done.

As I worked on a new feature which would allow some products to be formularies with no price, I began to fully grasp the value of comments in production codebases. I'd always felt that good code is self documenting, but for this particular feature there were many ways in which even good variable and function names would not convey the necessary meaning to future maintainers. This was further reinforced the following month when we landed a government contract to distribute free masks and covid tests to medical practitioners (since there were now multiple scenarios in which a price could be null or 0, which the previous implementation had always forbidden). We had to work around existing constraints, so it was important not to allow perfect to be the enemy of good, and to clearly explain why certain hacky choices had to be made. We also needed to update JSON responses to include new quantity restriction properties, and this was the first time I'd been directly involved in discussions around API architecture.

The CTO was always reticent to rewrite existing code, but was eventually convinced by the designer that we needed to redo the Order Details Page, one of the most crucial parts of the checkout flow. It was meant to be a coat of paint which would ensure responsiveness and consistency with our new design system, and our main concern was to avoid regressions. I spent nearly a month on the code, and it passed QA with minimal reopens. On the first morning after deploying the new build to production, Slack began to blow up with message after message from customer support. Our users were unable to place their orders.

What had happened was that the redesign included a new form prompting the user to add a credit card if they didn't have one on file. This form was only visible if the order in question included a vendor who billed by credit card instead of through EDI. Most of our users (>95%) did not have a credit card on file since they were not signed up for SaaS products and were merely using our marketplace. This meant that the credit card form was triggered and the checkout button was disabled. However, since there was no credit card vendor in their order, the form was not visible. Throughout all of our testing, no one had thought to try to check out using a non-premium account. I was able to quickly track down the bug and fix it, and we pushed a hotfix within about twenty minutes. This was the first major issue I had directly caused, and it was a harrowing experience. From then on I would allude back to the Order Details Page updates any time I wanted to express my reservations about a proposed change due to its inherent unknown risks.

Up to this point the codebase had never included any form of tests, so we integrated Karma and Jasmine and I started creating test suites. At the time none of us had any idea about how to write valuable tests, and the first attempts I made were laughably bad in retrospect. However, I improved with each new feature and within a few months was writing tests which did add value to the codebase and increase our confidence in it.

As I wrapped up my first year at Sowingo I was tasked with updating the inventory section to allow users to set an optional desired level and minimum level for each product. This stands out as the feature with the largest disparity between our initial assessment of the level of complexity and the actual amount of collaboration and iteration which was required. It seemed that at least once per day some combination of myself, the product manager, and the assigned backend dev would have to regroup in order to discuss some unforeseen complication. This went on for nearly three weeks, although our initial assessment had been that it would only take a few days to complete. Once we finally pushed a build to staging, QA began to discover other edge cases which we'd overlooked.

Having learned from our experience, we did a tremendous job of planning out the next feature we worked on. It was a system which allowed admin users to approve or deny marketplace orders and purchase orders created by their subordinates, and was by far the most well organized feature we ever built. Unfortunately, it never actually wound up being rolled out to real users, but it was still a tremendous example of how planning and communicating during the early stages of feature creation can save a lot of headaches and backtracking in the future.

My next major task was updating the way billing information was stored. We needed a secure solution for storing sensitive credit card information and after some due diligence decided to use a new tool called Skyflow. This was one of the first times that I needed to read and deeply understand third party documentation, which made me feel more like an engineer and less like a coder. I also needed to work closely with the lead backend engineer because there were a large number of edge cases which we had to handle gracefully. Creating UMLs and flow charts proved incredibly valuable.

In March of 2022 I took my first vacation, and during that week off I created the POC of a new project I'd been wanting to build for some time: a website which would allow users to vote on which athletes were the best. I hadn't taken a single sick day or personal day over my first year with the company and was starting to experience a bit of burnout, so it was a good decision to take a little time off to recover. I also realized how much I'd missed coding for fun in my spare time, and now that I was more comfortable at work I decided to get back into it. It was a bit of a struggle to figure out how much time to dedicate in the mornings, evenings, and weekends without risking my mental acuity at work, but I quickly found the right balance.

Over the prior several months Filipe had been tasked with updating the app from Angular.js to Angular 2+, but without any success. Generally he would spend a few weeks trying an approach which a blog post recommended, then come back and tell us that it wouldn't work for one reason or another. My suspicion was that he was not actually trying in good faith. Eventually it was decided that we would incorporate a more modern framework without doing a total rewrite, so he began creating an Angular 9 app and I created a React one. When we compared them, my boss felt that React was the way to go, so we moved forward with that. I've written an article about the way in which React was incorporated, which was the most advanced code I'd worked on at the time and is still one of my proudest accomplishments.

Next up was an improvement to the way features were gated. Over the previous years there had been several disjointed attempts at setting up user tiers and strategies for controlling access to certain modules and widgets, but the requirements of a massive new client necessitated a more granular and consolidated system. The decision was made to add permission overrides like "disable_checkout_button" and "hide_shopping_cart," and I regret not advocating more strongly for denying access by default and only granting it when a flag was present. Our experiences with leaks over the following years would only reinforce this basic principle: it's better to grant only the smallest possible amount of access by default.

As this point it was decided that we would expand the pool of vendors, so we added a new feature which we referred to as External Vendors. This was an incredibly complex undertaking which required a major reworking of the PDP and various other modules, and marked the first time that I had to make large changes to code which I myself had written in the first place. While it was certainly less painful than other similar endeavors, I was amazed at how much I'd improved since writing the original code, but also frequently pleased to note that a decision I'd made at the time with extensibility in mind was now proving to have been the correct call.

We welcomed a new team member named Ana in the spring, and she and I began working on incorporating unit tests into the React repo. She immediately proved herself to be a skilled and hardworking person, and I was overjoyed to finally have a fellow frontend dev who was as reliable and committed as I was. We began making great strides, and for the first month or two after she joined the team I noticed Filipe's performance improving as well, as he was likely concerned that he was being replaced.

Over the summer it was decided that the company would add an entirely new feature called Patient Workflows. This constituted an expansion from managing dental inventory to a broader focus encompassing the digitization and consolidation of everything which goes into running a successful practice (patient records, communication with specialists, and so on). It was an insanely large amount of work, and Ana and I both put in well over 60 hours per week for months on end. I can't imagine how it would have gone without her, but it was an extremely rewarding experience as we spurred each other on and were able to truly collaborate. I finally got to see how programming as a team is meant to be, and for the first time we were provided with a green field in which to work using React and TypeScript.

I was promoted to Senior Frontend Engineer in February 2023, which my boss acknowledged was really more of a recognition of the role I'd already been playing for the previous year. I felt tremendous pride in this accomplishment.

As a result of my promotion several key team members felt comfortable coming to me and expressing concern about Filipe's lack of effort. It had always been a sort of unspoken understanding, but recent performance issues had become so problematic as to warrant immediate action. We decided that it needed to be elevated to the CTO. Filipe was given numerous opportunities to improve his output over the next several months, but was unwilling or unable to do so. After being placed on a performance improvement plan and still failing to meet the reasonable requirements which had been clearly communicated, he was informed that he would be removed from the team in three months' time. He decided to resign immediately instead.

As one would expect, Filipe's departure instantly proved to be addition by subtraction. No more did Ana and I have to take on a bunch of new tickets days before each staging build was due. No more were entire features punted from sprints multiple times. Everything ran much more smoothly now that the entire team was honorable and industrious. I liked him personally, as did we all, but at a certain point a clear eyed assessment of value added needs to occur.

I spent two years as Senior Frontend Engineer, and during that time the workforce gradually contracted from a peak of nearly 30 employees back down to 12. This meant I needed to contribute much more to product decisions than ever before, and to improve my leadership skills. In addition to continuing to be a prolific individual contributor, I also took a lead role in the hiring process and in mentoring junior developers and interns. In my spare time I continued to work on my portfolio/blog and its featured projects, including the personal websites of my girlfriend and my mom along with the final versions of maxWellness and GoatVote.

Almost exactly four years after I joined the team, my position was impacted by layoffs. It was not a total surprise, as I had been privy to certain financial discussions, but it's never easy to say goodbye to your colleagues. I'll be eternally grateful for my time at Sowingo, it was just about the best experience I could have hoped for to start my career.

Since then I've focused largely on creating new blog posts and working on my passion projects, but I've also attempted to take a bit of a sabbatical in order to focus on my health and well-being. A much needed trip to San Diego marked the first time I've left Canada in nearly a decade, and I've also been able to invest more energy into my hobbies of weightlifting and playing bass guitar. I'm excited to see what the future holds!