Archive for Category ‘Productivity‘

 
 

Blogging as a Habit

Breaking habits is a slippery slope. You work for months, or years, to build up certain behaviors that your body and mind get used to, but it only takes a few weeks to break them. Maybe you’re changing jobs or going through some major life issues, but once routines are stirred up it’s a lot more difficult to get them rolling again. Me, along with most of my former Westgaters, all seem to have gotten off the blogging train these past few months.

So what can be done to get back on track? It’s as simple as taking one step. Then another. Often starting back up in a routine seems a bit daunting, but if you just take the step things start to build momentum. Reading little pushes like that, or the occasional Zen Habits post might be sound nice, but it still requires you making the effort and doing that single step. I’m going to try to get back into the blogging habit a little more myself, as there is no shortage of new material to blog about lately with a new side project, a new job in a new language/framework in a new part of town.

Tools Make the Difference

How much difference do the tools you use affect your productivity? That’s nearly an impossible question to answer. Books like Joel on Software or his bible Peopleware are more about how to be productive than how to write good code (for that try Code Complete). Although some of these tips can’t translate to a normal office (such as giving each programmer their own enclosed office), most suggestions are more easily palatable to management like multiple monitors or slightly improved workspaces. For instance, about 8 months ago our team at Westgate had experienced some much needed growth and needed to be split up into 3 rooms for developers instead of 2 interconnected ones. Although this meant we weren’t as close, and we no longer knew what everyone did the previous weekend, everyone I talked noted huge productivity gains in the days that followed. Quieter workspaces is on the Programmers Bill of Rights after all, so it’s probably no surprise. That’s not bad for just rearranging people but are gains like this possible from any tools or initiatives?

Multiple monitors seem like a no brainer for increasing productivity. Although 20%-30% sound high, I don’t doubt it. Assuming you’re not just working in your IDE, not having to tab around just to see everything will save you time. Multiple monitors are great, but what I’ve never quite understood is how people can use a single huge monitor effectively without some kind of software for splitting up screen real estate. With many of the Mac setups I see, for instance, there’s often a huge 24″ or 31″ monitor looming over the developer. Although this might work when a designer might need to see a large portion of an illustration, I don’t see how a single huge monitor could be better than two smaller monitors for most developers. With the smaller ones, you’ll need to spend time dragging from one to the other to get setup, but for the most part all applications will remain maximized and out of the way. With single monitors it seems lots of time is wasted repositioning everything. Also it’s more distracting looking at a monitor that has multiple apps on parts of the page rather than one maximized. For my home setup I went with multiple monitors of course, and can’t imagine trading them in for a single large display. What do you prefer, a huge monitor (24″+) or multiple smaller ones?

What programs make the most difference will be heavily skewed from one person to another. Little things like using TortoiseSVN rather than Eclipse’s much slower Subversion tools might not seem like much, but some people notice the difference and save a little time. Using a different text editor or web browser can make that difference as well. Since just about every developer uses Firefox, it becomes more an issue of finding the right extensions. As web developers though, most our time is spent in our editors, some shell, a web browser and a database tool — why not use the best of each?

I’d agree with many of the sentiments in the previous replies though — the tools we use are important. On more than one occasion Hal Helms compared the software and hardware we use as developers to the tools he used as a craftsman constructing chairs (7 – Tools We Use). You wouldn’t use a dull knife, why use a dull program?

New Year and a New Look

I’ve been neglecting this blog for quite a while. The main reason was that I wasn’t satisfied with how it looked, which was more of a deterrent than I would’ve guessed towards posting. Whenever I started writing something up I ended up tweaking the design instead. Instead of trying to fix a broken layout, I decided to go with a an entirely new one for now. Clean, cool colors and easy to modify.

Another new direction for this blog will be the topics I’m posting on. In the past I was primarily talking about ColdFusion and framework, with a side of microformats and web standards. Lately though the only exposure I’ve had to ColdFusion has been at work, where the Java/ColdFusion/Flex stack is still going strong (for the moment at least). In my spare time Ruby On Rails has been the major motivator, with the new project I’m working on being the driving force. Although some work in progress posts will be over there, I’ll be posting more on Rails here as well.