[giraffe_lady]

How many of us software engineers have had this experience: you fight a code problem for an hour and then when you figure it out you realize a clear description of the problem was right there in the initial error message the entire time.

We aren't above this or better about it. Knowing what to pay attention to is hard, people develop a huge and complex set of heuristics that sometimes let them down. Failing to account for that adequately may be a problem in our society but I don't think framing it as individuals failing at the virtue of "reading thing thoroughly" will be any kind of solution.

[apeace]

I upvoted you because I appreciate the point you're trying to make. But also: if you're fighting code for an hour without reading the error message, you need to train yourself to start reading those messages right away! This is one of the first things I always work on when pair-programming with junior engineers. Test run fails in the console, they switch back to VS Code, start adding a console.log somewhere, and I say, "What did the error say?" Their debugging time drops by a lot, quickly.

But I think your example still works, because this is something you learn to do through training and experience, not something that you inherently know to do.

[mikkergp]

This is interesting because I think this happens because alot of the time the error isn't accurate or at the right level of abstraction. I'm wrestling one now where a variable deep in a library isn't defined, so the error message is, "cannot read property main of undefined". But the problem is quite obviously not that I have to submit a pr to the repo to add 'let var'.

But the other 50% of the time.. After a few hours I go back and read the original error message very slowly :-)

[marcosdumay]

Often it's because of non-deterministic text semantics, that only make sense after you know what the error is, never before it.

Anyway, some times this is unavoidable.