I have just a little experience with programming, mainly from two college courses. From that experience, here are a few of the problems I think programmers spend the most time fixing:
- Forgot a comma, quote, or parenthesis
- Misspelled the name of a variable
- Forgot to instantiate a new object, or delete an old one
I know some of you have even less programming experience than I do, so let me elucidate a bit. All of those things are basic. They are the punctuation and capitalization of programming. They are not hard problems that take great brainpower to fix, they are obvious problems that are impossible to see. But they can cause the most obscure, mind-boggling problems when you attempt to run your code.
The only thing that could compete with the simplest technical details for hours spent is conceptual problems. Imagine that you have four ordinary plastic cups, say from a fast-food chain, and let’s say each one measures six inches tall. Let’s say you have to make a stack with the cups that measures two feet high. When you are having a conceptual problem, you will stack the cups all facing up and they will nest inside of each other, giving you a stack about seven and a half inches high (assuming a half inch of each cup shows over the last). You will stare at the stack and despair, seeing a physical impossiblity. When you get over your conceptual problem, you will stack the cups end to end and it will be a silly, trivial problem.
Conceptual problems are the creative work in programming, and brilliant concepts make great programs. But I think more time is spent chasing an elusive comma. In today’s programming languages you can usually just cobble your way around the problem. In the example above, you may not realize how to stack the cups but there is no limit on the number of cups you can request, so you just stack 37 cups up there and go your way, paying no heed to the inefficiency of your solution.
My most recent project at work involved setting up a database-driven tool for several locations where my boss has responsibilities. My boss had promised this tool to important people and he had run out of time to tell them it would be coming soon. Dates were set, plane tickets were purchased, and I had to be on site at the first location on October 6th. As September drew to a close I had nothing like the promised tool on hand. To make up time, I got a rare exemption from the all-hands Physical Inventory Count in the first three days of October.
On Wednesday the first I had a conceptual problem. I spent all day doing the equivalent of stacking the cups in a different order, hoping somehow the stack would come out taller. On Thursday and Friday I hid from the problem; since I couldn’t fix the “car engine,” I gave it a stero and some sweet rims and polished it. By Friday evening I was standing in the shadow of my nightmare of going to the first location, tinkering with the problem to no effect for three days, and leaving for the next stop without ever having set up a functional system at the first place.
Saturday I got my concept right. Monday I built it. Tuesday I rebuilt it, because the basic idea was right but several parts were built wrong. Wednesday I filled gaps, things I didn’t think of originally but knew how to fix when the hole appeared.
Thursday, at the second site, I found out they did not have any of the fundamental data the whole system relies upon. And that I had to present the tool the same day because several key people would not be available the next day. So I presented it, with results that appeared to be more wrong than right. Friday I fixed a few problems and found out that most of what appeared to be wrong was actually right.
On Monday, at the third location, I found out that the local IT department had a reputation for being about as helpful as a flat tire, and that I would need a lot out of the IT department if I was going to get anywhere with my project. By the end of the day I had everything I needed. On Tuesday I found out some things were set up wrong, and fixed them. And I was done, and I went home Wednesday, three days ahead of schedule, because my home location wanted the tool that I had not been able to give them before I left.
There have been new problems with this tool every day. It doesn’t do everything I could have wished, either. And not everybody was as happy to see it as I had expected. I am not telling a fairy tale where everything goes perfectly.
But it is hard for me to overstate how amazing it is that the whole thing didn’t fall off a cliff. I have personally experienced the hours one tiny little detail can cost you, much less everything that can go wrong when you try to stick the same widget into three different machines.
My colleagues, who, like me, are not officially credentialed in any kind of database work, see a smart young man who can “do anything” because he “knows everything” about this kind of stuff. I see answered prayer.
Gratitude mixes with puzzlement. Why this prayer? What’s next? What is going on here?
I don’t know about programmers in general, but my personal experience has been that chasing commas, quotes, parenthesis, and misspelled variables actually consume a fairly small portion of my time. The difficulty I had with these problems when I was first learning have be greatly reduced by moving to better langauges, compilers, and debuggers. You also develope and eye to spot these errors more quickly on your own.
The tools that I know you have used before for your VBA, Java, and C++ programming were pretty poor at pointing the flaws out and suggesting accurate corrections. Evan has been working with the latest versions of Visual Studio, and it’s amazing to me how well it points out these elementrary problems—often providing the correct code a single click.
A much bigger problem for me is undocumented quirks of built-in functions. These are nightmares to debug, and the behavior often appears to be inconsistent. Even after you pin down the problem, coming up with a workaround can often double your expected development time.