Junior Developers Are Here To Stay - Here's Why

Hi folks. So I'm here with Bogdan today. What we're going to do is we're going to go through this article that went viral, The debt of the junior developer. It basically says that a lot of people picked a bad year to be a junior developer. Not just the computer industry, any industry, it's a bad year to be junior anything. I mean, it's not at as easy as it used to be economy. It's cyclical and you cannot pick the economical cycle you are born in, but you have to deal with it anyway.

Things are not that bad. I would say because of the economy contracting, it's growing to be a bit slower. You will not get maybe hired as you used to get three years ago. But what will happen, and it did happen to me and the girl when we started our careers, we also started in an economical depression. It was 2015 back in the days. What happened is 2018 came. Our skills were good and that's when our career boomed. So, if you do the hard work, even if you are in a economical recession, your skills will keep improving and when the economy will boom, that's when your career will take off and you'll go very, very fast.

So, I wouldn't even care about how the economy goes. What's important is that this year you keep improving and you keep getting better. Because when the tide will come, then you'll be able to to sail again at full speed. I think LLMs in this case can produce research, summaries, brief contracts. what's your take on that? I think the word produce, it's a very strong word. Uh it's basically says the LLM can produce research and summarize and brief.

I think the real production was made by a human that wrote the book, that did the research and the only thing this large language models is to synthesize and mix that up. But produce it's a very strong word when it comes to LLMs. I think they are basically preprocessor or post processors of text. And the correctness of the output of FLM, it comes down to the quality of that text in the prompt. I will follow up with the next phrase which says catching the LLM in a hallucination, catching a junior associating a mistake.

Pretty similar. Really just two options for generating the same output. I would disagree and I think the author with all the respect, I think I think it's pretty engineer. is his understanding of humans, of human level intelligence, and his understanding of what a junior developer it's able to do, it's extremely limited. I would say that the way LLMs hallucinate, it's very, very different to the typical mistakes junior developers do.

The typical mistakes we see juniors do, it's either because they lack certain context or they might not have the knowledge, but they do most of the times have the intent. They know what they want to get done. There's just a missing piece of context or or an abstraction they're not familiar with. Whereas LLMs they have all the abstraction, but they have no idea which one is the correct one. The way LLMs hallucinate, uh they can't really discriminate between what's correct or not, whereas junior developers they do know what they want to get done, that's usually just a knowledge gap they need to fix to get there.

But they are humans, they understand very well the business context, they understand what the customers want, and they have a lot of knowledge that you'd otherwise need to put into an LLM just to get them operate to operate at the same level. So I would 100% agree with that statement. Okay, now let's move on to the next point. He doesn't consider himself a programmer anymore. And this is, I want your input on this.

What what's he's basically talking about is that this programmer makes GPT do all the work. And what I mean is that chat first is a default and writing code by hand with completion, naturally, it's our fallback plan. My quantum friend and I are both finding much less need for that fallback recently. you've been working with all kind of AI AI tools in last in last few months you've been working with a lot.

What's your what's your take on this? I think the quality of AI code, it's proportional to the debugging skills of the person writing it and to the prompt quality. So, what happens as senior engineers is that they see very good solutions when we use AI and it feels like AI it's so good. But whenever you go into a domain you are not so familiar with and you start prompting the AI and you don't know how to debug, the time it takes to actually come up with a good solution, it's even more than if you just go to the docs and start things from scratch.

And the reason for that is that al talked AI, GPT, Corsa and whatever the next rapper around uh GPT4 is. They're really good at generating a lot of code. But that's not producing software. Software it's code that was. Bulletproof, tested, debugged, the edge cases were specified, there was some acceptance acceptance testing, and it was shipped. And when you go from, I have this suggestion and I want to incorporate in a code base, sometimes the time it takes because GPT kind of just generated some code. The time it takes to read that and debug it and make sure it's actually something you can add to the code base. It's even higher than if you start from scratch. So I think it's very much depends on the specific task. If, for example, you want to refactor some documentation, you have a JSON document, you want to write it as YAM. AI will do that much faster than a human. It can read 11,000 lines of code. It's a very structured transformation and give you a good output. However, if you are actually trying to solve a specific problem in the real world, you're better off understanding the business domain, the problem domain, modeling it yourself. Making sure you come up with the smallest data structure and then writing the code. The more time and the more experience the programmer has, the less code we write, the faster we able to find solutions without going even without even maybe writing any code at all. And that takes a lot of creativity, it takes a lot of system understanding and problem modeling. AI, as far as I played with all the tools, cannot do any of that. It's really binded to text manipulation. That's what the technology does at its core. It looks fantastic, it generates a lot of code. But it's just text manipulating at its core. So programming has leveled up into a problem of explaining your situation to the LLM that is slanging context. Since you will want to include a lot of information from different resources, and then merging the output back into your code base. I do believe the author is slightly wrong here, and I do believe that the cost in terms of energy and time for you to describe the problem in a way that the LLM can understand it and solve it will get so high, actually higher. And actually you solving the problem and maybe using the LLM to help you fill out the gaps. What's the reasoning outlined by a human? I think what people forget is that when we explain the problem to the LLM, it's still

a domain expert explaining it to it. So, it's the expert programmer that goes in, kind of knows what they want, they know the function goes in, well, takes a result in a couple of seconds, and it feels like GPT wrote all that. But the reality is, it was the prompt that already interpolated that solution. So, yes, if you're a domain expert and you have a very clear idea of what you want, then it's usually faster to to have GPT writing most of the code refactor it and ship it. But you need to understand that the hard work there is not generating the code. It's having the domain expertise to correct that code and that if you wouldn't have that, and I invite you to test writing code in any technology you're not super familiar with, and this doesn't mean I can build a rest API in Node.js and I'm going to build it with AI in C sharp, because you still know what the rest API is. Try to do something you've never done before, you'll find yourself lost, you'll find yourself going to the documentation, and you'll find out that GPT repeat itself quite a lot, and the quality of the output and the quality of GPT, what GPT can do for you, will get better as your domain expert is expands. So, again, um I think a lot of senior developers are forgetting that there's a lot that comes into when we are querying the AI and um and that comes from human experience, and it's not GPT merit. It's literally the quality of the prompt is the quality of the result. How do you see GPT as a designer, as a designer? It says, I had presented a small design problem to GPT, asking for an evaluation of my options, it's great for that. Chat-oriented programming, it's not about just coding. There's a lot of design discussions too. I mean, I think that's a very blunt statement. Uh, I think the ability that GPT has, I mean, GPT can give you a lot of options. It can also miss out on the good options because it's kind of using a weighted average to find out what's the best option. So I think to be a very big mistake to blindly trust GPT designs without actually using it more for research oriented. There's this saying that if if we were to ask like adding Henry Ford said, if we were to ask the customers, we would build faster horses. I think GPT, if you want to solve transportation and you are back in the 19th century, it would give you faster horses.

I think when it comes to thinking outside the box and coming out with innovative solutions, it literally it might generate something that looks like one, but it's very far away from that. It's just very much uh it's it's been marketed as intelligence, it looks intelligent, uh it looks like it has some mental models, but again, it's very much limited to the text input and to the prompt you're giving it and from there to actually do chat oriented programming. I think that's a very very strong word and I think we're seeing a lot of companies that try this and now they're having a huge problem with code quality. There's too much code, nobody understands who wrote all that. And the best software companies simplify it. They do not make things more complex, just like the best developers. Without being said, let's let's move forward down the road. I mean, I do invite you all to read this article just just for you to go through the same reasoning. Uh, chat it seems it's safer for senior programmers. This goes in line to what said about their domain expertise, the more domain expertise you have. And this is something we were chatting before the video, I mean, chat GPT, it's great, uh, if you already know what you want, so that tells you a lot about the value it adds. I mean, if you can actually help me when I already know what I want and how to do it, then the value you add, I'm not saying it adds no value. But the value you add, it's maybe marginal, I would say. Imagine I would tell you, I know a great doctor and he will help you once you know what your problem is, once you have your diagnosis, he or she. So, you know, would you go? I mean, would you trust that and what's the what's the added value there? Awesome. Well, if chat oriented becomes a dominant modality, which is what in a few years the norm for self-scod will be that it's written and modified by LLMs via prompting. Based on everything we said so far, I doubt this will happen. I think this is an over exaggeration and I mean it's it's a nice idea to think about. Uh I think if you if this person tries to do that in practice, we'll face the same road blocks that was talking about. I think it depends, I think there will be domains where yes, it will make sense to have LLMs writing a lot of code, imagine you're building some sort of an embedded software for a very niche kind of hardware and and it's a kind of restrained problem. You don't want necessarily to specialize there.

writing a lot of that code. Uh if that would happen at an industry scale, we will see and even if it does happen, you would still need expert programmers using those machines. So, we've seen this in the last years when when me and started out coding. There were a lot of people were building um SAS software, Zapier wasn't around. You had to build a lot from scratch. Nowadays, we use things like Zapier, it's a lot of integration work.

And LLMs will help with that. The job hash changed since 20 years ago, it's been continuously changing, but it's very far away from from disappearing. 100% bogging. Okay, let's let's proceed, so defining kind of what a senior is. Uh if you want, and here is where this person starts giving tips to senior devs. And the question is, if you want to survive the change, you better show up prepared and stay on top of it.

The rest of this post is just some direct, simple and timeless advice for junior devs and aspiring software engineers. I mean, I think Bo and I know quite a bit about that, we trained around 270 people ourselves, personally, one-on-one in our coaching programs, so let's see the advice. Get good fast. Oh, yeah, I mean, what can I say about that? Uh, that's what you need to do, get ahead of the slackers.

I do not like to call people slackers, I think this is a bit of an exaggeration. I think most developers we work with, even if they are not at the level they want to, they are very ambitious, very hungry, and I wouldn't call them slackers. A lot of people are struggling to to make it in an industry that evolves very fast. Gain experience anywhere and any way you can. Mhm, before you even leave school.

Mhm, yeah, of course, like this is nothing changes. Get work experience, contribute to um open source. Open source before leaving school, I don't think you have the ability to do that. Uh, program on the side do we need open source given that GPT will write all the code? learned booking. Learn more than is requiring of passing each class. I mean, you know, hey, you know what, also why not have fun in college and, you know, care about worry about getting a job later and get off YouTube for your mental health.

Focus on algorithms, data structures, software design, engineering, discrete math, operating systems, compilers, databases, network, blah, blah, blah, real systems. It looks like three bachelor's degrees at the same time. 100%, and I think this is one of the um problems, the major the systemic problems that we have in software engineering, this kind of advice that tells you basically do everything you can, which is responsible for the poor mental health, for people running in a 100 different direction.

Uh and honestly, the first thing we do, we develop is that decide to work with us is to kind of get them focused and to simplify everything they're doing. Because we don't have a problem that people are you know doing too many things, they are doing too much of the wrong things, okay? So my advice to you, it's just focus on one thing, master it and then move on to the others. And no, you don't need to know compilers, databases and all that just to get a programming job, okay?

So, just chill out and just focus on mastering one thing at once. Focus, it's more important than just doing a thousand different things. And yeah, lean high on coding assistant like Cody. Of course, do use coding assistants, they're very, uh, they're very useful and they will help you go faster. But do not freak out, they won't replace you, they won't get you a job. And just to close up, I will let Budgan say his final words on this.

I would say I made my worst career decisions based on fear and anxiety. It's not a good driver. I think, um, there's a lot of that nowadays in the market. People are, um, there are layoffs, that's for sure. There's been a bit of an over hiring, there's a bit of a change in industry, but again, you just want to make sure that you get better as an engineer. You get better as a professional and you improve every year.

And use AI, uh, use try out Qussaur. We we working with it at the senior dev, try out code in this case. I work with copilot every day. I do not see copilot as the beginning of my thinking or my job. It's usually the end. 100%, Budgan. Yeah, folks. So I hope this helped you. I hope at least we managed to kind of ease off that anxiety. Because me personally and Budgan, as going through this article, if it wasn't for this strong opinion that we hold, which comes in part from our experience, our experience as developers, but our experience training developers.

Um, I would, you know, I would be a bit afraid. I would start, uh, freaking out. if you have any further questions about the things that we talked about. Number two, there is a free think assessment if you're really interested and if you really don't want to chase this all these three rabbits at the same time, like the site unfortunately is telling you to do. Check the the free assessment that we put together for you, it will give you a better understanding of where you're at and what are the things you need to focus on in order for you to level up without having to chase all these different things at the same time.

And I want to thank Bogdan. Thank you, Bogdan. You're welcome. Um, this is a new format that we are trying. I hope you like it because we're planning to do a lot more discussions like that. And let us know in the comments how you like this new format and if you want us to do more of these videos. With that being said, keep your heads up, keep up the good work. And I will see you in the next one.