How To Becomea Skilled Programmer

[This was originally addressed to the author of WhyDoPeopleMakeSoManyMistakes, but he/she didn't seem to have noticed it sitting in the middle of the (huge) page. I've brought it out onto its own since I think it asks some important questions.]

RobertlRead of Hire.com has written a 40-page opus on "How to be a Programmer". I don't know Robert myself but I know a good programmer and friend who works for him, and I recommend reading over the document at http://samizdat.mines.edu/howto/. -- StevenNewton

Okay, I'll take your word for it for the sake of discussion. Let's say that this is all true. Then it's definitely a problem. So what's your proposed solution? It appears on the surface that you believe these people are inherently incompetent and shameful and there's nothing that can be done to make them properly skilled. If I'm misreading your opinion, please correct me; I don't want to misjudge your position. This is only how it appears; I'm probably wrong in more than one way.

The reason I ask is that you have not responded to the essence of the GrandMaster? stuff and the Plato stuff. The GrandMaster? stuff says that certain people simply have a knack for things, either learned, innate, or a combination. It implies that some of this can be learned, but that there will always be a large variation in the population of programmers. The Plato stuff says that there are geniuses, but the major factors in "skill" are actually science, technology, culture, and history. It does not matter whether the studies measured "productivity" vs. "mistakes", or "IQ" vs. "skill". These are rough approximations of each other; they are not one and the same, but they are correlated. At least it's some evidence.

You seem to be implying that it's our fault if we're not properly skilled. In that case, teach us. We want to learn. What is it that you do that keeps you from making mistakes? We want to learn those skills. Or maybe you don't have time to teach us, but you could direct us toward the appropriate source of knowledge, such as a course, or book, or a particular place to work to gain good experience.

Or perhaps you are implying that certain people are inherently more skilled than others and it is not a matter of training. In that case, is it any wonder that most people make lots of mistakes? Why does that page (WhyDoPeopleMakeSoManyMistakes) exist?

I'm not sure what your position is. I may be completely off the mark. Could you give an example of your proposed solutions so that we can better understand your message?

The author of WhyDoPeopleMakeSoManyMistakes seems to be one of those people who says "We don't need methodologies. Just write good code!" I run into those people once in a while, and I can't understand that they don't understand that they are themselves following some sort of methodology. It may not be formal, but if they are successful, then they are doing something that most people are not doing.

Maybe, then, their point is this: Not everyone has to think about it to do it. Some might get great value from stepping back, observing their processes, hearing what others have to say about processes, and so on. Others might find this distracting. Or, maybe they just take pride in saying, "If I have success, it's because of *me*, not some goofball who writes a book."

KentBeck said, "I'm not a great programmer. I'm a good programmer with great habits." (See: GoodProgrammerGreatHabits)

One way to become a skilled programmer is to TeachYourselfProgrammingInTenYears.

I read some of the material on ExtremeProgramming and also thought to myself that it was a bit overkill. Never use code that you write by yourself? Given my remote location, that's going to rule out 95% of my work. (Ok, I'm a hermit.) YouArentGonnaNeedIt? Maybe appropriate for when you're doing contract programming, but the worst possible rule for when you're on your own time and trying to build better libraries for greater leverage later. But the base issue is that I've been cranking out functional, extensible software for going on ten years now. (I've been programming for twice as long, but my early results are embarrassing.)

So what's missing? Two key skills - one learnable and one not.

The first is never stop learning and growing. Learn new languages, new editors, new environments, methodologies, strategies, etc. An extension of this, is not to be attached to an existing implementation, which leads to RefactorMercilessly. Good programmers do this, 96% of the programmers I've worked with don't. Of course, the fact that design patterns, orthogonality, or even PragmaticProgramming? aren't even taught in school is a crime too.

The second is comprehension. You either get it, or you don't. I think at C3, they must all "get it". I've worked with a number of programmers that didn't. I would set a task down in front of them, and they miss the target time and time again. I don't see how even ExtremeProgramming would solve this problem - you would just get incorrect code and incorrect unit tests that went with them. It's like the on-the-spot programming quiz we used to give college interns: write a code fragment that traverses a linked list. About 60% of the students that interviewed could not do this (and this is after four semesters of programming classes: java/C++/etc).

So when is life going to get better? I'm thinking ten to twenty years. By then, the concepts of software design methodology will finally be taught, instead of professors just teaching the latest languages and then having the students implement projects and learn from their own mistakes. And second, hopefully we'll have some better method for establishing minimum acceptable standards for the craft.

-- DerekWoolverton

I would suggest that currently you cannot become a skilled programmer. This is not due to lack of effort, but rather due to lack of agreement of what skills are needed by a programmer. The following is a start of list, including some non-traditional skills.

Market Research Skills - The ability to identify an operation that can be improved with software.
Listening Skills - The ability to actually hear a user complaint and understand it without getting defensive.
Writing Skills - The ability to write expressive code in English (or other mother tongue) not in computerese.
Able to be Consistent yet Adjust and Adapt - Don't change for the sake of change, but be willing to listen, understand, and possibly try new things that seem appropriate.
Team Work, Trust, Delegate - The ability to trust, allow, and encourage others to succeed. Too many development projects devolve into one man shows with bread crumbs occasionally tossed to other team members.
Black Hole Warning Sensor - The ability to know when an approach is not working. You don't want to give up too soon, but also you need to know when to scrap an approach and start again from scratch.
2 Minute Monologue - The ability to describe what you are doing concisely and completely in 2 minutes or less in a language anyone can understand. Ever have someone come into your office looking for help and then have him start spouting off a list of unrelated events? Tell me what the problem is and why it is a problem before giving me the details.