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?

How do you handle disagreements with your manager about technical decisions? I’ve learned to pick my battles and always come with data instead of opinions when I do push back. It doesn’t always work, but it at least keeps the conversation productive. How do you approach it?

How do you know when it’s time to leave a job vs. stick it out and push through a rough patch? For me it comes down to whether the core reasons I took the role are still intact. If the work is still interesting and the people are decent, a rough patch is survivable. But if I’m dreading Mondays every single week, that’s usually a signal worth listening to.

Do you think the best engineers are the ones who spot problems early or the ones who solve them quickly? I’m starting to think spotting them early creates far more value.