Unlike “tech” companies that create programs or websites for the public, most programming jobs exist to help the other employees of the company do their job better, or to help clients and customers of that company.
For example, if you’re a programmer at an insurance company, you might work on programs to help salespeople sell insurance policies better. You might write programs to help detect fraudulent claims. You might write web applications to let clients monitor their policies online.
Basically, your job will be to automate business processes for the company. So, it helps to understand the business and how it works.
At some point, you will probably talk with the people who use your program, or someone who’s gotten instructions, specifications, or bug reports from them. The more you know about the business processes, the easier it will be for you to work on automating these processes.
When people describe things, they often forget to mention steps that are “obvious” to them, but not obvious to other people.
Here’s a video that demonstrates this problem. If it’s this difficult to write instructions to make a sandwich, imagine what can go wrong with describing a complex business process.
You also need to know if your company, or its industry, has hidden requirements – like privacy and auditing.
I’ve worked with a few people who did not know there were privacy requirements about data. One person was having problems with a third-party library and contacted the vendor for support. He was about to send them information about the problem he was having but was going to include private data in his example. That would have been a serious violation of our company’s contract with its clients.
You don’t need to gain the complete set of skills that your users have. However, your job will be much easier, and you will be much more effective at it, if you at least know the industry terms and basic processes your company follows.
Return to “Life as a programmer outside Silicon Valley” index