How to avoid understanding the business domain of the software you work on
What do I look like a business analyst
Your job as a software engineer is to:
understand how to build software, pretty much
barely understand what the software you work on does
complain about a lack of requirements explaining what it should do
receive detailed requirements and then scan them briefly
make huge sweeping changes to the software that appear to work on your machine
not retain any information you read in the requirements document
not respect those that wrote the requirements document
They hired you for #1 - because you understand the technical details that are needed to make changes happen, not because they wanted you to learn The Domain or The Business. Tomorrow you could completely change industries, so there is no need to learn about this one. There are no commonalities between accounting software in different industries.
What we are seeking is a cognitive dissonance that allows you to believe simultaneously that:
what the software does is highly complex
you are smarter than the people that understand it
People like business analysts, product managers, sales staff, and that VP with a nice smile understand it completely, but they can’t possibly have the brain power to understand things like while loops. In fact, if they add pseudocode to the requirements document to assist you, make comments about how it isn’t real coding and they should leave the real details to the technical staff.
Because after all, programming is only for the smartest among us, and people don’t self-select away from it because they find it boring or find that there is more upside to focusing on one industry and working your way up.
Stay focused on do/while loops and how the compiler treats them.
Write the requirements document by copy-pasting the source code of the prototype (written by a really smart founder who left the company six months ago) into chatGPT. No one will know because no one will read it.