The Professional Programmer What is a professional programmer? The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others. If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology.

The Road to Performance Is Littered with Dirty Code Bombs More often than not, performance tuning a system requires you to alter code. When we need to alter code, every chunk that is overly complex or highly coupled is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the way forward is smooth it will be easy to predict when you’ll finish.

The Single Responsibility Principle One of the most foundational principles of good design is: Gather together those things that change for the same reason, and separate those things that change for different reasons. This principle is often known as the Single Responsibility Principle or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is a class that has methods that deal with business rules, reports, and database:

The Unix Tools Are Your Friends If on my way to exile on a desert island I had to choose between an IDE and the Unix toolchest, I’d pick the Unix tools without a second thought. Here are the reasons why you should become proficient with Unix tools. First, IDEs target specific languages, while Unix tools can work with anything that appears in textual form. In today’s development environment where new languages and notations spring up every year, learning to work in the Unix way is an investment that will pay off time and again.

Thinking in States People in the real world have a weird relationship with state. This morning I stopped by the local store to prepare for another day of converting caffeine to code. Since my favorite way of doing that is by drinking latte, and I couldn’t find any milk, I asked the clerk. “Sorry, we’re super-duper, mega-out of milk.” To a programmer, that’s an odd statement. You’re either out of milk or you’re not.

Two Heads Are Often Better than One Programming requires deep thought, and deep thought requires solitude. So goes the programmer stereotype. This “lone wolf” approach to programming has been giving way to a more collaborative approach, which, I would argue, improves quality, productivity, and job satisfaction for programmers. This approach has developers working more closely with each other and also with non-developers — business and systems analysts, quality assurance professionals, and users.

Two Wrongs Can Make a Right (and Are Difficult to Fix) Code never lies, but it can contradict itself. Some contradictions lead to those “How can that possibly work?” moments. In an interview, the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug that should have made the lander unstable. However, another bug compensated for the first and the software was used for both Apollo 11 and 12 Moon landings before either bug was found or fixed.

Ubuntu Coding for Your Friends So often we write code in isolation and the code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation.

Use the Right Algorithm and Data Structure A big bank with many branch offices complained that the new computers it had bought for the tellers were too slow. This was in the time before everyone used electronic banking and ATMs were not as widespread as they are now. People would visit the bank far more often, and the slow computers were making the people queue up. Consequently, the bank threatened to break its contract with the vendor.

Verbose Logging Will Disturb Your Sleep When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I’m talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging can be as useless as none at all.