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:

1. understand how to build software, pretty much

2. barely understand what the software you work on does

3. complain about a lack of requirements explaining what it should do

4. receive detailed requirements and then scan them briefly

5. make huge sweeping changes to the software that appear to work on your machine

6. not retain any information you read in the requirements document

7. 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.