You will write only as well as you make yourself write.

Substitute write with write software and it remains a truism.

Writing software is easy. Writing good software is hard. It takes discipline to become a good software developer. The only way to get there is to write better software today then you wrote yesterday. And the only way to do that is to learn from what you and others have written.

Clutter is the disease of American writing.

The same can be said for writing good software. It’s very painful to create or find a bloated method or class doing something it shouldn’t be doing. It’s even more painful to maintain. Small and simple works wonders within the design of a program.

Strip every sentence to its cleanest components.

Strip every method and class to include only the functionality it needs to do its job. Methods which might be used at some point – get rid of them. Comments which try to explain away complexity or ambiguity – simplify the code so it’s readable and remove the them. Classes which try to do everything – refactor and pull out things it doesn’t need to do into their own class or module. Clever code – turn it into simple code. Simplify, simplify, simplify.

You must know what the essential tools are and what job they were designed to do.

A carpenter must know how-to hammer nails and saw wood before he can build a house. Likewise, a developer must know how-to write good code, perform object decomposition and refactor before he can build an application. Other basic tools and skills that a developer should know are: writing testable code, testing and test automation.

Take your stand with conviction.

Care about the software you develop. Stand up for customer involvement. Stand up for short iterations. Stand up for testing. Stand up for quality, even when the deadline is fast approaching, it’s the best chance you’ve got for hitting it with working software.

Never hesitate to imitate another writer.

Never hesitate to imitate another developer, especially one that writes better software than you. It will make you better in the process. Find open source projects that exceptional developers have worked on and read that code. How are they attacking a problem? How did they solve it?

A while back a coworker asked me if I had read through Mephisto’s source and I said I had scanned it, but that I didn’t think it was anything special besides the routing. A few weeks later I started reading the source. Rick Olson, the author of Mephisto, has some great techniques and code tucked away in Mephisto, things that I would be missing out on if my coworker would have never challenged me to read the source. Thanks Drew.

…it’s hard not to be intimidated by the expertise of the expert.

Ask questions. If you don’t understand something, ask. If you think it’s a dumb question, ask. Let the resident expert enlighten you. When they explain something and you still don’t get it, ask clarifying questions. They didn’t wake up one day an expert. And neither will you.

Writing is related to character. If your values are sound your writing will be sound.

Developers who have character are exceptional people to work with. They not only write better software, they inspire those around them to write better software.

Decide what you want to do. Then decide to do it. Then do it.

For all of those “I want to learn language X”, “I want to start learning TDD”, etc. statements – start learning language X, start doing TDD.

Think small.

Two immediate thoughts come to mind. First, good object decomposition. Work with simple objects that work with a single responsibility and let the overall system evolve of those simple objects. Second, short iterations over long ones and short stories over full blown specification documents. Thinking small in these regards will help you produce cleaner and simpler code as well as produce the right working features – sooner.