10 Things You Can Do Better While Working With Programmers

If you had to guess what is it that programmers hate the most, what would you say? A Quora thread asking this question triggered over 90 replies and nearly 450k views. Clearly, there are some strong sentiments on this issue. What struck me the most is that some of the problems these developer complained about are very much avoidable.

In this article I want to show you project management best practices implemented at our company, that help us to maintain a proper workflow and keep our employees motivated.

I thought that it would be interesting to ask the developers whom I work with at , if there are things that they don’t like, so that I could compare their views with the Quora answers.

Avoid These Mistakes While Working With Programmers

At Apptension we do our best to maintain a happy and productive workspace, which we’ve included in . So I asked my co-workers this one question: What do programmers hate? Here’s what they told me.

1. Lousy requirements

Sometimes it’s the requirements gap, unspecified project or unclear communication between the client, project managers and developers that leads to flawed software. If a client or a manager isn’t specific enough about their product, they shouldn’t expect others to read their minds and do the work they haven’t addressed properly. It is a manager’s job to gather as complete project’s specifications as possible, so the developers don’t need to guess or ask about the specs.

2. Repeatable tasks

Doing things over and over again can not only be boring, it can be exhausting. The problem here may be, for example, working on one project for a long time. It may also be a client changing their mind all over again on one feature. Either way, if a developer feels burnt out by the repeatable tasks they are doing, maybe it’s time for you to talk about it with them. If you can, relocate your employee to another project. Sometimes a simple change of the tasks one is working on can be refreshing and keep this employee motivated. At Apptension we use Officevibe for anonymous employee surveys, to measure their satisfaction.

3. Technical debt

is an effect of using a simple solution without thinking about future scalability of the project. In other words: it’s the result of choosing a quick & easy way to do something right now, which is not necessarily the best solution. The reason why developers hate technical debt is simple: Just like it is the case with the financial debt, there will be a moment to “pay it back”, which in development means tackling the same problem again. To fix it, developers often need to rewrite the code to finish “the uncompleted work”. It also causes missing deadlines, as it is hard to estimate how much work is required to pay of the debt. The solution: don’t fall into something because it seems to be easier when you plan it. Think about the best possible solution and execute it once and for all.

4. Not enough or too many tasks

Employee underutilization can result in reduced motivation, while too many assignments lead to burnout.

A good company can prevent both by implementing proper resource management. Tools like can help maintaining the right resource flow between the projects, and monitoring team’s utilization.

5. Interruptions

It takes up to 45 minutes for a programmer to get into the so called “zone”, which is a state of the deepest focus, assuring the biggest productivity. Getting out of it is much faster, on the other hand. Sometimes all it takes is a question asked in person or via messengers like Slack. Another form of interruption is context switching. It happens, for example, when a developer is working on several different projects during the day.

It might actually cause losing time or project delays for the company, as employees need some time to switch from one project to another one. While managing the project, try to plan every detail of it and avoid interrupting developers during their work. For small interruptions it is common to implement “the headphones rule”, which means that if a developer is wearing them, do not approach them. Important issues regarding the project try to tackle during scrum meetings — that’s what they are for. It will make their work less stressful and more efficient.

6. Unnecessary meetings

Not every meeting should actually take place. And certainly you don’t need to have developers involved in the majority of them. There are, however, meetings that require a presence of developers, like sprint plannings, project reviews or retrospectives. Here they can answer technical questions or to comment on the process. Scheduling a meeting, decide if the developers should really be a part of it. If not, they can spend their time more effectively working on a given project.

7. Bad QAs

It is important to assure that the code is of high quality, and most developers understand the role of QAs. What programmers hate, are unqualified testers, who interrupt their work instead of improving the code with meaningful reports. Bad QAs are especially annoying and disruptive when they prioritize wrong issues, focus on sitters instead of major issues, or when they leave out key information in bug reports. Good testers, on the other hand, can preserve the quality of the software and help developers in their work, instead of interrupting it. While hiring Quality Assurance team members, do your best to make the best choice, because it will not only result in great quality of the software, but also make the partnership between them and developers less painful.

8. Unclear schedules

For every task in software development there should be a clear due time. Milestones help to define when a certain feature should be completed, and when the developers are supposed to deploy the product. An unclear schedule or a lack of it makes it harder for the team to assume the priorities of a project, and to deliver it on time. Another reason for creating better schedules is a team-based nature of developers’ work, often requiring to sync several people to deliver a given feature. Running a project, analyze every stage of it, including scrum meetings, due dates for delivering the features, and shipping date. Then mark them in developers’ calendars.

9. Not including events in sprint planning

Consistent project management helps developers to focus on the right tasks at the right time. Including events like Sprint Review, Retrospective, Planning, and Daily Standups in developer’s calendar assures the proper flow of the project. Without doing that, every call for a meeting will be an interruption for a programmer, and you already know that it is both annoying and disruptive for them.

10. Estimating tasks in hours

Estimating tasks in hours is often considered as tea-leaf reading.

As programming tasks can take different amount of time for various employees, it’s hard to set a clear timeline of finishing them.

Yet, still many managers ask for time estimates and treat them as deadlines. Although it is important for a company to estimate how long a given project will take, it should be done based on the recent, alike projects, and always assume that it doesn’t mean that a new one will take this exact amount of hours. To improve your estimations, you can consider story points. It is a Scrum concept used to estimate work effort on a story. Story points include the amount of work and its complexity. If a company keeps track on story points, they can better estimate projects based on similar stories from the past.

Conclusion

Knowing these developers’ pain points, you can keep your employees motivated and focused on the right things. Avoiding them in your company may help in creating a for your team. And as study shows, than unhappy one.

Is there anything you’d like to add to this list? Feel free to share it with us in the comments.

Originally published at on April 20, 2017.