Do you trust a doctor with diagnosing your mental problems if the doctor tells you he's got 20 years of experience? Do you still trust that doctor when he picks up his tools, and asks you to prepare for a lobotomy?

Would you still be impressed if the doctor had 20 years of experience in carrying out lobotomies?

I am always skeptic when people tell me they have X years of experience in a certain field or discipline, like "5 years of experience as a .NET developer", "8 years of experience as a project manager" or "12 years of experience as a development manager". It is as if people's professional levels need to be measured in years of practice.

This, of course, is nonsense.

Professionalism is measured by what you are going to do now...

Are you going to use some discredited technique from half a century ago?

• Are you, as a .NET developer, going to use Response.Write, because you've got 5 years of experience doing exactly that?
• Are you, as a project manager, going to create Gantt charts, because that's what you've been doing for 8 years?
• Are you, as a development manager, going to micro-manage your team members, as you did in the 12 years before now?

If so, allow me to illustrate the value of your experience...

Here's an example of what it means to be a professional:

There's a concept called Kanban making headlines these days in some parts of the agile community. I honestly and proudly admit that I have no experience at all in applying Kanban. But that's just a minor inconvenience. Because I have attained the knowledge of what it is and what it can be good for. And now there are some planning issues in our organization for which this Kanban-stuff might be the perfect solution. I'm sure we're going to give it a shot, in a controlled setting, with time allocated for a pilot and proper evaluations afterwards. That's the way a professional tries to solve a problem.

Professionals don't match problems with their experiences. They match them with their knowledge.
Sure, experience is useful. But only when you already have the knowledge in place. Experience has no value when there's no knowledge to verify that you are applying the right experience.

Knowledge Comes First, Experience Comes Last
This is my message to anyone who wants to be a professional software developer, a professional project manager, or a professional development manager. You must gain and apply knowledge first, and experience will help you after that. Professionals need to know about the latest developments and techniques. They certainly don't bother measuring years of experience.

Are you still practicing lobotomies?

The Reality of Bad Programmers

I’ve been reading a lot of articles lately outlining what defines a bad programmer. I find this to be a particularly interesting topic myself as often times I am accusing other programmers of being “bad”. Upon reflection, and after reading these articles, I must admit, this is an unfair term. The term “bad” in this context is completely subjective. By calling someone a “bad programmer,” you’re applying standards to them which aren’t universally true. It would be a fair assumption to say that we’ve all wrote “hacks” in our times, and on many occasions, those hacks were out of the necessity of the situation and not what the developer would like to do.

Science does not promise absolute truth, nor does it consider that such a thing necessarily exists. Science does not even promise that everything in the universe is amenable to the scientific process. - Isaac Asimov

What I’m getting at here is that there aren’t bad programmers, there are bad programs… and even those often aren’t “bad” if they are taken into context. So what does all this talk of so-called “bad programmers” actually mean? It means we’re frustrated. It means we, as developers, strongly desire some metrics for determining “goodness” or “badness” of not only the code of others, but even our own.

Why is this still a problem? After over fifty years of code, we still cannot figure out what makes a program good?!? That would seem like a problem… on the surface. It’s not. Here’s why:

The Philosophy of Code

As programmers, we expect our code to do two things: Work or Not Work. And when it doesn’t work, we expect to be able to fix it after testing. Black and white thinking. It either works… or it doesn’t… and if it doesn’t… it should and it will.

The concept of good and bad aren’t just subjective and intangible, they’re completely non-existent in the realm of programming quality. Unless such metrics are created, and they themselves are immutable and empirically verifiable, then the best we can do is judge a program based off whether it actually does the tasks it was intended to do.

For instance, I consider myself fairly good at interface design. However, every single time I choose an interface revision that works to publish, there’s someone, bless their soul, who cannot deal with concepts such as, say, “drag and drop”. These people are a strong minority, but to them, I’m a terrible interface designer because it doesn’t work for them as they cannot understand it. This does not mean the interface is bad, it does not mean I am a bad interface designer, it does not mean I’m a bad programmer. It means that they would have done it differently.

What’s bothering me is that all these articles speaking of “bad programmers” are being extremely unfair and hypocritical. Much of the code they write, I can guarantee there would be someone out there who looks at it and says, “I would have done this better.” And that is exactly the problem; black and white thinking applied to a gray area.

The Metrics Being Applied

Does it work well?

• If no, bad code.
• If yes
  • Can it be better? (subjective)
    • If yes, bad code.
    • If no
      • Why can’t it be better? (subjective)
        • (enter list of excuses here)

The Only Metric That Matters

Does it work?

• If yes, good code.
• If no, fix it or start over.

What This Means

We want programmers to write nice code. We want modularity. We want good organization. We want the code to be decoupled. We want to avoid copy and paste. We want everything. What project has time for that? The only projects I’ve ever seen that are like this and remain like this are open sourced projects run out of love and not for money. They have no deadline. The quality is the goal as it’s the only feature that will keep users using is and, in turn, contributing. This is not a reality in the business world. In the business world, quality comes second to deliverables. Make the milestone, at all costs. And the first cost to go is code. Why? There’s actual profit to be made in doing so!

If coders were left to code. If coders coded for love. If coders didn’t have to worry about their jobs… if they did it out of love… well then of course the code would improve. They’d do everything in their power to improve their code.

All this talk about bad programmers is categorically false. There are uneducated people in programming positions, yes. There are incapable people in programming positions, sure. There are people in programming positions who cannot “hack it”, of course. But this talk of “bad programmers” aren’t defining standards for spotting these people. Those people *AREN’T PROGRAMMERS*, they’re script kiddies or charlatans. What we’re talking about are real programmers: people employed at companies, people gaining contracts, people who contribute to open source projects. That’s might haughty of these authors of these articles to tell such people that they’re bad programmers because they do not know certain things that they probably do not even specialize in or use.

What’s more is, look at what they are asking people to know? 25 years ago, knowledge of OOP would be a minor point. Now it’s a major point. Right now, knowledge of functional programming is a minor point. 20 years from now, who knows. Now, knowing about assembly languages isn’t a big deal. 20 years ago, it was a huge deal. If you can code (and by that I mean, write code that works), you are a good programmer.

In summary: does the code work? If so, it’s good as is whoever wrote it. If you need more requirements later and the program needs to be extended to make it work, consider that a separate program then apply the same metric… does it work? Talk of anything else immaterial as it’s a subjective qualitative assessment.

From http://www.humanerr.com/2008/07/04/the-reality-of-bad-programmers/