1. Don’t create prototypes
Clients do not know what they want. Managers do not know what they want. When you prototype, you learn about the constraints you are going to face and your audience learns what they can have and what is impossible. NOTE: Try not to use your prototypes for production code, they are meant to be prototypes. Learn from them and don’t just….
2. Copy the code
When you copy code one of these scenarios is likely to occur: either you don’t fully understand what it does or you may know but don’t think about refactoring it to be better because you expect it to just work. I know many of you out there see this all day long: someone copies code because they are lazy and don’t correctly create an abstraction, and they end up violating the DRY (Don’t Repeat Yourself) principle. Now when rules change, you have multiple pieces of code to change. Unfortunately, it seems that people who copy code also tend to believe that they should…
3. Leave working code alone
If you ignore old working code it will come back to haunt you. First of all, no code is perfect and when things change, anything that depends on those things could break if your code is any less than perfectly abstract. Second, you will (hopefully) gain knowledge and will be able to make that working code less resource intensive among other things. Don’t live with stale code it will only get moldy.
4. Write all code manually
Why not have that powerful machine in front of you do some of your work for you? Do not waste time writing the same type of code multiple times, either generate that code with a code generator or re-design your code so that you don’t even have to do that. It will make you more productive and you will be able to spend more of your day on interesting tasks.
5. Follow formal methodologies to the letter
No formal methodology will fit with all of the types of development you will do. You must be flexible enough to fit your methodology into the context of the problem you are solving or you are wasting time. Being unstructured is usually worse, so find your happy-ish medium :). Finally, the best way to suck at programming (well anything really)…
6. Don’t care about what you do
DO NOT WASTE YOUR LIFE PROGRAMMING UNLESS YOU CARE ABOUT DOING IT WELL. It’s a win-win for those who subscribe to this paradigm. While this can be taken the same way for many professions, I think it is especially important for software developers. Lucky for you it looks like you don’t suffer from this because you’re reading all this means that you intend to keep improving.
Maybe these were obvious to you. Actually, I hope they were. I have seen too many in my field that are too busy “writing code and getting things done” to really step back and look at what they are really doing. Share this with them if you can, it really will be better in the end.