I used to read less than one book per year. According to Code Complete, this is the same as the average programmer.

That was while I was at uni though. I sort of expected to learn slowly at uni, and anticipated rapid, mind-blowing learning when I entered the industry. My first job had me working under some of the smartest people I have ever met - it was at a game company. Unfortunately they ran out of money and I had to find a job at a slower-paced place, where I didn't have the luxury of mentorship.

My mind was going stale, I had to do something. I looked up recommended reading lists online and the first programming book I picked up (that wasn't for a uni course) was The Pragmatic Programmer. Are you sick of me mentioning this book in every post yet? ;)

PragProg recommends that you treat your learning as investment, and your knowledge as a portfolio; you should invest regularly, diversify, balance it between high-risk and conservative, buy low and sell high (i.e. take interest in emerging technologies). It recommends several goals, such as reading a technical book each quarter, and when you've developed the habit, one per month. It also recommends reading non-technical books too. I totally fell in love with this idea, and have been reading like a mofo since.

There is a slight problem though...

Read the rest of this post »

I am currently reading Edward De Bono's Thinking Course (Author of Six Thinking Hats), which has an anecdote from one of his seminars; he describes a problem involving two pieces of wood, and the task of crossing a room without touching the ground. He accompanies this with a discussion of three approaches, one very inefficient, and one seemingly good. The third approach is much faster, but everyone settles on the second solution, because it seems good enough...

The 'shuffle' solution seems so obvious and so adequate that there never seems any need to set out to look for an alternative. Contentment with an 'adequate' solution or approach is the biggest block there is to any search for a better alternative... It is only through realisation of this and an act of will that we can set out to look for alternatives - knowing that in most cases we shall not find anything better, but still being willing to invest that thinking time.

I feel that this advice should be taken in reverse too. If you have a new idea for how to do something, don't dismiss it because people are already happy with the current methodology; they could be ecstatic with yours. Maybe a solution you think is too obvious isn't so clear to them.

I think many people sell their good ideas short, and become too attached to ideas that maybe aren't all that great. Regardless of the perceived value of your idea (within reason), you should test the waters. Run it by some non-friends (they don't mind hurting your feelings). It may be better, or worse, than you think.

I am currently reading Code Complete 2 as per Jeff Atwood's Recommended Reading for Developers list, where I came across this interesting quote by Glenford Myers:

We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"

I think it succinctly illustrates the need for balance in software design; it is just vague enough to communicate exactly what you need to hear.

I'm interested in hearing any other cool quotes, or book recommendations if you've got some =]