2013
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”).
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.
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.
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:
- 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.
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.
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!
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.