Productivity. It’s something that all of us, as developers, should be finding ways to increase. I say should because I know of a stack of people out there who don’t. In fact, there’s a surprising amount of people out there who are not only not looking to find ways to increase productivity, they seem to go out of their way to reduce it - and this doesn’t just affect their own output, it affects that of the people they work with.

This is going to sound like a bit of a whinge, but I don’t mean it to I have a few frustrations when it comes to my routine that I would like to share, and see if you guys/gals feel the same, or have other things that you consider to be a hindrance while working.

• Typing speed - The first thing that most of you will think when you read that first title is “learn to touch-type”. And yes you’re right! But I have already. I learned to touch-type back in the days of university when I was well and truly frustrated by the speed at which I could get my ideas down in code. Thankfully, I’m nowhere near as slow as I used to be, but I’m still nowhere near as fast as I’d like. I don’t think this is something that people should use as a measure to determine if one developer has a higher output than the other, because quality of what is created is just as, if not more important, than the amount of code produced. There’s no point in having lots of code if it’s all rubbish. But that doesn’t mean that being a two-finger typist is justified either. I’ve worked with a fair few dudes who type so slow I feel like going to sleep when I sit next to them. I find it quite strange that they don’t feel compelled to learn to increase their typing speed just so they can get things down quicker. But I digress, this isn’t about other people, this is about me. I think that I’m close to having my fingers move as fast as I’m able to move them. Sure, I need to increase my accuracy, and I know that I could probably get the pace up just a little more, but I doubt I’ll ever reach the break-neck speeds of the really good typists (and that’s not just because I’m writing code instead of normal text). I don’t know about the rest of you, but the QWERTY keyboard layout can be painful to type on at faster speeds, which isn’t surprising considering it was designed to slow typists down in the ol’ days. I’m actually considering the possibility of learning to touch-type using the Dvorak keyboard, just to see if the layout changes do actually allow for a decent improvement in typing speeds.
• Knowing your Tools - This relates to my other post regarding IDEs and text editors. Finding the tool(s) which allow you to do the job the fastest is half the battle - mastering them is the other half. Mastering VIM/EMACS can be a huge task, but the benefits are massive. Learning to utilise all the features of a rich IDE can also take quite a bit of time and practice, but the payoffs are well worth the effort. If any of you have worked with a “click-n-drag” or “drag-n-drop” coder in the past then you’ll know what I’m talking about. Knowing the tool, and the shortcuts that go with it allow you to drastically affect your output. Of course, there’s more to the “tool” category than the stuff you write code in. There’s the compiler, the build system, the software environment, the version control system, and a stack of other things. Until you nail all the things you use daily, you’re never going to work at an optimal level.
• A non-obstructive Version Control System (VCS) - I know I’m possibly opening another can of worms by saying what I’m about to say, but I’m going to say it anyway. There are a plethora of VCSs out there, most of which do a really good job. There are some that quite blatently suck to the point where they’re almost not worth having, and others that just go over the top with tweakability and bind you too strictly to a long and drawn-out process that they also become ineffective. I think the key is to find a VCS that’s going to allow you to do what you need to do on a daily basis in an efficient manner without being burdoned with an overly elaborate process which takes more time to follow than it does to do your job (*cough* Rational *cough*) In the time I’ve spent working as a professional, I’ve had the (mis)fortune of working with VSS, Perforce, Rational, SVN, CVS and AlienBrain. I’m not going to go through and give a review of each of these bits of kit as that would be worthy of a whole new blog post (perhaps I’ll do that down the track), but I will say this: SVN and Perforce are stand-out performers (with their own pros and cons). I am yet to use VSS2005 with TFS, but I’ve heard that it’s a drastic improvement on the otherwise unstable (and old) VSS. Of course, these systems may prove to be way too complex or not good enough depending on your needs and the size of the team/project you’re working on.
• Interruptions - I’m sure I can speak for 99.9% of the development population when I say that constant interruptions are just a P.I.T.A. when it comes to trying to get things done. Now, depending on how lucky, or unlucky, you are, you may find yourself in a position where you tend to be a fairly regular point of contact for a lot of people. It could be that you’re a knowledgable developer with a certain language, you may have a strong understanding of the software and its architecture, you may be Team Lead or Lead Programmer and hence are a point of contact for the managers/clients/end-users, you may just be a nice person that people like to talk to! At the end of the day, the interruptions can hinder the creative process and have a detrimental effect on your output. Yes, I find this frustrating despite the fact that I know it’s part of the job That doesn’t mean to say I get angry with people if they want to talk to me, it’s more that when I’m getting into my work I like to get it done.
• Meetings - These drive me nuts, purely because I’d be lucky to attend 1 in 10 meetings which actually feel like a good use of time. If there’s one sure fire way of killing of a good couple of hours where you could be working, it’s to hold a meeting. I’d like to say thanks in advance to anyone who may respond and tell me that it’s well within my power to change the way these meetings go, but I think we all know that in a real world scenario (particularly when you’re working on-site) there’s a pretty good chance of you not being able to control it. I have, on more than one occasion, got up and left a meeting half-way through because I have felt that it’s just been a huge waste of time. It’s easy to get away with a stunt like this when you’re a permanent employee, or perhaps a Team Lead where your time is perceived to be quite valuable. Unfortunately, we’re not always in a position where taking this option is feasible. The best we can do is try and push the meeting in a direction where there’s a remote chance of getting some value before the hours tick by.
• Rubiks Cubes - I find these addictive! If I have one at my desk, then I feel compelled to play with it in the hope that the practice will aid in my target of consistently finishing it under the 60-second mark. Anyone who’s worked with me will probably know exactly where I’m coming from Yes, it’s a bad habit, and I’m doing all I can to rectify it. For now, it’s best for me to remove any evidence of cubes before I start my day
• Other people - This point does fit in with the point above that talks about interruptions, but I think this is worth mentioning on it’s own. The above point talks about being interrupted by people because you have a role or a set of knowledge that requires people to constantly talk to you. This point covers those people who constantly interrupt you for no apparent reason. They may feel they have a good enough reason, eg. to talk about how tanked they got the night before, or how so-and-so did something stupid at the Christmas party - but let’s face it, after hearing that story 5 or 6 times, the tiny amount of novelty you might have got out of it the first time has worn off. Then there’s the guy who, despite his every effort, “just doesn’t get it”. So you end up having to explain something to him not once, not twice, and not three times … but n times (where 3 < n < ∞). Call me impatient, and say that I’m a bastard who should do all I can to help the guy, that’s fine - but there comes a time when whoever it is should be able to understand it.

So there you have it. Some of the things that I find frustrating about working from day-to-day. The list is far from exhaustive, in fact there’s one that I’ve missed intentionally because it’s going to be the subject of another post:

The use of all the latest and greatest buzzwords without first determining if it’s useful to the project.