Three months of freeCodeCamp

I spent the past three months completing projects for the Quality Assurance Certification and the APIs and Microservices Certification from freeCodeCamp (fcc). In addition to passing fcc's automated testing, I wanted my projects to be informed by the principles outlined in Accelerate: The Science of Lean Software and DevOps. The book does not specify which technology is best suited for the job, so I picked a couple that I had wanted to learn for a while, such as Docker. Along the way, I also experimented with tech purely out of interest, such as TypeScript.

In retrospect, I was able to learn most of what I had set out to learn; however, I was only able to complete one of the two fcc certificates for a few reasons. First, the projects took more time than estimated. Second, heroku restricts the number of apps it deploys in the service tier I chose for my account. These factors formed a natural milestone to replace my original goal of completing two fcc certificates.

While it was a choice to apply the concepts of Accelerate to my fcc projects, my instinct tells me that the net effect of this book was positive. It took some time to understand how to use tech I was unfamiliar with, such as Jest, but the loss was offset by gains in time saved writing features. In particular, out of the 24 lean management and monitoring capabilities, I found the following ideas most helpful:

implement test-automation
work in small batches

Test automation and working in small batches led me to understand how important it is to stub out some testable interface. I can always change the logic of the interface, especially with testing in place, but that decision happens later when I have a better idea of what I'm looking for. Divide-and-conquer should be one of the first problem-solving tools that I use when I don't know where to start.

While working on fcc projects, there were moments when I did not know what to do, but there were also circumstances that repeated themselves, such as setting up linters. I was inspired by an article describing an offshoot of readme driven development, so I began to record the steps in order to reduce errors and expedite repetitive actions, which couldn't be replaced by boilerplate as the needs of each project were slightly different:

On each iteration, I reordered the steps to see the benefits of largely commutative steps. For example, is there a benefit to installing a linter before setting up a GitHub workflow? If I had continued to work on the three fcc projects remaining in the incomplete certificate, I likely would have written a script to automate setup. These types of considerations might fall under an idea Accelerate calls improving processes and managing work with WIP limits.

The last concept I applied was automating deployment processes, which was useful although I suspect in order to understand the power of automated deployment, I would have to see it in action when collaborating with a larger group of people. I also did not invest much time in many of the other 24 capabilities although I am curious to learn more. I'm interested in seeing how my thoughts on these topics change and grow in the future.

Links:

freeCodeCamp profile: freecodecamp.org/choilmto

projects completed:

Accelerate: firefinch.io/accelerate-24-key-capabilities