tidyfirst.substack.com/p/distinctions… At first, programming is just programming. You think of a thing. You make the computer do it. 🎉

After a while, you notice that not all programming is the same. Déjà vu sets in. “I’ve done this before.”

A list of distinctions in software design. Reversible vs irreversible. Some changes are easily reversed. Make these quickly & with confidence. Other changes have consequences for the larger system. Make these only after double checking. Converting irreversible changes (even partly) into reversible changes creates value.

Pushing The "Hardcore" Button.

There are times in my career when I would have already pushed the Hardcore Button. My self-image was based on out-working, out-intensitying everyone. I wouldn't push it now, but I can understand if someone else does. Here are 3 strategies. 1. Push it & mean it. Before doing this, create a stop loss--if my health gets *this* bad or my relationships get *that* bad, it's not worth it. Because your health & relationships will suffer.

Took me 17 years of struggle, but I can finally explain cohesion in software design. I dropped the Cohesion chapter of the #TidyFirst book yesterday. I'll summarize here. tidyfirst.substack.com/p/cohesion #payWall An element is cohesive if its sub-elements are coupled. A file is cohesive if all its functions have to be changed at the same time.

Folks seem to tune software development for a desired output rate. That's a disaster. Here's why, what to do instead, and (at the end) a speculation about an unhelpful belief that might underlie this behavior. I've been surprised to see smart folks unironically suggest that waterfall development is actually the best way to develop software--specify what you're going to develop, develop it, finis!

I got into a pissing match on LinkedIn (achievement unlocked):
Them: You cashed in on Extreme Programming with all those certification programs.
Me: Ha HA! There *are no* XP certification programs.

My bad. There *are* XP certification programs. Lots. WTAF? I have called the Certificate-Industrial Complex "dishonest", "a pyramid scheme", & "cancer". Once more for the folks who just got here:

Ignorance-as-a-service. My team is experimenting with frequent pair switching. Was it wasteful to be explaining the same basics repeatedly? Seemed like no, but why? Uninformed questions are most valuable when you're likely to get stuck in a local minima. "Ignorant" questions can get you unstuck.

When you aren't clear on what problem you're solving or how you're going to solve it, lack of knowledge is a precious resource.

The goal of software design is to create chunks or slices that fit into a human mind. The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes. This implies that software design is a human process with technical support, done by humans for humans. As shiny as the technical support is it took me a while to acknowledge that messy people stuff.

As part of yesterday's Invitation to Systems Thinking workshop @jessitron prepared a short play from which the students would draw various diagrams of the software development system described. At one point the manager says, "This is not acceptable," and it hit me hard in layers. Layer 1: of course it's acceptable. You've been working like this for months, maybe years. You've accepted it all along.

A story about human connection.

I've played guitar and sang for 50 years. I rarely play for anyone else. I'm haunted by the feeling that I need to be better before exposing myself to others. (Deep roots to this--story for another day.) I have a love/hate relationship with practicing. Sometimes I do it and love it, the sense that I know where the boundaries are and I know if I'm doing it right. Sometimes I do it and hate it, since I could always be faster and cleaner.

Re: observing effort/output/outcome/impact. Here's a concrete comparison of tweets, blogs, and videos. Effort (time invested per item)
* Tweet--5 minutes
* Blog--2 hours
* Video--1 hour

My disagreements around planning seem to revolve around metaphor: a plan is X. Different answers for X lead to different behaviors and different evaluation of outcomes. “A plan is a prediction of the future” is a common metaphor. Nobody out and says that, because it is absurd in an atmosphere of substantial change, but that’s how some folks act.

While working on #TidyFirst this visualization of why software design is a human relationship problem popped up. Thread The cliche product/engineering split has someone with an idea waiting for the behavior of the system to change so they can analyze feedback. These are the “waiters” (seems enough time has passed to reuse this word).

Lots of thoughts around coaching engineers 1x1. Who should do it? How much should it cost? Can it scale? Re: who. I had a manager tell me that their director wouldn’t approve an outside coach because the manager’s job description included “coaching”. Why should the company pay someone else to do the manager’s job?

My poker coach taught me an exercise. Before the start of every hand I sit up straight and while I'm breathing in I say, "Breathing in I have $400 and I am first to act" (or whatever the situation actually is). On the surface, this is in exercise in being aware of the amount of money I have and how much information I will have to make my decisions (acting last is valuable). At a deeper level, though, this is an exercise in accepting reality.

I've said it before but I was reminded again: the first rule of personal growth is that it is always going to get worse before it gets better. I've identified a behavior I want to stop, but I haven't identified the thoughts, feelings, and decisions that precede the behavior. 1/ It seems inevitable that the same (unexamined) setup occurs soon after identifying the behavior. This time, though, as soon as I do the thing again I know I messed up. This feels worse than before.