Signal-to-Noise
One thing someone asked me was, "How do you take on so much? Between a full-time job, your blog, your open source projects, training, and being with your family, where do you find the time?" Obviously, we all have the same hours in the day. One advantage I had was starting my own business and running it for several years. This forced me out of my comfort zone and required that I learn about sales and marketing. It also forced me to examine my time and learn how to maximize my time and organize my day.
I'm a huge fan of the "rule of three" that is a simple method for setting goals. I don't follow it religiously but the gist is simple: set three goals for today, three goals for the week, three goals for the month, and three goals for the year. Obviously the longer goals are bigger ones, and the shorter goals are baby steps to reach it. I'm constantly re-evaluating my goals and adjusting as I go, and even wrote myself a letter with some commitments for 2010 that I’ll open January 1st 2011 to see how well I did and then write another letter for next year.
One thing I am constantly aware of is my signal-to-noise ratio. In fact, the easiest way to explain this is to look at how I manage Twitter feeds. On the "publisher" side it would be extremely inefficient for me to scour the Internet all day long for information to post. This would disrupt my workflow, and take time away in chunks throughout the day. In essence, it would introduce noise that I don't need. During working hours, the "signal" is the work I do with Wintellect, so remaining focused on that outside of scheduled breaks is paramount. Instead, I allocate time in the morning (I get up between 5 am and 6 am) to review feeds and posts, and then schedule my informational Tweets. I know that dumping a dozen links on you would also be "noise" for you, which is why I have the tweets released on a schedule so you have time to absorb and respond to one before the next goes out.
As a "consumer" I do something similar. I follow a lot of people. Some people are interesting, some are friends, some I follow as a courtesy and others are great sources of information. Again, if I were to wade through the full stream of tweets I receive, I would be drowned in noise. I can't tell you how many people insist on posting nothing but FourSquare updates or tweeting about how they just walked to the mailbox. This is noise. So, to avoid that, I create lists. I have lists for Silverlight developers, for people who use or talk about MEF, and for people in the local area. My most valuable list is the "Signal" list. People with valuable information make it to that list and I scan it frequently. People who mostly make small talk or have their Twitter linked to games usually don't make it or stay on that list.
Signal and noise happen in other areas as well. When your work day is finished, what does the rest of your evening look like? Watch a movie? Noise. Read a book about unit testing? Signal. Watch the game? Noise. Build a reference project to learn a new concept? Signal.
Don't get me wrong. We all need a little noise. I take breaks during the day to read fiction novels and watch shows like "24." It's just that I am always focused on the ratio and try to keep the signal end as high as possible. That's why I sacrifice a lot of sitting on my thumbs or watching TV for doing things like my open source projects, blog posts, and writing. Oh - one more thing. Being forced to watch a show because it comes on at 8pm? Noise. Watching it on demand when you're ready? Signal!
Return on Investment
The next area I commonly focus on is return on investment. I'm constantly evaluating what the ROI of various activities is and prioritizing the ones with the biggest returns. It's like a personal stock market - I want to invest heavily in the stocks that are poised to produce major gains, but I'll still round out my portfolio with some others that may be higher risk and/or lesser yield. Where are some of the areas I can improve my return on investment?
In development, I can think of several ways. Building a new framework from scratch for each new project might be fun, but it certainly is a big investment. Creating a reusable framework based on common patterns I see in different projects is an enormous return on investment because I can slash days from projects by having the foundation ready, "out-of-the-box." Jounce is an example of a project I was tracking internally and eventually released so others could take advantage of it as well.
Unit testing is another example of ROI. I know many developers who still shy away thinking unit tests add extra ritual/ceremony, provide little value and will only add time to the project. I value unit tests from experience because I know I will receive a major return on the initial investment. In Silverlight projects, unit tests enable me to finish my view models before the design-team has written a single line of XAML for the views. In projects like Sterling, it saves me hours when I make a major change because I can run the unit tests and make sure the major pieces of functionality haven’t broken before checking in a change.
Being organized with my emails is also a huge ROI. People have different approaches to their inbox. Personally, I focus on an empty inbox. The trick, however, is that I don't always respond immediately to emails. When an email comes in, I may respond if I can. Otherwise, it will get filed in a set of folders by topic (this helps me narrow searches when trying to find older correspondence) and flagged. Outlook makes it easy to right click and turn an e-mail into a task, so I can constantly track items I need to return to.
Tools can also provide a return on investment. For me, software like ReSharper makes me far more productive than I would be without. The short cut keys, refactoring tools, and rule checks all help me develop quality code faster. If you are typing out every key word and manually implementing interfaces, your ROI is suffering. Knowing the short cuts and getting familiar with them will only help increase your ROI as you develop code.
A final thought on this is patterns. I've heard people complain that patterns are too prescriptive and often people follow them just to say "Hey, look, I implemented a chain of responsibility." The truth is that patterns are very powerful and useful, and help to increase ROI. I like to refer to this as "pattern vocabulary" or how knowing a solution can change your way of thinking. If you haven't been exposed to a way of doing something, it is harder to figure it out when you need to solve a problem. When you are very familiar with different patterns and solutions, you use this vocabulary to tackle problems and start by applying patterns to see if they fit. This can have a hugely positive impact on your productivity levels - to me, learning patterns is a huge ROI.
Return on Aggravation
The last piece is a phrase I learned from a former boss so I can't take credit for it, but it is a powerful idea. It's "return on aggravation." Most of what you do each day may come with a level of aggravation. The question is what levels are reasonable, and when the ROA is greater than the ROI.
As an example, consider writing a book. It's a goal that I have, and I've considered some offers and projects. However, right now, I haven't taken on a full project because the ROA is too great. The ROI is a little bit of cash (most technical writers know you don't write technical books to get rich) and a lot of recognition. There is an intangible reward for taking something I am passionate about (teaching and mentoring) and creating a vehicle to get it out there. The aggravation is the time commitment and things I would have to sacrifice to make it happen without driving my publisher, family, and eventually me, crazy.
Another example is forum posts. I love visiting the forums and helping where I can. I also am happy to share my experiences when some posts are opinionated and looking for feedback. These types of discussions, however, can quickly revert to back-and-forth arguments and debates. There is very little ROI (most often the urge to post a retort is just to get the last word in and say, "I'm right") and a lot of aggravation, so I typically stay out of those types of discussions on forums and Twitter.
You may find the ROA factors into your job as well. I've been in positions in the past where I had to look at what I wanted to do with my career and how much ROA (commutes, old technologies, 3am debug sessions) existed. One of the reasons Wintellect is such a terrific company for me is because the ROA is very low, compared to the ROI of working with a talented group of peers on amazing projects. It's important to note that I didn't just stumble into Wintellect - I had to make a decision and focus on taking the steps I could so they would consider me for the position.
You might think writing long blog posts like this also raises my ROA, but it doesn't. I actually enjoy blog posts because they are a less formal tone and help me offload thoughts and ideas. There is a bit of aggravation related to the time it takes but the ROI of being able to express myself and then create connections from the people who benefit from reading the posts far outweighs the cost.
One last area that ROA factors in is what some may call "over-engineered frameworks." I've been guilty in the past. I'm a big fan of frameworks that help steps magically fall into place and reduce the burden on the developer. However, I've also found that in many cases, the perceived ROI is actually quite small compared to the ignored ROA of developing it. You’ve probably done it, too. Have you found yourself spending hours or days trying to build that magic construct that uses recursive reflection and T4 templates so you can configure an item with an enumeration instead of a magic string? Do you suspect that sometimes the ROA of the time you invested in that solution, the complexity of maintaining it, and the performance hit it causes the application during runtime might perhaps outweigh the ROI of enforcing a value that might easily have been addressed by a few constants? The constants might not be as elegant, but it's important to keep in mind the entire scope of the system when making impactful decisions within your software.
So there you have it, in a nutshell. While I do fit a lot into my schedule, it is always in the context of understanding how each decision, step, post, or line of code will impact my day. I am constantly trying to raise the signal and lower the noise, increase the ROI of what I do while keeping the ROA low.
How about you - what are your techniques for maximizing your productivity?
