Allan & Steve are the chubby founders of LessEverything. This is their blog, hear them rant, praise, give advice and talk about Just Stuff, Less Accounting, Lovd by Less, More Honey, Less Memories, Code, Business, Design, Marketing
February 21st, 2008

Chasing Rabbits

written by Steven Bristol

There are a lot of people who are really good programmers who never reach that “top .1%,” or whatever, level. Of late I have been thinking of one of the things that sets the best programmers apart: Discernment. I’m not talking about discerning a good technology from a bad one, but rather the ability to discern a good choice from a bad one. To be able to see the consequences of this path versus that one. In short, to know which rabbits to chase.

When writing software we face a million billion choices every day. Having the talent to make good choices is crucial to being productive. It’s the reason we can launch a product in seven hours.

Here is an example: Recently, one of my guys was refactoring some bad controller code we inherited. He was very excited to show me how he had abstracted and cleaned some of the bad controller code into a library so all of the controllers could call these methods instead of duplicating this bad code all over the place. At first glance it was clear to me that this abstraction was the beginnings of a new library that would be almost identical to Make Resourceful. Once I showed him where his path was leading he agreed that this was probably not the right time to write a Make Resourceful clone, especially when what was really called for was just making the bad code proper, not writing a support structure for it. This reminds me of what Malcom Gladwell was talking about in Blink: The ability to know instantly. (Perhaps to know truth instantly.)

I’m not talking about syntax here. Obie Fernandez and I have fairly different coding styles. He prefers to have the code be more explicit and readable while I prefer my code to be more terse and succinct. Neither is right or wrong, and neither is the reason we are both able to look at a problem and immediately prune it to its core and see clearly where the different paths take us.

This isn’t just true of code, I have seen Allan do the same thing with design. We were working with a designer who was very headstrong and really thought Allan was lacking in something (I’ll save the “why were you working with someone like that” story for another time). This person was doing the html/css for a website and using some popular grid-css-template-thing (I believe that is the technical term for it). When Allan first looked at the code, he just started ripping parts out, not because it was bad in and of itself, but because it was clear that was way too complicated. Using this framework did not buy the simplicity and maintainability of what has come to be known as “The Allan Way™.” (It is amazing to watch Allan take a 7000 line css file and without changing the way the site looks, trim the file to 300 lines.) The other designer made a fuss until Allan was done. Once he saw the difference, he was converted to “The Allan Way™.”

It’s easy to say, “that is just a product of experience.” And although experience certainly plays a part, I think it goes way beyond that. I think this discernment might also be called wisdom. Wisdom basically boils down to how well can you predict the future. When one approaches the wise old sage, the sage immediately knows the outcome of all the paths presented.

So how does one get this discernment/wisdom? I am not sure. I do believe one can learn it, and I think one of the requirements is to know that that is what one is trying to learn. When you play chess, do you only think about your strategy, or do you constantly think “why did my opponent make that move?” Acquiring wisdom might require applying that mental discipline to every part of life: Why did my wife/boss/client/adversary say that? Was it planned or just careless? How does my action affect others? And not just in dealing with others: If I do this, what will I do next? And then what? What paths am I forcing myself into later, if I make this choice now? How deep is this rabbit hole?

Maybe this is the difference between success and mediocrity, between satisfaction and melancholy. Or maybe not.

3 Responses to “Chasing Rabbits”

  1. Jason McCay February 21st, 2008

    Oh Steve…feeling snarky today, are we? Admittedly, I found it humorous that you accused someone else of being headstrong and thinking that others were lacking. But, I digress…

    I think a point not being addressed is that everyone is impacted by biases that have attached to them as they experience life, both personally and professionally. Change is never easy and it is often quicker to dismiss one way of doing things over the other, rationalizing away any benefits with all the perceived drawbacks and risks without truly evaluating the situation.

    One final thought related to a specific example you used…the “lines of code” in a CSS document is truly a poor singular indicator of the “simplicity and maintainability” of the code and instead has much to do with the “style” you addressed in your Obie example. Simplicity is crucial, I agree…but using “lines of code” as a measure of quality is ultimately misleading and tells an incomplete story.

    Wisdom and discernment emerge from a spirit of humbleness. Be humble, my brother…be humble.

  2. Steven Bristol February 21st, 2008

    Jason:

    I’ll take your points in order.

    1. A. The reason I felt that this designer was “very headstrong and really thought Allan was lacking in something” was because Allan and I perceived (perhaps inaccurately) that this person was making fun of “The Allan Way” behind our backs. We actually caught him (and his team) laughing at Allan at one point. After seeing Allan cut his work, this designer seemed to overnight grow a very health respect for Allan.

    B. You seem to imply that I am headstrong and I think others are lacking. I agree with this implication. I am headstrong. Perhaps to my detriment, perhaps not. Honestly, I do often find other’s code lacking. The only reason we worked with that designer is because a developer we wanted to work with insisted on it. This developer is a really nice guy, but since early last year seemed to stop learning anything new and did not keep up with the latest rails developments. Once he was given free range and we saw how poor his code had become, we fired him and his designer. I have since heard that he said that getting fired was the best thing that every happened to him because it was the kick in the pants that he needed.

    2. “Change is never easy and it is often quicker to dismiss one way of doing things over the other.” I think you are making my point for me. I am taking about the very few people who are able to transcend this difficulty and see to the ends. But this is a great time to quote Gandalf, “Not even the very wise can see all ends.” We are all of us only human after all.

    3. Lines of code is not the only metric, but you have to admit less code is better than more code. (At least, that is our company philosophy.) I am not as expert at css as is Allan, and I didn’t want to make this an article about how to make css better, that was just an example.

    4. “Wisdom and discernment emerge from a spirit of humbleness. Be humble, my brother…be humble.” Clearly you are saying that I am not humble. And I will not argue your point. No one can see into my heart. No one can truly know my thoughts and feelings and motivations. No one can truly know which (if any) of my actions are guided by humility or arrogance. Clearly to many I may come across as arrogant. But any perception is just a perception, not an insight into my or anyone else’s soul. Think of me what you will, although I will caution that most eastern philosophies might suggest that I am simply a reflection of you, or as we said in the third grade: I’m rubber and you’re glue….

  3. Lourens Naude February 22nd, 2008

    Great book … Blink.

    I’d make the following bold statement :

    Ability to produce shippable code is directly relative to the level of fear a developer / programmer has.

    • Most don’t write tests for fear of failure.
    • Most don’t even bother evaluating multiple paths to a cleaner solution for fear of exceeding specs OR having to do more work.
    • Fear kills intuition.

    Wisdom positions you for a better informed decision.Some coin in ‘luck’.Luck is simply the ability to trust one’s gut feeling in an expert domain.

    You can only get wise through failing through multiple iterations …

Leave a Reply