Interesting Garry Tan piece.
Reminds me of a conversation years ago – and several since. A colleague reporting to myself and another manager simultaneously found herself conflicted. As an engineer whose job had nothing directly to do with producing software products, she announced she was doing a course on coding (some variant of C, back in the day). Not asking specifically for funding or time off, just a bit of leeway and acknowledgement for her initiative. We needed tools and, whilst she / we never envisaged she’d be producing the tools we needed, she’d be better placed to understand the process of getting them delivered against our needs. I was game, but the other manager told her that coding was skill she didn’t need and more or less (publicly) instructed her to drop the course.
Regretted several times myself not learning coding, beyond noddy script-editing stuff. Increasing understanding of processes you need to manage is obviously part of it, but often we’ve concluded that producing a working prototype of what was needed, is much more effective than writing a comprehensive specification between engineer and developer, at either the individual or inter-organizational level. (If software is your business, interactive, iterative prototyping “agile” methods have been the rage for some time, but those for whom software is “merely” an enabler of core business could learn a thing or two.)
(The counter argument, really just a call for balance, is not to have the hobbyist hacker “secondary” developer get too far into the product process before you have an unsustainable, unmanageable, mill-stone of a product on your hands.)