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.
Getting Your First Job
Let's start with the good news.
Everyone has to start somewhere. No one is born an expert developer.
It's a misconception - often fueled by job listings that search for junior developers with ten years experience in four different JavaScript frameworks like React (which isn't even that old!) and three database technologies - that junior developers should already be expert programmers. That's absolute garbage - don't let it affect you or your self-confidence.
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.
Apply for internships
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!
Have a part-time job
A part-time job during college, where you can practice your coding skills is also great. Look for job postings on and offline.
Create a portfolio
A portfolio consists of projects, for example javascript projects that you've worked on that you can show to potential employers. It's a good thing if you have one but not as important as many people want to make you believe. Portfolios don't get jobs - it's the people behind them. Don't expect to land a job because you have one. However, it can help you to get a job interview.
Contribute to open-source projects
Many people think that in order to contribute to open source projects they already have to be expert developers.
Go to a Bootcamp
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.
Junior Developer - Observe and Learn
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:
Ask questions
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!
Observe how teams function
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?
Get familiar with an IDE
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.
Learn how to write maintainable, clean code
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!
Learn how version control software works
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!).
Search for a mentor
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.
Embrace the power of code reviews
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 program if possible
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.
(Mid-Level) Developer - It's Not All About Code
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.
Senior Developer - Time for Mentoring
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.
Final Thoughts
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.
At the beginning of your career be patient. Learn the basic patterns of software engineering and work on your technical skills. And understand the difference between Java and JavaScript!
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!
Top comments (11)
Great article Simon 👌
One thing that I would like to add:
Being a senior does NOT necessarily mean you have extra super tech skills, it is more of the soft skills, things like empathy and communication... and yes, most seniors understand the business drivers.
Thanks, Yaser!
I fully agree with that and thought I had that covered in the article. Well, obviously it wasn't as clear as intended but I have a whole paragraph dealing with the importance of social skills for senior developers.
Best,
Simon
Yep Simon, I've read it and you articulated that well... It was just worth more highlighting.
One thing that I would like to ask.
What can you do when you have always worked alone, or should I say as the only developer in a team of 3, at most? What happen when you have to sometimes manage many roles at the same time (developer and product owner at the same time) or develop a web application alone (complete with design and testing, with the choice of the language) just after two years? because there is no one else that can do it?
In my case, mentorship doesn't exist, well apart from what I can read on dev.to, and I often must do my best to assume the role of a senior, even if I don't really feel that I should, because I have been placed on the project as an "expert".
I have no idea where I stand really. Dev.to is actually really important for me as my only reference of what a good developer should do
Inspiring and well-written. Thanks for brightening up my Monday, Simon!
Thank you for your kind words 😀
Great article
Thanks, Micheal!
I was hoping for a magic potion
Thanks Simon. I learnt quite a lot. A nice article indeed
Thanks, Rotimi!