One common pattern I see in not-quite-yet-senior developers is that they don’t necessarily recognize the moments when there is more than one option. This happens all the time in programming; you are constantly making decisions and committing to particular solutions. If you are not aware of the choices you are making - you are picking the first idea that comes to mind (or the first stackoverflow answer) then there’s a good chance you are choosing poorly.
If you’re living in the world of the pull request and peer review then this can easily result in our pull requests getting outright rejected because you’ve made incorrect assumptions or decisions in your code that don’t match what the rest of the team knows or wants.
Sometimes it’s best to just to get a different perspective on what you’re doing, being like a 10-year-old and asking why?
We should be always trying to develop our instinct for seeing the assumptions we’re bringing to the table. Is this code was just one-off stuff for a simple offline process? Do others on the team expect it to be reused as a library later in an online service call path? That difference of perspective will lead to vastly different expectations for how that code should be written.
The takeaway is to make time before you start coding to talk through the approach you were thinking of taking with someone. Then, as you start coding, watch out for moments when you can make a choice and again, get some input. It doesn’t need to be a long design session; just a five minute pull-aside to get a consult on an approach.