Do you assume or confirm?
Chapter 1: How I learnt to distrust JS Date
Kahneman’s famous book exposes two ways of thinking:
- System 1 as automatic, fastest, emotional, quick to respond to stimuli, always on the watch basing its output on assumptions
- System 2 as invoked consciously, slow, strongly logical, methodical, basing its output on reasoning
So when it comes to problem solving, we activate System 2; but familiarity to a domain builds a stack of assumptions that, on System 1 mode, overlook to re-validate. This overconfidence bias misleads mostly, turning our decisions not the smartest.
If we were to analogise both systems when getting stuck at problem solving, a quick picture on mind is the one of Coyote realizing standing on nothing but air while chasing the Road Runner. Letting System 1 on command for too long, bypassing verification of premises given for valid, is us playing Coyote.
Therefore, it’s mandatory for us to ask ourselves “Am I assuming these premises or have I already confirmed what I’m basing on?” so that we don’t fall to brain locking valleys. Which criteria to use to activate this question on System 1? Pick one, I take the laziness criteria: “The next hypothesis I’m about to buy in, the foundations for it are assumed or have I confirmed them all?” This simple question can save us lots of time and effort that, if not posed, could wear us off.
Application problem
Bit of context:
Two systems communicate based on event messaging, originator system sends events in an ordered sequence, receiver system should apply event data to its state and so update its UI accordingly.
Problem:
- Even though originator system sends its events as expected, receiver system UI does not update in given order
- These symptoms were well known, though root cause remained unknown, for which a race condition in receiver’s event interpreter was the scapegoat
- Evidence of events emitting at the same second support the race condition theory
- Eager to make changes in originator system, considering events from a while ago are sent in half time due to some recent fine-tune
- I’m asked why to change originator, I can’t answer anything but non-sense, feeling pressed to deliver a fix asap
- Learnt there’s an event’s time comparer in receiver, using MomentJS
- Event A coming at the same second as event B share also first 3 millisecond decimals
- Event A takes a bit longer to process than event B because some business rules applied along
- Before updating UI, receiver’s time comparer should skip an event if it’s time is older than one previously applied
- Because of JS limitation, and so MomentJS, time comparison is limited to three decimals
- Comparison is now done between time strings, sliced up to compare full milliseconds when events times draw
Lesson:
- Read documentation
- Get to the bottom of the problem prior to offering a cheesy workaround
Solution:
- Get raw time and slice up milliseconds for comparison when two events tie
Problem:
- With last solution, expected times to compare properly, but tiebreaking milliseconds differ in digits from reported cases
- Slicing strings might not be enough, opted for a regex, solution delivered
- Though feature reliability has improved, it’s not enough: some other reports turned in
- Now it’s not milliseconds taking seconds segment of event’s time, but incomplete numbers
- All of these extracted incomplete milliseconds had showed up in their corresponding full times as with trailing zeroes
- Testing milliseconds extracting function works with trailing zeroes, hit a block
- From a teammate, got a hunch about the serializer library, and so tests and confirms it is
- NetCore JSON serializer does not include trailing zeros in datetime by default
- Add an ISODateTimeConverter specifying full decimals for datetimes
- Solution works, event time comparers more reliable
Lesson:
- If it is not in business layer, then suspect of other supporting layers
- Use a reliable way to identiy your target in strings that matter like regex
Solution:
- Favor thoughtfully-crafted regex instead of quick slices
- Check on possible defaults affecting data
References:
- Daniel Kahneman: Thinking, Fast and Slow (2011)
- Github issues: https://github.com/moment/moment/issues/3256
- MomentJS project status: https://momentjs.com/docs/
- NetCore JSON serializer drops trailing zeros https://github.com/JamesNK/Newtonsoft.Json/issues/1511
I’ll come to this series whenever I stumble upon situations that bring the question: are you assuming or confirming, and overturn as much thinking aspects that I perceive makes us better not only at work, but also at our daily life
