Communication is often underestimated in our job. That's because when we start our journey with software engineering, we focus on the hard skills, such as backend language, frontend language, CI/CD, databases, infrastructure, and all the other sexy stuff. But as our seniority level increases and we get more and more experienced, we should start thinking about our soft skills as well. Because our job stops being just writing the code. Communicating with other team members and business gets more and more important.
In this post, I will use business interchangeably with the Product Owner, Manager, or anyone that should bring application requirements, in your company.
Unhealthy relation
Have you ever experienced when a business or Product Owner / Manager came to you and said that he wants you to display certain columns from the database on UI? Or that you should simply select, insert, whatever value into the database?
This is just an example. I hope you see where I am going. The business often gives us workarounds or what they think is the best technical solution, instead of requirements.
I truly believe that we need to understand the problem first before we solve it.
And let's be clear here. I don't mean that you need to learn about CROSS-JOINS to solve the problem. I mean to understand the purpose. The WHAT of what the person that talks with you want to achieve.
It might involve some discussions. It might require some time. Especially when you'll start digging for the first few times.
Looking through the prism of what we currently know
What I noticed is that the business or users of our application often look through the prism of the current system. Many times, it's not what the business or users really want. Talking with users or the business will lead to a better solution.
Ask few questions. Try to truly understand a problem. You might get surprised when during discussions you'll run into a solution that doesn't require writing a single line of code.
Let's stop talking SQL.
Latest comments (7)
Thanks, Amelia! And totally agree with you. Soft skills + hard ones make you unstoppable and desired on the market :)
Great article, and such an important + undervalued point. I actually left a previous job because we handled tasks exactly as you described, focusing too much on the technical solution and not enough on the actual requirement. It led to major developer burnout, because devs felt like they had no freedom to actually solve problems.
I would love to see a follow-up article with some specific examples or a list of do's/don't's, to give people some concrete steps they can use to improve their communication.
Thanks for sharing!
Thanks for your comment, Cooper!
Glad that you had noticed the unhealthy environment and changed your job 👏
When it comes to examples, I should probably anonymize the situations (when it comes both to a business person and the task itself), but there are some, even recently. The difference is that now I am smarter than I was, so I do talk and show empathy instead of getting into the code or solution mode right away.
And I was expecting NoSQL to be praised here! 😆
Great article! It's as they say, you don't become a senior not only because you're knowledgeable, but also because you've matured in the professional workfield. Even though we hear about soft skills everywhere, we still continue to neglect this part of our career.
+1 for NoSQL 😁
Exactly. Senior is much more than knowledge. You need to be able to talk with people to understand what problems they have and what they really want to achieve. And yet, often we don't even do the 5 Why's to dig a little deeper...
Thanks, Łukasz. Such an important point. Too often, technical people are our own worst enemies when it comes to this stuff. We toss around technical language in discussions with our business customers without proper context and they pick up bits and pieces and start to throw them back at us in non-contextual ways. We need to first speak the customer's language and provide feedback in the same way and only then start to use more technical terms in more consistent and precise manners. And, above all, determine the problem that needs to be solved FIRST.
A great addition to the post, thank you, Tim!