The previous 4 blog posts were part of a challenge I set for myself: Write one blog post a day for an entire work week. In coinciding with some things I’m participating in professionally, I wanted to practice writing on technical topics aimed at a reader a baseline knowledge who may not have dived into the details of specific topics yet. Put another way, I wanted to write the posts I wish I had found when I was learning about these topics myself.

One of the more challenging parts of actually working as a developer is the need to understand the technologies you are using and creating on a very deep level in order to be able to developer new software, answer questions and communicate capabilities to other people. Instead of writing the minimal level of software needed to get a rubric mark for a piece of logic or code, thousands of real people are engaging with your application and it needs to be robust, extendable, and cleanly written enough that you can effectively maintain it. I like the way that Steve McConnell puts it in Code Complete:

Software’s Primary Technical Imperative is managing complexity.

Software is so complex that no one person can even really understand it. The only way we can even begin to get a foothold is to divide that complexity into simple and understandable parts, and organize those simple parts into a system.

A great source of examples for how this is even accomplished is found by actually diving in to the weeds of how a particular problem works. Some problems are so difficult that nobody has really solved it, and looking at the various approaches can tell you the different ways people have attempted to solve those problems. I wanted to learn some of these general techniques by looking into the functions, classes, libraries, and technologies I use everyday and take for granted. I’ve found that by asking questions like “How does useState work and what problem was it created to solve” I can get a foothold into how I’m even supposed to something in the first place.

The process of looking deeper can also lead to connections with new techniques or technologies in of itself. I barely remembered binary arithmetic from my 2nd year Computer Science courses, but I had a reason to learn about it when writing my post on data serialization. Diving into when something is useful by seeing it actually used is so much more motivational for learning.

Going forward I think I’ll do something closer to a post a week. I may do a challenge like this in the future if I find I’m slacking or have a bunch of topics I wanna write about. I wanna do longer style posts I construct over a few days so I can go into more detail about some of the thing I look into. I found myself writing long paragraphs only to delete them because I felt it was a rabbit hole that didn’t need to be gone down to get a point across. Hopefully you found those posts informative!