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.
Pardon the dust, learning in progress
I’m trying a few things while I learn how ray-tracers work:
- learning Rust and graphics programming
- collecting my thoughts and discoveries in the repo, aka blogging
- doing it all in public, rather than a private repo
- tackling very math-y programming and domain problems, despite my lack of acumen in the area
Brought to you by: more folks should do blogging-like things, even if it’s not entirely on their own platform or using blog-software and more veteran programmers should be naive and not know everything in public.
It’s true that Twitter took some air out of blogging. I suspect it’s also true that they formed a positive feedback loop when they overlapped. Longer-form writing informed tweets, tweets responded to or inspired longer-form writing. We can have our tweets and eat blogs too!
Listening to a DJ live set and it opens with the whitest, most English version of a 90’s hip-hop sketch I’ve ever heard. This person learned the exactly wrong lesson of possibly every album after 3 Feet High and Rising.
Gil! Scott! Heron! man crush on LCD Soundsystem intensifies itunes.apple.com/us/album/…
Why blogs are still lovely, part fourteen: shawnblanc.net/2019/01/s…
Corollaries to “new languages won’t achieve career-sustaining critical mass": 1) frameworks become the important point of leverage 2) framework/language harmony or outright integration ala Elm or Erlang become even more important.
Long bet: Java, PHP, JavaScript, Python, Ruby, and C# will be the last languages that achieve a critical mass such that they can sustain developers through their whole career. From here on out, it’s a melting pot of framework and technology choices.
Increasingly convinced houses only exist in two states: brand new and invisibly needing repair, lived in and visibly needing multiple repairs. This adage may apply to societies too.
We don't have to agree about code style
Will we ever come to agree on writing code?
Ruby folks like short methods. One-liners even; maybe for their concision, maybe to show off their language and code golfing skill.
JavaScript folk like often like a bit more heft in their functions. No matter how good a function name is, logic is easier to understand if it's all in one place.
Despite the mechanical similarities of this sample size of two languages, programming communities have chosen very different styles. This has been happening for decades, since the beginning. It will probably always happen.
As sure as Keith Richards sounds different than George Harrison or Pete Townsend, developers will disagree on the structure and little details of code. Like music, like code.
Luckily, now we have pretty printers and code formatters like prettier, gofmt, rustfmt, or RuboCop. This is a welcome advance from even ten years ago, when some code reviews could bog down in "there's an extra whitespace here" or "this function seems too short, can we merge it with its callers?"
We don't have to agree, we just have to act like professionals when it comes to the little things.
It's 2019 and I'm signing my jokes like its 2019
A stranger walks into an elevator. I say “how about this weather?!” They smirk, or let out a small laugh. It’s easy to think, “I am funny guy!” But: that’s not a joke, it’s not funny. It’s just small talk and politeness in action. I am not, actually, the funny guy in this scenario.
When I was fourteen, I was really into standup comedy. I managed to find a club above a bowling alley that let me do a 2 minute set. The only constraint was that I couldn’t work blue. So I wrote two minutes of jokes, performed it a couple times, got a few laughs, and that was that. I figured out that I could get in front of people and tell some jokes, and I didn’t need to rely on slapstick cursing to do it.
Also, I was fourteen and surrounded by teenagers. Teenagers make a lot of jokes at each other’s expense, because they’re cruel, don’t know better, and aren’t practiced humorists. I had experienced my share of being the subject of those jokes and decided I didn’t want to be that kind of funny. Eventually, I came to the formulation that the best jokes aren’t at someone else’s expense.
As random things in one’s youth go, these two were pretty formative. I decided that if you can’t get a laugh without cursing or making a joke at someone’s expense by punching down, you weren’t actually funny.
Turns out these principles are pretty handy for the world we live in (and have always lived in, but some the future is not evenly distributed, etc.)
You can work blue, you can demean other people, you can say what’s really on your mind, and you can punch down. You may get laughs, but they’re because people are sympathetic to your anger or cruelty. Or, maybe you’ve been bombing so long they’re just relieved you said something almost decent and the laugh to diffuse the situation. But, that’s not funny.
When a joke misses, when a standup flops, it doesn’t mean we’ve become a humorless or prduce society. None of this means the end of humor or satire. It means we’re going to separate the really excellent humorists from those who are merely humor-adjacent.
Who has two thumbs and is pretty excited for Enumerable#to_h and the proc composition/chaining stuff in Ruby 2.6! 👍👍
Which came first: the theory of productivity or the Singularly Great Work?
Point: GTD and XP are both based on what worked Really Well for One Singularly Productrive person. Counterpoint: we all need our own theory of what might work for us personally before we get started.
In honor of Ms. Jackson’s imminent induction into the Rock Hall of Fame: is Rhythm Nation 1814 a concept album? 🤔 ✋🖐️✋