Skip to content

2023

  • 1 min read

You're the OS!

Link: You're the OS!: "Become a computer operating system and try not to anger the user!"

Really cool game to learn something about operating systems.

  • 1 min read

The Worst Programmer I Know

Link: The Worst Programmer I Know: "The great thing about measuring developer productivity is that you can quickly identify the bad programmers. I want to tell you about the worst programmer I know, and why I fought to keep him in the team."

  • 2 min read

Costs exposed: Monorepo vs. multirepo - Julio Merino (jmmv.dev)

Link: Costs exposed: Monorepo vs. multirepo - Julio Merino (jmmv.dev): "In software engineering organizations, there are certain practices that keep costs under control even if those seem more expensive at first. Unfortunately, because such practices feel more expensive, teams choose to keep their status quo even when they know it is suboptimal. This choice ends up hurting productivity and morale because planned work is continuously interrupted, which in turn drags project completion. The reason I say seem and not are is because the alternatives to these cost-exposing practices also suffer from costs. The difference is that, while the former surface costs, leading to the need to allocate time and people to infrastructure work, the latter keeps the costs smeared over teams and individuals in ways that are difficult to account and plan for. To illustrate what I’m trying to say, I’ll present three different scenarios in which this opinion applies. All of these case studies come from past personal experiences while working in different teams and projects. The first one covered in this post is about the adoption of a monorepo vs. the use of multiple different repositories. The other two will come in follow-up articles."

I’ve never used a large monorepo myself, but they do seem to be the way to go.

  • 1 min read

Costs exposed: Monorepo vs. multirepo – Julio Merino (jmmv.dev)

Costs exposed: Monorepo vs. multirepo - Julio Merino (jmmv.dev) –In software engineering organizations, there are certain practices that keep costs under control even if those seem more expensive at first. Unfortunately, because such practices feel more expensive, teams choose to keep their status quo even when they know it is suboptimal. This choice ends up hurting productivity and morale because planned work is continuously interrupted, which in turn drags project completion.
The reason I say seem and not are is because the alternatives to these cost- exposing practices also suffer from costs. The difference is that, while the former surface costs, leading to the need to allocate time and people to infrastructure work, the latter keeps the costs smeared over teams and individuals in ways that are difficult to account and plan for.
To illustrate what I'm trying to say, I'll present three different scenarios in which this opinion applies. All of these case studies come from past personal experiences while working in different teams and projects. The first one covered in this post is about the adoption of a monorepo vs. the use of multiple different repositories. The other two will come in follow-up articles.

  • 1 min read

Practical Stimulus: Building a Counter Component

Link: Practical Stimulus: Building a Counter Component: "In this article, we will build a counter component using the Stimulus JavaScript library. This simple example will demonstrate a bunch of useful features of Stimulus such as managing state, handling events, and targeting DOM elements."

A really excellent and simple explanation of Stimulus, a lightweight package for implementing responsive web pages.