Being a junior developer is a phase, a rite of passage that we all pass through. This phase is the starting point that made the masters of the trade that you and I know. Today, I share some ideas from my experience on common things that juniors do and think. Seniority is not measured by years of experience, but by many other key points that are touched on here.
Let’s start with the first point – having a narrow view of the programming language you are learning.
Your Job Is To Solve Problems
Juniors often get so involved in learning the programming language that they are learning without really understanding that a career in programming is more than just coding on their laptops. There are a lot of factors that define senior developers, and they are not their coding skills.
Programming is partially working with computers, but it’s more with humans. It might sound contradictory, but you have to always remember that your job is not to code.
Your job is to solve problems. You are solving problems of 2 kinds of people: stakeholders and end users. Whatever you are developing or doing using your coding skills must always solve business problems – to make money for the business owner and to solve a life problem for the end user.
So, you should open your mind to see the big picture of the business instead of having a fixed and narrow mindset of the programming language that you are using.
This will allow you to be more interested in what your colleagues are doing – the designers, the marketers, the frontend developers, the backend developers, the DevOps engineers and the business owners themselves. I recommend you watch my video on YouTube where I discuss the production workflow in software development:
Master of programming language, not human language
You must master 2 languages: your lovely programming language, and human language. Since a career in programming is about solving people’s problems, it’s a must to master your communication skills. Although communication in life is more about body language than words, a career in programming requires both.
Imagine how it sucks to work in a company with a single highly ranked developer, like a software architect, who is the only one in the company who knows how all the system is connected and how all the pipelines are connected and built, and there is no documentation to guide other developers, especially newly onboarded ones.
Being able to speak eloquently, precisely with direct and concise language is a must if you don’t want to be stuck in the junior role title all your work time in your company.
Use a professional language to speak to your managers and other developers. Learn to read more, so you can speak better. One speaks only what they read. Reading popular technical documentation will build your ability to write documentation yourself.
Communication is also not only about documenting your work to other engineers but also about speaking to your managers and the business owners. These people do not care about fancy language like “dependency injection”, or the “app router API”. The only thing that they care about is results. It’s not about what you did, but about what results you achieved.
Think in terms of metrics, automating tasks, saving time, saving money, boosting performance, improving user experience, or similar results. This is what your coding skills revolve around, and this is what your communication should be about with professionals like stakeholders and business owners.
Stuck in the ‘Tutoring Hell’
“The road to hell is paved with another YouTube tutorial and another Udemy course” – wise developer.
Since most of us are indoctrinated at school to believe that learning happens by only attending lectures and lessons, it is easy to get lost on YouTube or Udemy from one video to another, or one course to another. This phenomenon is called “tutorial hell,” where you feel you are in the hell of coding after someone else without developing the courage to fail and find solutions on your own.
How do you get out of tutorial hell? Simply go and build something! Escaping tutorial hell requires a shift in mindset and approach.
The structured, guided environment of tutorials provides comfort but can also become a crutch, preventing you from developing the critical problem-solving skills necessary in the real world.
Instead of passively consuming content, start by identifying a project that excites you—something small and manageable to begin with.
When you dive into building your projects, you confront real-world challenges that force you to think critically and creatively. You’ll encounter bugs and obstacles that aren’t covered in tutorials, compelling you to research, experiment, and learn independently.
This process might be frustrating at times, but it’s also incredibly rewarding and a true test of your capabilities.
In the real world, there is no online instructor who’s going to help you. You must find solutions yourself. This might involve reading documentation, scouring forums like Stack Overflow, or collaborating with peers. By tackling problems head-on, you develop resilience and adaptability, which are essential traits for any successful developer.
Build in Private
One of the things that many junior developers might fall into is enclosing themselves in an isolated shell, learning and building projects in private. I tried to convince you earlier that coding is not merely about coding. Opportunities in life do not necessarily come to you because of what you know, but more about who you know.
So, it is recommended that you build your network and start sharing your journey of what you are learning or what you are building in public. Building in public is more than just a trendy buzzword; it’s a strategic move that can significantly impact your career and personal growth.
When you share your progress, challenges, and successes openly, you invite a wide array of professionals into your sphere. Product managers, business owners, developers, designers, founders, and co-founders all can take notice.
These connections can lead to invaluable feedback, mentorship, and even collaboration opportunities that might never come your way if you remain hidden behind closed doors.
Moreover, by documenting your journey, you create a portfolio that showcases not just your technical skills but also your problem-solving abilities, perseverance, and growth mindset. This transparency can be particularly appealing to potential employers or clients, as it demonstrates your commitment to continuous learning and improvement.
Hello, I’m a junior developer looking for a job!
Junior developers often expose themselves to the world and introduce themselves as “junior” developers.
There is no shame In being a junior in any field, but constantly talking and mentioning that on a resume, a cover letter and social media will set you in the lowest pyramid of dominance. Whether you like it or not, you are NOT the only person looking to get employed for that role.
Telling recruiters, who often have no idea of the technical details of the job, that you are a junior will most likely result in a NO as a response.
Although being a junior is not something to be ashamed of, but the harsh reality is that nobody wants to work with juniors. How should you introduce yourself when you are truly a junior developer? Simply “developer”. Period. To get out of the junior label, you have to work on real-life projects.
Showcase your skills through personal projects, open-source contributions, and any freelance work you’ve done. This demonstrates your ability to apply your knowledge in practical situations.
Look for internships, volunteer opportunities, or part-time roles where you can gain hands-on experience. Even small projects can make a big difference in building your credibility. If you want to take it to the next level, build a SaaS or even your company. Try it, it’s easier than you think.
Advertising yourself as a junior developer will suffocate your career growth in the long run. People will attach a label on you based on different factors like what your skills, your achievements, and most importantly: how you see yourself and how you describe yourself.
When you join a company with the junior label attached to your title, it will be almost impossible to remove that stigma because this is human nature. Always appear stronger than you actually are.
My code just works!
The last thing I would like to discuss is a very common practice among the community – copy + paste. There’s nothing wrong with copying content from websites like stackoverflow, but to get out of the junior developer label, you should understand every line of code that you copy.
Other technical indicators of junior developers include:
- Neglecting data structures and algorithms: Although they are not used often, but there will come a time when you need them, and if you don’t, you’ll pay a big debt.
- Neglecting Git: Git is a version control system that makes contributions and working in a team possible. Every developer must learn git before becoming a part of a software development team.
- Bad variable names: I know that naming variables is the hardest thing in software development, but let’s make this more tolerable by creating descriptive variable names. Instead of using “data1” or “data2”, make it more descriptive to make the code self-explanatory.
- Neglecting testing: juniors usually are not aware of the importance of test coverage like unit testing, integration testing, API testing and so on, and then they try to implement testing all at once, and here is the catastrophe!
Testing is probably not what you want to learn, but you should learn it. That’s why I recommend you check out my testing series on YouTube.
So, today we discussed the importance of having a broad view of the software development process, develop communication skills with our fellow engineers and with the business owners. We also discussed some technical points and how to address them. See you in the next one!
