Why are senior developers unable to effectively communicate their expertise?

As AI-powered software development becomes more widespread, some argue that if AI can write code, then developers will become unnecessary. On the other hand, senior developers are not simply people who write code; they play a crucial role in avoiding unnecessary development, keeping complexity under control, and maintaining systems that continue to function. Copywriter Tuhin Nair explains why senior developers struggle to effectively communicate their expertise by drawing a parallel between two issues: 'complexity' and 'uncertainty.'
Why senior developers fail to communicate their expertise | nair.sh

According to Mr. Nair, there are two types of senior developers he encounters on his team. One type talks about things like, 'I found a new tool,' 'That company does it this way,' or 'Hacker News says this is best practice,' while the other type asks, 'Is that really necessary?', 'What will happen if we don't do it?', and 'Can't we make do with what we have now?'. Mr. Nair values the latter type, as these senior developers look for ways to avoid implementation, reduce scale, or reuse existing code before adding more code.
Nair likens what senior developers are wary of to 'the monster of complexity.' Because adding special conditional branching, new database tables, or new components complicates the system, senior developers try to confirm 'is it really necessary?' before adding more code.
On the other hand, Nair points out that what business people fear is not complexity but 'uncertainty,' and he explains business by dividing it into two loops. The first loop is when a company puts a proposal or product into the market and receives feedback from the market. In this loop, marketers, salespeople, product managers, and CEOs try to reduce the uncertainty of 'not knowing what has value.' Therefore, it is important to get into the market as quickly as possible and get a response.

The second loop involves the company providing services to existing users and receiving payments. Here, it's crucial to keep the service running and to make it easy to understand, fix, and debug problems when they arise. According to Mr. Nair, these become more difficult as complexity increases, which is why senior developers tend to avoid complexity.

Nair says that in companies with customers, these two loops operate simultaneously. Those facing the market want to 'get it out quickly and get feedback,' while senior developers want to 'keep the complexity down and provide a stable service.' Nair explains that this difference in priorities is why the expertise of senior developers is often difficult to transfer.

According to Mr. Nair, senior developers need to do more than just say, 'We don't want to increase complexity,' but demonstrate their expertise as a way to reduce uncertainty faster. This is where the ability to avoid creating unnecessary things and to reuse existing ones comes in handy.
For example, if you want to collect survey data, you can use Google Forms before creating a new survey function; if you want to check the demand for a new function, you can simply place a button on the existing UI and see if it gets clicked; and before creating a new analytics service, you can start with 'one judgment, one graph, one metric.' All of these are ways to quickly obtain only the necessary responses before building a complete system.
Nair expresses this idea by saying, 'If you're going to bake a whole birthday cake, you might as well put candles on a sandwich.' In other words, if what the other person really wants is to 'celebrate their birthday,' there's no need to bake a whole cake in the first place.
One phrase suggested to convey this way of thinking is, 'Can we try something quicker?' According to Nair, 'quicker' acknowledges the speed the other person is looking for, 'something' indicates that there is another way, and 'try' leaves room for trying something, even if it's imperfect.
Nair believes that AI will significantly increase the speed at which prototypes and code can be created. However, AI cannot take on the responsibility that senior developers bear. If the code written by AI makes the system difficult to understand, difficult to modify, difficult to debug, difficult to teach, or reduces stability, AI is not responsible to the customer.
Therefore, Mr. Nair proposes separating the system into one for quick testing and another for stable operation. The quick testing system would be a 'speed version' used by AI agents, unreviewed generated code, junior developers, and marketing personnel, aiming to quickly create something that can gather feedback from the market. The other system, the stable operation system, would be a 'scale version' refined by senior developers with an emphasis on stability, ease of understanding, and scalability, taking what worked well in the speed version and incorporating it into a reliable form for customers.

Nair says that this approach allows him to respond to requests for ambitious projects by saying, 'We can provide a speed version in three days, and then a scale version in about six weeks.' The client gains speed, while senior developers gain time for observation and design.
Nair likens this to a novelist hastily writing a first draft, after which an editor refines it. He concludes by suggesting that senior developers should perhaps be called 'senior software editors' rather than 'senior software developers.'
Related Posts:







