Skip to content

Index

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.

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."

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.

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.

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.

Ruby's Hash is a Swiss-Army Knife

Link: Ruby's Hash is a Swiss-Army Knife: "A Hash is a built-in data structure in Ruby that maps values to keys and has a constant-time O(1) lookup. This article shows the capabilities of this simple, but equally powerful tool. We’ll start with the basics but also cover some obscure but equally useful features of hash."

A nice review of all the things Ruby hashes can do and be used for.