Curated Content July 2024
July was much heavier than many other months, because I finally got back into reading everything and mowing through my backlog.
I had a decent number of articles, and for the first time in a few months, a book I can recommend, though both the book and a few of the articles aren't directly tech related, I found them really interesting, and I believe you'll feel the same.
Articles
A Brief Rant on the Future of Interaction Design
A tool converts what we can do into what we want to do. A great tool is designed to fit both sides.
Starting with some great points on designing tools, this one then gets into how our hands are one of our critical interaction points, so why are all of our visions of the future centered on what the author calls pictures under glass, that is poor facsimiles of things we'd normally interact with tactilely.
Stop Talking to Each Other and Start Buying Things: Three Decades of Survival in the Desert of Social Media
A great rant on the continous cycles of social media platforms wrecking the ability of users to maintain connection and relationships on them, because of the need to continually make more and more money. (I acknowledge that things need to make money in our current economic system, see the more and more.)
Until this blog I've always been more of a lurker than a contributor to social media, but this one resonated with me, and looks like many of the experiences that I've seen among those more active on social media than I am.
The Awkward Transitions of Disneyland!
Not tech related at all, but I really enjoy Disneyland, and this in depth look at what defines it's charm was very fun.
And I always enjoy a good in depth nerding out on a topic by someone who really cares about it.
Working With Discovery Trees
A great article, but captures the spirit of agile with a single sentence:
Frequent 2–10 minute discussions can save hours of upfront meetings, and days worth of time spent working on things you don’t need.
But also gives an interesting tool I'm likely going to end up experimenting with in order to show progress on projects:
I've Been Thinking About Tradeoffs All Wrong
Hillel is back with another great article. They consistently write great stuff, and regretfully I've never given them a proper thanks.
The framing presented here about tradeoffs:
It's not about what's better, it's about what's less worse.
...
See, normally I think of tradeoffs as framing two positive things, like saying "SQS has better control while SNS is easier to add new services". Instead the speaker framed it as two wholly negative things, and the tradeoff is which negative thing you want less of. We can do this with any tradeoff, because any positive quality about X can be turned into a negative quality of Y. Instead of "X is faster, Y uses less space", we can say "X uses more space, Y is slower."
While I don't know that this is always the right framing, because in some cases you do genuinely get a free lunch, but on the whole I think it's a very useful reframe to bring in when thinking about tradeoffs as you build.
Day 9: Distilling how to use Participatory Live Coding in-person and online - Tip 1
This is a great series on teaching courses online and in-person, but if you only take a single tip away, this one was worth it for me:
Use a program that shows your screen presses, like Screenkey. If you forget to say the shortcut you use aloud, the soft will show this on the screen for your students.
Don't be results-oriented
This to me doesn't mean don't care about the outcomes.
On the contrary, in order to actually meaningfully care about the outcomes you have to care about the process that gets you to them. (This deserves it's own blog post.)
Will Guidara: Restaurant Smart vs Corporate Smart
This one nails down something I hadn't quite been able to articulate previously, which the friction experienced between those who are building and "MBAs/Finance Types/Bean Counters".
I don't think that friction is wrong. In a lot of cases those who have never even seen the work done, much less done it themselves, aren't going to be able to make the all the right calls.
But on the other hand those who are exclusively in the trenches can often miss some of the big picture about what is and isn't necessary to grow.
This article names that friction beautifully, and suggests at least one possible response. I don't know if it's the right one, but it's certainly better than nothing.
Books
Not the End of the World - Hannah Ritchie
Not the End of the World: How We Can Be the First Generation to Build a Sustainable Planet is a book about hope, first and foremost. Hannah Ritchie takes us through a tour of the problems introduced by climate change, and doesn't shy away from them, but also gives readers some hope about the fact that while things likely aren't going to be great, they don't have to be apocalyptic.
In fact, we might even have some reasons to believe they might not be, if we act collectively, and are a bit lucky. She puts these arguments together based on looking at much of the available data. And while there are some holes that can be poked in her arguments, such as her belief in the viability of carbon credits being anything more meaningful than a shell game for polluters (possible, but not strongly probable given what I've seen) overall the book was a compelling dose of hope that I felt I could use.
Conf Talks
No conf talks this month.
Podcasts
No podcasts this month.
Microposts
My only comment on this one is I can relate to Justin here, and don't know how many times life is going to have to teach me this lesson before it actually sticks.
This single change about having a domain expert embedded in the team, and constantly available to answer questions authoritatively is the single most important feature of agile software development that is constantly lost by teams.
You introduce so much drag to your process, by forcing teams to either schedule a meeting, make things up, or wait, because you're unwilling to either under-utilize a single domain expert, or to allow them to be interrupted.
One I have thought about quite a bit since reading this.
Read into it whatever you feel is appropriate.
A great thread on different ways to improve productivity in software engineering, but also in many kinds of knowledge work.
A painfully accurate comic about my single least favorite thing about building software products.
The key bit here in this one is this to me:
Turns out, social atomization yields the same self-defeat as individual optimization did for factory machines. The Queuing Theory fact that, as utilization approaches 100%, latency approaches infinite, applies to humans and our emails, just as to machines.