Confirmation bias is affecting your technical choices; it is almost certainly driving you to make poor choices about how code is written. Likely in many cases, confirmation bias is costing your organization to miss opportunities, hold on to bad ideas and deliver inferior technology.
Confirmation bias is one of the most accepted ideas in psychology today. It is a type of bias that drives you to favor information that confirms your previously existing beliefs.
Developers have one priority above all others: Build a product that drives revenue to the business. Like it or not, most of the stakeholders are paying them to write code that they can sell, systems that increase the value of the company or apps that attract prospects to our doors. Yet, in many cases, developers don’t seem to consider this in their day-to-day choices about how they write code. Their priorities are more aligned with what framework is popular, what theory governs the coding style or what technology company to worship.
What biases are developers likely to have?
Think of the endless debates that circulate and are hashed and rehashed in development shops across the country:
• React versus Angular
• AWS versus Azure
• Mutation versus polymorphism
• Functional versus object-oriented
• Mac versus Windows
That last one is a big debate. People can spend hours arguing the superiority of one over the other; however, in truth, none of these preferences will have much impact on the success of your software.
Yet in the last 15 years, developers tend to shy away from writing new features or creating new products, arguing vehemently that some new things cannot be done, stifling the innovations of their own company. Then in the same breath, they enthusiastically commit to spending weeks or months refactoring code to bring it in alignment with their belief system, which adds very little or no stakeholder value and often does not reduce technical debt.
The confirmation bias of the developer often supports justification for such rewrites. The scapegoat for this is often technical debt, a genuine problem. Knowing the difference between a legitimate need to rewrite code or doing so because of your personal biases makes the difference between a good developer and a great developer.
Here is how you can void confirmation bias by following or instating a few simple rules:
Find people who will challenge your ideas.
First, check with sales. The sales team is good at focusing on a singular goal of making money. Sure, they have their own biases, but ask yourself this question: “Is the code I am writing right now going to make the company more money?” If the answer is no, then you need to justify your work.
Avoid anchoring yourself in your ideas.
If you find yourself reaching conclusions about the correct course of action early in the decision-making process and continually searching for evidence to justify your findings, you might be searching for evidence to confirm your own biases. Write down your early conclusions and the reasoning behind them. Check in with yourself and see how often you have let your ideas evolve with better information.
Use the data.
Do unit tests increase the stability of the code? Is React faster than Angular? Do your users care at all about the impact of these decisions? Collect data to help you decide when to refactor. For example, you should benchmark before you optimize code. Any time you refactor code, you risk the stability of your product. Before you do, make sure data supports your decision and that your choice matters to your customers.
As you strive to tease out your biases and rely on data, wisdom and collaboration, you will be a real asset to your organization.
Article Provided By: Forbes
If you would like to discuss Your Software Development with Mojoe.net or your website’s analytics, custom logo designs, social media, website, web application, need custom programming, or IT consultant, please do not hesitate to call us at 864-859-9848 or you can email us at dwerne@mojoe.net.
Recent Comments