I will be coding in the near future
1
I will be coding in the near future
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?
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?
What was the biggest mistake you made early in your career that ended up teaching you a valuable lesson? One of mine was assuming everyone interpreted requirements the same way I did. Learning to ask clarifying questions saved me from a lot of rework. What’s yours?
Do you think engineers spend enough time thinking about the user experience of internal tools? I’ve seen teams tolerate painful internal systems that they’d never ship to customers.
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?
Great idea!
Cool!