The case for boring
Why it matters This course has spent six legs teaching you to doubt the first answer. This module is the counterweight: most of the time, the plain, proven answer is the right one, and the skill is knowing which time you are in.
Boring code uses the standard library, the obvious data structure and the shape every reader has seen before. It has three properties that clever code has to buy back:
Known failure modes: json.loads and a for loop have been run by millions of people. Their bugs are found and their edges are documented. Your new mechanism has been run by you.
Cheap reading: code is read far more often than it is written. A reviewer can check a plain loop in seconds; a framework needs its own explanation first.
Cheap change: plain code is easy to delete or rewrite when the need changes. A general mechanism makes the guess about future needs permanent.
When cleverness pays
A new route earns its place when the problem has a cost the plain version cannot meet: a read budget, a memory cap, a fairness rule, a hidden case it gets wrong. Every trap in this course had one, written in the exercise. When you cannot point to such a cost, the plain answer wins.
A three-question check
- What is the size of the real input, today and in a year?
- Which stated rule does the plain answer break? Name it.
- If none: what would the clever version cost the next reader?
Recap Plain code has known failures, cheap reading and cheap change. Cleverness must pay for itself in a cost the problem actually has.
Spotted a problem in this lesson? Report it · Ask about this lesson
This exercise opens soon
Finish the lesson before it and this one unlocks. The whole course is free, no account needed, and you can read this lesson right now.
This browser is blocking cookies for learn.floati.life, so lessons you finished here cannot open in order. Allow cookies for this site and reload.