Code Is a Side Effect of Communication: A Key Lesson on My Path to Software Architect
Many years ago, when I was just starting my career as a programmer, my main task was developing accounting software. I enjoyed solving technical challenges, but I actively avoided diving into accounting terminology and, even more so, interacting with accountants (back then, there were no business analysts). One day, my manager told me: “A programmer without domain knowledge is useless.”
I remembered these words well, but they didn’t become a motivation for me at that time. I kept working, convinced that terms like “journal entries” “reversals”, and “balances” had nothing to do with me. And for a certain level in my career, this belief didn’t hold me back.
However, over time, I began to notice a pattern: most project challenges didn’t arise from code itself, but from misunderstandings between people.
Communication at Senior Levels
As you gain experience, your responsibilities and the way you communicate evolve. Memes about endless meetings in one’s calendar aren’t a joke — they’re reality. The more complex the system, the more discussions are needed — both with teammates and with the business side.
For the business, words from your cozy technical world might as well be an alien language. And for you, their words may sound just as incomprehensible. But once you reach a level where your decisions impact architecture, understanding the domain becomes essential. At some point, you realize that code is just a way to express agreements reached through discussions.
Should Developers Understand the Business?
Some might think: “We have analysts and architects in the team. Let them attend business meetings and hand me a well-defined spec — I’ll just write the code.” This approach can work, especially in companies with strictly separated roles.
However, there’s an alternative perspective: analysts aren’t needed in the team because they create a “telephone game” effect. Business problems pass through multiple filters before reaching the developer, which can lead to misunderstandings or incorrect decisions.
Less Ego, More Collaboration
Modern development is not just about complex algorithms or design patterns — it’s about communication and agreements. The clearer the agreements, the easier they are to translate into code. Conversely, weak communication within the team will be reflected in the code — through duplication and inconsistencies in logic.
Code as the Language of Business
That’s why many teams encourage direct developer-business interaction, where developers learn about problems firsthand. In this case, a developer is not just a coder but an expert in the domain.
This approach is central to (DDD), where code directly reflects the business language. Instead of an abstract term like Record in the code, a more meaningful business term is used, such as AccountingEntry.
Conclusion
Learn to speak the language of the business. Dive into the domain. And remember: good code always starts with a good conversation.
