Don’t Always Trust Your Senior
Okay, you usually can, just not with blind faith all the time. Although I speak as a Junior Web Dev, this post applies to anyone, of any experience level, in any field.
Don’t trust your senior, why?
As a junior, I love having one or multiple seniors around to guide me and minimize the amount of technical debt I accumulate. I learn so much and I am certainly better off with them around.
On the other hand, the following 2 experiences have shown me that regardless of how senior they are, it is probably better not to blindly follow everything they do or say.
Learning Experiences
1. The Users Are Complaining That the App Is No Longer Working!
While on a Microsoft (MS) Teams screen share session with a senior developer (SD) with more than 9 years of professional software development experience…
SD: “Wow, there’s a lot of unused code in this file here. Let’s just delete them all.”
Me (Internally): “I really don’t think that’s a good idea, shouldn’t we check if this code is used somewhere else before just deleting it?”
5 seconds later…
Me (Internally): “Anxious Web Dev, you FOOL, he is a SENIOR. He obviously knows what he is doing. Just follow what he says and everything will be a-okay.”
SD: Deletes 2 paragraphs of code.
Me: “Yeah okay sure, cool. Thanks for the help.”
1 day later …
“Our users are reporting that the app has stopped querying the databases! What happened! Someone fix it now!”, my product owner frantically types into our Microsoft Teams group chat. “I’ll look into it”, I instantly answer back.
I look at the last code-commit as that was when the error started happening. The only change seems to be the deletion of that code, “maybe it is used somewhere else” I ponder to myself. I open up my code editor then a quick global text search of the deleted code confirms my suspicion.
It is used in a lot of other places and it’s deletion caused the production issue.
Whoops?
2. The Users Are Reporting That a Form Isn’t Saving!
My product owner frantically says into our Microsoft Teams group chat, “our users are saying the form isn’t saving even after seeing a ‘saved successfully’ notification!”
“What happened! Someone fix it now!” he continues. “I’ll look into it” I answer back.
Ah barnacles, not again. I troubleshoot which code is causing this issue. I trace it back to the last code commit done by my SD (the same one as before). I run his code on my computer then I click the save button on the form. I see the ‘successfully saved’ notification. I then check my local database to see my form data saved into it.
So then I think, what if I ensure that the data isn’t saved into my local database when I click save. I shut down my local database then I click save on the form again. I see the ‘successfully saved’ notification pop up.
How is this even happening, I inspected his code even closer. I was genuinely stunned by what I saw. I realized that he coded it so that after the ‘save’ button is clicked, a ‘successfully saved’ notification always appears regardless of whether form data was inserted into the database or not.
To confirm this, I opened the form in the production web application. I disconnected my internet then I clicked save. I see the ‘successfully saved’ message appear again.
I quickly fixed it so that a success notification appears AFTER inserting data into the database. If no data is inserted into the database (like during database connectivity issues or a billion other potential problems), an error notification appears instead.
For any concerned programmers out there, both code commits were done through peer-reviewed pull-requests. However, they also both occurred early in the project before we implemented proper testing and CICD.
Takeaways
Personal
At the start of my professional career, I believed that just having the word ‘senior’ in your job title or email signature meant that:
- You’re an omniscient being because you’ve seen and done it all. (Don’t you need like a bajillion years experience to be a senior?)
- Barring divine intervention, you’re physically incapable of making mistakes or being wrong.
- You’re in the MENSA of your profession (i.e. top 2%).
- Anyone more junior than you is unworthy of challenging anything you do or say. Doing so is heathenism warranting exile (to where I don’t know).
- Anyone more junior existing within a 5m radius to you will become more smart, efficient and agile through some form of telepathic osmosis.
I think most professional juniors/newbies would be guilty of having some of the same beliefs (or it could just be wishful thinking on my part). The above experiences are rare and isolated incidences. Fortunately, they helped me relinquish the unrealistic beliefs about seniors I had before.
To Everyone Else (Especially if You’re Junior)
Regardless of the field you’re in, I think it’s always worth it to take a bit of extra time, effort, research (i.e. 3 second Google search), and maybe some 2nd-opinions to verify what was suggested or done is the optimal option given the circumstances.
I know it can be intimidating (especially as a junior) to challenge a senior, but there are multiple ways to look at this:
- You can double-check/verify their work or suggestion privately.
If You Agree With Them
Most of the time you’ll just end up agreeing with them, avoiding the need to directly question/doubt them at all.
If You Disagree With Them
- It isn’t feasible to always give someone what they ask for (e.g. because you don’t have enough time/resources, it’ll lead to bad/inferior outcomes, it conflicts with your ethics/morals, etc.).
- This is true for all of your relationships, especially with friends and family, users/customers, and work colleagues. It is completely reasonable for you to politely refuse and explain why then grant a bad/unfeasible request (and burn yourself and/or others in the process).
Best Case Scenario:
- You learn something new if your senior explains why their option is actually the better one.
- Consolidate the knowledge you already have if your senior agrees with you.
- If you discuss your disagreement with the team, you also implicitly share knowledge with the team (although the senior might prefer a private discussion instead).
- Improve an existing process/feature.
- Impress others with your idea/contribution.
- Prevent some pain for everyone involved (especially the users/customers).
Worst Case Scenario:
- It slows you down a tiny bit. My counter-argument is prevention is better than treatment (prevention also saves you more time in the long-run).
- You irritate a senior with ego issues who can’t take constructive criticism or listen to anybody junior to them. My counter-argument is trying to please everyone you ever meet in your life is an impossible and losing strategy. In my opinion, the pro’s of speaking your mind (politely and in moderation) far outweigh these cons.
To Seniors
Please be open to suggestions and questions from juniors.
Juniors are generally very keen beans, eager to learn and impress (as you would remember when you were a junior). There’s usually no malicious intent to undermine your credibility and skills or waste your time.
I have had experiences where I have presented an idea to a senior only to be rebuffed with no explanation (sometimes in a public forum). This definitely made me feel reluctant to ask for help and present ideas for improvement in future.
In my opinion, a good senior:
- Is always looking to improve.
- Is open to new ideas.
- When possible (might require a bit of wait), will take the time to assess the feasibility and efficacy of a new idea.
- Will thank the junior/peer for their idea and if they deem it to be suboptimal, proceed to kindly and patiently explain why.
I’m pretty sure everyone wants to work in a culture where anyone is encouraged to ask for help and present ideas for improvement.
Be the change you seek I guess?
Thanks for reading! I hope it didn’t come off as too angsty/ranty.
Original post published at anxiouswebdev.com on January 3, 2021.
