Item — HN Reader

So many people stop when it works, without understanding why it works. Or not caring how ugly it is.

They have no long-term perspective about the future cost of support - fixing bugs, adding features, or just understanding what was done.

When something changes and their snowflake solution breaks, their first reaction is to blame the external change for causing their poor solution to fail.

Top engineers don't do this. They understand why their solution works, they know its limitations, and their solutions are understandable and supportable. This significantly lowers the total cost over time and is what helps projects deliver on time with quality.

1 comments

> So many people stop when it works, without understanding why it works.

Most work environments train programmers to act that way. I find this is especially the case at workplaces that (sort of) follow scrum and agile. In most of these places, junior to mid-level programmers are given a task to work on that already has an hours estimate on it. Managers like to optimize efficiency and programmer time, so that estimate is always tight. Asking why we're doing this task is rarely received well and the tight time estimate means there's barely time to make the change work in the first place, let alone understand why it works.

We're literally training our devs not to be top devs.

The reverse side of the coin is an engineer who has complete leeway on what they do and they spend time "redecorating" their code ad nauseam. I think there is a golden mean to be found.