Today I learned a very important rule: get context for the request. I was asked to update the versions of all the software that we were utilizing including various dependencies and packages inside each application.
I had the feeling in my gut that it would be wrong to simply update all the software such as Solr docker instances, maven dependencies, docker images, etc. At first, I took another minute to think through the task and see if it is actually going to be beneficial to update every single thing in the software or if I misunderstood the task. Not being able to pull actionable insight from looking at the task again, I asked the mentor why the updates are needed. Based on the additional context I was provided, I realized that I actually would have to do some additional research and see if some newer versions of maven dependencies, Java SDK, docker instances, and others are going to be compatible with each other. I am glad I did not blindly go on updating everything together but double-checked with the mentor.
I realized it’s very common to have these misunderstandings in the workplace. I think it’s because the stakeholder may ask for one thing assuming that you already know how to deal with it — they just did not articulate it well enough on the first try. Maintaining a transparent and open line of communication elevates these sorts of situations. For me to be a good software engineer, I have to make sure I dig deep into these kinds of requests, utilizing my critical thinking and analytical mindset, to understand what is intrinsically driving the request and what is the actual deliverable needed. Otherwise, I would end up crashing all my applications my updating all the dependencies that are not compatible with one another.
No comments:
Post a Comment