Shades of Development

I just recently interviewed with a small company that needs someone to be the person who:

• Maintains programs which patch together the pieces of their enterprise, e.g.; do some processing between the Internet order and the ERP system, write reports which draw on the ERP system, etc...
• Identifies (or refines when others identify) and creates process improvement solutions.
• Helps to create / refine content to the web site.
• Does other sundry bric-a-brac.

Now this seems to be a good opportunity:

• The people seem great.
• The company is small and growing fast.
• I would be able to call the shots.
• I would be getting in at the ground floor.
• Productivity is inversely proportional to team size (with the probable exception that 2 are better than 1).

It does, however, illustrate shades of development. One reason I'm code wannabe is that I often come across examples of the work of people who may be called "computer scientists". Or at least what they're doing is something orders of magnitude more compelling and or useful than what the average business developer does.

This position is not one for the computer scientist; nor should it be. The business has a specific gap that needs filling - they need someone to apply the correct amount of lubrication at all the correct points to keep the enterprise at optimum operational capacity. I frankly think I would be very good at this.

One thing they made clear: things move fast, there would be a great amount of context switching, and they want someone amenable to as many interruptions as the business generates. They don't want someone who is a "head down coder with the office door shut". Once again, this is perfectly reasonable, but it's not without drawbacks from the standpoint of a purist (in this case purist being a favorable term for one of those really smart guy programmers described above):

• "Closed door programming" is to be preferred. But again, this presumes a certain type of programming. I wouldn't be creating the kinds of solutions that require intense, focused concentration (at least I don't think so).
• Context switching is harmful. Steve McConnell's quote also comes to mind, "... programming requires more concentration than other activities. It's the reason programmers get upset about 'quick interruptions' - such interruptions are tantamount to asking a juggler to keep three balls in the air and hold your groceries at the same time." I don't think there's any doubt it is a productivity killer. In this company's environment, however, there's probably a greater benefit that outweighs it's drawbacks.

So this company's developer should be much different than many others. This introduces the range of development:

• Corporate developers working on in house applications at BloatedCorp.
• Rock stars creating startup Internet applications.
• Lone developers working under unique conditions leading to killer solutions.
• ISVs creating (formerly) shrinkwrap or (now usually) Internet apps.
• Upper echelon programmers: those who create software for developers. Folks who work directly on .Net or Java internals or on IDEs.
  
• Luminaries like Richard Stallman, Linus Torvalds, or Edsger Dijkstra.
• Contract or independant developers: there's a whole sub range in here.
• Gaming programmers.
• Embedded systems programmers.
• Academics who may contribute to practical projects.
• Monkeys who act as typists for business analysts adding new widgets to code in a system that should be redesigned to be configured directly by business analysts. (That one is a bit specific because it's what I do now).
  

If I take the job, I will probably be busier than a one legged man (you know the rest), so I'll probably have to forebear studying the more C.S. intensive subjects as I am sometimes wont to do. One thing all good developers must share is the constant acquisition of new knowledge; just some more than others...