I like that Ember’s tagline is about ambition.
Use factories to create jumbo object graphs
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 }
Failure = entropy due to adding humans
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.
Writing is thinking, so write about code
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!
Bradford Fults on feedback and human bias
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?ā
The project management corollary to Hofstadter’s Law
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.
Towards smaller JavaScript
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:
- Snowpack 2.0 – download all your deps, import them as modules. Snappy development experience ensues.
- lit-html – generate DOM without going through React/Vue/etc. intricacies
- Alpine.js – attach dynamic interactions to elements with data elements describing DOM manipulations
- htmx – attach dynamic networking to elements with data elements describing AJAX/Websocket/SSE events
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.
The possibility of software through the ages
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.”
The Revenge of the Intuitive and developer tools in 2020
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.
One strong center and two senses stimulated
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.
