Being a programmer is a great thing. For me, there's nothing better than working in software engineering. It's highly satisfying to write code that works, to develop products that potentially billions of people are using every day (think Facebook), to have the opportunity to work with the smartest minds on this planet, and to get paid (well) for what I love to do.
A career in software engineering is often divided into phases. Most people start as junior developers, then later become mid-level and senior devs. But is it wise to follow this path? And what's expected of you at each career step? How do you progress?
I have been down that road and beyond and I want to share my experiences, thoughts, and opinions with you - providing some guidance for your own careers.
Let's start with the good news.
Everyone has to start somewhere. No one is born an expert developer.
Of course, getting your first job as a developer is far from an easy task. But you can do things that will work in your favor. Let’s start with something you can control: your resume. Quantify for impact, check for typos, keep it simple.
Internships are a great way to gain work experience. For many people, they're the launchpad for their first permanent role. Don't just look for money. Yes, corporations like Google, Facebook, or Amazon pay their interns five-figure salaries. But the competition is extremely strong and smaller companies can teach you valuable things as well. That being said, don't sell yourself short!
A part-time job during college, where you can practice your coding skills is also great. Look for job postings on and offline.
Many people think that in order to contribute to open source projects they already have to be expert developers.
Bootcamps have evolved over the last decade. They provide a compact way to teach you the basics of software development. They're especially aimed at people without a background in computer science. They range from three months to a year and are not generally cheap.
If things played out well for you and you landed your first job - great! If it takes longer than you have expected - don't worry, hang in there, good things take time.
Beginners tend to think that writing code that works is the same as writing good code. They can also think that everything needs to be fancy and overly complicated because that's how the pros do it. I encourage you to make mistakes but also to learn from them!
Here's some important advice for the early phase of your career:
I cannot stress this too much: Most junior devs simply don't ask enough questions.
This is the time to learn, to observe, to suck everything in. If you don't ask questions you will not only miss great opportunities to becoming a better programmer but people might also think that you're not interested in them or their work. Or even worse, that you think you know everything better. You don't! Even if you do - don't show it. Show them respect and be smart about it. This is your chance to lay the foundations for your future!
The chances are you joined an existing team in your first role as a junior developer. It's highly uncommon that you work on your own right away so don't waste the opportunity to observe your team members and how they interact with each other. Are there other junior devs? Senior devs that could potentially mentor you? Who seems willing to help others out and who doesn't? When are the important meetings like dailies, retrospectives, or plannings, and what is expected from you and the team?
Maybe you already have experience with one or another IDE when you are starting your first job. However, teams and projects have their own setups when it comes to development activities. Maybe they use VS Code, maybe PHPStorm, maybe something else. You want to get familiar with the tools as soon as possible. Ask what linting-rules the team uses and practice shortcuts to becoming more efficient when coding.
When you start writing code no one will expect it to be perfect right from the start (what's perfect code anyway?). What you want is to write code in a way that others find easy to understand and that speaks for itself. You want variable names that speak for themselves and you want to keep functions short. Don't do fancy things to impress others and always keep in mind that you're not the only one working on the codebase!
Most companies work with Git as their primary version control system. You want to learn the basic concepts right from the beginning because this is a vital skill for the rest of your career. And a potentially contentious point if you work on a wrong branch or push untested code to production (never do this!).
Many companies have established mentorship programs that pair junior devs with more experienced developers. But if that's not present in your company you should try to find someone on your own, preferably from within the team or company.
Code reviews are mandatory in many organizations, to reduce errors and prevent bugs. For you, the starting developer, they're a great opportunity to become better.
Approach them from two sides: On the one hand, you want to review the code of others as much as possible and ask for what you don't understand. On the other hand, others review your code and don't take their potential criticism personally but as a chance to improve your coding skills.
Pair programming is also a vital method of transferring knowledge. While it might be a bit frightening to directly work with someone else on the same machine, I can only recommend to do it. Don't be afraid to take over the keyboard and make mistakes - you learn from them!
Some people recommend taking on side projects to practice skills and learn new things. But I would advise you to do that later in your career. If you are just starting, believe me, there's so much to learn that you don't need anything else.
After your first two years in software engineering, you should call yourself a developer. This is the position where many people stay throughout their careers. And there's nothing wrong with that.
Attention: This is not just about the code you write but the ability to work in and contribute to a team and to understand software development workflows and processes. You should also understand common design patterns and understand the KISS (Keep It Stupid Simple), DRY (Don't Repeat Yourself), and SOLID principles.
You should be familiar with IDEs and version control software. You should be able to write good code on your own and to tackle more challenging tasks. There's nothing wrong with being a developer that works on routine tasks, fixes bugs, and contributes to the codebase. In fact, this is what the majority of people are doing every day. There are a lot of developers out there that love their jobs and are getting paid well.
Now would be a good time to try out other languages or frameworks. You could start a side project on your own or have a look at open-source projects.
Many people think that a senior developer is someone who writes perfect code in a fraction of time without any errors. A one-person army, building entire web applications on their own, producing deliverable pieces of software every day. Sadly, many companies are still looking for this fairy creature. They should look for something else.
As an experienced developer, you should be able to see the big picture. You constantly have to ask "why."
Why are we using a particular language? Data storage? A specific architecture?
Senior developers won't say that language x is better than language y. Instead, they understand that for a particular problem it would be more appropriate to use language x. They care for performance. They write code that's maintainable and leaves no technical debt for others. They also know when it makes sense to write code that seems amateurish and that violates the DRY principle but helps others to understand it or leads to better performance.
The most important deliverable for a senior developer is more senior developers!
One of the most important attributes of a senior developer, if not the most important attribute, is strong social skills. In the end, most projects fail because of a lack of communication. It's your responsibility to take care of less-experienced devs - to mentor them. But you should also be able to talk to stakeholders and executives and explain things in a way people with less knowledge can understand. To be a team player who strives for long term success.
Senior developers understand that working in software engineering is not solely about instructing computers to execute bits and bytes. It's also about communicating with humans.
There's no objective way to determine if one is a junior, mid-level, or senior developer. After all, titles are often used as a guideline to salaries - they depend on the company you work for. Real experience won't come from a title but from what you've learned from mistakes and failures.
When you gain experience, try to understand the bigger picture. Improve your soft skills, help others out. Be bold and open-minded. Don't base decisions on personal opinions but on what works best to solve complex problems.
Finally, don't hang onto those titles too much. A real senior developer doesn't care about the title - they care about the impact they have on people, products and companies, and their legacy. In the end, we're just people with strengths and weaknesses. We struggle, we fail, we get knocked to the ground. But we get back on our feet to continue doing what we love - developing software!
Don't forget to follow me here and on Twitter for more upcoming posts!