Yes. Keep building. Been there, done that. Went through a desert of not knowing this nor that, learning stuff along the way until it clicked and I understand so much better why xyz.
This is good. Point 6 really resonates with me. I learnt it the hard way that I don't have to confine myself with only the things I can build at the workplace.
During early stages the engineers should focus on Building Skills, not chasing the pace but to understand things deeply. If something haunts like some topic or logic, do it not today but tomorrow you will definitely get it just need to spend time with it. I myself was chasing new frameworks, concepts but eventually got to know that it's only about fundamental if we want to sustain in long run.
Beyond building useful things and mastering fundamentals, young engineers should also focus on reading code as deeply as they write it — understanding legacy systems, debugging unfamiliar logic, and learning from others' design decisions is a superpower in real-world teams. Equally important is learning the business context behind the code: knowing why a feature matters, how it impacts users, and what trade-offs drive product decisions will elevate you from a coder to a problem-solver.
Stop waiting for permission - this is a big one, engineer or not. I have noticed this often with employees right out of school, where they are asking if they may do something. I suppose school ingrains this. It is appropriate to ask before proceeding in certain instances, but it can be excessive early in one's career.
Absolutely — and to build on that, I’d add that learning to navigate ambiguity is just as important. In fast-paced engineering environments, there’s rarely a perfect spec or a clear roadmap for every task. The ability to take initiative, make informed assumptions, and iterate quickly is what separates engineers who simply execute from those who lead. Early-career engineers should embrace the discomfort of uncertainty and treat it as a signal to explore, not freeze. Confidence doesn’t come from knowing everything — it comes from being willing to figure things out.
This is one of the best advices I have got! For someone just starting to work this works like gold! Thanks
Glad it resonated! The early days set the tone for everything that follows
Yes. Keep building. Been there, done that. Went through a desert of not knowing this nor that, learning stuff along the way until it clicked and I understand so much better why xyz.
That “click” moment hits different when you’ve earned it the hard way.
This is good. Point 6 really resonates with me. I learnt it the hard way that I don't have to confine myself with only the things I can build at the workplace.
I can build anything I want.
I own my skills and I can build anything.
Realizing you don’t need permission is powerful. What’s something you’re excited to build outside of work?
Currently working on devops tooling.
I'm building an AWS automation companion tool for Kamal.
Kamal is a containerized application deployment tool from 37 Signal, the team behind Basecamp.
Great advice. Thanks 😊. Although every point is necessary but 1,2,4,8 resonates with my thoughts. 🙇
Thank you! ❤️ Those four are powerful, especially when combined.
Which one do you think more engineers need to hear early on?
The one that could’ve saved you time or pain if someone told you sooner?
During early stages the engineers should focus on Building Skills, not chasing the pace but to understand things deeply. If something haunts like some topic or logic, do it not today but tomorrow you will definitely get it just need to spend time with it. I myself was chasing new frameworks, concepts but eventually got to know that it's only about fundamental if we want to sustain in long run.
I love it. Thanks for sharing your experience 🙏
Beyond building useful things and mastering fundamentals, young engineers should also focus on reading code as deeply as they write it — understanding legacy systems, debugging unfamiliar logic, and learning from others' design decisions is a superpower in real-world teams. Equally important is learning the business context behind the code: knowing why a feature matters, how it impacts users, and what trade-offs drive product decisions will elevate you from a coder to a problem-solver.
Stop waiting for permission - this is a big one, engineer or not. I have noticed this often with employees right out of school, where they are asking if they may do something. I suppose school ingrains this. It is appropriate to ask before proceeding in certain instances, but it can be excessive early in one's career.
Absolutely — and to build on that, I’d add that learning to navigate ambiguity is just as important. In fast-paced engineering environments, there’s rarely a perfect spec or a clear roadmap for every task. The ability to take initiative, make informed assumptions, and iterate quickly is what separates engineers who simply execute from those who lead. Early-career engineers should embrace the discomfort of uncertainty and treat it as a signal to explore, not freeze. Confidence doesn’t come from knowing everything — it comes from being willing to figure things out.