It would be like if I said plumbing or auto repair is just watching youtube videos and going to lowes. Just because I've managed to do a few simple things, doesn't mean I'm in a position to belittle an entire profession.

That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.

Me too, then I understood that code and programming is commoditized. As long as it works and looks pretty on the outside and it can be sold, it's fair game.

"There'll be bugs anyway, we can solve these problems somehow" they probably think.

Heck even containers and K8S is promoted with "Developers are unreliable in documenting what they've done. Let's make things immutable so, they can't monkey around on running systems, and make undocumented changes" motto.

I still run perf on my code and look for IPC and cache trashing ratio numbers and try to optimize things, thinking "How can I make this more efficient so it can run faster on this". I don't regret that.

That's a dog whistle to find a better company/location.

I then modify the majority of the answer to fit any special criteria outside of the general case I asked, or more frequently, modify the code beyond the minimum viable answer to fit in the test suite/logging framework/performance monitoring/etc that is involved in my platform

Still call it copy and pasting in casual conversation even if there’s not a single line that’s recognizable between where I started in stack overflow vs where I ended up

Own code would be bad but libraries? That's kinda the idea of an abstraction layer.

The idea of an abstraction layer is to make it easier to read and write code that is at a different layer. Many of us write our own abstractions, it's not because we don't understand what its doing.

So many STLs are fucking unreadable. Golang's is the only one where I've actually enjoyed it a bit.

I can think about people who can do this happily. Some of them are professional programmers. Some are self-taught. Some have CS education. Seriously.

OTOH, I'm similar to you. I either re-use my own snippets or read SO or similar sites to get an idea generally how a problem is solved and adapt it to my code unless I find the concept I'm looking for inside the language docs or books I have.

Yes, I'm a RTFM type of programmer.

That said I would probably not look to a third party library to just to simple data transformation stuff. Probably the only thing I do copy almost verbatim from SO are things like Awk/Sed commands that are easy/low risk to test but would take hours to derive myself.

Check out the memoize example. That fails as soon as you pass anything non-primitive but there’s no one documenting that.

What? It's not anonymous, it's still committed by a dev. It can be non-checked and untested, that's true. But it's not any less untested than any other code. If you choose not to write tests for your code, this won't change anything.

The only issue I see with this is it being potentially unchecked. And the solution to that is reading all the code you commit, even though it's generated by AI.

Testing doesn't even enter the picture here, we're at the level of automating the stereotypical StackOverflow-driven development - except with SO, you at least get some context, there's a discussion, competing solutions, code gets some corrections. Here? You get a black-box oracle divining code snippets from function names and comments.

> the solution to that is reading all the code you commit, even though it's generated by AI

Relying on programmer discipline doesn't scale. Also, in my experience, copy-pasting a snippet and then checking it for subtle bugs is harder than just reading it, getting the gist of it, and writing it yourself.

Thank you for putting this so eloquently. This has basically been the sole tenet of my programming philosophy for several years, but I’ve never been able to put it into words before.

It synthesizes new code based on a corpus of existing code.

It looks to me like they're suggesting you use Copilot to write the tests.

> The advantage [...] without me having to leave my IDE.

You're arguing for the convenience, my point was that that convenience creates a moral hazard, or if you prefer, a perverse incentive, to increase the number of lines of code, amount of boilerplate, code duplication, and to accept horrible, programmer-hostile interfaces because you have tied yourself to a tool that is needed to make them usable.

> Ajax post boilerplate

This is an argument for choosing the most appropriate abstractions. The problem with boilerplate isn't that you have to type it, it's that it makes the code worse: longer, almost certainly buggier, harder to read and understand, and probably even slower to compile and run. You could have made an editor macro 20 years ago to solve the typing boilerplate problem, but it wasn't the best answer then and it isn't now.

In the examples, I wish the auto-generated code came with comments or an explanation like SO does. The code I need help with the most is the code that's a stretch for me to write without Googling. The code I can write in my sleep I'd rather just write without a tool like this.

I spend a probably half my coding time testing and digging into those libraries because I don't understand them and because they cause performance issues because nobody on the team understands them sufficiently to make their "high level design and abstract reasoning" accurate.

One problem with the current world of programming tools is that there's no good way to know which libraries are suitable for use when correctness and performance and reliability really matters, and which are only really meant for less rigorous projects.

Perhaps AI should work on simplifying the existing stack first, without breaking the functionality. What about that?

I like abstractions as much as the next person, but oftentimes you can just make due with the exact thing.

I think there is a pro and a con to that approach.

The pro is that there is a meaningful and familiar intermediate representation --- the output of the C pre-processor is still C code. Another example is https://doc.qt.io/qt-5/metaobjects.html

The con is that, well, it introduces a meta layer, and these meta layers are more often than not ad-hoc and ultimately became quite unwieldy. It's a design pattern that suggests that there is a feature missing from the language.

The disadvantage is that making sweeping changes is more work. The advantage is that making sweeping changes can be done incrementally. But the big win with code generators is that all you need to understand what's happening is right in front of you instead of having to mentally unwind a clunky abstraction.

Don't get me wrong if you have a good abstraction that reduces the use of mental registers do it! But you would and should do that regardless of boilerplate.

This is the part where I’ve been entertaining the idea of solving things at a language level (transpiler). It’s a dangerous idea because if we get better tools to extend the language and everyone does it, we’re all going to be fucked.

But I can’t shake the idea that some of our frameworks, if incorporated at a language level, could entirely eliminate the boilerplate.

Maybe that warrants a library, but then you also have to hook that up with the ever so slightly different boilerplate code.

If this 90% of the easy stuff is done for you, that gives you more time to focus on the 10% that matter.

Once we have multiple proven technologies that handle each of the functional areas that we collectively need, then we'll start to find greater benefit in maintenance, bugfixes, and performance improvements for those existing technologies and their dependencies than we find writing additional code and libraries.

You might be right (I haven't met the majority, I have no idea) about "the majority of programmers", but it seems a little rude to assume the person you are responding to is some talentless hack that can only import things off the internet they don't understand.

(Now... you may argue that apis are often badly designed and implemented... but at least they are trying).

There will still be plenty of low level systems programming work. The field is growing, not shrinking.

One impact this may have is that it may make tasks easier and more accessible, which could bring lots of new talent and could also apply downward force on wages. But the counter to that is that there is so much more work to be done.

I'm all for new tools.