Computer programming, to someone outside the practice, evokes certain mental images. There is the solitary nerd, hunched over his (it's always a man, right?) IBM Model M keyboard, entering his incantations, the jibberish appearing on a flickering CRT monitor. Of course, there is also the hacker cracker, perhaps a bit more sexy (and perhaps even a woman), surrounded by half-built computers and other bits of hardware, finding holes in the security systems around ever-larger computer systems. And finally, perhaps, there is the professorial programmer, with his bushy beard and unkempt appearance, solving hard problems and pushing the limits of computation.

Reality, however, is a bit different.

According to the latest information from the Bureau of Labour Statistics, there are roughly 1.3 million programmers of various stripes in the United States, and I would wager that a large percentage of them do not resemble the stereotypes above.

The reality many of us face as corporate programmers is that our jobs offer a spectrum of experiences (by "corporate" I mean we write software that either provides a valuable service for a consumer, whether that consumer actually buys the software or is the employee one cube over). Some of us may work for a bleeding edge technology company like Google, where pushing computational boundaries is simply what you do. Some of us may work for a security firm where we are paid to crack software and break things. Most of us, however, write software that provides some limited service to a known set of users, usually providing a solution to a domain-specific problem. While it is easy to dismiss this sort of software development, it generally serves a valuable purpose to its users. What's more, this development consists of more than simply head-down programming. Yes, weeks may pass when I write hundreds, perhaps even thousands of lines of code. But, soon after a release to our testing department, I spend weeks and weeks not writing code, instead focusing on bug fixes, some of which may only require the modification of a few characters in the source code.

Many programmers, myself included, see themselves as hackers—even craftspeople. We build things, and unlike engineers, there is a certain degree of creativity in what we do (Paul Graham once famously compared hackers and painters). Give us a problem, and we will design and implement an elegant solution for it. Some of us even go so far as to criticize programming languages as "ugly" (see Perl) and others as "beautiful" (see LISP). (Of course, while LISPers call Perl "line noise" and Perl-ites call LISP "parentheses soup," the truth is that you can write elegant code in almost any language.)

What can be forgotten in all this talk of beauty and craft, however, is that any created thing often requires a fair bit of work that, on its face, seems mundane and pedestrian. Add to that the pressures of market, and the elegance of the code suddenly takes a back seat to shipping usable software.

Yes, software development is full of mundane tasks, even in the most interesting and elegant pieces of software. Bugs need to be fixed. Third-party frameworks and libraries need to be integrated. Software and hardware need to talk to one another. New features need to be shoehorned into existing applications. Instead of wielding our hammers and saws, instead we're armed with glue and duct tape. Programmers like to chafe against these tasks, preferring hacking to gluing and fixing, but if the goal is to produce a usable, good piece of software, every detail counts.

Those seemingly endless nights of tracking down Heisenbugs do matter, and make the software better. The same applies for gluing code or hardware together. I will be the first to admit that spending my Thanksgiving determining why data was being truncated between our software and our server was not ideal, but in finding and patching the issue, we delivered a new product on time for a customer.

Gluing and long debugging sessions are a part of life in this industry, like them or not. As Christians, we have a unique call to sweat the boring details—if Christ does indeed claim every square of Creation as His own, every bit of our work, regardless of how mundane, is done for His glory. If you find yourself stuck in an endless cycle of drudgery, leverage what you know. Can you write a tool to automate a process? Can you write a test suite to better trap bugs? Can you improve the build and release process? Certainly this is different than writing the perfect algorithm, but the goal should be the same—shipping useful, bug-free software that will delight its users.