The Two Kinds of Programmers

In my time as a developer, and now managing a team of developers, I have come to realize that there are two kinds of programmers: the Journeyman and the Craftsman. These terms aren’t mine - I’ve seen them used other places - but they describe the developers I’ve worked with pretty well.

The Journeyman

…knows one programming language.

…knows one operating system.

…can’t be bothered to learn something on their own.

…doesn’t know anything about the operating system or hardware their applications run on: “Someone else takes care of that”.

…never masters his tools. “I know my way around my IDE, that’s good enough”

…doesn’t refactor: “It’s ugly, but it works. Leave it alone!”

…only learns about the part of the system they are working on. No need to learn the rest of the system: “That’s not my job”.

…doesn’t want to take on an unfamiliar technology: “I haven’t had any training on x”.

The Craftsman

…knows a handful of programming languages, and is always on the lookout for the next one he should learn. He knows that learning any new language will stretch his mind and make him a better programmer in the language he uses day to day.

…devotes time to learning about new technologies, and helps to make others aware of them.

…understands the platform and operating system his applications run on, because he knows that’s the only way to diagnose many problems.

…masters his tools. He can perform magic in his chosen editor, and is always looking for ways to make himself more efficient.

…rarely passes up an opportunity to broaden his knowledge of the system he is working on.

…is always willing to take on something he’s unfamiliar with. He can pick up most things pretty easily, and enjoys the challenge of learning something new.

One craftsman is worth three or four journeymen. Easily.

It’s the journeymen whose jobs often end up moving overseas (and rightfully so, they add little, if any, value).

The longer I manage development projects, the more I value the craftsmen I have around me.

My Favorite New Site: Tripit

I’d heard (first from Joel Spolsky, I believe) about a cool new travel planning site called Tripit. I’m making arrangements for a trip to St. Louis later this month, and so I thought this would be a good opportunity to try it out. To say the least, I’m impressed.

The first thing that I noticed was the registration process: there isn’t one. All you have to do is take any travel-related email (hotel confirmation, airline itinerary, etc) and forward it to plans@tripit.com. If the email account you sent it from isn’t already registered with Tripit, they create an account for you and send you your registration details. Most sites would have you create an account first, filling out a lengthy form before you could use it. Tripit’s strategy on this is brilliant as it removes all barriers to entry to their service, making it completely painless.

Tripit then takes that email and creates an itinerary. I emailed it a hotel confirmation, and it was able to extract out the hotel name, arrival and departure dates, the city I was staying in and more. It builds a nice itinerary out of this data, and adds some useful information to it like weather and maps.

Tripit also allows you to collaborate, sharing your trip information with others in your party. There’s also a social networking component. If you add contacts who also use Tripit, you can see who else might be close to you on an upcoming trip. I don’t really travel enough to probably get much use out of that, but I can certainly imagine that it will be useful to a lot of people.

One other nice feature is that it can publish your itinerary in iCalendar format, for consumption by Google Calendar, Outlook 2007, or Apple’s ICal. It also appears to have good support for mobile devices, though I haven’t had a chance to try that out. One other nerdy item to note is that they’ve marked up many of their pages with Microformats.

All in all, Tripit is an impressive service so far. I would definitely recommend giving it a try - it’s as easy as it gets.

Links for 4/2

A list of random and assorted things I have found lately

New York Times blog on open source technology at the Times

“A blog about open source technology at The New York Times, written by and primarily for developers. This includes our own projects, our work with open-source technologies at nytimes.com, and other interesting topics in the open source and Web 2.0 worlds.”

There are a lot of nice posts in there, including one on how they used EC2 to convert their archives to PDF.

Desert Rails Plugin

Desert is a component framework for Rails that allows you to seamlessly define in your plugins: \* Models \* Controllers \* Views \* Helpers \* Routes \* Migrations \* Plugin Dependencies

Five Runs Interviews

Five Runs is conducting a series of 5-question interviews. So far they have interviewed Chad Fowler, Michael Cote and Peter Cooper.

Arc is Released

Paul Graham has released Arc, his long-awaited Lisp dialect.

Arc is designed above all for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that’s what we’ve aimed for. This is a medium for sketching software.

How to be a Great Dad - 12 Awesome Tips | Zen Habits

’nuff said.

Mac Question: What Books Should I Buy?

I’ve owned the Macbook Pro for a little while now, and am getting comfortable with OS X. I think it’s time to dig a little deeper though, so I’m going to buy a book or two.

I’m a long time computer user, and have a lot of *NIX experience, so I’m not looking for something too basic. I’d like something that will teach me the ins and outs of the whole operating system, and let me go from being “comfortable” to “power user”. I’m leaning towards Mac OS X Leopard: The Missing Manual, but I thought I would ask here if anyone else has any other recommendations.

Is SwitchPipe the Solution for Rails Shared Hosting?

Peter Cooper (who I interviewed recently ) has just announced SwitchPipe, which aims to make deploying and hosting Rails (and other frameworks, such as Django) applications easy. From the site:

Introduction / Overview\ SwitchPipe is a proof of concept "Web application server" developed in Ruby. More accurately, it's a Web application process manager and request dispatcher / proxy. Backend HTTP-speaking applications (Web applications) do not run directly within SwitchPipe, but are loaded into their own processes making SwitchPipe language and framework agnostic.\ SwitchPipe takes control of, and manages, the backend application processes, including loading and proxying to multiple instances of each application in a round-robin style configuration. As an administrator, you can define the maximum number of backend processes to run for each app, along with other settings so that you do not exceeded preferred resource limits. SwitchPipe quickly removes processes that "break" or otherwise outlive their welcome. For example, you can let SwitchPipe kill any backend processes that have not been accessed for, say, 20 seconds. This makes hosting many multiple Rails applications, for example, a quick and non-memory demanding process, ideal for shared hosting environments.\ ...\ SwitchPipe's goal is to be:

* super easy to configure
* the easiest way to deploy multiple HTTP-talking backend applications
* painless in terms of management; no hand-holding of different applications is needed
* a permanent daemon that can handle configuration changes in backend apps “on the fly”
* a reliable solution on Linux and OS/X (and anything POSIX compatible, ideally)

Links for 1/29/08

A list of random and assorted things I have found lately

New York Times blog on open source technology at the Times

“A blog about open source technology at The New York Times, written by and primarily for developers. This includes our own projects, our work with open-source technologies at nytimes.com, and other interesting topics in the open source and Web 2.0 worlds.”

There are a lot of nice posts in there, including one on how they used EC2 to convert their archives to PDF.

Desert Rails Plugin

Desert is a component framework for Rails that allows you to seamlessly define in your plugins: \* Models \* Controllers \* Views \* Helpers \* Routes \* Migrations \* Plugin Dependencies

Five Runs Interviews

Five Runs is conducting a series of 5-question interviews. So far they have interviewed Chad Fowler, Michael Cote and Peter Cooper.

Arc is Released

Paul Graham has released Arc, his long-awaited Lisp dialect.

Arc is designed above all for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that’s what we’ve aimed for. This is a medium for sketching software.

Monday Question: What Is Your Text Editor, and Why?

Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives

The text editor is the programmer’s main tool. The best programmers I know are masters of their chosen editor, whatever that might be. Knowing how to be productive with your editor can make the difference between a good developer and a great developer.

So today, I’m asking you to share with us what your favorite text editor is and why.

My editor of choice is Emacs. It’s the first “real” editor that I ever bothered to learn well. I started learning it right after reading The Pragmatic Programmer for the first time. I have a love/hate relationship with Emacs. It’s an amazingly powerful editor - there’s very little that it can’t do. Unfortunately, it’s as ugly as they come and a pain to customize. Lisp is cool in the same sense that Latin is cool. Beautiful language, but hardly anyone speaks it. I had hoped that when I made the move to OS X, I would switch to TextMate. I tried it, and even bought the Peepcode screencast on Textmate. In the end though, I couldn’t give up Emacs. It has too many features that I rely on that Textmate just doesn’t have, like split buffer windows and dired mode.

As always, post your answer in the comments below.

Monday Question: What Music Do You Code By?

Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives

Most people, it seems, listen to music while they work. Whether it’s to aid concentration or drown out their coworkers, I see most people do it. So today’s question is:

What music do you prefer to code/design/whatever by?

I have very diverse musical tastes and listen to just about everything, but I find that lyrics are distracting when I need to concentrate. So I prefer Jazz like Miles Davis and John Coltrane, or classical like Yo Yo Ma when I need to focus.

Monday Question: What Is Your Development Machine?

Monday Questions is a recurring series on The Curiosity Project. For more questions like this, please visit the archives

As previously noted I recently switched my development environment from a Linux laptop to a Mac.

This Monday’s Question is: What is your development machine?

Tell us your OS, hardware specs, etc.

Interview: Geoffrey Grosenbach on PeepCode, Entrepreneurship, and Making Book Publishing Easier

This article is the second in a series of interviews that I will be conducting over the next few months. For the other interviews, please visit the archives

Thanks for agreeing to do this interview. Can you start by telling everyone a little bit about yourself?

I live in Seattle, home of the world’s most pretentious Ruby brigade. I’ve been doing professional development for almost 10 years.

Do you consider yourself a developer who happens to be an entrepreneur, or is it the other way around?

Definitely a developer first. I love solving problems and reading about other people’s approaches to software development. However, I’ve worked for many startups and it was probably inevitable that I would eventually ask the question “Could I run a business of my own?”

I had wanted to start my own business since high school but didn’t pursue it until recently. In 2002, I wrote a shareware RSS reader and started selling it for $15 online. Cory Doctorow even bought a copy and gave me some feedback, which I unfortunately never implemented.

I only sold a couple hundred copies, but it was a good lesson in developing a product, getting feedback, and advertising. One lesson I should have learned is that there are no overnight successes. Even a good idea often needs 6 months or a year of development and promotion to get off the ground. Unfortunately, I promoted the RSS reader for only a few months and then let it slowly die.

I also started an online todo list that has accidentally resulted in almost 10,000 signups. I haven’t figured out what to do with it yet, but it taught me a lot about deploying Rails applications.

When did you first discover Ruby on Rails?

I started working with it in January, 2005. There weren’t any books, so I started by reading the entire online documentation, method by method. Everything just seemed to fit together and I loved the way that common web development tasks were wrapped up into simple methods.

I still recommend reading through the entire API documentation. It’s the most thorough source available.

What was it about Rails that appealed to you?

At first, I appreciated the high-level completeness of the API. Most of the common things that a web developer would need to do were all there, from database relationship definition to form building. While reading through the documentation, I kept thinking “Yes…I could use that feature!” or “That’s so useful…why didn’t I think of that?” I had built my own MVC framework in Perl, but it was a chore to keep it consistent and bug-free. With Rails, I found a framework that was already capable and was also being constantly improved.

Currently, I appreciate the inventiveness of the Ruby community. Most of the software I rely on day to day isn’t part of the Rails framework at all. I use Haml templates exclusively (I hate having to type all those angle brackets and end tags!), Haml’s Sass templates for my CSS, and make_resourceful whenever I need a REST controller.

I received a copy of the Django book earlier this month (which was very well written), but I cringe at the thought of doing web development without Haml. I’ll probably need to write a few demo projects just to become familiar with it.

What does your development toolset look like? (editor, browser, etc)

I have a pretty standard Rails setup with a Mac, TextMate, FireFox with the web developer and FireBug plugins. For everyday browsing, I find Camino to be a bit faster.

I use the tcsh and the standard Apple terminal. MailPlane for email, though I’m probably going to switch back to mutt now that Gmail offers IMAP. I try to reduce distractions, so I run with a solid black desktop picture and the MenuShade utility to hide the menubar. Sometimes I also use Spirited Away to hide background applications.

I’ve got a great desk from Anthro Cart that can be used sitting down or standing up. Plus, there are attachments for all my audio gear, speakers, etc. A comfortable keyboard from TypeMatrix and the Freedom chair.

Do you have any must-have libraries or tools for Ruby?

autotest and rstakeout for running tests or other commands automatically. In addition to the Rails plugins mentioned above, I use memcached and acts_as_state_machine in most of my web applications. The Hodel logger is a must for viewing the real-world performance of a web application.

I’ve been experimenting with dtrace and hope to learn how to use it.

You started PeepCode several years ago. What drove you to do that?

I had wanted to do something with teaching and digital distribution. I read many books and they are often out of date by the time they hit the shelf. I saw how popular the original 10-minute Rails blog screencast was and I also noticed that many other people were doing screencasts. However, they often had distracting quirks, such as being shot fullscreen and delivered at gigantic resolutions. So I figured that I could do a really polished screencast that would be more informative than many books and cover timely topics. It started with one and has turned into a full time business not only for me, but also for a few other authors who are writing PDF books.

The PeepCode screencasts are very high quality. What tools do you use to put them together?

I’m currently using Final Cut Pro for editing and iShowU for screen capture. I also use OmniGraffle for diagrams and other utilities such as XScope and OmniDazzle.
In fact, I’m working on a screencast right now that shows how I create a screencast.

How long does it take to create one screencast?

Technically, it only takes about a week to film, dub, edit, and release. But often, I’ll do a few weeks of research about a new topic, or I’ll re-film a screencast after receiving feedback. For the git screencast, I created an entire hour-long screencast and then started again from scratch after receiving technical feedback from Junio Hamano, the maintainer of git.

Peepcode originally started as screencasts, but recently you’ve started branching out into publishing. What drove you to do that?

The information that developers need is increasingly time sensitive. I don’t scale very well as a single author, so I was looking for ways to work with other authors to produce relevant content on topics that developers want to learn about. PDFs are a great way to do that, and are even preferred by developers because of the ability to search the text or copy and paste code snippets.
A printed book usually takes 9 months or more to write, and authors often end up exhausted, discouraged, and poorly compensated.

So I built a system that works with standard Textile-formatted text. So far, authors have responded very favorably and it has even made translation very easy. I have a half-dozen authors working on some great topics that will be released over the next few months.

There are many important topics that aren’t very well documented. I want to make those topics accessible to developers at an affordable price.

Originally, PeepCode focused solely on Rails, but with the latest screencast on the Git SCM, you seem to be branching out a bit. Was this a one-time occurance, or will we be seeing more screencasts like this?

Rails developers have supported my business from the beginning, so I’ll definitely continue to publish Rails-related content.
But I hope to branch out into other topics, especially where it’s of interest to the Rails community as well as the greater web development community. The Prototype.js Javascript screencasts were quite popular but didn’t require knowledge of Ruby code. I’m hoping to do a series on CSS that will be useful to developers, no matter what framework they are using.

Your website says you are no longer doing consulting work, does that mean you are doing PeepCode full time?

I’ve been fortunate to have been working on PeepCode full-time since May, 2007. It was a big decision to make, but it has definitely been the right decision. Overall business has more than doubled since then and I’ve been able to collaborate with many intelligent developers.

The other thing you are well known for is the Ruby on Rails Podcast. You have been doing that for some time now, but I seem to recall that you weren’t the original host of that podcast. How did you come to be the voice of Ruby on Rails?

Scott Barron started it, thanks to encouragement from David Heinemeier Hansson. I contributed a few shaky interviews starting in July of 2005 and have done almost all of the subsequent 60+ shows.

I just bought a ticket to San Francisco for the sole purpose of interviewing Rails startups for the podcast. It will be right around the time of the MacWorld expo, and I hope to post the first interview almost as soon as it is recorded.

You seem to have a lot of irons in the fire, is there anything coming that you can talk about?

Right now it’s all PeepCode! There will be a book on ActiveMerchant that I’m excited to see published this spring. I also have an idea for a series that will compare Rails to other popular web frameworks.