I’ve been reading an excellent book, Head First Design Patterns, which covers many of the Gang of Four’s famous design patterns for software engineering from the Head First series own irreverent and creative perspective.
Design patterns are great; they are a useful shared vocabulary for discussing software design and a source of inspiration for your day to day programming. However, as the GoF and the Head First book point out, design patterns are not invented, they are discovered by working with real world applications whose unfettered complexity has lead to unexpected problems. Or more succinctly, they emerge out of encountering and solving pain points.
The danger with design patterns is that you learn them, apply them liberally and then complain about the extra overhead and up front design time. This danger lessens the more and more you’ve actually experienced the pain of clunky and obtuse code. As with most of life, experience is the best and most bitter teacher.
I was further reminded of this when I was recently talking to a friend who mentioned GTD or getting things done, a time management philosophy that encourages creating and executing to-do lists, among other productivity tips. I am not a strict adherent to GTD, but I discovered I did follow one of its most well known off shoots, the idea of a clean email inbox or “Inbox Zero.”
As the name suggests, the idea behind Inbox Zero is to have no emails sitting in your Inbox. This does not mean automatically deleting every email or anything that dramatic, but instead it means expediently applying one of the following actions to every email that comes in:
- Delete
- Delegate
- Respond
- Defer
- Do
There are plenty of resources available online to more fully explain this, but it boils down to making a decision about every email that comes in (even if the decision is to defer your decision) so you never get overloaded with too many emails.
I began following my own form of Inbox Zero after going through a period of time in a project where I got at least 100 emails a day and was going crazy trying to keep up with them all, alternating between frantically trying to respond to each one immediately and a kind of exhausted “benign neglect” of any email without at least a few exclamation points or priority flags.
So, like a design pattern, out of a pain point emerged a general approach to me organizing my inbox. Also like a design pattern, the point of a clean inbox is not to follow Inbox Zero techniques for its own sake, it is help manage complexity and reduce pain points. Process does not exist for its sake, but to alleviate a certain problem.
In some ways it would be much easier if this were not the case. If we could create great software solutions every time by using the Decorator and Factory patterns or never get behind in a project by sticking to Inbox Zero, our jobs would be a lot easier.
However, we certainly cannot. Our primary job is to identify problems and then develop solutions for them, whatever the techniques along the way. This is why we sometimes struggle to identify a clear methodology that we use or a strict definition of what we are looking for in an employee. On the flip side, this is also what makes our work so interesting and rewarding.
A few weeks ago, I attended 2 sessions of the SoCal Rock & Roll Code Camp at the USCD Extension campus. This is an event I’ve attended before and always enjoyed. This year was no exception, as the event was well organized, the schedule was well communicated and the two presenters I saw were good.
The two sessions I attended were Integrating Silverlight 2.0 into an Existing Web Application and Using ASP.NET MVC to Build a Blogging Engine in 60 Minutes or Less. The Silverlight presentation covered some general ideas on how to take an web application you already have and add Silverlight content to it. In particular, I appreciated that the presenter, Robert Atland, emphasized thinking carefully about where to use Silverlight so it is not just a gimmick, but actually enhances the user experience.
The ASP.NET MVC presentation was more of a mixed bag. I didn’t start my programming career in .NET, instead I started in Java where MVC is a much more common paradigm. So MVC as a concept is not new or difficult for me, especially after spending some time recently with Ruby and Python web frameworks. For ASP.NET MVC, Scott Gu provides a brief overview here.
However, a lot of the attendees were new to MVC and used to .NET’s postback model. I think this tripped up Adnan Masood, the presenter, and he spent most of the session valiantly trying to explain the Model View Controller architecture, as well as defend the idea that anything could be better than the postback model. Nevertheless, I thought he did a good job and the ASP.NET MVC framework is worth checking out.
More recently, somewhat inspired by this positive experience, I attended a user group meeting for a non .NET language and had quite a different experience. There is no point in me going into great detail, but the group, although full of what seemed to be very nice people, was incredibly disjointed and vague in it is direction. Almost no content was presented and no particular agenda was followed.
I was more excited about the content I thought would be presented at that user group than the content at the code camp, but the code camp was a far more satisfying experience. So kudos to the folks at the SoCal code camp; it is tough to carve out time outside of work for activities like this and they made me feel like my effort was more than reciprocated.