Today’s interview is with Lobsters user Peter Harkins. He has a weblog at push.cx.

0. Introduce yourself, describe what you do for work and how long you’ve been at it.

I’m Peter Harkins, a web developer.

When I was a kid I learned Logo but didn’t think anything of it. A year or two later I saw another student making a game in Hypercard and was instantly hooked by the prospect of making interactive programs. I’m still programming because I love making things that people use, whether that’s for entertainment, learning, or to do things faster or better.

I didn’t know any other programmers or think to find any online for the first ten years I was writing code. This slowed down how quickly I could figure things out, but I got enough practice by constantly writing programs that it worked out fine. I got good at debugging (because otherwise I’d have given up) and evaluating my own work, and luckily avoided developing any weird habits.

The second decade went a lot better, as I learned from local meetups, had access to better libraries, found online communities, minored in Computer Science, and began professional work. I’m a bit into the third and I’m still enthusiastic about learning more and building new things.

A few of my more fun projects: I’ve rewritten the code running the .pro registry (don’t worry, nobody’s ever heard of it), built a site for tabletop gamers to meet, made ASCII art out of Unicode, covered the U.S. 2008 election season, and alphabetized the Bible.

Currently I’m the first of ten employees at DevMynd, a small web/mobile consultancy in Chicago. I work part-time, three days per week, and for the first time I’m not burning out on a job after a year or so. I’ve really enjoyed helping create a company culture. At my current client I’m running a training program to give brand new developers a roadmap to becoming effective.

1. What is your work/computing environment like?

I used to have a dual-monitor battlestation, but I spent 2011 wandering the U.S. and Canada with just a backpack and that necessitated lightening my load a bit. On that trip I switched from a 15" laptop to a 13" netbook and I’ve stayed there since. Modern computers are so powerful that I’ve been buying based on weight, keyboard feel, and screen quality for a few years. I like how easily I can take my computer between rooms and buildings, whether that’s going to the office, a coffee shop, or a friend’s home.

The most important thing about my working environment is that I’m not static. When at home or the office (or wherever I can jury-rig something) I’ve been using standing desks for the last six years and my body is a lot happier for it. When I’m doing serious work in a distraction-free environment, I can hurt myself by sitting unmoving for hours. I’ve had to re-introduce distractions like an alarm clock for meal times. :)

After lots of experimentation, I’ve found my hands are happiest with a low-profile keyboard with scissor-switch keys, like Apple’s current offerings. I also use a cheap wireless mouse for gaming (almost all of my regular use is solely keyboard-driven).

I live in Chicago, so I’m stuck with mediocre quality cable from the local duopoly.

2. What software are you most often using?

Vim, far and away. When I got into Linux in the mid-90s the advice was to choose between vim and emacs, and I chose the former for ubiquity. Now a lot of my software choices reflect that: pentadactyl in Firefox, set -o vi in bash, vim-mode in irssi, etc. Using that muscle memory everywhere has been a win. Here’s my .vimrc.

I’ve run a Linux desktop about fifteen years (BeOS for a few before then – anyone other fans out there?). I browse with Firefox, IM with Psi. I’m mildly dissatisfied with bash and roxterm, and am considering a move to zsh and some new terminal (suggestions welcome).

The most important thing about customizing my environment has been doing it slowly, adding a plugin or tweaking a configuration only two or three times a month. That’s about as fast as I can learn new shortcuts and internalize new commands; any faster and it goes unused or I flail about with unfamiliar config. I try to minimize changes and flashy tools because any attention I’m spending there is a distraction from what I want to be working on.

As an example, I surveyed window managers when I started using Linux. I used Blackbox with a theme I stripped down to make as plain as possible. That moved over to Fluxbox, a better-supported fork. My desktop barely changed appearance for 12 years. I moved to Awesome when I started using a netbook because I realized I had one or two windows filling the desktop almost all the time. I ported as much as I could from the Fluxbox config, so it looks very similar and I still have almost all of the same keyboard shortcuts. The window manager is something that I interact with hundreds of times per day and mediates everything I do. I want it to be really plain and unchanging.

3. What’s an interesting project you’ve been working on recently?

The Well-Sorted Version (on Lobste.rs). Now that it’s done, the thing that interests me is how it felt to be so dedicated to a project.

I tinkered with it on and off for a few years, and then made it my nights-and-weekends project for all of 2012 and the first two months of 2013. I spent many hundreds of hours on it. When I emailed the final copy to the printer I felt lost because it was the first time I didn’t have a to-do list telling me to tweak some typesetting, proofread another chapter, improve the program to generate it.

I committed to it to get my mind off the end of a terrible relationship, in large part after hearing a speech by Neil Gaiman about sublimating the difficulties of life into making good art. (20m original video, 2,900 word transcript, or brief comic version.) I was in really bad shape and it helped a lot to lose myself in a project that was bigger than myself.

I’ve also had a lot of trouble with procrastination over the years. I’ve read every book, tried every strategy, and I wouldn’t have believed I could finish a multi-year solo project until I did. I can’t say anything that suddenly “clicked”, I’ve just steadily practiced using to-do lists, recognizing when I flip over to Reddit because I’ve hit a stumbling block, planning when to take time off instead of putting it off until I’m exhausted and then feeling guilty about it, and working on each small part of the project until it’s really done rather than jumping into the most interesting bits first.

Hopefully these skills will translate to being productive on the next thing (updating and improving NearbyGamers after I finish my vacation this week.

4. What is something new you’ve used or integrated into your work that has made a positive impact?

Trello. I’ve introduced it to a few workplaces and folks actually use it for planning work and tracking bugs and it quickly supplants other tools because people enjoy working with the cards and can immediately get a feel for current status and progress.

I’ve also found it really useful in my personal projects. I think I got the idea from this blog post. My workflow of cards floating left-to-right is the same, though my lists are ‘Big Picture’ (a list of projects, mostly as a key for colors), ‘Later’ for 1-2 months of planning, ‘This Week’, ‘Today’, ‘Blocked’ for things I’m waiting to hear back about, and ‘Done This Month’. I love watching the ‘Done’ list fill up and looking over it at the end of the month.

5. What are your debugging strategies? Do you prefer formal debugging tools or are you a printf-style person?

Pardon the long answer, I’ve been thinking about how to explain this to my students. :)

My debugging strategy is probably influenced by the fact that my mom was a research scientist. When I’m working on a bug I go through the typical steps of finding steps to reproduction, minimizing my test case, finding the root cause, fixing, and verifying the fix. But I add a lot of thinking before each step and afterwards.

Before each step, I stop and think deliberately about what I’m trying to do and why. It sounds silly when I say it that way, but I see a lot of developers who don’t seem to, or are only testing to see if one specific thing is the source of the fault.

I think of debugging as scientific research: given this natural system, who do we understand this unexpected property? I generate hypothesis and think of what tests I can do that will differentiate between them. Each step of the way I’m running an experiment to learn the most.

Working on a web stack means there are a lot of layers for things to go wrong in (especially due to subtle interactions between layers). My early tests will often be to look at HTML as it leaves the server or arrives at the client so I can learn the gross direction I should be looking in. The sign of a good test test is that I’ll learn things whatever way the test comes out. “If the HTML has all the list elements, I know the bug is in the JavaScript stack. If not, it’s on the server. … OK, it didn’t have them all, so I know it’s server-side. I’ll run the db query by hand, that’ll tell me if the database is populated wrong or if the web stack is losing them along the way.” I’m not guessing at what could be wrong, I’m bisecting the problem.

I’ve started thinking about these tests in an information theory sense, each is a bayesian update that should minimize the posterior entropy. Unfortunately my math background is pretty weak, I’ve only learned fairly recently that these are the formal terms for what I’ve been doing intuitively. If anyone has thought along these lines or has good introductions to bayesian updating (yes, I’ve seen Yudkowsky) and information theory, please share.

I also think a lot after fixing a bug. I stop and ponder how I could have found this bug faster. Did I start in the wrong place? Did I ignore clues or fixate on the wrong ones? Is there a tool I could have used to find something better? Every bug I hunt is an experiment in learning more about bug hunting. :)

I’ve gone on about my thought process enough that I clearly think of debugging as a mental exercise rather than being about setup and tools. I do have favorite tools, like Firebug, curl, pry, the Rails console, and various database command-line clients. I’ve only started using debuggers in the last year or two. They’re certainly useful and make some of my old printf experiments faster, but I don’t feel like I’m learning anything about development when I use them and I’m constantly tempted to get stuck tinkering in one spot instead of following the efficient mental process I’ve slowly learned.