87

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.

  • 3
    It sounds like he is trying to step into the role of a project manager. Is there already a dedicated project manager on your team? If yes or any supervisor, I would bounce this to him... you already tried the one-on-one approach. – Phil M Jun 19 '18 at 17:36
  • 16
    Since none of us know who you are, and thus none of us know who the person in question is, why not say he or she? It's not sexist to use a single gender if you're talking about a specific person. – user1602 Jun 19 '18 at 17:51
  • 8
    @kyralessa how could you know that this person the OP is referring to doesn't prefer the pronoun "they" when being referred to? You can't assume that "he" nor "she" is appropriate here. It would be cis-gender-normative for you to assume either is most appropriate here. – acidnbass Jun 19 '18 at 18:42
  • 2
    @Kyralessa, the OP might have been trying not to give out unnecessary clues as to identity. – Paul Johnson Jun 20 '18 at 7:41
  • 10
    Using 'they' also avoids any gender related unconscious bias.The wording here isn't made incomprehensible by the use of "they", and I don't think that changing is to "he" or "she" is likely to significantly improve the question. – Snow Jun 20 '18 at 8:00

14 Answers 14

75

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.

  • "(If you have one, then simply keep referring any queries to this and refuse to answer directly)" That's actually quite horrible for the working environment, nobody likes it when you go the passive aggressive route. Better is to give an answer but also refer them to the issue tracker, make it bothersome so they learn. – kevin Jun 18 '18 at 13:21
  • *evidence (not enough rep to make such a small edit) – Greg Schmit Jun 18 '18 at 14:33
  • 2
    @kevin This is not a passive aggressive action. When there is someone who is responsible for what gets done in a certain period of time, referring people to them is standard procedure. Trying to bypass such a person is highly unprofessional. – Cronax Jun 18 '18 at 15:30
  • 17
    @kevin I would argue that, when there is an issue tracker, sending an email to the developer rather than checking the issue first is itself unprofessional. You can look at the same issue in a different context: what's the first thing support departments do on just about every web service? Point you to the FAQ. – NemesisX00 Jun 18 '18 at 16:30
  • 16
    +1. The link to "The Multitasking Myth" alone (and pages linked from it) is worth the upvote (because forced context-switching is big part of OP's problem). – Peter M. Jun 18 '18 at 17:53
44

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. “

  • 86
    -1 This isn't particularly helpful and more than likely will antagonise the OP's colleague. – camden_kid Jun 18 '18 at 14:39
  • 67
    +1 dis funny, but @camden_kid is right, this is really bad advice. – user53651 Jun 18 '18 at 14:59
  • 10
    It's among the best ways to make enemies ìn the workspace. – Igor Soloydenko Jun 18 '18 at 15:51
  • 10
    @closetnoc There's room for humor, but we need to remember that humor and sarcasm don't always read well over the internet, especially when not everyone is fluent in English. This has been discussed in Meta before, and the answer is that humor is fine, so long as you make explicit what is meant to be taken seriously or not, and still answer the question in plain English. – David K Jun 18 '18 at 17:28
  • 5
    I feel like this answer would be better-received if it had an alternative response in case OP's coworker can't take a joke. – Jeutnarg Jun 18 '18 at 17:29
24

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.

  • 12
    The QA guy knows what's a major problem and what isn't. What the QA guy doesn't know is how big a code change it would be, or what would need to be changed. – David Thornley Jun 18 '18 at 15:53
  • +1 for looking into fixing the Dunning-Kruger effect. If the incompetent person can actually see how much they don't know that you do, they will feel much safer trusting you with decisions. – ivan_pozdeev Jun 18 '18 at 19:34
  • 3
    @DavidThornley which is exactly the point I addressed, but feel free to provide your own answer. – Richard U Jun 18 '18 at 19:47
  • 5
    @FunnyJava - By taking the attitude that you just described you are actually making the problem worse. Trying to shield your self and your code puts up walls and impairs communications. – Michael Karas Jun 19 '18 at 12:44
  • 1
    @FunnyJava your job is to get the job done. When I was a project manager, I needed my reports from someone who wasn't familiar with Excel. It wasn't in my job description to help him either, but guess who got his reports before anyone else after that. Sometimes, you need a more creative approach – Richard U Jun 19 '18 at 13:16
15

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.

  • There's a certain personality type that needs to keep expressing an idea or suggestion long after it's time to change the subject or end the conversation. I think a lot of people in this thread either don't understand this, or don't understand how much of a problem this causes. Phrases like you suggest are good techniques for dealing with this kind of personality; and escalating when needed. – Andrew Rondeau Jun 18 '18 at 20:33
  • I am aware that they are trying to help. I've done what you said countless times, the result was them returning more persistent each time, until they have finally ruined my concentration and I reluctantly give in to explaining what I am doing/will do instead of doing it. – FunnyJava Jun 19 '18 at 5:13
  • @FunnyJava, I updated my answer to give you some additional thoughts for continual pestering, especially if you have a hunch what is going on. – Jay Jun 19 '18 at 13:56
  • 2
    @FunnyJava: If these techniques aren't working, it's time to involve management. If they won't help, it means that your management is ineffective and you need to think more critically about how long you plan on staying in this position. – Andrew Rondeau Jun 19 '18 at 14:03
9

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.

  • 2
    I think the co-worker is a bit more neurotic than you realize. I regularly encounter the kind of person who just always thinks their ideas are right, and doesn't know when to stop. The above approach just doesn't work for that kind of person. – Andrew Rondeau Jun 18 '18 at 19:23
  • 1
    'To avoid being interrupted when you are "in the flow".' I want to avoid having to go through this little chat in the first place. It doesn't have an impact anyway: they will come to interrupt me again later, to see what I'm doing. – FunnyJava Jun 19 '18 at 6:03
  • @AndrewRondeau: there's no silver bullet that can apply to all situations, but I think we at least can give the "good-intention" friend a chance to back off. If they don't, then it's simple: be polite yet firm (taken from David's answer). We all have to refuse the "help" some time. – Hoàng Long Jun 19 '18 at 6:33
  • @FunnyJava: Well, at least by that way, you can schedule the time where you can effectively deal with the issue. Who know, maybe within that time, they will find the answer by themselves and not even call you again. However, I have a concern here: if the only reason they come to you is to see what I'm doing, then I don't think you need to entertain them. If they have a valid concern, then it's another issue – Hoàng Long Jun 19 '18 at 6:54
  • 1
    A scheduled time is ok, but I don't know if they are eager to accept that. They want to know what the problem is/if I found it, so that they can interfere with guessing again/get reassured and relax. I have explained countless times that I will get to them when I find something, but it didn't have much effect. – FunnyJava Jun 19 '18 at 7:02
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 you 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.

  • 1
    But it depends--if the bug is existing, then sure, it is a business decision on how to prioritize it. If the bug is in new work that is being tested for the first time, then most of the time it is (automatically) high priority, since it would block that story being done/accepted, unless you want to argue that the acceptance criteria should be changed to account for this behavior. – user3067860 Jun 18 '18 at 17:19
  • @user3067860 It depends on the nature of the bug. If the new code doesn't meet requirements then I'd agree it should be a high priority. The fact that there's any disagreement on the priority -- and trying to give the OP the benefit of the doubt -- leads me to believe that's not the case. – David Jun 18 '18 at 21:06
  • We have similar ways to deal with the situation. These are really close to what I say and do. But expressing the above while being polite and firm (or not, when I'm too tired for that) hasn't worked for me. – FunnyJava Jun 19 '18 at 5:59
4

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.

  • 1
    This is quite insightful. "...these kinds of things happen when management is immature or missing" - right on the spot! In fact this person has informally acquired responsibilities of a project manager (the 'real' project manager is very understanding, but doesn't work on this project much). – FunnyJava Jun 19 '18 at 6:31
  • "the 'real' project manager is very understanding, but doesn't work on this project much": Is the project important? If it is, then it'll attract management attention and you can ensure they coach your colleague. Otherwise, perhaps it's time to move on. – Andrew Rondeau Jun 19 '18 at 19:05
3

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.1 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.

1 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.2

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."

2 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.

2

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.

  • This is similar to the approach I have tried so far. "...stop trying to discuss or solve problems with him unless you think he'll be helpful." - definitely! I've tried to contact them as little as possible in order not to provide opportunities for spamming, but even this little is firing up a series of other messages, probably because they think I am not searching in the right direction or something... – FunnyJava Jun 19 '18 at 6:36
1

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.

0

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.

0

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.

  • As someone working in testing, I find your opening paragraph highly antagonizing. What makes you feel it's OK for programmer to interrupt tester, but not the other way around? Why programmer "can't afford interruptions", but tester can? We are all in the same boat. Successful teamwork and collaboration means that sometimes we have to give up a bit of our individual convenience. – Mirek Długosz Jun 20 '18 at 13:52
  • @Mirosław I never said it was okay for a programmer to interrupt a tester. There is nothing stopping them emailing to ask to speak to them. I also think I should add - programmers are often deep in thought on extremely complex problems. Their work is thinking, not typing. By interrupting them, you've basically destroyed however much time they have spent on extremely mentally taxing work.I guess we can all agree interruptions are bad. – David Jun 20 '18 at 15:57
0

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

  1. 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!

-5

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

  • the fact this is marked down makes me feel sorry for the lot of you.. I've been a developer for 25 years, and yes i've been in this situation many many of times, and I've never fallen out with anyone and never had this issue.. guess why?.. cos I'm able to make a joke out of it.. you guys need to stop being so weird and bullying the right advice.. you can't get "all technical" with things like this.. you don't "use a check list" and "group huddles" and "managing a person" you fix it by winning the person.. ffs .. life isn't solved 001010010010010 I honestly feel sorry for you all – Mr Heelis Sep 24 at 12:43
  • or to put it another way.. all the (wrong) +^+^+^ LOVED UP THUMBS answers say (in effect) "take back control and change the other person" .. the right answer is to "give up trying to control everything and lighten up and not be precious about kindly asking for boundaries in a non offensive way" – Mr Heelis Sep 24 at 12:48

protected by Jane S Jun 19 '18 at 21:44

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.