How to ask a non-programmer not to advise me on programming tasks

Question

I have this problem with an otherwise very respectable colleague, who holds the position of consultant/tester in my team. Due to them being in the company twice the years I've been working here, they have acquired great experience on how things work and are able to be very helpful on that aspect. They also know some technical stuff - but no programming.

So far so good. However, there is some friction between us when we are required to collaborate and I really want to settle things and not get frustrated when this happens.

Although they are very good at what they are doing, they sometimes inconvenience the way I work. Let me explain: they get very anxious and impatient when they assume (sometimes mistakenly) that an issue is urgent or difficult to fix. They even go into lengths such as guessing what the bug actually is and urging me to look into particular functionality/code when I have already found the issue is elsewhere. Or, they give me advice I didn't ask for, on very easy algorithms (in other words, how I should code). They often don't respect the estimated effort I have determined (which is logical because they don't know coding, but still very frustrating given I'm many years in the project myself). They often try to remind me about the bugs assigned to me, and frequently ask me about the progress I have made (in other words, they are spamming me when I'm trying to work). This whole behavior makes things worse more often than not.

I really appreciate that they assign the most urgent and sometimes complicated issues to me instead of the other developers. But I'm also an anxious person and multitasking impairs my productivity. When I'm not overly nervous and not required to switch from coding to communicating very often, I'll have the code ready way sooner than I'm supposed to. But when I am interrupted frequently, my work slows down. I also don't like unnecessary comments on how I should code, since it implies that I don't know how to do my job. I have already told them that they don't need to interrupt me and tried to imply that advice on coding is unnecessary, but to no avail.

I have tried to advise them about something that concerned their duties, and they rightfully reminded me that it was their job. So, they are aware about the boundaries of each team member's position, but unfortunately not about their own.

My question is: how should I convey to them that our collaboration technique isn't working? My goal is to work together more effectively.

^{NOTE: They refers to a single person.}

Answer 1

It sounds like there are many issues, a lot of which is related to communication.

Daily Standups could help this. They are a tool from the agile world. Even if you are not following an agile methodology you could still find it useful.

Quite simply each member of the team stands together at the start of the day and says what they worked on yesterday, what they intend to work on for the day, and anything that is holding them up. Your QA person should attend to, so they know what is going on and can ask questions to help prioritise work.

An issue tracker Jira, Trello etc can be used to provide an up to date status of the issues, if you keep this as the primary source of information there will be less of a need to do this by email. (If you have one, then simply keep referring any queries to this and refuse to answer directly)

The most current status of the issue is in link to issue please check this for updates.

A frank discussion about communication and context switching This is more direct than the other approaches, but it could be very worthwhile. It could be that the tester has no idea how disruptive context switching is to a programmer. Back it with evidence if you need to. It's clear that you both have the same goal, but it is not clear if the non-programmer knows what the impact of their interruptions.

Use a project manager (person) Having a go-between to shield the programmers from interruptions can help. A good project manager will be able to help the QA person by showing the relative priority of the various bits of work as well as taking and prioritising new issues without the programmers having to switch immediately. (A bad one sadly will not do this but contact you directly, so you will end up with twice the interruptions)

Finally, it would be good if you could appreciate the rarity of a good QA person. While it sounds like they do not appreciate your work, I think that you may not appreciate them. A good QA with an in-depth knowledge and passion for a product is a very rare thing. I'm sure there are false positives where they identify the wrong source of the issue, but I expect there are many times when they help by suggesting where something has gone wrong. The fact they know roughly how the system works is a huge bonus. I'm sure you would miss them if they left.

Answer 2

Tell him the story of the car mechanic who was asked how much he charges. His answer was: “It’s $25 an hour. It’s $35 if you watch, $45 if you give advice, and $55 if you try to help. “

Answer 3

I ran into this very thing, here's what I did.

Note: Only do this if there is no urgency and you have the time.

I sat down with the person and let them watch me fix some bugs. I let them know that some times, things that may look like major fixes or urgent are not, and I demonstrated fixing something that caused what looked like a major problem, but was fixed in a few minutes. Then I demonstrated what looked like a "minor tweak" that caused some extensive recoding due to the architecture.

Failing that, I have also found that using analogies and putting things in terms that the person understands is the best way to help the person understand.

You can use an automotive analogy, if you like. You can tell him that your mechanic has to first diagnose the problem before he knows what is going on, and that just because your engine light is one, it doesn't mean that your car is about to die. It could mean that your gas cap isn't on right. The same thing applies for fixing bugs with programs. The fact that one exists doesn't mean that it's difficult to fix or is urgent.

Answer 4

This person is only trying to help, don't shoot them in the foot, all you need to say is:

"I got this [name of person], thank you for your help. I'll let you know if I have any questions".

If they immediately come back with more helpfulness, you repeat yourself. Don't entertain long conversations about the fix, especially if you've found them unhelpful. This will only encourage them to keep on talking now and in the future.

If they still pester you, you are going to just have to show them they are wrong with hard facts on the issue.

[Name of Person], I understand what you are saying about 'A', however I know the issue is really related to 'B' as I see (logs, events, data, etc.) to prove it. Right now I really need to concentrate to pull this all together and come to a solution.

Answer 5

Not sure if this helps, but this is how I will handle situations like yours:

Situation A. When your colleague brings an issue to you:

1. Listen to that person

Whatever you do, listen first. Listen to their problem: no reaction, no comment, no chatting on the phone. Stay face-to-face if you can.

This makes the other person feel respected and will make your life easier.

2. Think a bit.

Try to understand every word they say. Believe me, many times I thought I have fully understood an idea, yet later things turned out differently.

Take a deep breath, give yourself sometime to process what they say. Then continue to next step.

3. Repeat their ideas in your own words

Explain their issues in a way that both of you can understand. If there are too many points, try to make a quick note and cite them, point by point. If there's any unclear information, let them clarify. For example:

• If I understand correctly, you mean that the button must be in the top-left corner of the screen?
• You mean that our program is significantly slower with certain input. Let's not talk about the algorithm just yet. What kind of input causes the delay? Can you give me an example?
• So you think this issue needs to be completed today before the release. Is it correct?

Note that, steps 1 => 3 are all about understanding the other person opinion. You have no input here, except maybe giving some examples to clarify their issues.

It may looks like a lot, but step 1 => 3 often take no more than 2 minutes.

4. Follow up with an answer/clarification

Now that you have all the information from their side, you can form your answer perfectly. Example:

• I believed the button was moved to the top-right of the screen based on a recent change request, but I maybe wrong. Let me check and I'll get back to you later.
• So the program is significantly slower if the input is negative number. Hmm.. interesting. I believe I have an idea for where the issue is, it may not relate to our algorithm. Let me do a quick check and I'll update you.
• From our last meeting, I remembered that this feature isn't needed till next release. I'm confident in this. If you are still worried, we can re-check the meeting note to be sure.

Situation B. To avoid being interrupted when you are "in the flow".

Colleague X: Hey, I think you should look into this bug T4235. I believe it's in the Search function and it's just a quick fix. Can you help?

Me: Ok. May you wait a little? I'm in the progress of this T100 functions that we need to deliver this sprint. I'll reach you before lunch and we can discuss.

or

Me: Give me 15 mins. I'm in the middle of the T100. I'll look into it after that.

The best case is: ÿou can set up a fixed time-window for communication. It can be before lunch-time, at the end of the day, or right after a weekly meeting session. If people come to you with a non-urgent issue, ask them to gather all their questions and come back on your time-window. In the long run, it will be a time-saver for both of you: you can get on with your flow and they get the best support when you are most-prepared to do it.

Answer 6

(too long for a comment ...)

@JeremyFrench makes a good suggestion about a project manager, but I don't think he goes far enough.

In most environments -- that is, regardless of the software development methodology being used -- it's not up to QA to determine whether or not an issue is urgent. (It's not up to the developers either.) That responsibility resides with the project manager, product owner, etc. (We are, after all, talking about adding work to the schedule.) And the project manager / product owner should be taking difficulty (cost) into account when prioritizing work items.

That being said, in environments where roles, authority and responsibility are not as well-defined as they should be, in my experience it's not uncommon for QC / QA staff to prioritize bug fixes (even if they're not new), invent new requirements, rewrite existing ones, etc. -- whether or not you use an issue tracker.

Therefore, my suggestion would be, as each such bug is discovered:

• Tell your co-worker you will look into it, and offer to bring the issue to the project manager / product owner when you have concluded your research. (That is, offer to work with them rather than taking a defensive posture.)

• Perform some minimal research into the potential cost. By "minimal" I mean document the issue to the extent that you can without compromising your existing scheduled commitments (I'd suggest no more than 15 minutes). Include in the cost the number of features that will need to be re-tested.

• Depending on whether you can easily determine the cost, you can say one of the following when you approach project/product management (or when they approach you):

• "QA found this bug; my best guessing is it'll take about a week to fix, and we'll need to re-test all the reports afterward."

• "QA found this bug; I spent a few minutes looking at it and really don't have a good idea what's causing it, I would need at least a day or two to research it."

Either way, you allow management to make the decision concerning the priority. (If your co-worker insists this is a high-priority item and you disagree, you can include that in your statement to management: "X seems to think this needs to be fixed right away. I'm not sure I agree, because such and such workarounds exist, and the effort involved is probably going to push back the next release".

If your co-worker has suggestions as to what is causing the issue:

• If they make suggestions before you've had the opportunity to look into it, say that you have not a chance to investigate but that you will take their suggestion under advisement.
• If they make suggestions after you've had an opportunity to look into it, say that you're confident in your assessment of the issue.

If your co-worker makes suggestions on how to go about fixing the issue:

• If you haven't had an opportunity to investigate, say that the precise nature of the problem hasn't been determined.

• If you have investigated, say that you're confident in your proposed fix.

Be polite but firm.

Update / Clarification:
If new code does not perform to requirements, that is almost always a high-priority issue. I'm assuming these bugs are not of that variety, that rather they are:

• existing bugs;

• scenarios (possibly edge cases) which the new code's design doesn't account for;

• etc.

I am not saying that these types of issues are automatically low priority -- only that decisions concerning their priority should not be made by the developers and/or testers.

Answer 7

Short answer: You need to find a phrase like, "[Name,] I understand this issue. I appreciate your idea about [hypothesis.] You've explained it to me. Now it's my turn to take over this task."

Long answer: From reading your question, it's really hard to know what the person you're working with is like. I regularly encounter people who just don't know how to work with programmers; and a lot of the answers in this thread also don't understand your problem.

It sounds like you're working with a personality type that doesn't understand when to stop volunteering ideas and let you follow your particular role. These people often miss the polite conversational cues to stop, and will repeat the same idea many times, even when it's inappropriate to do so.

In my experience, these kinds of things happen when management is immature or missing. In such a case, your manager should be able to help; even if it's just coaching you about your colleague. In reality, your manager needs to explain to your colleague that they have to trust you in your role. Your manager needs to explain that they need to make their point once and then return to their role in the team.

If your manager can't or won't help, I advise having a 20-30 minute one on one with your colleague. Explain that you're a professional software engineer and, that you appreciate their input. Then, very firmly state that they need to make their point once and trust that you can handle your role. Explain that your role is to further diagnose and resolve these issues.

Perhaps bring up an example where your colleague continued to belabor an idea or hypothesis. Explain when it would be appropriate for your colleague to end their train of thought and let you perform your responsibilities.

The next time your colleague continues to press an idea, say something similar to the suggested phrase above. If that doesn't work, re-involve management. If your direct manager doesn't help, it's time to escalate above your manager.

It's important to know that these are situations that lead to raised voices and lost tempers.

[Edit] It's also important to understand that this personality type often has hurt feelings when they aren't allowed to continue to repeat their ideas. That is not your problem. They need to develop the maturity to collaborate and trust, and part of that includes knowing when to make their point and move on. It's not reasonable for them to become personally insulted in this kind of a situation.

Answer 8

It sounds like most of the problem for you stems from your workflow being interrupted. It also sounds like your colleague is expecting more communication than you are currently giving. With this in view, you can find a way to enlist your colleague to help you reach a solution.

Workflow

Find a workflow that works for you, and ask them to respect it. Set up guidelines, and ask them to support you in being maximally productive. Phrase this as a problem that you have, that they can help you with, so that they can get what they need.

This approach avoids blame or offence, and gives your colleague control to help you meet his/her needs --- which is really what they want, after all.

For example, you could set up guidelines for how to report a bug, and how often to check for progress. (Note: If you could give an estimate for a given fix proactively --- before your colleague sends a reminder --- you might not even have to explicitly ask your co-worker to change.)

Maybe you could replace the "status update" emails with a once-daily, 10-minute meeting.

Communication

Does your team have a good issue-tracking product (e.g. something like Jira, or Microsoft Planner)? If you can easily publish (1) What you're working on now, and (2) How you've prioritized things, it could help a bunch.¹ It takes 3-5 minutes to update a bug request, and happens when you're ready to switch tasks.

It sounds like your co-worker is trying to replace such a tool with an email-polling system. As I mentioned, if you can't use a tool, you might at least be able to have a 5-10 minute meeting every so often (even once a day), to sync up on priorities.

¹ Better yet, ask them what is important for them to know about. Even if you already have an idea, it encourages a mutual feeling of partnership, and teamwork.

About priority

It is important to realize that assigning priorities is a business activity, not a technical activity, even though the details may all be technical. Therefore, a technical user and non-technical user should be able to agree on the priorities, as long as both are aware of the business needs, and are able to communicate effectively in terms of those needs.

Furthermore, any disagreement about priorities comes back to a misunderstanding or miscommunication of how business objectives are impaired (in the case of a bug), and has nothing to do with coding.²

To prevent misunderstandings, be sure to discuss priorities in terms of the business functionality that is affected, rather than the technical bits. That puts you and your colleague on equal footing, and gives them a relief from the technical parts.

What's more, that provides a mechanism to appeal to a third-party, whenever you cannot agree. If you frame the issue in terms of competing business priorities, you can point to the real stakeholder --- or perhaps your project manager or boss --- and say, "If you want to prioritize X (business function) rather than Y (business function), please talk to so-and-so."

² This assumes that both you and your colleague are actually aware of business priorities, and are competent at your respective jobs.

Trying to do your job / Hold your hand

I would recommend choosing which problem is more important to you to fix. If your colleague tries to explain what to do, but not in a way that affects your workflow, I'd say, live with it, at least for now. It might mean your 10 minute meeting takes 20 minutes instead, but if you can say, "Okay, but talk to me during the meeting, please," that at least limits the damage to your effectiveness.

Pushing back could somewhat antagonize your colleague, and prevent you from "enlisting" them to fix the bigger issues.

I assume the workflow problem is more important to you, despite being (perhaps) a bit less salient. I also don't have any solid advice about this part.

Answer 9

I tend to be a bit intense in certain conversations regarding differing opinions on things; one example for me was comments. While I interface with most people fairly well, I do run into some people with a similar personality trait but the opposite opinion.

When this happens I first try to pivot into the person after having the friction; increasing interaction and bringing more things to them in an attempt to figure out how to better work with them. Often this does not work.

What I then do is minimize disagreement passively and only bring up critical problems or needs with them. This reduces "inflammation" if you want to think of it that way; meaning flares up are less likely. It also helps because when I want to talk to them about an issue it's because I genuinely need an opinion from them; and being genuine is always good.

I see that may seem like it's not an answer; but basically I'm saying "stop telling him things he doesn't need to know" or "stop trying to discuss or solve problems with him unless you think he'll be helpful."

This all said, I tend to be someone who using people as a sounding board and looks for uninformed or unconventional ideas because it gives me a different approach to the problem; so it may be that you want to simply start listening to him when he has an unconventional or unlikely idea.

Answer 10

Others have addressed the interruptions and context switching, and there are some good answers about that. I'm going to address the tester trying to fix the code.

It sounds like your tester would like to learn to program, likes solving puzzles, and is looking for feedback (and learning), without having a real clue as to what it is like to program professionally. So show them.

As a warning, whenever I did this, it wasn't the most productive day in terms of fixing bugs, but it always paid off in the long run.

What you want is to take one of the bugs (preferably one that the tester was incorrect about) and show the tester what you need to do in order to solve the problem. This works best if you can do things the tester cannot do, like use the debugger or look into the database.

Invite the person over to your desk and talk through the problem. Then, explain what you are doing as you start to fix it.

Let's say I have a three tier system. Browser, server, database. Let's say I have a bug that involves filling out a form, posting it, and then reading it back, and the data doesn't appear when read back.

The first thing I'd do is to duplicate the problem. The second thing I'd do is to see what the database looks like. At that point, I know if the problem is writing to the database or reading from it. The third thing I'd do is to jump into the middle of the server with a debugger, to see what the data looks like there. Next, I'd look at the data as it is sent to the database or browser. And so forth. I'm narrowing down to the point where the data was corrupted.

The point is this. What I don't do is first speculate on "what" the problem is, because that can lead me astray. I first use my tools to find out "where" the problem happened, usually by looking at the data half way between the known good and bad state (and somewhere I can look at it efficiently), and repeating until I have narrowed the problem down to a small bit of code. Once I know "where", I can put breakpoints in the spot and step through and discover "what". As I do that, I may even find other potential bugs in that bit of code I can fix at the same time, as well as discovering what needs retested.

If throwing darts at a target in the dark, it is easier to turn on the lights than to guess where the target is and hope you hit the mark.

And then encourage your tester to talk to their manager about becoming a programmer. We need more good programmers in this world.

Answer 11

If you are in a position to do this, try this experiment (and put in in writing to have a mail trail):

Every time they insist you drop whatever you are doing and do what they want you to do, do exactly that, and compare the results in a week or two with your normal working pattern. Then sit down with them and discuss the pros and cons of both approaches, with actual statistics on how much work you can do and how happy the management is with each approach's results.

There is always a chance that results might not be all that bad, but in case it goes as you expect, you'll likely make them stop bothering you as often as now.

Answer 12

Interfacing directly with QA should be at your discretion, not the other way around. You can't afford interruptions. This needs to be made clear to QA by the manager of the project assuming that fits your company culture. If not, you may have to try and change the company culture.

Insulate yourselves with a better workflow. I would recommend looking at good bug tracking databases if you don't already have one. Speak to the project manager and explain how these interruptions are dramatically slowing your progress and causing stress. If possible, separate QA in another area of the building.

In my experience in QA for a video games company, my job was to find, replicate, detail, and classify bugs in the bug tracker. The programmers role was fixing these. The project manager (producer, in this case) prodded the programmers when they had critical bugs left open. As QA, I could contact the project manager if I thought something was urgent. I wouldn't bother the programmers directly, but they would often come and speak to me.

You are on the same team. As some of the other answers have noted, great QA makes your job a lot easier. I would go so far as to suggest making a point to go over and speak to them at your convenience to see what the mood is like as not everything comes across clearly in text.

Answer 13

My answer is going to be different than most here.

Many of the other answers focus on what your colleague should or should not be doing.

I am going to suggest instead what you can do.

First off, look at the positives. This is a knowledgeable co-worker that genuinely wants to collaborate and help you do your job. You mention nothing to suggest that they are deliberately trying to hinder you. They're only doing so because they don't understand how to be most effective in helping you.

That's where you come in. It's time to have an honest, frank, and objective conversation with them about this. Easy, right?

It actually isn't. Which is why there are plenty of resources out there to help you achieve this. Here are a couple:

1. Crucial Conversations (book)

I read this book and find its framework helpful in having productive discussions with team members: https://www.goodreads.com/book/show/15014.Crucial_Conversations

2. Clean Language (technique)

I know less about this so I can't provide concrete resources. This was a popular topic at a recent conference that I attended: https://en.wikipedia.org/wiki/Clean_Language

TLDR: Collaboration is hard. Fortunately, you're not the first person with this challenge. There are resources out there to help. Try also Googling "productive conflict techniques" or "conflict resolution frameworks". Just avoid superficial articles and find something with substance (such as a course or book) that gives you some concrete tools.

Hope that helps!

Answer 14

can't you try to make a joke out of it?

"I heard tester say that to a dev once, they found him years later as the 4th bump on the motorway"

"you must really like my low salary if you're always trying to do my job"

"whoa there horsey we havn't even got to that bit yet"

make fun comments as you get a coffee say something like "do you take take sugar" then "no wait i'll ask ask tony he'll tell you how you want your coffee"

I know that it may not be your style to be "my amazing brand of funny", andit isn't funny unless you're both laughing as you say it.. but make him laugh and he'll not mind I assure you. .. if you don't know how say that

"I wish I knew a joke then i'd tell you so I didn't have to punch you in the balls"

he probably is a back seat driver in other parts of his life. most people will laugh at stuff like that if they know deep down you like them