Agreed, but a lot of code doesn't need to be understood. Knowing which is which is the art right now.

> a lot of code doesn't need to be understood

Really? I am having difficulty thinking of any examples of code that doesn't need to be understood. If it isn't understood by someone, then how is it even working?

If you mean like a library you are using, where you aren't even reading the internals or might not even have access to it, OK, but that code is stull understood by its authors, surely?

▲

27183 2 hours ago | parent | prev [-]

Uhh... what? You'll instantaneously feel very differently when the service you're responsible for is down at 3:15am and your logs are full of stack traces that end somewhere in that code that "doesn't need to be understood". At that point, you will need to understand it well enough to fix it stat.

▲

jeremyjh an hour ago | parent [-]

Test code for a new bug is a good example. You can prove the test covers the bug without understanding the test code (you need to understand the bug, of course). There are some domains/tests where you can't do that - you need to be sure its failing for the right reason, but often you can do that without understanding every line of the test code. You can extend this to lots of related test infrastructure. If you can watch playwright test the app the way you expect it to, you don't have to understand all the code.

You can also do this for apps that are just tools for your own use. You satisfy yourself that they are working, and you use them because they save your time. You review enough to be sure its implemented the way you think it is - and if it is working, that tells you quite a lot. Sometimes you will be surprised and have some time wasted.

Yes, yes - there are people who will make the wrong choices in some of these cases but that doesn't mean there are never cases where you can do it.

More broadly - anyone who works in a team is already working with code they don't fully understand. I have code I wrote years ago I don't fully understand. I trust its observable properties and its track record.

	▲	27183 38 minutes ago \| parent [-]
		> You can prove the test covers the bug without understanding the test code (you need to understand the bug, of course). I'm not following.. When we write regression tests those tests encode invariants we expect to be maintained under source code transformations over time. If I don't understand the test code I've written, how can I know which invariants I've imposed? That's why, broadly speaking, we write test code to be as simple as possible above all else--it's absolutely imperative that these invariants are not only intentional and easy to reason about, but also that when an invariant is violated we can easily discover why. Often, on a team, the person encountering a test failure after making a code change is not the person who originally established the invariant, so it's very important they be able to easily understand it. I see no possible world in which failing to understand the test code is... possible? Like, if you have indecipherable test code things are really bad in your codebase. Fixing that is P0, because it'll compound rapidly.