[rendall]

I think the main point of the article, to question whether using an IDE actually improves our work, is valuable to at least ponder, if not just as a way to improve IDEs in future. As an aside, I don't think the author steal-manned his argument by using a few illustrative anecdotes, but he's not completely wrong, either.

My objection to the article is to the sentiment expressed:

> "But, a lot of code doesn’t matter because Sturgeon’s Law informs us that 90% of the code is crud. He was talking about science fiction, but it feels true of just about anything. All of that code learning is parroting the bad habits of the 90% crud."

I strive for empathy with my colleagues, and I have mostly* won the struggle against harshly judging the code that I read and maintain, and judging the people who wrote it. Judging code can be a terrible distraction that turns programming from a lovely, interesting and fun task into a grind.

Is it true that "90% of code is crud"? It is, if you want it to be. Or, perhaps we all as a community and a society are slowly learning how to program, and the best of the code written 5 years ago uses ways and means that we are abandoning. I think specifically of the movement away from Object Oriented programming toward immutability and Functional Programming, which is arguably an overall improvement. Also, the No Blame movement, which assumes that the engineer at the time is making a smart decision given all of the constraints. But we're not done, and the code of today will look quaint in 5, 10, 20 years.

It helps me to have "warrior mind", which I interpret to mean that completing a programming task is a mission, and I can feel upset about the circumstances, or I can put all of that aside and help complete the mission (or fail to complete the mission, which happens), without ego or drama.

So, I would say, "90% of code is crud" belies an attitude that would benefit from correction. All code contains a lesson.

[musingsole]

> Is it true that "90% of code is crud"? It is, if you want it to be.

You're being way too generous from a false sense of compassion. Most code is not written from a place of serene comprehension. It's written under the pressure of getting features out the door fast enough to justify a paycheck.

Add in that programming is a task that is rapidly changing over time -- so what's good today, is a naive implementation tomorrow...yeah, practically all code ever produced or ever to be produced will be crap from any reasonable perspective.

[rendall]

Kind of my main point, I just choose not to think of it as "crap", but as the best expression of the coder's intent given the all the constraints at the time it was written, including deadline pressure, context, experience. Try it out. Now instead of "wading through crap" you can think of it as "sifting for nuggets of wisdom". Or whatever you like.

[musingsole]

Alright, I can accept that. We're mostly describing the same thing, and it's a question of focusing on the silver lining -- golden nuggets -- over the rest of the thing, which could be seen as crap or could be seen as the casing of a gold nugget.

Given that framing, what expectation can there be that an automated platform like CoPilot can acquire the wisdom to recognize gold from dirt? I believe it may be a question of does the overlapping, correlated portions of code from the corpus of repos signal the gold or signal the common dirt encasing the gold?

I largely expect it's the latter, and that the trends copilot is likely to recognize and use as foundations for its suggestions are motivated from dirt. To accept them and to learn from them is to internalize a horse without a cart philosophy.