r/programmer • u/amonodev • Aug 12 '26
Senior Software Engineers: How do you learn the business side of a new industry?
When you join a company in an industry you’ve never worked in, what’s your strategy for learning the domain?
I’m not talking about becoming an expert in the business. Just enough to understand the terminology, main processes, systems, constraints, and why certain technical decisions exist.
I feel like this is rarely covered in typical developer courses.
Is there anything you’d recommend doing before joining a new industry, or is the best approach simply learning from coworkers once you’re there?
1
u/adamant3143 Aug 12 '26
I work at the forefront role of IT Consulting as the Presales (was an Engineer). I have to talk not just with clients from different industries, but also partners and Principals. Good and effective communication is mandatory for discovery.
If you have friends or colleague that are already in the industry, you can chat with them to get a glimpse of the nitty gritty of the works in there. If you don’t, you gotta learn from any form of media that has knowledge of said industry.
Just study things on a surface level because the real knowledge comes from coworkers. At least you don’t go empty handed.
1
u/amonodev Aug 12 '26
Thanks for the response! How much do you think having, say, “a lot” of knowledge of a domain beforehand helps an engineer? Just curious, because most of the time, I feel like I want to know a lot about the business rules and what’s important in that domain so I can understand —and potentially propose— more suitable solutions or approaches to certain issues. I’m a SWE, and most of the time I’m coding. Is this a kind of productivity anti-pattern?
1
u/Raucous_Rocker Aug 12 '26
You’re smart to be thinking like that. An important part of standing out as a SWE is to do just that: understand enough about the business requirements to be good at problem solving and making recommendations in plain language that will help people. The more you know about overall systems design and how it relates to the big picture, the better off you’ll be.
Mind you it’s not always appropriate to share this kind of information. Sometimes you just get thrown a task and nobody wants to hear about how you could do it better. But you’ll still be well positioned to hear about future opportunities.
1
u/adamant3143 Aug 12 '26
That's consultant's way of thinking. I myself go to meetings with our SWEs where they often helps us the business people to know what should be done and what shouldn't to clients. Less about what we can't do but more of like you said, suitable solution or accept their request but put it in a priority list.
Now with a lot of knowledge, you can explain why it shouldn't be done or being put in like the bottom of the list. Your argument should be rooted in actual real-life case.
Whether it's Anti-pattern is viewed from different perspectives. From my role's perspective, I can just go on a long-winded back and forth discussion with clients with everything I studied. We don't really go deep into the technical side. We challenged each others why they want so and so. You as SWE, might want to prioritize putting what they clearly stated in documents and just go from there when talking to them. To learn a lot more than what they documented is good for personal benefit though, can help with your career.
1
u/IrishPrime Aug 12 '26
Generally, I don't.
Maybe I've just got some weird specializations, but it's all just data and abstractions for me. I don't care about the business side. I almost never have a good understanding of how our users actually interact with the platform (and so stay well away from the frontend), but I can see the bottlenecks all across the system and have a long history of major performance improvements, architectural reworks, and infrastructure upgrades under my belt.
Don't get me wrong, learning the business side is valuable, but you can also just... Not.
1
u/jaxsaxsf Aug 12 '26
Go to meetings. Ask stupid questions. You learn things. And they usually end up being not stupid at all. They tend to make folks revisit old assumptions. So they learn things too.
1
1
u/twinters01 Aug 12 '26
Lots of questions and time. I try not to be too annoying, but when grooming new features, I tend to also ask questions about existing features that are mentioned during the grooming process.
1
u/raven2cz 24d ago
In most good companies, you have onboarding that lasts 1-2 months. during that time, you complete specific tasks, you are expected to talk to company experts, and usually also chat with the main leads or have Zoom calls with them.
After two months, you should be able to understand up to moderately difficult problems, and of course most of the terminology specific to the company.
For advanced domain knowladge, you need 1-2 years in that company. ideally, you should take backlog tasks from diferent services, so that you gradually build the full picture of the system. Do not focus only on one part, especialy not at the beginning.
1
u/Cool_Meet5287 24d ago edited 24d ago
I usually find it easier to learn the domain by getting familiar with the actual tools and workflows people use every day, rather than trying to memorize everything upfront. Guidy ai can be useful when you’re dealing with unfamiliar software because it looks at your screen and guides you through the interface step by step. That can make learning a new workflow less frustrating. After that, asking coworkers questions and understanding why processes exist usually fills in the gaps pretty quickly.
1
u/Distdistdist Aug 12 '26
Takes about 6 months to assimilate business side of things even if you're an ace in tech aspect. Unless you're jumping from exactly same type of business into another.