Transforming Average Programmers into Power Developers

The term software crisis coined in the late 60s described the ratio of software required by industry to the inability of software engineers to deliver correct, understandable, and verifiable programs. Back then the problem was blamed on the relative high power of new computers and the general low quality of programmers.

And now 40 years on, our industry continues to suffer the software crisis, but not because computing power has outstripped programmer ability. And our crisis cannot be blamed on a lack of programmers; the world has provided an over abundance of programmers, so that's not an issue. But, as an industry, we still fail to deliver on a consistent basis. Here are some tips designed to help alleviate our crisis and improve the quality of our programming community.

1. Learn UNIX. Ok, linux, mac osx, or cygwin; the main idea is to use the command line in a well thought out shell. Good programmers program all the time, just like musicians practice scales. Every time you enter a series of commands into the command line you are excising your skills. When you learn the power of command pipelines to solve basic problems your are flexing your ability to solve problems pragmatically. Learn and use tar, jar, grep, tail, find, sed, awk, lex, yacc, etc. Use curl, svn, git, ant, make, ssh and scp. Find a good shell like zsh, bash, ksh or whatever and write scripts to help you organize your work. Write aliases that tame the command line. Write sed or egrep scripts to exercise your Regular Expression patterns. The important thing is that "Programmers program--always".
2. Expose yourself to as many languages as you can. You probably have one or two primary languages that you use on the job. Don't limit yourself to just those. Create a sandbox using subversion or git and create scripts in ruby, php, perl, javascript and python. Create java, action script, c++ sandboxes with either ant, gant, rake, or make files to build small applications. Learn new, or newly recognized languages like Scala, OCaml, Erlang, Haskell and Go.
3. Contribute to an open source project. There are a gazillion open source projects on the market now, most of them throw away. Rather than creating your own, join one that has a chance of succeeding. Read the project's standards and rules and begin by submitting documentation updates. Search the bug list and submit proposed fixes, complete with unit tests (don't bother with projects that ignore tested designs). After a while, if you pass the initial stages, you will become a committer--your right of passage to the open source community.
4. Read and re-read the APIs. The programming language that you primarily work in was created by several brilliant people that have devoted thousands of hours to create a useful platform. Don't ignore their work. Even if the platform solution may not exactly fit your situation, at a minimum, know what it does first before creating your own. Dive deep and read the platform source code.
   
5. Read the expert blogs. Posts to Object Mentor, InfoQ, Artima and experts like Martin Fowler, Ward Cunningham, Dave Thomas, Kent Beck, and a host of others. Find the blogs that are specific to your language. Look for web or pod casts.
   
6. Keep up with technology changes. IoC from Spring Source or Google, Agile and Extreme Programming, Rails Active Record, Hibernate, Apect Oriented Objects, JUnit 4, Flex Unit 4, DSLs, Patterns, Idioms. Lots to keep up with, some hype, others real.
7. Write readable, clean code. The definition of clean code is 1) code that is understandable by someone other than the original author, 2) package, class, and method names that are accurate and fully describe their intended purpose, and 3) code that is fully tested with a suite of automated test tools. Always choose readability over writability. As Knuth says, "A program is essentially a work of literature".
   
8. Read. Most programmers are in the habit of purchasing lots of technical books. That's great, but don't let them sit on the shelf. Read and re-read them. Dog-ear or sticky note sections that you want to re-visit. Highlight important points that resonate with you. And, don't just read the cook-book tutorials. Your library should contain a healthy mix of literature from publishers like Prentice Hall and Addison Wesley to offset your APress, O'reilly, Manning, and Wrox vocational studies.
   

I'm sure that there are more items, but these eight represent a good start. Happy coding!