You're not insightful for noticing a website is dog slow or that there is a ton of data being served (almost none of which is actually the code). Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone.
From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
If a bridge engineer is asked to build a bridge that would collapse under its own weight, they will refuse. Why should it be different for software engineers?
You're not even arguing with me BTW. You're arguing against the entire premise of running a business. Priorities are not going to necessarily be what you value most.
I’ve seen a lot of times where “business people” ask for a feature that sounds good but isn’t technically viable for any number of reasons. The devs not doing pushback would lead to similarly non-functional/broken stuff getting shipped.
The pushback doesn’t even need to be adversarial, just do some requirements engineering, figure out what they want and go “Okay, to implement X in the best possible way, we should do Y and avoid Z because of W.”
In the bridge analogy, the people who are asking for a specific design might not know that it’d collapse under its own weight and the engineers should look for the best solution.
There are environments where devs can't do that sort of requirements engineering and those are generally pretty dysfunctional - obviously you don't need that for every feature request, but it's nice to have that ability be available when needed.
On those sites you’re right: the approach was different, but not necessarily better. Tracking library bloat and marketing-driven design were reduced. But insane “security” constraints (e.g. “you have to stay on outdated revisions of this library” or “containers are not allowed on the backend, only bare metal”, no joke—constraints that led to significant increased security risk) and extremely user-hostile design practices increased, as well as there being an exceedingly long hurry-up-and-wait turnaround time for shipping important fixes/improvements.
Working on a safety/state-critical site isn’t a panacea, in other words.
> From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
this belittles the intelligence of the dev team. they should know better. it's like validating saying "i really thought i could pour vodka in the fuel tank of this porsche and everything would function correctly. must be porsche's fault."
Oh, and the rest of the business doesn't even know what a car or gasoline are!
The blame clearly lies with the contradictory requirements provided by the broader business too divorced from implementation details to know they're asking for something dumb. Developers do not decide those.
Developers often do push back and warn against ideas that have too many compromises, but cannot outright say no just because of that. There are too many other people involved.
You seem to think that any one person/group has/wants/should have full control when deemed necessary. That doesn't make sense unless either the success criteria are lacking (you call the shots alone and probably miss a ton of opportunities), or the requirements are so constrained that all the work is just optimizing the implementation (someone else already called the shots without you).
If your work is either of those situations it means the business plan sucks. AI is the least of your worries.
Failing that, interpret the requirements.
Nobody can watch a bunch of videos at once that don’t even show up until you scroll! That’s a nonsense requirement and the dev’s failure to push back or redirect in a more viable direction is a sign of their incompetence, not that of the non-technical manager that saw YouTube’s interface and assumes that that’s normal and doable.
It is! You’d have to know about lazy loading and CDNs, but neither is black magic.
I suppose you've never experienced the corporate hell that can happen with a CDN. The dev could submit a dozen servicenow tickets only to see half of them rejected by those same incompetent non-technical managers, or they could just make the thing work now and move on.
The next project will be better after the dust settles and those rejections have been reviewed and escalated into proper discussions. Nobody tells the story of that project because it does the things everyone expects. Guess who led those discussions and fought to get the meetings on the calendar? The "incompetent" devs of course!
But hey, if you want to rail against incompetent developers who exist in a make-believe world where they hold all the power are simply too lazy and incompetent to 'do the right thing' then go ahead!
Me: we cant do X bceause it has Y and Z implcations for end users
Manager: It fits our brand and we have to do it.
Dev: I can do it and the implications are mitigated by (handwavy explanation)
Maanger: sounds good. (To me) Maybe you can make a (useless) diagram for this featuer that will be realy handy for KT
--Days later--
Feature is delivered and the Y and Z were ethier not mitigated or there was a attempt-ish to mitigate them
Stop making excuses and start taking ownership and responsibility of your craft.
I work in huge government departments, large financial orgs, and other "enterprise" places that are the poster child for the "realities of corporate environments".
Automatically saying "yes" to everything makes you a useless meat robot.
If you do everything that the customer asks, without push back, negotiation, or at least a deeper understanding, then you will produce broken garbage.
I see this all the time: "The customer asked for X, so I pressed the button!" is the cry of the incompetent junior tech that will never be promoted.
Nobody wants a uselessly slow website. Nobody wants to piss of their customers. Nobody wants angry rants about their online presence to make headline news.
What the customer wanted was multi media content. That's fine. The technical specifics of how that is presented is up to the engineering team to decide. You're not advisors! You own the technical decision making, so act like it.
If you make the decision to shove nearly a gigabyte down the wire to show the landing page, then that's on you. The manager asking for "video clips" or whatever as the feature probably doesn't even know the difference between megabyte and gigabyte! They shouldn't have to in the same way that I shouldn't have to know about my state's electrical wiring standards if I get a sparky out to add a porch light. If my house burns down, that's the electrician's fault, not mine as the customer!
Similarly, if someone asks for lights inside their pool, an electrician that strings ordinary mains cabling through the water should be jailed for criminal negligence. Obviously, only special low-voltage lighting can be used in water, especially near people. Duh.
Act like an electrician, not like a bored shopkeer who's memorised the line "the customer is always right" without realising that the full quote ends in "... in matters of taste."
Some are just flat out refused as they are just too stupid and will cripple the system in some way.
https://en.wikipedia.org/wiki/Conway's_law
Have a wonderful day =3
The responsibility of the devs is to deliver what was asked. They can and probably do make notes of the results. So does QA. So do the other stakeholders. On their respective teams they get the same BS from everyone who isn't pleased with the outcome.
Ultimately things are on a deadline and the devs must meet requirements where the priority is not performance. It says nothing about their ability to write performant code. It says nothing about whether that performant code is even possible in a browser while meeting the approval of the dozens of people with their own agendas. It says everything about where you work.
We always have discussions here about how you have to learn to talk to communicate your value to clients in a language they understand. Same goes for internal communications.
Software development isn't factory work. And factory workers are expected to notice problems and escalate them.
Anyway, they're paying me far too much to have me turn off my brain and just check the boxes they want checked in all situations. Sometimes, checking boxes because they need to be checked is the thing to do, but usually it's not.
We're definitely way past the point where there is a singular definition of what "software development" is supposed to mean.
I also didn't describe anything like factory work.