Category: Curated

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.

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.

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.

Overtime means your business is hurting

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.

I’ve seen too many developers put in a heroic effort, only to repeat it the next day, sometimes without sleeping in. That’s “killing the patient”, to extend Ernie’s metaphor. It’s not the natural state of a business to notice the human cost it might have. The people inside the business have to assess that cost and do something about controlling it.

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.