Adam Keys is Thinking

The best thing you’ll read about football today. Peyton Manning is what happens when a guy with the attention to detail of an accountant is also proficient at throwing a football and making snap decisions. Manning also looks like he could give you excellent tips on cutting your hedge or fixing that one toilet.

This is why Peyton is my favorite Manning.

Better Code Design through Pictures:

Looking at a picture like this reveals so much that is missing when only looking at Emacs or Vim. Classes that violate the Single Responsibility Principle may become obvious because they’re related to too many other classes. Cyclical dependencies might be identified. Even class names may be brought into question. These discoveries are not very obvious when writing code, but they were remarkably obvious once we threw the structure up on the whiteboard.

How to celebrate the 64th birthday of Bruce Springsteen, “The Boss”, if you’re new to this curious American phenomenon:

• If you’re totally new to his music, start with Born to Run; there is no better album.
• If you’re a little familiar with his music, hit The River or The Wild, the Innocent, and the E Street Shuffle; there’s tons of great stuff hidden here.
• If you’re familiar with the Boss’ repetoire, you’ve gotta hit a live album; the compliation of performances from 1975–89 is my favorite right now.

This advice is going on a year old, but it’s still some of the best around. If you’ve got ungainly ActiveRecord objects that are doing way more than abstracting your data model, you are missing classes in the design of your application. Chances are, one of the objects Bryan describes here is what you might want to extract.

Naming things is hard. Witness things that developers have named and then struggle to explain because words and people are weird:

• TDD sounds like it's about testing, but it's really a design technique.
• BDD sounds like it's about what code does, but it's really a communication discipline.
• Outside-in development sounds like a way to discover the design of software, but it's really a technique for building software using a fractal todo list.

I like to listen to podcasts and screencasts at two or three times the recorded speed. The application I use (Instacast) does this with pitch correction, a feature that’s probably built into iOS at this juncture. In short, I can listen to a thirty minute podcast in ten to fifteen minutes and they only sound funny when music plays. I do mean funny; listen to Radiohead’s “Creep” at 3x speed and it comes out downright chipper.

Our brains can process speech at these accelerated rates just fine. In fact, when I listen to some of my favorite podcasters in “real” time, they sound like they’re thinking really hard and speaking slowly, or that they’re flat-out drunk. The interesting bit is when an accelerated speaker has an accent or when there is radio interference with the FM transmitter I use in the car. At this point, all bets are off and I have to slow the podcast down or listen when the signal is better.

The bottom line is that, empirically, human speech has built-in redundancy. We tend to speak at a rate that, if you miss some sounds, you can probably still make out the words. Further, the space in-between words is probably filled with our own thoughts anyway; we only listen part of the time we’re listening.

Nifty things, our brains are.

You know how sometimes, everything is clicking and you've just got it? Some people call it flow. On Thursday, I was in a quiping flow. You may have witnessed it on Twitter. I thought it would be fun to try and weave it into a coherent narrative, so here we go.

Sara Flemming started a new blog about digging into the technical mysteries she comes across as she works. It is, brilliantly, titled Visiting All The Turtles.

Upon seeing a press photo of Adele, I had an epiphany. As an SAT analogy, Achilles Heel is probably about like Adele's eyelashes. All of her singing powers come from those lashes.

There's not many ways to connect Brian Wilson and Axl Rose, except that they both worked on an album for more than a decade, managed to finish it, and missed the moment when it would have been a huge deal. That said, Brian Wilson's album Smile is way better and about as genius as you'd expect. It's better to be a follow-up to Pet Sounds than a follow-up to Use Your Illusion, even though that's my favorite Guns 'n Roses album (haters?).

It's easier to draw a connection between Igor Stravinsky and Brian Wilson. Listen to the former's ballets or the latter's albums (not the surf songs) and you'll always find something strange going on. A flute trill where it doesn't make sense, a honking bass clarinet, a bizarre harmony. It's fantastic.

As you can tell, Brian Wilson is a kind of my jam lately. It would be a shame if that guy doesn't have the opportunity to make all the music that is bouncing around in his head.

I've never actually been around someone “vaping”, but I'm pretty sure I don't like it based on the name alone. Because that word will never get mispronounced or misheard in a booze joint. Great job, tobacco industry!

On contemporary indie/rock music. No value judgement, just an observation of the way it is:

A one. A two. A one two three four.

hits play on drum machine

Semi-related: I am so glad 7-string guitars are (mostly) no longer a thing.

Tinkering with coffee plus condensed milk has brought my iced coffee game way up. I highly recommend it, if you have the means. Just be prepared to stir, a lot.

To wrap it up, on some other music I've enjoyed and thought a bit about lately:

Ben Folds taps into pathos. Bruce Springsteen taps into the American Dream. Dave Grohl taps into the part of us that just wants to turn it up.

Listen to suit.

Sometimes I think 20% of programming is staring at a problem for thirty minutes and thinking there must be a really simple solution right in front of me and then, eureka and then, duh.

Note that it sometimes takes multiple sittings to reach that simple solution. Last night, for example, no eureka. Step away, try again, repeat. Brains are weird.

Carried complexity is the bane of your application. When you add something to software, you incur the cost of doing the work plus the risk that the change will break something in already deployed versions of the software. But you also possibly incur the cost of understanding that addition later, probably in the context of other additions, and then trying to figure out what’s broken, slow, or needs to change to add this other new thing.

Software developers are most adept at identifying and resisting complexity when it comes from the product or business guys. Adding this feature will take a few days, fixing this bug will take a few hours, generating that report will take a week. This change might sound good for getting that new customer, but the way it interacts with the other features will confuse lots of people in the long run.

You’ve probably thought or said all of these things in the past.

It’s important to realize we put it upon ourselves too. Are there two ways of solving the same problem in your project, team, or organization? Are you migrating from one framework/queue/architecture to another? Those are complexities that you are carrying around in your head. They aren’t inherently bad, but they are costly, and it is important to weigh the pros and cons before you commit to them. When you choose to incur complexity, make sure it’s buying you something and not just shuffling the bits around a little bit.

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.

Problems, puzzles, startups as dynamic mazes:

just running to the entrance of (say) the “movies/music/filesharing/P2P” maze or the “photosharing” maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies that are likely to move walls and change assumptions

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.

When I start work on a project, whether for personal or professional purposes, I have a sense that I need to devote myself to it. That I should figure out how to make it the best it can be, I should only commit the best codes to it; it should be an exemplary piece of work.

On the one hand, this is taking pride in my work, and that’s good! On the other hand, this is ownership, and that’s a little problematic.

The problem with ownership is it leads to irrational decisions. There’s always one more improvement I could make, because this is the thing I own. There is little bit of scope I could add, because I can make this thing really good (at least in my head). There’s one more bug to fix (inexplicably, in my head).

What I’m finding all this points to is, finishing is hard. It’s easy to start a project. It’s challenging to get it out there, and get people to use it. It’s really hard to get it to the point where it’s running itself, you can delegate its operation to others, or it doesn’t need further work.

So that’s a thing I’m trying to figure out. Developing.

In the last improv class I took, we spent a lot of time focusing on four kinds of scenes that appear in improv with astonishing frequency:

• Straight/absurd: A character has a strange perspective on the world, another points out the absurdities in what they're saying and encourages them to say even more absurd things.
• Peas in a pod: Two characters who are very similar in demeanor, perspective, or motivation interact with each other.
• Alternate reality: Two characters inhabit a world notably different from ours; maybe gravity is no longer a thing or it's entirely normal to wear ketchup as formal wear.
• Real: Two players interact with each other mostly as themselves, bringing their own personalities and perspectives to the scene.

• Peas in a pod: take some code that already exists in an app, clone it somewhere else and make it do something slightly different. Extract the boilerplate and ship it.
• Real: the code around the functionality I need to change, improve, or add to is already just fine (I probably wrote it or have an awesome team); I just code like I code.
• Straight/absurd: the code I'm working on has good parts and bad parts; if at all possible I make my changes in the good parts or figure out how to make a new good part for my changes to live in.
• Alternate reality: the code I'm working with is utterly bizarre and strange; I have to make lots of tactical decisions about how to make progress while bringing some level of sanity to it.

A sophisticated solution to a complex problem is fun to find. Its even fun when someone else finds the solution and thoroughly writes it down.

Despite the thrill of recognition for tackling a big complex problem, I find it's more practical to seek the simple problem lurking in and around the big problem. Not all tricky problems are complex. Some are presented in a complex way, some are complex because of restrictions that are easily worked around, and some are complex because of an adjoining social problem. Find the simple problem, or the social problem, and solve that instead. It often works for me.

My favorite kind of solution is one where the solver has taken a problem with a big surface area, found the core of the problem that is 80% of what people care about having solved, and then solved that tiny subproblem. If you want to see masters of this approach, check out the works of Blake Mizerany and Ryan Smith.

Here’s a nice story on technology that isn’t startups: Unhappy truckers and other algorithmic problems. Logistic networks are a technology, just like smartphones. They make our world way better, but they do so invisibly and at a slower pace than the churn of mobile apps, web frameworks, and startups. But they’re still solving problems, moving the needle. They’re just, possibly, less obsessed with technology tribalism and fashion. Some days, that seems like a pretty useful space to find oneself in.

It wasn’t long ago that other developers not knowing the things I know was really frustrating. “How could they not know this?!” I thought that I didn’t have time nor should I be expected to train other developers. If I could learn all this stuff, they can too. (Older, wiser Adam: younger, more naive Adam was very wrong!)

At some point, my perspective on this did a complete turnaround. Now I’m eager to teach other developers things they don’t know. The major benefit is, now they know the things I know! A side benefit is now I know the thing better because I had to teach it.

I was completely wrong when I thought I didn’t have time to teach. Turns out, I don’t have time to not teach other developers the things I think are important.

Overtime is Morphine, Ernie Miller:

A developer who is truly concerned about the health of his or her company also must be careful to ensure the "patient" isn't developing an unhealthy dependency on their heroics, allowing the company to limp along without experiencing the pain that should accompany unwise choices. Pain is how we learn to avoid repeating mistakes.

If your business, or the one you work at, requires regular heroics, consider that it is a broken system. Luckily, software developers are well equipped with mental routines for diagnosing and patching broken systems. Time to hack the organization.

The Scala folks are building newer, better cities on top of older cities, which is how things really work (e.g. Paris, Rome, Boston, etc.). The Clojure folks are building Dyson spheres in space, which is a little ambitious and maybe not entirely realistic.

That said, sometimes wouldn’t you rather live in a sci-fi fantasy world rather than on top of layer after layer of archaeology?

When software becomes successful, software often becomes large. More features, more support systems, more infrastructure, more people, etc. Therefore, software “in the large” seems like a good problem to solve: how can you work at the same pace with one person, one application, and one server when you reach a hundred people, ten applications and a thousand servers?

Right now, I think the only tool we have for reducing the overhead of large systems and organizations is language. Frameworks and libraries can help make larger applications plausible, but they don’t resist the forces that make a large application hard to work with. Tooling and process, like source control or CI, only help us keep large software going; they don’t slow us down on the path to producing huge software.

Better programming languages make it possible to produce software that does more things in a more concise statement. To some extent better “API language” makes that possible too, but it relies on the power of the host language.

Am I overlooking other tools that make software in the large a manageable endeavor?