19 Tips and Thoughts Toward Developer Productivity

Jon Gallant - My Thoughts on Developer Productivity

The best developers optimize every aspect of their lives. Optimization is built into their DNA. We are always looking for ways to not repeat ourselves and strive to make everything we do faster. Everything from doing the dishes to serialization. If it’s not as fast as it possibly could be, then we spend countless hours making it so. Now as a manager I get to code a bit, but a big part of what I’m responsible for is optimizing developer productivity. I have a long way to go, but I have definitely improved as a manager over the last 10 years, so I thought I would share what I have learned. Hopefully this will help the newbie and seasoned managers alike.

Hours

The first thing you want to do is set the expectation that your developers will be working very long hours. They should be working from the moment they wake up to the moment they fall asleep. If not coding that whole time, they should at least be thinking about code. I find it best to set mandatory in-office core hours from 8am to 8pm. That way they get in a solid 12 hours a day in the office and then they can make up the remaining 4 hours of their 16 hour day on their own time. It’s fine if they chose to come in earlier or stay later, but everyone must be in their office for core hours. Try roaming the halls at the start and end of each day and take notes on who is and isn’t in their office. That way you know who the really productive people are. You could also go the punch card route or you could require them to install a service that monitors their activity and alerts you when they aren’t meeting their numbers.

Meetings

....

Do not do “No meeting Fridays” or “No meeting afternoons” and put a 30-60 minute gap in between meetings so they can get a good 20 minutes of coding time in between them. At the end of the day they should spend 80% of their time in meetings and 20% of their time developing.

WFH

Working from home?….it should be…..“Xboxing from home” because you know that’s what they are doing all day. It’s a trick. Don’t fall for it. You can let them have every other Sunday to themselves if they are hitting their “lines of code” count and code coverage percentage for the month. But, never on a regular basis.

When someone says they need to work from home immediately schedule an early morning meeting and require them to be there in person.

Software

Cloud

DevOps

Hardware

Process

Quality

TIP (Testing In Production) is cool, but TIP-WAU (Testing In Production With Actual Users) is even cooler. If you want to know where the bugs are in your software then just ship it. Users will report any bugs. That way you don’t need to distract developers from what they do best...creating new features. Those new features may break other features, but as long as the new feature somewhat works it’s all good.

Rewards

Fun

Furniture

Food

Personal

Reviews

Training

Credit

Vision

Visions are overrated. You want to keep them guessing about what you are thinking. ...

Attrition?

...

The above was fun to write, but it is obviously very bad advice. Keep reading to see my honest take on developer productivity.

Hours

On my team the expectation is that you’ll work roughly 8 hours a day, but it is very self-managed. Some days you’ll work 10, some days you’ll work 6. I never track developer hours. The code you produce speaks for itself. I work an hour or so in the morning, get in around 9:30, leave at 4:30, then I’m back at it for a bit before I go to sleep. That allows me to eat breakfast and dinner with my family on a regular basis.

...

The funny part, in a sad way, is I'm not sure which is more valid in the real world, the first set or the last... :/