I probably spend too much time thinking about my "unpopular opinions" in coding, looking for like-minded souls who might agree with me that the industry has emphasized some of the wrong thing over the past decade or two, and trying to come up with arguments to persuade smart coders who disagree with me that even where I don't share their intuitions, I understand both sides enough not to be too much of a pain in the butt curmudgeon about it.
Really I might be better off shutting up, getting to work, and pretending that TypeScript is obviously The Right Thing, and OF COURSE testing every line of code as a unit, in a reductionist context free way, carries its weight. I'm well into the back 9 of my career, my best hope is to fend off AI bots (or rather learn to leverage them but hope they don't suddenly become good at big picture, senior level coding rather than extremely helpful junior level bots that are also good at remembering documentation) long enough to stumble into retirement without TOO much a salary collapse. Maybe I should save my unpopular views, no matter how thoroughly rationalized, for my side projects where no one will care if I'm just a overgrown-script-kiddy lone-gun-cowboy/caveman.
So, that disclaimer aside (though there's always disclaimer...)
The number one thing the web UI industry has lost is appreciating simplicity and transparency for its own sake. For a lot of challenges they faced, the answer was get a shiny new toolkit, add in a layer, learn a new specialized syntax. (A reverse of "NIH", not invented here - the impulse is "lets find a toolkit to do this for us rather than trusting our own code") There is sometimes a false simplicity in these tools, a veneer of "use our complex engine humming under this glossy metal hood" - but god help you if the engine goes wrong (or you lazily didn't read QUITE enough of the docs to use it right) and you now have to figure out why its way of solving your problem PLUS a hundred other company's problems isn't going sour and no longer solving your problem.
(At the risk of frustrating one coworker who I might be brave enough to show this to - Tailwind for CSS is one example of a false simplicity for me. I mean, at one level it starts off obviously more complex, needing a build system vs the old day of "use any editor, save, reload in browser" ... and then requiring learning a new set of (admittedly crisper) tokens for CSS properties I already have to be fluent in. But I want to keep talking with this coworker and try to "get" the appeal of it more, I think he sees something in it I should lean into more.)
But I trust enough of my fellow devs will at least acknowledge the idea of simplicity and transparency enough that they'll understand some gripes I got stuck in my head last night.
Lately I've run into some lint rules or code smell guidelines that seem to deprecate comments - I guess the idea is code should be self-documenting so most explanatory comments are a sign things are awry. And then I get hit by lint rules forbidding commented-out code. I mean yeah, I guess grepping through files could be confusing if a TON of your code was comments, but often commented out code is just helpful signposts of where you've been - and where you might want to go again! Comments are right there at hand in proximity to the code in a way commit messages and PR comments aren't, and while you should always debug the code not the comments, I don't quite see why people don't trust comments more.
Another anti-simplicity aspect is over-zealous unit testing. Most unit tests either fall into: you're writing the same functionality twice (i.e. testing for something simple that's like, just right there in the code), or you're testing your mocks more than you're testing you're code. Or you're describing your contract with the outside world but more likely than not describing your implementation, not your higher level result.
And like yeah, TypeScript. TypeScript is an awkward at best syntax, and I think makes it harder to get the gist of code, even as it does better at empowering autocompletion in editor. And I feel like lately I've really been suffering through "oh you said this can be a string or undefined, NOT string or null". I'm not going to live long enough to what to ponder the "correct nature of nothingness" that deeply... but anyway. TypeScript feels less agile. You can't just change some code (and some of the code calling it) you have to change at least one other place to describe it. Like to be there's just this weird seeming contradiction with people who on the one hand seem to hate comments, and want the code to speak for itself, but also don't want the code to speak for itself, they want to make sure everything is in a formalized type.
Anyway. Just my ranting for today. I don't know how much I want to publicize this article, lest I be seen as a old fart pain in the ass about where modern software has gone. But I try to reach out to my fellow "hey things have gotten out of hand. we're not solving that many harder problems than we were 20 years ago, we just have more complex ways of doing so"...
