Tuesday, December 05, 2006

Software Engineer does what? Part II

Defects and Enhancements:
No engineer is perfect, and eventually a defect will be logged against the system. This might come from a user in the field using an operational version of the system, or a tester in-house getting things ready to ship. Honestly, most defects occur as the result of a user using the system in unexpected ways or fat finger typos in the code -- very few defects can ever be traced back to engineer incompetence because it's surprisingly hard to just get a solution completely wrong (engineer incompetence only makes things run very very slowly). This makes fixing the bug very easy, but the tough part is tracking down the location of the bug in the first place. Defect fixing is a fun stage for people who like to make lists and check things off as they complete them, since you get to play detective and doctor on many very small problems, keeping things fresh.

Putting Out Fires:
Occasionally something goes critically wrong, and the live system explodes or nuclear deterrents from Russia are mistakenly launched. When the problem is too urgent to go through the usually "write it down and fix it in the next version" approach, engineers drop everything else and do what they can to save the day. Sometimes it's not so much that the issues is major -- it's that the people who care about the issue are major (or Majors), since political clout has an unerring ability to expedite the tiniest of issues. On putting-out-fire day I can often be found on-site in Bailey's Crossroad sitting in a refrigerated lab giving directions to system administrators since I don't have the authority to touch the computers myself. This turns my 14 mile commute into a 60 mile commute, but given the current rate of federal gas-perdiem these days, I generally turn a profit when I calculate my expense report.

Giving Demos:
Sometimes people just won't accept that the product you're developing is the greatest invention since the toaster oven (even sliced bread would be useless without it!). On those days the least socially-awkward engineers get to put on a suit and present a demonstration to the customer, who often drag a couple tech guys along to make sure you're not just playing tech-word Bingo during the demo. The tech guys often feel the need to earn their keep, so they'll toss out a question or two, generally hitting about a 40% relevancy rate.

So that is the job of a software engineer in a nutshell. There's enough challenging creative tasks mixed in with the mundane to keep us from getting bored. Though it would be nice if we could cycle through the various phases one after the other, the reality is never so cut and dried. At any given time, you're supporting one or two live products in the field, developing a new version back home, and putting out one or two fires a week. The lines between phases blur to the point where you really need to have a multitasking personality to ever get anything done. Yesterday in the eight hours I was physically in the office, I did three hours of development, three hours of debugging, an hour of requirements and design, and another hour just helping fellow engineers out. Then I came home and did another few hours of documentation and design. Luckily there were no fires, and I haven't had to go down to Bailey's Crossroad since, oh, last Thursday.

Happy Birthday Ben Seggerson!

Bizarre deep sea creatures of New Zealand
Rap away your ticket
Road spraying releases spirits

tagged as programming | permalink | 3 comments


Previous Post: Software Engineer does what?


Next Post: At the Mercy of Fans

 

You are currently viewing a single post from the annals of URI! Zone history. The entire URI! Zone is © 1996 - 2014 by Brian Uri!. Please see the About page for further information.

Jump to Top
Jump to the Front Page

visitors since November 2003