Why Do Some Programmers Never Agree?

Why Do Some Programmers Never Agree?


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.

7 thoughts to “Why Do Some Programmers Never Agree?”

  1. Have you struggled to get other programmers to agree because of limiting beliefs? Leave me your thoughts below!

  2. I've tried a similar approach in the past,

    However my teammates are usually only 2 levels deep / or not willing to share.

    You have a solution

    They will argue with:

    alternative solution -> reference to a well known book/author/web article

    eq. according to Eric Evans (DDD), Martin Fowler, etc

    A junior dev even argued about the "Onion Architecture" he read from a web article with an unknown author, which basically another flavor of Layered-Architecture
    and implemented it on a new project without our approval, when he was done, it's really an onion, that made me almost cry for having too many layers.

    (This sucks, because it feels like they are just riding the hype train and don't really have that level of software development wisdom.)

  3. https://youtu.be/uA5wW4pbIJs?t=645 watch the clip at 10:45 and pay attention to the body language. People will listen ONLY when they are ready to listen.

  4. I think you have great advice about picking up the phone and asking the 5 whys. You point out that having that having that conversation can help you better understand the other person in addition to having them understand you. That’s an important point as well. Always remember that you could be wrong, and that to the other person, you may be that programmer who never agrees!

  5. Also, there are a ton of reasons why people may disagree beyond trust vs mistrust of programmers. I assume you just used that as one example. Each person has experiences that feed their viewpoint, and I personally have found that there is no such thing as “best practices”. I’ve found that the practices have to be the right ones for the individuals on the team, the particular team, and the particular company. I think you’ve mentioned in other videos that you’ve found practices that worked great one place don’t necessarily work great somewhere else. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *