Offering Guidance Without Context
Be careful of "we should do X" statements without sufficient research!
There are cases where a young, inexperienced software engineer might try explore how to optimize some task to become more efficient, or achieve things more quickly, without considering the full scenario of what they are tasked to do. This is often accompanied by a lot of unspoken assumptions, and it leads to a lot of lacking considerations.
What happens then might be that they spend time and effort attempting to optimize certain problems that are not yet understood correctly, or attempting to solve problems which are not yet sufficiently defined.
This can result to recommendations or actions that end up not being useful or effective, or worse, expensive, risky, and dangerous.
Analogies
Cooking pizza and pasta
A cook is asked to cook pizza and pasta. He heard that microwaves heat food quickly, and so he recommends purchasing a microwave.
However, because he did not understand the problem (i.e. cooking pizza and pasta from scratch), he failed to understand what kind of equipment he needed. He might have also not known the limitations of his recommendation: that microwaves can only re-heat the food, not cook or bake from scratch.
Frontend web application directly connects with data storage infrastructure
A new frontend (FE) web developer learned that they can upload images directly to Amazon Web Services (AWS) Simple Storage Service (S3). Instead of building BE systems, they now recommend others and their employer to directly upload images to S3 from the user's browser client (FE app) because of "efficiency" of not needing to build a BE application.
However, because they did not understand the purpose of why BE applications are built, this recommendation opens up security risks (i.e. OWASP Top 1: Broken Access Control) to their employer, along with potential financial risks.
Caveat
To be fair, the above scenarios are not necessarily wrong. It is possible that a microwave is indeed what is appropriate, or that the BE system is indeed unnecessary. Here are possible scenarios where that is the case:
Using a microwave is appropriate, if for example:
(a) the cook is working in a restaurant that is not fancy, and the restaurant's prime value is delivering quick food but not necessarily freshly made
(b) the restaurant owners deliver microwave-able, packaged food for sale at the shop.
(c) the cook's job is not really "cooking" but re-heating food when customers arrive.
Using the FE to directly upload images to AWS' S3 is appropriate, if for example:
You fully understand the risks and dangers of exposing security credentials to your AWS infrastructure in public.
You come up with your own way to "secure" your web application (e.g. restrict IAM access roles, weak security by obfuscation).
You, as a software engineer, are building a simple prototype to test an idea or design, and want functional image upload.
NOTE: Outside of experimentation and testing, it is not recommended to take bad security practices, or advise others to do so.
Recommendations
Outright declining recommendations or solutions that well-meaning individuals might offer can result in halting overall constructive discussion and collaborative solutions design. You can do this, if you are certain that you don't want to collaborate (or if you are simply looking for someone to just listen).
However, if you are open to collaborative problem solving, then:
You can instead recommend that they ask more questions before giving a recommendation, so that they can tailor their suggestions to the situation better.
Consider if there are ways you can better communicate the situation or scenario. You might have failed to elaborate the situation sufficiently, which resulted in others not being able to understand properly.
Try to identify and define the problem clearly, and invite the person you're talking with to act as a teammate. The problem is the enemy that you would both strategically attack, and solving it together is the win condition.
References
sapalo.dev - Mental Model: Prioritization - I talk about software engineers' experiences when it comes to problem solving, and sometimes they "optimize" too early, when they have not yet fully understood the problem or do not yet understand what "correct", reliable, secure software code looks like.
Dunning-Kruger Effect - David Dunning, an American social psychologist and professor of psychology at the University of Michigan, states: "If you're incompetent, you can't know you're incompetent... The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is."
Law of Conservation of Complexity - This law states that there is a certain amount of complexity in a system which cannot be reduced. Attempting to reduce it further results to unexpected consequences or risk. Failing to understand the problem as it is defined can lead to over-simplification which leads to ineffective recommendations or solutions.
Chesterton's Fence - Reforms should not be made until the reasoning behind the existing state of affairs is understood.
Last updated