A nice reminder that our work is often more about storytelling than we think - Name It, and They Will Come — Overreacted
TIL, Vim hybrid absolute + relative line numbering: jeffkreeftmeijer.com/vim-numbe…
Does Clojure style still rely on writing a lot of chains of higher-order functions (with -> IIRC) or have they moved on to something else?
Sometimes software rewrites don’t fail - if you focus on escaping a local maximum for the product and customers.
Leaning into the impostor syndrome here, I did a little bit of GraphQL hacking to see how the ecosystem is coming along. Not too badly! github.com/therealad…
Also, semi-literate programming 🤓🤠💪!
Stephen Anderson on The Future of Design: Computation & Complexity. Like everything else, its going to get more weird. But, the large-scale outcome remains the same - design is deciding which elements are essential and which elements to remove:
The real world isn’t so simple, and often has many competing goals and constraints. As a designer, what are you already doing, to help define the objectives and goals for a project? As critical as this is to teamwork, it’s the single, driving factor for machines. We can — and should — absolutely lean into defining these things. This has always been important, but will be vital as we hand over more decisions to Machine Learning.
This definitely sounds like the future…
Now, what if I told you nothing could be designed that can’t be pitched, coded up, and released in an afternoon. Sound insane? I know of at least one company — the largest in their industry — that works this way.
…and we have to invent a future where we solve this future we created without thinking through the ramifications:
Never before has technology allowed individuals to do more harm (or good) with such low effort. — Christian Beck
Any practice where we can drive the iteration time to zero will end up requiring a new way of working where the computer generates a bunch of possible designs/systems/artifacts and a human applies education and intuition to determine which one to keep:
Play this out, and the role of human shifts from that of hands-on creator using software to render an idea to that of a conductor (or curator or cultivator?) working with software to explore possible options. In a sense, we develop a sort of symbiotic relationship with the machine; the machine generates possibilities that we then direct or tweak until arriving at an optimal solution. We see this playing out in nearly every industry, from manufacturing to the design of web sites to healthcare.
A phase transition has already happened where the most successful systems occasionally touch the lives of city-sized populations. “Scale” means the most successful systems/platforms touch entire societies and a major fraction of the human population. I missed this forest amongst the trees of frameworks, languages, and databases. I suspect leaders like Zuckerberg and Dorsey missed it amongst the trees of growth and market acquisition.
Again, we have to invent a future where we fix the future we accidentally created:
What is new in all this is visibility into the scale and scope of problems we now work on — we have to ask questions about impact and outcomes. Facebook and Twitter are platforms that have changed the world. The addictive properties of Pinterest and SnapChat are changing human behavior and social interactions. We can’t treat these things like simple web apps. They aren’t.
Part of inventing the future to fix the future is thinking more about feedback loops and how small changes in forces and incentives create outsized results:
Much of the literature on formal systems thinking is dedicated to this topic of small changes. Reinforcing loops and balancing loops are the two foundational structures of systems thinking. The idea goes like this: Want to introduce a change? Don’t try to change the system (you can’t!). Instead, introduce a small change, or tweak an existing rule, then see what happens.
More optimiscally, this last bit leads me to (continue to) think that the skills designers need aren’t so far off the skills developers need:
I’ve identified about 11 ways of being that describe design. I won’t go into them all — there’s a post coming for that. But you’ve heard me mention some of these:
- Frame & Reframe Problems
- Work from Principles & Values
- Think in Systems and Contexts
- Focus on Human Needs & Motivations
- See Possible Futures (where Others See Present Realities)
- Thrive on Ambiguity
Since I can never remember their individual names, it’d help me a lot if all pugs were named “Puggers” from here on out. “Mugsy” would also be acceptable, but I might get them confused for bulldogs idk.
At least once a week, I wish I could go show fourteen-year-old Adam Diamonds and Pearls and Enter the Wu-Tang so that I’d have much better musical taste much earlier.
Coding without a computer, designing without a design
A thing I want to try is coding offline, per se. Without a functional computer (like a tablet). Think first. Outline and sketch a solution. Maybe pseudocode it up. Then fill it in and make it work once a “real” computer is available.
Related: think first, outline/sketch a solution, only use the computer once I’m ready to build.
Related related: what if frameworks like Rails, Django, etc. are scaffolds that we attach boilerplate-ish behavior to while we’re trying to figure what a program really wants to be? How many essay-sized programs are hiding in novel or encyclopedia-sized systems?
Basically: I want to code without computers more often, and discover more program designs that are lurking within the design of a framework.
Vacation reads
It used to be that all the programmers were ladies. Arguably, they were higher skilled programmers since they didn’t have little luxuries like text editors, REPLs, and online communities to problem solve with! Things were different back then, and they could be better again - The Secret History of Women in Coding - The New York Times
I finally looked into The Pudding and came upon many a delightful visual essay: Rappers, sorted by the size of their vocabulary and The Structure of Stand-Up Comedy on the cycles in Ali Wong’s famous set.
A list of non-hacks, mostly about sleep, that might help you feel better. 7 Biohacks That Actually Work - The Atlantic
A bit dismal: Dictators have reemerged as the greatest threat to the liberal democratic world - The Washington Post. Improvements to liberalism that could counter said rise of dictators and nationalism: The Economist at 175 - Liberalism.
The degree to which the tradecraft of national intelligence agencies are applied in the private sector continually appalls me. But apparently its part of the game for at least one activist investor. Paul Singer, Doomsday Investor | The New Yorker I think probably we’re doing capitalism wrong at this point?
On James Cameron. A man creatively possessed, but a crude man at a best.Man of Extremes | The New Yorker
Javier Grillo-Marxuach (LOST and a bunch of other stuff) on running a television show, but absolutely applicable to any creative leadership discipline.
On Barry, the loveliness, and apparently the sadness that is Bill Hader. Bill Hader Kills | The New Yorker
I think with my mouth. Often that means I start talking with some idea, realize that the idea isn’t as hefty as I originally thought, and end up talking until I reach a moment of mild truth. Which often ends up being a platitude.
Shutting up: it’s a thing I’m working on.
In the world where data-privacy and GDPR compliance matter, owned/onsite analytics stacks like this seem promising bostata.com/post/clie…
Technologies which I am 🤔 about adding to a product but 🤷♂️ if someone has already gone through the process of setting them up and getting the developer experience right: React, Docker, ELK, (probably others)
A thing people don’t like is hearing that a foundational component of their project is mathematically impossible. Corollary: never tell people about the halting problem.
Programming languages > frameworks > libraries > domain languages > domain modeling
(Things on the left are higher leverage than things on the right. Things on the right are easier to build than things on the left.)
In the brief moment when I start a new application, I work from left to right. The rest of the time, I’m working right to left.
It’s easy to learn languages, frameworks, and libraries in the abstract. It’s harder, for me, to find domains to model and build languages for outside of teamwork/professional contexts.
I continue to suspect that developers are undervaluing the ratio of leverage to development effort of frameworks.
Markets Are Eating The World. A non-obnoxious meditation on how blockchains could reduce coordination costs and makes large, corporate-like entities less necessary in the same way division of labor and technology have in the past.
Why are you building this?
At some point in what feels like the very distant past, I bought The Shape of Design by Frank Chimero. For six years, apparently, I’ve flipped past it on the way to reading other things. For some of that time, I was convinced I’d already read it. I was wrong, I just started reading it, and I’m super glad I did.
It opens with this bit of foreword, which struck me right in the “these are my people” feels:
Frank Chimero and I came together over a shared commitment to jazz. But not only exchanges of music. We emulated the form. He would write a blog post. I would respond. I would improvise one of his hunches. He would iterate one of my posts. A call-and-response approach to a developing friendship.
From there, it’s continued to impress. The illustrations before each chapter are delightful, the chapters are short and punchy, and the ideas are as useful to doing computer programs as they are to doing design.
The first idea in the book has taken up residence in my brain and I don’t want to let it go. It is, simple enough, that we should ask “how and why?” are we building this thing.
The “how” is often easy enough and the proverbial cart before the horse. We’re building a design system, we’re using Rails or React or whatever’s hot right now, or we’re doing XP with a little bit of Kanban and a dab of Lean methodology. The thing is, in the end, few of us will say “Oh, they built this with a design system, React, and lean methodology. Phew! I wasn’t going to use it otherwise.”
The answer to “why” is more likely to generate a satisfying response. We build things to learn, because they don’t exist and we want it to exist, because what exists doesn’t satisfy us, because people need it, because it brings joy to those who would use it, etc. Answering why motivates our craft.
Working backwards from “why” something should exist to “how” it should come to exist makes the difference between boring blandness and purposeful clarity.
Little (Rust) learning victories
I’m attempting to learn Rust. And really make it stick this time around. A lot of the “making it stick” part is making lists and having the discipline to stick with crossing items off them!
A smaller part is figuring out how I can notch very small victories no matter how much progress I make. This is crucial because I’ve got about a half an hour each morning to work on this!
My current favorite sort of small victory is to write up what I’ve learned if it doesn’t seem like I’m going to get far enough to commit new code behavior. This happens a fair bit when you’re working with a type checker after years of using a very implicit language.
So far I’ve written up what I’ve learned about the web frameworks Nickel and Actix so far.
The motivation for these little chunks of progress are the learning journals Brent Simmons has published over the years.
