As recently as 2019, there were still conversations about devs who don’t use IDEs. There is also still guidance that new coders shouldn’t use IDEs.
When I was a dev, the Spring framework was new hotness. Then, and now, there are devs who resist it and other frameworks, particularly those with auto-magical wiring.
Further back, there was a conversation about the lavish nature of Java’s managed memory feature. For C/C++ devs, the idea of not managing memory is like learning someone else will take care of your kids: enticing, but a gross dereliction of duty.
The ideas underpinning these are similar:
- Portability: what if I become dependent on this new devilry, and I must use something new? (an isolated sort, we’re wary of interdependence)
- Visibility: how do I know what the gizmo is doing, and what if I strongly disagree with what it’s doing?
- Control: what if I have a problem that I can’t see or fix because the doodad handled that part?
This last part is probably most salient in the minds of experiences programmers, who remember needing to find the root cause of production issues in time-sensitive situations. When your company is losing a million dollars every 5 minutes, and you’re the on-call, a thoroughly understood control of your software keeps you sane.
This is the backdrop of the industry’s entry to generative coding. As experienced leaders, we can help engineers make the transition by recognizing that their hesitance comes from the things we want: a commitment to their own effectiveness and to business outcomes.
Once you get to the vibe coding, the fear is reduced and the strategies for the above three are:
- Portability: the code is still yours and you can get a new LLM tool started on code written by a different one
- Visibility: you can still read the code and view the execution logs
- Control: you can still revise the code, before and after the agent commits it
References
