Job Description for Programmers

Our Mission Statement defines an ambitious Goal for each Member of ArsDigita: "to become an internationally famous Web developer capable of managing an entire project from start to finish."

Realistically, whether or not you become "internationally famous" has less to do with your programming skills and more to do with the company's ability to find good clients, so we programmers should focus on the latter part of the goal, i.e., becoming "capable of managing an entire project from start to finish." Accordingly, the most important part of the programmer's job is delivering projects or, in other words, launching sites. (This statement does not apply to toolkit programmers.)

Running a project

What does it mean to "run a project" in concrete terms? Does it mean that you, as a programmer, are responsible for all of "the elements of a typical ArsDigita project" (as defined in the Compensation Principle section of the Mission Statement)? No, it does not. As a programmer, you are not expected to:

• land the contract
• host the site

What does that leave? A lot.

Working with the customer

There is no layer of full-time business analysts and project managers at ArsDigita to insulate you from the customer, so you are expected to:
• understand the customer's goals (what they want to achieve) and strategy (how a web service will help them to achieve those goals)
• understand the customer's constraints: when they want to launch, how much money they have to spend (which translates into how many programming resources their project will be allotted)
• use this understanding (in concert with your experience and your knowledge of the toolkit's capabilities) to define a minimum launchable feature set, in collaboration with the customer
• review the project plan with the customer, to set the expectations as to the basic sequence and timing of the project work (if the customer needs Feature X by Date Y for a meeting with VCs, then your plan had better account for it), as well as who does what (us or them)
• keep the customer involved once the coding begins: solicit feedback on features of the site as soon as they are available (start using the Ticket Tracker early); make sure the customer is getting what they want
• keep the customer informed about the actual progress you're making; it's inevitable you will not execute the project exactly as planned, so let the customer know what adjustments you need to make (use your judgement here; don't waste their time with minutiae)
• track not only ArsDigita deliverables but also the customer's (e.g., content, graphic design, payment): help them to avoid missing deadlines by clearly defining what's expected well in advance and then following up with reminders as the deadline approaches; when they do slip, communicate the consequences of the delay on the project as a whole, ideally with suggestions for how to mitigate the impact
• manage scope creep: if the customer has a "great, new idea," evaluate the amount of work it will require to implement and then -- assuming that it's not trivial -- help the customer decide for themselves whether or not the new idea is truly a "must have" for the initial launch; if they believe it is, then make sure that they identify what other feature(s) they're willing to sacrifice in order to get the new one in, or work with your team leader to determine whether it's possible to add resources to the project at an additional price
• work with other contractors (e.g., management consultants, graphic and UI design firms) as if they are customers too; determine at the outset who is responsible for what decisions and who else (besides the ultimate decision-maker) needs to be involved

Building the site

The foundation of ArsDigita is our excellence as programmers, so it should come as no surprise that you are expected to:
• write a clean, well-engineered data model that adheres to standards
• design a user interface that makes intelligent use of the database and adheres to standards
• write clean, well-engineered code that is readable, adequately commented, robust, and adheres to standards
• understand why the consistency that results from adherence to standards is so important
• learn what you need to learn, e.g., even if you know Tcl better than SQL, don't blindly use Tcl to solve all problems, including those best solved with SQL; rather, crack open some O'Reilly books, fire up SQL*Plus, and improve your knowledge of SQL
• help junior programmers become productive, by training them, reviewing their work, giving them timely feedback, and (when time and circumstances permit) involving them as observers in all aspects of running the project, e.g., designing the data model, meeting with the customer
• enforce a disciplined development process, e.g.:
  • use CVS for version control
  • perform and/or solicit data model reviews before starting to code
  • perform and/or solicit code reviews on a regular basis
• write documentation for two audiences:
  • the customer, who will use the admin pages to operate the site
  • other programmers tasked with maintaining and enhancing your code
  Comments in the code are not enough; you also need to produce ACS-style documentation (i.e., an HTML page with sections for "The Big Picture", "Under the Hood", etc.) for all major modules of the site, even if they will not be rolled back into the ACS.
• leverage the toolkit whenever possible, enhancing it if need be
• fix bugs in the toolkit as you encounter them
• identify any features that are worth generalizing for inclusion in the toolkit and actually build them as "ACS-ready" modules, making sure not to divulge any of the customer's proprietary secrets
• post bug fixes and toolkit improvements at http://photo.net/ticket/
• seek help when you need it; don't flounder (striking the right balance between self-reliance and knowing when to ask for help is one of the hardest parts of this job)
See the Developers Guide for more details on writing high-quality software.

Launching and operating the site

To turn your big heap of software into a running, reliable web service, you need to implement the ArsDigita Server Architecture. You will find that much of the infrastructure is already in place (i.e., Unix, Oracle, AOLserver, the various ArsDigita monitoring tools) but it is still your responsibility to walk through the setup instructions, to make sure that the ArsDigita Server Architecture is properly installed for your service.

If we built the site correctly, then the customer should have all the admin tools they need to manage the day-to-day operation of the site, but, inevitably, problems will arise that require our intervention. At the same time, we don't want to be leaping into crisis mode every time a minor bug is discovered. Thus, you need to educate the customer about our standard Alert and Response policy. When alerts do occur, respond to them quickly and take action to ensure that the same problem will not happen again.

Finally, given our goal of building long-term relationships with our customers, you need to maintain contact with the customer beyond the initial launch, to help them capitalize on what's working and correct what's not. At a minimum, you should invite the customer to participate in our quarterly Strategy Review process.

Beyond project work

Aside from producing quality software, programmers at ArsDigita are expected to contribute to the company's other main goals: education and growth.

Education

In addition to mentoring our less experienced members, we want to spread the gospel to the world at large, through externally-focused teaching. At the moment, there are basically two ways to do this:

• TA 6.916 and/or Boot Camp
• Answer questions on the web/db, Problem Set 1, Problem Set 2, and Problem Set 3 forums

(For those of us who aren't at locations where either the class or Boot Camp is being taught, the second option may be our only choice.)

Building the company

You can contribute directly to the growth of company by:

• recruiting high-quality people to work with us
• mentoring the people you recruit, to help them become productive as quickly as possible

You can improve the company's ability to grow by:

• following procedures where they exist and make sense
• suggesting ways to fix procedures that exist but don't work very well
• defining procedures that don't exist but are needed

General expectations

It's pretty much impossible to do this job well unless you are:

• good at solving all sorts of problems (new problems don't intimidate you; rather, you use analytic thinking to decompose the problem and, more often than not, solve it quickly)
• self-motivated (when you run out of tasks, you start thinking of what else needs to be done, instead of waiting for more tickets to appear; as mentioned above, you learn what you need to learn to succeed)
• reliable (you keep the promises that you make, both to the customer and to your colleagues)
• independent (you're able to produce results without requiring constant supervision and hand-holding)
• helpful (you're willing to take time out of your day to teach a teammate something new or to help a teammate crack a particularly hard problem)
• responsive and flexible (you're willing to do things not explicitly listed in this document if needed)