Even with "just coding", a skilled coder can translate thoughts directly to code more precisely and faster than translating them first to imperfect English.

I still have to find a programming language that allows me to convey all the nuances of my thoughts and considerations only through code (and keep it readable and concise). This is why there there are few (no?) languages that don't allow for comments in natural language.

The original-ish Lisp had no comments I believe. The workaround was a nop "comment macro" though.

I guess it was more common in the card data days where you could write comments by hand on the card.

I know it sometimes feels easier to just implement something than file a JIRA ticket with enough detail to describe what needs to be done.

As I've progressed in my career, I find this to be more and more true. I would say most days I spend only 50% or less of my time writing code. Even when I do write code, the volume isn't huge. The challenges for me these days is in evolving existing systems without disrupting the business and designing and then implementing things that people can build on top of. The work is still very technical but a lot of it involves researching and planning and testing out hypotheses.

Coding is also a part of why coders get paid so well. It's certainly true that software developers have other skills too, but how those skills are distributed among the general population can't be known so long as coding remains an entry barrier for most people.

My experience is that "coding skills" are the intersection of analytical (being able to formulate hypothesis and test them) and language. There's a (small) barrier to entry. That and the lack of any gatekeeping is why we saw the explosion of Coding Bootcamps "become a javascript engineer in 12 weeks". Even tough the great majority of people attending these camps won't be able to write a single line of code at the end of the program, a few will be able to grasp it enough to fill in the blanks on a template for a website or an app.

We also had language models that could generate code out of very precise specifications back in the 90's. They were called offshored programmers. Send an email in the evening and get a .zip file in the morning with code. Sometimes it would even compile!

Engineering is much more than that. It's about being able to formulate, understand and analyze (conflicting) requirements as well as the ability to gain domain expertize as needed. The best example of that is Carmak and binary space partitioning. [0]

To me, what GPT is going to achieve with it's current performance is akin to what compiled and interpreted languages did: You no longer really care about word size, endianness or alignment issues. The compiler takes care of generating the correct assembly for you. Same thing with snippets generated with GPT.

[0] https://fabiensanglard.net/quakeSource/quakeSourceRendition....

I agree that it's not about coding. However, I wouldn't discount the importance of clarity in the way you code.

You might end up writing the right solution, but because you didn't communicate "what", "how", and "why" you did clearly enough, you will setup other developers for failure.

The first hard problem is to understand what to build. The second hard problem is to build it in a way that is clear and maintainable.