Let me help you, computer DJ

I look forward to the day when machine learning can differentiate between “don’t play this song because it is awful” from “ don’t play this song because I’ve heard this it a thousand times” (e.g. “Superfreak”, “Rapper’s Delight”, “Come as you are”). Related, I’d love a way to tell the machine learning “if you are ever stumped about what to play next, it’s always OK to slip this song in” (e.g. “Wouldn’t it be nice”, “Summertime Blues”, “Izzo (H.O.V.A)”, “Overture to Samson and Delilah”).


Quit your desk

Things I’ve quit doing at my desk:

Many writers maintain a private writing hut. The hut has one purpose: it’s the place they go to write. They don’t do anything else there. Once they can’t write any more, they go do something else. I think we need to think of our desks in the same way: these are places where we get work done.
I like my desk, but I know the hours I can sit at it and get work done before fatigue sets in are finite. I try to mix in standing at our bar-height dining table, sitting on the couch (most recently, with three dogs), working from coffee shops and occasionally sitting on the front or back porch.

The big idea from that article, burning a hole in my head, is that we should step away from our desks when we’re not working (for me, telling computers to do things). Thinking can happen on a walk, standing outside, or in the shower. Socializing can happen from the couch or mobile device. Procrastinating by reading, surfing, social networking, etc. can happen anywhere.

Once I freed my mind from the idea that I’m only working the moments my butt is in a chair at a desk in front of a computer, my work improved and my life got better. Quit your desk and find out for yourself.


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.

vimeo.com/77330591


Coffee and other warmups

Making a cup of coffee sometimes helps me prepare for the process of solving puzzles with computers. Something about choosing AeroPress, French press, Chemex, or Clever; heating the water to 212F or 200F; medium-fine, medium, or coarse grinding of the beans. The weighing and grinding of the beans, boiling the water, rinsing the filter, pouring the water, waiting, pouring more water, agitating, pressing the coffee, discarding the filter and grinds. Now I’m left with a cup that I made for myself. A minor victory for the day.

All sorts of things require warm-ups. Stretching, air-squatting, or a quick jog lets my body know it’s almost time to exert itself. Word association or playing little games tells my brain it’s time to improvise.

Updating some documentation. A tiny, superficial refactoring or layout change to some code. Drawing a picture in my notebook. Making some coffee. That’s how I know it’s time to solve puzzles.


Off my grid

Off my grid

Courtney regularly drives an hour southwest of Austin, past Dripping Springs, to practice dog agility at a barn her friend rents. It's amazingly quiet once you get past the city, past the backroads, and out into the hills and trees. It was an overcast evening when I went with her so the sunset was a no-show. Yet, the serenity and variety of it wasn't lost on me.

Reads for your weekends

That what I’ve read today and greatly enjoyed:

  • 1491, on rethinking what America looked like before Europeans arrived. Has a delightful sci-fi twist: large parts of the Amazon rainforest could be a human effort, not simply nature. The notion that what many of us consider wilderness might be due to the human hand has tricky ramifications for the tension between preservation and development.
  • The End of the Nation State asks, what if we’re already forming the structures that come after large-scale states?
  • Innovation Starvation, Neal Stephenson on the reasons why we aren’t building big, awesome things like we did in the sixties or seventies.
  • Presentation Skills Considered Harmful, Kathy Sierra argues that it isn’t a good performer that makes a presentation good, it’s a presenter focused on the skills, needs, and experience of the audience that makes it good.
  • The Inferno of Independence, Frank Chimero on the tensions of what it means to be an independent creator of words, music, software, etc. The tensions and misconceptions are worth considering, even if you don’t consider your work “indie”.
  • FastImageCache, an iOS open source library for quickly storing and rendering images, has an intriguing explanation of why displaying many images on mobile devices is hard and how they’ve worked around it to deliver a smooth user experience.

Ignorance: pros and cons

We can often, but not always, choose to ignore those on the internet, on TV, and in our lives with different ideas, philosophies, or opinions about the world. Whether intentional or accidental, this is ignorance.

Ignorance is handy because it can keep us sane. We can’t know all the things or have all the experiences. We all value things based on our own experiences and learnings. We cross-reference that with our ego and emotions and come up with our “truths”. Conflicting “truths” can hurt, and so we only let some kinds of them in and trim our lives to exclude the others. This is helpful for reducing stress and making for more happy days.

It’s not great though, because it isolates us from seeing more of the world and understanding it more clearly. Many media fights/beefs/arguments are rooted in conflicting “truths” and collisions of ignorance. You ignore the value of a supportive government, I ignore the value of maximum personal liberty, and boom! we’re arguing. We’re not getting things done.

Personally, that arguing is stressful. I’d rather not get worked up about politics, governance, and technical minutiae if at all possible. Therefore, I selectively engage in ignorance. I try to double check my assumptions and ignorance occasionally; I find ignorance is a useful tactic, not a long-term strategy.

If you could imagine a world where empathy ruled and everyone possessed a superpower for compromise, you might see a world where ignorance isn’t so much of a problem and amazing things can get done. Oh, what a fantastic, science-fiction world!

Ignorance is bliss and that which prevents us from achieving really big things. Use your ignorance carefully and with consideration.


Peyton Manning, boringly awesome or awesomely boring?

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.


Draw your software

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.
I almost always have some kind of notebook and pen by my side so that I can doodle words and shapes. Having a whiteboard nearby is even better.

Happy Birthday, Mr. The Boss!

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

You want to listen to at least one of these albums because there is no one who better combines the story of America with its music than Bruce Springsteen. If all you know of his work is “Born in the USA”, you got some educatin’ to do!

Find the classes lurking in your ActiveRecord models

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.


Developers are weird with words

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.
Bonus developer weirdness not about words: If you can't decompose an idea into a todo list, you've got an initiative, not a project. Be afraid, keep digging at the idea until you can make it a todo list.

Twice the podcast listening

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.


On music, mostly

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.


20% of programming is duh

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.


Oh, the complexities you'll know

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.


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!

Problems as ever-changing mazes

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
I love this idea about thinking of solving systems as though they were an ever-changing maze, with history (fallen players) embedded within the system. Doubly so when you extend the metaphor to solutions that route around one problem to brazenly take on another problem. If this had a further extension to football playcalling, it would be perfect.

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.

Finishing software ain't easy

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.