Why you are not growing as a software engineer
I have been programming for well over two decades now. I got my first "real" job as a software engineer back in 2012. But personally, I feel like my true career only started in 2015. Because before that, I wasn't growing as a software engineer. It's not that I wasn't putting in the effort -- I was. I showed up to work every day with my best self, and did everything that was asked of me. And, my performance numbers were also always better than average. But in spite of all that, I was just as at the entry level position of Software Engineer I. I never got promoted, not even once. Until 2015. That's when I finally figured out why I wasn't growing and worked hard on fixing them. And in just two years, from 2015 to 2017, I went from Software Engineer I to Senior Software Engineer, which at my company, is a total of 4 promotions.
If you relate to the first part of this story where you are doing everything you can, yet you feel lost and stuck, it could be directly related to your lack of growth. And here are 5 reasons why you are not growing as a software engineer.
Reason number 1 - You don't have a mentor
My mentor and my manager had the biggest impact on the rapid acceleration of my career growth during, and ever since those few years. You mentor and your manager could be two different people, or just the same person. See, anyone eager and willing can put in the effort to learn something new when they know exactly what it is that they have to learn. But, what do you do when you don't know what to learn? How do you fix your mistakes when you don't even know they exist? You don't know what you don't know! This is where a good mentor can be life-changing. With their experience and contextual knowledge, they have a birds-eye-view of your career, and therefore, can provide the direction you need to succeed.
Back in 2015, I was working on my first large, high impact project. I clearly did not have the necessary skills to work on the project end-to-end, but for some reason, my manager trusted me with it. He gave me extra time to work on it, but he wanted to push me with a challenging project. As I progressed through the project, I had major performance issues due to high data throughput. I tried all the tricks I had learned in school and few of my past jobs, but things did not improve. At one point, I was frantically trying out random recommendations from popular blog posts and articles in hopes to prevent my first ever big project from going down in flames, and burning my career along with it. That's when I did something that changed things for me. I admitted that the project was a little outside my skill level, and that I would love to have a senior engineer advise on the high level architecture. In an attempt to save my own ass, I accidentally stumbled across my first mentor.
Within just one meeting, he was able to explain to me what I was doing wrong, and more importantly, why. My data throughput was heavily skewed towards the current month and would steeply taper off once the month got stale. It was a classic case of data hot-spot. I was introduced to the idea of sharding, in our case, by month, so that I could optimize at a partition level. And once a partition got too stale, I could simply swap the logical partition into a temp table and truncate it without having to perform any lengthy logged delete operations. I remember him using a classic quote from Uncle Bob's Clean Coder book, when explaining to me, how logical partitions could be altered into actual tables. He said, "If it quacks like a duck, walks like a duck and acts like a duck, it must be a duck, right?" I later found out that Robert C Martin uses this quote to talk about duck typing as part of the interface segregation principle, but for a young software engineer, hearing those quotes in the context of real work, felt like it was all magic.
I lucked out with an incredibly great manager who invested a lot of his own energy into my potential. I also lucked with a highly technical mentor, who could effortlessly teach complicated ideas like how data can be partitioned in various ways to optimize beyond performance tuning, or how something as simple as leveraging appropriate CDNs to serve static content can speed up your web application by 300% or more, or how you can use the chain of responsibility pattern in your architectural design to introduce hierarchical redundancies. You can read about these in books, but nothing comes even close to someone with knowledge and experience showing you the insides and outsides of these design decisions within the context of your own project. Things like these excite you, motivate you and inspire you. And as a result, your growth accelerates 10-fold.
So if you feel stuck, think about whether you have a strong technical mentor, and whether or not, your manager is invested on your growth. Actively and deliberately seek these two things and when you find then, be ready to soak al boat load of valuable learnings they will provide to you.
Reason number 2 - You never ask questions
For the early part of my career, I thought that doing everything I was told would give me stellar performance reviews and I'd climb up the promotion ladder like nobody's business. I couldn't have been more wrong. It's not that I got bad reviews, I met all my expectations. But what I didn't understand early on is that meeting expectations is not performing at the next level. And I can guarantee you that in 99% of the cases, you will need to already be performing at the next level to be promoted to that level. As an entry level software engineer, your job is to simply validate the skills that got you the job. Just by showing up to work and not royally fucking thing up, you meet your expectation bar. You are given a set of tasks and timeline to finish them, and you get them done. But, to move up to a mid-level software engineer, you need to have more curiosity around the work you are doing.
Why do we need this feature? Why is the current architecture designed in a certain way? How can we improve it? Can we improve it? Who is our customer? This is called thought leadership. And for various reasons, most notably, imposter syndrome, a lot of young software engineers software engineers shy away from asking important questions and this hurts their ability to grow in the area they work on.
If I had to succinctly describe the expectation of each software engineering level in terms of asking questions, I would say the following:
Entry level - Ask questions to learn
Mid-level - Ask questions to anticipate problems
Senior - Ask questions to provide an educated opinion
Principal - Ask questions to influence the direction
Higher than that - Ask questions to make larger business decisions
Regardless of what level you are, curiosity is at the front and center of your growth. Curiosity also leads to ownership, which then leads to accountability. Ownership and accountability are critical leadership traits. So, if you want to grow as a software engineer, start asking questions.
Reason number 3 - You don't invest on yourself
It is totally cool to have a clear work-life balance to keep work separate from your personal life. But that does not mean you also leave all your interests about software engineering back at work. You can still have hobbies around the same area. Perhaps you have kids and you teach them a thing or two about building cool things with Raspberry Pis. Maybe you are a backend engineer at work, but you dabble with machine learning and the stock market in your spare time. Maybe you have a knack for entrepreneurship and work on your million dollar app idea for a couple hours after work. Or maybe, you just run a software engineering YouTube channel. These things encourage you to continually invest on yourself. If I am giving advice to a hundred thousand people week in week out, I better be up-to-date on what is going on in the world of software engineering. As I help you grow, it helps me grow as well. And maybe your work allows you to allocate time to invest on yourself -- and many companies do these days -- then that's great, you should absolutely utilize that time and focus on growing your skillset, not just to get your job done, but out of interest and curiosity. If you don't do that upkeep, the tech world moves so fast that you will be obsolete before you even know it.
Reason number 4 - Your insecurities keep you away from collaboration
Collaborating with other software engineers is a great way to accelerate your career growth. But sadly, a lot of software engineers are reluctant to collaborate or at least try their best to work within their own bubble. One of the main reasons for that is their own insecurities. That was also the case for me. During my early years, I was very heads down, in my own world. I thought as long as I get things done, why does it matter? It does. Because when you work by yourself, you only have your own perspective to work with. And that can overtime become stale, outdated and even biased.
Through college, I did everything on Java because that is what my school taught. And I got pretty used to Java. For my masters degree, we used some Scala, which based on Java so that wasn't bad either. But every time I had the opportunity to collaborate with friends and colleagues and they suggested using anything other than Java, I'd either ask them to use Java or not collaborate at all. Because in my mind, Java was the best language. Javascript had complicated callbacks for no reason and Python was just silly with it's weird indentation and ugly naming conventions. Early through my professional career, I had to switch to C#. And once I got comfortable with C# and especially all the fancy stuff that came with tools like Reharper and Visual Studio, C# became the best language. We wrote the entire backend of our start-up in C# even though that could eventually cost us more since the Microsoft stack wasn't entirely free then. But then, C# was the best programming language in the world, right?
I broke out of that barrier once I started working with people with different backgrounds and perspectives. I want you to fight that urge "to have it your way or the highway", because collaboration is critical for growth. Your colleagues, both senior and junior to you, or even your friends, are amazing teachers, equally as amazing as mentors and managers! You can learn so much by just working with others. And they can learn from you, too! So, look for opportunities to work on cross-team projects, and start pair programming. You learn so much from watching others display their craft. And not just that, when you get over that "someone is watching over my shoulders" feeling you get when you are initially driving the pair programming session, you gain so much more confidence in your coding ability. Pair programming also provides a process for sharing knowledge and context. Every line of code you write while pair programming, you've got two eyes on it. This not only provides automatic redundancy in terms of code quality, but also in terms of reducing the bus factor. Even more importantly, pair programming allows for different perspectives and knowledge-sharing. This is amplified even more on a swarming session, where more than two developers collaborate to debug code or knock out a feature.
So, leave your insecurities, ego or seniority behind, and take every collaboration as a growth opportunity.
Reason number 5 - You are afraid to step out of your comfort zone
We all get complacent at some point in our careers. It's happened to me, too. After an amazing run of growth from 2015 to 2018, in late 2019, I started feeling like I had hit a ceiling in terms of my growth as a software engineer. I had lost that feeling of "I have to keep growing", "I have to keep pushing myself". Even though my performance numbers were still pretty solid, deep down inside, something didn't feel right. I had become too comfortable. I had gotten complacent. At that moment, I had two choices: embrace that comfortable life where I had a great job with great compensation, benefits and security, or to pull the rug from under my feet and step outside that comfort zone. I chose the latter, and quit my job without knowing what I'd be doing next. But as a result, I was forced to think outside the box and explore new ideas, find new hobbies, try different avenues that I had never thought of before. I had time to invest in learning about the latest movements in the world of distributed systems, which is what I was passionate about. I also always loved mentoring others, so I started a YouTube channel, even though I was deeply uncomfortable in front of the camera. But the whole idea was to step outside that zone of comfort. And all that eventually led to a great new job where I work with distributed systems day-in, day-out, and this software engineering youtube channel with over a 100,000 subscribers in just one year -- it's just crazy!
So on hindsight, staying back and taking home a paycheck I didn't deserve would have been a bad idea, and I'm glad I stepped out of my comfort zone. Because, I genuinely believe that true learning happens outside your comfort zone -- when you accept that you don't know a lot of things, when you seek to learn from others, when you push yourself to do things that are challenging because your intention is to learn from the process, and when you share your learning with others -- that's when you grow. It's terrifying, overwhelming and nerve wracking. But, I promise you, that once you transcend beyond the boundaries of your safe space, your personal as well as technical growth will be far greater than what you could have ever imagined.
