Coming to the "wrong" conclusions

Have you heard about “unlearning”? This is when we have come to a conclusion, a new habit or rule that we apply, ultimately turns out to be subpar or sometimes even wrong.

It is extremely hard. We are learning machines, best out there, even in the AI age. After all, we try to model our computer systems after biology.

I prefer to avoid unlearning by learning better in the first place.

Using my inner value system and already learned preferences, whenever a new experience teaches me something, I consciously ask, if this new method I would apply to avoid or mitigate, would work widely?

If my inner voice says a resounding “no”, I would dig more, why? And what could be done?

Self-knowing really needed for this. And wide interests, reading a lot. And to see the consequences of decisions first hand. Hearing about it is not a strong enough feedback loop for most learners.

Take the example, a software engineer builds a new invoicing system. The system works for two years, he leaves the company for a new opportunity. Bringing all what he has done as good experience, reaffirming himself he has done well.

In the third year, problems start to happen with the system. A new engineer finds architectural mistakes, it’s untested, some parts are shaky and can’t even build the system easily. He starts iteratively improving it. The users praise for unresolved bugs finally gone. After two years, this engineer leaves too.

A third one comes in to maintain the system. Which now has two competing architecture in it, some pages like this, some components are like that. Documentation is sparse and does not say the why. Commit history is gibberish or only contains merge commits squashed. Can’t find out which arch came later and where the project was intended to go. Users want features. Get bugs instead as now a third architecture starts to compete.

Which one of these engineers would you think learned from this project? And what are their take-aways? Assume the best from all! They are seasoned, senior engineers who know product and user experience too, well-rounded experts with decades behind them.

First one, will repeat what he has done, as it was good. Never seen how his own decision impact the future 4 years down the line. Same effort he could have built better systems, yet no feedback loop for him.

Moral: Good practice to check in with your old employers, see how they are doing, learn a thing or two about your impact.

Second one, will say his predecessor was not up to the job. He never saw the time pressure and original learnings that went into building the system from scratch in the first place. His incomplete transition to a better version of the system now left confusion. He documented, yet he missed the hardest part of the documentations: why? For your own mind, the answer is obvious to this question, for others, it is not.

Moral: Never assume you will do better as you don’t know the circumstances. Document the decisions taken and the why. They may stand in the future and clarify confusion.

Third one, will get disillusioned in the craft. Burn out and leave the organization where they struggle with tech debt. Or start a complete rewrite that never will be finished as he unfortunately does not hold the lessons and knowledge from building it in the first place.

Moral: if you understand the full context, you can more easily see if the conclusions are correct or not. Find out of the history from the people worked on it before. Give and ask for feedback even years apart as hidden consequences teach the most.

You may agree or disagree with my conclusions in above cases. That is fine. Actually good, we should, due to different contexts and experiences.

What was your worst conclusion to be unlearned?

What tech decision taken by someone else impacted you the worst?

P.s.: place is limited, the organization should have take-aways too in this situation on the other side.