Software Engineer does what?

People who aren't software engineers often picture us as albino code monkeys, hovering over a phosphorescent screen in an office cave, endlessly typing lines of code on a keyboard buried in three layers of Chipotle take-out wrappers. Since the vast majority of my readership is non-technical, I thought I'd describe some of the tasks that make up a typical day for me as a public service.

Requirements:
The customer gives us a list of requirements that should be met in the next version of the product, but they're usually high-level and far-reaching. The engineer's first job is to translate those customer requirements into more specific technical requirements. For example, if the requirement were, "The system will play the Howdy Dowdy theme song on startup.", the derived technical requirements might be "The system will be able to use the computer's soundcard. The system can tie sound events to arbitrary user actions. The system will have the Howdy Doody theme song included as a selectable sound." Often, this phase is accomplished through many rounds of back-and-forth with the customer, who might only come up with a requirement like "The user interface will not suck". There may be a lot of prototyping and writing quick and dirty examples to help the customer figure out what they really want.

Design and Planning:
Once the list of requirements is initially set in stone, the software engineer is free to start designing those requirements (ignoring the fact that those requirements set in stone will be followed in a couple weeks by several smaller stones and pebbles filled with added requirements, wishlists, and impossibilities). They'll consider things like system architecture, which languages to use, and which patterns and algorithms might be needed, and then create a written map of how the requirement will be implemented. With this roadmap in hand, the engineer then comes up with a time estimate. Engineers can give estimates based on their many years of experience, or (if they're in a company jailed by the bars of Process Improvement) they can force all their team members in a room to "wideband" the estimates. A wideband is when multiple engineers are held captive and while everyone talks about their estimates and their dogs. The wideband ends after multiple rounds of re-estimating when all the estimates are within 10% of each other (or when everyone has to pee so they "accidentally" adjust their numbers to reach a consensus). These numbers are then given to the manager so they can be cut by another 10%.

Implementation:
This is the part that people see as the classic role of a software engineer. With the design outline in hand, engineers start coding. The quality of the document correlates directly with how this phase goes -- a comprehensive well-thought-out document makes the coding phase almost brain-dead, since all the hard decisions have already been tackled. You could almost train a seal to enter the code, if they had keyboard-friendly appendages and a degree in Computer Science. This also depends on the engineer's personal style -- some people like to solve all the problems up front so that implementation is a breeze, while others like to provide a general direction in the design doc and then do the heavy lifting while writing the code. I'm in the latter camp. Starting with only a vague direction means I'll often hit roadblocks and have to backtrack, but the end result is usually stronger because of it.

To be continued tomorrow...