I think we should already get past pretending it's about people who just like typing words on their stupid mechanical keyboards. The real split is whether you like understanding systems and inventing new things or whether you are OK to delegate this part to someone else and are just happy to take credit for their success. With a small note that when someone else is a human, the credit can be justified if you mentored them or created conditions for their success and growth.
When one side of the discussion makes their ignorance a point of pride, defining themselves entirely based on what they now need not know, I believe you've inadvertently insulted yourself.
I don't see many on one "side" with prideful ignorance. There are a few loud ones, sure. But I love to see the many ideas I've not had the time to implement come to fruition. I don't get the same satisfaction. It doesn't seem as much "mine" as if I did it all by hand. However once the tool is built, I use it to build more things. More tools.
Not having to know the lower levels means you can free your mind for things at higher levels of abstraction. It's not a void in our brain you don't fill with other things.
I've noticed that too and it's not too different from political discussions. At the end of the day, I think the split is really about different values people have, their identity, and justice.
A lot of developers' identities is tied to their ability to create quality solutions as well as having control over the means of production (for lack of a better term). An employer mandating that they start using AI more and change their quality standards is naturally going to lead to a sense of injustice about it all.
Disagree. I think it was always obvious to me that there are at two kinds of developers. To make an extreme example: developer A writes long, sometimes tedious, security-minded, thoroughly tested code, and has written the CI pipelines too. When tasked with some ticket, they'll develop it to the letter, not one inch further, and even if it makes zero sense from the point of view of the users. Developer B knows nothing of that, doesn't write tests, can't be arsed about security and has no idea of how to deploy stuff, but thinks backwards from what the users (or other developers, or their future self) might like a lot and tries to make that. Both have been useful, though the first kind usually much more appreciated (maybe because it's really essential, while type B's contributions are harder to measure).
Probably AI has come a little bit earlier for type A, but type B will follow soon anyway. In the meanwhile, they're enjoying the ride a bit more since AI takes care of all the tedious but essential details.
That has become pretty controversial recently, but I think the difference is that in software development, building knowledge is the work. You write software and simultaneously build expertise in your team regarding what the software does that allows you to maintain it and move forward.
Part of figuring out where the pieces should go is usually in trying to put them in, because you generally can’t visualize the complete solution in your mind just by looking at all the pieces and only thinking. I don’t think this is a good analogy.
Puzzles have a correct solution that is known in advance, the pleasure consists in the work you do to reach it. It's a bit different when the solution has a beauty in itself.
How about people that understand things are changing whether anyone likes it or not and want to stay relevant. What about the people who care about the end product and not rabbitholing design decisions on a proof of concept. What about someone who understands there is more nuance than assuming people with a different perspective on AI are lesser than or lower than people who resist the technology. You may feel you know the “right way” but to everyone else who is interested in operating in a world changing beneath our feet and not whining about the fact that everything will be different, and denigrating the people who want to succeed in it, this opinion is not exactly convincing. You want to cludge your way through a problem you’re welcome to but it’s not necessarily logical to suggest this is the only “right” way and infer that people who build with AI don’t like “understanding systems”.
When I build with AI I build things I never would have built before, and in doing so I’m exposed to technologies, designs, tools I wasn’t aware of before. I ask questions about them. Sure I don’t understand the tools as deeply as the person who wasted like 10 hours going down rabbit holes to answer a simple question, but I don’t really see that as particularly valuable.
