Business, business and more business.
“Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities.” [1]
The quote above, from Eric Evans’ Domain-Driven Design book, speaks to a challenge many of us in software development face. A lot of us prefer jobs that build on what we learned in computer science.
We look up to senior engineers who work on complex systems and wonder, “How can we do algorithms like them?” or “How can we build a microservice architecture like Amazon have”
While coding is fundamental, it’s essential to recognize that it’s not the actual purpose. It’s about writing meaningful lines of code. It’s about solving problems with the code. A line of code means nothing if there’s no context to it. Clients don’t say, “Nice hexagonal code!” Instead, the soft. enginyeers notice when users are happy with a feature or when time to do a simple action go down or even desapear because of your code.
The biggest differentiator in this field is being able to accurately diagnose and solve business problems with technology. That’s why software engineers are referred to as engineers. You are a professional problem solver and you need to know the domain space to be able to effectively do that. Otherwise, you are simply a coder who has little value beyond your technical skill set, soon to be replaced by AI.
If we only focus on technical problems without understanding their real impact, how can we know if we’re doing well? Understanding how your code improves things, like user satisfaction or cost savings, is what really matters. Code is just a tool to get there:
Code -> Software -> Value
“The critical complexity of most software projects is in understanding the domain itself.”” [1]
References
[1] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software