A high salary, the ability to work on “important projects,” making big technical decisions impacting the course of a company, all that and still neither the satisfaction, nor the will to get up and drive to work in the morning. Does this feel familiar?
Anatomy of your purpose
In the year 2001, I became interested in developing games at a young age of 11. I used a software called Game Maker created by a university professor called Mark Overmars. It had a pretty active forum with other kids having the same passion as I.
I soon became part of this community. My interest morphed into creating games and utilities and tutorials that this like-minded community would enjoy. I found a purpose. This purpose led me to write a lot of tutorials, learn C++ and create extensions for Game Maker, even create new forum/communities by collaborating with people whom I’ve never met before, and have never met since.
Technologies came and went. Delphi, that was popular at the time (and Game Maker was also written in it) soon got replaced by other languages and tools. What remained constant was my purpose of helping by creating things on a computer. Just because the purpose was simple doesn’t make the outcome trivial. It took me a year to grok C++, an effort I’d probably not put for anything else today. The goal, at the time, was not \“C++.\” The goal was what learning C++ would allow me to do.
That’s how purpose looks. It’s when you choose a community and play a productive role, like a Goalkeeper or a Striker in soccer. You should use your best abilities.
However, today people are interested in showing off during meetings and water cooler discussions. Our motives changed from participating in a community/team to being that self-centered person who always likes to be right. How many discussions do you see online where people blame everyone, from managers to other programmers, for everything wrong with their company? In contrast, how many discussions do you see where an engineer honestly says, \“I screwed up\”?
To lead a less frustrating life, learn how to differentiate between doing the right thing, and considering yourself right. The former involves doing something productive, the latter involves complaining and bragging most of the times.
What is engineering?
As a software engineer, do you know what engineering is? Most that I’ve interacted with, don’t. If you don’t know what is it that you’re doing, you probably won’t know how to improve.
When you start playing with software for the very first time, your profession is \“tinkering.\” You go into software assuming that \“software engineering\” and \“tinkering\” are the same thing, only to get bored to death after your first year.
Engineering is the purposeful use of science. Science is a systematically organized body of knowledge on a particular subject. A programming language, for all practical purposes, is one of the sciences, while the process for creating software using it is the engineering.
Data structures, algorithms, and even domain knowledge are other sciences that a software engineer relies on and must understand.
A domain refers to a specified sphere of activity or knowledge. A sphere is a section of society or an aspect of life distinguished and unified by a particular characteristic. You build software to help a particular sphere.
Do you lack domain knowledge?
I worked for a SaaS startup in the corporate training domain, where customers comprised of people from the Learning & Development departments and the recipients of various learning materials within the company.
Creating a software that people can use to learn something new (something like Udemy, Udacity, and many others) seems rather easy. A little database here, and a few REST APIs there, and then the final icing on the cake in the form of the current frontend fad in the JavaScript world. That’s what it looked like to my developer mind, as well as every other engineer that I worked with.
Fortunately, I had the opportunity to meet a lot of these prospects in person, and also resolve support issues for large customers already using the product. My initial assumptions on the problem that I’m solving was very different from the reality.
This is where I first learnt about change management, which is all about introducing something new inside a large company. Although a lot of companies provide training portals, the engagement rate there is abysmally low. The real problem was not about how feature-rich our product was, but how much it can nudge the users to take advantage of the hundreds of thousands of dollars poured into such systems and the associated content.
The goal was not a ReactJS + Golang microservices based architecture that would be so awesome that people would just start blindly using it. The goal was to get people to upskill themselves using these portals, so that they can put this skill to better use, while keeping dropouts low. How many Udemy courses have you hoarded that just sits collecting digital dust?
It was during these meetings that I finally understood the reasoning behind a lot of obscure feature requests. As an engineer, it’s so easy to say, \“Why don’t they do just this? Why am I expected to add features that are not convenient in my fancy microservices framework?\” However, the real fun is in truly understanding your domain and then making use of your skills to creatively solve problems.
Your first step
Although I intend to write and go deeper into a lot of points that I touched above in my subsequent articles, I will leave you with the first step that you should start thinking about. It could take time, and sometimes it takes a vacation and some soul searching too.
Your first step should be answering this question to yourself. Do I enjoy helping people with things that they find hard or tricky to do, and will I be happy doing it continually?
If your answer is a resounding no, then there is little value that this newsletter will add. Or else, if there is even a chance for yes to that question (however bleak), then maybe you can find that child-like excitement in software development once again.
However, if you’re really not into software, or just think that it’s not for you, then that’s okay too. You can help the same sphere by doing something other than programming. If you consider a hospital, everyone from nurses to doctors to technologists to architects to scientists have a contribution. It takes everyone’s help to create something beautiful and useful. Just try to play a role that’s most comfortable and productive to you.
