As a proponent of perpetual learning, I like to periodically take the time to reflect on what I have learned. Looking back at this past year, I definitely expanded my understanding in a number of areas based on my experiences at work and at home.

My most significant growth was in the area of personal productivity: I read and implemented the organizational system described in the book Getting Things Done : The Art Of Stress-Free Productivity by David Allen. I have found this system very useful both at work and at home, and wrote an article describing my experience implementing the system.

This last year I switched to a four day work week, and have found it to be a significant improvement over the normal five days. I even figured out how to do this without a drop in pay.

One area of software development I have explored a lot this year has been change and release management: specifically the process of promoting application or infrastructure changes into a production environment. Both my experiences at work and my experiences running this website have made me appreciate the necessity of having a defined process. The amount of process that is necessary depends on the types of changes being made and the complexity of the environment. As I wrote in my article on deploying application changes, it is easier when the application is packaged and deployed as a single unit. When this is not possible - like for database changes - then more process is necessary. Adding too much process, however, can be just as harmful as having too little - a proper balance must be maintained.

Over this last year I have spent a lot of time thinking about application reliability. Ensuring a system is highly reliable is a surprisingly difficult task, and one of the major culprits is complexity. I have found myself arguing more strongly for simpler, more reliable solutions as a result. My most recent focus has been on error handling. My article on the fail fast and degrade gracefully approaches to error handling contains some earlier thoughts on this subject, but I have not yet written up my latest ideas. I have come to believe that the degrade gracefully approach, while more difficult to implement, is the best for creating highly reliable software. I have unfortunately encountered a third approach to error handling: ignore errors. This leads to silent, undetected failures whose negative effects go unnoticed for an arbitrary length of time.

I have also learned a number of lessons from running this website, including improving my knowledge of web design, promotion, and on-line advertising. I have found the process of writing my weekly articles to be a great learning aid. Writing forces me to reflect on and clarify my thoughts and ideas on a particular subject. It is no coincidence that I have provided a number of links above to articles I have written this past year. I tend to write about topics that are currently in my focus of attention, and the act of writing about them helps clarify and solidify the learning I have done.

If you find this article helpful, please make a donation.

Share this article: Add 'Lessons Learned in 2006' to reddit Add 'Lessons Learned in 2006' to digg Add 'Lessons Learned in 2006' to Del.icio.us Add 'Lessons Learned in 2006' to FURL Add 'Lessons Learned in 2006' to Technorati Add 'Lessons Learned in 2006' to Yahoo My Web Add 'Lessons Learned in 2006' to Newsvine 

Related Posts