How do you decide when to keep digging into a problem versus stepping away? I’ve learned stepping away usually helps more than brute-forcing through frustration.
3
What’s one engineering “best practice” that you think is actually overused or applied in situations where it doesn’t add much value? For me, it’s excessive documentation on very small, low-risk changes. Documentation is important, but I’ve seen teams spend more time documenting simple fixes than implementing them. Where do you draw the line?
I'm a junior engineer, but I inherited a project mid-construction because the designer left. I wasn't around for the early phases, but now I’m running the site meetings. I'm stressed about the technical gap and being asked questions I don't know the answers to. I don't want to appear clueless in front of the clients, even though I am. Is it okay to say that I don't know, but I will get back to them? Or does that look unprofessional?
If you can afford to step away without any major impact then it probably isn’t worth your time
It's a terrible mentality that is unfortunately true because how modern business runs. Shoot the 70% solution now and make corrections later as needed. For now just stem the impact to the customer.
Sometimes stepping away and giving it a rest is the best thing to do , sometimes the answer will come out of the blue when you least expect it
Sometimes asking up the chain of command how important it is can help decide whether you should devote your time because your time may be valuable in other ways too. Of course, some digging in for details helps the original developers find a bug or find an alternative way to do what you need to do.
I step away when I get stuck for more than a day
Good advice