Why does it seem like some people on software projects just never "get it?". No matter
how hard you try to convince them of something you give them all kinds of information and
try to tell them what's in it for them - they still don't want to support you. Well today we're going to talk about why sometimes
programmers never seem to agree and what you can do about it - right after this.
Hi, I'm Jayme and at Healthy Software Developer,
I want to help you have a long career where you don't get burned out
You don't get pushed around by people that don't really understand software development
so you can just have a really fulfilling career. In the first 10 or so years of my career
I got really good at software development and testing and agile development and a whole bunch of different things.
And I got really frustrated when I couldn't convince certain people that an idea
I thought was really gonna help us would help them too. And so in this video
I'm gonna help you understand a little bit about what I've learned about why this happens
and hopefully give you some tools that will help you avoid it and get through to people.
When we're in a software development project a lot of the debate and arguing is really about practices,
and I'm going to give you just a couple examples.
One might be code reviews. There might be some people on your team that think it's a good idea, and
some that think it's a horrible idea.
Another one might be manual testing being done by dedicated QA engineers. At some companies
this is looked at as very beneficial,
and at some other companies and by some people they might think this is a really bad idea and that
everything about your testing should actually be automated.
And finally another example of a practice that people often debate is
whether the product manager on your team if you have one should write the
requirements for your software. And on some teams the software developers will write the requirements, some will have a business analyst,
but these are just three examples
of practices you probably run into all the time on a software development project that people can often debate.
Now there's an endless number of practices that people come up with and they can debate
but really if you think a little bit bigger picture about these practices
we argue about they fit into some sort of larger things that are called
principles. And a few examples of these principles that might be driving people to choose the practices
they do might be statements like this. The thought that "quality on a software project matters". The thought that
"individuals make mistakes", and maybe the thought that
"developers are really just best at writing code".
And those might be
principles that an individual or a team or a company have chosen to agree on and they kind of drive all the
practices that everybody chooses to use on a project.
But there's an even deeper root cause that's usually driving the reason why people
have adopted the principles that they have that is usually not talked about in a lot of software projects unless people have really
authentic and close
relationships with each other and that's what their beliefs are. So in this example
the belief that might be driving those principles that everybody has sort of made a lot of
practice decisions on could be the thought that
"programmers can't be trusted". And I personally don't agree with this belief
but there are a lot of managers and people and software companies who unfortunately
do hold this belief and so when two people are
arguing about why should we pick this practice one of these little purple circles
and they're trying to talk about how it helps quality and be improved and all these different things these different
principles the ones in the middle, the green circles
for why they are selecting that practice, it can feel very
frustrating sometimes when you don't seem to be able to get through to people and usually this is because
there are conflicting beliefs.
Somebody out there believes programmers can be trusted and so their set of principles and therefore
practices that they believe in and they think are a good selection for the project are in conflict.
And so if you're gonna resolve this
situation the only way that you really can is you can't continue to just argue about and try to educate someone about why a particular
practice helps the principles that they've sort of stated publicly. You need to get to know that person better.
And this is something that I did really poorly earlier in my career. And as software developers, I think we spend so much time
whether we're in UX or operations, or we're actual just programmers sitting on the computer writing code
we don't kind of get the social interaction with the rest of the business. But oftentimes
I think what it's going to take is, for you to resolve that conflict you have to figure out
"what are the beliefs of the person that's disagreeing with me that doesn't want to do this thing that I think is a good idea?".
And discovering beliefs is really a pretty simple process, but a lot of people don't have the courage to do it.
It really just starts first with asking if somebody's recommending a particular practice,
and this doesn't matter if it's managers asking you to do it or you are a software developer
and you're asking someone else in the company or maybe one of your teammates to do it. The first thing is just to ask
"why?" and try to get them to go a little bit deeper into maybe the principles that are driving them.
And you've probably heard this concept Eric Ries who wrote the Lean Startup calls this "the 5"
"whys" but he didn't really invent it.
This is just a an approach that a lot of people used to kind of get to the root cause or belief or something.
So once you know a little bit about the
principles that are driving someone to tell you why they think you should follow some particular software development practice,
you need to ask them "why?" again and in this diagram
I'm just showing you that you only may need to go to levels deep.
But you know the concept of the 5 whys, and five is just an arbitrary number,
but it's really just to get across you may have to ask "why?"
many many times of a person to get them to really break out of maybe the
mindset that they're in because they don't even realize that that belief that's deep down inside that's causing them to feel what they do.
So if you want to get other people to agree with you and they seem to have conflicting beliefs
and you're not really sure what those are I would just encourage you to watch some of the other
videos on my channel where I talk about getting support for your software ideas and
having the courage to get off the computer or make phone calls. And I know we all hate it. I'm telling you
I'm an introvert at heart too a lot of programmers and software developers are. But I've just found that
sometimes it's not worth months and months and months of
frustration on a project when all it really takes is having the courage to sit down with somebody
try to not just explain why they should do something, but get to know them and get to understand
what are the core beliefs that are really driving the resistance that you feel?
So have you ever dealt with a really resistant person who you try to get through to
you've given them a lot of information, and they just don't seem to care
or you're not able to really get them to be open to your idea because they have some sort of limiting belief?
Leave me some comments below. If you're new to my YouTube channel go ahead and subscribe, click the bell icon
and you'll actually be notified each time
I post new videos. And you can also listen to this as a podcast on Google Play, Stitcher,
SoundCloud, or iTunes. So until next time, thanks.