"Debugging" is a frequently misused term in the development ecosystem nowadays. It began as an actual verb when Grace Hopper literally had to remove a moth from a computer to fix it. But now people use it to describe anything from unexpected errors to issues with (technically error-free) code.
Don't get me wrong, "buggy" code exists in the wild. Race conditions, unsafe error handling, lack of cross-browser support, the list goes on. But it's important to differentiate between implementation issues like this and incorrect assumptions based on an incomplete feature spec. Calling good code "buggy" can make the person who wrote it feel like they did a bad job.
It's difficult to gauge the level of granularity appropriate for a spec though - skirting the line between over-information and over-assumption. The former isn't practical, but the latter requires the developer to put on their product hat and make decisions about how things should work. If that developer makes a wrong assumption, that's okay! It's not buggy code, it just means their interpretation of something didn't align with someone else's.
So next time you're doing this sort of "debugging", try referring to it as "recalibrating" - the developer will appreciate it! 😇
Top comments (0)