A student asked me about design patterns in class about 6 years ago, and, although I knew the term from engineering, I wasn't familiar with any of the design patterns documented in the GoF text. How I wish I would have taken this guy up on his invite to meet for lunch after class!
The problem for me was my schedule. I was so busy working on so many things that I didn't have time to keep up with changes in my industry. Yes, I tried to read as much as possible from trade journals, but even this time was choked out by an ever increasing sense of urgency to meet deadlines and get software completed. What I needed was a design pattern for staying up-to-date in my field.
So what is the design pattern for staying afloat? I'm sure it's different for everyone, but for me it's recognizing the need to schedule time for professional maintenance.
Up until just a few months ago, I found myself working long hours with a partner trying hard to establish a reputation for getting projects done right and on time. You may be different, but what I've found is that software engineering is very different from other forms of engineering in that the level of unanticipated decision variables (unk-unks or unknown unknowns as Donald Rumsfeld likes to call them) is much higher than in other industries. This means that it's pretty risky to say that x can be completed in y weeks. On every project, we run into these unknown unknowns and yet we are still able to make almost every one of our deadlines? How? By working day and night for days on end and ignoring anything not related to the achievement of the goal.
I've learned to accept the fact that in most cases customers don't understand why you can't provide an exact estimate for a specific set of features. And while I may try hard to properly set customers expectations, I also believe in a fixed ship date mind set for software development. It's the best way to actually get things done. All this to say that while I'm working on a project, I've come to accept the fact that I won't have a lot of free time to read up on the latest developments in my industry.
But, what I do have control over as a consultant and what I would encourage many of you who manage a development staff to consider is the amount of time that is allocated between projects (or even during projects if that's feasible for the personalities of your developers) for continuing education in their field.
What am I talking about? Well, here's a short list of resources that I would recommend making available to your developers for self-paced study and research; and I would encourage you to plan for between 15 and 20% of your developer's time to be dedicated to using resources such as the following for professional development:
I've heard that Google allows their developers to dedicate 1 day a week to professional development. I think this would work great for some developers; but, for others, it would be best to plan for time between projects to allow for more extended and in-depth research. I've dedicated the last 3 1/2 months to research and I feel like I could spend another 3 1/2 months if it weren't for the fact that I need to make some progress on projects that are of significant interest to me.
I'm interested to hear back from you regarding how you or your development staff are managing to stay afloat.