Throughout my life, I’ve worked with many different software engineers. I’ve seen how many of them succeeded and grew in their careers and, unfortunately, many being stuck and struggling to find new opportunities.
The meaning of “success” varies for each person: some became managers, others tech leads, and the majority (like myself) stayed as full-stack developers for a while (in my case, I was happy as long as I felt challenged and kept learning new interesting stuff). However, the meaning of failure is pretty straightforward for everyone: hating your job and being unable to find a new one meeting your expectations.
Succeeding as a Software Engineer does not have anything to do with the programming languages you use, your coding style or even having “good coding practices” (those things are secondary) but with the decisions you’ve made throughout your career and the habits you have developed as a professional. Because of this, I would like to share the key takeaways I’ve identified about the behaviors of successful software engineers.
Eagerness to learn
Let’s be honest: coding is not hard at all. You don’t have to be a genius to learn to code and become a senior engineer. You can start at any age and the best part is that you don’t even need to go to school. There’re a lot of resources on the Internet and you can choose the type you prefer (books, tutorials, videos, etc).
However, it requires dedication, time, and practice to develop the skills you’ll need to execute independently and solve the problems you’ll have to solve among the way. There are no shortcuts. You can even finish college or take a 12-week BootCamp, but if you don’t keep practicing and learning, I warranty you that you’ll get stuck early in your career because compared to other professions, tech evolves incredibly fast and you will fall behind if you don’t do regular upgrades to your mind.
I also used to believe that you must be really passionate about coding (and tech in general) to be a successful Software Engineer but I’ve met engineers that are not precisely excited about creating software itself (they have a different passion) but they’re still pretty effective since they have developed the habit of learning new things regularly and they’re enthusiastic about solving problems.
Soft skills
It is not a secret that software engineers are not precisely the best in regard to communication and collaboration. Persuading people and communicating clearly and concisely are the skills in which I’ve struggled the most during my career (in both English and Spanish). I’m aware of a couple of times in which I missed the opportunity to be considered for a new position due to a lack of negotiation skills (in spite of being the most qualified in terms of technical expertise) which are crucial while dealing with third parties and due dates.
The first step is to understand that soft skills are as important as engineering work (we are not minions in a cave without the ability to speak) and becoming an engineer that excels in both is a must if you aim for a promotion.
Speaking in front of the mirror and recording and listening to your own voice may not sound as fun as coding your new app idea, but you can find other alternatives to improve your speech that make you feel motivated. In my personal case, I decided to start a YouTube channel to share my old video game creations and I can openly say that my clarity is finally progressing (little by little). It also helps me to increase my portfolio and it is something that I actually enjoy.
Finally (but not least important) being open to collaboration and listening to other people’s ideas is expected and there’s nothing more discouraging than having a coworker that believes that she/he is always right (and “knows everything”). We can always learn interesting things from other people regardless of their age, seniority level or professional experience. Even if we strongly disagree with someone’s approach, we can always yield and let them acquire that experience by themselves (as long as it does not affect the business).
Stepping out of the comfort zone
Switching jobs too often is not always a good idea. In tech, it is common to receive offers right after starting a new opportunity and we may be tempted to jump again to shift our salary. While it may have short-term wins, it won’t look good on your CV and recruiters will definitely figure it out. Also (and more importantly) it will affect your ability to get real experience/learnings from that job because you won’t have a chance to deal with the hard problems of your role after being onboarded.
Don’t get me wrong: You should definitely escape if you discover that a job is not what they promised and you realize that you won’t get anything from it. But that’s different than changing your mind right after someone else makes a slightly better offer. As a rule of thumb, I would not recommend quiting a job within the first 6-12 months unless: (a) you won’t learn anything useful for your career on it or (b) you receive an offer that is substantially better. I’ve observed that people making this mistake get stuck after doing it a couple of times and they have to step back to get real experience and make progress.
Nevertheless, the opposite is also true: If you overstay in a job/position/project, you are jeopardizing your future in this industry. Why? Simple, because at some point you’ll stop learning things that would be valuable for other companies and your knowlage will start to be too attached to the processes, practices and systems of your current employer.
I won’t dare to generalize and suggest any lenght of stay for this one, but it is safe to recommend to switch jobs (or project) if you realize that you’re not being challenged anymore and you feel too comfortable dealing with your duties for a while. Of course, this may not sound reasonable if you are looking for stability but it is a risk you have to take if you want freedom in the long run.
Doing “the dirty” work
Just like a garden, creating software requires constant maintanance and a strong sense of ownership to perform the tasks that are not precisely fun but neccessary. Unfortunately, not all smart engineers are keen to deal with the inevitable problems that will arise while making changes and updating software.
I understand that even for someone that is too excited about coding, it might be exhausting to keep working on new features while refactoring and cleaning up the old messy code that your team (and yourself) haven’t been taking care about. But someone has to do the job and take the initiative.
The best engineer is not always the one that codes faster or works on the most amazing features, but the one that you can trust when something is broken and makes sure that the system is healthy and the product has a good quality.
All successful engineers I know have this characteristic. The ones that only want to do the cool stuff, never stand out from the crowd.