I would like to get a consensus from more senior level colleagues here on how to handle a situation where you may disagree on a technical problem or code review with a colleague in an environment that has no standards.

  • Is there a process or precedent in your organization for determining "correctness" of technical solutions? Any standard you develop to? Are you asking us to help you approach the senior colleagues to create a standard, or to resolve a specific disagreement? – dwizum Apr 17 '18 at 14:50
  • @dwizum, there is no process or precedent. Typical hierarchical organization, usually the higher on the totem pole, makes you correct and anyone lower is wrong. What would be the best approach in the typical hierarchical environment? – Daniel Apr 17 '18 at 14:58
  • Typical approach to do what? Try to get a standard/process in place, or resolve a conflict/question on a specific technical review (in an environment that apparently has no standards)? – dwizum Apr 17 '18 at 15:04
  • @dwizum, hmm, so what would you recommend in an environment with no standards? – Daniel Apr 17 '18 at 15:06
  • 1
    @Daniel Who is actually writing the code? You or another dev? In most "flat" organisations, this matters. If there are two, more-or-less equally valid ways of doing something with no clear winner, the responsible dev "owns" the implementation and so gets to make the decision. The concept of ownership is pretty important to job satisfaction. – Joe Stevens Apr 17 '18 at 15:47

I always try to sell ideas from a position of confidence and assertiveness. I do my best to defend my ideas, not shut down if someone disagrees. I would come back and tell them that I considered what they want to do and why I decided on the other approach as well. If I knew a more senior person that agreed with me, I would try to get them to present the idea and utilized that, not to get my way, but to learn how to disagree and resolve disagreements in that organization.


Basically, depends on the situation. If it is something that you are experienced on and if it is your responsibility, and if someone is talking without having a clue, I would possibly suggest to put your reasoning with examples. Be assertive that it is your responsibility but be open to hear the other side and ask questions to understand where your colleague is coming from.

In case you think what your colleague is trying to sell is not any good, list the disadvantages of his/her approach.


A lack of standards seems to be the particular issue here. I am a senior developer (15+ years) and in most of my experience there are usually established patterns in existing code that can be followed when solving new problems.

In the absence of any precedent, if your colleague is of the same experience level as you, then can you not seek the opinion of a more senior staff member? If I disagree with the approach someone with less experience has taken, I try to explain it by exploring some of the issues that can arise with the approach and why other solutions may mitigate them.

That said, in software development there are usually many "right" ways of doing something, just as there are many "wrong" ways. Most modern software teams adopt the Agile methodology and the KISS principle ("Keep It Simple, Stupid") which advocates that if two or more solutions achieve the desired outcome, the optimal choice is the simplest one to implement.

Anecdote: in my earlier years as a developer I struggled with this principle because I wanted to perfectly engineer my code and use lots of design patterns and abstractions, partly to make the solution elegant and also to future-proof my work. Only through experience have I learned that it's as likely any future-proofing is wasted effort due to the ever-changing nature of software systems. Trying to forward-engineer usually makes it harder in the long run, except in that rare case where your early optimization happens to fit the change you didn't know was coming.


First of all, you can support your claims with evidence from people who have studied these sorts of problems longer than either you or your colleague. Read some books from the likes of Bob Martin, Kent Beck, Martin Fowler, and Michael Feathers. Learn how to describe the problems with code in more concrete terms than, "This way feels cleaner."

Second, code talks louder than words. People are often easier to convince when looking at real code, instead of just a theoretical better implementation. Also, sometimes you might be surprised yourself when you think a certain way to write it will be cleaner, so you write it that way and find out there are problems you didn't consider.

Finally, people are more willing to make changes when it's earlier in the process. A code review feels like the last step before calling a change "done," and people are loathe to make significant changes at that point. Try to foster a culture of doing design reviews earlier, before you spend a lot of time coding. Start by asking for whiteboard design reviews of your own code. When other people see how it improved your design, they will start asking for it for their own code.

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