This is the second part of the series on how to be passionate about your work. In the previous article, I shared general information about job satisfaction in IT, how to define happiness at work, and what helps me personally to be passionate about my work while providing media/scientific sources and jokes whenever I can.
In the second part, I will focus on what helps me personally to be passionate about my work.
Take Initiatives
I enjoy taking the initiative at work to a degree when it doesn’t bother other people. By initiative, I mean introducing new concepts, ideas, approaches, processes that can be useful or take on some new challenging or interesting work that I can avoid. This research shows that taking initiatives is overall well-correlated with job satisfaction. Even though it may be a correlation rather than causation, it works well for me.
For example, when I had a project that was not satisfying (you can find my strategy to cope with a “bad” project here), I tried to pick up various activities in the company to entertain myself. Writing articles, mentoring people, helping to organize the conference, English lessons – most of the involvement came from me, and I asked my company where I could be useful so that I can switch my thoughts from the project.
Initiating new things is not only fun but typically useful for the team and the company. You can help with a new process in a team or in the company, or you can generate new feature experiments to discuss with your Product Manager.
This mindset is also about the desire to try new things in code, learn new aspects of programming and try approaches that you didn’t try before.
I was really glad when I finally could dig into the languages outside of Python. Even though it was a little bit scary and new, I tried to accept challenges to code in new languages. It both entertains and helps me to learn. In the same way, it can be a good knowledge boost if you show the initiative to take on the hardest problems on the project. However, don’t be the person who takes away all of the interesting work from the rest of the team.
Also, taking initiatives can lead you to unexpected new opportunities that you didn’t think of. Getting a little knowledge of C on one project can later help you get to a new IoT R&D project. Taking on some Product Management tasks can help you get to a management position or give a better foundation for creating your start-up. While most of the initiatives may bring little useful results or benefits, there are still some that will bring tremendous results that you totally didn’t expect.
For example, once I decided to expand my mentoring program to spheres outside of programming. I helped the mentee improve his English with specific steps and the timeline. Ultimately, It made me interested in coaching, and I decided to read an article about it. Later on, I read a book, got really excited about the subject, and helped my friend get a new job with coaching sessions. Eventually, coaching knowledge appeared to be useful in my new position as a Tech Lead.
If it wasn’t for the mentoring that expanded to English learning guidance, I wouldn’t have a useful skill for 1:1s and help with team members’ career paths. In the same way, a lot of my knowledge is the result of many initiatives and experiments that I tried!
Keep Asking ‘Why’
The constant process of challenging assumptions and trying to dig deeper is an essential part of education, involvement, and happiness for me. I have heard an opinion that with the growth of seniority, you don’t need to learn as much, and it’s not that important to be that curious as before. I would say quite the opposite. When I started, my knowledge was limited, and it was essential for me to understand just enough things to get the job done. It was enough to understand the web framework that I used well, get a handful of libraries and follow the framework’s security advice page without understanding much what CSRF and XSS attacks are.
That time, trying to understand everything in depth would be overwhelming, so It was more reasonable to figure out the essential minimum and to learn “just enough” to finish the task. As my knowledge expanded, I started to have a foundation to build upon, and therefore, the number of “whys” only increased.
Almost every day, when I find something intriguing or worth further exploration, I mark it down to read later about. Typically, I don’t even have time to read everything through, even though I’d really like to. And “aha” moments or understanding that I had incorrect knowledge happen to me quite often.
For example, I thought that Websockets works on top of 2 UDP connections as there is no such thing as an application-level acknowledgment of messages. That was completely wrong! The WebSocket protocol is built on top of a single TCP connection.
Also, I remember a discussion with a groupmate a long time ago that it’s impossible to build an async engine implementation with just 1 thread – for example, JavaScript claims to implement it. Yes, it was completely impossible until I read the “under the hood” explanation of how Futures work in Rust. They explain exactly how it can be done using 1 thread with the help of an IO-aware system blocking primitive such as epoll in Linux.
And it doesn’t stop with technical topics. There are many assumptions and rules in methodologies and processes that tend to be taken for granted. I’ve seen people immediately frown when they simply hear the word “waterfall” or that a team doesn’t run “complete” Agile.
Even though all of the teams I’ve worked with mix techniques from different approaches (yes, including waterfall). It took me some curiosity and time to figure out that there is no such thing as “bad” methodology and that they are tools in the same manner as software languages are. Claiming Waterfall being a dreadful methodology is as claiming C being bad language. They are fine in appropriate contexts.
“Whys” can exist in various forms. For example, one of the values of a team I work in is “the are no stupid questions,” and I think it’s a good principle to exists in a team to build emotional safety and an environment of knowledge sharing and trust.
Ask your teammates why they chose that technology and approach. Ask your Tech Lead why you have the processes you do. Ask your Manager why the company strategy is like it is now, and ask your Product Manager why you have such features on the road map.
I think that level of curiosity is a powerful engine that will eventually determine how good a software engineer can become. Our field has a very fast pace of evolving and there are myriads of interesting topics to read about. The moments when I find some piece of knowledge that shatters my previous picture are truly enjoyable for me and, I hope, for you as well.
How to Take Failure
I fail all of the time, my assumptions turn out to be wrong, my judgments and predictions may be completely incorrect, my estimates fail, and I produce bugs. It’s the essence of Software Engineering to try and fail, so there is nothing to be ashamed of. However, it’s important to learn from the mistakes.
Sometimes, trying something new, like introducing a new tool to a project, a new process to a team, or giving a public tech speech, can be scary.
We are all afraid to look incompetent, stupid, and short-sighted. But at the same time, there is no more powerful approach to learning than trying something out. So it’s important to embrace that you can and will constantly fail in this long journey.
It’s worth mentioning that the same mindset should be applied to people that surround you. There is not a single person who doesn’t make mistakes, your manager, mentor, or role model included. Sometimes it may seem that the mistakes they made were obvious to avoid. However, it’s always easy to judge from hindsight.
A very good example from my experience that still gives me a little bit of shivering down my spine each time I recall it. When I worked on my project at university in my second year, I needed persistent storage to deploy my Django application on Heroku. I had zero knowledge about clouds at that time, and I needed to find something quick to integrate with, cheap or better, even free. A lot of guides pointed toward using S3. If you remember your first exposure to AWS, I think you understand how lost one can feel. I needed to simply create storage for my images, but I had to go through tons of concepts and configurations. In the end, apparently, having been able to get all of the concepts, I used my Admin API Key to access the S3 and pushed the key right to my public Github repo. The next day I saw a star on my Github repo from a person I didn’t know and a bill for 3000$ for using GPU-optimized EC2 instances. One crypto miner apparently enjoyed using my AWS Admin API Keys…
After that, I try not to judge others and remind myself of tons of stupid mistakes that I’ve made. I try constructive feedback.
Feedback from your colleagues is a very powerful tool.
So try to ask for it whenever you do something that other people have more experience with. For example, if you give a public speech, choose a few people afterward in the room to ask them what they liked/disliked and what can be improved. If you make your first system architecture documents, find out a few experienced developers or software architects in your company that are willing to peer review it.
One of the essential things to mention is that feedback should be constructive, and not all people can deliver it in this way. If you notice that feedback from a person brings you more bad than good because they are sharp in their words and judge you or provide it in an aggressive way, it may be worth simply stopping asking for feedback from the person.
I always try to provide constructive feedback to others. The first rule that is sometimes missed from the guidelines that I cannot stress more is – ask the person if the feedback is needed. I try not to jump straight ahead with providing my “precious” opinion because some people are just fine without it. It doesn’t work with situations when you must give feedback to a person, like in the case of a person offending other teammates, disrupting team spirit, or not meeting the performance expectations. The main rules of providing good feedback are the following:
- State why you give the feedback and what you want to accomplish.
- Describe your feelings and how you see the situation if it’s needed. It’s a good approach, especially if you provide negative feedback and expect the person to change. For example, saying that the person makes you feel as if your opinion doesn’t matter during the meetings because you see that the person gets irritated each time you propose an idea is a good start of feedback as it focuses on how you feel and you don’t blame the person for anything.
- Don’t focus on personality. Focus on the action. We tend to generalize a person’s bad behavior to the person’s personality and attack it instead. It’s not the right attitude. All of us act irresponsibly, but not all of us are irresponsible because of that.
- Give a recommendation on how to improve the situation if appropriate.
- Discuss the person’s opinion on the situation, their feeling, and next steps.
Be Nice
Having good relationships with people you work with contributes much to be satisfied with the workplace. Therefore, it’s important to be able to treat other people nicely and be treated nicely in return. I’ve already mentioned a few points already such as embracing that other people can fail, having a positive attitude to challenging assumptions in the team, and providing constructive feedback, so let me aggregate all of them in a list that I try to stick to:
- Don’t think that you are smarter than others. Firstly, you are not. Secondly, I don’t think that it can bring any good to anybody. Every person around me has strong and weak sides and makes mistakes from time to time. Never treat others as if they were stupid. It can only create bad relationships.
- Help other people to grow and learn. Try to give them feedback if you think it’s useful, and they agree to accept it. Share knowledge and materials that you find interesting.
- Help others when they are stuck. Be open to participating in architecture review for another team or sharing the findings and experience you have got from using the CI/CD tool to a new team that wants to introduce the tool in their pipeline. Be easy to approach and be helpful.
- Don’t let your emotions drive your behavior. Work is never the place for you to show your emotions and burst at other people. If you do something because of emotions that should not have been done, come back to the person and say sorry.
- Commit to the only thing that you can accomplish so that others can rely on your words and plan accordingly
If you work according to this, people will enjoy working with you, which will benefit you and them. At the same time, it’s important to understand what to do if you need to deal with an unpleasant person yourself.
How to Deal with Unpleasant People
One of the important ideas I believe in is that software engineering is not a field for jerks. Most of the people I interact with are very pleasant to work with most of the time. It can happen that once in a while, a person acts like a jerk, but the person comes back and says sorry. Then, it’s almost fine. The situation is completely different when a person is a jerk all of the time.
So let’s start with how to deal with good people who don’t do something as expected. If a person skips half of the stand-ups being late or rewrites the code after your colleagues at night, it’s typically not what you want to see. Try to give feedback either to them or, if it’s more appropriate, to their manager. Give them a chance to change and adapt. Most people can do it.
And for jerks who don’t change – try to kick their ass out of the door as quickly as possible. I have zero tolerance for jerks at the workplace. Let me give an example of such a situation.
Once I had a very toxic ML engineer on a team. He would get angry at you for giving comments in pull reviews responding with “why are you not so picky about your own code?”, he would blame all the world around him for not meeting the deadline, he would scream at the CEO and other colleagues at meetings when he didn’t agree with them. He would write messages in slack throwing obscenities at you and delete them afterward.
It, actually, led us to a rule to speak with him only in public channels. In addition, he was not a good engineer either. The quality of the code was awful, and he would struggle for a month to bring his ML model into production code. The reason he was on the project is that the start-up company didn’t have enough resources to have someone better and the guy was affordable.
I didn’t work much with the guy, but he truly infuriated me by how he treated other colleagues. Three other people and I were from one company and worked as consultants on the project, with the whole start-up team being of just around 10 people. Being backed up by another consultant who was a Tech Lead on a project and who also agreed the behavior of the ML must not be tolerated, we decided to do whatever it takes to get him fired. As a result, we came to the management and said that there are only two ways out of it: either our whole consultant team leaves or he gets fired.
Even though we were not likely to leave in any case, it did the trick. They gave the guy the last warning that brought him back to his senses for a month and made him leave afterward. By the way, now the person works in one of the FAANG companies, so I feel really sorry for his team if he acts the same way he did back then.
Conclusion
Taking initiatives, Ask whys, embrace failures, and be a pleasant person to interact with. I believe that all of this can help you to be happy and passionate at your job. And, please, don’t tolerate jerks.
This article is a part of the “The Rational Software Engineer” series. It covers topics related to optimizing personal processes, education, career development, and being passionate in a software engineering context:
Tags
Create your free account to unlock your custom reading experience.
0 Comments