Practicing Developer Weekly S1-E3

Welcome back to Practicing Developer weekly!

Let’s jump right in.


Add by subtracting.

I love commits that remove more code than they add.

I love software updates that replace several half-baked features with a single well-considered one, or even just get rid of things that never quite made sense.

My favorite way to make my house more comfortable and pleasant to live in is to get rid of stuff I don’t need anymore.

My favorite way of building a happier and healthier life is to stop doing certain things that no longer serve me well.

Before you can sow new seeds, you first need to get rid of the weeds.


Does that thing belong in a Stack, a Queue, or a Pile?

A TODO list is often treated like a queue: First item on the list gets worked on first, then the next, then the next, until you get to the end—which in practice, rarely comes.

But first-in, first-out sequencing is not natural law.

We routinely throw them out the window in moments of urgency anyway, replacing the queue with a last-in, first-out stack. Of course, we don’t think of it that way… instead, we just run off in fire-fighting mode, putting our regular queue of work on hold until we clear the stack of urgent tasks.

But when we get overwhelmed or disrupted in some way, we lose sense of both the queue and the stack and instead end up with a messy and disorganized pile. This is wh what happens when we end up working on whatever happens to catch our attention in the moment, but there’s no rhyme or reason to how it’s sequenced.

Things get interesting when rather you start actively observing the stacks, queues, and piles in work and life. Each has their own set of unique tradeoffs to them, and so being intentional about what ends up where goes a long way.

(More on this idea in a future letter, but feel free to reply if you’ve got thoughts or questions about it)


Do repeat yourself.

No need to rush to abstract something away before you understand it well enough to separate the specific from the generic.

No need to automate that which has not proven itself to be scalable yet.

No rush to make the decision that “We’ll do this thing the same way over and over” until you’ve benefited from the experience that comes from actually doing the thing in several different contexts.

Do repeat yourself. Just don’t do it mindlessly.

Let each repetition deepen your understanding and appreciation for the patterns you come across as you work, and then let your understanding and appreciation be the basis for figuring out what to automate and when.

(There’s no singular magic moment, but usually when something has become genuinely boring — it’s a sign you’ve found a pattern that’s stable enough to scale)


“When you read tweets you are actively consuming people’s belief systems. Every now and again stop to question the information you are presented with. Think for yourself and your context.”

Benedicta Banga

“If Conway's Law surprises you, you haven't been seeing code and organization as one system.”

Michael Feathers


What are you currently stuck on, and what is one concrete next step you could take to help get yourself unstuck?

(Or less stuck, or stuck in a different way, etc.)


That’s all for today. Thanks for reading, and have a great week!

-greg