Curated
Just keep writing, October 16, 2017
I watched pal Drew Yeaton work in Ableton briefly and it was pretty incredible. He laid down a keyboard and drums beat, fixed up all the off-beat stuff, and proceeded to tinker with his myriad of synthesizers and effects rack with speed. I had no idea what his hands were doing as he moved from MIDI keyboards, mouse, and computer keyboard like a blur. Seems pretty cool!
I talked myself into and out of porting this website to Jekyll three times over the past week. Hence, the writing dropped off, which is silly because I just blogged about not tinkering with blog tools in the last month. WordPress.com doesn’t quite do the things I want it to and its syntax highlighting is keeping the dream of the nineties alive. I’m writing these short form bits in lieu of a sidebar thing for now. No idea how I’ll make do with the code highlighting.
The Good Place is an amazing show. Ted Danson, Kristen Bell, and the rest of the cast are fantastic. There is an amazing-for-a-comedy twist. Do not read the internet until you watch the first season of this show. It’s just started season two, get on board now!
A Ruby hash, Luxury Touring Edition
map.rb, quality software by Ara T. Howard:
the awesome ruby container you've always wanted: a string/symbol indifferent ordered hash that works in all rubies
m = Map.new
m[:a] = 0 m[:b] = 1 m[:c] = 2
p m.keys #=> [‘a’,‘b’,‘c’] ### always ordered! p m.values #=> [0,1,2] ### always ordered!
m = Map(:foo => {:bar => 42}) s = m.struct # maps can give back clever little struct objects p s.foo.bar #=> 42
I like little tactical improvements to the Ruby standard library that give it a slightly more modern feel.
Currently provoking my thought
The worst NFL announcers, by the numbers (via Kottke). Obviously, this is my jam. To my surprise, Phil Simms didn’t come in last. Simms is a real conundrum; I think he’s great on Inside the NFL, but on live TV he shows frequent ignorance of how NFL games work. Apparently a lot of people don’t like Aikman as an announcer; I think he’s tolerable. I’m surprised Daryl Johnston’s FOX team didn’t show well; I guess Siragusa brings them down something awful.
Mapping Place Pins. The extended story of how the city guide feature on Pinterest came to be. Having worked on the edges of stuff like this in my Gowalla days, this was an intriguing read. Even if you haven’t worked on a location product, stick around and read it for the behind-the-scenes details and the loving treatment of how an idea becomes a product.
Architecture and Agility: Married, Divorced, or Just Good Friends? It starts here…
Does agile development need architecture? Does architecture need agile development? Is it possible to even answer these questions without a polarizing debate typified more by caricature and entrenched cultural views than by clear definitions and open reasoning—a debate more closely resembling two monologues streaming past each other than a dialogue?
…and ends with thinking about the intersection of making things, designing things, and working with people in a different way: holistically. People don’t write great code on schedule because of architecture and process. Architecture and process are what help people learn and create faster. Once a team is learning quickly and creating effectively, then they can write great code and ship it predictably.
Designing technological empowerment
What future are we building, given that we play a role in such an important process?On the role designers play, what they do as careers progress, and how design can positively enhance the world.
Reminder: if you tilt your head just so, developers do a lot of design activities too.
Currently intriguing me
A channel, a sewer, Alabama, and a sunset walk into a bar:
- A Lua implementation of Go-style coroutines and channels, inspired by a channel implementation by Russ Cox, who is a major contributor to Plan 9 and Go
- The infrastructure underneath New York City, sewers, subways, the whole shebang
- “Alabama” by John Coltrane, a jazz cadenza
- Sunsets, as always
It's all made of maths
Math: humans mostly have a love/hate relationship with it. And yet, even if you’re challenged by the continuous maths like myself, it’s hard to argue that there isn’t something magical to seeing the commonplace of our world in mathematical terms.
Confidence despite evolving systems
Facing risk by instrumenting the hell out of it:
Software development is a complex system existing as it does at the intersection of people, systems, good intentions, confused and changing goals, and overly literal state machines. Past behavior isn’t always an indication of future behavior, and humans are terrible at reasoning about complex systems. As such we’re unlikely to know or have good visibility into whether we’ve reached a steady state and our hypotheses are likely to be wrong. In this uncertain and complex environment we initiate change only when the cost of not making a change overcomes the fear of making it.First in a series on how Etsy writes, deploys, and operates changing software without The Fear. Thanks for writing this stuff down, Kellan!
Refactor for value over cleanliness
Practice Responsible Refactoring:
When cleaning up the code enables you to work faster for a task you aren’t dreaming up but actually have at hand, refactoring is the way to go.Dave Copeland makes the point that refactoring without a value-added change (feature, improvement, bug fix, optimization, etc.) is a losing proposition. By the numbers, he's absolutely right. Further, I've found that probably half of the refactorings I'm convinced are necessary aren't as simple or useful as I thought once I get an hour into them. Despite all that, keep doing therapeutic refactorings for practice and to keep your spirits up.
Lessons from premature design
Lessons from Premature Abstractions Illustrated. I’ve run afoul of all three of these:
Make sure you have someone on the team or externally available that will keep the critical, outside look at the project, ready to scream and shout if things turn bad.Don’t let your technical solution influence your design decisions. It’s the tool that needs to fit the job, not the other way round.
Don’t build abstractions as long as you have no proven idea on how the levels below that abstraction will look like.
I could have used an outside, trusted voice to gently reel me in if when I went off into the unproductive weeds. Someone to ask “how will this help the team in two weeks?”, someone to point out ideas that might be great but have only achieved greatness in my head. A person who is asking questions because they want me to succeed, not because they’re trying to take me down a notch.
I have rushed into implementing the first idea in my head. Sometimes I’ve convinced myself that my first idea is the best, despite knowing I need to review it from more angles. I’ve jumped into projects with a shiny new tool and a bunch of optimism, only to cut myself on a sharp edge later on.
I’ve built systems that look fine on their own, but don’t fit into the puzzle around them. I’ve isolated myself building up that system, afraid to figure out how to fit my system into the puzzle in a useful way. I’ve used mocks and stubs to unintentionally isolate myself from the real system.
Basically, these are all really good ways to paint yourself into a corner. It seems like being in a corner with a shiny new system/tool/abstraction would be nice. Unfortunately, my experience is that once you have to make sense of that abstraction in a team, things get dicey.
It’s dangerous to run a software project on your own! Take a friend.
Typing code examples, it's like biking
If you want to learn from a piece of code, you should type it out, instead of just reading it. The value of typing code:
Typing code may be like riding a bicycle. I’m surprised how much more detail I see the first time I ride my bicycle over a road I’ve driven on, mostly because I’m moving slower but also because there’s an additional muscular dimension to the experience.
I love this bicycle metaphor. The slowness of biking engages my brain in an entirely different way than running or driving. Even the mechanical sounds are more pleasant; the consistent whirr of the chain is so much more calming than the revving up and down of a gasoline engine.
The value of typing code holds very true for me; I usually get very little by simply reading code in books and articles. But when I take the time to type it in and actually try to run it, I struggle with it more (not all code examples are perfect) and get more out of it. You should give it a try.
Hit it, don't quit
How to be good at anything. In short: do it, get feedback, study how to improve, repeat.
Something I’ve found, through crossfit, is that if I have any strong suit it’s not quitting. Seems trite now that I write it, but it occasionally helps to state the obvious.
Once I’ve decided an activity is worthwhile, I’m pretty good at sticking with it no matter how silly I feel doing it. I’m not the strongest, the fastest, or the best eater. I’m not the smartest, the funniest, or the most charming. But I’ve made progress in life by showing up every day and trying to do a little better than the previous day.
The bottom line: pick a few things to do well, do them, and don’t quit.
You can't solve technical debt, you can only hope to contain it
Technical Debt is an interesting phrase. We all have a sense of what it is instinctively, but we rarely want to think about it. If we think about it too hard, we feel somewhat oppressed by entropy. All systems tend to toward disorder and software systems are no different. The big question that we all face is what to do about it.
Systems tends toward disorder. Disorder is hard to reason about and risky to deal with, i.e. you’re likely to avoid dealing with it at all. But, most successful products have a system with more technical debt than you’d like at its center.
Increasingly, I think that the only way to confront technical debt and complexity is to contain it. Languages and tools only seem to help at the margin. Rigorously splitting large, complex, debt-filled systems into smaller, proportionally complex and debt-filled systems is the way to gain traction.
You can’t solve technical debt or essential complexity; you can only hope to contain it.
The qualities of better code
What is 'better' code? Dave Copeland on the qualities readable, changeable code exhibits. Of the attributes he identifies, I think number of paths (ABC complexity) is the most important for reading code and fan-in/out is the most important thing to manage for easily changed code.