Software Developer

Without smart software, the Pragmatic Bookshelf wouldn’t exist. Everything we do relies on it, from book preparation, through book production, to the online store, fulfillment, royalty payments, and administration. We’re looking for someone really smart to take on the challenge of supporting and enhancing our systems.

You’ll be working from your home. You’ll report to Dave Thomas, but you’ll also be working with other senior staff both to help resolve issues and to work on enhancements to our systems.

Some Background

We have three major areas of software.

  • our online Rails applications. We have two public-facing apps (the store at pragprog.com and the discussion forums at fora.pragprog.com). We also have an administration application (which is probably the largest of the three)
  • our “gerbils”—the EC2-based servers that create personalized eBooks for our customers, storing the resulting files in S3
  • our book development and production software. This is largely XSLT based, but is supported by a number of utility programs and Rake tasks. The XSLT is not part of the Software Developer role, but maintaining the other software is.

All but a few hundred lines of our software is written in Ruby.

What The Job is Like

Your morning’s email contains three messages needing your attention.

The first is from support. Overnight two people complained that their Paypal transactions could not be completed. You look through the server logs and discover what looks like a temporary connectivity issue in the wee hours. You verify that Paypal transactions are currently working, then reply to support explaining what happened and asking them to keep an eye on transactions today. You also raise a low-priority support ticket with the hosting provider, asking them to verify the network.

The second is from David, who handles the formatting side of book production. An author has asked us to support syntax highlighting for F#. You do a quick search to see if there’s already a Coderay F# scanner. Not finding one, you add this task to Highrise, and email back saying it’ll be done by the end of tomorrow.

The last email is from Janet. We’ll be pushing an update to the Rails book today, so she suggests that we should bring up a few more gerbil instances; the gerbils are the machines that do the per-customer personalization of the ebooks. You do a quick query to see how many books will be generated, and decide that 12 extra servers will get the job done in about 3 hours, so you start up the extra instances. You also add a low priority task to your Highrise queue to investigate how easy it would be to have these instances start automatically if the stamp queue starts to build—after all, the more you automate, the more time you’ll have to spend doing new development.

Having cleared your plate (for now), you move over to working on the new delivery feature that you and Dave specced out. You’re looking forward to this, both because it’s a fairly interesting technical challenge, and also because you know that once it’s working it is going to be a big deal for customers who read on mobile devices. You finished a quick prototype yesterday, so today you throw it away and start on the code (and tests) for the initial release. The plan is to deploy basic support this week sometime, gather feedback over a few days, then add features based on what customer say.

Just after lunch another email comes in from support. It looks like the Paypal issue is back, so you ssh in to one of the servers and confirm there’s a connectivity issue. You escalate your previous support request to urgent status and temporarily disable the checkout side of store. You email support and Dave to let them know. The hosting company gets back to you a few minutes later—they found and fixed a configuration issue. You verify that connectivity is back, then reenable the store and let support know. While you’re messing with servers, you check that the gerbil queue is fairly empty and shut down the extra gerbil machines.

By the end of the day you have a good chunk of the new distribution system coded. You drop Dave an email with an update, and break for the day. Tomorrow you’ll knock out the F# scanner in the morning, then get back to the distribution code.

How The Role Will Develop

Initially you’ll be working with Dave Thomas, learning how everything works. Longer term, you’ll be largely self directed.

Initially, the tasks you take on will be smaller and fairly well defined. Longer term, the requirements you get will be more general, and you’ll interpret them to produce great solutions that work in the context of our technologies and our business. You’ll also generate tasks on your own initiative as you identify opportunities.

As we grow, we may need to take on more developers. You’ll have the opportunity to be responsible for these folks if you want.

Technical Qualifications

You will:

  • be fluent in Ruby and Rails, and comfortable using Git and Subversion
  • know how to manage groups of remote servers. Experience with Puppet and Nagios is a plus (but not a requirement)
  • be happy with HTML, XML, and CSS
  • be experienced in Unix system administration
  • have experience designing, implementing, and deploying large Rails applications with multiple cooperating components

Nontechnical Qualifications

You will:

  • be a US resident
  • be happy to work from your home
  • feel comfortable interacting with both technical and nontechnical people

We’re looking for someone who sees their role as being bigger than just programming. You’ll also get to know our business and look for opportunities to use your skills to make things cooler for our readers.

It also helps to have a sense of humor.

Job and Benefits

  • You will be a full-time employee, nominally working 40 hours per week. You can take 4 weeks of combined vacation and sick leave a year—we ask that you give us at least 4 week notice of vacation time.
  • You’ll work from your own home, and provide your own computer and network connection
  • Very occasional travel will be required
  • We do not currently offer either health care or a pension plan—the position’s salary is higher than the normal to reflect this.

How To Apply

Send us a .tgz containing:

  • a cover letter explaining why you’re right for us
  • a brief resume. Don’t bother with all the “my goals are” stuff—just give us a list of your achievements and your experience
  • either:
    • a Coderay scanner that supports F# syntax highlighting, or
    • a short document telling us how you’d address this design challenge

Send your submission to jobs@pragprog.com by October 14. Include [Developer] in the subject line. If we like what we see, we’ll interview you by phone and possibly in person. If it looks like you’re the right person, we’ll require two recent references.