[RsAaNtDoYsIhSi]

"Where exactly is the skill to know good code from bad code supposed to come from?"

Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Also Teaches you how to convert procedures into analytic solutions into numerical solutions aka a single function that gives you an answer through determining the indeterminate of an inductive reasoning (converting a series, procedure or recursive function into an equation that gives you an answer instead of iterating and being dumb.) Networking. (error checking techniques, P2P stuff) Compilers. (Dragon book.) Math. Linear Algebra. (Rocket science) Abstract Algebra (Crypto stuff, compression) Theory of Equations (functional programming). Statistics (very helpful). Geometry. (Proofs).

Taking all these classes makes you smart and a good programmer. "Programming" without them means you're... well. Hard to talk to.

I don't think you need to write any code to be a good programmer. IMHO.

[CoinFlipSquire]

I feel like this answer is reductive. It's not just having a bunch of academic syntax. You need reps. You can't seriously be suggesting that reading about a skill is equal to practicing a skill. The skill was never about the syntax in the first place.

Also again, this logic only works on absolute greenfield project. If you write enterprise code in large organizations, you also have to consider the established architecture and patterns of the code-base. There's no book or usually cohesive documentation to that. There's a reason a lot of devs aren't considered fully on-boarded until after a year.

If you leverage the LLM to write the code for you. Then you never learn about your own codebase. Thus you cannot preform good code review. Which again is why I say reviewing code while never writing code is a paradox statement. You don't have the skills to do the former without doing the latter.

Even if you're take was that typing code into a keyboard was never the main part of your job then the question is ok what is it? And if the answer was being an architect then I ask you. How can you know what code patterns work for this specific business need when you don't write code?

[timmytokyo]

Exactly. Programming skill, like most human skills, is acquired through practice and repitition. You can't become an excellent programmer by observing other people (or LLMs) doing it. That's like arguing you can become a master musician by reading sheet music or watching live performances by other musicians.

[GeoAtreides]

bait used to be believable

(i.e. I don't think that's your honest opinion and you're just trolling)