Being a software engineer is one awesome job!
Software developers strive to live up to our creed: solve problems with amazing people and follow best practices to make the (tech) world a better place. Engineering and product managers are tasked with leading groups of passionate, knowledgeable people as they work together designing architecture and features. As one can imagine, this can be a lot of fun.
Working in a close-knit team isn’t always sunshine and roses though. When you have a group of people from different places, with different experiences and various expertise, there is often discord with how to best develop, implement, and work on features.
But disagreement and discussions aren’t the main issues. In fact, when people are open-minded and focus on the result that’s best, instead of being “right,” disagreement can create better solutions.
There are a few areas that typically generate discussion and lead to disagreements on dev teams.
Imagine this: one developer on the team spends hours writing code to complete a sprint ticket. He or she labors over creating the best names and abstractions that lead to readable, concise code and create tests to make sure all is working as expected. Then, the dev submits a pull request, which requires another developer’s approval once the code is ready for review.
Coding is an art, and our process for creating masterpieces is personal, but code reviews are a forcing function that ensures high-quality code and applications.
It’s easy to see how the reviewer, who is critiquing and asking for changes, can potentially cause tension with the author. There’s ego involved and the pesky “self-interest” bias that everyone has.
For example, developers are interested in getting their code approved without having to rework large amounts of it. Why? Because they have other work that’s due for completion by the end of the sprint, too. It’s also an Agile value to deliver working products in a timely manner.
At the other end of the spectrum is the reviewer, who is charged with maintaining and improving standards, and ensuring those standards are followed, even if the ticket will take longer to complete. How can the reviewer allow for sloppy code or code lacking in best practices into the codebase? Isn’t it their responsibility to ensure high-quality projects?
It’s quite evident why the back and forth between getting code approved and completing all the changes requested can cause disagreements. In fact, it’s totally normal. How you go about communicating and resolving this is what matters.
Software engineering has the benefit — and sometimes the challenge — of not having specific best practices that are followed by everyone at all times. Opinions vary and standards evolve. These are not only brought up in code and sprint reviews, but are points of tension when different opinions between team members arise (such as tabs or spaces for indenting lines).
The key here is to continuously decide on and update code conventions in a centralized wiki or file. This gives reviewers documentation they can point to, and pull request authors a guide, meaningless points for tension.
As teams evolve their software over time, they must adapt and change their architecture to meet new designs or features. Database structures or new micro-services might be required, or they may adopt new frameworks or libraries into the stack.
Experience in these areas is varied, and opinions on naming conventions or tech stacks chosen can dictate so much of a project’s code base. It affects everyone on the team, and, because of that, individuals have reasons to prefer one solution over another.
A healthy dialog builds strong outcomes, but teams should outline some of the baseline goals they are trying to achieve for these discussions. By doing so, they can drive conversations toward a specific end result that they can weigh options against.
It’s become apparent that software engineers need proficiency in soft skills. Developers collaborate all day long, and being able to relate to others, communicate their ideas, and find common ground impacts the success of their projects.
Developing these skills can be tough for those who tell computers what to do all day.
At work, we can’t just stop working with someone we don’t along with. We might have true personality mismatches, stark differences in views on best practices, or overall communication style differences. Such is the life of working on a team.
Learning to put differences aside to get work done and accomplish goals for the team continues to be an ability of great leaders. You can do the same!
There is one fundamental truth in all of the discussions and disagreements in your life: you are part of them.
Creating self-awareness around discussions helps ground you, set aside emotions, and enables you to think with more clarity. As a teammate, you must understand that you can’t always get your way, and challenging everything will result in a huge loss of time and productivity.
In other words, challenging and pushing for a specific option should only be done when the impact and benefit are worth it. Here are some questions to ask:
If after answering these questions you still feel strongly about a particular solution, determine how you can best communicate the differences of each option and why you believe one achieves better results than others.
One of my favorite people that talks about open-mindedness is Ray Dalio. In Principles, his recent book, he outlines what being open-minded really means (check out my full article on this if interested).
The main point is this: If someone disagrees with you, the first instinct should not be to show why they are wrong, but to understand why they disagree… because guess what? They might actually be right!
Comprehending and then incorporating their reasoning could design a better solution, or it might help you see their concerns and better communicate how your solution eases them.
Having an open-mind within your development team creates a safe environment where ideas can be challenged, discussed, and improved upon.
It’s definitely possible that even after both sides do their part, an agreement can’t be made. It happens and it’s fine! The question then is this: where do we go from there?
That’s where these steps of resolving disagreements come in!
If the initial disagreement and discussion started over a non-verbal medium, and an agreement can’t be made, the next step would be a Zoom call or in-person chat.
It’s quite common that disagreements are fundamental misunderstandings, where the ideas and differences being communicated are actually two people on the same page. It’s much easier discovering where and how an agreement can be made over a better communication medium.
If the conversation ends in a stalemate, no problem. Let’s move on to step two.
Taking the debate and different ideas to a wider discussion can transform a stalemate into a solution. By laying out the different options and advantages or disadvantages of each view, you give a full-view of the ideas and allow contextual input from all teammates (even managers can weigh their thoughts here).
Typically, a majority will start forming and a resolution comes forth. I find most disagreements can be solved during this step.
If you notice that a higher level of conflict is forming, here’s your next step.
If you’re seeing that conflict, disagreement, or tension occurs often between you and a teammate that feels hostile, the next step would be involving your manager.
You can ask for their advice on approaching the situation or ways they can help mitigate the conflicts. Hopefully, this resolves the hostile work environment, otherwise, you may need to take things to HR.
It’s possible that even after involving your manager, the tension continues. At this point, it’s best to bring in high levels of leadership or HR.
You should not feel threatened or uncomfortable at work and these are the resources who can help solve that.
Obviously, this step is the most drastic and is usually the final straw. But we spend a huge amount of time at work every week, and with the collaboration required on software development teams, it only follows that you want to be in an environment you feel comfortable and have fun in.
If after you’ve tried all previous levels and the conflict continues, the last options are to find another team within the organization that gets you away from the hostility or begin looking for work at a new company.
Both options can really make a huge difference in your life! The key is to choose wisely, ask a lot of questions during interviews, and find a culture you fit in with.
The software engineering profession is rare in its ability to constantly challenge and grow its members throughout their careers. Technology truly lives up to the mantra of: “The only constant in life is change.”
It’s an immensely rewarding career choice with the opportunity to accomplish great things in the world with great people. Like any team working in any industry, it’s likely that you’ll come up against conflict and disagreements with colleagues, but when you do, you are now equipped to handle it effectively.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Handle frontend data discrepancies with eventual consistency using WebSockets, Docker Compose, and practical code examples.
Efficient initializing is crucial to smooth-running websites. One way to optimize that process is through lazy initialization in Rust 1.80.
