The guy doing the typing makes the call

Everyone brings unique perspective to a team. Each person has learned from successes and failures. There is a spectrum of things that are highly valued and that are strongly avoided and each team member is a different point on that spectrum.

It’s easy to bikeshed decisions. Everyone should feel free to share their ideas if they have something useful and constructive to contribute. High-functioning teams share assets and liabilities, so naturally they should share and discuss ideas.

That said, teams don’t exist for rhetorical indulgence. They exist to get shit done. Teams have to get all the ideas on the floor, decide what is practical, and move on to the next thing.

If there isn’t an outstanding consensus, the tie breaker is simple: the person who ends up doing the work makes the call. That’s not to say they should go cowboy and do whatever they want; they should use their knowledge of the “situation on the ground” to figure out what is most practical. With responsibility comes the right to pick a resolution.

It’s worth repeating: the guy doing the typing makes the decision.

Skip the hyperbole

Hyperbole is a tricky thing. In a joke, it works great. Its the foundation of a tall tale (TO BRASKY!). But in a conversation of ideas, it can backfire.

The trick about humans is that we rarely know exactly what the humans around us are thinking. Do they agree with what I’m saying? Are my jokes bombing? Is this presentation interesting or is the audience playing on their phones?

So the trick with hyperbole is that I might make an exagerated statement to move things along. But the other people in the conversation might think I actually mean what I said. Maybe they understand the thought behind the hyperbole, but maybe I end up unintentionally derailing the conversation. More times than I can remember, I’ve said something bold to move things along and it totally backfired. Hyperbole backfired.

Nothing beats concise language.

Post-hoc career advice for twenty-something Adam

No program was ever made better by one developer scoffing at another. Computer science does not move forward with condescending attitudes. Success in software isn’t the result of looking down your nose or wagging your finger at others.

And yet, if you observe from the outside, you’d think that we all live in a wacky world of wonks, one where it’s not the facts, but how violently you repeat your talking points that matters the most. The Javascript guys do this in 2011, the Ruby guys did it in 2005, the .NET people before that in 2002, and on down the line.

Civility isn’t always what gets you noticed, but if you don’t have an outsized ability to focus on technical problems for tens of hours, it sure helps. You’re not the most brilliant developer on the planet, but you like to make people laugh, and you like to hang around those who are smarter than me. That’s not the recipe for a solid career in programming, but it’s a good bridge to get you from the journeyman side of the river over to the side where people think you might know what you’re doing.

Once you reach the other side, its a matter of putting in the hours, doing the practice, learning things, and always challenging yourself. Work with the smartest people you can, push yourself to make something better every day. Grind on that enough and you’ll get to the point where you really know what you’re doing.

Then, you close the loop. You were civil, you didn’t piss too many people off. They are eager to hear about the awesome and exciting things you did. So tell them. Even if you don’t think it’s all that awesome, some will know that you’ve got the awesome in you and that it will come out eventually. Some of them aren’t your mom!

This is what some call a successful career. It’s not so bad, but it’s not exactly the extravagant lifestyle you imagined when you were twenty. On the plus side, you do roughly the same things on a daily basis as you did back then, which isn’t so bad. Being an adult turns out to be pretty alright.

At some point, you write this advice to yourself on your weblog, except in the second person. Hopefully someone younger, perhaps on the precipice of idolizing a brilliant asshole, will read it and take a more civil path. Maybe you’ll get to work with them someday. Let’s hope it’s not too awkward.

The next step and the cleared canvas

Knowing the next step is a pretty good feeling. The uncertainty of where you should next place your foot is somewhere between unnerving and terrifying. But if you’ve got an idea of how to proceed, you can learn something. Maybe you’re right, maybe you’re wrong. It’s the step that counts, not so much where you end up.

I just finished reading the RSpec book. It’s a really nicely done book. It does a great job striking a balance between conveying the philosophy of BDD and outside-in development with teaching the tools that Cucumber, RSpec, and Webrat give you when applying that approach to building, delivering, and iterating on software.

What I’m finding most useful about applying those approaches is that I know what the next step is. There’s always a missing piece right in front of me. Sometimes its a big thing, a feature-sized piece. Other times it’s smaller, a pending spec or a refactoring calling out to me. I’m never in the dark, which is important and useful to me.

On a whim, I decided to start doing the “always keep your email inbox empty” thing. I have always been aggressive about making sure everything is read, and I got pretty strict about deleting stuff I’ll never need to look at ever again. But now, I file things away (mostly into a shovebox) once I’m done with some email.

This is a big deal. It’s easy for me to look at my emails and figure out if there is something I’ve let slide. If there isn’t, I can proceed to doing more interesting things. It’s pretty great.

This week, I made a point to “clear the decks” regularly. If I haven’t listened to a podcast, read something in Instapaper, or scanned feeds after a few days, I shove it away. So I can my check email and OmniFocus lists to make sure I didn’t miss anything I wanted or need to do. Then I make awesome things. In the evening, I clear out my reading lists in Instapaper and Reeder. I don’t feel like I’m always behind. This, too, is pretty great.

It’s really easy to let all the reverse chronologically sorted lists we allow into our lives dominate our routines. Clearing those lists makes it easy to see what the next step is and get on with learning interesting things and making awesome stuff.

Workouts make focus and discipline

It is probably obvious I have something of a crush on working out. I am proud I have reached a point where being fit is part of my lifestyle and that I see more and more results. But my crush with exercise goes beyond what I see in the mirror.

As important as the physical aspects are, I get the most out of the mental aspects. Working out mirrors what I do in coding in a couple ways. Both require staying on my grind almost every day. Both require the focus to push myself and resist complacency.

It’s easy to spend too much time tinkering with social media or pick the lighter weights. It’s harder to ignore distractions and focus on the task in front of me, whether it’s code or heaving kettlebells.

When I do manage to focus I benefit twice. Immediately I feel great because I challenged myself and moved my work or workout forward. Later, I realize I’m getting better at putting the work in every day and tuning out that which is not important to what I’m trying to do.

The TV infomercial benefits of working out, ripped extremities and a strong core, are a tertiary benefit to developers and creative types. Even the decrease in neck fat, the ability to lift heavy things, and reduced tendency to get winded are auxillary. The real benefit that people who make things get from working out are increased focus and discipline.

Clips from unfinished pieces

On the crux of America's challenges:

Part of the American experiment is answering the question, "how can we best take advantage of abundance?" Beginning with manifest destiny and evident in the machinations of Wall Street, one of the story lines of America is the quest to make sure resources of all kind are abundant and generating wealth. But we're arguably at a pivot point. Our money and energy don't go as far as they used to.

How do we make the transition from resource abundance to resource scarcity?

On helping people troubleshoot the Gowalla API:

While this level of self-documentation is quite helpful, sometimes people have questions on the developer list. For this, I've found that asking people to show me whatever it is they're trying to do using curl is invaluable. It's a win-win situation. Often, dropping down to a lower-level tool like curl helps to focus your thinking and makes silly error obvious. If it doesn't become obvious to the API developer, they mail the list with the command they think should work. At that point its either obvious to me and I tell them what to change, or I have a nice, isolated test case from which I can easily try to reproduce their problem.

Who gets screwed when a borrower declares bankrupcty?

Is it possible that bankruptcy-declaring-borrowers are screwing lenders in aggregate? I find it really hard to believe that the banking industry, with its legion of lobbyists and regulatory capture, that any group of uncoordinated individuals could screw the banks.

On the other hand, there was lots of screwing on the part of the banks that led to the financial crisis. Whether it was predatory lending, relying on moral hazard to double down on terrible bets, or asinine compensation structures, the financial industry did something very human. They violated social norms. Except, corporations of this size don't have social norms. They have only market incentives; when the executives, board members, and majority shareholders look at the books, the numbers devoted to "doing the right thing" are probably a rounding error.

On tail recursion and compilers:

Fact of life: modern processors don't execute your code in the order the compiler spits it out.

If your code has, for instance, two adds followed by an if statement, it's pretty likely that second add is going to be executed concurrently or after the conditional. In the world of computer architecture, they call this out-of-order execution, and it's just another service your hard working processor offers to make sure your code runs faster than you ever intended it to.

On shorter cycles of production and the need to get past perfectionism:

Our modes of production are causing us to change how we produce. More and more mediums, be it journalism or software, are produced on shorter timelines. This is leading us to optimize production such that we can bang the content or code that matters into templates that mostly work, but have a tolerance for the rough edges where things don't work.

On Barack Obama's 2010 State of the Union speech that preceeded the health care debate:

Just for grins, I went and read the GOP response to the State of the Union. While they had some vague counterpoints policy-wise, it read mostly as subtle and useless jabs combined with carefully-constructed language to console their base. The GOP is a cynical, gutless organization.

On refactoring and deleting code:

People often say that they would miss having a refactoring browser in languages like Ruby, JavaScript, or anything that is reasonably dynamic. My glib response to this sort of comment is invariably "well, the best refactoring I know is to select the code to modify, hit delete, and start over." Let's take that apart.

I've observed that, despite our best intentions, we are often loathe to change code that we suspect is working, or that we suspect we don't know why it's there. And so, like the planet on which we live, applications accrete into Katamari balls of overly-coupled code that is bound only by locality. Cutting this Gordian knot is often the first step in reclaiming a project.

Deleting code is the knife with which we can attack this problem. Many will acknowledge the goodness of deleting code; it is, quite nearly, a virtue unto itself. I've observed that some of the best developers I know are always on the lookout for ways they can obviate code. So, by way of a strawman, I hope you see that I'm quite correct in this regard.

Focus, momentum, and accomplishment

Lately, I’m a little fascinated by the interplay between focus, momentum, and accomplishment. Focus is the feeling of flow, the world around you fading away. Momentum is the feeling that you’re moving things along, getting stuff done. Accomplishment is stepping back, looking at what you’ve done, and feeling like you did something good. These factors play out differently in the three activities to which I decide much of my time.

When I’m building software, I’ve found that momentum leads to focus, accomplishments yield momentum, but focus does not necessarily yield accomplishments. Yet, the most exciting moments seem to come when I’m focused and building momentum. Those times when my attention is fragmented but I’m working through a list of stuff that needs to get done doesn’t feel like accomplishment, but it does seem to get the job done.

Anecodotally, it seems that, by definition, Monday is the day of the week that lacks focus but still possesses some form of accomplishment. It’s the sacrificial lamb of the work week.

When I’m reading, writing, and organizing information, I’ve found that momentum is not much of a factor. It’s all about focus. Stick my head into a cluster of ideas, focus on what I’m reading, how I’m thinking about it, or how I’m writing it back out. Keep the problem state in my head, admitting as few distractions as possible. Come up for air periodically, review my progress, and decide to either continue or move on to other things.

Of these three activities, I’ve found that I’m most methodical about how I use momentum when I’m thinking. It’s sort of a rate limiter; after I’ve read something particularly dense, I’ll immediately do something banal like catch up on social medias. Not sure if this tendency is enhancing or diminishing my thinking.

I spend several hours a week training. The coffee shop (thinking) and the gym (training) are my third place(s). Recently, it feels like I’ve leveled up. I had a few consecutive workouts where I was more focused than I’ve ever been whilst exercising; no worries about my breathing, or if I was pushing myself too little or too much. From this focus I found momentum. A couple minutes on the treadmill would turn into tens of minutes, then a half hour. One set of strength exercises would blend into the next. I was able to push myself to higher levels of accomplishments. It felt awesome.

Interestingly enough, I’ve found that I need a day off from each of these activities. As awesome as it sounds to have the kind of intensity that lets one make awesome things every day of the week, I’ve found it necessary to relax and take time away from coding, thinking, and training. As it turns out relaxation is an important part of a balanced diet of focus, momentum, and accomplishment.

The political empathy gap

The structural problems in American political discourse are legion. Polarized interests, corporate and special interests, the news/hype cycle, and pundits who serve no real political purpose but exist only as media entities. All of it conspires to misdirect discussions of where our country is, where it needs to go, and how to get there.

Underlying all that is a serious problem. There are two sides to every issue (or so we’re told), and they cannot fathom each other’s position. Empathy is not a characteristic of American politics.

This manifests itself everywhere. Dismissive rhetoric, talking past each other, insulting jabs, moral grandstanding, dehumanizing the other side, binary reasoning, and violent propaganda. Were it the case that conservatives and progressives could understand each others goals, fears, and dreams, these problems would exist on the fringe rather than the mainstream.

Intellectual empathy is a hard thing to come by. We all want to be winners, firmly on the side of the virtuous good. To accept that there is something valid in one’s debate opponent is challenging. To go further and accept ambiguity and uncertainty is even more difficult. It would seem that a majority would prefer comfort in wrongness rather than face up to a world where their side is not that of the virtuous good.

I’m not sure how one learns these things other than seeking out new ideas and opinions. Even then, there’s the intuition to sort the wheat from the chaff, the practice from the principle, the solid thinkers from the eccentrics. Political empathy is perhaps (but hopefully not) the endpoint on an intellectual journey that a pop culture is ill suited to embark upon.

I can’t say that my grasp on the problem is good enough to suggest solutions. Perhaps humor, perhaps better education, perhaps breaking bread, perhaps more journalists growing a spine. I should hope it happens soon, because I’m getting pretty tired of how cynical I am of what politics has become.

Now witness the power of this fully functional domicile!

About a year ago, our garage door was not feeling well. It wouldn’t go down on it’s own. To close it required my loving embrace. Specifically, I had to lean against it as the door goes down the tracks. I’m sure I looked like the “mystic” trope in the “action” movie who, at a crucial moment in the action, resurrects the hero so he can go whoop the bad guy.

This is the part about home ownership that sucks the most. I had a strong suspicion this would work out one of two ways. The repair person will come out, look at it for two minutes, bang on something with a hammer a few times and everything works. Easy, cheap. Or, the repair person will look at it, tinker with it, and pronounce the motor dead, to the tune of a few hundred dollars. It ended up being somewhere in between; I think some kind of specialized garage door grease was involved.

I avoid these things because, through hundreds of logical and unintended decisions, I have chosen the life of an extremely specialized knowledge worker. I enjoy making sense of complicated systems that involve people, computers, and uncertainty. I am nearly useless with everything else.

Luckily, ours is an age where that specialization works out pretty well. I am fortunate that I can pay others to worry about typical “male” tasks like changing the oil on our cars or painting the bedroom (cue applause from the economists in the audience). That said, sometimes the interactions with those folks feels a little odd. I usually have to prefix them with the disclaimer that I am “the least handy dude on the planet”; it’s important to set expectations.

Another thing I’ve learned about home ownership is that repairing my garage door will almost certainly be worth every penny I pay for it. I know this because some time ago, we got around to having someone fix our toilet. It would run for quite some time after you flush it. At least thirty minutes. I let this linger because it was easier to not think about spending money on it that it was to do something about it. But, for not too much money, a professional (read: not me) fixed everything. The toilet flushed and stopped running mere moments later.

The psychological release this brought me was incredible. I found myself noticeably happier that our house was less broken. It was like I got a new toy. And exciting, rejuvenated, toilet toy!

…and that’s the worst part about home ownership. That you can sit down and write more than five hundred words on the joy of home repairs. I’ve been working with some folks that are several years younger than I am. These events are interesting to me, but I know that if I were to breach the topic with them, it would confirm to them that I am indeed the lamest trigenarian they’ve ever met. I know this because in college, I worked with older dudes and the summer I spent listening to them talking about the pH balance of their pools was notably tedious.

So here we are, five hundred words later, telling the whole internet I’m the lamest trigenarian they may ever meet. The good news is, everything in my house works. We got it inspected, and we know this with certainty. I highly recommend it if you have the means.

The ear is connected to the brain

Some measure their work in tomatoes. I measure mine in albums and songs.

When it comes time to get stuff done, I match my ambitions to my energy level. Big, uncertain things when I’m full of spark and optimism. Tiny, predictable things when I’m sapped and ready to check out. The coherence, duration, and novelty of what I’m listening to takes me in a different creative directions. I use Pandora, my own iTunes library, and Rdio to match my creative mood to a musical mood.

Sometimes, I don’t know where I’m going. I may not even know where I am. At best, I know how I feel. This is when Pandora shines. If I feel funky, I go with a Billy Preston or Meters mix. If I’m feeling peppy, I go with RJD2 or Steely Dan. If I’m feeling brooding, it’s DJ Shadow or Explosions in the Sky. Pandora finds my way musically, I find my way creatively. Teamwork.

I’m an album guy. I like to queue up a coherent piece of music and listen to it all the way through, in order. A good album rewards this. It starts with a bang, proceeds through a middle section where things might get slow, take on minor key, or both. Things clear up, maybe with a light and organized middle piece. The finale brings it all together and ends with something that sticks in my head.

Ideally, I’d create this way too. Start at the beginning. Find the crux of the problem space, explore some solutions. Work to some kind of apex where I’ve got all the problems solved and all my ducks in a row. Clean up the rough edges, tidy everything up, and ship it as the finale.

Duration is important. A short album (Treats by Sleigh Bells, 32 min.; Beethoven’s 5th Symphony, 31 min.) is great for tackling a compact but rewarding task in a small timeframe. A medium length album (The Suburbs by Arcade Fire, 60 min.; Game Theory by The Roots, 51 min.) is good when I’m starting to feel my groove. When I’m feeling more ambitious, a double album is in order (The Beatles White Album, 96 min., Mahler’s 5th Symphony, 72 min.).

My wildcard is Rdio. Rdio is a blessing for me as a music service. It is very much based on systemic album listening, as opposed to Pandora’s serendipitous song discovery. I turn to Rdio when I know I want to focus, but feel uncertain about where my creative travels will take me. Rdio’s full of music I think I might like, but I’m not yet sure if I really want to make it part of my collection. When I’m listening to Rdio, I’m tinkering with ideas, seeing if I want to own them now or stow them away for later.

Music is important to my craft, even though it’s not a touch point. I bought almost twice as much music in 2010 as I did in 2009. I started paying for both Rdio and Pandora. Text editors (I spent significant time in three of them last year), notebooks (I finished two and started a third), and various arcane tools are important to my work making code, organizing ideas, and shipping useful software. Getting my music right is perhaps just as crucial.

Four odes to Amazon Prime

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.

Groove failure and reacquisition

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.

A language experiment writ large

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.

Form: follow your influences

Now that I've sort of ranted about tinkering with software and how it is less important than writing, let's talk about form.

I've found new energy in writing here of late. Part of that, I think, comes from thinking about a handful of weblogs that I really enjoy and figuring out how to emulate them on my own terms. What I find most intriguing and energizing to study is the framework within each author writes.

Shawn Blanc is a tasteful writer and curator. His site brings me interesting insight into design, aesthetic, and interface. I like his even-handed mix of original and linked content, his in-depth pieces, and his dedication to words over imagery. You can tell I'm thinking of Shawn when I write lengthy pieces examining an idea from all sides or when I post shorter links with a few sentences on how the linked article fits into a larger idea or aesthetic I find intriguing.

Tim Bray has his hands on many of the technologies and ideas I use on a regular basis. On his own weblog, he often goes off into the weeds of an idea, documenting an intellectual journey of trying to understand a topic that is new or interesting to him. I don't always agree, and even find some of his stuff boring, but love it when he grabs hold of an idea and works on it. You can tell when I'm wearing my Tim hat (not literally) when I write a serial, a bunch of posts tied together by some idea, trying to figure out where the idea leads and how it fits into the bigger picture of an intellectual journey.

Jason Kottke is sort of the original gangster of curation. He is at his best and prolific when he is pulling together ideas, finding the unique and wonderful stuff. But more importantly, his erudition puts a lot of ideas and topics together I don't normally come across. Sometimes I post things that aren't really on topic for this weblog, but I do so because I think they represent the "cult of personality" of what I find interesting or exciting; this is me playing the Jason Kottke card.

Rafe Coburn is also a curator, but his topics-of-interest go a bit deeper, a little nerdier. Rafe's at his strongest when he's pulling together ideas about psychology, economics, science, and history. He uses these ideas to explain the political and technological world we live in. He does so in an opinionated way, but one I find easy to read and non-offensive, even when I disagree with him. I've yet to master his tone and the skill by which he brings ideas together, but if you see me posting on topics that are a little boring on their surface, its me trying to make sense of the world in the way that Rafe does.

Matt Webb is the island and the bridges between thinkers, dreamers, and makers. For years, I've followed his work, delighting in how he brings science, futurism, technology, and materials into wonderful and contemporary ideas. Even better, in his company's recent work, he makes these futuristic ideas happen. Should you ever find me wandering into oddly disparate ideas, trying to pull them together into something wonderful, it's likely I'm doing my own faint impersonation of Mr. Webb.

So that's who I'm influenced the most by lately. The writers whose form, style, and excellence I strive to emulate, whose work I most enjoy. Yours are probably different. But the formula is the same: figure out whose work you aspire to the most, write a post about why you admire their work, and then get to work living up to the bar you've set.

Adam's guide to switching weblogs

Over the past few years of writing on this weblog, I can't tell you how many times I've convinced myself that now is the time to move my stuff to new software. Oh, the shiny and wondrous things that must be on that grass that is so much greener on the other side. This, despite having written at least once before on whether one should implement their own blogging app.

Consider this my yearly devotion to not rejiggering things.

WHEN SHOULD I REWRITE/SWITCH/REDESIGN MY WEBLOG, ADAM?

If your weblog software is so broken you can't post, get some new software that you can post to and port all your old content to it, taking care to preserve links and such (so much as possible; don't worry about boiling the ocean).

If you make your monies blogging, follow your needs; actually you should largely disregard anything I say.

If you're a designer by trade, I'll allow that it's often good for your cred to pop a hot new design a couple times a year; just make sure that only one in ten of your posts are about your fresh new redesign.

ADAM, YOU HAVENT MENTIONED ME YET, I'M CONFUSED.

I'm getting to you!

  • If you're a writer, just WRITE
  • If you're a coder, just CODE

BUT BUT BUT!!!!!!!

No, really. The important thing about a weblog is that you put your ideas and experiences down in writing. You work through your thoughts. You put them out there for people to ignore, criticize, or praise.

You may have a lovely thing where you post links, images, funny videos, etc. Great, me too! But I'm not talking about that. I'm talking about banging two hundred words or more together into a cohesive, intriguing idea.

MAKE WORDS, NOT MARGINALLY USEFUL SOFTWARE SHUFFLING.

The art of making a useful todo list

I have a tenuous relationship with todo lists. Rather than helping me focus on getting stuff done, they usually only give me something to tinker with and feel better about having slightly mitigated my procrastination.

I’ve used Kinkless, OmniFocus, and TaskPaper. The latter is helping more, due somewhat to its more spartan nature. But mostly, I’m simply wiser and more pragmatic about the extent to which a todo list app can improve my life as the years have gone on.

In that wisdom, I’ve eschewed working from my todo list much lately. Instead, I’ve just glanced at it a few times a week to make sure I’m not forgetting something crucial.

For no particular reason, I went back to working from a list last weekend. To my surprise, it worked out for the better. Things got done, a feeling of accomplishment was achieved, stress levels were down, greater relaxation was had.

I suspect this success was due to a confluence of factors:

  • I made sure my list was minimally aspirational; everything on the list was something I could achieve in less than an hour
  • The list was focused on what I need to accomplish; if something was nice-to-have, I did it in the rest times between working items on the list
  • A little bit of novelty can’t hurt; working from a list after a few weeks not doing so is perhaps just different enough to yield temporary productivity gains

All that said, I’m starting to think there’s an art to making one’s list of things to do on any given day. Something that is achievable, but moves the ball. Something not too aspirational, but worth doing. Fresh, but with some long-standing items that feel good to knock off.

Perhaps a good todo list is equal parts excitement, tedium, and accomplishment.

A Personal Journey in Editing Programs

Over the past year or so, I’ve spent a bit of time tinkering with text editors. It feels like I woke up one morning and was simply dissatisfied with what I was currently using. It certainly wasn’t disgust, because I largely like the tools I use. But I felt it was likely there were better tools out there, and that I should give them an honest try. The grass on the other side might be greener.

So I went through liasons with VIM and a couple with Emacs. The first left me feeling disconnected, like I had ideas but I couldn’t even make them appear on the screen, let alone run. My experiences with Emacs are better, but have always felt somewhat awkward. I suspect that at some point, I could be a full-blown Emacs person, but right now, I’m just an aspirational Emacs guy.

I’ve used a myriad of editors in my time. I started with jed, a small-ish Emacs clone, then graduated to full-on Emacs. By way of viper, I migrated to VIM. Then I picked up BBEdit, because I wanted more direct manipulation of text, and less of a never-ending learning curve. I was pretty quick to jump on TextMate, seeing a great fusion of the Mac and Unix aesthetics.

I still think TextMate is as close as it gets to an ideal situation. And yet, it falls short enough that I tinker with VIM and Emacs, two editors that can easily be labeled powerful but extremely lacking in the visual and conceptual aesthetics departments.

I suspect my mismatch with most of these editors is due to something about my habits, the way I like to work with programs, and the kinds of programs I work with. Emacs’ notions of major and minor modes doesn’t play well with markup files with three different languages embedded within. VIM is efficient for those who have internalized it and hostile to everyone else. TextMate is easy to get started with and pleasant to extend up to a point, but seems to have fallen victim to its creator’s perfectionism.

For a long time, I’ve adhered to the philosophy that one should choose one text editor and learn as much about it as possible. Increasingly, I’m starting to think that there is no panacea, no "one true editor". TextMate is great for working on web apps and easy to extend. Emacs is really wonderful for functional programming languages, especially those with REPLs and languages that are LISP-shaped. And some kinds of development demand an environment more like Smalltalk browsers than text editors.

My journey for editing bliss probably won’t end anytime soon. In the future, I suspect that it’s going to be a spectrum of tools depending on the work I’m doing. It could be that the days of personal text editing monoculture are over.

A Brief Survey of the History of Editing Programs

Software developers spend a lot of time working with code. Over the past half-century of doing so, we’ve invented a lot of mechanisms that make that task easier and reduce the amount of friction between an idea and a computer executing that idea.

A quick review of the approaches to working with code reveal some areas where tool makers have devoted a lot of effort:

  • Editors — we’ve gone from paper tape to punch cards, from flipping switches on a panel to editing files one line at a time, and finally to the point where (most of us) work with one or more files by directly manipulating the text with a combination of keystrokes. When you get down to it, the experience of editing code in Emacs, TextMate, Visual Studio, or Eclipse are quite similar.
  • Environments — many software developers today use some kind of full-screen tool that puts a friendly face on all the tools they need to create, edit and deploy their software. These days, it is most commonly an IDE like Visual Studio or XCode. But way back in the day, Smalltalk people used a clever piece of technology called a browser, and it’s not too much of a stretch to call Emacs a Lisp browser.
  • Tools — we’ve come a long way in fifty years. We started writing machine code directly, then we grew assemblers, linkers, and compilers. Today, few developers will go through their career without using a debugger, profiler, lint tool, or applying an automated refactoring. There are a lot of development tasks that can be offloaded directly to the computer, leaving the programmer free to worry about important things like why anyone would ever choose three-space tabs.

Finally, let’s not forget that the past half-century of software development has seen more than its fair share of programming languages. These languages express a myriad of ideas and the ones that combine them nicely and support their users well have left a lasting impression in the evolution of how we express our ideas so that computers can run them.

It seems we are nearing an inflection point with regard to how we use tools to create programs. As the keyboard-and-mouse give way to the display-and-finger(s), there’s an opportunity to interact with and modify programs in new ways. I suspect that the future of editing programs has something to do with merging editors with environments and making the tools as pervasively used as typing is today.

Who are we that make software?

We who spend all of our time in front of a computer involved in the production of software are often quick to pigeon-hole ourselves. You probably self-classify as a developer or designer, maybe an engineer or artist if you got a college degree and think highly of it.

But like many other things, it’s all messy now. I’d say I spend sixty percent of my time doing general “developer” stuff, twenty-five percent doing something one could approximately call “engineering”, and split the rest between marketing, business, and design.

Does self-identifying with any one of these roles limit how we think or approach doing what we do?

Sloppy classifications

Consider these heuristics for placing people into categories:

  • You build things that face other people
  • You are making things that are constrained by rulesets defined largely by Newtonian mechanics
  • You are making things where trade-offs between aesthetics and affordances are made
  • Other people build things on top of your things

None of these are useful at all. Were you to provide any one as a definition of what an engineer or designer is, you could probably get some heads nodding. So there’s something appealing about each of these statements. But none of them provide a pleasing definition or guideline for when you’re doing engineering, development, or design.

Part of the answer to these classifications is that we all do everything. Developers strive to build software that fits within the aesthetic of the code around it or their own personal aesthetic. Designers operate within the limitations of human perception and cognition. Engineers are constrained by both of these but will throw either out in a heart beat to improve upon the efficiencies that are important to the project at hand.

We’re all hybrids

The notion of developing designers and designing developers is by no means new. A few examples:

But consider Kent Beck, renowned for his work building and thinking about the process of building software. He often talks about the design of software, considering trade-offs, aesthetics, and affordances just like a designer does. But he’s also been spending a lot of time recently iterating on businesses, trying out new ideas, and writing about the process and essence of converting an idea into a sustainable business.

Or consider Shaun Inman. He’s writing games as a one-man show. He splits his time between producing the music, drawing pixel art, and coding up collision detection systems. That’s a pretty neat cocktail of talents.

If you’ve ever bikeshedded a design discussion or suggested how a feature might work, you’re a hybrid. Ever refer to yourself as a specializing generalist? That’s a hybrid.

Directed thought

If you’ve self-classified one way or the other, there are little things you might do that have large effects on your thinking. You socialize with those who are like classified, use the tools of that classification, and concern yourself with the classic problems that consume those working in your area of specialization.

If you’re not careful, you could box yourself in too much, become too specialized. While there are opportunities for well-chosen, tightly-focused specializations, they are few and far between. Specializing generalists are the order of the day.

Where do we get if we acknowledge that we’re all hybrids now? Suppose you’re aiming for a balance of sixty percent developer, twenty percent engineer, and twenty percent designer. Is it worth going whole-hog learning Emacs or Photoshop? Or is it better to learn less-capable but lower learning-curve tools like TextMate and Acorn? Should such a person concern themselves with the details of brand design and the implementation of persistent data structures, or is it more important to grasp those topics in a conversational manner?

Is it a better use of Shaun Inman’s time to dissect a Mahler symphony, do an expansive study of pixel art, or review the mechanisms Quake III used for detecting collisions? Is it a better use of Kent Beck’s time to build software and write about that process, to talk to people and integrate their problems into his way of developing software, or iterate on business ideas and share those experiences?

Here's the motivational part

So now that all of this is forehead-smackingly clear (right?!), where do we go from here? Personally, I’m using the idea to guide how much effort I put into teaching myself new tricks. I probably won’t go on a six-month algorithms kick anytime soon, but I might spend six months learning the pros and cons of various database systems or application frameworks. I’d love to spend a month just tinkering with typography, color, layout, and other visual design topics. I probably won’t sweat it if Emacs or Photoshop don’t integrate into my daily work too well, or prove impenetrable to my mind, since those tools imply workflows that aren’t top priority to me.

But that’s me; where should you go? If you don’t already have a good idea of what kind of hybrid you are, start noting how much time you spend on various sorts of tasks and think about whether you’d like to do more or less of them. Then, start taking action to realize a course correction.

You can be whatever kind of hybrid developer you want, it’s just a matter of putting in the time and effort.

Those who think with their fingers

In the past couple of years, I’ve discovered an interesting way to think about programming problems. I try to solve them while I’m away from the computer. Talking through a program, trying to hold all the abstractions in my head, thinking about ways to re-arrange the code to solve the problem at hand whilst walking. The key to this is that I’m activating different parts of my brain to try and solve the problem. We literally think differently when we talk than when we write or type. Sometimes, the notion you need is locked up in other parts of your brain, just waiting for you to activate them.[1]

But sometimes, when I’m doing this thinking, there is something I really miss: the feel of the keyboard under my fingers and the staccato of typing. If there’s an analog to “I love the smell of napalm in the morning”, it’s “I love the sound of spring-loaded keys making codes”.

With the release of the iPad, it’s quite likely that a large percentage of the population can start to eschew the traditional keyboard and pointer that have served them in such a mediocre fashion for so long. On the other hand, you can take my keyboard from my cold dead hands. I really like typing, I’m pretty good at it, and I feel like I get a lot done, pretty quickly, when I’m typing.

Last year, I decided I would give other text editors a try. I stepped out from my TextMate happy place to try VIM. I knew this part of the experiment wasn’t going to work because when I felt like I’d gone through enough reading, tutorials and re-learning of VIM, I sat down to tap out some code. And…nothing. I felt like I was operating the editor instead of letting the code flow from my brain, through my fingertips, onto the display. It was as if I had to operate through a secondary device in order to produce code.

Sometimes it seems that developers think with their fingers. I’m not sure what the future of that is. We’ve created environments for programming that are highly optimized for using ten fingers nearly simultaneously. How will that translate to new devices that focus on direct manipulation with at most two or three fingers at a time. Will new input mechanisms like orientation and acceleration take up the slack?

Will we finally let go off the editor-compiler-runtime triumvirate? Attempts to get us out of this rut in the past have proven to be folly. I’m hoping this time around the externalities at the root of past false starts are identified and the useful essence is extracted into something really compelling.

In the mean time, it’s going to be fun trying the different ways to code on an iPad as designers and developers try new ways to make machines do our bidding.

1 If this intrigues you, read Andy Hunt’s Pragmatic Thinking and Learning it’s excellent!