I wrote this article in reaction to the quora answers to “What are some things non-programmers say that frustrate programmers?”, I will assume in my response most of the question are asked by a project manager, product manager or product owner of the code that your are developing. In Italic you can find the quote from the original response and my opinion below.
1. “Are we on track?” I never know how exactly to respond to this. Maybe we’re “on track” right now to hit the deadline, but what if something happens? We could easily be off track any minute. I don’t want to commit to something that I’m not completely confident in.
It’s important to communicate how the project is going and the confidence we have in the remaining tasks, especially if we are developing a feature with a specific timeline. Either with a fixed deadline or a moving one, there are several reasons why this question could be asked, like reducing the amount of features or communicating with the client or coworkers how advanced the project his.
2. “Sorry, but we committed to this deadline.” All programmers hate deadlines. The problems that we deal with can be very complex, so it’s often not helpful to commit to an arbitrary date.
Most of the time arbitrary deadlines are useful, what should vary is the scope of the project/sprint you are working on, if the problems that seem simple at the estimation time, turn out to be complex or more difficult to tackle than we were thinking, we communicate it and we give information in order to reorganize features or cut scope. Also splitting the complex task into smaller ones, can help to have a more detailed description and also it becomes easier to add and remove tasks from the scope of a deadline.
3. “You can cut corners if it’s necessary.” Thanks for giving me permission to move faster. But as you know, I wouldn’t be in this position if you hadn’t made us agree to such an unrealistic and arbitrary deadline.
Another reminder to seat and tell which part is more difficult to implement and taking most of the time, and come back to you with which corners you can cut. By cutting corners, we mean to create a simpler or less polished version, but never a buggy one.
4. “There are bugs in the code.” There are bugs because you asked me to cut corners.
There will always be bugs, but they should not come from cutting corners, testing is what should help to fix that, no matter whether it is manual or automated. Just check if this or that test scenario was described as an acceptance criteria and if it needs to be added to the test suite or not.
5. “I know I’m not supposed to do this, but could you quickly help out with X?” People who aren’t product managers sometimes try to go around the system to get one
thing done. I’m a nice guy and like to help out, but this just adds more work to my plate and makes everyone else less happy.
6. “Sorry to interrupt you, just had a quick question.” It takes programmers about 30 minutes to get in the groove, so breaking for 1 minute to help someone else get what they need can actually set me back a half hour.
Nice guy or not, everybody has a bunch of work on his plate, you should get back to people on your own time, pomodoro technique is useful, but a simple phrase like, "when I finish this" it’s a good start. About adding work, if it’s not a coffee break help, just check with the person how it’s fit in the priorities of the project. Also using async communication like chat or email, could be a good solution to reduce interruption and others to find a solution in the meantime.
7. *Taps me on the shoulder* If you sneak up behind a programmer who is in the zone and tap them on the shoulder, you could initiate a flight or fight response. It’s physically jarring and dangerous for all parties involved.
Be gentle and remind them, if they can shout you a message on the chat or email first, and you will be happy to help them.
8. “Not sure if I fully understand the problem, but how about we do this…” It’s impossible to propose a credible solution to a problem that you don’t understand. Programmers are problem-solvers, so they appreciate it if you take the time to dive into the problem before offering a potential solve.
Programmers should ask questions, and understand the problem or the business logic, we are not baby birds that need pre-chewing of the information to put ourselves in context. Developing a product is solving solutions and take times to investigate and sometimes test a hypothesis.
9. “My heart tells me that we should…” It’s a programmer’s job to make rational, fact-based decisions. So it’s upsetting when emotion becomes part of the decision-making process.
Opinions help to take a decision, and facts to concrete it, also this kind of sentence is there to remind us a set of facts related to past decisions and experience, try to bring them and see how they work in the actual case.
10. “This should be easy.” Fixing problems with code is never as easy as it seems.
And sometimes, things that seem complex are easy to fix, communicate how this will go and everybody will learn about it.
11. “I need a status update” If the client’s site is down, and it’s my job to pull it up, I’m clearly in a high-stress situation and doing everything I can to fix the problem. I understand the need to keep the client updated, but if a PM interrupts me to ask about the status, they’re actively preventing the problem from being solved.
If a client’s site is down, you need to communicate what’s going on, at least to a person of the team not working on solving the solution to relate to the client, information is key, and an alternative solution can be brought while fixing the problem.
12. “Please A/B test the size of this button.” I’m all about testing stuff so that we can learn. But is it really worth a day’s work to test an 80 pixel button vs an 85 pixel button?
Ask, what are the KPI, or the goal of the funnel, it will help you understand how they can be improved. There is no meaning less A/B testing if there are a KPI improvements.
13. “But it’s just a checkbox!” Oh man. One time, this PM decided that we needed to add a checkbox during the last stage of a project. He framed it up as an “easy add-on” and clearly didn’t have much respect for the complexity involved. This was frustrating.
Why was it disrespectful ? did you tell others in the previous occurrence how the project was going ? can you reframe “easy add-on“ in his mindset, and understand that it was easy for him to think about this checkbox and explain to him what does the change involve ?
14. “What happened? I thought we were ready to launch.” Often, you think you’re ready to go, only to realize that there is a show-stopping bug (like having 1-2 characters off) that will set you back a few days. It happens, and when it does it shouldn’t be treated as a huge surprise.
It shouldn’t, if you explain that there is a show-stopping bug and that it will take you a few days to fix it.
15. “I know it’s late in the game, but we need to change X, Y, and Z.” There’s nothing more demoralizing than requirements that constantly change.
Constant requirement changes shouldn’t be annoying if you didn’t start working on it yet. Don’t be shy to ask why do we change them and move them to the next sprint.
16. “I have this great idea. If you build it, I’ll give you X% in my company.” Programmers are not “idea people.” We’re executors. We tend to see far more value in the execution than the idea, so the best way to gain our respect is to build the MVP of your idea yourself. If you do that, then I’m interested.
Some programmers are “idea people”, GitHub is a good example of that, there is a ton of projects and libraries that you probably use every day. Building an MVP is a great and enjoyable moment, and it could be really helpful to define the scope of the MVP with a programmer to stick to the bare minimum.
17. “This isn’t what I wanted.” General, negative feedback doesn’t help solve the problem. As a programmer, I need specific points in order to make the necessary changes to give you what you want.
Don’t be negative, and ask what is different from expected.
18. “C’mon man. It’s Friday. Let’s play some ping pong.” Sometimes, programmers love this. But other times, I’d rather just finish shipping the feature that you’re asking me ship.
Is it easier to mention it on quora than telling it to your co-worker ?
19. “We need you to work the weekend.” I only have to work the weekend because I spent hours playing ping pong with you instead of actually working.
Sometimes, we really need to work on weekend, but not because you spent hours playing ping pong, a service is down, an advertising campaign, a meeting with an investor, a top manager demo,.. There are tons of good reason, and they should be well communicated, should occur as little as possible and both parties should agree on to use time after the weekend to avoid that next time.
Conclusion
Because the quora answer really depict programmers as some kind of socially misfit robot that only want to transform issue tracker tickets and coffee to code, I need to put another perspective on this. We are way more than that, and I hope my point of view can help people to work better with their teams.