Anybody can learn how to code and get really good at it nowadays. Implementing code isn’t the hardest part anymore. Trying to figure out how an application should flow for a user has crept up that list of priorities. Getting that information out of a product manager or project managers can be tricky since you’re all speaking different jargon. That means someone has to be able to translate business logic into code — and that someone is you.
Not every developer will have to directly talk to business managers in their career, although that doesn’t change how useful it is to understand the business needs. It’s one of those things you only get with experience and it is a subtle art that depends on the industry you’re building an application for. Here are a few reasons why I, as a software engineer, think you should always try to understand the business logic, before you jump into the code.
It gives you a reason why things work the way they do
As you’re adding features to an application, it helps to know how it currently works and how users expect it to work when with your new feature. When you know a bit about the core business behind the app it helps give you perspective on where the company is heading and then you can write the code in a way that helps support that. If you have ever seen a ridiculous task that makes no sense as to why anyone would ever want it, remember, it was a decision made to drive the business forward (hopefully).
Working off of a task list without context can make it more difficult to implement features if you don’t understand what a user will do with it. Don’t be afraid to ask questions about the product you’re working on because the business people love that (sometimes).
Learning about the business logic will not only make you a better developer, it will also make you a domain expert on the product. You will understand more about how the app works in that industry than most people in the company once you start writing code with the business needs in mind.
It tells you what kind of features or changes you can look for
There’s a huge difference between the initial setup for an app that get 10,000 hits in a day and an app that get millions in a day. Knowing that a business is trying to grow will give you some insight on what to expect from the task list.
After you have learned what the application does, how it works, and how the business wants it to work, you can start being proactive with your coding. When you sit in on a meeting with business managers and they talk about budgets and release cycles, you get an idea of what might be coming your way.
If they are going over metrics for user activity, you might expect a lot more feature requests or get ready for performance testing. Remember, the business needs are what drive your task lists and a huge part of your work environment. When you pay attention to what the business is doing you can be better prepared for any bombs that get dropped.
It helps you give better communication with product managers
Product managers work with developers from time to time and they can have great conversations. The product manager can teach the developers about the business and the developers can explain the tech to the product manager. When you are in an environment like this, take advantage of it! You can explain to a product manager why a certain feature should be implemented in a different way or how long a particular task will take.
They are also your resource to ask business logic questions. Maybe you know that some functionality is already working in the app and they forgot about it. When you tell them stuff like that you just saved both of you a lot of wasted time. You can even get them in on your sprint planning meetings to get feedback on user stories and get general ideas of what they are looking for when the task is finished.
It helps you understand how the core business works
Knowing about the company you work for is important because you spend a huge part of your life with them. It’s always good to be aware of what direction the company is headed so you can decide if it still aligns with what you want.
Learn about the way big decisions are made and learn how those flow to your work. Once you start connecting the dots of how the overall business needs are being made and how they connect to you, you’ll find yourself doing the work a little easier with more purpose.
When you run into a case where you have multiple options to fix an issue, you’ll know the best one to pick because you have an idea of what might come later. The details of the core business will also help you communicate better with different parts of the company as well. Having domain knowledge is another big deal when you learn about the business. You’ll be able to work through the code faster because you know how everything should work and why.
This is just some of what I’ve learned in my developer adventures. What do you think? Do you think it’s that important for developers to understand the business side of things or does it just depend on the person?