If the dev pool of 2022 was like the dev pool of (for example) 1994, just larger, you would have been right. But the software goldrush came and attracted many more who were just in it for the money or just weren't as thoughtful. Scale matters, upscaling people is hard.
I'm not sure the ratio is that different. In 1994 how many different browsers, connection speeds, phishing scams, competitors shipping fast forcing you to do similar to stay competitive, accessibility considerations, etc. If memory serves, it was dramatically less than now.
This thread of comments is kinda weird to me, there's like a romanticized view of old timers or something, and the problem must be the young, money hungry and unenthused. It feels like boring old internet gatekeeping and is not insightful.
There is a totally different world in tech now than in 1994. Tons of stuff and often optimized for mean time to recovery. I crave quality too (believe me) but I think shipping fast and breaking a few eggs (not directly but that's essentially what you're left with) is what is asked of engineers in 2022.
All of my peers seem to care about quality and we do our best but even in the days of buying software on floppy disks, bugs existed.
The scope of problems being solved is much higher. Adding a two or three libraries- jquery and a plugin or two- and not giving a toss about performance was indeed easy. Few auxiliary tools were required.
Back then, we all could have a pretty strong hand on the wheel of our websites & how they functioned, at a detailed level. It was feasible, for the scope was small. But now, we all use package managers, we all use bundlers, we all use minifiers, we all use production builds, we all use tree shakers. Any one of these concerns is a significant realm that tends to have significant people-years worth of work poured into it. The need for these capabilities distances the practitioner from the core truth of the media: we no longer see clearly what we are doing, we no longer have personal stake or control in the processes.
There's still a strong latent desire to re-simplify, to de-configure the web, to de-build it. We had hopes that EcmaScript Modules would help, we had hope HTTP2 Push would be a viable delivery platform, for un-tooling, but we never really made an earnest go at tackling the optimization problems that all brought in; works like Cache-Digest never de-facto materialized or got made-available. Front-end architecture similarly has been dominated by high-abstraction top-down frameworks, namely React, which complects in a wide host of assumptions/abstractions that distance the practitioner from the actual media-form. Just as ESM was a hope that we might get back to understandable, without lots of framework/tools, WebComponents too presents a hope that we can strip away a lot of the specific complexity & find a more inter-modular, general & understandable grounding. The web can & should be at a similar power level to where it is, more so, but in more honest, accessible, direct manners than the crafted-of-necessity deep layering we cobble with today.
> and not giving a toss about performance was indeed easy. Few auxiliary tools were required.
When the internet came through a modem and bandwidth was very expensive, performance was concern #1. So pages were kilobytes, not multi-megabyte monstruosities.
> When the internet came through a modem and bandwidth was very expensive,
That effectively ended in the mid 00s. Otherwise we wouldn't have had services like YouTube.
Between those times and around 2012 there was an explosion of script bloat because back then it was more important to have an interactive page than a fast page.
Bandwidth resurfaced as a concern only with the proliferation of mobile devices.
The whole premise of tree shaking, introduced in 2012 was to reduce bloat.
which of the techniques that i listed that are common now dlwere possible then?
we did indeed squeeze a lot out of the code we wrote. and we were very aware of js performance issues- using array.join religiously instead of concatenation was a big one. but most of the modern techniques & concerns simply werent appplicable or possible.
the shift from writing it ourselves to loading dozens or hundreds of modules came quite late, all told. that lead to the explosion of performance tools & techniques.
I've got a strong suspicion that there would be more productivity if the bottom half of developer (or more) left the industry. Control for seniority, of course. The majority of 1Xers produce outright bad code, contribute disproportionately to tech debt, don't read user stories thoroughly, don't test their code properly, and generally get in everyone else's way.
The most productive thing our industry could do is create an anonymous blacklist of devs to avoid and code samples of their shit work.
Really? I think the most productive thing the industry could do is get rid of developers who drastically overvalue their own work, methods, and ideas, haughtily dismiss the value of others’ contributions out of hand, and blame everyone else for a project’s shortcomings. You can usually ID them by their persistently rolled eyes, big fish in small pond mentality, and 1.9 septillion reputation on Stack Overflow.
you're both wrong. the most productive thing would be to grow up and help bring the better out in each other. create an environment thats about the skill. set aside ego and focus on building something wonderful. but doesn't seem that's gonna happen soon. (i dont really like bigtech, but the "blameless" culture seems like it could be very productive and save many a dramatic exits)
I wouldn't be so fast to dismiss the previous answers, although I think they're a bit snarky. There is indeed a larger number of developers that is necessary on lots of projects from influential companies lately, and this heavily affects the architecture and the outcome of those projects.
The goal isn't to "build X" anymore, it's to "build X but with N engineers", with N being multiple times the minimum amount needed. This affects how tools are built. They're built "to scale", and this trickles down to smaller companies too. This also affects how software ends up looking, meaning custom GUIs and widgets all the way, even when it's not necessary.
After working in a couple Unicorns where the investors asked for larger headcount, and a short stint in a FAANG, that's my experience.
Maybe there are a ton of unqualified developers in SV playing Wordle instead of coding? I have no idea. The vast majority of software projects aren't managed by FAANG or Unicorn companies. The financial landscape in those companies is completely detached from reality and not a good basis for comparison.
> Maybe there are a ton of unqualified developers in SV playing Wordle instead of coding?
Maybe there are, I also have no idea. But in my experience most engineers are qualified and hard workers, even when there is team bloat. Companies are hiring well. It's just that they're hiring too much.
> The vast majority of software projects aren't managed by FAANG or Unicorn companies. The financial landscape in those companies is completely detached from reality and not a good basis for comparison.
But this happens on several industries, not only FAANG. Most companies that get off the ground with a skeleton crew will start hiring more as soon as they get more cash, doesn't have to be from investors. That's because they want more things faster. The reality is grimmer, though: 9 women can't make a baby in 1 month. And 9 women can't also make an adult-sized baby in 9 months.
It sounds like I struck a nerve. Does it hurt you knowing there are a lot of developers out there that contribute more in a week than you do in several months?
Software engineering has huge ranges of salary. Not only do I doubt you get paid the same, but I also doubt you get paid as much as my best performing lead engineers.
Agreed, I'd argue the even higher meta problem is that we're afraid to hurt feelings.
Because there is such a big drive for growth and more bodies, we have to tip toe around crap work and crap work ethics. Nothing wrong with being a bad dev perse if you accept it and learn to improve. But instead we ego stroke juniors and poor quality developers, inflate their contributions, inflate their title and then wonder when everything is shit at the end of the day. Those poorly trained juniors and boot camp devs are now eng managers, CTOs and loud evangelists that are driving our industry into the gutter with billions of funding.
Hmm, just need to fork it and call it "Nopilot" (though personally I find Copilot to be sometimes handy, it makes plausible guesses when I am doing something repetitive, I'm sure that's because my code isn't DRY enough etc. but it saves me a little time)
