Articles

Articles I've read and liked.

Lockhart's Lament

Barrels and Ammunition

Things you should never do, Part 1

Rewriting from scratch is almost never a good idea.

"Founder mode" and the art of Mythmaking

Distributed Systems Shibboleths

DevEx: What Actually Drives Productivity

A human-centered approach to developer productivity

The SPACE of developer productivity

Write better error messages

Describes the failures of bad error messages, and also gives an opinionated view on what good looks like, which I think is a pretty good one. If all error message writers learned the lessons described, the world's software would be significantly better.

Questioning vs Asking

Asking questions from a place of genuine curiosity has been a game changer for my own learning, and for my work relationships. Sometimes, as you're about to ask a question (e.g. in an email or a message) it is as simple as tuning into your own thoughts and adjusting your intention, without even changing the words you're using. In doing so, we can tap into the part of our selves that is focused on learning, rather than winning.

The Plan

Thinking about the complexity of the Kubernetes ecosystem

I like this empathic treatment of Kubernetes from the perspective of new users, experienced users, and of the its creators. I think this empathy bears applicability to other domains as well, such as build tools.

Using Gradle to download and run anything

I like this little trick. I wish the official Gradle documentation had more things like this. I should add it as a sample.

Project Loom and Thread Fairness

Thinking about the complexity of the kubernetes ecosystem

I like this article for its balanced take on the kubernetes experience, and the project's role in the tooling ecosystem for deploying applications on cloud services.

CUPID - for joyful coding

Joyful is a great word to describe the feeling you can give to yourself and your colleagues by writing code with care. Read the corresponding paragraph of the article.

The CUPID properties themselves are great. Something I like is that even for one class in an object-oriented design, you can look at it through the lens of these values. I don't find that the same is always true for the SOLID acronym.

LMAX disruptor

Distributed Systems Shibboleths

I really liked the positive shibboleths here. In particular:

• We made the operation idempotent
• The system makes incremental progress
• Every component is crash-only

These are all great qualities for any piece of software to have: Idempotent operations, incremental progress, and uncompromising, early, failures.

Chesire Yeomanry

Tech perhaps could learn from the Yeomanry.

1. Mission command

People ... have a mistaken idea that the Army is rigidly hierarchical. Yes, it’s always extremely clear who’s in command and we have etiquette, symbols and ceremonies to reinforce this, but the Army and especially the Yeomanry is actually excellent at integrating everyone’s input and empowering people at all levels. It’s sacrosanct that I tell the people in my Squadron what I want them to achieve, and not how to achieve it. They take a goal from me and then use their own initiative to make it happen. This is ‘mission command’ and violating it and micromanaging my Yeomen is a real taboo. If you try to tell a Yeoman how to cross a piece of ground in their vehicle rather than telling them where to get to they’ll certainly let you know what their job is and what your job is. I feel like tech could really learn something from this.

1. The importance of explaining why

... People think the Army is all about just being told what to do and doing it without question. Really, the Army is fastidious about telling people why they’ve been told to achieve something. In our way of delivering orders we emphasise explaining the context two levels up. I may tell my soldiers to raid a compound, but I would also tell them that the reason for this is to create a distraction so that the Colonel can divert the enemy away from a bridge, and that the reason the Brigadier wants the Colonel to divert the enemy is so that the bridge is easier to cross. Not only do the soldiers then know why it’s important to raid the compound (so that others can cross the bridge), but they know that if for some reason they can’t raid the compound, creating any other diversion or distraction will do in a pinch, and if they can’t do that they can still try to do something to make it easier to cross the bridge. It lets everyone adapt to change as it happens without additional instruction if they aren’t able to get in touch with me. Again I think tech could possibly learn from that.

The Tyrany of 'what if it changes?'

I don't like the Java-bashing, but this article touches on an important skill of good software engineers - accurately estimating the cost of hypothetical, future change.

Example 1: An essential implementation of some specification in your stack is notoriously slow at releasing security patches. It might make sense to decouple from this tool quickly. This might be your choice of JDK.

Example 2: The S3 bucket path for storing some data is hard coded. You probably don't need to care about the risk of this changing. If it needs to change, you will deal with it, no problem.

Founders should think about channel/offer fit instead of product/market fit

BashFAQ/045 - Mutual exclusion in Bash

In your darkest hour, you may need this.

Why I like Java

I don't like this article, but I like this cherry-picked excerpt, because it describes a programming feeling that I like: The feeling that your software is a just matter of time. Of course, I do take great care to see that I am doing things in the right way.

In Haskell or even in Perl you are always worrying about whether you are doing something in the cleanest and the best way. In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try ... the only thing you can do is relax and keep turning the crank until the necessary amount of code has come out of the spout.

Minsky moments in Venture Capital

---

Created on 2022-05-28

Updated regularly