I work at a bank writing financial software —- a trade capture system, it’s basically everything that happens after the client agrees on the price. Knowing the

I work at a bank writing financial software —- a trade capture system, it’s basically everything that happens after the client agrees on the price. Knowing the business and thus rules is the most important thing. We support a global business and Asia regulations are different from Europe, products are managed differently by different traders, etc. Knowing the business gives context to what the software is doing and why because this kind of software is written by people who didn’t understand the rules in the first place. It isn’t abstracted correctly and there is a ton of if-else branching for edge cases, variable/function/class naming that is inconsistent and often incorrect, etc. I would also +1 a known bug list. You can spend a lot of time tracking down a “bug” that seems new because it’s an edge case that rarely appears. Each time it comes up the users think it’s new and a complain.