In athletics, “training periodization” is a method of structuring periods of progressively-loaded training stress, followed by rest periods. In short, this means an ebb and flow of the amount of work put in, typically in four week sets where the first three weeks increase the workload, followed by the fourth week of a greatly reduced load.

The same principles and periodization phases can be applied to learning – and in turn, any career in which learning is a core part of the requirements. Constant learning is a requirement of software development. Just like in athletic training, if we’re always pushing at or above our limits, we will never recuperate enough to retain the benefits of what we’re doing. And in turn, jumping over a few connections and tying our work to our business’ perspective, we’re going to start losing money.

A short recounting of the thing that changed my mind forever on strict type checking for JavaScript.

Path aliasing, sometimes referred to as import or module resolution, in the earliest and most naïve sense, is a method of overloading the Node Require Resolution Algorithm so that it first looks in some particular defined folders for modules of a given name before looking for installed modules of the same name in node_modules folders. While this seems handy at first glance, in practice, it’s is an unnecessary maintenance overhead in large distributed teams and a sign of poor code organization and architecture.

When was the last time you stopped to think about the cost of a new third-party package that you’re adding into your process?

Where do you recommend balancing between “not invented here” syndrome and using packages just because they exist? I always come back to the “left-pad incident” as an extreme example to avoid the latter, but where should we be drawing the line between the two?

Let’s take a moment to break down considerations that I try to make when balancing writing code against pulling in third-party modules…

How do so many people just ignore cruft in their projects and keep moving forward? I was fighting with a bunch of package.json files recently that had 10s of dependencies that were completely unused. Why was it left this way?

The problem with Web Components has and always will be that they were designed for the browser and not for the developer. As many features as they get, they’re still ergonomically odd and difficult to maintain.

We’re now nearly a month into the year 2023. I’ve started a new job and have been doing a lot of research for new projects and auditing old code. This process has given me time to reflect on what is and is not working – and what I’d like to see going forward this year.

I’m a bit of a stickler about meetings. If I can, I like to instill a healthy meeting culture in teams I work with. Not all meetings are bad, but I have some rules that I like to follow to ensure that they don’t become that way. This is my list of tips for keeping meetings healthy and useful.

I’ve been thinking back to my time as a core member of the original team that built the Twitter web app. I learned a great many lessons there and thinking through them: How would I rebuild something similar to the Twitter web app today, like a Mastodon or Activity Pub web client?

We all make mistakes in the technical planning process that bubble through to execution. Looking back over the past 10 years or so, these are the two biggest tech & development mistakes that I think I have made and the lessons that I’ve learned from them.