시니어 개발자가 자신의 전문성을 제대로 전달하지 못하는 이유

What do you feel about the following sentence: “AI agents are the future of software development. We won’t need developers anymore to slow down the progress of a business.” If you’re a senior developer and you think this is true, I’m somewhat suspicious of your expertise (I’ll explain why; I’m not needlessly antagonistic). But if you’re not a senior developer and you think this is true, I think you’re probably right. Huh? What’s going on here? Copywriting is, in its essence, about matching a message to an audience. And so, to me, a copywriter, what’s happening here is that the same message is meaning two different things to two different audiences. If you’re a senior developer, and if you’ve played with the agents and skills and models and all the other things that are blowing people’s minds, and if your intuition is still telling you something is off in how people are proclaiming your job obsolete, then here, in this post, I’m going to try and put words to your intuition (as a good copywriter does). But wait a minute! Many seasoned and famous developers are also proclaiming the death of the developer. How’s that? Whose intuition is right? And what’s causing this split? When I join a team there are two kinds of senior developers I meet. The first kind says things like: “I found this new tool and it’s pretty cool ...” “This company <company totally unlike the one we’re in> does things this way, so …” “Here, look at this HackerNews post that says this is best practice, we should probably …” I don’t like this kind of senior developer. A little self-protective, lots of time spent in the industry, probably a good people person. But not my wavelength. Then there’s also this kind of senior developer: “Do we really need that?” “What happens if we don’t do this?” “Can we make do for now? Maybe come back to this later when it becomes more important?” Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. Why? Because they hunt a singular monster in professional software development: complexity. Special cases, if conditions, new database tables, new components. All yuck yucks. The senior developer wants as little of this as possible, spending lots of time making sure they absolutely need to add more code. Because adding to a system is risking more complexity. Yes, yes, of course this is simplistic. There are senior developers who excel at taking on unsolved problems and finding new creative designs. But eventually, if you’re taking responsibility for a working system, you’re scared of complexity. Now, why is that? What’s the downside of complexity? And why doesn’t anybody else get it? We’re going to be simplifying what a business is using two loops. This is the first loop; marketers, salespeople, product managers, the CEO, they all live here: The main goal of this loop is to try and learn. The business wants to take things to market and then get feedback on whether they’ve got something valuable or not. The monster, for people in this loop, is uncertainty. And uncertainty is cruel because no strategy is guaranteed to work. When combined with time (compensation for marketing/sales, or payroll for founders, or data for product managers) it can feel like taking things to market as fast as possible is the only way to reduce uncertainty before a deadline. The more you can take to the market, the more you can get feedback from it, the more you can (potentially) reduce uncertainty. This loop, and all companies start with this loop, is about pure, raw, speed. But what happens when a business gets customers? Ah, now, here’s our second loop. People paying for a service. This loop is where a lot of senior developers find themselves in. The main goal in this loop is the continuation and guarantee of service. Keep things working, keep things understandable, keep things debuggable, keep things fixable, keep things teachable, keep things stable. Senior developers worry about stability because they take responsibility for the business to continue serving customers. And what risks all of that? Complexity. It makes a system less understandable, less debuggable, less fixable, less teachable, and ultimately, less stable. Rising complexity = lowering stability = senior developer failing responsibility = bad bad not nice, payments interrupted, everybody sad. So, if the first loop’s goal was uncertainty reduction, the second loop’s goal is complexity management. But why does this lead to communication failure? Because once you have customers, both loops are running simultaneously. A business needs to both explore possibilities and serve customers at the same time. Ok, now you might be able to spot my answer to the question in the title of this post. Depending on which loop you spend your time on, your problem is framed differently (which is why I think developers get split in their opinions on AI; some work more on one loop than the other) This was the story of the people in the first loop: But this was the story of the senior developer in the second loop: The stories don’t match. The more requests to build and add to the system the senior developer gets, the more the senior developer wants to respond with “uhhh, no complexity … maintenance costs … understandability … speed of continuing development … productivity over time …”. But that does nothing to address the rest of the business’s need for reducing uncertainty. The copywriter’s diagnosis: You can’t explain away someone else’s problem using your own problems. And the copywriter’s prescription: You need to describe your solution as a solution to their problem as well. Senior developer’s fail to communicate because they express their problems in terms of complexity management when they should be expressing their solutions in terms of uncertainty reduction. By acknowledging that what the rest of the company is seeking for is uncertainty reduction, the senior developer can use their expertise to help. And what’s the most useful skill a senior developer has? The reluctance to build what’s not necessary; the ability to spot an opportunity to re-use something already built. Need to collect survey data? Google forms, baby. Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it? Need new analytics service? What’s the most important decision we need analytics for? Can we start with one decision, one chart, one metric? You want to bake me a whole birthday cake? Just put a candle on my sandwich. This is what senior developers learn to do: they learn how to give people what they want by being resourceful with existing software. But how do you communicate this without sending people whole essays? Copywriters love boiling down multiple signals into singular phrases. And so, here’s the magical phrase every senior developer must learn: ‘Can we try something quicker?’ The use of ‘quicker’ acknowledges what they’re really looking for; ‘something’ implies another way of achieving it; ‘try’ implies imperfection, but also the possibility of it being good enough. It perfectly cuts down to the requirement of the rest of the company, speed to reduce uncertainty, while allowing the senior developer to exercise their expertise: reduce, re-use, and if life is truly a blessing, avoid. That’s it. That’s my answer to the title of the post: senior developers talk in terms of complexity when everyone else is worried about uncertainty. But! Big but! AI now seems to make all of this pointless, doesn’t it? Why reduce? Why re-use? Why avoid? The AI can build so much in so little time. Ah, well, it can’t yet do the one thing senior developers still do. Take responsibility. Senior developers care a lot about understanding the system because understanding allows fixing it when things go wrong. It allows extending it intelligently when the system needs to grow. It allows, more than anything, the continued, reliable servic