Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.
A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.
As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.
Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
You are far too empathetic to them. They should not hold the jobs they have.
These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.
It’s a culture of not giving a shit, that’s the deeper issue.
I had a contract once to save a government website that had serious performance issues, it was so unusable that people preferred to go in-person and wait 4h in a queue rather than try to fill the forms online.
The frontend was in React because the company that got the contract initially used React for everything. The frontend was a 5MB SPA, but it could've been (mostly static) HTML files with some interactivity for forms like TFA. Everyone working on the project agreed React didn't make sense, but we couldn't do anything about it because someone from the government IT department would have to admit they made a mistake. There was no budget for rewrites in the contract. The few times a developer attempted to remove any "React monstrosity" they got in trouble.
Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.
> Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.
To be fair, the same thing happens in private companies. How many UI changes have people gone through that didn't actually make anything better and just made everybody relearn everything? We would have been better of scrapping many of those and let people continue to use what's already familiar, but that too would have to involve someone admitting failure, which is a hard thing to do for some people.
I've used many a government website in the Navy, and they were almost invariably bad, but it had nothing to do with React per se.
A very slow website I can think of had something like 200 GET requests required to load the landing page, and it used Liferay with Material Design Bootstrap. That was closer to the "style at the time". React is the style of this time, but you can write very slow websites in anything, I'm convinced.
I’m curious if - and when - LLMs change this. They’re very good at web apps. And they’re great at rewriting existing stuff. Just give them a well scoped /goal and go get coffee.
Theres lots of open questions about the future of our profession in the age of AI. But, playing with opus and fable, I think the future will be bright for our users. There is no reason any more for teams to put out junk that’s worse than what an LLM can do.
Unfortunately the LLMs are trained on what we've made, and there's going to be a ton more React garbage[1] in the training set than there are carefully-crafted websites like the article describes, so I don't expect a decrease in overengineered, bloated junk. If anything, I predict that the fact that you can shit one out in less time than before will have a different effect: A modest increase in bloat since an LLM won't mind adding a half dozen redundant and competing ways to do the same things in a large codebase, combined with a shorter mean-time-between-full-rewrites.
I think most of us have seen incredibly creaky codebases that are too buggy to be maintained any longer, where we make the hard choice to wipe the slate clean and build a new one.
We might find those rewrites happening every 12-24 months instead of after a decade.
[1] Frontend people, I mean no disrespect -- just that React & friends are (ab)used for nearly every website now, even those which map perfectly onto the "Simple document viewing with occasional submission of incredibly simple form data" model that plain HTML has always been perfect for.
> Unfortunately the LLMs are trained on what we've made
This.
As I’ve pointed out in other posts, I work in two languages: Swift (my main language), for native app clients, and PHP, for backend work.
I have a lot of experience, with each language (12 years for Swift, and 25, for PHP).
My experience with an LLM, is that I get very good PHP, and fairly mediocre Swift. The Swift often looks like fancy tricks, that newer enthusiasts like to demonstrate. Lots of unnecessary threading, and complex, dogmatic, overengineered approaches to simple problems.
I suspect that this has a great deal to do with the availability of high-Quality public repositories. PHP is more than twice as old as Swift, and, by nature, is a much more open language.
It doesn't take that much effort to put guardrails around your prompt to solve problems in a certain way and with certain frameworks and excluding certain others.
Who will be doing that? Only a small minority of developers pre-ai cared to attempt using HTML, so I don’t see them urging Claude to create efficient and lean websites in the future either.
Claude is remarkably good at performance engineering and ports. It only takes one person on your team to ask claude to do a round of performance profiling and tuning. Or ask claude to take your react site and set up a server to render parts of your site as static, cache friendly HTML.
You barely need domain expertise any more. Just ask claude to make it go faster and it will.
In Canada you can't call yourself an engineer unless you have some kind of association behind it; the title holds meaning including partially accountability. Something that is lacking in the tech world. I'm not saying I want to live in that world but also I worked hard for the knowledge I have starting in the IE days of web dev; it was hard earned experience making things work across the web without loosing performance. The idea that we have developers out there now getting paid higher than me that are clueless on how auth works, how the browser works, why css and browsers maintain backwards comparability for a reason.. well it's sad; but good for them I guess?
The behaviours of developers as well being beholden to their managers rather than the craft; meaning not saying No we will not move forward without proper unit tests, or pushing back when business demands quick corner cutting solutions.
Anyway, decades of bitterness. I wish we had associations to uphold some level of accountability on developers as much as protect developers. I think things would be a lot more expensive and slow if we did that though.
Fundamentally I agree with your take, not just on dev side but just the web/dev/produce' a culture of not giving a shit.
Always be a doubled edged sword, why would a startup with an optional product like a fitness tracking app ever rise to level of regulation that requires developers that are beholden to associations to uphold some level of accountability on developers.
A lot of products don’t come close to rising to the level of a government website, industrial control systems, financial transactions, etc. in terms of needing structure accountability.
I use to have an old pentium 2 computer for testing websites. Sometimes you cant make things fast enough for the old box. A fun trick is/was to have <script>elm.textContent="loading images"</script> between each "heavy" section, all targeting the same elm. If the computer, network or server is truly extremely slow you will get a nice message at the top describing what they are waiting for. On a normal slow computer you won't see the messages unless something went wrong.
Junior and midlevel devs aren't decision makers for government benefit websites. The culture of not giving a shit is real, but the responsibility goes far beyond these roles.
If we're talking a government site, chances are you don't have the budget to be able to hire much above junior or midlevel devs. And the project manager probably has a small budget [^1] and little experience with what the web design choices really mean (and what the trade off are).
I think you'd be surprised who ends up making those decisions.
Which goes back to the original point (that's valid for any project) - keep your user in mind. If your users will be using recent-ish iOS or Android devices, use as much flair as you'd like. If your users will be using mass-market low-end devices or used devices from 4+ years ago, then maybe dial down the interface.
Knowing your user is important, no matter what level you're at.
[1] Unless we're talking about some kind of large system that's being redesigned by a consulting company on a cost-plus contract. Who knows how those decisions are made.
Even if this were the case, and I wouldn't be surprised, it's still misplaced blame.
> Knowing your user is important, no matter what level you're at.
I agree, but it's absolutely ridiculous to expect a junior dev to make excellent decisions on this. Software development is a massive industry with no prescribed methods. It's not like these folks are going through a residency before getting the job. Even if they went to uni for CS those programs don't teach these skills.
You'd be surprised, then. Some managers don't know squat. I rolled onto a project once and found that an entire application was being delivered as a 300MB ActiveX control, to run in a browser because that was cool and "cutting-edge" at the time.
Looking at the code, I found it was using UI elements for data storage and other such nonsense. A colleague and I had to tell the manager that the entire thing had to be rewritten. I'm not sure he actually went pale, but that's how I remember it.
It is EXACTLY the type of people that are hired to make decisions, because of either nepotism or impressing with portfolio filled with overcomplicated, 3.js frontpages.
The tech stack is almost always decided by someone in leadership that has no developer experience. Or by the consultant company that will chose the most complicated and difficult to maintain stack because then they can invoice more and will win all future contracts. The trick is to hire someone that is not corrupted by money, someone like the author of this post, who cares more for the users then how much he gets paid.
> These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.
@concinds, you yourself are being too empathetic. I am trying to view these websites on my $2,000 PC on high speed internet, and it still is maddeningly slow.
Most companies actively punish you for giving a shit. The more shit you give, the worse things get for you. Not giving a shit is a form of self-preservation.
New cheap android phones are just as slow as old cheap android phones. The bottom of the market has been stuck in performance limbo for years, and modern web dev frameworks are ill designed to meet them where they are at.
Mobile devices rarely last beyond the 5 year mark, although the age span has been increasing in the past several years and the resale market is booming thanks to inflation, geopolitical instability, and a global cost-of-living crisis.
Oh, I know it's not the point but I find it a bit disingenuous going from iPhone base model to the Pro in the last 3 years and still comparing to the base model Samsung S series. Though maybe I'm missing something non obvious.
But yeah, generally I've seen a better experience buying used phones (in good condition) instead of budget/cheap new ones.
The top two lines are the fastest devices available in the iOS and Android ecosystems each year, and when using Samsung S-series devices, I have made sure to pick the faster of the Qualcomm vs. Samsung Semi parts (both are used historically, but Qualcomm is most prevalent in the US). As explained in the piece, the bottom two lines are taken from representative devices in the mid-range and low-end price categories. There's wild variation in those market segments due to short-run discounting, and the most meaningful uplift in CPU speeds has coincided with 5G radios (for obvious signal-processing reasons). Because the lowest-priced segment doesn't yet feature 5G, those processors have remained stubbornly slow, even if they get cheaper every year.
Thank you for clarifying and sharing the full blog post! It was actually an error on my part because until now I didn't realize that the S-series base model and the Ultra model actually share the same CPU. I should've checked my assumptions first.
I also saw you addressed in your blog post the growing market for refurbished phones and in the last year or so I've noticed a similar thing in Romania where a e-commerce giant is involved with a company that refurbishes and resells old user devices to try and corner a big piece of the pre-owned (second-hand) market where previously you'd be stuck hunting for good deals on the national Craigslist equivalent or searching for small-ish repair shops that sold refurbished devices.
I just had one of these people, a contractor working for a state government, argue vocally with me in a meeting stating that "500 JavaScript requests is not a problem" for a single page. Un-cached, of course, despite there being a CDN in front of the site.
You can't win against cargo-cult coders because they just assume you're from a different, competing cult.
They have no concept of engineering or science, they have never encountered it.
Heh this is one nice thing about doing engineering work in Australia. Our round-trip time to US data centers is often about 200ms. There’s no hiding from sloppy choices in the performance panel.
I had an argument a few weeks ago because our page took 4 serial requests before content appeared. I argued - with solid data - that it should be 1. If we could manage that, cold load time would ~ halve.
> argue vocally with me in a meeting stating that "500 JavaScript requests is not a problem" for a single page
Where's the benchmark or at least the numbers? If not, that's not proof of anything. Nothing to argue about. I'd just laugh.
> You can't win against cargo-cult coders
You don't need to. Unless you're not in control or don't have influence then whatever. It shouldn't be about "winning". It's either some vote (hence influence) or there's a process e.g. PoC with backed numbers.
“The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.” -- Alberto Brandolini
I like to fight this kind of asinine "push back" by simply reversing the time order:
Here's an app that does 5 CDN-cached requests of its JavaScript. Demonstrate why disabling the CDN cache and splitting that into 500 individual requests is better.
I see no reason not to be empathetic. The frustration is fair, but it's aimed at the wrong layer. These people were guided into this spot by bootcamps and curricula that start at React and never go down the stack.
My experience was the reverse. I learned HTML and CSS first, then Rails in college to serve templated pages. I understood the client/server boundary fine as a concept, what I couldn't see was where it actually sat in a web context. I sort of knew JavaScript ran in the browser, but then I'd see ERB templates stamping values directly into script tags, so the server was writing the JavaScript that ran on the client, and my mental model fell apart. Where does my code actually execute? Why does this variable exist here but not there? Why does the page have data the network tab never fetched? Nobody ever sat me down and explained the request/response lifecycle as its own thing. I had to assemble it from fragments over years. This was around 2017 for context.
How you learn something shapes how you keep learning. If your mental model is misaligned, everything downstream is friction. The thing that finally made it click for me was reading the actual HTTP RFCs, which is apparently a weird thing to do, because HTTP itself is absent from nearly every guide and curriculum. Tutorials teach you the framework, maybe the language, and just assume the protocol underneath. These days I make newbies read the MDN docs like a book and skim the HTTP wiki page, learn the history of the protocol. It's short! It's not even a book! That gives you a firm foundation. But if your foundation starts at React, drilling down is like digging past bedrock. People don't know where to start, and Googling only shows them wrong answers because they don't yet know how to ask the question.
Are you sympathetic to a doctor who specialized in surgery and now always recommends surgery, even for a common cold? Or would you say they are in the wrong job, if they are anywhere but surgery?
Ridiculous example that does nothing to argue the original, fair point. Obviously health interventions demand more finely tuned solutions than information technology
FWIW, maintaining at least a moderate degree of empathy even in systemically frustrating situations is good for the empathizer and thus in one’s interest
Kinda sorta analogous to the cloud engineers who can standup complex monstrosities in AWS-land, but don’t know the first thing about how to troubleshoot say a connectivity or simple problem where they have to ssh to an ec2 box and do the needful
well... just because you know how to ssh into the prod DNS host and manually update the prod zone files in vim to remove orphan A records + duplicate CNAME records, in order to fix an ip address exhaustion issue that is blocking new VM's from spinning up for your customers... it doesnt mean that you should, lol.
that was 8 years ago in my first gig. now i kinda wonder... having those skills made it easier to put off implementing a robust long term solution. it was playing with fire, sure, but i was a rookie
>Don't you think they have a legit skill issue here and should they be better off upskilling themselves?
Absolutely agree! Just because I understand how they got there doesn't mean I think it's a good state of affairs ;)
My post was already quite long, and I didn't want to append a treatise on what one should do when encountering those engineers. It depends on many details. Avoid hiring them, if that's a power you have. If you are stuck working with them, depending on your authority, encourage them to learn or force them to learn. If you're coming in to clean up after them... well, hopefully your comp is worth the annoyance.
We are all simultaneously in the position of encountering "the world as it is", understanding it, and doing what we can to improve it.
Why should you necessarily avoid hiring them? You yourself said that they are not stupid. Maybe some of them are very good, hardworking employees. And if all your company needs is a react app, does it matter that much that those people are unfamiliar with building websites without react? Maybe they've spent all their working hours doing work for their employer's company, leaving no time to learn other ways of building websites.
The thing is, people often assume that bootcampers/self-taught devs are only in it for the money and do not "care about the craft", or else they would have studied CS in the first place. But this is not true: There are many reasons why someone could have found their passion for software engineering only later in life. Some of the best engineers I know are self-taught or bootcampers.
Yep. It’s also an attitude problem. A lot of devs are able to up-skill just fine, but some are downright demeaning towards anything they don’t understand, or towards anything that doesn’t come from a FAANG.
In the olden days, people wouldn't take office jobs or factory job necessarily because they thought: "Yes! That's my passion! That's exactly what I've always wanted to do." Passion isn't your first and foremost thought when you have a family to feed.
A few decades ago, IT jobs were for the most part done only by people who were in it for the kick they got out of working with computers. They already hacked at their dad's computer in their early teens (or sometimes even younger), and just could just never let go. It was for people who loved it because it was a niche.
But today, IT is no longer that. It's the backbone of much of our society. And so the field no longer attracts just the die hard fans, the nerds. It attracts ordinary "career people", who just need to have a job to feed the family. Who turn the machine off after 8 hours. Who don't go on coding all through the evening on their hobby project. Who don't try out new tech just for the heck of it.
I think it's hard to understand if you belong to the first group, the nerds, that anyone working in the field isn't like you. Because they all used to be! But those days are gone. We live in the times of enshitification for a reason. If you have the hacker spirit, you don't enshitify because you simply can't. You know what is the right way to do it. Sometimes that's a React app but sometimes it's just an HTML page.
You're not just in it for the money. You care. Not necessarily for the end user, although that would be nice. You care for the tech. And when - like in this article - both come together, sweet things can happen.
I'm not a web developer. I built a few websites in high school, but these days I write safety-critical real-time code for robots.
A few years ago I was back in grad school and I took a class with undergrad senior CS students. We had to write a fairly simple web service, and I was blown away by how complicated they were making it. Based on the requirements we easily could have written 90% of it in plain HTML, but everyone else insisted it should be 100% react. Part of that is honors students wanting to do everything the most complex way possible to impress teacher, and part of it is them simply not knowing that other options exist.
I’ve long thought frontend web developers are the ones most threatened by LLM-assisted programming for a bunch of reasons and now I can add “many don’t understand web fundamentals” to the list.
Yup. It’s exactly like the dismal state of CSS frameworks we're mired in.
All these new kids walk in and learn the CSS framework du jour first, then find themselves stranded when things move on. If they had just learned CSS the first time, they'd be set for life.
Nobody should learn React before learning HTML and vanilla javascript.
Yeah but at least now we don't argue about Bootstrap or Foundation, it's just go with Tailwind.
I still remember when a good chunk of the web took Bootstrap's defaults and ran with it.
That said I've still got a bone to pick with Tailwind but I understand it's a good compromise in a world where BEM and CUBE and other methodologies require more effort up front and if done incorrectly impose a bigger burden.
A few of them would outright not know how to do anything else.
It's like how a lot of people these days reach for an electric drill/driver for even the most simple projects like tightening a screw. It never occurs to them to use a screwdriver, or even a butter knife.
They may not be stupid people, but they are bad at their jobs. One needs to be able to at least try other approaches to a problem, and not have a one size fits all approach. The latter isn't engineering, it's cargo culting.
My wife used to maintain a website for a non profit organization that was just HTML/CSS. After that she started building a lot of stuff in HTML without javascript.
And (now that I'm in management I understand this better than I used to) this problem becomes self-reinforcing. If every candidate out there only knows react and doesn't actually know how to do a simple front-end without it, you need to use React because at some point you'll need to hire someone to replace the person doing it. Even when management understands why the design is bad, if that's what the labor market supports it exerts a definite pressure.
There is a reason we use React today - if you want dynamic and complex site, HTML is PITA to work with. Either you reload everything on any change (not good), or end up with a maze of partial reloads in event handlers (not good either). It was done, it was bad, React (and similar frameworks) was the solution. If you don't need complexity of React, fine, use HTML. But if you do, who can guarantee that 5 min later someone will not start requesting site not to reload here and there, but update this bit here. So I don't blame people for just using React. And in this case the issue wasn't that react was used, but that it was used poorly.
Having gone this route in the past*, once I accepted that I needed a second GPU dedicated as owned by the VM, most issues went away. No SR-IOV battles, just the simplicity of "Linux owns GPU A, Windows VM owns GPU B".
If I am remembering my build from the time, I had an RX 580 for Linux, and a GTX 1070 as passthrough to the Windows VM. At first, it felt like I was "giving up" on solving some problem that felt like it should be solvable, but it worked so well that I couldn't argue with the results.
It also assumes you have a motherboard with the right slots and enough PCIe lanes to get the performance out of two GPUs, and assumes you have a PSU with the power budget to support both GPUs. It definitely was a compromise, not perfection.
*Approx 2017 to 2020, before Proton or when it was was still new/immature. I now no longer care enough about games to play one when it doesn't just work on Linux. I assume the author does not feel this way.
Also worth remembering that all of us had to deal with China attacking Github and taking it mostly offline for quite a while 11 years ago. China used the great firewall of China to inject a malicious script into Baidu analytics javascript files. Every website outside of China that used Baidu analytics wound up serving those infected file to every visitor. All of those visitors were then reloading two Github projects over and over. The two projects were designed to allow Chinese citizens to view uncensored news from the NY Times and from the greater internet.
Never incorporate third party Javascript, CSS, images, etc served from a server within China through their great firewall in anything you do.
In the latter (earlier) case, the Notepad++ issue tracker was bombarded by Chinese spam in response.
The Notepad++ releases have supported other causes too like "Je Suis Charlie", so special releases aren't confined to Chinese topics. Seems like they are concerned about free speech causes especially.
There's also much more to Shopify than just Ruby feature work. I've heard tales of their infrastructure and it seems like it would be very exciting for the right kind of person.
Never worked there, probably never will, but they have my respect for the things I have seen, read and heard.
I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.
If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.
For each of these, a strong test suite was the best tool, which it sounds like you already know?
In my experience, the other impactful factors were:
(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.
(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.
(3) Having a true QA function in the company that isn't just engineers testing their own code.
>one could also expect a functioning city to not have flooded streets
In some cities, certain streets are designed to flood during heavy rain, and are an integral part of routing the water away from neighborhoods and businesses, and into the drainage systems.
>The Times was also in the midst of a leadership transition, and new management tends to want to move on from the old regime’s pet projects, even if they were successful.
Learning about B2B sales over the years, the size of this leadership-change factor has been among the most eye-opening (and among the most disappointing).
It cuts both ways: You can have a successful pilot that doesn't proceed because this-or-that VP was replaced, and to show off their bold new direction, the new VP cancels almost everything novel the previous person started. Or you can reach out just at the moment the new guy or gal comes in, right when they're looking for the pieces of their bold new direction, and you become part of that.
I would love to have later learned that leaders who evaluate opportunities separate from personal attachment are seen as more efficient, better, and selected favorably; that more successful companies are less subject to this sort of political/careerist whimsy. Alas. At least I have been fortunate enough to experience both directions in quantities that roughly balance out.
> I would love to have later learned that leaders who evaluate opportunities separate from personal attachment are seen as more efficient, better, and selected favorably; that more successful companies are less subject to this sort of political/careerist whimsy.
My experience is that it's the opposite: the more successful the company is, the more prone it is to flights of executive whimsy. At more successful companies, it basically doesn't matter what the executives do, because the company's moat is so big that it can tolerate grotesque mismanagement and still make money. (This is the converse of the old aphorism "When a management with a reputation for brilliance tackles a business with a reputation for bad economics, it is the reputation of the business that remains intact."). Executives seem extremely uncomfortable with the idea that they are being paid tens of millions of dollars and yet nothing they do matters, and so they're intent on leaving their mark. Thus, they cancel all the pet projects of the past management, instill their own ideas, and boldly take the company in a new direction. Except not really, because the fundamental parts of the business that make it work are all handled by people 8 levels down in the org chart whose job functions are considered common sense by everybody and never really up for discussion.
At least, this was my experience at Google, which is perhaps the best money-making machine ever invented and yet is grotesquely mismanaged by mid-level VPs that cancel every promising new product that comes out, only to start their own initiatives that themselves get canceled by their successors.
> the more successful the company is, the more prone it is to flights of executive whimsy
Apple's Liquid Glass comes to mind.
The design exec responsible suddenly left Apple for Meta, a company rather less esteemed for design, and Apple still hasn't acknowledged this failure or backtracked.
Bear in mind that they forced the butterfly keyboard for years despite loads of users complaining. It took Johnny Ive to leave for Apple to finally fix the keyboard, that's how powerful the detrimental leadership can be at times.
Yeah I do understand that. It occurred to me right away that getting people used to partial transparency might be explained by the difficulty of doing opaque drawing on heads-up displays.
Apple has strategically retreated a few times but it always puts on a show of doing it in a “forward” direction. Look for much of the annoyances of Liquid Glass to quietly be lost.
This is also my experience at Google, and I have not really figured out the incentives. Plenty of people seem _perfectly comfortable_ with the idea that they are being paid tens of millions of dollars when nothing that they do matters. And it takes enormous effort to get anything actually done in the face of our enormous bureaucracies. I have a few hypotheses:
- Career progression is still a motivation. If there are enough sufficiently motivated people in the organization (whether they come from upper management, middle management, or frontline workers), leaders need to harness that motivation and move it in a direction and potentially dole out career rewards. Otherwise, that motivation that is not properly harnessed can be destructive.
- Similar to the previous hypothesis, they might axed _because_ nothing they do matters. So they may thrash about, making enough noise and movement to convince enough people that they might actually be doing something important, and it would be risky to dismiss them from their position.
- Turf wars/politics/etc. If you do "nothing", then you look replaceable. If you're just a very expensive paper-weight, someone may try to usurp your highly-paid paperweight position. Thus, the nash equilibrium is to do something that makes your position less likely to be usurped by making it look difficult or that you are uniquely qualified to do it.
My job involves service contracts for the cloud. We get to know workloads and optimize them and learn how to troubleshoot them to reduce mitigation time.
I had a big customer go from "must have, non-negotiable" for my team to a non-renewal in weeks when a new CTO came in. Within a month, they had an outage we could have mitigated quickly and had our yearly contract pay for itself.
Having been on both sides of this: Often, one of the purposes of the leadership change was to start shedding the old regime's pet projects. Even semi-successful pet projects can be a distraction from the direction the company wants to go.
I've been unlucky enough to work under several executives who thought they could resist direction from the CEO and board. They pushed their pet projects and thought leadership would eventually see the light. Instead they got ejected from the company and replaced with someone who knew how to follow orders.
My cynical assumption when I first saw this was that it was all just politics, but I have to admit that life is so much easier when your management chain isn't fighting uphill all the time. If the CEO and board want the company working on some things and not others, you're on thin ice if your manager is assigning you to go against the company's direction. It's scarier when you may not even know what they're doing to you.
For this specific case, completely pulling the content offline feels like a loss across the board. I could see it happening as an overreaction, to send a message that the new management is serious about not repeating the (perceived or otherwise) mistakes of their predecessors with an unmistakable signal
I imagine people won't like the comparison, but this is exactly how changes in leadership work for developing countries.
Anyone tied to the old regime that isn't immediately, obviously, and hugely beneficial to the top of the new ranks is scrapped. Business arrangements and government contracts have to be re-negotiated to cut in new leadership. If business owners don't hedge on both sides, and get in there immediately after the election, they become castigated as loyal to the old regime, leading to more friction, costs, and work to simply get back to normal operations.
Depending on the rate difference, I'd be tempted to setup a 'burner' checking account at a separate financial institution and just auto-transfer the loan amount from my primary bank to the burner every month.
My bank's underwriter/loan officer actually said to get the best rate with them to specifically setup an account with them (They aren't my day to day bank) and just use it for my house payment. For the past decade the only transactions it has ever seen has been the direct deposit and the auto-withdraw for the mortgage.
Really? Both times I got a loan they wanted bank statements from all of my main accounts and verifiable income history, but they didn’t care that I was paying from an account that I had just opened for the specific purpose of paying the loan.
I'm not OP, but I assumed from their post that they meant the loan provider wanted Plaid access in order to perform underwriting - as in give us access to your account(s) so we can pull your banking history via an automated manner instead of sending PDFs.
Could be wrong though, as I never considered it'd be used for payments at all.
same. maybe it just depends on the bank, but i can't imagine why that would matter at all. they have the whole picture of your financial history, generally. what does it matter whether that one bank account has only enough in it to pay off the loan every month.
BMO offered the ability to link plaid and some other company to automate it vs me sending updated statements manually. I chose manual. I hate that this is the only option for convenience.
A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.
As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.
Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
reply