Posts on For my friendgineers

Technical debt has been on my mind a bunch the last few weeks.

image source What’s more important, starting or finishing?

image source I had a different topic on my mind for today but life and the internet have conspired to change my mind.

Customers are and partners are different.

A best practice is a “method or technique” that often produces superior results.

Did you know that applesauce can be an important part of refactoring, understanding code, and honest function naming?

I’ve talked about Chesterton’s Fence before.

I’ve talked about The Unix Way before.

I’ve talked about the difference between Test After Design and Test Driven Design before.

Pop quiz.

Just what is a tradition?

I’ve talked about rework avoidance and the advantage of taking smaller steps.

In the past I’ve talked about Why We Test.

Continuous delivery is the idea that every change, or at least every change a developer thinks is done, gets built into the product and into customers hands.

The other day I mentioned to someone that we had a scream test scheduled for a few weeks from now and they gave me a very confused look.

If you need to do something millions of times a day it needs to be repeatable and, ideally, idempotent.

Test After Development (TAD) or Test Driven Development (TDD)?

I don’t know about the lint filter on your dryer, but our current dryer, and every dryer I’ve used before this, had a message on or near the lint filter something like this.

You’ve probably heard the quote from W.

I’ve had a bunch of discussions lately around the nature of software development.

For those that know me, it’s no secret that while I like a lot of Uncle Bob’s specific advice (clean code, unit tests, I have some problems with his overall approach.

It turns out, unsurprisingly, that having 500+ blog posts in a single directory isn’t a great way to run things.

I’ve talked about vision and mission statements before.

We test to find bugs, or at least make sure there aren’t any, right?

In part 1 I talked about how your “level” or title was just a way to describe the scope of influence you had.

Bias for Action is one of Amazon’s Leadership Principles.

The typical user story starts something like As a <persona>, I should be able to <task to complete> That’s a decent format, or at least it’s a minimum bar.

In Part 1 I described how your level is a proxy for scope of influence.

This is a real thing you can buy.

I’ve often (usually?

Time passes.

I’ve been doing this for a while.

Speed kills.

Q1 is done in most places, so Q2 planning is mostly done as well.

You’ve probably heard of the Gang of Four and their book, Design Patterns.

Context is a concept that comes up here a lot.

I’ve got a Remarkable 2 next-gen paper tablet.

I’ve talked about context before.

Test Driven Development, as I’ve said before, is really design by example.

Who’s more important, the person who comes up with a weird idea, or the person who validates it?

Some call them Postmortems, Post-Incident Reviews (PIR), or Root Cause Analysis.

I’ve talked about guardrails and Root Cause Analysis before.

“The wider you spread it, the thinner it gets.” – Gerald M.

Paraphrasing Eisenhower and von Moltke, planning is important, plans, not so much.

OKRs.

I’ve spent the last 10 years or so down in the metaphorical engine room.

No, I’m not channeling my kids on a 20 hour car ride (although that has happened multiple times).

As a general and President, Eisenhower had a big impact on the US.

Today I started the latest chapter in my life.

I’ve mentioned Chesterton’s Fence in a couple of previous blogs, but I never did define it.