I’ve recently recognized a nasty coding habit I seem to be developing. It’s been developing for a few months now, and while I kick myself every time I discover myself doing it, the habit itself is remarkably hard to kick.
I’ve been working on enhancing our internal Queen Bee application, this time making it so we can more easily track the performance of our Job and Gig boards. The change itself is pretty straightforward, but I found that when it came time to build the actual UI, I got stuck.
I kept chasing my tail. I’d look at the existing reporting UI that we have for our other products, and then I’d start thinking what needed to change to adapt it for the Jobs/Gigs reports. That would then lead me to think about potential refactorings in the code needed to support the (hypothetical) UI changes. Thinking about the code refactorings would lead me back to the UI, where I would think some more about the visual impact of the code refactorings, and so I would go, loop after loop, ad nauseam.
It’s ironic that, even after nearly 4 years of drinking the Getting Real message almost every day, I’d get stuck in such a trap, because the solution really is to just stop pretending and make something. In my case, I had to sit down and just mock up the page, throw together some HTML with fake data in it, and see what it looked like. And it turned out that I didn’t need to change the existing UI or code much at all—the new stuff was actually independent enough that it stood almost completely on its own. Oh, the bitter, bitter irony! I had wasted almost two days worrying about a non-issue.
So, if you ever catch yourself playing mind games with your code, just stop and make something. Pretending is poison. Stop drinking it!
Cory
on 21 Nov 08For me, the solution to this infinite feedback loop is to use paper and draw something. Draw the interface you want. Then write code to make it happen.
The first few times you do this, you will in fact have problems with your UI that only get noticed when you try to write the code. You will have to revise some small part of your UI until it reflects reality. This is far preferable to doing lots of fruitless thought experiments.
But doing this exercise just a few times will give you a very firm grasp on how to design user interfaces. The practice is worthwhile, and you end up with the skill, the ability, to see the code problems in the interface design as you draw the interface and not afterward, leading to both better interfaces and better code.
Grant
on 21 Nov 08I don’t know if it’s ironic, so much as human. I think there’s a bit of a barrier we hit whenever we’re presented with a new task. I often find myself in the situation where I need to do something and I know that the very act of getting started, putting some code down or ink on the page will break that barrier, but still I often avoid it. Thinking deep about stuff is hard. We do our best work that way, but I think it’s natural to avoid doing it.
Justin
on 21 Nov 08“I had wasted almost two days worrying about a non-issue.”
Does your employer know about this? Seriously, though, good insight.
brandon
on 21 Nov 08“loop after loop, ad nauseam”
I was battling this cycle just a few days ago. It’s amazing how difficult a task can be until you dive in and let it absorb you. Just take the plunge. :)
GeeIWonder
on 21 Nov 08Great story, and again, I can’t credit you enough for putting your self-criticisms on display for all to see.
Quick question though, just out of curiosity—is it built yet? Did you re-encounter any problems you anticipated or similar to those you had anticipated?
Todd Zaki Warfel
on 21 Nov 08That’s exactly why we start all of our designs on paper. We’ve created these 8 up sketch boards that have 8 small screens or tiles on each 8 1/2×11 piece of paper. I just grab a pen and start drawing on paper first. It’s fast, cheap, and easy to correct, or strike through and move to another tile.
Once I get the design 70-80% figured out, I move into our XHTML/CSS/AJAX prototyping framework and start building it. The rest is figured out along the way.
But it’s really important to just plan a little and prototype the rest.
Duff OMelia
on 21 Nov 08I’ve done this as well. Thanks for posting this lesson Jamis. I think this will help me recognize the issue earlier next time.
Keith
on 21 Nov 08I keep a big stack of paper on my desk with my trusty colored pencils all within easy grasp.
Every problem has a quick solution when you start sketching it. Sometimes just drawing a box and starting without plan, but starting, helps me make up my mind.
You’re right Jamis…doing is way better than thinking about doing. Smart people, like the ones reading this blog, will see all the layers of a problem and get tripped up. Actually solving the problem a lot of times is much simpler!
zeynel
on 21 Nov 08Great insight. I catch myself doing this as well. But how is pretending different than laziness or mental inertia? When a job perceived as simple (“the change itself pretty straightforward”) goes wrong we usually feel stingy about investing more time on it. So we look for shortcuts.
Bob
on 21 Nov 08Jamis, you’ve described my current programming habits to a “T” and I thank you for all of the insight you share with the greater community. It is one of the things I most admire about 37signals, and why I keep on coming back to read what you guys have to say.
Right now, when I catch myself doing what you described, I usually stop my brain dead in its tracks by deciding it is time to do something else if for no other reason than to get my brain to reboot properly for once. After that, I tell myself just to put something out there and then get to work.
Once again, thanks for the post.
Saverio Mondelli
on 21 Nov 08I often solve this problem by jumping into Fireworks (vectors w/ some bitmap abilities make it brilliant for this type of work) and begin putting together the draft that way. Once you “see it”, it’s easier to understand where you want get to.
Still, the problem I always have is that I still play some mind games before actually taking the app from canvas to code. To fight that problem, like you said, you just need to dive in and start writing code, whether it works or not.
Tim
on 21 Nov 08Spot on!
You definitely nailed it.
Nivi
on 21 Nov 08Pair programming is a great way to stay true to your practices whether they’re Getting Real or XP or whatever.
Jamis
on 21 Nov 08@GeeIWonder, re: “is it built yet?” No, but almost. And, no, I haven’t actually hit any of the issues I imagined hitting. The going really has been quite smooth since realizing how it needed to look on the front end.
James D Kirk
on 21 Nov 08Worrying about code, worrying about hot dogs, worrying about life. Silly, yeah, but some of us really like hot dogs (turkey or chicken that is ;) ). Funny thing about this, like @Grant indicated above, this must be human. For instance, I just love to travel; whether it be long road trips in the car (when gas is below $7 a gallon) or driving to the PHX airport and flying off somewhere. Strange thing the past few years (possibly due to 9/11? Not sure; ask my therapist, I will) is that I just abhor getting ready to leave. Don’t like to pack. Don’t like to think about packing. Will stay up WAY too late watching a movie/TV, even, gasp, reading a book.
In the end, I get about 3 hours of sleep, get up early, pack for the journey, and leave dog tired. When I do force myself to prepare early, by just doing the packing and going to bed early, I sleep well and am energized for the adventure ahead.
None of this probably applies to this thread, but it was my first reaction. Great weekend to all!
Doug Adams
on 22 Nov 08I get this anxiety, too. I know exactly where I have to start-as if that’s an acomplishment-but hold off on getting my hands dirty. Forcing myself to dive right in almost always results in getting into the ‘zone’ so I can make what turns out to be quick and simple changes. So, like any anxiety, this can be overcome.
joelfinkle
on 22 Nov 08I don’t find myself spinning, rather I find myself procrastinating: there’s always another piece to improve, enhance, debug, profile… and the trouble spot just churns away in the back of my head.
Usually the problem is that my gut says, “There’s an elegant way to do it, but all I can come up with is the brute force approach, and the brute force approach is work.”
About half the time, there is a clever, elegant way to solve the problem, and giving it time to bubble up will help provide the nice solution.
The other half of the time, I eventually have to take the brute-force approach, that involves a nasty refactor, a new family of classes, adding a fist-full of parameters to a fist-full of routines, and the work gets done.
Was the procrastination well spent? About 85% of the time, because there’s still practical things to do. Other times, I would have been better just plunging in the first time.
springrider
on 22 Nov 08Thanks for share. Right it’s “ad nauseam”, I’ll avoid that too
Joshua Sierles
on 22 Nov 08Definitely a sentiment I share with Jamis. One of the challenges of working remotely is the potential to stew in this pot of uncertainty. In the past, I’ve found an informal review of your approach with a coworker or friend can help put you back on the pragmatic path. I agree with Nivi – this is the most valuable lesson learned from pair programming.
Does anyone do remote pairing?
Jay
on 22 Nov 08Sounds like a discipline problem, rather than not following a methodology.
Dave Flynn
on 22 Nov 08I do exactly the same thing, although I tend to get stuck in normalising databases and sometimes find it hard to even get to coding lol
Cam Caine
on 22 Nov 08OMG I have this same issue so much lately. And it is so true what you said about just getting on with it. Sometimes the failing early is actually just what I needed to figure it out.
Shamus McCahey
on 22 Nov 08Congratulations for reaching the productivity equivalent of the Berlin wall, commonly brought on by object-oriented and obsessively re-factored coding languages, such as Ruby on Rails. When you have to worry how some module is going to interact with all the other purposes it’s going to be re-purposed for, development suffers.
Go procedural PHP or similar for a week. It’ll snap you out of the funk in a jiffy. Start scribbling out procedural code purpose built for only your app, the programmer’s equivalent of a designer grabbing his pen and pad, then move those functions into OOP class methods for modification when needed as the first post-release upgrade; that’s how I snapped out of it this morning. :)
Matt Radel
on 22 Nov 08Hmm…I thought UI always led in 37signals development? Sounds like this is the inverse….
Sam McDonald
on 22 Nov 08I get into the same trap. My solution, git branches. I seriously think that good code versioning is the best defense for this type of a trap.
Nivi
on 23 Nov 08Joshua, The guys at Grockit and Pivotal Labs do remote pairing. They are both “strict” pair programming shops.
Diwant Vaidya
on 24 Nov 08@Keith I do the paper and colored pencils thing too. The more I find that people are as visual as I am, the more excited I become.
@Jamis I wanted to get a game and its engine perfect so I started it and restarted it and restarted it. This problem is sorely present for indie game developers.
Matt B.
on 24 Nov 08Speaking of “nearly 4 years of drinking the Getting Real message”...
My girlfriend is getting ready this morning… staring into the mirror. (She’s gained a little bit of weight – but still beautiful.) She goes, “OMG, this bra doesn’t even fit anymore.”
Without hesitation and with a big smile on my face, I reply, “Hey, scaling issues; that’s a good problem to have.”
SuatE
on 25 Nov 08Sounds like a discipline problem, rather than not following a methodology.
This discussion is closed.