I came across this Linkedin post where the author emphasizes the approaches of the two types of engineers when integrating a web socket into an application: one focuses on practical implementation, while the other delves deeper into underlying complexities. It suggests that both approaches are valid but highlight the value of understanding hidden complexities in software engineering without being intimidated by them.
I can resonate with the author, and I have been there and done that.
I started as "Type 1," who directly jumped into the solution, learned things on the go, and focused on wrapping up the task within the given deadline and moving on to the next task—a classic and obedient order-taker.
Then, I started realizing that my shallow knowledge was not going to help me in the long run; I started digging deep to understand the know-how of what I do and became "Type 2".
After a while as a "Type 2" engineer, I realized that I needed to level up further and become "Type 3". The author of that post didn't talk about it, so let me write it for you here.
To understand "Type 3," we must go back to the basics and ask ourselves a fundamental question.
Why do we write software?
We write software to make the lives of its users simpler, easier, and better. When they get what they need, they pay you the money, and in turn, that becomes a business. The salary we are getting is the money those users are paying.
Things like "Web Socket" or any other technologies, frameworks, or languages are tools that help the engineer write the software. The ultimate objective of writing software is to solve our user's problems by picking the tools that make sense in the given context. These tools are a means to an end and not the end itself.
The "Type 3" engineer, whom I call a "Well-rounded Product Engineer," will stay true to the above answer and balance the "Type 2" and "Type 1" mindset in them.
Returning to my experience as "Type 2", I got fascinated by the complexities of these tools. The core engineering ego (in a good sense) in my mind led me to master as many tools as possible. I started picking up language after language, technology after technology and ended up with an understanding that I needed more.
I became a victim of Confirmation Bias. Instead of picking the right tools to get the job done, I was doing the reverse. I was like a carpenter who started creating furniture with a tool that he had recently learned without considering its applicability. No wonder with the saying that everything will appear as a nail when all you have is a hammer.
If I was doing this as part of my deliberate learning, there is nothing wrong. But doing the same at my job is a million-dollar mistake. This realization kickstarted my "Type 3" journey.
Back to the "Web Socket" example that the author quoted, If a "Type 3" engineer has asked to do a "Web Socket" integration, this is how they respond.
- They start by asking the right questions and get to the crux of the user's problem that we address.
- Then, they apply their critical thinking to find ways to rephrase the problem statement to simplify the solution. They try hard not to solve hard problems.
- Then, they come up with multiple suggestions to solve the problems and have a collaborative discussion with the business stakeholders to pick the appropriate suggestion. In the case of "web socket," the potential alternatives would be long-polling, short-polling, server-sent events, or even integrating with out-of-the-box pub-sub software.
If we look at the above, you can sense that "Type 3" embodies the good things of both "Type 1" (getting things done) and "Type 2" (knowledge of multiple things to come up with suggestions) with a great attitude of doing the right thing for the business with a strong empathy towards the user's needs.
Focusing my energies on this direction is a game-changer in my career.
It may help you as well!
