Relationships: Non-geeks, Geeks, & Self
“Software design is an exercise in human relationships”—that’s the motto of Tidy First? Which relationships am I talking about?
(The following is a half-baked exploration of ideas intended to get me back to writing book-quality content once I’m clearer. You’ll see the polished version in the book.)
I stunned myself when I typed the motto. What in the world does that mean? Then I got to thinking about it & realized it was true, but that explaining which relationships & how software design enhances/hinders them was the work of the book.
Books. Not one book. This happens every time I sit down to write a book. I think there’s no way there’s a whole book’s worth of content in this topic. Then realize there are several books’ worth. Then I cut scope. And think there’s now way there’s a whole book’s worth of content.
I’ve gone through this cycle twice with Tidy First?. The first set of relationships I want to (eventually) talk about is the relationship of geeks with non-geeks. As geeks we can make stuff. That separates us from those who can only express needs but can’t make stuff themselves. I call these groups “waiters”—those waiting for changes to the behavior of the system—and “changers”—those changing the system.
There are various power differentials between the two groups, some tilting one way, some the other. Software design is one of the activities influenced by those differentials.
Changers design software to enable future (perhaps immediate future, hence tidy first) changes. Changers do this so they can maintain their relationship with waiters. (And also because it feels good.) Without design, changes take longer & longer & trust erodes. So that’s the first set of relationships.
The second set of relationships served by software design are geek-to-geek. If I change an API you use, that puts a strain on our relationship. Now somebody has to do the migration work. How can I continue to make needed changes without breaking trust or becoming annoying? That’s the second set of relationships.
My relationship with myself is the third set of relationships, the one I’m focusing on in Tidy First? Geeks seem to love pain. They’ll use a slow tool or a bad API or tolerate horrible coupling for far too long. The times I’ve done this it’s started with my poor relationship with myself. I’m not worth making my job easier so I just do the hard job, over & over.
That’s why the tidyings are so tiny. They are the least work you can do to make your work easier. Get in the habit of making your work easier & you may find yourself making other people’s work easier & then you may find yourself making your users’ work easier. Who knows where that will turn out?
"My relationship with myself is the third set of relationships, the one I’m focusing on in Tidy First?"
I really felt suffering from this one recently, and would even feel that is the most important one.
Painful / slow review process, tend to just leave me in a uncomfortable state, where I would want to clean code before doing something, but getting stuck with the review taking an eternity.
So I would just "maybe" do Tidying after, but be really in bad code state.
Or suffer from even longer delays if I would clean before, have many changes flying at the same time that I need to rebase.
But that really really frustrates me and limits what I am able to do (and that I want to do without even be forced to).
On one of the project I have 1 tenth of a reviewer so is on an extreme level and can really feel the issue with this.
To be in a nice relation with myself, I need that these cleanups are possible, cheap and fast.
I thought for a long time why I want "Tidy First? and split PRs" even tried to propose it in my team with "objective arguments", used your video as a base, discussed it, and focused a justification on these two first relationships.
But actually, I do not really care that it makes change faster for the 2 first relationships, I really just want a better environment for myself.
Where I can clean stuff, and where behavior changing pull requests from other changers are not a pain to review because they mix too many things.
With still in mind, my freedom limit is when the group freedom is not harmed. So if I want some better things for me, they should be the same for everybody.
So I would compromise and take on me to review really fast these "trivial"/"refactoring" pull requests, just so that if I need to do the same ones, they could be reviewed quickly.
I want a better relationship with myself, and it is acceptable because it does not hurt my changers and waiters colleagues.
As a bonus it even benefits them, but I would personally not anymore put it as first thing. Otherwise a "do shift working to increase the company productivity" argument would also be valid.
Does not work for IT but it's just an example of focusing productivity over people life.
I think in addition to the relationship with ourselves not being prioritized due to a lack of respect for ourselves, I often find it just being a lower priority than the first two relationships. So I don't always actively feel like I don't deserve the investment but it just isn't a higher priority than the needs from the other relationships which often feel more urgent. This is often a bad way to prioritize things since investing in those things for relationship 3 can enable us to more effectively improve the other relationships as well.