You should be wearing two watches
Antonio G. Di Benedetto in The Verge
A little over a year ago, I made the conscious decision to wear both a traditional watch on my left wrist and a smartwatch on my right wrist day in and day out. And I’m here to tell you with a straight face that this best-of-both-worlds solution has no downsides.
Most days, I wear a Fitbit Charge 5 on my right wrist and a traditional watch on my left. I agree with Di Benedetto, it’s the best of both worlds.
Do you have a brand or just a logo?
Committee or Working Group?
The difference between a working group and a committee
working groups relax organizational boundaries while committees reinforce them
Replace “AI” with “Automation”
I think that discussions of this technology become much clearer when we replace the term AI with the word “automation”. Then we can ask:
- What is being automated?
- Who’s automating it and why?
- Who benefits from that automation?
- How well does the automation work in its use case that we’re considering?
- Who’s being harmed?
- Who has accountability for the functioning of the automated system
- What existing regulations already apply to the activities where the automation is being used?
Five things I like right now
Apple Music just started showing me a new “Discovery Radio” channel. So far I’m getting a lot of downtempo electronic jazz, like St Germain but new. Cool.
Justified. It’s a little of-its-time (early 2010s), but it’s good, too.
I just finished Kill it With Fire by Marianne Bellotti. It’s about replacing legacy software systems. Bellotti is an anthropologist by training, and though she’s clearly a fantastic engineer, the book is really about change management.
There are three or four fundamental concepts that were new to me in Kill it With Fire that I will be wheeling out for clients from now on.
Been so sick recently that I’ve just been making easy things with lots of veggies.
Most organisations operate on deductive reasoning. They know what they have, they know how those things are arranged, and they know what outcome that produces.
The building blocks are things, arrangements and outcomes.
Most “design thinking” operates on abductive reasoning. Compared to deductive reasoning, the equation is reversed. There’s a desired outcome, we know something about the arrangement of the situation, and we’re trying to come up with the things that, when suitably arranged, produce the desired outcome.
It turns out that coming up with new things is hard and surprisingly expensive.
But there’s another way to think about things. Inductive reasoning, uses the same building blocks, but it’s the arrangement that we create, not the things. That is, we know the outcome, we know the things we can use, but we have to come out with a way to make use of them to achieve (or explain) the outcome.
I’m increasingly convinced that most of the time, most organisations need inductive problem solving, not “design thinking”.
Code over Requirements
On Brian Marick’s Oddly Influenced, he was talking about the historical antecedents of the Agile Manifesto. He explains that agile emerged at a time of tension in software development. There was a pushback against the distinction between creating software requirements and doing software development. Marick tells the story that before agile, the work of creating the documents that directed software development was seen as higher status than writing the code. Agile is a rejection of that, and an elevation of code over requirements.
For Agile, code is seen as real and requirements are speculation or a model. (This is maybe why programmers call themselves engineers: engineers make things that are real.)
Here’s the problem: code is a model, too.
Dorian Taylor, on agile and “requirements gathering”:
The problem is that a “requirements gathering phase” has a persistent downward pressure because everybody wants to “get building”. As such they are very rarely adequately resourced, because if they were, they would literally be the job, as the requirements don’t stop accruing just because the requirements phase does.
But what if we’re discovering new ways of creating software?
The Agile people assert that this is what iterating is for, and they’re right some of the time, but many of the questions about what the software should or should not do can be settled without writing even a single line of code
All fandoms are about the same thing
Kennedy is also a perfect example of what I believe was one of the biggest mistakes of the 2010s, which was to treat conspiracy theories as political movements and conspiracy theorists as those movements’ leaders. These communities, obviously, have political dimensions to them, but I think they are, first and foremost, fandoms. And are all fandoms about the same thing: the news.
Learn and Play
The only way to learn is by playing
the only way to win is by learning
and the only way to begin is by beginning
– Sam Reich’s introduction to every Game Changer show.
I'm @firstname.lastname@example.org on Mastodon