Companies often feel that they are getting the most out of their employees if everyone is working as hard as possible for as long as possible. However, this can be exhausting on the employees and can lead to diminishing returns. We feel that the better approach is to emphasize efficiency over effort, and our level of productivity speaks for itself.

Working in a ROWE gives us an advantage in working efficiently because we can better handle common productivity pitfalls. Stress rears its ugly head in many projects. In a typical 9-to-5 (or even later) the employee is chained to their chair and must work until the end of the day, or until a moment of escape presents itself. How much work is actually done in those last few hours as stress goes up and morale goes down? Because we have the freedom to work when we want we are able to step away from our projects for a few hours, do something that relaxes us, and try to tackle the problem in a better mindset. Given the break time we may work fewer hours in the day overall, but those fewer hours produced more than the stressed employee. The resulting code is also likely of a higher quality due to the more focused employee making fewer careless mistakes.

We are also able to avoid burnout by taking advantage of productivity bursts. Every developer has been on a programming tear, where they are able to crank out code at a blistering pace and don’t want to stop for fear of losing momentum. When they are done they may have completed a day’s work in a few hours. What to do next? Whatever you want, as long as you’re meeting your client’s needs.

Emphasizing efficiency over effort leads to happier employees, fewer errors, a higher quality product, and happy clients. Everyone wins. What other strategies can you use to maximize efficiency?

The post Working Hard or Working Efficiently? appeared first on Big Nerd Ranch.

After a week of working at Highgroove I am impressed at our efforts to provide everything a developer needs to start creating the best software possible through the right hardware, tools, and support. For someone like myself, who had lots of programming experience but knew little about Ruby on Rails, this was invaluable in getting me into the Rails trenches and helping my client.

Although I received lots of cool things on my first day of work nothing stood out like the shiny, new, top of the line Macbook Pro sitting on the table. It put the other work laptops I have received, a Windows XP Dell and a worn out Apple Powerbook, to shame. Our policy on tools also separates Highgroove from the rest of the pack. In other places I would have to do a sales pitch to negotiate my way into the sea of paperwork in order to get permission to use a non-standard tool that might help me get my work done. At Highgroove it is not only encouraged but required that I get whatever I need to do my best. If there is a tool unknown to the team that I think will help, I am required to show it off in case it might help them in their work.

The most powerful tool in getting a new developer up to speed costs nothing but time. I’ve never had an employer that used pair programming, but we encourage and require it. Having someone with more Rails knowledge available to bounce ideas and problems off of gives more insight into the development process than any book or tutorial ever could. Several of the software bugs that caused me to spend too much time banging my head into my desk were quickly resolved through pair programming. No two developers think alike, and having a second thought process in the mix helps avoid lost time and benefits both partners in seeing how the other operates. Now I wouldn’t work anywhere that didn’t encourage it.

The post One Week In appeared first on Big Nerd Ranch.