When maintaining large software systems, you will likely have multiple environments with names like Prod, Staging, Dev, Eval, UAT, Daily, Nightly, or some remix of these names. To distinguish this type of environment from the dozen other things in software development that we give that same name, these are often formally referred to as Deployment Environments.

One question I’ve never been asked directly is: “What is an Environment?” This is surprising; because not understanding what Deployment Environments actually are is one of the most common pitfalls I see in my day-to-day work.

Last year, I wrote about migrating this blog to Next.js. It ended up being a huge post, so I wrote a <TOC> React component to make it more navigable. You can also see the TOC in action on this page:

The bulk of the logic for this component is based on Emma Goto’s great examples in her ”How to build a table of contents in React”, with a few improvements worth discussing. If you haven’t yet, go read that post! Emma does a great job showing both the final working solution and explaining the thinking behind it step-by-step.

In February 2020, I migrated this blog from WordPress to Gatsby. Using Gatsby also allowed me to switch from hosting my site on a paid plan on SiteGround to a (usually free) plan on Netlify.

The migration made sense to me at the time: static-site generation was all the rage, and Gatsby was the exciting new thing. It promised better performance and improved my authoring workflow with Markdown and React. Saving a few dollars a month on hosting didn’t hurt either.

To this date, schema-dts is the only side-project I have that achieved better-than-moderate success. It took several hours between the time I had the idea for schema-dts and when I had a reasonably working v0.1. I pulled an all-nighter—something that I hate doing and would never recommend—not out of sheer passion, but because:

• I knew how rare a moment of inspiration is, and
• I knew that if I went to sleep, I would never finish this project; there’s a graveyard of unfinished projects haunting me.

In the Unity for Software Engineers series, I give an accelerated introduction to game development in Unity. Subscribers have been following this series over the past few months, often suggesting areas to cover or elaborate on. A few months ago, a reader—also a software engineer—reached out to me (lightly edited, emphasis mine):

The biggest unknown for me is: How do I start? What does the process of creating a game look like? Should I build the scenes first? Should I design the gameplay mechanics first? With business software, it’s much more familiar. It’s easy to think, “Well, okay, I need to write the DAO or controller, etc.” But with games, I’m lost.