It took me 17+ years to realize what I'll tell you in 18 minutes

0:00 If you've been following my channel, you know I usually teach you AWS, data engineering, SQL, ETL, all the technical stuff that helps you build systems and solve problems. But today, I'm doing something completely different. I'm going to share the career lessons that took me over 17 years to learn. Lessons that could have saved me years of struggle, self-doubt, missed opportunities, and honestly, some pretty big mistakes. I have worked at different companies like Accenture, Twitter, American Express, Royal Bank of Scotland, last but not the least, Amazon and have been through migrations, promotions, setbacks, bench time, project failures and major career pivots. If I could go back and tell my younger self these things when I was a

0:47 fresher at Accenture, my career would have accelerated much faster and with a lot less stress. So grab a coffee, settle in, because in the next few minutes, I'm going to break down the biggest myths and mental blocks that are probably holding you back right now. These aren't just theories. These are battle tested lessons from the trenches of a 17-year tech career. So let's dive in. Point one, stop waiting to know everything. Just apply. First big myth that kills career is I need to know everything before I can apply for that particular job. Here is the truth. If you match 60% of a job description, you should apply. But let me tell you what I

1:34 see happening all the time and it drives me crazy. I hear from many people that they are starting preparation for a new job. They tell me I'll study for another 3 months and then start applying outside for a job. But I don't understand this logic. The same job and the same skills they've been working with for the last 5 years. Why do they need three more months of preparation? Just go ahead and apply. Worst case scenario, you won't get the call. But guess what? Not applying will also not get you a call either. At least by applying, you have a chance. Let me share a personal example. When I joined Impetus, all I knew was terod data. I was no expert in Hive, Spark or even cloud era distribution of

2:20 onremises Hadoop. I was self-taught with no professional experience in big data technologies. But I applied for the job anyway and got the role as a lead. How? Because during the interview, I was honest about what I knew and confident about my abilities. And guess what happened? I learned those technologies during the job. In the next full year, I got promoted to an architecture role. Here's what companies really want. They write wish list, not requirements. They want Superman, but they'll hire Clark Kint if he can solve their problems and learn quickly. The real question is not do I know everything. It is can I learn what I

3:05 don't know? And if you are watching this channel, if you've been working in tech for any amount of time, the answer is absolutely yes. So stop disqualifying yourself before you even try. Let them tell you no. Don't do it for them. Let's move to the next point. Master the art of learning, not just tools. Now the second game changanger for me was I learn how to learn, not just what to learn. So in our data engineering field, new tools mop up constantly. Yesterday it was Hadoop, today it's snowflake ldbt. Tomorrow it will be something completely different. You simply cannot learn every single tool that exist. But here's what never changes the fundamentals and the process of learning

3:50 itself. Let me give you some real example from my career. I have participated in many migration projects where I mostly knew only one side of the migration. For example, terod data to spark migration. I knew only terod data at that time. Informatica to AWS glue migration. I knew only Informatica at that time. But I still exhibited confidence and learned the missing half on the job. How? Because I had learned the process of learning rather than just learning specific tools. When I understand ETL concepts deeply through Informatica, I could apply those same concepts to AWS Glue. The tool changed but the underlying principles remained the same. When I knew how data warehousing worked in terata, I could adopt that knowledge to understand how

4:36 Spark handled similar challenges. Here is another example. When I joined AWS in 2020, my very first month in the company, I was completely overwhelmed. I clicked on all the services in the AWS console and immediately got terrified by the massive list of services. There were hundreds of them. But then I calmed myself down and realized something important. I don't need to learn all the services at once. I learned one service at a time, understanding how it fit into the bigger picture and I did pretty well because I focused on understanding the core concepts behind each service rather than just memorizing the features. If you understand databases fundamentally, you can learn any database whether it's

5:22 posgress SQL, MySQL or even Dynamob. If you understand ETL concepts, you can adapt to any ETL tool, the AWS glue or whatever comes next. So focus on the why behind the how. When you understand why we normalize data, you can apply that principle anywhere. When you understand why we need data pipelines, you can build them with any tool. So strong fundamentals make you adaptable and in technology adaptability is your ultimate superpower. Let's move to the next point. Perfection is your career killer. Heard myth that absolutely killing careers. I need to be perfect at this before I can move forward. Perfectionism is not a virtue in tech. It's a trap.

6:09 While you are polishing your Python skills, for the hundth time, someone else with good enough Python skills just got promoted. Why? Because they also understand Docker. They knew cloud architecture. They can set up CI/CD pipelines and can communicate technical concept to business stakeholders. The job market doesn't reward narrow specialist anymore. It rewards versatile problem solvers. Be the person who can write decent code, understand business requirements, architect solutions, and explain complex technical concepts to non-technical people. I used to spend months trying to master one technology completely before moving to the next. Now I aim for professionally competent and move on. You can always deepen your

6:56 knowledge later when you actually need it. But you can't get back the opportunities you missed while pursuing perfection and explain complex technical concepts to non-technical people. Here's the reality. Most of the time, you don't need to be the world's best expert in a tool. You need to be good enough to solve the problem at hand and confident enough to learn more when a situation demands it. Done is better than perfect. Professional quality beats perfect quality. Your career will advance based on the value you deliver, not the elegance of your code. Let's move to the next point. You will never feel ready. Still take the action. Fourth point that changed everything for me. You will never feel

7:43 ready and that's completely okay. I turned down interview opportunities for years because I thought I'm not ready yet. I was waiting for that magical moment when I would feel confident about everything in the job description. That moment never came. And here is why confidence doesn't come before competence. It comes after you build confidence by doing things you are not sure you can do. Let me share a story from my early days. When I joined Accenture as a fresher, I was not sure if I would get my first promotion. Why? Because I was on the bench for a couple of months after my training. then got rolled off from my very first project in just 4 months and then joined a project in a different city with totally different tools and skills that didn't

8:30 even match my trainings or previous learning. I was terrified. I felt completely unprepared. But guess what happened? I got backtoback promotions in two years. I got promoted twice. And all this happened because of my clear and confident communication with the senior managers in my team. Even though I didn't know everything, I was proactive in raising my concerns and highlighting gaps in business delivery. I found it okay to challenge seniors in my team on technical grounds when I thought there was a better approach. I took ownership of problems even when I was not 100% sure of the solutions. Here's what I learned. Every senior engineer, every architect, every tech lead has the same

9:17 story. They got promoted or landed their dream job while feeling like they were in over their head. The difference is they went for it anyway. Imposter syndrome is for real. But it's also a liar. It tells you everyone else knows more than you do. But the truth is everyone is figuring out as they go. The people who advances are the ones who are comfortable being uncomfortable. So stop waiting to feel ready. Start getting ready by doing. Apply for that stretcher role. Take on that challenging project. Volunteer for that migration you have never done before. The confidence will catch up and I promise. Let's move to the next point. Problem solving and communication trumps everything. Fifth

10:04 game changer that most people completely miss. Technical skills get you in the door, but the problem solving skills and communication get you promoted. I used to think being a great engineer meant writing the most elegant code or knowing the most advanced algorithms. But as I progressed in my career, I realized something crucial. Nobody cares how clever your code is if it doesn't solve the right problem. The engineers who advance fastest are not necessarily the best coders. They are the best problem solvers and communicators. They ask the right questions. What business problem are we actually solving here? Is this the most efficient approach? How will this scale? What could go wrong? How do we measure success? Let me give you a

10:52 real example from my Accenture days. I was not the most technically skilled person on my team. But I was the one who could translate between the technical team and the business stakeholders. When there were issues, I could explain what went wrong in terms that non-technical managers could understand. When business requirements changed, I could assess the technical impact quickly. This skill became incredibly valuable. During project meetings, I would proactively raise concerns about potential delivery issues. If I saw gaps in the business requirement, I would highlight them before they become bigger problems. If I thought there was a technical approach that could save time or resources, I would challenge the current approach, even if it meant disagreeing with senior team members. This was not about showing

11:38 off technical knowledge. This was about demonstrating business acumen, leadership thinking and communication skills. And that's what got me those backto-back promotions. Here is what I want you to understand. Technical skills are table stakes. Everyone applying for the same role has same technical skills. What differentiate you is your ability to think beyond the code to understand the bigger picture to communicate effectively and to take ownership of outcomes. Start developing these meta skills. Now when your manager assigns a task, don't just execute. Understand the why. Propose alternatives when you see them. Think about edge cases and failure scenarios. Communicate your approach clearly. Take ownership of the

12:25 end-to-end solution, not just your piece of code. These are the skills that make you irreplaceable and promotable. Let's move to the next point. Nobody cares about your code as much as you do. Here's a hard truth that took me years to accept. Nobody cares about your code as much as you do. I used to stress about every line of code, every function name, every comment. I thought my code was a direct reflection of my worth as a developer. I would spend extra hours making sure everything was perfect even when the deadlines were tight. But here is the reality. Most code is temporary. That beautiful function you spent hours perfecting, it might get replaced in the

13:10 next sprint when requirements change. That architectural design you agonized over, business priority shifted and now it's completely irrelevant. So don't get me wrong here. Good code does matter. But clean, maintainable code is important. It's a mean to an end, not the end itself. Your value is not in writing perfect code. It is in delivering the solutions that move the business forward. Most companies care about the business values your work brings. Not whether you use the latest design patterns or wrote the most elegant algorithm. They care about does it work? Is it reliable? Can it be maintained? Does it solve the business problems? Can it scale when needed?

13:55 Write clean, maintainable code, but don't let perfectionism paralyze you. Focus on delivering the results. Communicate clearly with your team. Collaborate effectively. Understand the why behind what you are building. Your career will be judged on the problems you solve and the value you create, not the elegance of your individual code files. If you are following me till now, let's move to the next point. Burnout is real and it can be career ending. Last but not the least, I want to talk about a very critical point. Burnout is not a badge of honor. It's a career killer and it's completely preventable. In my early years, I wore exhaustion like a medal.

14:41 working weekends, pulling all nighters, always being on and available. I thought this is what separates me from average performers. I thought this is what it took to succeed in tech. I was completely wrong. Burnout didn't make me more productive. It made me less creative, more prone to mistakes, harder to work with, and honestly, it nearly derailed my career entirely. Here is what I learned. Sustainable careers are not built on sprints. They are built on consistency. The tortoise really does beat the rabbit in the long run. Grinding 14-hour days is not sustainable. You might be able to do it for few days, few weeks or even a few

15:27 months, but you cannot build a 15 20 year career on that foundation. Eventually, your body and mind will give out and you will either burn out completely or make critical mistakes that damage your reputation. Consistent, steady progress beats burning yourself out every single time. The most successful people I know in tech have learned to manage their energy like a precious resource. Set boundaries. Take your vacation days. All of them. Learn to say no to non-essential request. Invest in your physical and mental health. Maintain hobbies and relationship outside of the work. You are not a machine. You are a human being with limited energy and attention. Manage that energy wisely.

16:14 Protect your mental health and you will have a long successful fulfilling career. This is especially important in our field because technology careers can span decades. you want to still be learning, growing, and contributing 20 years from now. That only happens if you take care of yourself along the way. So, these are the points I want to cover. Let's do a final recap. Let me wrap this up with a key takeaways from 17 plus years in the trenches. First, apply when you are 60% qualified. Don't wait for that perfect preparation. I got some of my best roles knowing only half the required technologies. Second, master the process of learning itself, not just individual tools. Understanding core concepts make you

17:00 adaptable to any technology. Third, aim for professionally competent across multiple skills rather than perfection in one. Versality beats narrow expertise. Fourth, take action before you feel ready. Confidence follows competence, not the other way around. My biggest career jumps happened when I felt least prepared. Fifth, develop problem solving and communication skills alongside technical abilities. This is especially important in our field because technology careers can span decades. You want to still be learning, growing, and contributing 20 years from now. That only happens if you take care of yourself. These are what actually get you promoted. Sixth, your code serves

17:48 the business, not the other way around. Focus on delivering value, not the perfect syntax. And seventh, sustainable success requires sustainable habits. Protect your energy and mental health for the long game. If I could go back 17 years and tell my fresher self these things, I would have avoided years of self-doubt, missed opportunities, and unnecessary stress. Don't make the same mistakes I did. Your career is not just about what you know. It's about how you think, how you adapt, how you communicate, and how you add value to every team you join. You are more ready than you think you are. Stop waiting and start doing. If this resonated with you, smash that like button, subscribe for more career insights alongside our usual

18:36 technical deep dives. Drop a comment below. What's the biggest career lesson you have learned the hard way? I read every single comment. So until next time, keep building, keep learning, and remember, your next big opportunity is probably closer than you