Most programmers shouldn't write code.

Hi, I'm back and I'm ready to start blogging again.
I can think the best thing to do here is to kick off my blogging with a rant about the state of the software industry.

One of the reasons I have not been blogging recently is that I am busy writing code, yes real code that will ship. Not only will it ship but the code will be publicly available for other programmers to learn.
I am not new to this kind of gig, the are several samples in the Windows Vista SDK that I wrote, and lots of code examples around web, in books, magazines etc...
When I used to run my own software companies I learned very quickly that not all programmers are born equal, in fact far from it.

A small minority of programmers deliver the majority of the value, the rest add little bits of value and lots of bugs.

The reason the software industry has such a bad reputation is not without cause. Most software projects fail in some way. I think there is one overwhelming reason for this; most programmers can't write code that can (or should) be shipped.
What is it that, this majority of programmers, are doing wrong?
Here is a short list to kick things off.

1. They don't have a clue how a computer actually works, what a CPU is, how instructions are processed, how memory is allocated or how data is stored in registers. Many programmers will say this isn't important as modern programming languages absolve the software developer from having to worry about the hardware. That is exactly the reason so much software sucks.
Understand how the hardware works, understand the implications of context switching, threading, multi-processor machines, otherwise your software will always suck.

2. They don't strive to write the simplest code to solve a problem. Most programmers believe that complex code proves they are heroes, god or whatever. All it proves is that they didn't think very hard about how to simplify the problem. The best (most robust, bug free, fastest) code is simple. Simple solutions to complex problems is clever. Complex solutions for any problem is dumb.

3. Most developers don't create feedback loops that allow them to improve the code in a project as they build it. There is a truth in software development, the code you write today will change tomorrow.
If you feel that changing what you have already done is a waste of time, proof that you did it wrong or caused by clients changing their minds then you should quit writing code professionally. Whenever you write code be aware that it will change, so the smart thing to do is make it easy to change.

4. Designing the architecture for all the software before writing any code. The concept that you can define all the classes and methods before you start writing a single line of code is a path to disaster. I am tempted to draw analogies with sculpture or jamming in a music session but there are hundreds of these analogies out there and they clearly don't work. People still believe they can architect a software solution and then get programmers to build it. This just doesn't work. I have shipped lots of software in the last 25 years and I have never seen or heard of a single instance of this working. Software architecture is a skill that must be learned by everyone that writes code.
If you don't understand design patterns and core architectural concepts your code will likely suck.

5. Writing code to fit in with some design patterns chosen for the task. Design patterns provide a vocabulary to describe the patterns in the code. they are NOT patterns that will enable you copy and paste code to create a solution.
Often a pattern I initially thought would emerge in the code of an application doesn't emerge but other smarter patterns emerge. This happens because the process of writing the code and the feedback loops change the way I was looking at a problem.

6. The majority of programmers believe that bugs are inevitable. That's just like saying 'Lets write bugs'. To make matters worse programmers then expect to get paid for fixing the bugs they wrote. Let's clarify something here; a bug is some code functioning in an unexpected way. A bug is code that is wrong. If you find a bug fix it now. Bugs should not be stored somewhere, or left to linger. They should be destroyed.
If you keep a bug database you are tracking all the mistakes you have made, why not fix them? I do not keep a bug database for any project I work on, bugs are high priority tasks that must be completed before other work can continue that day. If you find you are creating bugs faster than you can fix them, stop writing code. If you expect to get paid for writing code that is wrong and then expect to get paid for fixing that mistake, go and do another job, you are doing the software industry and your reputation no good.

7. Coding for a J O B. If you go to work at 9 (ish) and leave at 5 (or earlier if you can get away with it) and never write code outside of those hours you will never deliver great software. You need to have a passion for software development if you want to deliver amazing solutions. Yes you will probably get paid for doing a JOB and delivering some half working solution. No, you should not be paid for this, in my opinion. It is the software developers that have no passion that create some of the biggest issues in this industry. It is true that most software is shipped by people who develop software as their job, it is also true that most software sucks.

8. Copy and pasting code from examples without understanding exactly what the code is doing. The clipboard development strategy to building software started sometime in the '80's but really took off in the '90's when the Internet started to provide lots of code snippets to add to the clipboard coders toolbox.

9. "Customers and clients are just idiots." I encounter this almost every week, developers that believe the clients are stupid and keep changing their minds about what they want. Guess what? The customer is always right. Clients know they need software to solve a problem, you are acting as a conduit to help them discover what they want. Often a client doesn't know exactly what they want to start with, it takes several feedback loops for their vision to become clearer. This is part of the development process. If you don't like rewriting code, throwing away work you have done, changing the direction of the project then go and get a boring job. It will suit your temperament much better, boring jobs don't have challenges or too much change.