I’m worried about AI.
I’m not worried about it taking away my job. I believe AI is a true productivity tool. By that I mean it can make developers produce more.
Learn faster. Dig deeper. See further.
The question is whether those developers are producing something good or not.
The difference between an experienced developer and a junior is that an experienced developer knows:
- There is more than one good solution to every problem.
- The answer to the question “what is the solution” is “it depends”.
- What it “depends” on, or at least has a handle on how to find out what it depends on.
The way we train juniors, whether at university or bootcamp or whether they train themselves from the materials we make available to them (Long Live the Internet), we suggest from the very beginning that there is a right answer. “This is a solution for printing the Fibonacci sequence using recursion.” Junior developers are trained to think that if the code solves the problem, the job is done.
However, what we do in software development usually doesn’t have was done earlier. If so, it’s usually codified into a language, framework, or library.
What does this have to do with AI? Currently, generative AI gives you the answer. As the AI improves, it will probably even give you an answer that works. That’s great! We no longer need to spend a lot of time training developers; we can train them to be “ready engineers” (which makes me think of on-time developers) and they ask the AI for code and it delivers.
But it’s more complicated. Assuming the first answer the AI gives us will compile and work, it may not match our style of code; may not use libraries and frameworks available to the team; it may not take into account the particularities of the business domain of our particular application; may not meet our performance requirements. An experienced developer would notice all this and either ask the AI to massage the answer into the right shape or do it themselves. A junior developer may be tempted to put this code into an application where it works.
I want to be clear here. I don’t blame the junior developers for that. That’s part of learning. We’ve been doing it for decades. When I got my computer science degree, I used AltaVista (yes, I’m that old) to find solutions to my problems and poke at the code until it did what I wanted, often without regard to any tools, frameworks, or design patterns. we used Later, juniors would use code from Stack Overflow as inspiration, blissfully unaware of which lines they inserted into the code base did nothing and which were actually relevant. These days, those embedded lines of code will be code generated by generative AI.
Our responsibility as an industry has always been to guide emerging developers in the right direction. It was always important for senior engineers to point out the downsides of an approach and show juniors better or newer ways of doing things. I still clearly remember one developer, only two years older, explaining to me why I should use it ArrayList and no Vector. Growing as an engineer isn’t about learning to write more code; it’s about learning what questions to ask, what trade-offs and “it depends” issues are, and what solutions might be right for a given problem.
So back to why I worry about AI. I’m afraid experienced developers will add this to their arsenal of tools to get the job done, as well as code completion IDEs, Stack Overflow, and Google. They will learn how (and when) to use it to give them ideas, point them in a direction, and do the hard work of creating boilerplate code or chunks of common code. They will learn how to coach the AI to give them “better” code over time (for some definition of better). All this time they are training AI: they are not training young developers. In fact, experienced engineers are encouraged to train generative AI the way they were never encouraged to invest time in junior training.
And the juniors – well, the juniors will assume that the AI-generated code works. Experienced engineers will be so busy training the AI that they won’t be helping the juniors level up. Juniors won’t have the tools to improve, and senior developers may spend so much time fixing bugs in poorly implemented code from juniors that the organization might decide that juniors are not only not needed, but actually an unwanted drain on productivity.
what is the problem Surely whether we train juniors or AI the end result is the same? The code that works for our problem. Sure, and as AI improves, we may rely on it even more. And for argument’s sake, let’s say that AI improves enough to replace junior developers. Will it become good enough to replace experienced developers? Maybe, but we’re definitely not there yet. If it’s not enough to replace experienced developers and architects, and if we don’t invest in today’s juniors, we won’t have any seniors tomorrow. For the foreseeable future, we’ll need skilled developers, even if it’s “just” to train AI or help create the next generation of AI tools.
Aside from the pipeline issue, I want to address something that I think is very often overlooked in our industry. Developers are not code producing machines. Our job is not to write code. I don’t just mean experienced developers; I am including the juniors. When I worked in a team that matched regularly, when I was a developer with a solid 10+ years of experience, the people who challenged me the most were the juniors. Yes, I learned a large business from smart, experienced people like Dave Farley and Martin Thompson. What I learned from them were often new things I didn’t know before, or they confirmed beliefs and ideas I already had. But the juniors, they were the ones who really helped me understand what I cared about and why I did the things I did. Juniors really challenge you as a developer. Juniors ask great questions: Why did you do that? Why did you reject this idea? What do you think about when deciding which of these approaches to take? Why is this test difficult to perform?
These questions help us grow as mid-level and senior developers. Why he did do we do it like that? Is it because someone showed us to do it a long time ago and we just blindly followed that approach? Or, after extensive googling and searching on Stack Overflow, after a lot of trial and error and possible refinement, have we found that this is the best way to do it? The answer to that will tell us a lot about how much we understand the matter and whether we understand the trade-offs we make when we go down this road. It should also make us think about whether we need to do more research on this approach or tool – Has it been updated since we learned about this approach? Is there a newer/better/faster/cleaner way to do the same?
Of course, we could just sit there and silently ponder these questions and then continue what we were doing (or choose to do things differently). But verbalizing the inner conversation, doubts, or certainties we have about the answers will not only give the junior some insight into our thought processes, but help him create his own decision-making process. It’s perfectly acceptable to say, “I’m not sure, really. I’ve just always done it that way. Should we do some research to see if there’s a better way?” Or “Well, at my last job we had a limited number of open connections, so I always close them when I can. Not so much the case here, but it seems like a good habit anyway. It comes to mind reason not to do it?” It’s good to ask juniors questions to get them thinking, and it’s great to have a two-way conversation about trade-offs and implementation decisions. God knows we’ve all been stuck in circles thinking about a problem only to solve it by simply asking a question. (Often we don’t even need an answer!)
Seniors know that the answer to everything is “it depends.” Growing as a developer means discovering more and more things it “depends on,” being able to uncover those things in code, infrastructure, or organization, and asking questions to uncover known unknowns. Answering the junior’s questions or guiding them to their own answers helps them on their own journey of knowing what “it depends on” and where to find balance in compromises. It also helps us better understand our own processes and update them when necessary.
AI doesn’t ask questions. It gives answers. With confidence. This is not a challenge for you. He bows to your wisdom when you express an opinion, and yet he also does whatever the hell he wants.
We need tension between seniors and juniors. This helps us all grow. As juniors, we can ask questions, teach ourselves, and help seniors challenge their assumptions. As seniors, we have much more experience with the nuances of why we would choose a particular solution and what preferences we or our team might have for our solution. But even if we can make the AI give us the answer we wrote ourselves, the AI won’t ask us, “But why do you want to do this?” or “What issues are you concerned about with this solution?” These are the questions we need to grow as individuals to create better code that isn’t only it works, but meets the requirements of the business, the user, and the team that maintains the code. Building good software is a team sport.
(I also made a video on this topic: https://youtu.be/AK9pFlLJwbQ?feature=shared.)