Adam Keys is Thinking

twitter.com/therealad…

I have a somewhat irrational “thing” for Amazon Prime. So much so that I’m a little surprised that I have such an affinity for what is in some ways simply the act of prepaying for shipping. But that’s understating what Amazon Prime is.

Prime is a fine example of physical computing. I click a button on my computer. Electrons fly all over the place. Database records are created, messages are sent. Pedestrian. But at some point a TV comes off a shelf and is loaded on a truck. Less than forty-eight hours later, it appears on my porch. Maybe not as nifty as an Arduino robot that mixes drinks, but just as physical and slightly more practical.

Prime is what Amazon should have patented (if they could have waited). “Method for buying something with one click” isn’t so impressive sounding. “Method for integrating e-commerce, logistics, and shipping systems so that things magically appear at my house at my whimsy”, now that’s a good title for a patent.

Amazon Prime has a transformative effect on how I consume. There are all sorts of things that I just kind of languish without because I never remember to buy them when I’m at the right store. If it’s not food, I buy it on Amazon now.

Today I decided I should buy more undershirts. Five minutes later, they’re on their way to my house. Because I’m paying a fixed rate for shipping every year, I don’t worry about batching up my shopping. I just go buy things when I realize I need them. Potentially costly, yes. But now I’ll have a proper supply of undershirts.

Prime, coupled with Amazon’s recommendations, is eerily effective. Years and years ago, when I started using Amazon, the first thing I added to my wish list was first three seasons of Bosom Buddies on VHS (yes, that long ago). Amazon promptly recommend I look into other movies feature men dressed as women (good call, I find this amusing) and serious movies with Tom Hanks (not as amusing). Fast forward ten years, and Amazon gives me humorous, but much more useful, recommendations. I bought three things I’d been meaning to pick up but had forgotten about due to recommendations. I’m a little surprised the streak ended at three. I’m sure there are legions lazy people like myself improving those recommendations right this moment.

Prime makes all sorts of transactions much more fluid for me. I spend less time in shopping centers and have a pretty great choice of products; in exchange, money departs my bank account more fluidly. When economists talk of the incredible complexity of markets, free market acolytes proclaim that truly free markets can route around inefficiences, and globalizationists trumpet the benefits of low-friction trade, they’re talking about Amazon Prime. It’s a service that could only exist in our current age of networks, connectedness, and impatience.

Into every creator’s life, a few non-creative events must fall. Sometimes its meetings, maybe it’s a bunch of business-related emails, or a bunch of support tasks have piled up and it comes time to empty the queue. Whatever the cause, the result is often the same: my day is robbed of chunks of time that are sufficient for tackling the code I wanted to work on. Total Groove Failure.

Going with the assumption that eliminating Total Groove Failure and its causes is impractical, I’m left with the question of how to recover from these sorts of days. I asked about this the other day. I got two sorts of responses.

On the one hand, you can withdraw. Get away from the computer, maybe get some sleep or enjoy an adult beverage. One the other hand, you can take action. Get outside, go for a walk or exercise. Maybe work on a side project. Start some code and leave it for the next morning to finish. These are some of my Groove Reacquisition Tools.

Discovering a new Groove Reacquisition Tool is a wonderful thing. None of them are silver bullets, but each one is little slice of confidence that, even if I get derailed, I can get back on the productivity train.

Whether through action or inaction, it’s important to get away from the computer and/or that which sliced your day into fragments. From there, I’ve often found it helpful to consider what it is that’s stealing my focus and react appropriately. Some days I know that diving into some open source work will do the trick. Others, I need a nap, to exercise, or to wrap myself in a book.

The crucial bit is to realize I’ve lost my groove. Not every interruption leads to Total Groove Failure. There are days where I respond to a few emails in the morning and quickly get into my coding happy place. But if I find myself frustrated at every turn, I resort to one of my Groove Reacquisition Tools.

For the past year, the Java ecosystem has seen interesting evolution. Java the language continues take its place as the new safety scissors of programming, but the pieces around it are getting better. The JVM is now acknowledged inside and outside of the Java community as really good stuff. Really interesting software like Hadoop and Cassandra are built on top of Java. Integration with languages like Ruby and Python is getting pretty good.

What’s most interesting to me is that there’s a competition going on for the hearts and minds of those developers who don’t like using safety scissors. This competition is a great experiment into what developers really want in a programming language. For a language nerd such as myself, observing this experiment is a lot of fun.

On one side you’ve got Scala. Scala looks a lot like Java. But on top of that it adds shorthands and pleasantries from Ruby, a really good type system reminiscent of Haskell, and other handy functional features. When you build up a hybrid language like this you, two things happen. First, a lot of people who look at their checklist, find everything they need and decide. Second, you get a pretty complex language.

Clojure, however, looks nothing like Java. It’s a Lisp, it simply can’t. Clojure borrows from Haskell too, this time borrowing ideas about state and how to avoid it and concurrency (notably software transactional memory). Clojure is a funny looking language at first, but there are some great ideas within it. Plus, it’s a relatively small language; it’s just that it’s a different kind of simple and almost every concept is new to many developers.

Both these languages are building up strong communities. Both are full of great people with energy and ideas. It’s quite possible that a winner-take-all situation won’t occur. I’d like that.

What’s most interesting to me is to see how people take to the languages. Will they go for the familiarity of Scala and deal with the complexity? Will they learn the simplicities of Clojure and rewire their brains? Will they prove the common wisdom wrong and learn both?

I’m watching with great interest.

I’m a Unix guy, by upbringing. My first formative experiences in software development were on an early, Linux 1.x version of Debian. I’d used Windows, but always came back to Linux. When OS X got good enough around 10.2, I switched to something that didn’t require so much tinkering, so I could make more useful stuff.

Software development on Unix has skewed towards focusing on tools, languages, and text editors for quite some time. IDEs and browsers on Unix are a messy, foreign thing (just like everything else in Unix). Thus, I’ve long favored the terminal-and-editor style of development.

I’ve decided that now is the time for me to try something different. I like text editors and directly manipulating text, but I can see why some people feel naked without an IDE. The ability to pop-up a level and make a more broad-stroked transformation to a program is appealing. Having code navigation and semantic awareness baked in has lots of potential.

I’ve probably said grumbly things about RubyMine in the past, but I think now is the time to give it a go. Worst thing that could happen is that I don’t like it and I go back to the infinite tinkering of Emacs or the 85% perfect experience of TextMate.

I’ll let you know how it goes.

I originally wrote that a few months ago, at the apex of my editor neurosis.

I did give RubyMine a try, and I like some parts of it. It’s code navigation is pretty nice, it does an admirable job of integrating with the unique ecosystem of tools that a Ruby developer uses to manage their environment, and it does an excellent job of grokking TDD with test/unit and RSpec. RubyMine is a step in the right direction. I suspect that if I had muscle memory for IntelliJ, it would be the way to go.

But, I have muscle memory for TextMate and Emacs, and I have an affinity for being close to my tools. RubyMine felt one step disconnected from both my muscle memory and my tools. That’s quite an accomplishment; most IDEs feel several steps removed the tools and seem to discourage developing finger-memory in favor of menu-memory. I’ll give RubyMine another try in a year, probably, see how it’s coming along. But in the mean time, it’s great to see that there is a vendor out there tackling the challenge that is tools for Ruby.

Elevator pitch: I’ve found that if you want to divert a productive team into an hour or two of semi-fruitless banter, ask how the team should use Git, Pivotal Tracker, and Capistrano to manage incoming work, verify it, and deploy it to production. In reality, you should ignore all the corner-cases and figure out what will enable you to push really small chunks of work with great frequency.

Ed. What follows isn’t novel, but it was a useful change in perspective for me, so I decided to share.

I’ve been thinking a bit about software processes lately. Despite great variation in telling you how to do so, most processes seem to focus on to do more stuff faster.

Lately, the notion of doing less has a lot of interest. Lean startups are the new-new thing and Getting Real is the old new thing; both preach getting more done and delivering value by doing less and analyzing the results more.

There are two kinds of “do less” a software developer can engage in. In the past I’ve been a little too focused on how I can take on fewer responsibilities from other parties. Literally doing less by scoping down features, putting off decisions, and focusing on things that seem like they really matter. I sometimes feel like I’ve become too eager to do less, making myself something of a cranky coder/slacker. But I digress

Recently, I’ve been trying to tackle doing less in my habits of creating software. How can I write less code to implement a feature, not in the minimalist sense, but in the “how do I just get it to kinda work sense”? How can I take less time between starting something and getting some form of it out in the wild? How can I make my code less coupled so there are fewer changes to make when I decide it needs to do something else? How can I make this less coupled to data storage so that putting it out requires less deployment effort? How can I make changes that are less likely to cause long-term regressions? How can I make it less effort to rollback bad changes?

When I look through the lens of accomplishing more by doing less, a lot of popular software methodology seems like dead weight. Rather than trying to find a process that addresses every team member’s own scars and affections, both perceived and imaginary, it seems most useful to imagine the smallest ruleset that won’t result in uncontrollable entropy and put it into action. If something starts to hurt, imagine the simplest new rule and put it into play.

The goal, as stated above, is to get to the point where you make really tiny, maybe imperceptible changes, and push them really frequently. Everything that stands in the way is the enemy.

Of all the new and reimagined code in Rails 3, ActiveModel and ActiveRelation rank amongst what I find the most interesting. I’m excited that they potentially lower the bar to implementing one’s own data layer. If you’ve got some custom backend or datastore, writing a nice API around it has previously been quite the endeavor. To get it working is one thing; to make it as pleasant to use for application programmers is another thing entirely. ActiveModel and ActiveRelation have been extracted from ActiveRecord and make the task of building one’s own model layer far easier.

My presentation for RailsConf 2010 focused on what ActiveModel and ActiveRelation provide and how one can use it to write cleaner code in domain models, how to make your models feel more like ActiveRecord objects, and how to use ActiveRelation to build your own persistence layers.

I hope you find the slides educational. Further, I’ve posted the examples on GitHub so you can play along at home. If you’re particularly interested in ActiveRelation, I hope you’ll find the examples useful as a starting point to using that library.

Over the past year, I’ve been trying to create more stuff, some of which I’d hope to turn out awesome. Largely this is an ongoing sort of thing. I try things, I learn a little, I keep at it. Some things I try work, others don’t. I try to make a habit out of the things that have worked out well. I make a note of things that seem to help me get out of a funk when I’m not making as much as I’d like or having trouble putting in the hours I think are necessary to make cool stuff.

I first distilled these ideas into a talk I did at RubyConf 2009 on having more fun while coding. But I didn’t realize it at the time; I was just sharing some ideas about how to have fun. For me, one of the ways to have more fun is to make more time to have fun. But that’s just the beginning of making more awesome. I found I had to make more time, and develop a bunch of other habits.

For Big Design 2010, I honed the ideas, habits, and tricks I’ve found useful to me into a presentation on how to get off the couch, start making more things, and make some of those things awesome. I hope you’ll find it useful and perhaps start making lots of awesome stuff.