Yeah; I've long argued that software should be divided into two separate professions.
If you think about it, lots of professions are already divided in two. You often have profession of inventors / designers and a profession of creators. For example: Electrical engineers vs Electricians. Architects / civil engineers and construction workers. Chefs and line cooks. Composers and session musicians. And so on.
The two professions always need somewhat different skill sets. For example, electricians need business sense and to be personable - while electrical engineers need to understand how to design circuits from scratch. Session musicians need a fantastic memory for music, and to be able to perform in lots of different musical styles. Composers need a deeper understanding of how to write compelling music - but usually only in their preferred style.
I think programming should be divided in the same way. It sort of happens already: There's people who invent novel database storage engines, work on programming language design, write schedulers for operating systems and so on. And then there's people who do consulting and write almost all the software that businesses actually need to function. Eg, people who talk to actual clients and figure out their needs.
The first group invents React. The second group uses react to build online stores.
We sort of have these two professions already. We just don't have language to separate them.
The line is a bit fuzzy, but you can tell they're two professions because each needs a slightly different skill set. If you're writing a novel full-text search engine, you need to be really good at data structures & algorithms, but you don't really need to be good at working with clients. And if you work in frontend react all day, you don't really need to understand how a B-Tree works or understand the difference between LR and recursive descent parsing. (And it doesn't make much sense to ask these sort of programmers "leetcode problems" in job interviews).
ChatGPT is good at application programming. Or really, anything that its seen lots of times before. But the more novel a problem - the more its actual "software engineering" - the more it struggles to make working software. "Write a react component that does X" - easy. "Implement a B-tree with this weird quirk" - hard. It'll struggle through but the result will be buggy. "Implement this new algorithm in a paper I just read" - its more or less completely useless at that.
If you think about it, lots of professions are already divided in two. You often have profession of inventors / designers and a profession of creators. For example: Electrical engineers vs Electricians. Architects / civil engineers and construction workers. Chefs and line cooks. Composers and session musicians. And so on.
The two professions always need somewhat different skill sets. For example, electricians need business sense and to be personable - while electrical engineers need to understand how to design circuits from scratch. Session musicians need a fantastic memory for music, and to be able to perform in lots of different musical styles. Composers need a deeper understanding of how to write compelling music - but usually only in their preferred style.
I think programming should be divided in the same way. It sort of happens already: There's people who invent novel database storage engines, work on programming language design, write schedulers for operating systems and so on. And then there's people who do consulting and write almost all the software that businesses actually need to function. Eg, people who talk to actual clients and figure out their needs.
The first group invents React. The second group uses react to build online stores.
We sort of have these two professions already. We just don't have language to separate them.
The line is a bit fuzzy, but you can tell they're two professions because each needs a slightly different skill set. If you're writing a novel full-text search engine, you need to be really good at data structures & algorithms, but you don't really need to be good at working with clients. And if you work in frontend react all day, you don't really need to understand how a B-Tree works or understand the difference between LR and recursive descent parsing. (And it doesn't make much sense to ask these sort of programmers "leetcode problems" in job interviews).
ChatGPT is good at application programming. Or really, anything that its seen lots of times before. But the more novel a problem - the more its actual "software engineering" - the more it struggles to make working software. "Write a react component that does X" - easy. "Implement a B-tree with this weird quirk" - hard. It'll struggle through but the result will be buggy. "Implement this new algorithm in a paper I just read" - its more or less completely useless at that.