26
Career Advancement
Once you have figured out a way into your first software development role, it is only logical that you would consider how you can move forward in your career. But it's not always clear what the next steps are beyond completing the tasks that you are given.
Firstly, I'd like to say that setting your focus on climbing the ladder quickly is not exactly the best use of your time. No doubt that you've figured out that learning is a pretty important part of our career field, and that doesn't change after getting hired. Having a job does provide a significant amount of direction for your learning. It's a good first step to get comfortable with the language, frameworks, and tools that your team uses; focus first on what's relevant to your current project. Learning things that seem small may be greatly helpful when making decisions later.
When you are learning your first language the biggest thing that you are really learning is what computer programming really is. You learn how a programming language can be used to complete tasks. When you learn your second programming language, then the most important thing that you are learning is how you learn best. You will also learn how much the learning of your first language carries over into using a new language. There should be significant overlap in techniques. The language after all is just a tool at your disposal. By the time that you learn your third programming language you are really learning how esily you can pick up new things. I highly encourage people to take languages one at a time. You will learn more by getting into a deeper knowledge of your first language than by trying to learn three languages at the same time (like one of my coworkers). Allow yourself to become fluent in your first langauge to the point that you can think in that language the same way that you would a spoken language. If for some reason you find yourself working in a new language before you believe that you have reached the necessary depth in your first language then you should work to bring that new language to the level of understanding that you had in your first language, and continuing in this new language from there.
The biggest part of your career, throughout all phases of it, is you. If you are anything like me then you may have managed to reach a suprising age before actually understanding WHO you are, and what your strengths are. Branding is something that gets discussed a lot in some dev circles, and the short version is that you have to know what's important to you, and what you're good at. I highly recommend asking your coworkers that know you best what they think your strengths are. For me personally this is asking questions and just talking to people. I really enjoy learning about things, whether those things are relevant to my job or not. The thing that has been the central pivot of any acknowledgement that I've received are about taking part in discussions and asking questions that move towards goals. Your strengths aren't likely the same as mine, but it's very important that you know what they are.
Once you know what things set you apart from your peers and where your largest amount of value lies, you need to keep these in mind during your work. For me this means that I make sure to ask questions about things that don't seem to make sense. Sometimes this reveals that I'm just the only one in the room that didn't know something, other times it reveals that the entire team had assumed something wrongly. If your strengths lie directly in code work then perhaps you would be able to provide special value in your code reviews or pair/team programming where you could make an impact with the overall code quality. Whatever you do with your streghths, remember that every person on your team also has some strength and you should never assume that you are better than they are.
The best engineers not only provide value in their work, but improve the skills of those around them. This comes in the forms of teaching and of motivating those around them to learn more. Developing a culture of improvement and learning is paramount if a team is going to get better over time. As learning is such a pivotal part of our industry a team/person that is not interested in improvement is a liability to their company as our tools continue to improve. Our languages get new features and flaws are discovered. If we don't grow with our tools then our productivity is actually reducing over time.
In order to become a junior developer you need to learn how to write code. These are the basic skills that everyone in the field should have. I expect that everyone reading this understands some amount of computer programming basics and knows that it is the vocabulary that we use to discuss solutions.
In order to move on to a mid level then you need to understand the tooling itself and how tradeoffs work. Every tool has its strengths and weaknesses. As you work on different projects you will learn about the weaknesses of the tools that you use and the problems that can happen because of this. There is no such thing as a 'best programming language' or 'best framework'. Every tool has an area where it accels. Understanding tradeoffs is what will help you to move into this space.
As you move toward senior or lead, your skills need to spread more into team culture and dynamics. It becomes important that you be able to mentor other developers. Mentorship doesn't always imply that the mentor knows more than the mentee. We all have gaps in our knowledge and in my experience a mentorship relationship can actually go both ways. The developer that has been in the industry longer can provide direction from that knowledge, and the developer that's been in the industry less time can provide information about different practices or tools that the more experienced dev has no experience with. Being able to identify where your knowledge gaps are and who around you knows the most are very important. In order to make the important decisions that come with more responsibility and title you must be able to evaluate the necessary factors and this often means asking the people that have the most knowledge.
26