Self-deception habits of the Software Developer
![Self-deception habits of the Software Developer](/content/images/size/w1200/2023/12/thought.jpg)
Self-deception is a process of denying or rationalizing away the relevance, significance, or importance of opposing evidence and logical argument.
Once in a cafe I was waiting for service and had few minutes to observe what is going on. An obese woman was ordering breakfast, she said: "A croissant, a sweet bun, café au lait and a yogurt, but don't put much marmalade on the yogurt".
The last part of the sentence got my attention. It was the way how she said it. She clearly thought that putting less marmalade is a decision made by a person who cares about health. By doing this decision she was a good and thoughtful person, therefore deserving a fatty croissant and a sugary bun.
Real formula:
sugar bun + croissant + yogurt with marmalade = nutritional truth
Self-deceptive formula
less marmalade < more marmalade = True AND ignore the rest
This got me thinking what kind of self-deception I am doing as a freelancer and as a software developer.
Self-deception in the Web
It's easy to fall in a trap of watching vanity metrics that pleases your ego and neglect the hard facts. For example I really enjoy watching Google Analytics page visits, but unfortunately the visits itself doesn't mean anything (unless you're concerned about server overload). More important things would be conversion rate, did people like the content, would they recommend the service/product etc.
It's nice to see graph saying that you have new Twitter followers and neglect the fact that most of them are just bots that are not interested about you or your content.
Self-deception in the software development
There are many ways to analyse code quality: cyclomatic complexity, code coverage etc. It's easy to pick metrics that suits your needs and boast with the numbers. The truth might be that be that your colleague doesn't understand the source code you've written, but you think it must be understandable as the cyclomatic complexity analysis gave you nice number.
Writing a unit test to a crappy code doesn't make the code better even if you get a satisfying green light and you have >1000 tests in the project. It's not the test itself that makes the code quality better, it's the process of writing a good test that forces you to write testable code.
Updating a production environment is something where I find fooling myself:
"The software worked in a staging environment, so it must work smoothly in the production. No need to test the production as the environments are almost the same".
Wrong.
What kind of self-deception habits have you encountered?