SENIOR SOFTWARE ENGINEER, BLOGLINES

Ask Jeeves, Inc. is seeking qualified candidates for the position of Sr. Software Engineer to work at our Los Gatos location. The Software Engineer will develop and implement a large scale data processing system in a distributed environment, in C++. The development tasks involve all aspects of scaling and improving a high-volume end-user focused web service.

What’s wrong with this job advert? Let’s pick it apart:

  • Senior, but dictated to. They want to hire in expertise, but they’re not willing to hire in expertise (as we will see).
  • Premature choice of technology. We know the task (a large scale data processing system in a distributed environment), and unfortunately the technology is already chosen (C++).
  • Conflation of concerns. “The development tasks involve all aspects of scaling and improving a high-volume, end-user focused web service.” This is a singularly massive undertaking. The implication is they want not just a good developer, but someone who can also build the systems that will run the code as well. Perhaps I’m reading into this point too deeply.

The choice of C++ up front is, I assume, because they already have a(n inadequate) solution in place, written in C++. Or, perhaps, because they think that by writing it in C++, it will be easier for them to hire in someone to help extend the system, or to replace the senior engineer later with someone less expensive when the development work is done.

Either way, they’re confused. The problem here isn’t one of language, but one of paradigm. Developing in a distributed paradigm where you have both performance (must be responsive) and reliability (must not go down) demands is challenging, to say the least. Then, requiring a tool as poor as C++ to do the job, you might as well set the project up for failure.

Granted, someone very talented can work with even the most inadequate of tools and do an amazing job. But I can’t help but wonder: wouldn’t the developer produce safer code, faster, in any of a half-dozen other languages? First and foremost, Erlang comes to mind. Then, perhaps Concurrent ML or a Lisp of some variety. In any of these three cases, you get much cleaner semantics and good performance. In the case of Erlang, I think I should just quote from their FAQ:

  • Telecommunication systems, e.g. controlling a switch
    or converting protocols.

  • Servers for Internet applications, e.g. a
    mail transfer agent, an IMAP-4 server, an HTTP server or a
    WAP Stack.

  • Telecommunication applications, e.g. handling
    mobility in a mobile network or providing unified messaging.

  • Database applications which require soft realtime
    behaviour.

Erlang is good at solving these sorts of problems because
this is the problem domain it was originally designed for.
Stating the above in terms of features:

  • Erlang provides a simple and powerful model
    for error containment and fault tolerance
    (supervised processes).

  • Concurrency and message passing are a fundamental
    to the language. Applications written in Erlang
    are often composed of hundreds or thousands of
    lightweight processes.Context switching between
    Erlang processes is typically one or two orders
    of magnitude cheaper than switching between
    threads in a C program.

  • Writing applications which are made of parts which
    execute on different machines (i.e. distributed
    applications) is easy. Erlang’s distribution
    mechanisms are transparent: programs need not be
    aware that they are distributed.

  • The OTP libraries provide support for many common
    problems in networking and telecommunications systems.

  • The Erlang runtime environment (a virtual machine,
    much like the Java virtual machine) means code compiled on
    one architecture runs anywhere. The runtime system
    also allows code in a running system to be updated
    without interrupting the program.

Comments are closed.