Teach people to magnify their mind, not write code

Adam KeysLeave a comment

Coding is not the new literacy:

When we say that coding is the new literacy, we’re arguing that wielding a pencil and paper is the old one. Coding, like writing, is a mechanical act. All we’ve done is upgrade the storage medium. Writing if statements and for loops is straightforward to teach people, but it doesn’t make them any more capable. Just like writing, we have to know how to solidify our thoughts and get them out of our head. In the case of programming though, if we manage to do that in a certain way, a computer can do more than just store them. It can compute with them.

That is, it’s not enough to write a loop in Ruby, a class in Java, or use a channel in Go. You’ve got to learn way more “material” than that: how to run your code in an application server, how to store rows in a database, how to deploy all your code to another machine. And then: how to have good taste, how to correct oversight, how to avoid bugs! And then, worst of all: knowing all the little miniutae like platform bugs, slow code paths, unstable code, dependency hell.

We shouldn’t put that upon people just because that’s how most programmers interact with computers. We should keep looking to help folks leverage systems as part of their work, not learn how to build systems to leverage systems to do their work.

Hence, the ending:

Alan Kay did a talk at OOPSLA in 1997 titled “The computer revolution hasn’t happened yet,” in which he argued that we haven’t realized the potential that computers can provide for us. Eighteen years later, I still agree with him – it hasn’t happened yet. And teaching people how to loop over a list won’t make it happen either. To realize the potential of computers, we have to focus on the fundamental skills that allow us to harness external computation. We have to create a new generation of tools that allow us to express our models without switching professions and a new generation of modelers who wield them.

We’ve succeeded in magnifying our voices with computers. I like forward to standing back and looking with wonder at how much we’ve magnified our minds.

When software loses its hair

Adam KeysLeave a comment

Software’s Receding Hairline:

This is interesting, because the mechanism of growing a comb-over applies to software development. A comb-over is the accumulation of years of deciding that today is not the day to change things. A comb-over is the result of years of procrastination, years of decisions that seem right when you’re in a hurry to get ready for work but in retrospect one of those days should have included a trip to the barber and a bold decision to accept your baldness or take some other action as you saw fit.

A comb-over is a local maximum for improving baldness. You can’t really escape baldness of your head. You can escape a local maximum in your software, if you’re thoughtful about managing tradeoffs between product progress and technical progress.

It would have been better if you hadn’t gone bald in the first place though. Same with software!

(Analogies are just great. Thanks for this one, Reginald.)

New Pro Bowl selection explainer

Adam KeysLeave a comment

Pro Bowl rosters selected by Michael Irvin and Cris Carter:

Last year, the NFL did away with the AFC vs. NFC format and began using “captains” to oversee a fantasy draft to fill out the teams. In 2014, Jerry Rice and Deion Sanders were the honorary captains, with this year’s choices being Hall of Fame receivers Michael Irvin and Cris Carter.

In other words, they took the one thing fans can control about the sport, choosing the team in the game that means nothing, and gave that responsibility back to millionaires.

Besides the dozens of other terrible things about the NFL, this is the most NFL thing I’ve heard all week.

Sometimes

Adam Keys
  1. Sometimes you go on a writing slump. Usually, just throwing something at the wall is how you undo that.
  2. Sometimes you notice that a lot of your writing can end up in platitudes and that deepens your slump. We regret the error, those responsible have been sacked.
  3. Sometimes you get kinda caught up in learning, tinkering, and enjoying things and forget to write. That's ok!

18 months is a smelly interval

Adam Keys

18 months is a dangerous window, when it comes to building a product. It’s far enough in the future that it seems like you could deliver an ambitious idea within a year and a half. But it’s a long enough timeline that one is tempted to skip the necessary contemplation, dividing-and-conquering, and hypothetical thinking that the planning process forces on you.

As it happens, 18 months is 540 days. 540 degrees is one and a half revolutions. As in, you started a revolution, but ended up regressing.

Saddest trombone. Be wary of anything that promises to happen in 18 months. It’s the “epic handwaving” of project management.

Dining at the source code buffet

Adam Keys

Let me start with a quote from wonderful person James Edward Gray II:

One of my favorite techniques for really learning a new language is to read the core API like a good novel. I’m a hit at parties!

I’ve had great success with this approach as well. I probably read the majority of Rails, the source of every RubyGem I used, and chunks of Ruby’s standard library in my first few years of working with Ruby. I picked up new tricks, figured out how things worked, and got myself out of a lot of tricky corners by reading code.

That we can do this is, to me, the real wonder of working with an open source stack. If I’m curious, I can dig into the framework, language, database, compiler, and operating system I’m using. If something goes weird, I can dig into it. I probably won’t end up changing or fixing anything below my app in the stack, but the ability to peel back the layers is a huge deal.

Given the choice of digging into why software sometimes goes weird and complaining or giving up, always chose digging into the source to see what’s going on.

When you work with open source software, you can always chose to figure out what’s going on around your app. Eating at the source code buffet is awesome!

Megaprojects: megacool

Adam Keys

Megaproject. It’s a cool word. It’s an even cooler list-of-pages on Wikipedia. I’ve only worked on projects limited to tens or dozens of people. The human and geographical scale of some of these endeavors just blows my mind. The coordination and planning required for something like the Boeing 747 or Apollo program is beyond my comprehension. (OK, maybe I’m still really into aerospace; I did go to Space Camp. Twice.)

I would love to be a fly on the wall of the meeting where it’s decided to go ahead with a project that will be visible from quite some height above the earth like Denver International Airport or Walt Disney World. That’s a pretty huge commitment. I waffle for weeks when I decide I’m going to buy a new car!

If those don’t whet your appetite, perhaps speculative megastructures are more your speed? Trans-global highways! And of course, Dyson spheres, ringworlds, et cetera.

It’s good to remind myself that occasionally, human kind is capable of building really great stuff.

Sam Stephenson, understated and excellent

Adam Keys

I’ve enjoyed Sam Stephenson’s work for a long time. Even before “sheesh”, the most polite dismantling of an over-privileged open source user, Sam’s work has been top notch. Prototype is the library that made JavaScript palatable and learnable for me. pow and rbenv, in concert with ruby-build, are a lovely simplification of the weird problem of maintaining Ruby development environments.

The thing that pulls it all together, I think, is how well suited his solutions to diverse problems are. There aren’t a bunch of moving parts. Prototype was very much a library, and not a framework. His code is very much of the tool, playing well in the environment, be it Ruby, CoffeeScript, or even shell scripts. rbenv, ruby-build, and pow all play to the strength of bash and Node rather than trying to extend them to become something they’re not.

I was tempted to say his work is minimalistic. On second thought, I think it’s understated. Look at his website or photostream. The quality of just enough, but not too much, isn’t luck. It’s Sam Stephenson’s calling card. I love it.

Vacation, disposable, and calm computing

Adam Keys

1

Let me talk about vacation computing. The prime directive of vacation computing is that you should compute on vacation as little as possible. Neglect your email, abandon your social mediums. Don’t do the things you normally do, regardless of how computery your regular work is.

From there, it follows that your vacation computer should basically not be a computer. That means smartphones, tablets, and book readers are the only options. But smartphones are pretty much synonymous with social media, so they aren’t really viable as a vacation computer (though you probably want it anyway because they’re a superpower). Tablets are nearly computers now, so that’s not viable either.

It follows that a book reader is the only acceptable vacation computer.

2

Let me talk about disposable computing now. We put a lot of important stuff on our computers these days. Important passwords, legal documents, email, family pictures, private pictures, computer games, purchased and bespoke music, Hollywood and home video, etc. Sometimes those computers are in our pockets, sometimes they’re on our laps and coffee tables, and occasionally you might still find them on our desks!

For the drama and heartbreak that can occur when we lose these computers, we take astoundingly bad care of them. We don’t back them up, we reuse passwords. A moment without wireless networking is the worst and yet we don’t take steps to prevent even more dramatic losses due to password breaches and storage failure.

Given all of this, a computer is made better by making it a disposable object. Backup your data, and backup your backups. Practice good password habits as much as possible so your accounts are isolated and somewhat disposable. Know your gameplan and what happens to your stuff if your computer or backups fall into a lava pit.

3

Knowing about vacation and disposable computing, I’m led to an odd and dissonant conclusion: an e-ink Kindle is the perfect computer. It does not do work, it does not social media. You can take it through airport security without any extra steps, which feels a little perverse and seems a bit surreal. It does not interrupt, it does not beep or blorp, it just barely displays text. As modern computers go, it’s basically useless.

But. You can read on it. And reading is so wonderful. And you can put stress aside. A Kindle gets wet? Not a big deal. Drop a Kindle? Not a big deal. Try to use it by the pool, out in nature, out in weather, out where the internet does not go? Not a big deal. Lose your Kindle? Buy another one, it costs a fraction of all your other computers.

The one scenario where you will find yourself absolutely screwed with a Kindle is when you have to enter text. Logging into Amazon or a wireless network for the first time? That’s a bad time.

In every other respect, the Kindle is a computer that does nothing to increase your stress level. That’s pretty remarkable today. Let’s make more calm computing devices, ok?