One way to look at improving developer productivity is to consider the destructive, inefficient, and time-wasting habits that happen in the workplace. People tend to point out the actions and processes that hinder productivity. However, here we are framing the discussing of boosting productivity in terms of things that help not hinder.
Developers & Productivity
Developers are a sub-genre under the creative personality type. They work with what has been called “logic-based creativity,” and when allowed to do their thing, you’d be amazed at what software developers create. They do often need their space, extra time, and inspiration to write amazing code. A pat on the back never hurts. Unless touching is a no-no for someone – then verbal recognition will likely suffice.
When a job has deadlines, project specifications, bosses, and a time clock, here are ten things to help increase developer productivity and overall business success.
1. Physical Space
Let your developers and other creatives have their space to stretch out, like free-range chickens. Whether it be their own office, a separate cubicle, or a different location. If one particular developer loves a window to look out, find them a seat by the window. If a dark corner is their preference, there should be a few of those around the office.
Alternate Locations to Work From
Today, many tech jobs are remote. Employees are working from home, from shared workspaces, and even cafes. Some employers offer split days with a minimum required amount of time spent in the office, and the rest can be from another location. Developers often thrive outside of the office environment. They have their space exactly where and how they like it, and can change it up as needed to help them focus on getting their work done. So, make sure wherever the location, your developers have the space they prefer.
2. Proper Tools
Having the right tools is vital in any job. For developers to be most productive, the right hardware and software are a must. Find out what tools and programs your team likes to work with. Find out what will work with the tools already in use. And ensure that developers can collaborate if necessary by having compatible software.
Updated hardware is a necessity for effectiveness when writing code and dealing with backend development projects. Also, set policies for how and when someone can obtain new equipment. Set budgets for employees, but don’t get upset if a necessary piece of hardware has to be replaced and will cost you a little more. Remember, it’s an investment in your employees. Happiness can be a new computer that makes their jobs easier. That happiness equals increased productivity when it’s on the company’s dime.
3. Allow for Flow Mode
Letting your programmers do their job is vital, and often overlooked until an error or a deadline pops up.
Flow mode is what we call it here at ExaVault. You may refer to it as something else such as:
- Being in the zone
- Flow state
- Focus time
No matter what you call it, closing yourself off from distractions and spending a chunk of time on one specific task can boost productivity. Let them set their show their status as flow mode, set their Slack to away, and turn off email notifications. When I have to write, it’s much more enjoyable, and I find that I produce at least 3X the word count when I get to be in flow mode. It’s the same for our development team.
4. Scheduled Meetings
In line with flow mode, scheduling meetings at non-disruptive times will positively affect developer productivity. The key here is to schedule meetings ahead of time. Ensure a chunk of the workday is free, not sprinkled with meetings. Developers need time to get set up and in the right frame of mind for certain projects. When you respect the time they need for their work, you’ll get better results.
5. Acknowledge Estimates as Estimates
Estimates can be tricky. Employers are continually asking developers to estimate how long it will take to complete the project. Being forced to provide an estimate when you may not know all the factors involved and haven’t had a chance to do any initial work, such as thinking about how you will code, tends to suck the happiness right out of someone. This doesn’t mean stop asking for an ETA.
To improve developer productivity, the boss has to acknowledge that estimates are precisely that – estimates. A good boss will also know that most software development projects will take considerably longer than estimated. Bear that in mind and don’t add stress to the ones doing the work. They will feel the pressure as it is when they don’t hit the estimate they gave. Nod, smile, ask them for an update and let them get back to work.
6. The 30% Review
Another thing we do at ExaVault is the 30% review.
Don’t wait till the end of a project to look at the code that’s been written. Don’t nag someone every day to check in on their work. Find the balance. The 30% review means getting your work reviewed near the beginning of the project, but far enough in that you have something to show. Catch any changes at a point where corrections won’t have a devastating impact on the overall project or due date. A review at the 30% mark also allows the manager and developer to make sure they are on the same page.
Group meetings are often a place for recognizing team members and their contributions. Many companies have daily or weekly group meetings to check in, catch up, and share what’s been going on. These meetings are not the place for management to talk about all the wonderful things they have accomplished. It’s not you; it’s your department that reaches goals. If you’re a manager, give your developers credit for their work. Announce specific developer accomplishments during the group meetings. A little shout out goes a long way towards increasing job satisfaction and productivity.
People like to refer to houses as having good bones. Well, developers love working with code that has good internal structure. Technology is always changing; that’s just how it is. While managers may cringe at allocating hours to updating something that is not broken or has no client-facing impact, refactoring makes code more efficient. It prevents hours spent to maintain and debug old code.
9. Best Solution vs. Faster Release
I’ve mentioned deadlines and estimates. Now, you can improve productivity from your developers by letting them work not faster, but with higher quality results. You don’t want to use a seamstress’ fabric scissors on paper — that will ruin the scissors so they won’t cut fabric properly. Similarly, you don’t want a programmer writing code solely to meet a deadline. That will diminish the quality of their work.
Sometimes the best solution presented by your developer may take longer and even delay the release, but it may be the right choice in the long run. Few people will happily work and be productive when grumbling under their breath, “this would be so much better if we had the time to do XYZ.” Compromise will often be necessary on this point due to larger company goals that must be met. Know that the best work is work done towards the best solution.
10. Clearly Define Project Scope
Finally, developers need you to clearly define the scope of the project for them. If you are working with a ticketing system or project management software such as Asana, leave detailed notes on what you (the manager) is envisioning for the project.
I. First, this will give the developer what they need to get started. When in flow mode, they can look at the notes to keep on track.
II. Second, setting the scope allows for better time management throughout the project.
III. Third, a clearly defined project scope reduces miscommunication and the need for additional meetings, which we all know developers love having sprinkled throughout their day.
Improve Developer Productivity
If you work with or manage a team with software developers, programmers, or the like, you know productivity is essential. The best way to have happy developers who are more productive can be as simple as implementing a few of the changes outlined in the ten areas above. It won’t always be perfect bliss, but what code hasn’t needed a little debugging at some point.