From Programmer To Business Enabler
And how it can help you advance further in your career.
You love coding, great. After practicing in this industry for many years, sometimes, you may be wondering what’s the next step. To survive as a programmer, we always have to write working code and learn new technologies. But to be a great developer, there is something deeper that we need to grasp. This post gives a list of those crucial aspects that may help you advance further in your career.
Understand the Problem Space
Any software development requires two types of knowledge, technical knowledge and domain knowledge. Many programmers put a lot of effort into the technical side and assume that domain knowledge will slowly build up over time. It would be much better if we intentionally put efforts into learning the domain and try to understand it in a bigger picture. Mainly we need to pay attention to the following aspects:
Understand where the money comes from
All social activity can be explained from the economic point of view. Programming is no exception here. For whatever software being written, there must be a financial motivation behind it. This motivation will serve as a guideline for domain decomposition and sub-domain prioritization. We need to focus on the core sub-domain that could give the enterprise a competitive advantage.
Understand the communication in the domain
As many domain-driven designer practitioners observed, the communication between domain experts often reveals essential strategies to decompose the system. It’s the perfect abstraction level we need to understand the domain. For example, when developing software for the healthcare industry, we should not go too deep and become doctor ourselves. More importantly, we need to understand the communication between parties involved in the industry. It is this communication and terminology that help us model the business domain correctly.
Understand how the business will evolve
The software itself is not an industry, but it’s eating the other industry. The software provides new capabilities that are unprecedented and unparalleled in the world. A lot of new opportunities could emerge when the software is embedded in every aspect of the established industry.
As a software developer, on top of understanding how the domain works now, we need to help the business to make use of those capabilities to evolve the domain. The more we think about the big picture, the more valuable we are as developers.
Explore the Solution Space
With the knowledge about money and communication in problem space, we are well equipped to decompose the problem domain into sub-domains and distill the core sub-domain from them. As programmers, producing working solution should only be the entry level goal we have to achieve. In the long term, we should target reducing the total cost of product maintenance and evolvement.
Be a problem solver
In some agile environment, the product owner will decompose user requirement into user stories. Many developers blindly follow whatever in the story and don’t pay enough attention to the big picture.
We are paid to solve business problems. We are not paid to write smart or fancy code. If the solution could be lower cost without code, then go for it. Being able to write code doesn’t mean we have to solve every problem with the code. A lot of developers tends to solve every problem with the code. For example, a lot of energy is wasted to solve the edge case that has very minimum business value. A careful analysis of ROI(return of investment) is needed before we put effort into any edge cases.
Chase simple solution
As mentioned here, a simple and elegant solution should be our ultimate goal. Whenever we find that coding is hard, we are probably doing something wrong. Instead of pushing hard to crush the obstacles, we should step back to think through the whole problem, or maybe try to attack it from a different angle.
Don’t just stop at the first working solution you produce, don’t get too attached to your working solution.
Avoid unnecessary abstraction
Programmers love abstractions, that’s why we invented tools like OOD to help us abstract and model the business domain. After seeing so many meaningless inheritance hierarchies, we finally realized that inheritance is not the right tool to model the business domain. It should be used with caution, and any time, more than three levels of inheritance are merely evil.
Also, we should be aware of the abstraction level we are working on and don’t mix different abstraction level in the single module. Here the module could be any component like microservices, class, or even functions. For example, at the function level, general purpose code should not be mixed with specific code.
As explicit as possible
Being explicit means no surprise and works just as everyone could guess. It is always better to be explicit. Hiding important domain concept behind abstraction will significantly increase maintenance cost. To achieve explicitness, we should not allow any hidden side-effects in our system. Whenever we feel we may confuse someone else or future ourselves, we need to step back and start refactoring. The refactoring could be simply renaming variables or functions, but we need to be cautious about any implicitness and try to make everything as explicit as possible.
Conclusion
Writing a working code is just the minimum requirement for anyone who wants to earn butter and bread with coding. More importantly, we should target reducing Total Cost of Ownership for our business. We need to decompose the business domain into sub-domain and put the right effort in each sub-domain.
