It's as if software developers secretly hated their jobs and found most tasks a chore, so they hired someone else to poorly do the mechanical tasks for them, while ignoring the tasks that actually matter. That's not software engineering, programming, nor coding. It's some process of producing shitty software for which we need new terminology to describe.
I envy you for retiring. Good luck!
To you. For others, it looks differently. And for yet others, they don't care about the coding nor the reviewing, they want to solve a particular problem.
I'd probably say I'm a programmer by accident. It's not that I love producing binaries by writing and compiling code, but I need to solve some particular problem that either is best solved by programming, or can only be solved by programming. "Programming by need" maybe is a fitting definition.
Doesn't mean I don't care about code quality, or good abstractions and having a reasonable design/architecture. But I'm focused on the end goal, having a particular problem solved, and coding is just the way there (sometimes).
Which is fine, don't get me wrong. But that would be like if someone wants to work as an automotive engineer, but they only enjoy driving a car. It doesn't work that way. You should enjoy the entire process of manufacturing a car if you want to drive a good one. Sure, you may enjoy some tasks more than others, and this is fine, but you can't ignore the ones you don't. Otherwise you're only doing a disservice to yourself, your team, and the users of what you build.
> Doesn't mean I don't care about code quality, or good abstractions and having a reasonable design/architecture. But I'm focused on the end goal, having a particular problem solved, and coding is just the way there (sometimes).
But coding is just the mechanical part of building software. It's the last step of the process after everything you mentioned is taken into consideration. Everything else is how you ensure that you reach the end goal successfully. So saying that the end goal is your main focus doesn't make sense if you want to actually reach it.
This is why I think that people who enjoy vibe coding today, are not, and will never become software engineers. They want to fast track to the end goal by jumping over the parts that are actually important. Blindly accepting whatever a code generation tool spits out if it passes a quick manual happy path test is not engineering. It's something else that produces much inferior results. At least until these tools get much, much better at it, which still seems far away, and unlikely with the current tech.
