Definition of a Great Programmer - Part Two

April 26, 2009

In my last post, I provided my list of what makes a programmer great:
  1. Motivation.
  2. Critical thinking skills.
  3. An understanding of software design: Architecture and design patterns.
  4. A solid working knowledge of the programming language being used.
  5. Communication and collaboration skills.
  6. Continual learning and exploring.
  7. Domain knowledge of the problem being solved.
  8. Experience.
As promised, I’ll dig into the details.

Motivation
Without this, everything else is in the tank. A motivated programmer will apply his or her self towards producing results. A motivated programmer will want to get to the bottom of any vexing issue, to work through a logic maze to produce elegant code that works – and works well – over time.

Motivation comes from within, but is influenced by the work environment. The tone set by management is vitally important. I always try to keep Dilbert in mind; I don’t want create a scenario where I’m treating intelligent, hard-working programmers like they are clueless idiots! A poor work environment, even one bad boss, can suck the life out of an otherwise talented staff.

From an individual perspective, you really need to want to be a programmer. It takes some long hours, and given the time you put into a programming career, you had better enjoy it.

My wife Lauri-Ann, someone who is not in the computer field at all, would support this assertion. In fact, she once steered a college student away from programming based on a conversation she had with him. This student was taking computer classes because his father had pushed him towards a programming career. This student confided to Lauri-Ann that he didn’t really want to be in the computer field at all, but the money seemed good.

Lauri-Ann immediately advised this student to find something that he truly wanted to do. She pointed out that she has referred to herself as a “software widow” during times when I’ve been working night and day on projects with tight deadlines (bless her), just to illustrate the point to this student that programming is a demanding profession.

I’ll sum up my view on motivation by quoting Steve McConnell from his book Code Complete 2.0: “If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.”

Critical Thinking Skills
Highly productive, highly valued programmers exhibit certain traits that I find important as a manager. When the time comes to assign someone a difficult task, managers always have their “go-to” people that have proven that they can handle difficult assignments. And more than likely, critical thinking skills played a role in enabling someone to handle that difficult assignment.

Critical thinking is a large topic in its own right, but I found something developed by Peter Facione that captures the essence of critical thinking. He developed the IDEALS model that includes six steps for effective thinking and problem solving:

Identify the problem. — “What’s the real question we’re facing here?”
Define the context. — “What are the facts and circumstances that frame this problem?”
Enumerate choices. — “What are our most plausible three or four options?”
Analyze options. — “What is our best course of action, all things considered?”
List reasons explicitly. — “Let’s be clear: Why we are making this particular choice?”
Self-correct. — “Okay, let’s look at it again. What did we miss?”

I have observed highly productive programmers using this type of thinking, though I'm not convinced everyone that exhibits this type of thinking can actually explain it.

The absence of this tends to have people asking things like: “What do you want me to do? How do you want this to function?” Basically, those who don’t apply critical thinking tend to ask for direction and very rarely provide options or recommendations. That means that someone else has to step in and work through determining the options, involving additional dialog and time on everyone’s part, and a reduction in overall productivity.

An Understanding of Software Design: Architecture and Design Patterns
Understanding software architecture is about organizing and structuring the system at a high level, concentrating on the components and interfaces between the components. While not all programmers are architects, it certainly helps to be grounded in basics of functionally decomposing systems into a cohesive, organized, and structured system.

Use of design patterns is about all about leveraging industry expertise by re-using good design (and prior thinking) to solve frequently occurring programming problems, increasing productivity as a result. This comes under the “why reinvent the wheel if you don’t have to?” category.

There are numerous books on software architecture and design patterns available in book stores. Like everything else, there will be some subjectivity in terms of architectural design and differences of opinion in code reviews on just how well design patterns are implemented in actual code, but highly productive programmers are always keeping themselves up to date and striving to apply these concepts.

A Working Knowledge of the Programming Language 
I cited a real-world example in my post Does a Software Productivity Metric Exist? where someone wrote a function without leveraging date routines available with the language that we were using. While the function worked, it was difficult to understand and I'm sure required extensive testing before it was deemed correct.

Highly productive programmers always want to make their lives easier, and this means applying leverage wherever and whenever you can. While some may call this “lazy” programming, I call it smart programming.

Call it what you will, but it does take time and effort to learn what features are available, but in the end it sure pays dividends because you are using previously developed and tested code – because you are leveraging what is readily available. And that will save you time and aggravation later.

I feel that I've covered enough for this post, and I’m only part-way through my list! Next post, I’ll cover the remaining four.