When discussing current changes in the market and especially the rise of AI, the most endangered group seem to be junior developers. Let’s take a look at what being a junior developer means, what their role in companies entails, why they are important and what you can do as someone just starting out to make yourself stand out.
A skewed image of tech in media and marketing
The tech sector has been the poster child of press and media of continuous growth and constant innovation. Especially the story of a self-taught developer with no means becoming a millionaire overnight because they wrote “the killer app” is not getting old. This gave people a wrong impression of what working in tech is about, and pushed it from an excellent place to work with good salary to a high-stakes battlefield where only the best and most innovative win. Tech has been constantly growing and got all the support and benefits that other jobs did not. A lot of people want to get in on that and there are big promises that by attending a boot camp and learning a hot, new technology you’ll find a high paying job in days. The other big siren song is that this knowledge will make it easy to start a company to be your own boss.
The idea was to write code, deploy the app, get millions of users, lots of money and - in the best case - sell the app to someone else and create the next amazing thing. This works for some, but it is far from being the norm.
Move fast and break people?
The constant delivery hype of our market doesn’t lend itself to having hierarchical teams. The goal is not to write a great product that gets maintained over years, but to create, destroy, re-write and re-release. However, this is just a glossy, small piece of the market. And it doesn’t result in good products either.
Code is not a magic key to a world of money and success. It is a tool. Other tools are writing or knowing where to look things up that you need. The fast paced glossy world of killer apps and explosive success startups also doesn’t lend itself to a healthy work-life balance or leaves space for mental health and social contacts. Burnout is not uncommon, and staying in the office or on the job for long periods of time is considered a given. If you’re young and eager, that seems not to be that much of a problem, but it does deteriorate your social skills which are incredibly important for your further career once you fail to become a millionaire.
The realities of being a developer
In 25+ years of my career, in my work,I built 6 projects from scratch, 2 of which never saw the light of day. Everything I built and released quickly were side-projects or fun things I wrote drunk in the wee hours of the morning. Most of our job is to extend existing products, maintain them or clean them up. Products are not successful because they do a job well, but because they keep adding new features. These are also the products that vanish quickly or are merged into bigger ones. The products that do a job well are often old and hard to change as over the years many cooks were in the kitchen adding their own magic ingredients to them.
Getting started as a developer in a company
Bootcamps, training courses and many other resources tell you that knowing a certain technology is your job and you will start developing great things right away. The reality though is that the first few months of any developer are almost never spent developing. Instead, they get set up in the company environment and get to know the current products and their limits. They also have to understand the delivery cycle and the human parts of it. Who needs to sign off on your work? Where do you get specifications from? Who sets the goals and the time you get to fulfil them? You also get onboarded to company policies and deliveries and learn about the hierarchy and the structure of the company.
This means that outside of startups with a few people or side projects your job doesn’t consist of writing new code. Instead you fix bugs in old code and go through your task list. You contribute to existing code, write tests and pull requests and add new functionality defined by others. You also have to work with QA and PMs to make sure your code is according to the company standards and outside demands (GDPR comes to mind).
Knowing how to write code is just the starting point
It is important to remember what development knowledge means at this stage. If you don’t do your own thing, knowing how to program gets you past the job interview. Knowing how to work with others inside the company makes your career.
A change of skills over time
As a junior developer or someone just starting you tend to take code and use it without knowing what you do. Don’t let people tell you that this is just you - we all did. Back in the days we copied and pasted from other people’s source code, later we used Stack Overflow or packages and libraries others have written. Now, a lot of people ask ChatGPT, copy and paste the results, change some numbers around and if nothing breaks, ship it.
This is a spectacularly bad idea. If you don’t understand what you do, you will add security, performance and many other issues. However, it is also a learning experience. You need someone to tell you what’s wrong with the code or learn the hard way after an incident that this is not a good way of working.
As a senior developer you get more and more into reviewing other people’s work and put in safeguards to prevent juniors from causing incidents.
As a lead or principal you deal more with team dynamics, structures, time and allocation assessments than writing code.
And in even higher up roles you define code standards and practices and contribute to the company direction and product decisions.
The lower on the ladder you are, the more code you are likely to write. But you also make the most mistakes, so you need your company to back you up on that. Allowing junior developers to mess up is an integral part of our knowledge and we can not skip that part if we want people to work for us that know what they are doing later on.
A waning demand Junior developers in the current market
For companies to ensure that their product will be maintained in the future and to not waste time onboarding new people all the time, establishing and planning for a tiered hierarchy in their engineering department is a must. However, it seems that there is a massive downturn in junior developer jobs. The WeAreDevelopers job platform, for example, shows 10% of job ads for juniors, 48% of intermediate and 42% senior engineers. This is in stark contrast to the messages that the developer market always looks for more people. There are several reasons for that.
An over-reliance on frameworks
The first reason is that the use of frameworks and packages seems to replace the need to start from scratch. Every product out there, may it be React, Vue, Angular, Tailwind, Vite and others promise to enable you to hit the ground running as a company and build a great product without having to have big teams. Developer efficiency and convenience are their biggest selling points. And, as a lot of them come with free and readily available training materials many companies list them in the job ad and use them as a gatekeeping tool.
We expect developers to do their own training and learn before they apply for a job. This is counterproductive to the company's need that always comes up: that engineers know the tech but also know about the company setup and structure. In other words: companies make themselves dependent on the library or framework instead of investing in people. A lot of badly maintained products I know that are hard to hire new talent for are reliant on some outdated tool that back then promised to solve all your problems.
The myth of the 10x full stack developer
The second reason is the myth of the 10x developer, a developer so effective that they can do the job of 10 people. Or the excellent full stack developer that knows how to set up a hardened server, optimise the database, create a solid API and build a perfect accessible and engaging frontend without display issues at the same time. Now, I have encountered amazing developers that could do the job of three people. I’ve also always found them to be utter poison to the team culture. So, yes, if you want to save money and time go and find that mythical being. Don’t expect them to stick around for too long and create code that other developers can maintain though. Which brings us to another big issue with junior developers.
Job hopping and wasted investment
One of the most frustrating things I encountered as a lead developer is junior developers job hopping. This was a practice, especially in technical hot spots like the Silicon Valley, to take a job to get the name of the company on your CV and move on to the next after a few months. Instead of wanting to do a job, you wanted to add to your perceived experience you had. People successfully jumped 3 levels in a short period of time that way. During the high times of our market I also found people to use similar tactics inside the company. At Microsoft, for example, a few people who didn’t get promotions left the company and applied for jobs in other departments just to get hired on a higher level. There is a current downturn on this. First of all, companies don’t hire all the time and they also got wise to that hack and see it not as a clever way to increase your career but as a red flag showing that you have no plans to be a loyal worker in the first place.
The average retention rate of a developer was 1-2 years and declining, and it is not surprising, that this meant companies were less willing to invest in people that don’t plan on staying anyways. Given that onboarding an engineer took us from 2-3 months to really get them effective, this was a lot of wasted investment and effort.
On the flip side, waves and waves of mass layoffs and radical changes to office policies also made the brave new world of big tech a less reliable target for new developers, too.
The big one: AI will do all the menial development work
In recent years the big spectre is the rise of AI and “intelligent systems” replacing the need for engineers, especially junior ones. This is nothing new. There has always been a promise by software companies to allow you to build the next killer app without needing to pay developers. This was never the case.
Sure, you can build prototypes with a single prompt these days. But this is not a product, this is not what customers will pay you for. You will have to have a team that knows both your technical needs and those of your customers to have a product that succeeds and lasts.
The other big movement is to have AI be an aid to developers to build things faster and better by tapping into the vast data and code we have accumulated over the years. AI Copilots and guided development are a fascinating new market and world, but it has a big problem.
These systems favour popular over appropriate. Earlier we explained that developers should not just copy and paste code they don’t understand. This doesn’t change when the code is part of an autocomplete or the answer of a chatbot.
Over the years, every single development resource I worked on or took part in suffered from one issue: the answers that gave the fastest result were the ones upvoted by the community, not the best ones. And guess which ones were used to train these assistants? Using a code assistant is a bit like hitting “I feel lucky” in Google and expecting the best result because Google knows what’s best. Not that those who paid the most for it to be first. Often code assistants would get you the fastest and easiest to read option, not the one that performs the best or is easiest to extend and maintain. It is a happy path, because AI is supposed to always be helpful and not tell us to learn more before applying its outcome. But learning about the limitations of code and your solution and finding the errors and dangers in it is a crucial part to move from junior to senior developer.
There are already voices that warn about code assistants erode programming skills, that AI assistants are not as useful as we think they are and that using AI generated code makes you a bad programmer. Worse, even, bad actors are already trying to poison code assisting environments via prompt injection to offer malicious code to developers using them. If you want to learn more about that, check out Liran Tal’s talk about the security aspects of LLM driven code.
But the question of course remains how should developers move on from junior if they don’t even get a chance to get started in the first place?
Companies must re-learn that junior developers are a good investment
Right now we are still in a massive hype phase where companies want to always ship new things and hope they stick. And our market is a mess because of it. Software quality has declined and the amount of news of security issues, data leakage and people paying tons of money to cloud providers because of ineffective software keep rising. Software has become a commodity and many companies see developers as just an extension of that, not as people. The mass layoffs we have seen lately and the subsequent changes in perks and packages for developers show that, Some of that could be because companies are frustrated by people not staying long enough in one place to be effective. But maybe this is a two way street and we as developers also need to get something to believe in again when it comes to work contracts. A company investing in juniors and showing them an in-house career ahead is one that cares about people. And it is always cheaper to keep an effective person in the company than to hire new ones.
Looking back at my own change from junior to senior to principal and beyond
I’ve been lucky. I have worked in the field I deeply love since 1996. Every time I started a new job, I managed to get promoted quickly. I have worked with amazing people and learned tons. I led teams and taught people of all walks of life and worked with huge projects and in the companies that drove the market. I am not a great developer – I have no degree and never learned about algorithms and patterns – but I did invent a few along the way. The biggest thing I had going for me was that I was always ready to learn something new and integrate myself into existing environments, improving them from within rather than continuously reinventing or battling my company and peers about using the thing I enjoyed the most.
What can you do as a junior developer to get a job?
The things junior developers need to be aware of are the company demands mentioned here earlier. You need to have a basic understanding of development. But the more important bit is that you have to make yourself easy to work with. So when it comes to finding a job, you should look around and learn about the companies that you are interested in. And here comes the interesting part: go for older, more “boring” and mid-market companies. These do have a hierarchy in place. They want junior developers and provide them with a career inside the company. Sure, they don’t offer as much as startups and big players do in terms of salary, but they also don’t mean you have to deliver and “hustle” all the time.
The other thing to do is to make yourself visible. Write a good, concise CV without embellishments and spend your time instead playing with technology and creating a few demo apps to show. Contribute to open source repositories - even if it is just fixing typos. Get out there and meet people at free events and meetups. Remember that starting at a company means you will have to learn how the place works anyway, so don’t focus too much on accumulating tech knowledge, but focus on the human aspects, your soft skills instead. MDN has a great article with lots more tips on how to get started.
