Great Code Comes from Knowing More

The blessing, and the curse, of being a software developer is that theres almost no limit on what would be useful to know. As software merges into every product or service, extracurricular knowledge will be the mark of the developer with a career path--not just a job slinging code.

Some have tried to list the things we should understand. Computer science professors Eugene Charniak and Drew McDermott described an ideal background in one of their textbooks: not only programming, data structures and logic, but also calculus, physics and statistics.

With studies in logic, as well as in programming topics such as recursion, were more apt to write code that does its job (or, at any rate, does no harm) even under nonideal conditions. As more of our code lives on networks whose configuration we cant control, or even know, this skill is becoming more important.

Exception handling in C++, Java and other languages aimed at network-based applications is not just a decoration. Master it and use it.

As more of our tasks involve sophisticated data retrieval, rather than brute-force data manipulation, data structures become more than bookkeeping. The right data structure becomes a huge head start in capturing the right knowledge and making it accessible with flexibility and speed.

In fact, the essence of object-oriented design and development is to think of code as the property of its data, as something that exists to enable that data to contribute to solving your problem. If youre just using objects to collect your procedures in little bags with name tags, youre not getting the picture. The data is in the drivers seat.

So far, youre probably nodding your head in ready agreement. But calculus? Physics? Statistics? The first is more relevant than it may seem: As the language of things that change, calculus is the path to the best solution when a problem can be solved in many ways.

With software coming out of its back-office role as a necessary cost of doing business, becoming instead a major part of the value of products and services, we have to think like product designers about up-front and recurring costs. A decision to spend more up front, in order to reduce the costs that repeat with every transaction, is a trade-off that has to be stated with precision and determined with accuracy.

To deliver solutions that we can be proud of, we have to be part of the dialog that decides what problem were going to solve. Though you may not see calculus up on the whiteboard during the product planning session, its a way of thinking that will make your contributions more valuable even if you never mention the word in public. (In fact, a word of advice: Dont mention it in public.)

And physics? Its physics that limits the speed of our processors, the bandwidth of our networks, the reliability of our wireless links. If you dont understand the connections, youre writing code for an ideal world of massless bits that live on noise-free channels. The developer whos writing code for the real world will deliver a better product.

Statistics? Increasingly, software is part of a process of making decisions: calling the signals in the game, not just keeping score. If calculus is the language of change, statistics is the language of the errors and uncertainties that are larger in the presence of rapid change.

Again, its a matter of solving problems in a world of realities instead of a world defined by APIs. Do it and prosper, or leave it to others--and wind up working for them.