11 psychological traps in software engineering
There are certain common behavioral patterns and effects that you can observe while working with people. Knowledge of them helps me to advocate their behavior, avoid many mental mistakes, and make better decisions. Some of those psychological traps and patterns are especially noticeable in software engineering. Today, I would like to explain to you my top 11 psychological traps.
Dunning–Kruger effect
Let’s start with my favorite one. This effect was identified by 2 American social psychologists and professors David Dunning and Justin Kruger in 1999. It basically says that people with low abilities (low knowledge about something or who just started exploring some area) have a tendency to have high self-confidence and to believe that their skills/knowledge are much better than it really is (illusory superiority). On the other hand, people with mid ability have a tendency to low self-confidence and to underestimate their real knowledge. People with really high abilities start getting more self-confidence but they rarely reach the imaginary confidence of people with low skills.
How the type error cost NASA $ 327 million
On December 11, 1998, NASA launched the Mars Climate Orbiter - robotic space probe designed to explore Martian climate from orbit and also to act as a communications relay for polar lander sent 2 months later. Nobody expected that after 9 months journey it will crash in the atmosphere from such simple software mistake.
Hard problems in NASA scale
NASA puts a lot of effort into reliability. A lot of things can happen in space that we do not observe so often (or never) on Earth e.g.:
UTF-8 - the brilliant trick to rule them all
UTF-8 is probably the biggest invention in electronic text communication since the invention of the ASCII table in 1967 and remains so to this day. It dominated the World Wide Web in 2009 and it is used by almost 95% of websites nowadays. In fact, everybody uses it but many might be not aware of why this standard has been chosen so let me put some light on this and show you the brilliant trick.
Hell of a time
The hell of a time idiom has two opposite meanings - having a good or a bad time. I would rather to talk explicitly about the hell which is dealing with time and time zones in computer science.
The first impression is innocent
There is a Unix time which is just 32-bit integer incremented every second. 0 value means the date 00:00:00 Thursday, 1 January 1970 UTC. It is also called UNIX epoch time as we calculate time inside one epoch. We switch to the next epoch and start counting from 0 value again when this 32-bit integer overflow. Second is the SI unit which is well defined as “the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom.” Definition of the second given by the BIPM at the 13th General Conference on Weights and Measures in 1967 (at a temperature of 0 K to be exact). The above part is obvious. Things start to be a little more complicated when time zones come into play.