Should Programmers Solve Business Problems?

I recently came across an article arguing that programmers shouldn't be involved in solving business problems, claiming it's a harmful myth perpetuated by the industry. The author believes that focusing on business needs corrupts the pure technical nature of programming. I strongly disagree with this perspective, and here's my response based on my experience as a web developer.

Developer Levels

Let's start with developer levels. Unfortunately, the three well-known grades (Junior, Middle, and Senior) lack clear definitions. Every person and company defines requirements individually, with blurred boundaries that sometimes take unexpected turns. So, first, let me explain how I understand these concepts.

• Junior: This is the least controversial definition: a beginner programmer who has just learned theory and maybe completed a few pet projects or recently graduated from university.
• Middle: An experienced programmer who not only knows but truly understands the technology stack they use daily.
• Senior: An experienced programmer with diverse experience across multiple projects, has "production" work experience with several technology stacks, and possesses broad industry awareness. They should have experience in related fields (for example, I consider it normal when a Senior Web Developer has system administration skills) and can switch between frameworks or even programming languages without significant performance drops.

Like It or Not

Whether you want it or not, programmers solve business problems. Always, with rare exceptions. We need to understand that employment or self-employment always involves monetary relationships. Business needs to make profits, which includes paying employee salaries. Consequently, to generate profit, problems need to be solved (or, you could say, business tasks need to be addressed). Programmers need to make a living, preferably a good one. It's also important to understand that you can bring "value" to a business (or solve its problems) in different ways — both indirectly and directly.

How It Works

Let's examine a classic case and see how business problem-solving happens. A task arrives: We need to build a new website; it's nothing special. Simplified, the task flows like this: Company Head -> First-level managers -> Project Manager -> Team Lead and Designer (usually two different departments, so the task is assigned in parallel) -> Senior and/or all implementers. There are two possible approaches:

• Case 1: Just do what you're told, "just code" — everyone works within their direct responsibilities: Team Lead discusses with business and creates Jira tickets, Senior designs architecture and handles the most complex parts, Junior does markup, and Middle handles regular tasks, possibly complex things alongside Senior (for simplicity, all Full Stack).
• Case 2: Before starting work, several meetings are organized where the Senior Team Lead, designers, and management discuss the business problem in detail. They discuss not just how to solve it but how to solve it effectively for everyone — businesses, developers, and designers. They find a golden middle ground that works for everyone, and only then does development begin.

The Results

In the first scenario, when everyone "just codes," the business problem gets solved inefficiently. You get 100% deadline misses, hacky solutions, and responsibility shifting, followed by lengthy fixes and adding "new client wishes." This happens because people just did what business asked for. Nobody said it shouldn't be done this way — everyone worked like "cogs" within their competencies and didn't get involved in solving the business problem. There was no team here. After such projects, developers typically aren't viewed favorably. Business cares about results. Smart managers then hire Seniors who are willing to solve business problems.

In the second scenario, most potential issues, which always occur, are resolved through team interaction. Not to mention that developers can radically change project implementation because businesses might misunderstand what's needed. Can problems still occur? Of course, much depends on competencies, but there will be incomparably fewer issues. Here, the business problem is also solved, but effectively.

Infrastructure Projects

Some suggest moving to infrastructure projects where you can "just code." This is deceptive. Developers still solve business problems, just internal ones. These are the same monetary relationships. And the problems are the same as when working on a company's external product. The difference is that infrastructure projects are usually handled according to the first case. Hence the result. But even here, business problems are being solved, and the programmer participates in solutions.

Team

The main difference between the first and second cases isn't in implementation but in teamwork. And by team, I mean not just a couple of coders implementing the project but the entire company. The first case shows the absence of a team; the second shows its presence — everyone works together to achieve a good result. Of course, there are many assumptions, but the world isn't perfect.

Solving Business Problems ≠ Sales

I don't know why, but people often associate problem-solving with sales. Yes, many tasks are related to sales, but this is just one factor and often not the most important.

A programmer shouldn't think about HOW things will be sold, but they should think about WHAT will be sold. The quality of the final product depends on purely architectural decisions (which Senior often designs), response time, working logic, design (yes, programmers NEED to participate in interface design before development), etc. Even an infrastructure project is sold but within the company. The company's efficiency and consequently personal benefits (not just material ones) depend on the final product's quality.

Exceptions

At the beginning of the article, I mentioned that programmers solve business problems whether they want to or not, but there are exceptions. In my opinion, the only exception is pet projects - things you do for yourself. Open source projects might qualify with some stretch, but often, your commit ends up solving a business problem, just not your own.

Conclusion

Should a programmer solve business problems? Yes, they should. At the level of their competencies, position, and experience. Should a programmer SELL? Of course not, although it's a useful skill, especially in higher positions. Can you just code? Of course, you can. Can a Senior just code? No, for just coding, you can hire a middle developer.