1) What is the benefit of using a metaphor?
Software engineers love to use metaphor (at least in my case), the reason is, well, most of the time, our products (the running version on production) are existed only in our mind. There are limited things we can do to understand clearly about our products, and there are at least three ways we can comprehend our software: the business view, the machine view and the software engineer view.
Side track: At this point, one reader’s thought could be: Software engineer role is to integrate among business, machine and other engineers viewpoint? So, to be a good software engineer, we need to have knowledge in Business, Computer and Psychology? Which may even lead to a more interesting question: does any challenging profession require the combination of three or more perspectives?, which I would discussion further in later posts.
Coming back to the metaphor benefit, let’s give a simple example: imagine that you need to explain to a new hire what your system is doing, how would you approach it? A typical flow could be: first, tell him/her about what is the real life version of it (if exist) or at least some thing close to it, which makes sure that he/she will be set into the right direction. Then, we will iterate slowly from the high level technical design/diagram until ultimately, the code. We may have done this so many times that we don’t even realize that metaphor has been a powerful tool in our tool box we use in daily basis.
2) Why another metaphor?
Today, there are several metaphors that exists, which helps us to set the right mindset when thinking about how to approach a problem :
- Software development is like building
- Software development is like gardening
- Software development is like surgery
All of those are good one and have served us well.
- Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.
So, why another one?
I personally feel that all existing metaphors are too specific, they are solely focusing on the development process which is about the relation between the developers and their product: the code. However, are we forgetting about another important aspect of our job: the relationship between business as well as other developers?
There should be some way to guide us to the correct direction, how should we interact with others? How should we negotiate with business people, with other engineers, with other team? What do we aim for in each discussion? What are our position in the organisation? What do we have and what don’t we have?
3) What is the metaphor?
Well, this metaphor is a direct deduction from another metaphor:
- If a company is a country, software engineer is the military force.
Yup, that’s the metaphor. It gives us a broader perspective of our profession. It is not focusing on our daily task: writing code, but give us a better idea of how our contribution relates to the overall business, what are the mentality of the engineers while designing, executing and making decision.
Think about it.
Every software is produced to either conquer new territory or protect our old one. Every tools we use could be considered the weapon we choose to accomplish the mission. We need to understand the big picture, thus take into consideration what should be the most important factors while working on a project. Once a problem arises out of our original plan, we could make decision to even overwrite existing decisions on the spot to keep the business moving, depending on the urgency of the problem.
4) How does that help?
The fun
It sheds the light into why doing software engineering is fun. It is not just about using cool weapons, which many of the young soldiers enjoy doing (which leads to something like: rather than choosing old classic pistol, we like to experiment with nuclear bomb). Countless discussions about what is the coolest, deathliest gun … are so uhm, distracted.
The fun of software engineering could also be: strategically executing the mission, utilising the least amount of resource and limiting casualty, creatively using what available in your hand to effectively solving the problem.
Inside our company
It also helps us during the negotiation/communications with other parties, we now know the position of us within the company. Software engineers are the one who executing and owning the product eventually, it is definitely up to us to define how to carry things out: time, resources and requirements in the final product/project to a certain extend. Controlling complexity and managing risk are usually mentioned, but now, we should view those in bigger landscape.
And others
Knowing about the current situation of the company could also help us to understand about the attitude/opportunity of the company towards engineers:
- A well established company (dairy cow phase), the military is something important but not crucial, the power of the military should be limited and in control.
- A growing company (unicorn phase), the military force is the most crucial, which involved in almost any decisions, with great impact and visibility.
- An early start-up (survival phase), well, every body is in the army.
5) Final thought
Software engineer is a challenging career choice with many opportunities as well as pitfalls. Choosing the right mindset/mental model could help you navigating through all complexities, focusing on the right direction as well as setting up the expectation and selecting the correct set of problems and challenges in each stage of your career.
Next (possible) blog post:
- Meaning of life
- In the end of the day, we are all thinker
- How every unicorn company will eventually become dairy cow?
trungpham90 