Journey

What Happened

The announcement came during an all-hands meeting. Our largest client had decided to switch development partners, and as a result, our entire division over 400 developers was being let go. It wasn’t about performance or budget cuts; it was simply business redirection.

I had been with the company for four years, working on critical projects. The layoff was effective immediately, with severance packages and outplacement services offered. But the reality hit hard: in an instant, my stable corporate job evaporated.

The Aftermath

The first few weeks were a blur of job applications, networking calls, and resume polishing. The market was competitive, and many of my colleagues were in the same boat. I attended countless interviews, but we could not agree mutually on terms.

After two-three months of fruitless searching, I started reaching out to my professional network. Old colleagues, former clients, and industry contacts became my lifeline. I offered consulting services on a freelance basis—small projects, code reviews, technical advice.

What started as survival work quickly became something more. The freedom of setting my own rates, choosing my projects, and working from anywhere was intoxicating. I realized I had been undervaluing my skills in the corporate structure.

How It Changed Me

This forced career pivot fundamentally transformed how I view professional security:

Corporate employment is temporary. No matter how stable a job seems, external factors can change everything overnight. Building personal resilience became my priority.

Networking is your safety net. The relationships I maintained during my corporate years became my lifeline. Never underestimate the power of genuine professional connections.

Self-dependence is empowering. Freelancing gave me control over my career trajectory. I could choose projects that excited me, work with clients who valued my expertise, and build wealth on my own terms.

Continuous learning is non-negotiable. Without a corporate structure, I had to stay ahead of technology trends myself. This made me a more proactive and adaptable engineer.

The layoff was terrifying, but I’m grateful for the push. Freelancing has given me professional freedom I never imagined, and I’ve built a sustainable career that can’t be taken away by a single client decision.

The Challenge

The transition was harder than I expected. I was used to being valued for my code output, but as a lead, my impact comes from:

• Making good architectural decisions
• Unblocking team members
• Reviewing code and providing feedback
• Communicating with stakeholders
• Planning and prioritizing work

Key Learnings

Write Less Code: My job is to enable the team to write great code, not to write all the code myself. This was a hard mental shift.

Document Decisions: Architecture decisions need to be documented and communicated clearly. I started writing ADRs (Architecture Decision Records) for major decisions.

Invest in People: Spending time mentoring junior engineers has a multiplier effect. Their growth is my growth.

Say No: Protecting the team from scope creep and unrealistic deadlines is part of the job.

Learning from this experience

• Balancing technical work with leadership responsibilities is a continuous learning process.
• Giving constructive feedback effectively is an art that requires practice and empathy.
• Navigating organizational politics is an inevitable part of leadership, and it requires emotional intelligence and diplomacy.
• Advocating for the team’s needs is crucial for their success and morale.

Leadership is a continuous learning journey, not a destination.

The Signs I Ignored

Looking back, the signs were obvious:

• Dreading work I used to enjoy
• Constant exhaustion despite sleeping
• Cynicism about projects and people
• Difficulty concentrating
• Physical symptoms (headaches, tension)

I kept pushing through, thinking it would pass. It didn’t.

The Breaking Point

I made a significant error in a code review—something I would have caught easily before. That’s when I realized something was seriously wrong.

Recovery

Recovery wasn’t quick or linear:

I took time off. Actually disconnected, not “working from vacation.”

I set boundaries. No more late nights as the default. Sustainable pace became non-negotiable.

I said no more often. Not every opportunity needs to be seized. Some need to be declined.

I rediscovered hobbies. Coding stopped being my only identity.

What I Tell Others

Burnout isn’t a badge of honor. It’s a signal that something is broken—in the environment, the expectations, or the boundaries.

Sustainable careers are marathons, not sprints. I’m still learning to pace myself, but I’m much better at recognizing the warning signs now.

The Need for Change

After working as a web designer for a couple of years, I decided to switch my role and company to gain new experiences. The work I was doing became monotonous, and I felt the need for a change. Fortunately, I got an opportunity to work as a front-end developer using Angular. It became the main turning point of my career.

The Assignment

The company was building a full blown saas product for our client, but client was not satisfied with current UI that was built. As our client was the product designer and product owner by himself, he decided to take the matters in his own hands. He designed the screens himself with pixel perfect accuracy and great color combinations. He then tasked me and two other team members to implement this design.

Harvesting the Benefits

I got great appreciation for completing this feat from our client and the management. And the juniors I mentored also got selected for other projects in the company. This was a great boost to my confidence and motivation.

Learning from this experience

• Refactorization is a lot more difficult than writing new code from scratch.
• Building something from scratch can give you a new perspective.
• Angular was difficult to learn but even more difficult to work with.
• Working alongside a product designer can give you an insight you can never think of.
• Positive motivation with a little bit of confidence boost can do wonders.

This experience was great stepping stone for my career and I am always grateful for it.

Why I Started

I remembered how lost I felt as a junior engineer. Good mentors accelerated my growth tremendously, and I wanted to pay it forward.

What I Learned About Teaching

Explaining reveals gaps. When I couldn’t explain something clearly, it meant I didn’t understand it well enough myself.

Everyone learns differently. Some people need to see code, others need diagrams, others need to talk through problems verbally.

Ask, don’t tell. Guiding someone to discover the answer themselves is more effective than just giving them the solution.

Celebrate small wins. Progress isn’t always visible day-to-day, but looking back over months shows tremendous growth.

The Multiplier Effect

One of my mentees is now mentoring others. Seeing the knowledge and practices spread through the organization has been incredibly fulfilling.

Mentoring isn’t just about helping others—it’s made me a better engineer and communicator too.

Learning from Mentoring

• Teaching is also a great way to learn and understand concepts more deeply.
• Patience and empathy are crucial when mentoring, as everyone has different learning styles and paces.
• Never underestimate the flow of knowledge as it can come from your juniors as well.
• Mentoring can change your perception about your oen knowledge and skills.

What Happened

I added a global utility class to improve spacing consistency across the site. It was a simple change—just adding some padding and margin rules to handle responsive layouts.

The styles looked right on my system. They passed our design review. The pull request got approved.

In production, on tablets and older browsers, the utility class inadvertently overrode nested component styles, breaking layouts across 20+ pages and causing a cascading layout shift that made the site nearly unusable on mobile devices.

The Aftermath

The debugging session revealed several architectural problems:

• We had no isolation between global styles and component styles
• CSS specificity was a constant battle with no clear hierarchy
• We weren’t testing across different screen sizes and browsers
• Our component styles assumed a specific DOM structure that wasn’t enforced
• Mobile testing was an afterthought, not part of the review process

How It Changed Me

This incident fundamentally changed how I approach frontend architecture:

I design for constraint and isolation. Global styles are dangerous. Component styles should be self-contained.

I test across browsers and devices. What works in Chrome tells you almost nothing. Safari, Firefox, and mobile devices often reveal problems you never see in development.

I think about CSS specificity as a feature. Utility classes are powerful, but they need clear scoping and documentation to avoid battles with component styles.

I make cross-browser and mobile testing non-negotiable. Responsive design isn’t something you bolt on at the end—it’s fundamental.

The incident was embarrassing, but I’m grateful for the lessons. I’ve prevented similar cascading style issues many times since by applying what I learned that day.

The Ask

In this role, I was initially responsible for designing and developing the front-end of the company’s website and web applications. When the team became confident in my abilities, I was introduced to our offshore clients and partners. This becam a huge turn in my career. From designing simple websites, I started working with real complex Dashboards and CMSs for the clients. I understood what the pixel perfect design meant and how to achieve it.

I worked with the clients from the US, UK, Canada, Dubai, Egypt and some Indian clients as well. This introduced me to the significant cultural and communication differences that exist in the global industires. It made my communication skills way better than before.

I got many recognition, rewards and appreciation for my work from the clients and the management. This was a great boost to my confidence and motivation.

Learning from this role

• The importance of communication and collaboration in a team environment.
• Cultural and communication differences are real.
• Client interactions are a great learning experience. But sometimes, their expectations can be unrealistic and scary.
• The need to constantly learn and adapt to new technologies and trends.
• Rewards and recognition can become solid motivation factors.

What I Learned

This was a humbling experience. My code worked perfectly in development, but production revealed issues I hadn’t considered:

• Load time under real user traffic
• Design flaws that only became apparent with real users
• Device and browser compatibility issues
• Many CSS libraries can become a nightmare in production

The first production incident (a design mismatch due to multiple CSS files) was stressful but taught me more than months of tutorials ever could.

What I Did

I was first tasked to create an in-house website using html, css, javascript and jquery. Later, it was developed into a full fledged CMS using .Net and SQL Server by the team. I was responsible for maintaining the website and adding new features as needed. I also had to deal with browser compatibility issues and ensure that the website worked well on all major browsers.

When I got some experience and confidence, I was given the opportunity to work on the client’s projects using Wordpress. I had to create custom themes in html, css and modify existing designs to meet the client’s requirements. I also had to troubleshoot and fix any issues that arose with the website on different browsers.

This was a great learning experience for me as I got to work on a real project and see the impact of my work on the business. It also taught me the importance of writing clean and maintainable code, as well as the need to constantly learn and adapt to new technologies in the ever-evolving field of software development.

This was an invaluable experience. It taught me that real-world applications are complex and require a deep understanding of both the technology stack and the business requirements.

This experience gave me something that I became the foundation of my career:

• Listening and understanding the requirements are two different things.
• Properly running code on local machine is not the same as running it in production.
• Internet explorer was my real frenemy. I had to learn all the browser hacks to make my code work on it.
• Tutorials don’t prepare you for the real world.
• Tweaking & modifying existing code teaches you more than writing new code from scratch.

This first job was the real seed of my knowledge and experience that started to grow and flourish with the flow of time.