Overconfident developers

Questions
#1

Hi All,

Working with a new team, they all thoroughly buy into the idea that QA (quality advocacy) can assist in building confidence in the changes they are making. i regularly have chats with devs and help uncover areas they have forgotten or misunderstood. however there is one developer who only involves me when they are not confident in their current solution and feel that involving me in everything is process overkill.

Often when I talk with devs about their work they are confident there is nothing to be found, but then we regularly find ways to increase the quality. I don’t want to be overbearing and impose myself onto this developer, but also eager to get opportunity to show the benefits i can bring to the team.

At the moment my best approach feels like trying to build a better relationship with the dev in general conversation, whilst working more with the rest of the team to show the value i can bring and biding my time.

how have other people worked through this problem?

2 Likes
#2

Hello Daniel,

How long have you been working in testing? And for how many companies/customers/teams?
What you are speaking about is indeed a very common issue. It has a lot to do with overall “team dynamics” and the psychology of testing.

Our job is to question what other people did (or are going to do) in order to increase the overall quality of a product. Some people see us as partners. Other people see us as dangers, who will question their work. Some people just think we are useless because they feel that the product they are building does not need improvement (and this last type of people is really hard to work with!). Other testers will probably have other types of colleagues to add to the list.

During my carrer I worked with all types of developers, from people who were so enthusiastic about my work that it was freaky, to people who were downright hostile every time I tried to work with them. It is okay. Promoting our work is part of our job. Many developers have never worked with a tester before, or worse, they have worked with “bad” testers. Testers who would despise them and make fun of their mistakes. Testers who were former poorly skilled developers and were moved to a QA position in a bet from HR to “make something useful” of them. Testers who would not do their job properly, and give a GO to products that were simply not ready.

You need to earn the confidence of this developer, for whatever reason. It can be done directly, by showing your worth, or by proxy, by involving another person who is enthusiastic about your work (you know, the fanboy who asks you for help every time he makes a commit?). In order to achieve this, what I found useful is to have a chat with another developer who has a great work relationship with the developer I was trying to “reach”. Do not be inquisitive, just ask how he/she sees the job, what that person thinks about quality, check if he/she may have had bad experiences with testers before
 And so on.

Persist! If you do earn the trust of this developer, in the future, he/she might become your best ally. And you will probably learn a lot of useful things in the process.

I wish you good luck.

#3

Hi Florence,

I’ve been in the industry for a good number of years and many different teams, i’ve encountered this problem plenty of times, but i’m always looking to learn new ways to connect with the diverse spectrum of personalities that is the developers.

Sounds like we have similar approaches, build a relationship and display value with everyone in the team that you can. I’ve also gotten involved in the past with a “can you show me how this works” approach, as it’s as important for us to understand what they are working on and how it effects other tasks as it is to ensure the work is quality.

Thanks Florence

#4

Thank you for your answer.

In that case I suppose you tried all the usual strategies. There is a last one that worked for me with really reluctant developers - but it is “risky” and requires development skills. Let’s call it the technical legitimacy joker.

I picked a really “bad” ticket that had been there for months and passed to a few people. Used intuition to pick something that I could solve all by myself, without help. Took a deep breath and started to dig until I could solve the bug.

Once it took me one week (not full time!). The second time it took me two days. Both times it was a sound “hit” - I had proven my technical worth and made allies in the process.

Who knows, it might work for you.

2 Likes
#5

Rather than convince someone you can add value, it might be easier to achieve the same result through different ways.

Your goal might be to help the developer find things they might not find on their own but if they honestly believe they are fine and don’t need your help, maybe you can get the developer to ‘help you’.

In all honesty, when I talk to a developer it is a two way exchange. There are things all developers can learn from me but there is also things I can learn from the developer. Often just the act of communicating with someone results in me learning something new, something I never thought I’d learn.

So I’ll often approach a developer letting them know they can help me as much as I might help them. The reality is that they probably don’t want your help because they like being the person who helps others. If you appeal to their desire to look smart and help others, it could work. I’ll often ask developers questions. Sometimes I know where the conversation is going but I’ll play dumb and let the developer feel they are discovering the issue on their own. Sometimes it will take a long time for them to realize I was playing dumb but sometimes I’m happy to always let them think they solved it without me.

I actually had one incredibly bright developer say to me one day, “You’re actually quite smart. You could be a developer.” I smiled and said, “Maybe some day.”

There is a danger to this approach however. I once worked at a very small company. I had to trick all the developers including the CTO. They figured they found and solved all the issues. So they didn’t need me. I was laid off.

1 Like
#6

I used to say “I’ve been a developer, but I like testing more”. These days, I usually say something like "You’re actually quite smart too, so maybe some day you’ll make a good tester :slight_smile: ".
Since “being smart” at one thing doesn’t mean being smart at everything, “developer smart” and “tester smart” can co-exist perfectly within a team. And saying something like the above seems to remind the team members that we each contribute our different skills, and all can be useful.

Regarding the approach of asking them to help you: I wholeheartedly agree. Developer overconfidence, in my experience, is in many cases lack of (complete enough) understanding. And asking to explain what they built to you (“as if you were five”), helps you both find out if it is confidence or over-confidence. So I find that “asking for help” becomes a great test :smile:

3 Likes
#7

The way I’ve won people round in the past is by showing an interest in what they’re doing. Asking them to talk through the code they’re writing and asking ‘what if someone does this?’ or ‘how does this code handle this scenario?’ This can help you catch some scenarios the developer may not have thought of.

The best way to convince people of your value is by demonstrating it. If you raise a few unconsidered scenarios or highlight a few assumptions that the developer has made then your developer should see your value pretty quickly!

3 Likes