I started my career in IT in 2015 in a service-based software company in Bangalore, India, and in 2019, I was hired as a Tech Lead for one of the most aggressive start-ups in Dublin, Ireland. I did a few things right that led me to this position and I also made a lot of mistakes. In this article, I want to share my experience through this career progression, hoping it will help some of you on a similar path.
I have structured this article listing the job roles I was in - what I did right and what mistakes I made. Feel free to jump to the section relevant to you 🙂
Contents
Associate Software Engineer to Software Engineer (2015 to 2017)
Image by Paolo Nicolello on Unsplash
This was my first job in tech and thus the foundation of the rest of my career. I was hired as a backend developer to work on a Spring-based application wherein my focus was to build RESTful APIs. Before starting this job, I was a newbie with just about skilled enough to build core Java applications with MySQL, and some basic HTML, CSS, and JS. These are the things I learned to be able to land my first job.
At this point, there was no way I could have built a full-fledged application independently. I did not know what APIs were, let alone REST or SOAP or any of that. To give you some perspective, I was building command-line Java applications to perform CRUD operations and building simple frontend stuff like an expanding card.
However, I was good with problem-solving. I was spending half my day solving HackerRank problems, reading other people's solutions and the rationale behind them, and working on learning the fundamentals. I was also good with data structure and algorithms, as well as core Java concepts like memory management, garbage collection, etc.
So when I started my job, I was trained on the job for two full weeks covering MySQL, Spring, Hibernate, REST, Maven, and Shell scripting. As you can imagine, this was overwhelming and the training touched upon each of the topics. To be fair, it was a good starting point to help me understand the basics of software development and the tools involved. However, this meant that I was now expected to start working on a project. This was intimidating. But the leads on the project were extremely helpful and approachable.
Soon after, one of the leads had to leave the project and we were expected to run with the project ourselves with very little guidance. This is where things got interesting. I started learning more and helping my colleagues. I started working late hours trying to learn the basics of the technologies involved in the project. First, it took me quite some time to explore the different ways of learning and realizing what worked best for me. I started with reading docs, then I tried watching videos, and I also tried interactive tutorials. After several tries, I accepted that first reading the docs (a couple of times) and then coding alongside was the best way for me to learn anything new.
However, the most overwhelming part was not learning, but implementation. Everything seemed to be too big a problem to solve. I knew I had to figure out a way around this. I approached one of the leads and asked her for advice. She was kind enough to sit down and take an example of what I was trying to do and break it down for me. She explained how important it is to break things down and try to solve smaller problems. While this is a simple idea, it is not something I had thought of. Mostly because I was naive and under a lot of pressure to "prove" my skills.
Soon, things started to change. I had figured out the best way for me to learn something new and how to approach a problem. I was pretty good at problem-solving already so now I was able to put it all together and things finally made sense. My tests were passing. My PRs were being approved sooner than usual. There were some more changes in the team and now we had a part-time lead on the team and 4 junior developers including myself. I was given more responsibilities and I was just about able to cope with it. I was still working crazy hours and also suffering from 'Imposter Syndrome'. I did not trust my skills. A simple null pointer exception was enough to throw me off. One of the primary reasons for this was I was trying to move too fast. I was trying to learn something every day. Weekends were no different. I wanted to learn everything. This was clearly a bad decision and I was paving my path to burnout.
However, let's focus on the positives first. I was 4 months into the job and a new opportunity came up. I was expected to travel to Ireland to take over a new project from the company's then clients. I was excited but also extremely nervous. I did not think I was ready. My manager and the lead thought differently though. They trusted my skills more than I did and they believed I was capable of representing the company. I traveled to Ireland for about two weeks and that venture went extremely well. This was a huge reinforcement for my then-paper-thin confidence. It made me realize I was doing something right. My process of learning and problem solving was working well for me. I continued working ridiculous hours but then I noticed something seemed to have stopped working. I was not able to pick new things as easily anymore. My code had some obvious bugs. But the worst part was I was no longer excited about what I was doing. I realized I had overdone it. I was burned out.
Fortunately, I had some holidays coming up which I had booked well in advance for a family trip. In the meantime, I decided to slow down. Go back home after work instead of staying back and learning something new. Spend more time hanging out with my friends. Resume some workouts. Do some recreational activities. But most importantly, not spend every waking hour trying to learn something or working. I went on holidays and completely disconnected from work. When I returned, I felt much better. I was happy to resume work. I eased into it though. This time, I had set small achievable goals that I could review every few weeks. I added time to my calendar to do something recreational at least once a week. Basically, I planned a better work-life balance. Around 8 months later, I was asked to travel to Ireland again to support a project that was being deployed to production soon. We had been working on this project for almost a year.
This time, I was more confident than the last time. I was working with the client tech lead on the project while the project was going through BAT phase. A good few changes came out of this phase but my team and I were able to work through it. We successfully delivered what was one of the most complex and crucial projects in the client's portfolio. My managers back in India could see the effort I was putting on and decided to promote me to the Software Engineer role. Overall, this was a great learning experience for me. In the meantime, I had also started networking and meeting new people from the local Irish dev community.
I continued working at the same company for another year and things were going really well. Maybe even too well. Then I decided to quit my job and pursue Data Engineering. More about that in the next section. First, let's take a look at the mistakes I made and the things I did right during this 2-year tenure.
Mistakes I made
Urgency to learn everything - I felt this sense of urgency to learn everything right away and have seen other fellow engineers feel too. The problem here is that we are extremely goal-oriented and miss out on the fun of learning something new. As developers, we sign up for a lifetime of learning. Once we start rushing through it, it soon starts to feel like a job we have to do and less fun.
Overworking to prove your skills - As a beginner, I assumed that I had to prove my capabilities by successfully* delivering everything that was assigned to me. Soon I was burned out. I was not proving anything to anyone. Things would have worked out whether or not I worked 18 hours a day for a few months. If anything we would have had to push the deadlines by a week or two. But that's not the end of the world. Prioritizing a good work-life balance from the very beginning is absolutely necessary. There is no "once I am done with this project, I am going to take it easy". That's a lie. You get used to overworking and normalize it as your regular way of working.
Lack of self-awareness - Learning to learn is an important skill for all of us as engineers. Tech evolves pretty quickly and we are expected to upskill at the same pace. To deal with that, the sooner you realize the best way for you to learn something new - watching videos, reading blogs, reading docs, interactive code tutorials, etc. the better it is.
Not asking for help - There were several instances where I was skeptical about asking for help. I was under the impression that asking questions/for help would make me look like an idiot. Guess what? Not asking questions and doing things my way proved I was an idiot. Some of my PRs had glaring logical mistakes. Only because I did not want to ask questions. Some days I spent hours debugging something that I was completely oblivious to again because I did not want to ask for help. On the other hand, when I did ask for help, I ended up with not just a solution but also got clarity on some more fundamentals I was missing. I've always learned more when I have asked questions. Don't be afraid to ask about whatever you are not sure of.
Things that I did right
Spending time learning the fundamentals - I cannot emphasize enough how helpful this has been to date. Whenever you pick a new language/framework, the one thing that does not change is the fundamentals. What do I mean by fundamentals? Basics of object-oriented programming, data structures, algorithms, libraries and how to use them, testing and its importance, etc. You get the idea. All of these are language agnostic concepts and can be applied to most languages and frameworks (except you cannot apply the basics of object-oriented programming to non-OOP languages). Spend time on your fundamentals and they will pay off in the longer term.
Take your chances - Whenever a new opportunity was handed to me, I took it up. I was nervous almost every time I decided to step up but it was the best way to learn new things - not just coding, but other facets involved in building an application like deployments, architecture, team/resource management, etc. Also, new opportunities help you improve your non-technical skills and develop your personality. You learn how to be a better communicator which is extremely important. You also learn how to handle bigger responsibilities as well as how to be an effective team member. Often new opportunities expose you to a new group set of people which can be a great learning experience. I have learned a lot more from people I've worked with than I have from tutorials and docs.
Discipline - This is pretty much self-explanatory but to give you a brief idea, when things slowed down a bit, I realized the only way to stay on track and continue upskilling without burning myself out was to be a bit more organized. I decided what I wanted to learn next and created an agenda. In fact, I added this agenda to my calendar and followed it through. I slacked every now and then. So I added a "review" time to check in and see where I was with my plans. Every time I found myself getting sidetracked, I assessed what went wrong and re-planned. I did this every 2-3 weeks. If this process sounds familiar, you are right. I basically followed a sprint review process. 🙂
Data Engineer (2017 to 2018)
Image by Jared Rice on Unsplash
Things were going well in my last job and I got pretty comfortable. However, the comfort was a bit unsettling for me. I started feeling I had slowed down. So I decided to try something new. I decided to pick up Data Engineering. I prepared just enough to land a position and then hoped to learn further on the job. That plan went as expected. I was hired as a Data Engineer where I was building data pipelines. I had to upskill and I got into the "prove" my skills mindset again. I didn't mind it as much since I was working with some of the best engineers who ended up becoming my closest friends.
I was mainly working with a lot of Python and Scala. There was no more Java, Spring, and Angular. I was no longer building APIs or web apps. This was a total change of mindset for me. If my code worked well, I could not see it as JSON response or a pretty website. My outputs were now seen as CSV files. However, I got a lot more exposure to AWS. Especially, the services I was not already familiar with like RedShift, EMR, Glue, etc. Overall, I did not hate the experience. But I did not love it either. I realized this was not what I was not looking for. I was not happy with what I was doing overall. I could have continued doing it anyway because it was a well-paying job and I was offered a lot more money to stay. But I decided to leave.
I stayed in that job for 8 months. I learned a lot. A lot of new technologies. But most importantly, I learned what I was actually interested in - building full-stack applications. Anyway, let's jump to my key takeaways from this experience.
Mistakes I made
You don't need to make a career out of a hobby - I picked up data engineering as something I wanted to learn and explore. It could have remained a hobby or a side project. I jumped the gun and decided to take it up as a career choice. It was a mistake. I should have researched more about what I was getting into and definitely explored it as a side project before deciding to take up a full-time job in it.
Not discovering my niche - I'd be lying if I said I did not take my first job for granted. Not only did I good at it, but I was also enjoying it. While it's debatable, I think I could have discovered my niche earlier i.e. while I was on the job doing what I liked. The main reason I wanted to mention this was to emphasize how important it is to do what you like and not fall for the "trend". I picked up Data Engineering as it was the cool thing to do at the time and I assumed I would like it too. I was wrong. 🙂
Things I did right
Try what intrigues you - If there is a tech out there that intrigues you, try it out. Read the docs, build a mini project, study how it works. Don't be afraid of trying something new. It's just tech - worst case, you have some broken code. Best case, you discover something fascinating. Also, discovering new tech helps you understand the ecosystem of applications better. I'll explain more about how this job helped me in my next job so you can relate to it 😎
Accept your mistakes and move on - When I realized I was not happy doing what I was doing, I decided I had to leave. There was no way for me to lie to myself and continue doing what I was doing. So I quit. This is not an example for jobs alone, there are times when you start with a project and mid-way through it you realize there is a fundamental mistake with your approach. Don't be afraid of redoing things and correcting that mistake. Being stubborn in such cases does not help anyone. Doing the right thing is always liberating.
Senior Software Engineer (2018-2019)
Image by Jamie Street on Unsplash
While I was in my last job and realized I needed to leave, I reached out to my manager from the previous company and asked him how things were and if they were looking to hire more people. He got that I was not happy and looking to change my job again. Fortunately, the timing worked out well for me. The client I was working for during my first stint at this company was looking for an onsite engineer. They had worked with me in the past and thought I was a perfect fit for them. The manager explained what the role was and all the other details. I was on board and decided to join them again.
It was a bit awkward at the start to go back to the same company after just 8 months. But I got used to it after a few weeks. Mostly because my colleagues were awesome and warm towards me. And also because I had accepted that a job is a job. If I bring my pride into it, it becomes unhealthy.
Anyway, the client I had to join in Ireland got acquired by another company and the role was cut. In fact, their contract with the company I was working with was terminated as they had decided to have an in-house engineering team and no longer outsource. Oh well. 🤷♂️
I was then assigned to other teams for some related work. I was also asked to upskill on some Oracle products for a project I was going to be assigned to. I did but I was not happy about it. I had come a full circle again to doing something I was not enjoying. I conveyed that to my managers and they were understanding. I was assigned to a different project where I was working directly with the Solution Architect to architect a solution for a potential client. This was a great experience. He mentored me and helped me understand the rationale behind the decisions he was making while architecting the solution. This was probably one of those experiences that changed my career majorly. I had a better understanding of end-to-end solution architectures. I had previously looked at say a three/four tier application and not beyond that. This experience helped me see beyond the 4 tiers and understand large-scale applications better.
Soon after, I was brought in to do Solution Architecture myself for another Irish client. I was assigned to a team of some senior tech leads and architects. I was probably the least qualified to be on that team. Or at least I thought so. However, I had domain expertise in what we were architecting. There was another thing that I was brought in for - my recent experience in data engineering. One of the key requirements for this solution was designing a data pipeline, something I had done in the past. We continued working on that solution architecture for the next three months and I was now more confident in designing solutions now than ever before.
I was also invited to visit Ireland and give a presentation on the overall solution architecture. I was confident since I was heavily involved in designing that solution. The presentation went well. Next, I was back home and now I was working with a group of junior developers on a different project. These developers were reporting directly to me and I was assigned to work on a project with the stack I was comfortable with - Java, Springboot, Angular. In the meantime, I was also working on an internal mobile app using Flutter (v0.8 😅) and a React-based project.
Soon after, one of the clients from Ireland again was looking for an on-site tech lead with experience in Springboot, React, and AWS. And guess who had this experience at the time? Correct, I did. So I volunteered for that role and submitted my resume. I was interviewed and shortlisted for the role. 🤯
Mistakes I made
Starting too many things and finishing nothing - I was not in a rush to learn this time. But I was only doing whatever was necessary for me to be able to do my job and dropping it there. For instance, I picked up Flutter and React, did what I had to, and dropped them there. I was jumping between too many things and not finishing one thing before starting the next. Now, I kinda know Flutter and I am alright with React. I had the time to learn them both well but I was being lazy.
Sticking to my comfort zone - I was on the other end of this problem earlier. I was trying to stay out of my comfort zone and get better by the day. Now, I was resting in my comfort zone. I was happy with Java, Springboot, and Angular. I decided this is going to be my stack. However, the one thing about tech is that it is constantly evolving. Being stubborn about your stack does not help you progress in your career. It was not helping me either. Your stack should be what solves your problem, not what you are just comfortable with.
Things I did right
- Broadening my horizon - I actively chose projects that helped me broaden my horizon. Projects that dealt with things I had not done in the past. While this contradicts my previous point of sticking in my comfort zone, I want to highlight that as a "Senior Software Engineer" there was an expectation of me to write good quality code in any language I pick (figuratively) whereas there was very little expectation of me to design great quality architectures. This is what I mean by being in my comfort zone with my tech choices to ensure that I am consistently good at it.
Tech Lead (2019 to date)
Image by alan King on Unsplash
Moving to a tech lead role as a software engineer is by far the most exciting (and scary) thing I've done in my career. I'll explain to you why. Imagine writing code and raising a PR and if something is not logically right, someone will point it out and correct you. Now, before I realized it, I was that someone. And this was the easiest part of the job. The more difficult parts of the job were choosing the tech, evaluating libraries/frameworks/languages/services for a project, finding and filling gaps in a solution, mentoring other engineers, etc.
For some context, let me give you a brief insight about what my job as tech lead was when I started - low-level design of the entire project, security reviews, microservice design, agreeing upon the design pattern the team will be following, doing reference implementation, building reusable libraries, high-level estimation for projects, etc. This list only got longer as time passed.
For anyone senior software engineers looking to take up tech lead as their next role, this next section might help you:
Suggestion for Senior Engineers
Understand end to end software architecture - One of the key things that a lead is expected to know is how the application hangs together end to end i.e. starting from the frontend, patterns used on the frontend (client-side MVC, server-side rendering, etc.), backend, design patterns, databases (SQL, NoSQL), to the architectural patterns (monoliths, microservices, serverless, etc.), security protocols across different integration points, etc.
Recognise your team's strengths and weaknesses - Often some members of the team are great at something and not so good at others. A lot of the time it'd be up to you how the tasks are divided among your team. Learn the strengths and weaknesses of your team members and this will help you with assigning the right task to the right person. To add to it, as a lead, you are expected to mentor your team members. It is essential to understand your team members before you start mentoring them. There is no secret on how you learn about your team members - you just talk to them. You ask them questions about their interests, strengths, and weaknesses. Treat them the way you expect to be treated - like mature adults.
Be ready to make difficult decisions - There are times you will be asked to make a difficult decision. Not what tech to use. That's the easier decision in the scheme of things. But decisions like who do you want on the team and who do you want to let go. Remember that this is a part of the job. There is no getting away from this and the best way to deal with this, IMO, is to remember there is nothing personal at work. You don't pick or drop team members based on how close you are to them or who do you get on well with. It is purely based on skills. It is important to remember this and look at it objectively. Always. And be professional about it.
Be an effective communicator - A major part of the job is interfacing with stakeholders as well as your team. Being an effective communicator here makes everyone's (especially your own) job easy. Learn to convey information in a clear and concise way.
Stay up to date - Since you are expected to make important tech decisions, it is extremely important to stay up to date with what is going on out there. What new tech is available to solve a previously unsolved problem, what new practices are being adopted, what tools would make your team more productive, etc. There are several ways to do this and I personally recommend reading blogs, subscribing to newsletters like Technology Radar from Thoughtworks (I've personally been following this for the last 3 years), interacting with more developers, and learning from other people's experiences.
But most importantly,
via GIPHY
That was my journey and my experiences through it. If you are on a similar path and think there is something I can help you with to make your journey easier, please feel free to comment here or connect with me on Twitter. Good luck 🙌
