[steve_adams_86]

I agree. This is the classic “you don’t understand it if you can’t explain it” problem. If you don’t have the domain nailed down in plain speak, there are risks to productivity - especially if an entire team is involved. Business logic becomes open to interpretation at implementation time. That means a different solution for any developer who happens to implement it, and each one potentially incorrect and unable to interface with correct code in its own way.

I’ve set myself up for failure this way, essentially by assuming things would just fit into place as more of the project became clear. That’s a really bad way to work, haha. But you learn as you go.

[TameAntelope]

It's why "naming things" is one of the hardest problems in CS!

It's hard to work with someone who doesn't get that.

[craftinator]

I consistently have to argue with my brother about this, who started developing in the 90s and has a perfect memory for mapping terms to abstract objects.

He argues that at some level, every construct is just assembly that shuffles bits around, so nomenclature doesn't matter (he also grew up with Perl as a first language...). My argument is that it makes his code unreadable without a graph unraveler.