I fully concur, we've automated away the enjoyable and creative part of the job. I used Windsurf for a project recently, and while it was impressive, I don't feel I was notably more efficient at delivery. I often had to intercede to refactor what it had churned out to make the solution legible.
My takeaway was that AI coding is a fairly joyless experience, you're effectively writing JIRA tickets for it, and the labour switches to coaching and PRs. It feels like we're just accelerating the speed at which we build legacy code bases, which no-one will understand.
I've been following some kid on TikTok who started last year on this journey - and it's been truly frustrating to watch. I tried to discourage them from leaning so heavily on AI, but they insisted it was a different way of learning.
A year later, and they still don't comprehend for loops or conditional blocks, and believe that comprehending this basic material is a deep understanding of code.
>Do you equate freedom of speech with "abuse, harassment, and harm"?
Almost anything in CURRENT_YEAR can be interpreted as "abuse, harassment, and harm" by someone. Is saying "fuck Christianity and fuck White men" abusive, harassing, or harmful? What if Christians and White men interpret that as harmful? Will they take that down?
>Were these activities you wanted to perform in order to sign up?
Again, something as benign as "men cannot get pregnant" was a non-issue fifteen years ago. Now, that makes you a transphobic neo-Nazi.
That would probably more likely get you a polite correction on that type of forum. Partly because it's kind of a niche argument but mostly because it only invalidates the beliefs of the women who want to be men, who are often sidelined by their own ideological movement in favor of the men who want to be women.
By contrast, if you wanted to express some other truths that pertain to the latter group, such as "'trans women' are not actually women, they are men who desire to be women" or "there are a significant number of 'trans women' who 'identify' as women because they are men with a sissy porn fetish", then all their fury will be unleashed upon you. Even if you back it up with evidence and solid argument.
I'm very dubious of anyone resorting to "readability" as a justification.
What you're doing by breaking things into functions is trying to prevent it's eventual growth into a bug infested behemoth. In my experience, nearly every case where an area of a code base has become unmaintainable - it generally originates in a large, stateful piece of code that started in this fashion.
Every one who works in said area then usually has the option of either a) making it worse by adding another block to tweak it's behaviour, or b) start splitting it up and hope they don't break stuff.
I don't want to see the "how" every time I need to understand the "what". In fact, that is going to force me to parse extraneous detail, possibly for hundreds of lines, until I find the bit that actually needs to be changed.
> What you're doing by breaking things into functions is trying to prevent it's eventual growth into a bug infested behemoth
Not every piece of code grows into a bug-infested behemoth. A lot of code doesn't grow for years. We're biased to think that every piece of code needs to "scale", but the reality is that most of it doesn't.
Instead of trying to fix issues in advance you should build a culture where issues are identified and fixed as they come up.
This piece of code will be a pain to maintain when the team gets bigger? So fix it when it actually gets bigger. Create space for engineers to talk about their pains and give them time to address those. Don't assume you know all their future pains and fix them in advance.
> In my experience, nearly every case where an area of a code base has become unmaintainable - it generally originates in a large, stateful piece of code that started in this fashion
In my experience it gets even worse with tons of prematurely-abstracted functions. Identifying and fixing large blocks of code that are hard to maintain is way easier that identifying and fixing premature abstractions. If you have to choose between the two (and you typically do), you should always choose large blocks of code.
The great thing about big blocks of code is that their flaws are so obvious. Which means they are easy to fix when the time comes. The skill every team desperately needs is identifying when the time comes, not writing code that scales from scratch (which is simply impossible).
As stated elsewhere, if you're using a component based UI, this isn't a problem. You're also free to mix regular CSS with Tailwind.
As for the "git gud" school of CSS, should we also abandon React, Svelte and the like and revert to hand-cranking DOM manipulation like it's 1999...?
Sure, if you're manually editing a large volume of .html by hand, Tailwind is bad news, but given the plethora of static site builders out there (brief shout out to Astro which is excellent), manually authoring individual .html pages seems like masochism.
I think this is about the level of abstraction. As React component extraction is to tag soup, so named functions composed are to fp primitives. In code reviews, if I see a big swamp of pipe/fold/cond etc at the top level, I'd kick it back and ask that to be wrapped in a named function that explains what it does, rather than exposing it's guts.
Writing concise, clear code is a skill that straddles any paradigm.
I agree! Why would you use OTS tools in any DIY project? I'm going to make my own hammers, nails, drills etc - and anyone who does use store-bought tools probably doesn't know the first thing about building.
Or they just want to get the actual job done and don't see the value in cobbling together a homebrew solution, instead of using a library maintained by skilled devs with excellent documentation, battle tested in thousands of applications with a huge community of users and articles for support.
I used PS and many other 3D graphics apps commercially for over 10 years, Gimp is sadly not a patch on it. UX is a thing, and Gimp doesn't have that. As a now software engineer, I can see the thought process behind the application, but it's workflow is treacherous. I switched out to Affinity a few years ago, because PS became too bloated/heavy, and Gimp just doesn't cut it for real work imho. I mention this because it was easier to pick up Affinity after a couple of hours than wrestling with Gimp. Same goes for Blender Vs Max/Maya. I hate to say this, because I would like these tool to be more accessible to all
