Deploy fast, deploy often

I recently finished Atomic Habits by James Clear. Atomic Habits had been on my bookshelf for years (ironic given his content around procrastination), and after a particularly irritating bout of increased phone screen time, I finally read it. Clear, a former athlete turned performance coach, writes and speaks on continuous improvement and decision making. His general thesis is that you can increase productivity and life satisfaction by stacking micro habits in your everyday behavior.

While there are a lot of takeaways from Clear’s writing, removing friction from good habits and adding friction to bad habits resonated most. Removing friction from a habit, like taking your gym clothes out the night before heading to an early morning workout session, might be the difference between working out in the morning and sleeping in. Conversely, adding friction to a habit, such as keeping your phone outside of your bedroom to prevent nighttime doom scrolling, might be the difference between meeting your goal of 8 hours of sleep per night and getting a Sunday morning notification that your screen time averages 8 hours per day.¹  

Overall, Atomic Habits centers around one theme: use the power of compounding to your advantage. Stacking micro habits leads to compounding, and compounding leads to growth. Compounding is a popular concept in personal finance communities - invest early and often so your interest accrues interest, leading to a flywheel of wealth creation - but it should be considered more often when discussing personal growth.² After all, improving 1% in a new skill every day compounds to a ~38x fold increase over the course of a year:

Product Development Lifecycle (PDLC)

The theory in tech is that product development should function similarly. To fully leverage the power of compounding, Clear says, you must start small, lean into what works, and be patient. If you do all of the above, you will see exponential gains over time. In tech, you leverage compounding by building a minimal viable product (MVP), iterating quickly, and leaning into features that resonate most with users. With enough iteration and improvement, you will build a product that solves a real problem for a lot of people.

The product development lifecycle (PDLC) is the framework that encapsulates this motion into a well-defined, step-by-step process. It involves capturing feedback on users’ interactions with the product, brainstorming solutions to solve these problems, developing and testing these solutions, launching the feature to all users, and most importantly, starting the process over again.

This is a simple but fairly accurate representation of how an application like Facebook develops from an app where users compare the attractiveness of Harvard students to an app where your grandma is the only one who writes on your wall for your birthday.³

In reality, product development in most organizations is significantly more dysfunctional. Loud customers, know-it-all executives, and ego-driven PMs often get in the way of building products that solve for the majority of users. I’ve seen cases where a sales team sells a feature that doesn’t yet exist, forgets to (or deliberately chooses not to) tell the product team, and there’s a subsequent scramble to solve their need to lock in a contract renewal. Therefore, the actual PDLC is more often something like this:

The first is a data-driven, tested loop, while the latter is an autocratic, untested line (not cycle).

Continuous Integration and Continuous Delivery (CI/CD)

CI/CD is a framework that engineering teams use to make and deploy continuous changes to an application. CI/CD introduces version control (i.e. the ability to log changes over time), automates testing, and enables rapid and reliable releases to users. GitHub and GitLab are the two most common tools for maintaining CI/CD.

Strong CI/CD practices facilitate a strong PDLC in a few ways:

1. CI/CD decreases development time by fostering collaboration via a shared code repository, code reviews, and testing.

2. CI/CD decreases the time between development and launch via automated testing that can quickly catch bugs.

3. CI/CD reduces the likelihood of a rollback (i.e. reverting a change due to bugs) by facilitating user-facing testing in staging deployments.

Implementing CI/CD on williamdecesare.com

The existing process for changing anything on my website was cumbersome and error-prone. CI/CD did not exist, deployment involved several manual steps, and changes went off the rails more times than I’d liked. For an app with minimal traffic, production-level bugs hold less significance. But, they are still an anti-pattern for a product at scale.

The first step to implementing CI/CD on williamdecesare.com was to containerize my app in a Docker image. I’ll save a full rundown of Docker for another post, but the short of it is that Docker reduces dependency issues across machines (i.e. my local machine and the AWS VPS).

Next, I set up a GitHub Action that checks out the code in the main branch on GitHub, builds a Docker image, moves the image to the VPS, runs the image, and restarts the server. The total build time is 1-2 minutes, which decreases deployment time by ~90%. This leads to a much simpler release process:

With a simpler release process, I can now:

1. Release faster: What once took 20 minutes of manual deployment now happens in 1-2 minutes through automated processes.

2. Release with more confidence: Automated testing and the ability to quickly catch bugs means fewer production issues.

3. Quickly and easily revert changes: Having a robust version control system makes it easier to undo mistakes when they happen.

Up next: build a better UI 🖼️

1  I’m in the process of decreasing my average from ~5 hours to my historical average of ~3 hours per day.

2  Friendly reminder to increase your 401k contribution!

3  Good one, Zuck. Also, is a Facebook “wall” still a thing or am I old now?