This summer, I am doing an internship as a backend engineer. Every engineer in my squad needs one-on-one with the lead engineer each month. Here is the core advice I got from my lead:
Try to understand the business more than the technical side of it.
As an intern, I am still not handy in the tech stack and the codebases. So I often ask the lead engineer about it. He said it was good that I asked when I got technical hurdles, but I should've not only asked about the technical side of the task. He encouraged me to ask more about the business part, like how my assignment correlates to the user need or how my story ends up presented in the front end.
I need to be more curious about the whole picture of the task rather than only care about the itty bitty of the implementation. My lead engineer told me, "You need to carve out more the business side of things here because you can easily find the technical side of your tasks on the internet, but you can't find the business side anywhere else."
Communication over speed
His other core point is that he prioritizes communication over speed. He won't be worried about an engineer that does tasks slowly. He will be worried about an engineer that doesn't communicate their progress and neither asks when they found hurdles. This behavior is problematic as the subsequent flow of the task (e.g., QA testing, UAT testing, other stories in the epic) can be blocked.
He pointed out that an engineer with high speed can be stellar and are applicable everywhere. But good communication makes people work together efficiently and solve complex problems better.
Long road ahead
I do feel that I lack that genuine curiosity about the business part of my tasks. I try to find the solution of how to grow the interest. I found How to spark your curiosity scientifically by Nadya Mason on the TED youtube channel. She encourages the audience to do hands-on experiments by themselves. By doing hands-on experiments, we will gain our curiosity about the subject.
It means I need to try things out from the company's services, click something, and explore its features. Then, backtrack it to the backend and try to understand the logic it does.
I still have a long road in my engineering journey and am always ready to improve.