Inspired by the interviews in the Paris Review and Bomb magazine, "The Questions" in Sports Illustrated, and the regular interviews on the blogs of Tom Peters and Guy Kawasaki, Comment has asked a diverse group of mentors for their stories.

Comment: How would you explain what you do to an interested nine-year-old child?

BJ: I teach computers how to work for us.

Comment: What first drew you to this work?

BJ: The recommendation of a friend. I don't have any formal training as a programmer, and I spent five years after college using my philosophy degree to run a rock-climbing gym. He suggested that programming can dovetail nicely with philosophy (specifically the study of logic), and gave me a copy of Programming Perl. I've always enjoyed self-directed study, so six months and countless books later I was offered my first job in the industry by another self-taught programmer.

"...another self-taught programmer taught me that there was nothing I could not learn on my own."
—Brian Janaszek

Comment: As a novice, what were your most valuable learning experiences?

BJ: Making mistakes. You can only learn better methods by screwing up. Also, mentoring below another self-taught programmer taught me that there was nothing I could not learn on my own.

Comment: What is the best advice you've ever been given?

BJ: Work iteratively, using proof of concepts. It's far better to waste a day hacking together a practical test of a solution, rather than weeks designing a project around something that might not work. And, don't be afraid to make mistakes (in the right circumstances)—novel solutions won't be perfect the first time.

Comment: From what sources do you draw inspiration for your work?

BJ: Ultimately, I want my work to be glorifying to God. That is, in something like programming, it can be hard to discern what exactly a pretty high standard entails. At the lowest level, that means my work should always be the best I can produce, but there are other issues to consider as well. How is the program to be used? Are the work and culture of the company in any way a hindrance to my faith? More practically, the books The Pragmatic Programmer and The Practice of Programming have influenced my attitude toward my craft—beginning with a requirement and producing working, maintainable code that delights the user (to paraphrase The Pragmatic Programmer).

Comment: What rituals and habits structure your workday?

BJ: My commute on my bicycle. It gives me an opportunity to think through work issues, and it provides a transition between home and work. I also try to take a stroll during lunch to stretch my legs and clear my head. My actual work time tends to be unstructured, or at least unplanned.

"My actual work time tends to be unstructured, or at least unplanned."
—Brian Janaszek

Comment: What are your favorite tools?

BJ: There are a few constants, regardless of the project: a good pen and notebook, and Google. I still prefer to use a notebook to sketch designs and take notes, and even write code snippets. And a day doesn't pass that I don't consult Google—there is no reason to reinvent the wheel for a particular programming problem.

Other tools vary depending on the project. I prefer to find the best tool for a given task. Currently, I use PSPad Editor for writing code, and rely heavily on two Firefox extensions to debug web code: the Web Developer toolbar and Firebug (for debugging Javascript). I don't have a computer or operating system preference—whatever is best for the job, or, more appropriately, whatever my employer gives me. Dual monitors are kinda nice, though.

Comment: Tell us about a project that delighted you.

BJ: Several years ago I was working as a consultant with my original mentor (see the response above), and we were building a document management system for one of his clients. I was tasked with developing a solution for capturing signatures for the company's shipping and receiving department. This required that I learn their particular programming platform (a language I was not at all familiar with), assess the various hardware available for capturing a signature electronically, and develop the component to integrate this system with the larger solution.

It was challenging, and we were working against the ever-changing demands of our client, but we delivered the product to them on time, and four years later, they are still using it.

Comment: How do you plan your work?

BJ: It depends on the task. My current job is split between designing bits of the larger product and implementing existing designs. If I am designing, I typically try to identify the most basic units of information and determine how best to model them programmatically. If I am implementing (that is, coding) an existing design, again, I determine the basic functional bits and work outward. Modularity is important—I want to accomplish the given task with the minimal amount of code, so I am always aware of finding ways to reuse code.

Comment: How does your work connect to other aspects of your life?

BJ: In many ways, I try very hard to keep work segmented from the rest of my life. More important to what pays the bills is my larger work as a husband and a father. That does not mean I am not committed to what I do "from nine to five" (and that I do not see myself glorifying God through it), but I see my career as only a part of life, not the key component to it.