My favorite question for years has been, “What are you trying to accomplish?” Our clients frequently begin asking about new work with questions like, “How do I get a report out of the software that shows profit by job?” Or, “Does the software support barcode?”
I’ve learned to ask my question, “What are you trying to accomplish?” Sometimes the answer is simple, “I want to know whether I made money on that last installation we just finished.” Sometimes the answer is in a completely different direction, “I noticed that we lost money last month. I was trying to figure out why.” In that case, the answer might be on the Job Profitability Report (or whatever it’s called), but the answer might also be somewhere else.
Also, the question, “Does the software support barcode?” could be going in one of a hundred different directions. A few examples: “We’re getting a lot of returns, I want to have the packing staff scan out product before packing it.” Or, “Inventory is wrong, I think warehouse employees are entering the wrong part numbers in the system. I want to use scanners to make sure the product IDs are correct.”
In both of these cases, answering just the question asked may point in the right direction, or the client may find themselves barking up the wrong software tree.
More and more of the jobs being created today are in positions that require some business knowledge as well as technical knowledge. Being a CPA, knowing something about the technology (Windows, Linux, etc.), and being able to write code has been a big advantage to me in understanding the right questions to ask to help our clients.

When I was in college, Computer Science was a Major in Math with a concentration in Computer Science. There were two introductory, lower-division computer science classes. After that, everything else was a 4000-level “Topics” class. They offered the standard fare for these days: compiler design, operating system design, system development methodologies, programming languages, etc.
The first one of these classes I took was (effectively) a class in Pascal, the popular teaching language of the day. The assignments were pretty simple, and often mathematical. I remember doing a fibonacci series, numerical integration, input processing, etc. One of the early programs the professor graded came back with some surprising grades for some of the students. They raised their hands. “Professor,” they said, “I got the same answer you did, but you gave me a C- on the program. The program works, how come I got a C?”
I then got one of the best lessons of my IT career. The professor sat down on the desk and looked slowly across the class. “Here’s something you need to learn now,” he said. “Just because it works doesn’t mean it’s right!”
In IT, we should have more significant standards than just working. Is it maintainable? Is it simple? Is it profitable? Does it make sense? Is it stable? Is it scalable if it needs to be?
Too many solutions I see today just “work.” We need to get past that to get real benefit from our IT.