I think the argument of the article is flawed at the core. "Optimizing for fresh eyes is the wrong optimization". You're always having to optimize for fresh eye, whether that be for a new coming developer, or for yourself, when you haven't worked at some piece of code for a couple of months, after you have forgotten about the details of the implementation of something you wrote yourself.<p>Implicit code, by definition, increases your cognitive load. Because, now, not only you have to read code, and imagine about how it would run. You have to read it, remember all the context of what the code is supposed to do for you, and only then you're able to picture what exactly it is you wanna change.<p>This leads to harder to maintain code. The "amortized over a lifetime" part never really happens. Worse is if you leave the company, leaving all the context behind! "How does this code work? I don't know... The person who knew left"<p>One more thing against implicit code. It makes it <i>extremely</i> difficult to make things work once you're out of the realm of the assumptions made by whoever wrote that piece of code...<p>And that is what i think is the killer part of writing implicit code... Besides everything else, if the assumptions don't fit your use case 100%, you're going to have a bad time making things work, because the implicitness hides that part of code (again, by definition)...