Writing Code Like a CEO
The average developer makes hundreds of decisions every day. This applies to programmers of all types including newbies, seniors, leads, and architects. They prioritize the work to be accomplished, which bugs to investigate, how to fix issues, and the programmatic path taken to solve problems. Although some of these decisions are smaller than others, they all have varying levels of impact. When too many competing needs arise, seeking guidance on priority is a simple, yet smart decision. Eliminating the haze helps to align the importance of work and reduce the static/noise. But what about the smaller decisions in a day? Although smaller, each of these materialize in different ways.
Should this code be broken up? Should this be a configuration option? Should this code be centralized? Should this code be refactored? These and other questions like it are some of the decisions made by developers every day. Although it can go unnoticed, approaching these decisions can be just as important as fixing a high priority production issue. These decisions affect how much time is spent building, testing, releasing, and maintaining each feature. Not sure how much time to spend on an item? An easy trick is to think like a CEO. Take a moment and complete the statement: "If I ran the company, I would recommend..."
This line of thinking can serve as a lighthouse during the decision making process. Be aware that thinking like a CEO is not easy at first. Instead of mentally switching roles, many developers attempt to attach the CEO mentality to their existing thought process. This has too much influence and will ultimately sway any decision making. Most CEOs know very little about programming beyond a rudimentary understanding. They think in terms of time, money, and value. In most companies, programming is one part of a larger puzzle.
This is not meant to insinuate software development isn't important to a company's business. On the contrary, the investment of time and money is large enough that it warrants special attention. Too many subtle decisions in the wrong direction can put a product weeks or months behind. Too much refactoring, excessive configurability, and unnecessarily complex logic are all examples of small decisions that can start to compound. This unspoken and undervalued area can be a silent killer in the software industry.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)