Mike Perham: Grouping Events for Later Processing:
But we see enough traffic that we don’t want to turn every single click into a background job. We want to aggregate the clicks and process them regularly. There’s several ways to do this; I’m going to show you how to implement it using a cron job running every minute.
Redis and some creativity scales really well. In other words: you may not need microservices, part 34.
Christof Damian, My thoughts on meetings:
I used to really hate meetings. As a developer they seem to just get into the way of doing real work…But at some point you specialise, teams grow and you need some way to sync up.
I’ve learned in the work-at-home times that it’s definitely possible to have too few meetings. After passing that threshold, the cart to play is creating better meetings. Lots of good ideas and guidelines in this article.
Annabel Scheme and the Adventure of the New Golden Gate - a short story by Robin Sloan. Fantastic world building for a short story. Highly recommended.
Nostalgia and the “this city used to be cooler” sentiment comes up (and is rejected). Funny that the sentiment in the story is about San Francisco, where many Austinites came from and was allegedly cooler when it had fewer former-San Franciscans.
Maybe cities are like Saturday Night Live: there are very few real stinkers, just casts or episodes or locales for which one isn’t nostalgic.
How Product Hunt does asynchronous work: everyone in their own swimlane, unblocked. I really dig how they haven’t siloed work between front-end/back-end developers.
Collaborative Single Player Mode:
A developer should be able to execute a feature from start to finish – from the database to the backend, API, frontend, and CSS. The goal is never to get blocked.
- If you are missing a design, mock the UI, designers can fill this in later
- If you don’t know how to do something technically, hack it or fake it
- If a product decision is missing, try to make this decision yourself - it’s better to ask for forgiveness rather than permission
Sounds like they use feature flags so they can move quickly and decisively, but safely. And of course, plenty of testing and code review automation.
My new boss had written up a 90-day plan for me the week before I started. This was perfect timing. I was already starting to put a bow on my current work and my focus was wandering. Now my brain could start working on ideas for the next gig. Plus, I had a much better idea of what I’d start working on and how to make an impact than I did coming out of my interviews. It was one of the better emails I’ve ever received.
It seems totally obvious that hiring managers should have a plan for new hires. Yet, in more than a decade of work and several jobs, I’d never had a 90-day plan for a new position. In the parlance of our times, a 90-day plan for new team members is one weird trick that is pretty dang easy to pull off.
For all my hires since then, I’ve written up a 90-day plan. I’m convinced that this is one of the best things a hiring manager can do to bring new people onto their team. And it’s relatively easy!
A 90-day plan for onboarding starts off with very specific tasks for the first day and week. Do the paperwork, meet the people, get your digital and/or physical workspace set up. Learn about the team’s process, the rhythm of building and delivering. Meet with a team buddy who will introduce you to folks on the team and explain all the quirks and features of how the team works.
The first 3-4 weeks of a 90-day plan, for hands-on engineers, is about working with a buddy to spin up the flywheel. The goal is to come up to speed on learning the systems and contributing to them. Get the system running on your laptop or development sandbox so you can make quick iterations and one-off experiments. Land your first code change, your first review, and your first change to production.
(My angle here is for folks building SaaS web applications, but it’s the same for any kind of developer: get a few early wins and build from there.)
The second 30 days are when new team members start to come into their own. This is when I want to help my new teammates plant the seeds to realize the potential I saw when they interviewed. Important projects start spinning up. Strategy comes into play. Now is when I re-emphasize to them the potential I saw and brainstorm how to put that special skill, innate talent, or superpower to work improving our team or outcomes.
The final 30 days should start showing evidence that my new teammate is creating good outcomes. The seed of what makes them special (and what compelled me to hire them) is planted and starting to take root. I should be able to talk to teammates and co-workers and hear about how this new person is making an impact on our work and the company’s trajectory.
After 90 days, my new teammate should feel like a productive part of the team. At every point in those first 90 days, they should see little hints that they belong with this group of individuals making a thing together. After 90 days, they should feel confident that they do in fact belong with these folks and made a great choice when they accepted our offer.
Writing a 90-day plan for new hires forces you to think through how to get them started. You won’t just throw them in the pool and say “good luck!” And, it tells your new hire that you’re a smart person who is invested in their success. Every leader should do this.
I like that Ember's tagline is about ambition.
It's easy to write an empty, temporary tagline. "Simple and good". "Only 4 kilobytes." It's harder to write a tagline that generates principles which stand the test of time. "Simple and fast" are in opposition. "Only 4 kilobytes" is unlikely to last if the software evolves.
"Ambitious" as a tagline speaks to a number of qualities, but none of them are in conflict. An ambitious project could choose the boring tactics in favor of rapid delivery. Another ambitious project could aim for longevity. Yet another ambitious project might aim to have a large impact in the world or aim to do something previously considered implausible.
For a framework the size of Ember, that's an appropriate diversity of goals. But they're all covered by ambition. The tagline unifies and clarifies as much as it inspires.
The entire time I’ve been using FactoryBot, several years at this point, I’ve used it one factory at a time:
company = create(:company, name: "Acme, Inc.")
alice = create(:user, name: "Alice Smith")
posts = create_list(:post, 3, user: alice)
Do you see the mistake I make all the dang time? Spoiler alert, I forgot the company relation on Alice’s user, so she is either orphaned (unfortunate) or created on an entirely unrelated company. That’s gonna make my test fail in weird ways!
Lately, I’ve been trying something different: create the whole object graph I want to test on in one fell swoop:
company = create(
:company,
name: "Acme, Inc",
user: build(
:user,
name: "Alice Smith",
posts: build_list(:post, 3)
)
)
The entire intent of the test scenario is made clear right here. And, the error I so often make is solved structurally rather than by vigilance.
Granted, that’s pretty chunky and way more lines. I feel like it’s a worthy tradeoff!
When I need to reference the models created by my jumbo object graph, I use RSpec let
and ActiveRecord finders with a mind towards consistently finding the right thing:
let(:company) do
create(...) # the whole company bit from above
end
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }
“Perfect is the enemy of shipped” - Simon Willison
15 rules for blogging - Matt Webb
Lists, emoji, and consistency are totally working for Duncan Davidson
Austin Kleon’s list of perfect albums: #perfect31. Non-compilation albums, no songs worth skipping. Discovering these albums is one of my favorite things about listening to music. Blood Sugar Sex Magik was the first one I found myself, when I was sixteen. Blew my mind.
Matt Webb on Asimov’s Foundation, and what’s unique about science fiction:
Like any scientific endeavour it starts as a phenomenological exercise: what’s happening? How does this thing behave in various circumstances? Then beginning to probe: what are its limits? How do we break the premise? And finally consequences… what does it mean for this phenomenon to be wielded deliberately; what are the second order effects when others can see the effects …and so on. Dynamical systems are all the same; the reader can readily draw parallels and discover new truths.
Writing is thinking. Sci-fi, at its best, is thinking about an idea taken to its end. Most sci-fi is a miss, but every once in a while it describes upcoming realities with absolute clarity, e.g. Neuromancer.
Let me tell you about my theories on art and fishing.
This Ernest Hemingway story is definitely about fishing.
On the other hand, I have a theory that most Billy Joel songs are either a) definitely about a fisherman or b) could exist in one world where the protagonist is a fishing professional. Kinda the same thing with Bruce Springsteen song; the whole canon is one working-class world.
Here’s a real dinger of a sentence from Michael Lopp’s latest, The Art of Leadership: Small Things, Done Well:
Failure is created by the increasing entropy of a growing number of humans running around the building, good intentions in hand, breaking things.
Growing an organization requires rethinking trust, coordination, and collaboration. The breakpoints where things go from working pretty well to an absolute shamble come faster than we think. They don’t even occur at nice, round numbers like base–2 or base–10 orders of magnitude.
Figuring out how this works for teams, companies, social networks, and whole countries feels like one of the big unsolved problems of the knowledge/attention-era.
Two iOS wishlist items:
The best way to achieve these outcomes now is to delete the app from your device and only dip into the web interface when you absolutely must. That’s contrary to Apple’s goals. It’s not bad for the web platform, though🤔.
In short: nerf the engagement loops at the operating system level.
Determined Disney fan recreates the original Disneyland version of the Alice In Wonderland ride-through in 3D. Same, but for Mr. Toad, one of my top 3 Disneyland favorites.
Writing clarifies thinking. Therefore, writing design docs clarifies one’s thinking about code. Design Docs at Google and an example/meta design doc from the same author are great places to start!
I found that writing prose until I run out of clarity and then switching to proof-of-concept code is even better. The constraint of making an ambitious design work with a minimal change-set is a nice way to work for a day or so.
Lots of features or fixes don’t require in-depth thinking to get started. But when they do, sorting out the ideas and tradeoffs in writing helps a lot.
Write until I run out of ideas, flesh those ideas out, write about the nuances I found. It’s a nice feedback loop!
A Better Approach to 360° Feedback: Bradford Fults shares ways to route around fallible human memory and gather useful information when it comes to review season.
Humans also have a recency bias and suffer from long-term memory distortions that change to fit their current opinions of other people. This means that “observations” from months ago often aren’t so much observations as they are current opinions and emotions repackaged as fixed stories about the past. Most people don’t even intend to distort the truth like this: it’s just the way the human brain works.
Instead, ask questions in the context of how the reviewer works with the reviewed, particularly in the last 90 days or so. Paraphrasing Janet Jackson: “What Have You Done For Me Lately?”
In my too-frequent skimming of German sports cars for sale near me, I came across a BMW 135i with a black exterior and interior. It’s a tempting car, but I’m afraid it says “I listen to two kinds of music: Kraftwerk on cassette and Kraftwerk on vinyl”.👴
1992 Lancia Delta Integrale Martini 5 Evoluzione, Bring a Trailer fodder for the day. I can’t resist Martini Stripes. Or bright yellow, extremely 80s instruments.
Watched Jim Gaffigan’s The Pale Tourist. I’m surprised one can dedicate an hour-long set to Canada alone, but he makes it work. Gaffigan’s not the edgiest comedian or most insightful orator, but he is delightful. And delightful is mostly what I want out of entertainment right now! Recommended.
Unlocking value with durable teams, Anna Shipman:
If you build teams around projects, this means that there is a ramp-up period while the team go through the early stages, and if the team is not together for long enough, it’s possible they won’t spend very long (if any time at all) in the performing stage. This happens if new initiatives come in and the team is disbanded to form other, new teams.
It takes a lot of effort to form a team; you need to find the right balance of skills, someone to tech lead, delivery manage and be the product owner; you need to find engineers, customer researchers, product designers and possibly business analysts and you need to make sure that the work they are currently doing can be finished or stopped.
Specialization and matrix’d teams seem inevitable as an organization grows. I suspect that a cross-functional, self-sufficient team that has time together and knows how to work together will almost always outperform teams of specialists spread across multiple projects and priorities.
h/t Simon Willison
I’d never seriously listened to Mazzy Star before today. Had really only heard “Fade Into You”. Now I’ve listened to all four albums and they’re a) pretty good! and b) kinda ahead of their time?
I’m a little surprised that something so straight-forward and sounding very much of the nineties can predate music I associate more with the “indie sounds” of the 2000s and 2010s. Maybe I’ve just got my history wrong!
Marketing folks should dispense with “this is familiar-thing two point oh”. It’s always “Underpants 2.0” or “Butter Knife 3.0” and never “Non-stick pan 2.3”. Just call it like a straight-up Hollywood sequel. “Chair 4: The Sittening” or “Ball-point Pen 7 Part 1: The Penultimate”. 🥁👴
Bunkerpunk, short sci-fi from sudowriters, “a speculative fiction writing group”. My first foray into collected short science fiction. Recommended for modern, addled attention spans, those who are intentionally avoiding mega-tomes/epic fiction worlds, and/or the biographies of Robert Caro.
I would never have guessed that “video memos” would become a thing in remote working. Rather than sending a wall of text (which people are unlikely to read or even expand in Slack), record a short (~5 minute) video summarizing the ideas in context with metrics, screenshots, etc.
The jury’s still out on how this compares to a written memo culture. But, a marginal benefit of a video memo is you can watch it at greater than 1x speed and feel like you’re getting more out of your time! 💪
Awesome Cold Showers - “ It’s great when people get excited about things, but sometimes they get a little too excited.” A collection of papers for when you don’t believe the hype and need to help others think that way too.
By some kind of coincidence I’ve read The Difference Engine by Gibson & Sterling followed by Quicksilver by Stephenson (re-read) and both are set partially in a London where covering once’s face for safety is prevalent. History repeats itself, historic/science fiction doubly so.
Alex Danco: The Freud Moment - You could draw a line from all of America’s divisiveness and much of the culture wars down to ego vs. superego.
America’s egotistical bent doesn’t mean we lack a conscience: we carry around a ton of guilt, as part of the cost of letting egos run wild the way we do. The narrative of “the coastal elites want to tell you what to feel guilty about; we won’t let them” is effective for a reason: because we are collectively guilty of so many things, from climate change to police brutality and everything else. The Trump candidacy figured out how to exploit this better than anyone else: in a complex and interdependent world, everyone is basically guilty of everything. And when that’s true, no one can say “you should feel guilt” without sounding hypocritical. It’s a perfect judo move, because not only does it neutralize the superego’s ability to effectively level any criticism, it opens the door for the ego to go be as offensive as possible.
The Garden Of Forking Memes: How Digital Media Distorts Our Sense Of Time - grab a beverage, this one made me think of time in a whole other way and reframed our narrative-heavy, fact-light information situation:
The de-centralization of timekeeping brought about by digital media harkens back to a much older style of measuring time. Before the invention of the telegraph, there was no way to instantaneously synchronize timekeeping devices across long distances. No time zones, no universal standard against which clock towers could be evaluated for accuracy. Timekeeping was more an art than a science. Each village emitted its own time zone. Much like the townships of old, every internet community has its own “subjective time zone”.
The disruption of the old timekeeping regime created a void that’s being filled by new online communities, cliques, and cults. Whereas the industrial schedule provided a sense of structure and stability and continuity, D.I.Y. timekeeping often feels aimless and disorienting and uncertain. People are seeking out groups and ideologies that put them “back in time”, and many internet subcultures do exactly that.
Tom Armitage » Props and Prototypes - props for movies are like prototypes for building technology. A hero’s lightsaber exists as different props for stunts, close-up shots, costuming, plus a digital version for CG shots. Clickable mockups, short video demos, and working code all serve different phases of a project. See also: tools for thinking.
We had a real dinger of a sunset last night
I finished the last season of The Clone Wars over the weekend. Recommended for all Star Wars fans. Hot take: the last four episode arc is a better Star War than Rise of Skywalker.
Oddisee’s new EP Odd Cure has skits, but they’re recorded phone calls keeping up with his family and friends. Kind of a perfect version of the interstitial skit for this moment in history.
Untools is a collection of mental models for thinking about problems, projects, and ideas. For example, the latest tool, the Cynefin framework is useful for assessing the kind of problem you face (complex, complicated, chaotic, or obvious) to determine what kind of strategy is appropriate for tackling it. Makes for a handy afternoon research dive.
There’s something interesting about Untools as website. Under the hood, there’s not much to it; you could implement it with a static site generator. By that measure, I might describe this as a “brochure” site. But the attention to design and organization makes it feel much more like a product. Delightfully, one that doesn’t seek a commercial transaction. More like flipping someone’s personal but well-organized notes on conceptual tools. Feels novel, in an obvious way.
Albums with acceptable skits between tracks:
That’s it, as far as I know. It’s exceedingly difficult to pull off skit tracks.
p.s. there may be an Outkast or Goodie Mob album with nearly acceptable skits?
How I Got My Attention Back - doing a residency and totally disconnecting is implausible for most people. But the idea is great and Craig Mod spins a great story every time I read him.
Writing Better, Type-safe Code with Sorbet. Hot take: gradual typing of large Rails codebases is going to make developers more productive than microservices, radical decoupling, and splitting out SPAs has. Combined.
How “Starship Troopers” Aligns with Our Moment of American Defeat
For most of “Starship Troopers,” humanity, in every possible facet, gets its ass kicked. A culture that reveres and communicates exclusively through violence—a culture very much like one that responds to peaceful protests with indiscriminate police brutality, or whose pandemic strategy is to “dominate” an unreasoning virus—keeps running up against its own self-imposed limitations.
Well that hits home.
Terrace Martin in heavy rotation this week: 808s and Sax Breaks and Dinner Party 👍👍 Robert Glasper, 9th Wonder, and Kamasi Washington mean you can’t lose!
Tips from HBO’s Watchmen on building an inclusive workplace:
The most valuable thing a showrunner—or any manager—can do to create an inclusive workplace is to listen carefully and respectfully to what their employees have to say, while checking their own defensiveness.
The overlap between showrunning and managing a team creating software continue to intrigue.
Periodic reminder that we are worse off for letting folks run Kathy Sierra off the social parts of the internet.
Peak Texas weather. The moment I step outside, I’m thoroughly warmed by the sun. A pleasant glow. For 5 seconds. Then it’s time to plan how I’m getting back to climate control. Rinse and repeat until mid-September.
I probably write this every summer because every summer I love it.
The pandemic that has dominated the past three months strikes a useful contrast with what’s happening now. Unlike coronavirus, racism and police violence are problems caused by humans. There’s a saying, “You aren’t stuck in traffic, you are traffic.” Similarly, the unrest occurring right now isn’t something that is happening to anyone, but a phenomenon that everyone is a part of, even if they haven’t left home or directly participated at all. Like traffic, the reason you’re surrounded by protests is partially because of you, regardless of your perceived level of involvement.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Corollary: It always takes more repetitions to tell people what you're doing, how you're going to do it, why you're doing it, how much progress you've made, that you finished doing it, etc. even when you take into account the corollary to Hofstadter's Law.
The JavaScript ecosystem’s gone to a strange place where dense frameworks and complex tooling are the status quo. But, there are data-points suggesting the pendulum could swing back sooner than later:
Caveat: I haven't tried any of these. But, the trend-line is promising. JavaScript the language, while not perfect, is Pretty Good now. Perhaps the next few years will see the great ideas of the frameworks squeezed into more accessible, less sprawling expressions of those ideas.
A tale of Ghosts’n Goblins’n Crocodiles
There is something noble about developing on a dead platform – it is so completely for the joy of the development, without any commercial motivation.
- John Carmack
When does a platform truly “dies”? A “dead language” is defined as “a language which is no longer in everyday spoken use”. By analogy, a dead platform would die not when it ceases to be profitable or when it is obsolete, but when people stop playing it and caring about it.
Now the question becomes “what draws people to retro-computing?”. Is it nostalgia, the diversity, the creativity, the simplicity, or is it inexplicably fun?
Come for the sentiment, stay for the backstory of an old computer you may have never even known existed.
The gestalt of what's new in software and how it's changing our world has evolved over the decades.
In the ‘90s, it was “don’t make me think!”. User interfaces went from text-based systems that required memorization and expertise to graphical systems that afforded more casual use of computers. Unix users and their terminals are a notable holdout to this day.
In the ‘00s, it was “don’t make me remember!”. The internet let us to stop worrying about access to common knowledge. Search engines, news feeds, e-commerce, and listing sites made it pretty easy to answer many questions without a resident expert. Nascent social platforms made it possible for our “friends” to feed this information back to us. Notable holdouts: it was impossible for me to search for punchlines from SNL skits, and largely still is.
In the ‘10s, it was “don’t make me describe the content I want to see!”. The now-giant tech companies figured out that their products were more “engaging” if they pushed content to people instead of people clicking around and typing queries to describe what they want. Thus was born machine learning, recommendation systems, and infinite/algorithmic feed scrolling. Notable holdout: none, the blast radius of ad-tech is wide and far-reaching.
From this particular moment, it seems like the ‘20s are going to be “don’t make me leave my enclave”. Even if there’s a breakthrough in medicine and this pandemic is a temporary blip, the writing seems like it’s on the wall. Many kinds of service and retail commerce we used to go out into the world to interact with, along with offices, are going to fade away as climate changes and viruses come and go. Notable holdout: the not-so-middle class folks who do the machine's bidding and keep the wheels of commerce rolling.
Over three decades, things are at once noticeably better and yet there's vast room for improvement. If you're wondering where impactful work can be done in technology, it's in making the benefits of the technology we're building for the middle/upper classes today available to the less fortunate tomorrow. If we can make fantastic televisions available to everyone, surely we can improve the outcomes that matter most in everyone's lives.
If we could bend this curve, the '20s could be the decade of "no pithy quote, just people helping their neighbors."
Yin and Yang: Lessons of Creativity — David Perell
Flow states are the holy grail of productivity. To achieve flow, we need a proper skill-challenge ratio. Skill: Yin (Order) Challenge: Yang (Chaos) We do best when we’re pursuing goals that are a little bit tougher than what we can easily accomplish.
A little bit of disorder makes many things better!
Dear Apple Music algorithms,
The center item is not at all like the others.
H.264 is Magic. There’s so much amazing stuff you can do with math in the pursuit of distinctly non-math-y endeavors. I’ve always thought compilers, and their cousins the query optimizer, are magic. Computer graphics too. Turns out video compression is also uniquely amazing.
Bonus quote from Revenge of the Intuitive:
Years ago I realized that the recording studio was becoming a musical instrument. I even lectured about it, proclaiming that “by turning sound into malleable material, studios invite you to construct new worlds of sounds as painters construct worlds of form and color.” I was thrilled at how people were using studios to make music that otherwise simply could not exist. Studios opened up possibilities. But now I’m struck by the insidious, computer-driven tendency to take things out of the domain of muscular activity and put them into the domain of mental activity.
I am, in general, a sucker for the notion of the studio as a kind of musical instrument unto itself. It’s a very maximalist, Romantic-era symphony sort of thinking. I want to be Pet Sounds-era Brian Wilson or Rite of Spring-era Stravinksy when I grow up.
The Revenge of the Intuitive - Brian Eno lamented the downsides of a modern, computer-based recording console. Twenty years ago! The trade-offs for “freedom” at the expense of human affordances were too much for Eno at the time.
Feels like we’re in a similar spot with developer tooling. It works for the most accomplished and persistent of us. For many people who would like to build software, it’s too much. It’s too easy for our castles of complexity to thwart the novices.
The trouble begins with a design philosophy that equates “more options” with “greater freedom.” Designers struggle endlessly with a problem that is almost nonexistent for users: “How do we pack the maximum number of options into the minimum space and price?” In my experience, the instruments and tools that endure (because they are loved by their users) have limited options
You could just as easily write this today about software development libraries and tools. Too many of them discard pretty good ideas about how to build applications. Too much fascination with meta-tooling. Not enough thought put into how to put applications in people’s hands.
With tools, we crave intimacy. This appetite for emotional resonance explains why users - when given a choice - prefer deep rapport over endless options. You can’t have a relationship with a device whose limits are unknown to you, because without limits it keeps becoming something else.
We need standalone tools and libraries to build upon. However, well-curated, opinionated developers tools are where the magic happens. Frameworks like Rails, Tailwind, Next.js are where the leverage is.
A determined expert can build an application from building blocks. Novices can at least get started with a well-crafted framework. A good community and forgiving documentation can get them through the valleys of confusion to the peaks of accomplishment.
Perhaps low/no-code tools will bring the benefit of the “golden, narrow path” to more people. Maybe the trade-winds of developer tooling will blow away from showmanship back to accessibility. Either way, we should tidy up our house and make software development more welcoming to those who aren’t already monks in the monastery.
We should use the pandemic to reevaluate how we value service, child care, and education labor. It’s apparent we undervalued them. Their value is now explicit for those clamoring for a return to paying people to handle their chores and obligations. So let’s pay them more when we emerge from this!
The burden of navigating urban sprawl to reach our offices, shops, and entertainment is now explicit. Density won’t be the answer for this is in the short or medium term. Perhaps we could value the ease by which we can drive around right now and work backwards from there.
The bit that has worried me is how density is no longer a virtue. Public transport and dense neighborhoods won’t be desirable for a while. What’s the alternative that reduces our environmental toll and increases the cohesion of our neighborhoods?
“Building quality things of substance takes time.” - Rands in Repose, One Thing
Why NetNewsWire Is Fast - I love it when Brent Simmons writes about system design and principles.
I rented a 12-year old Porsche Boxster via Turo this weekend. Good app, great car. I’m shopping older German convertibles for my next car. Paying a little to rent a prospective car for a day is way better than driving one for less than an hour. Plus, no sales tactics!
The center of the Boxster experience, it turns out, is the tachometer and the engine. The tachometer is dead-center, set in distinctly-Porsche numerals with a digital speedometer in the bottom. You don’t want any other gauges. It’s nice to know when you’re about to run out of fuel, I suppose.
The flat-six cylinder engine sits right behind your shoulders. It is, according to my wife, loud. I found it sonorous. I don’t have a picture of it because you literally can’t see it without taking the car apart. And, a picture of a dirty machine with 130,000 miles isn’t right. The engine on a Porsche is meant, and designed, to be heard.
Once I was between that tachometer and engine, I knew I was definitely in a Porsche Bubble. The switches, seats, even entertainment system didn’t matter much. It helped that it was a lovely day and the air conditioner was up to the challenge. But it’s all auxiliary to the sights and sounds.
Turns out, that’s sort of all you need. A strong design center and two senses stimulated can make a product that stands the test of a decade or three.
Margin is a plain text notation for thinking in lists, notes, and structured data. I have a soft spot for notations for thinking like, e.g. Markdown, TaskPaper, even bullet journaling.
The mark of a nicely designed plain text format is that it works equally well in a well-crafted app, a text editor, and on a sheet of paper. Margin meets that criteria.
The Bremont Argonaut - there’s a lot of “ink” on this watch face, but it doesn’t seem busy. Even more, the marks on the crowns are the real winners.
![https://hodinkee.imgix.net/uploads/images/1586281720176-9qegaqjnjs7-0243d3e3c71e5244dc4c03c63b5282cd/L1180502.jpg?ixlib=rails-1.1.0&fm=jpg&q=55&auto=format&usm=12&ch=Width%2CDPR%2CSave-Data&fit=crop&w=820](Bremont Argonaut crowns)
The second best sunset of the week (Monday)
Features in software are answers to questions. How can customers send what they're looking at to someone else? That's share via email. How can customers distill all the data about my project's tasks down to raw data to analyze it? That's a report, probably with a CSV export.
All of these answers exist on some kind of spectrum. There are simplistic and sophisticated answers. Maybe reporting has no interaction affordances at all; it's an HTML table and a link to download it as a CSV. Perhaps reporting is full of interactions, using metaphors of spreadsheets like sorting or filtering.
It hurts to waste time and effort. We get attached to the things we work on. But that’s the Sunk Cost Fallacy talking. If you don’t think a feature is worth the time it takes to make it great, then it is not rational to ship a crappier version simply because you have sunk time into it.
Julie Zhou, How to Make Things High-Quality
Early in the development of a feature is the time to seriously consider whether to ship the simplistic or sophisticated version of the feature. Before Sunk Cost starts to weigh on our souls. The first few days of building the feature are often about figuring out how much sophistication we can afford to build given the amount of time we have to ship the feature.
It is tempting to stop when it works, but it is only the beginning. That’s the shitty first draft you’d never turn in. Now you must go through the process to make it as simple as possible for others to understand.
Simon Hørup Eskildsen, Shitty First Software Drafts
In a sense, we’re matching a time budget to a mental complexity budget. In one week, we could figure out how to do a very simplistic CSV export. We could get it to work, make the implementation clear, test it out, iterate on code review, and have it ready to ship. In four weeks, we could add all the features that make a crisp and clear customer feature: generating it in the background, emailing a link to download the CSV after its generated, showing progress of the export to a user, etc.
With the teams I work with, we operate with the idea of peak complexity: the time at which a project reaches its highest complexity. Peak complexity has proved a useful mental model to us for reasoning about complexity. It helps inform decisions about when to step back and refactor, how many people should be working on the project at a given point in time, and how we should structure the project.
Simon Hørup Eskildsen, Peak Complexity
Somewhere in the middle of the time allotted to the project, a feature might start to feel like its getting out of hand. Inevitably, there's some surprise complexity or scope that no one anticipated. If the code of the feature were a combustion engine, it is sitting on a stand, partially disassembled, and in need of a rebuilt component.
Maybe we decide that the surprise scope isn't worth the toil and scrap part of the feature. We might decide it is essential and scrap some other part of the feature so we can finish this while affording the time and complexity budget.
Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.
Basecamp Hill Charts
We reach that Peak Complexity, decide how to get through it, and start working downhill. We're now reaping the benefits of the thought and effort we put into managing the complexity budget of the feature, given the our time budget. We're crossing t's and dotting i's, finishing detail work, and getting the project ready to ship.
I find that managing software projects as time plus complexity works far better than viewing it as tasks for people to work on until it's "done".
You could also think about the Apple Watch as the main input device. In contrast to the AirPods, Apple opened the Watch for developers from the start, but it hasn’t really seen much success as a platform. Perhaps a combination of Watch and AirPods has a better chance of creating an ecosystem with its own unique applications?
Bingo.
In the sense that trees of people (managers and reports, ala Taylorism) are the old guard. Data (folders and files) are old sauce and nodes + edges are new sauce.
In the sense that part of the confusion of our modern world is that e.g. the Koch brothers have considerable influence on how the Republican party organizes itself. Thus, money is the speech that organizes our current regime and acts on policy. But the Koch brothers aren’t on the org chart for the government or the Republican party.
In the sense that hierarchical databases are such old sauce that I’ve never used one. People new to software development don’t even realize they were at one time a thing that competed against the idea of relational databases.
In the sense that writing is linear or organized by chapters in books. But, the web is a wild mess of hyperlinked graphs. Maybe writers want to organize by graphs too!
(Spoiler: you can represent strictly hierarchical data with graphs too!)
Knowing what books someone loves is to know their perspective and their journey, to have something special in common, to share a language.
The CWC Mellor-72 - I love the overall shape, but especially the arrow icon above the 6.
My law of music: there is no song that Aretha Franklin could not perform slower and therefore better than everyone else.
Newly discovered corollary: except possibly Pierre Boulez and Beethoven’s 5th. So slow, nearly belabored. Love it!
Drew Austin on high/low-brow music, how it fits into album reviews and club culture, and how all that has shifted in our current state of distance. Energy Flash:
“For Reynolds, “at home and at album length” refers to a process of decontextualization, the musical equivalent of the modern gallery’s white cube: a belief that any cultural product meriting serious appreciation must prove that it can survive outside of its native habitat by becoming a fungible unit of culture, fitting into the standardized format of Pitchfork album reviews and solitary, focused listening. If music sounds good in a packed nightclub at 3 a.m. but not through headphones on your couch, is it real in the same way that Kid A is real? Right now in quarantine, the contextualizing environments in which culture traditionally incubates are closed off and dormant, so everything has to sound good in the living room whether it’s meant to or not. We live in the white cube now; anything that relies on a specific source of external context is an endangered species. We’re one month into a worldwide experiment to learn whether the internet alone can produce sufficient meaning on its own, or whether we must keep mining our memories of an embodied shared reality to bridge this gap.”
A new cannonball run record set - a surprise and unintentended consequence of pandemic and shutting down the economy. It’s now much easier to drive a car really fast from New York to Los Angeles. The new record is just a few hours over a day.
The Majestic Monolith can become The Citadel - when a function of the monolith becomes unwieldy, split off an Outpost to service that need specifically. I like to call them sidecars, because that seems more fun!
Introducing Watchsmith - I love the idea of using customizable, bespoke complications to get a foot in the door of customizable Apple Watch faces. I’m trying it right now, so far so good!
I’m no good at photography, but Texas sunsets make it easy.
I’ve been tinkering this weekend and MVP.css may be one of my new favorite tools. Drop in some CSS and then just use HTML elements as their name would suggest. No layout, no grids, no typographical system. No classes to memorize. Build now, worry about all the other stuff later.
This weekend, I’m revisiting some of David Perell’s writing on writing, thinking, and aiming high. My favorites: Why You Should Write, Learn Like an Athlete, Networked Writing.
A lot of us are out here, amongst all the strangeness of the world, trying to figure out how to help our teams adjust to collaborating remotely. It’s long been my observation that nothing beats people in a room together communicating via ad-hoc scribbles on a whiteboard.
Seems like a good time to survey the landscape and see if the situation has improved!
On one end of the spectrum are Google Draw and Jamboard. The former seems better for attempting to draw technical diagrams. I think it's actually better for ironically creating WordArt. The latter seems like an honest, lo-fi attempt to re-create whiteboards online and collaboratively. I don’t think these tools cut it. But, they have the advantage of ubiquity: a lot of companies use Google Suite, so these could come in handy, in a pinch.
Another wild card is to use design software your team might have in place. Sketch or Figma are inherently about visual communication. If everyone has a license and some patience, this could work! If anyone can put some boxes, arrows, and text together, you can basically whiteboard.
I’ve used Whimiscal to create non-trivial visual communications. It works great, it’s easy to share with people, there is some multi-person editing. It's easy to get started in Whimsical and it has some depth, but not so much depth that it's intimidating or overwhelming. Pricing aside, this is where I’d start with my current team.
I have not kicked the tires on Miro, but the concept is intriguing. Looks like there’s real-time, collaborative visual communication/editing. They also brag a lot about their integrations with adjacent project/collaboration tools such that one can embed JIRA cards, mockups, docs, etc. in a whiteboard. If you’re already using this, I’d love to hear your experience with it!
Finally, you don’t need software to share ad-hoc scribbles. You can draw on paper, capture it with a camera, and share that image almost anywhere. You could use sketching/drawing tools to do a fancier version of that. If you have a whiteboard at home, you can draw on it, take a photo, and share it.
It doesn’t matter if the tools aren’t that great or if your company hasn’t adopted any of them. Taking the initiative to collaborate, or having the insight that communicating with words is not cutting it, is much more important.
Remember secretaries and drinking at work? And land-line telephones? And smoking inside? Blech! And an even more unequal society with even more thumbs on the scales?
My wife and I, when we first watched Mad Men:
Oy, Makefiles! And weird preprocessor tricks! And file-scoped variables/memory ownership? And everything is an int, sometimes pretending to be a char.
Me, reading C code, having last written valid, in-anger C code during college
The 1960s and 70s had some nice qualities, but some of them don't hold up to the nostalgia.
That is a beautiful machine. I must have a soft spot for extensive air-cooling schemes. If Windows/PCs were a thing I could get with, I would get with this hardware.
Rules won’t solve your problems, but thinking about them might. To paraphrase a couple well-known quotes:
“Rules are useless, but thinking about rules is indispensable”
Dwight Eisenhower
“No rules survive first contact with a toddler”
Helmuth von Moltke the Elder
😉
It’s folly to think we can generate the exact outcomes we want with rules. Every ruleset leaves more unstated assumptions than it generates clarity. The legalese found in contracts, and its absolute obtuseness, is testament to how hard it is to write clear rules.
That said, thinking about how rules, or a lack thereof, generate outcomes is an essential and worthwhile exercise. I like putting things through the lens of macroeconomic thinking to seek out second order effects, unintended consequences, and perverse incentives that emerge from a proposed rule set. Rules are trade-offs!
In short: humans + rules are a strange, not entirely mathematical thing. Think about how bad actors will abuse rules in their favor and how good actors will be constrained by rules in search of the outcomes you actually want. Then, if you must, write as few rules as possible.
We took all the dogs on a walk today. Even the sixteen year old one who walks janky. I have never seen so many people out walking in our neighborhood. So that’s nice! Add that to the list of things we should considering preserving once we reach the new normal.
Stop the Coronavirus Corporate Coup. I’ve got a bad feeling about this.
The aerospace giant of course wants a $60 billion bailout. Financial problems for this corporation predated the crisis, with the mismanagement that led to the 737 Max as well as defense and space products that don’t work (I noted last July a bailout was coming). The corporation paid out $65 billion in stock buybacks and dividends over the last ten years, and it was drawing down credit lines before this crisis hit. It is highly politically connected; the board of the corporation includes Caroline Kennedy, Ronald Reagan’s Chief of Staff Ken Duberstein, three Fortune 100 CEOs, a former US Trade Representative, and two Admirals, one of whom is the board’s only engineer. Using the excuse of the coronavirus, Boeing is trying to get the taxpayer to foot the bill for its errors, so it can go back to making more of them.
The jazz icon Sonny Rollins knows life is a solo trip. Seems like a surprisingly wise, grounded performer.
This year, I’m trying to better keep in touch with friends, family, and former co-workers. It came to my attention that this is, in many ways, a thing for which you would use a customer-relationship management application. This could work, but seems like a lot to me.
Most software starts life as a) a document/spreadsheet or b) a system of long email threads. In that spirit, I thought I might work backwards from what I normally do: build the littlest CRM I can without writing code or using development tools.
I’ve already got Things and Bear in my workflow. Turns out that duo solves the essential part of the problem. Things reminds me to contact a friend/family/co-worker periodically. I keep notes on what folks are up to, what we talked about, when the last time we talked, etc. as unstructured notes in Bear.
That’s it! I’m only one month into this experiment, but I’ve contacted, at least once, most folks I wanted to. 📈
(…continuing a Twitter thread)
io-ts caught my attention a while back and I finally had the chance to read through it. I’m glad folks are experimenting in this area, particularly with the potential reach into multiple communities and ecosystems that TypeScript affords.
We use dry-rb extensively at work and I was curious how a TypeScript expression of the same idea (define type-like structures at your runtime boundaries) looks.
The flippant response to runtime type systems for dynamic languages is: if you love types so much, why aren’t you using Haskell, Scala, Swift, etc.? That is, a type system over JavaScript or Ruby is a relatively new/unconventional choice.
Gradual type checkers: it works for Facebook and Stripe. Maybe it scales down for much smaller teams and codebases? Weird flex, but okay.
In reality, a runtime type system is easy to adopt and, when paired with some kind of Either/Result abstraction, can be built incrementally by composing types, data coercions to types, and validations of coerced data.
Having spent a year and change working with dry-rb’s runtime types/validations, I’m looking forward to introducing Sorbet. I like the idea of writing types and function signatures for development-time enforcement, but having the option to use some of them at runtime for boundary enforcement.
dry-rb has served us well, but the development experience that I crafted is highly coupled to using a Result/monad-ish idiom. Lots of combinator-envy. Most developers don’t crave this sort of thing.
Even if it’s successfully sold, it’s an uphill battle of education and FP/OO adaptation the whole way. If I were doing it over I’d look to Go’s tedious but easy to teach idiom of checking for errors after nearly every non-trivial operation.
I think dry-rb and io-ts will succeed or fail in very similar ways. Teams that know an ML-like language but are for some reason using JS or Ruby will take quickly to it. Otherwise, there’s an impedance mismatch to manage as they teams their own idioms on top of runtime types.
I’d pitch this to front-end developers as similar to React’s PropTypes, but better.
PropTypes give you greater confidence that you’re passing the right properties to a component and that a refactoring didn’t break things. Type-asserting data structures, like io-ts, give you confidence that the boundaries of your system, e.g. the XHR request/responses and persisting data to local storage, are either well-formed or immediately kick over to failure handling.
Enforcing object shapes (keys and nesting), type correctness (the value for key X is type Y), and validity (values declared as an “age” are always positive integers) at the boundary of your application and between components means you can more code on the “happy path” in your application logic. Conditionals and error handling are largely, but not entirely, pushed outwards to prop types or the boundary type system. This is, in my opinion, living the dream!
The gift and the curse of io-ts and dry-rb’s design is the use of combinators as the center of their design.
The skill ceiling for composing functions to handle network/database requests, type/shape assertions, coercions, and validations is very high. There’s lots to learn about combinators and the more you know, the more you can do. The downside is that the skill floor is also high. The less you know about combinators, the more mysterious, intimidating, and math-y they are.
It’s an unfortunate reality that developers rarely rave about how great a library or language’s error model is. Mostly people put up with exception handling and try to live in a blissful world of error-avoidance and happy paths.
Result types - e.g. Rust’s Result, io-ts’ Either, Haskell’s monads, dry-rb’s Result and monads, Elm’s Result and Maybe - are promising. Function return types that are explicit about whether the thing succeeded or failed (without stack manipulation hijinks) is something we really should have put in practice some time ago. io-ts and dry-rb are existence proofs, to me, that you don’t need an extremely sophisticated type system to make these work in practical, runtime-typed languages like Python, Ruby, or JavaScript. But they can quickly send you down the road of combinators. I’ve found this is not a road developers are enthusiastic about traveling.
Go and Erlang take a different, utterly unsophisticated, road and I wonder if it’s more promising. Functions that can fail (any kind of IO, some kinds of math, etc.) return a success value and error value as an array or tuple. Developers are expected to always check for an error before proceeding; linters and peers will complain if you don’t.
If a linter does it, so can a compiler or gradual type system can too. Maybe the middle ground between the status quo of exceptions and the promised land of result types is compiler-enforced checking of success/error pairs. The advantage is, no invention or re-learning is needed. It’s an array and a conditional. Granted, I’d prefer to get rid of the conditional. But, I’ll take the ease of training developers on the approach as a trade-off.
In short: my new hypothesis is “run-time enforcement of types/values/rules around the boundaries of your system, gradual/static types inside your system to prevent programmer errors”. If you can go further and use a static type system like Rust or Elm to reach the point your software is “correct by design”, that seems like living the mega-dream. 🌈
Prince’s unfinished memoir, The Beautiful Ones is a quick, but awkward, read. The preface is the most coherent, the story of how the editor, Dan Piepenbring, ended up being chosen by Prince to realize his autobiography. It shines an interesting light onto what it was like to be in Prince’s orbit, if only briefly.
Of course, Prince passed away shortly after the book was announced. He had started providing material to his writer in the form of notes and guidance, but only a few chapters worth covering his youth and early career. These notes, in their idiomatic manner of writing, e.g. “👁️ love u”, form the bulk of the book. The rest of the material are photographs and other notes collected with the help of Prince’s estate. They’re insightful, but not particularly coherent.
I’m relatively new to the deep Prince mythology. I suspect I got more out of the book than those already steeped in purple mystery would. There are probably better starting points for those who want to know everything about Prince or who are enitrely new to the Prince mythos.
I just finished reading the Watchmen graphic novel and it is amazing. I was drawn in by the HBO series last year, which amplified my enjoyment of the original story. It might end up in my top five works of fiction.
The story is of its time: the Cold War, superheroes as saviors. Even better, it has timeless themes that feel relevant in our weird contemporary situation: growing authoritarianism and nihilism towards overcoming the status quo to tackle other looming problems.
I saw the Watchmen movie first, several years ago. The movie, as I remember it, holds to the first few issues surprisingly well. The ending of the comic is far superior to the one used in the movie. The comic has more space to expand minor storylines and even introduce a whole other comic within the graphic novel. The comic stands head and shoulders above the movie.
I still feel like the Watchmen HBO series was one of, if not singularly, the best shows on television/streaming last year. The graphic novel is the perfect chaser. Lots of plot points make more sense through the lens of the graphic novel: the whole squid attack, Looking Glass being slightly off, Robert Redford as president.
If it turns out they don’t produce more seasons in the HBO series timeline, at least there will always be the comic. (And Westworld, for the time being).
Highly recommend: get a BB-8 or similarly lovely icon from your favorite mythology on the credit/debit card you most frequently use. I have a couple lovely bonus conversations with folks per week because of it. Sometimes it's "like your card" but sometimes it's full "did you see the latest thing?" and it's nice to talk to people outside my normal routines.
Of note, I get as many comments about BB-8 on my card in a week as I did for Darth Vader in a month. QED the fandom is wrong, bring more fun stuff and less super-serious Skywalker stuff. And don't be cowards, let Chewbacca and Maz resolve their romantic tension!
ps. tip everyone you can until our country’s terrible treatment of people in service jobs improves. They work hard, get paid too little, have basically zero safety net, and serve on the front lines of the "may I speak with the manager" wars.
An insightful thing my pal Brandon Hays observed is that teams introduce little bits of waterfall into their agile processes when they get burned by scope expansion, bugs, infrastrucure, and such.
It’s tempting to try to eliminate potential sources of surprise and drama. Paradoxically, adding waterfall-style checkpoints seems to introduce more drama and surprise than it prevents. In my experience, checkpoints introduce bottlenecks and hand-offs that reduce the speed and quality a team produces software.
Instead of reinventing waterfall within an ostensibly agile process, I’ve found its better to note all the things that have surprised and caused drama. Consider if those are due to consistent conditions in your team. If they’re systematic, fix them. That is, do agile retrospectives.
If it’s not systematic, take a dose of optimism and keep going. Thoughtful, capable teams have a sense for the conditions that yield unpleasant surprises. They don’t need waterfall-esque checkpoints and documentation to avoid them. In my experience, they’ll tell you what they’re worried will bite them later. Just ask!
Succeeding and thriving at remote work is largely about getting very good at asynchronous (Slack, discussion threads, email, etc.) and nearly-asynchronous (phone calls, video meetings, screen sharing) communication.
Productivity in remote work is often bottlenecked by the availability of teammates for near-asynchronous collaboration.
Therefore: boost your productivity as a remote team member by writing up context and questions your teammates can think through and help with when they’re available to collaborate. Then, pick up another task to make progress on in the meantime.
Suppose I’m working on a card/task someone wrote up for me last week. I’m likely to come up with questions about edge cases or clarifications about how the thing is supposed to work. Often I can make a guess and keep working, but sometimes all those guesses pile up and necessitate getting on the same page before I go too deep. Instead of waiting for my teammates to get out of meetings or re-appear online, I write up my current thinking and the questions that I’m blocked on.
The key is to always have another task I can switch to without losing all the context in your head. Usually, there are tests to write, edge cases to explore, code to refactor or clarify. Switching between entirely unrelated features or bugs is not the best choice. I maintain my own backlog of ideas, chores, and tasks for these occasions.
My teammates are pretty consistent about their working hours and checking in several times per day, so I don’t often wait more than a couple of hours to collaborate on how to unstick myself. More often, the act of writing down how I’m stuck leads me to realize how I could proceed while my teammates think about my questions.
p.s. this works for co-located teammates too! 😉
A nice guide on code reviews (unfortunately no author is attributed on the Notion doc) is making the rounds. If you do code reviews, you should read it. If you don’t, you should start, and then read it.
I do have a personal quibble with this particular guide. I find code review most valuable for “education and context sharing”. I rarely detect bugs or “safety” issues when reading PRs. I’m trying to build this skill, so maybe check back with me later on that.
On the flip side, I want to boost a couple ideas that I wish had been in force for code reviews I’ve given/received in the past:
Lastly, this whole paragraph hits home. Onboarding and “mind-melding” is possibly the second most important thing to keep in mind regarding code review in the year 2020:
Nobody went to school for hacking on your company’s stack. Outside of software fundamentals all of us had to learn how to make things work while on the job. Code reviews are one of the best ways for us to share knowledge and context about different ways things are done or tricks we’ve figured out to get things done in better ways.
In my opinion, the most important thing to remember about code review is that it is often the worst time to offer non-trivial feedback. Most pull/change requests land when a project is wrapping up and the author is ready to ship the thing. This is the riskiest and most frustrating time to make substantial changes. If you want to improve code design and practice, pair programming is the better tool, not code review.
I’m drawn to expansive views on a subject. Sprawling narratives are irresistible. Giant books are my weakness. It’s rewarding to finish a chunky, 500-page book but getting there is quite the chore. The more pressing problem is, there are far more tomes out there than I can ever read.
Previously, my strategy for reading large non-fiction tomes has been to 1) slog through them or 2) let them sit around making me feel guilty. Instead of accruing a backlog, I’m looking for opportunities to get the essence of longer books with a smaller investment of time and energy.
Thus, I’ve organized my ideas into a 2x2 diagram to how I’m making tradeoffs and deciding which books to read this year:
Interviews with the author on podcasts are often the sweet spot. Podcasts around 60-90 minutes are often enough time to explore the major ideas for the majority of the interview. Often this is as much or more than I’d want to get out of the book in the first place. Plus, a podcast, especially when sped up, is a tiny fraction of the time it takes me to read a short book, let alone a considerable tome. If I finish listening to a good interview wanting more, it’s a great indication that I should the book to the “someday” list.
Book reviews sometimes cover enough of the material in a book to get an idea of whether it’s worth seeking a podcast interview or adding to the “someday” list. Even better, sometimes they more concisely state the whole idea of the book, obviating taking time to read it. This is especially true for topics not known for their depth, e.g. business books.
I am probably never going to read War and Peace or Capital. A Critique of Political Economy. Instead, reading the Wikipedia articles on those books gets me in the ballpark or conversation. I think of this as quiz-level literacy: I might remember enough to answer a pub quiz question on these, but I would not be able to debate even the granular points in either of those books with someone who had read them.
On the upside, most Wikipedia articles are less than a ten-minute read; quite the time savings! Sometimes those articles are heavily linked to other topic pages, possibly more useful than reading the actual book when it comes to deep topics like economics, history, or philosophy. On the downside, most Wikipedia summaries are very short, to the point of only indicating an idea is present, rather than exploring it.
Discussion threads on a book (Twitter, Reddit, Internet forums) sometimes yield deep insight or connections about the material in a book. More often, the discussions get sidetracked and it's not about the book I’m interested in anymore.
Articles on books often seem like they would be a perfect balance between depth and time. However, like discussion threads, they tend to spread out into other topics easily. Not necessarily bad, but suboptimal for my purposes.
It would seem like long-form magazine writing on books would be a nice balance point. Reviews and articles on interesting books often pop up in my periodicals or timeline. Mostly, these aren’t as useful as interviews because they weave in and out of the book material and into whatever larger point the writer is trying to make of the book. Nonetheless, a good article on a book indicates either a writer worth reading in the future or a book with “someday” list potential.
When I really want to go deep, but still don’t know if it’s worth reading every single page, skimming is the answer. Some books are rewarding in-depth but repetitive. The second or third case study backing up an idea or thesis is not as valuable or interesting as the first.
Finally, if the topic and/or author seem worth the time and effort, just read the dang book. It takes time and dedication but yields the best journey. It’s an investment; the reward is proportional to what you put in.
After all these hacks and shortcuts, deciding to read a massive tome ends up being something of a joy. I want to read a Robert Caro book this year, either The Power Broker (definitively a tome) or Working (relatively short). Having read about Caro a bit last year, it seems like I should experience his work at least once. So I’m a little excited to take on the challenge and a little worried it might consume many months of reading time. But I’m pretty sure it’s a worthwhile adventure.
A couple of my favorite Ruby friends mentioned that they’re trying to keep their side projects small. Despite that very practical aspiration, the siren call of larger projects still beckons. We know the pragmatic step is to find the little projects inside the big projects and share/ship those.
And yet…it’s easy to fall back into big projects, forgetting to show progress. So here I am, showing a little bit of progress! 🤞
...
Here's a behind-the-scenes look: I wrote this months ago, when I was trying to get back to consistently blogging. It was my the little push to get the habit started again.
The astute amongst have noticed that I've been somewhat consistent for the past few weeks. But I'm about to jaunt off for a few days of vacation and I didn't want to let my progress reset to zero. So I dug this post back up and here we are. Repurposed for a good purpose.
I'm still here, showing progress. Finding the little victories amongst the bigger vision. Keeping the candle lit, per se. As it turns out, if perfect is the enemy of good, skipping your blogs because you're going on vacation is the enemy of sticking with the habit of blogging. 📈
As a manager, I hear about things that are interesting and things that probably need changing.
“We want to do three projects but only have two teams.”
“The next production release is held up by this one task that needs seven people to agree on a minor but complicated detail.”
“The backend team has to spend the next week upgrading dependencies to meet new security requirements from the operations team.”
Lots of work to do there. Eyes bigger than stomachs, weird coordination issues, past decisions piling up and haunting us all at once. Assembling these data points into a theory of how the organization works, without falling victim to us-vs-them narratives and cynicism, is an essential challenge of management.
On the other hand, I hear things that are categorically good.
“Alice has saved us a ton of work this week.”
“Bob did fantastic work on this product and we’re going to ship early.”
“Carol stepped up and coordinated everyone when the project lead had to take a few sick days.”
In my few years of leading and managing teams, these are the best kinds of things to hear. Something about people is working here. They’re turning accountability for their work into positive outcomes.
Stacking repeated positive outcomes yields trust in people and teams. That yields agency to tackle future projects in creative, potentially better ways. That usually leads to even more positive outcomes. Even more importantly, it makes for teammates who are excited and satisfied by their work.
Bringing teams together across an organization to make positive outcomes for people who are excited about their work: that’s when management feels like it is clicking.
As unreleased material trickles out of the Prince estate, some fantastic stories have emerged. I haven’t yet read The Beautiful Ones, but even the stories that aren’t part of his incomplete autobiography are top-notch Prince mythology.
Prince hired a DJ to play music for just him and his date:
“And then it hits me,” WallyWaves writes. “There’s only two people in there. Prince and a girl. I’m not there to DJ a private party. I’m there to DJ a date. Prince is on a date and I’m the entertainment.”
Prince shopping before Tower Records opened:
Mike: "How do you want to pay for this? Would you like us to ring it up now?"
Prince: (smiles)
Jerome: "Yeah, talk to THIS dude, here's his number, he'll handle it." (hands us digits for the President of Warner Bros. Records)
Finally, for all your conversational and expressive needs, an Official Prince GIF Archive.
Developers love contracts, i.e. types and type systems. Except, and especially, when they don’t. Contracts tell us, this module has a few functions and they definitely take these inputs and produce these outputs. Some languages (Haskell, Elm) even encode the possible side-effects of calling a function in the types. Contracts place useful, and sometimes comforting, constraints on the relationship between two bits of code.
A consequence of software eating the world is real-world contracts became weaker. Physical objects no longer have the constraints that made them special before.
That fancy car you bought might mix artificial engine sounds in with whatever’s playing on your speakers. It may also collect data on where you’re going, upload it through a cellular data connection you’re not even paying for, and sell it for “marketing”. All of this a departure from what was previously considered the “contract” for a high-end car.
That porch camera an e-commerce giant sold you so people don’t steal packages off your porch may also be accessible to their customer support. Or, the police. Again, a departure from the contract most of us grew up with for household electronics.
That book you bought might get “turned off” if it’s no longer a good business for the vendor. It might get changed if words in it were wrong or politically inconvenient. You guessed it, not quite the contract most of us expect from a bag of words.
That computer-enhanced movie you went to see might get revamped wholesale because the teeth are creepy, a human hand where a cat's paw should be was overlooked, or because people were having too much of a laugh about the whole movie. Notably, this is not Martin Scorcese’s vision of what cinema should be.
Before they were software it was natural that cars, books, appliances, vinyl, etc. had better contracts:
To understand why books are still around, and why they delight as they do, we need to do some “media accounting” — What are the costs (individually, socially) of engaging with certain media and mediums, apps and publications?
Stab a Book, the Book Won't Die - Craig Mod
Understanding the contracts into which we enter with media helps demystify why physical books (and, similarly, vinyl, analog film, et cetera) not only remain compelling, but become more compelling the more their digital twins grow vast and fuzzy.
The software we’re building today is in almost every way superior to the immutable objects we created before. But I can’t help think that the constraints that make a copy of Cat’s Cradle, The White Album, an Omega watch, or a Porsche 911 special might make software better as well.
Perhaps what we need is a little less change and a little more purpose.
A thing I’ve learned from weightlifting (also from Destiny, but that’s a whole other thing), is the value of showing up several times a week and putting in the right kind of work.
Learning is training, and the quality of your reps is important. David Perell makes the connection better than I could:
Athletes train. Musicians train. Performers train. But knowledge workers don’t.
Knowledge workers should train like LeBron, and implement strict “learning plans.” To be sure, intellectual life is different from basketball. Success is harder to measure and the metrics for improvement aren’t quite as clear. Even then, there’s a lot to learn from the way top athletes train. They are clear in their objectives and deliberate in their pursuit of improvement.Learn like an athlete
Knowledge workers should imitate them.
In short:
Economist Tyler Cowen also commented and shared his routine.
My personal routine this month is: read fiction and non-fiction every day. Write or revise every day with an eye towards building up my muscle for publishing articles on this blog.
Also: floss every night. 🤷♂️
Related: applying a fitness training mindset to software development is a great way to reach “I know this”!
How William Gibson Keeps His Science Fiction Real - I gotta read more Gibson; just as soon as I finish all the Stephenson. 🤦♂️
One of them showed him an episode of “Cops,” the pioneering reality series in which camera crews sprinted alongside police officers as they apprehended suspects. Policing, as performance, could be monetized. He could feel the world’s [fuckedness quotient] drifting upward.
Futurists he knew had begun talking about “the Singularity”—the moment when humanity is transformed completely by technology. Gibson didn’t buy it; he aimed to represent a “half-assed Singularity”—a world transforming dramatically but haphazardly. “It doesn’t feel to me that it’s in our nature to do anything perfectly,” he said.
He spent time on eBay—the first Web site that felt to him like a real place, perhaps because it was full of other people and their junk. Through eBay, he discovered an online watch forum, and, through the forum, he developed some expertise in military watches. He learned of a warehouse in Egypt from which it was possible to procure extinct Omega components; he sourced, for the forum membership, a particular kind of watch strap, the G10, which had originally been manufactured in the nineteen-seventies and had since become obscure. (A version of it, known as the NATO strap, is now wildly popular in menswear circles.) Gibson noticed that people with access to unlimited information could develop illusions of omniscience. He got into a few political debates on the forum. He felt the F.Q. creeping upward.
Did Gibson popularize the NATO watch strap or was he just ahead of the horological time?🥁
Setting roadmaps and key results feel like truthful, strategic work. But the flip side is, if you approach them at face value or don’t focus on the outcome, they reduce the ability for teams to creatively pursue different solutions in service of the desired outcome. That increases your risk of exceeding calendar/complexity budgets!
I’ve come to hate the damage the “product roadmap” metaphor does to the brains of everyone involved in developing a product. When I use an actual map of actual roads, I assume that I know where I’m going and how I’m going to get there. This is never the case when developing a product.
Kent Beck, Decisions, Decisions or Why Baskets of Options Dominate
Instead: choose shorter iterations that let you try an idea, spend a limited amount of time on it, and decide if it’s worth further pursuit. Optionality! The downside is, now you have to decide on each idea that got you closer to building the product or achieving the key result. Decision fatigue: It’s a better problem than no options! 🤷♂️
Consumers, on the other hand, love options. Buying a car, instead of e.g. a bike or using scooters and buses, is buying a bundle of options:
That’s why ditching car ownership is going to be really unattractive for a lot of people - no matter how attractive you make the alternatives. Unless you can replace all of the important jobs that a car does for you, all at once, then competing against the car means competing against free. Actually, it’s worse than that - it means competing against free and nice. Bundle economics (and also ego issues) are powerful enough that it’s pretty rare to see people downgrade their cars, even if their car requirements have gone way down (like they had kids go off to college). Once you go SUV, you don’t go back.
Alex Danco, The Car Bundle
When we’re buying cars, we are making trade-offs on money, signaling, time, practicality, wanderlust, recreation, and whatever hoops the car salesperson is putting us through. Again, decisions are fatiguing!