Friday Linkage
Some of the web pages I found most interesting this week:
Mentoring is something we do not see enough of in this industry especially compared to other industries e.g. tradesmen where new workers have to serve under a master tradesmen till they learn their craft. I personally find one on one sessions very valuable to my personal growth but only if I am having a one on one with the best people available: why learn from anyone else other than a master?
The definition of Done is Badly Named
I’ve written about what done looks like before as it is something software engineers get wrong a lot: every witnessed an engineer claiming they are 99% done on a tasks for days? This brief article points out that we should not consider done as a concrete definition but as a flexible concept that will change and grow over time: evolving as the scrum team does.
Advanced Segments and E-Commerce
This post on the official Google Analytics blog provides an good overview and introduction to the segmentation features that were recently added to the Analytics service. It also demonstrates their capabilities to create custom segments to help analyse and understand your websites traffic patterns.
This Google service that lets you register your domain and then view GoogleBot‘s view of your site. You can upload sitemaps too to help GoogleBot index all the pages on your site correctly. You can also check out statistics for your domain like top search queries, crawl statistics and subscriber statistics too. The service also diagnoses common problems detected by GoogleBot like broken links, HTTP errors, times outs and unreachable URLs. Very useful for anyone running their own website.
Quick Security Checklist for Web Masters
Another post from a Google Blog this time from the Webmaster Central blog. It is an old post but still useful as it provides a short checklist of basic security checks to preform for your website.
Effective Work Breaks
I have made an interesting discovery since I started taking our new puppies to work with me: I actually seem to be more productive now than I was before I started taking the puppies to work! The pups generally need to be taken outside to relieve themselves and run off some energy every hour or so for about ten minutes. These puppy induced breaks are fairly practicable and not skippable unless the pups are asleep at which point I think it is better to let sleeping dogs lie.
Previously I had been using programs like Work Rave and Anti-RSI to make sure I’m taking sufficient work breaks, mostly to keep me sane and free of RSI like injuries (I still recommend these programs). I confess I am guilty of skipping breaks suggested by these applications fairly frequently, which perhaps is not a smart thing to do as it increases the likelihood of fatigue, injury and lowered productivity. I had thought this system to be effective but I’m finding puppy breaks even more effective: possibly due to the lack of a skip option. As puppies with full bladders cannot miss a break without risking an accident!
I think perhaps this lack of a skip option to puppy induced breaks is giving me more of a sense of having to make the most of the time between the breaks, this is helping me focus which results in increased productivity (which is not what I would have expected). This is a most welcome and unexpected side effect to having the puppies at work with me: aside from the obvious benefits of canine companionship and having a very good excuse to go for a walk at lunch time!
I have found over the years that any sort of regular break gives me a chance to pause and reflect about my current task and that is very useful for considering options and possible solutions to problems. The end result is that stopping to reflect about what I am currently doing regularly results in a superior end product than just hammering away at a task.
Do you have regular breaks and do they help or hinder your productivity?
Writing dirty
Starting to write something new like a new application, class, feature or any written work like an essay or blog post even can be very daunting. Defiling the blank screen or sheet of paper with your first scribblings can be very intimidating as you know you probably will not get it right the first time. This can lead to avoiding starting a task: especially one you are unsure of where to begin, even when you have the required technical ability to complete the task.
I experience this myself from time to time: I know what I need to do but I am unsure of where to begin and I will find myself actively stalling starting the task and do anything else instead. Later I will do the task and wonder why I put it off for so long: completing the task is easy but starting is somehow hard. The best way I’ve found of combating this sort of block is something a friend introduced me to and they called it dirty writing: it has nothing to do with erotica (sorry!).
The core of this method is that when you go to start a task you start writing immediately: it does not matter if what you are writing is any good or even compiles. It just matters that you are putting something down that you can then re-factor into something worthwhile. Otherwise it is very easy to sit at the ‘not sure where to begin’ stage for a long long time, which is highly inefficient.
For example if I am writing a new feature in a C++ application I will generally get started by:
- Creating the new source files for the new classes and associated unit tests.
- Adding the new source files to source control.
- Inserting the skeleton infrastructure into the files e.g. include guards and empty class definitions into the header (.h) files and #including the headers from their implementation (.cpp) source files.
- Define the test classes and their test methods for the methods of the new classes.
- Start adding methods and member variables to the classes in the header files and add empty implementations in their source files.
I find the above works quite well as defining the unit tests before I start to define the feature classes helps focus my mind on the interfaces of the new classes and what it is exactly that I require to implement the new feature and no more. I find if I start by writing the new feature first and then the tests that my implementation tends to end up more bloated with unneeded methods and code. You will notice that steps one to three are pretty basic, no advanced design or thinking is required, they just serve the purpose of gaining momentum in the task until I reach the stage I can start in on the meat of the task at hand.
How do you get past the mental block that a blank screen or piece of paper or empty source file can cause?
