Thursday, April 22, 2010

On Salary Ranges

I have recently participated in several conversations on how salary ranges are used in various companies. I’m not speaking now about large corporations which need to synchronize ladders across offices and departments, but of micro- and mini-ISVs.

Many of the problems I heard of come from a simple mistake of taking these ranges too seriously. Far too often managers forget that every developer in a small team is individual and bound his career path to a predetermined grid.

In reality these ranges should not constrain, but help managers when he is not sure about the pay. Whenever you know exactly which compensation certain employee deserves, you shouldn’t try hard binding it to the grid.

Sunday, March 14, 2010

The Real Value of Productivity Tools

If you look around in 2010 you will see how well people are working together. Modern tools let them collaborate and create amazing things. Wikipedia and Flickr is what comes to mind first, but there's a lot more. Many contemporary thinkers point out that the social tools we have now thanks (mostly) to the Net help us care more than ever. Take Wikipedia: despite a number of failures, in general it shows unbelievable ability to remain a source of (mostly) accurate information, resist vandalism and get up-to-date faster than anything.

The power behind this fenomenon is collective care of people plus easy-to-use tool. If someone sees an inaccurate or broken page, it takes seconds to edit text or restore a previous version. The easier the process, the less motivation one needs to act.

This perfectly applies to software development as well. While some think that quality results are product of centralized organization and thought-out architecture, a lot depends on attention and care invdividual developers pay to the code. An architect might not have enough time to know entire codebase, but when an attracted developer does his job, he sees unused code, complicated methods or overly architected subsystems. It hurts, and the easier it is to fix things, the more chances he cleans up the mess.

Productivity tools are the ones which remove hurdles to making code improvements. Refactorings, code analyses, quick fixes and code cleanup are some of many features offered by tools like ReSharper and IntelliJ IDEA. Managers often consider them luxury or toys but in reality these are the tools that help team show their care. You should never underestimate the effect. If someone conducted a study showing how code quality changes over time in teams using and not using productivity/refactoring tools, I'm sure the results would prove my point.