If I'd come here in when React was the new hotness and criticised it, I'm pretty sure I would have been shouted down.
In the meantime this one site I worked on, which used Java for server side rendering¹ with a bit of JQuery and custom scripts is still going strong.
1: It's ridiculous to hear JS people say how awesome server side rending is when basically every other language used for the web was server side, sometimes decades before it.
Wasn't this a bit of a self deprecating summary of his own career?
Many of the comments seem to assume that it was written by his colleagues and that the description of his career is condescending or snarky.
Personally, I find it really funny, and that it probably describes many of us, despite the fact that we think we are way too cool to ever be like the character described in the piece.
Most of today's new tech will become tomorrow's 'legacy'. Imagine how your awsum multi lambda hairball deployment will look in 30 years. (If it's even around in three decades.)
This is how it should be on salary. If you're good enough then you can get time back from the job and work less per week. It starts to look crazy good when you are doing like 5-10 hours per week because you're so familiar with a code base and have a decent understanding of the business. If they aren't going to give meaningful raises for doing maintenance, then time is the only thing you can get more of.
If companies want people to work harder, they'll have to give more compensation that scales better with performance.
Geez, this was just basic street smarts when I was growing up. Ask some questions upfront.
Have cash on hand when dealing with taxis. Don't assume card terminals will work, or even that they won't skim your card.
You may say, 'That's why I hate taxis cos they scam you,' yet this thread has contains many examples of Uber(Eats)* scamming people too.
Why is that better? Cos it's accessed via smartphone for some reason?
Conjecture/Rant: There is a growing cohort of people who want everything to become 'frictionless'. They are even afraid to just talk to people, talk to girls, everything has to be through text or through an app. If they get their way humans will start to interact with each other more like machines than like people, hey, maybe even through APIs! Meanwhile, what makes life interesting 'is' friction between people and cultures.
Yea - And those darn kids play music too loud too!
I grew up in the suburb where there were no taxis. I live in SF, and we can’t call a taxi without an app. I visit NYC once a year. Plenty of people (esp immigrants from other cultures) don’t have “street smarts” that match what some urbanite 30 years ago would have. I tried taking a taxi from JFK last time I was in NYC. The driver claimed he didn’t know where my hotel was, or even the neighborhood (“Chelsea”). They stopped in the left side of the highway to spit out the door. They pretended not to take cards, they added on fees not in the original agreement, etc. If I’m gunna be scammed either way, at least let me use google maps to put in an exact address and pay by card.
Wanting frictionless commerce is not a character flaw geez. An app is way more convenient. I can talk to people “IRL” but some things are easier with an app. Getting a taxi to pick me up is easier with an app that knows my current location - that’s a good product development not an indictment on the next generation.
> Yea - And those darn kids play music too loud too!
I sure hope so.
> I visit NYC once a year. Plenty of people (esp immigrants from other cultures) don’t have “street smarts” that match what some urbanite 30 years ago would have.
Ironically, the immigrants probably have more street smarts.
> The driver claimed he didn’t know where my hotel was, or even the neighborhood (“Chelsea”).
And you rode with him anyway? Why would you do that?
Reliance on Apps to intermediate everything is bullshit in my opinion. Plus I personally specifically don't want to share my location with some app written by people I've never met who are 100% likely to either misuse it themselves or to sell it to someone who will.
When they want to take your freedom away, they won't come jackbooting in with rifles, they will do it by offering you convenience.
I can navigate around my city effortlessly, but I’m not someone-else’s-street smart. Don’t expect me to know the rules in Tokyo, NYC or Rio. I don’t expect a Japanese person to know the NYC, Rio, or SF rules and I don’t expect a Brazilian to know them either.
I rode with him anyways because all this people on hacker news told me using an app instead of a Taxi would mean I would lose my freedom. I have him an address… which he put in an app that surely is the exception and doesn’t misuse it. Realistically, this taxi driver just didn’t want to drive to Manhattan during rush hour, and knew damn well where Chelsea is. We all knew this was the reality. But at the airport there’s a queue for taxis and he was next in line and had to take me.
I actually took a taxi instead of Uber because in NY they use regulatory capture to ensure they have better airport placement than Uber and I chose that “convenience”. I think Uber is way more freeing than a taxi because I can go to almost any metro in the US and get a ride without having to learn the local system. It’s a tap away. It’s way more freeing and has emboldened me to explore more than I might otherwise. That is freedom.
> Reliance on Apps to intermediate everything is bullshit in my opinion. Plus I personally specifically don't want to share my location with some app written by people I've never met who are 100% likely to either misuse it themselves or to sell it to someone who will.
Have you tried taking a taxi in a country where you didn’t know the language?
How many different countries and phrase books only takes you so far. I know barely enough Spanish to almost get by. But I wouldn’t have wanted to depend on it when I was in Los Cabos for three weeks staying in a hotel and I definitely wouldn’t have been as comfortable going around Mexico hailing a cab and giving directions as I was with Uber - and also needing cash.
Giving them an address for pickup works as well as a location based tracking and allows you to tell them to meet you 5 blocks away if you are on the move when you call.
The driver didn't know the neighbourhood nickname you gave..did you give them an address? You have to searching the map on Uber anyways, did you search your google map for the address?
Taxis will go down the streets you tell them while you drive. Turn left or right next lights work. It's more flexible than ubers pre determined route.
Immigrants have more street smarts than you give them credit for. They literally uprooted their lives from places who generally scam more than the places they move to. They have taken a scammier cab ride before they even left their home country.
> The driver didn't know the neighbourhood nickname you gave..did you give them an address?
They asked for the neighborhood not the address because that’s how pricing is determined. When you’re a taxi driver… you learn the neighborhoods. Especially one of the most well known neighborhoods on manhattan.
> Immigrants have more street smarts than you give them credit for.
I mean no ill towards immigrants. Immigration is scary and hard. But being “street smart” in a different city doesn’t always translate directly. They’re not expected to know that they’re about to be scammed! They shouldn’t be getting scammed!
> Giving them an address for pickup works as well as a location based tracking and allows you to tell them to meet you 5 blocks away if you are on the move when you call.
Or you can just put a note in the app when you order and send messages. They can also call you.
If you don’t speak their language, the Uber app does translations.
> Immigrants have more street smarts than you give them credit for
When I spent 3 weeks in Los Cabos, Mexico. I had no street smarts, I didn’t know the language and when we were stuck in traffic, Uber automatically sent calls because it noticed we weren’t moving.
No. It's 2023. You're expected to take credit cards like it says on the little logo on the window. If your credit card machine is broken, your Taxi is broken and you can't pick up fares unless YOU tell them ahead of time that it's cash only.
If this happens to me I simply tell the driver I don't have any cash and exit the vehicle. Now if you have luggage in the trunk this of course gets a little more complicated. Somehow the credit card machine amazingly comes back to life as I'm getting out.
> Why is that better? Cos it's accessed via smartphone for some reason?
No, at least the ideal is there's a functional reputation system for drivers and riders. Of course, if corporate is going to scam you, too, and if they're going to make less than 5 stars a death penalty for a driver, and if the app and payments are always buggy, then /shrug it all stinks.
Cab drivers are the real ones getting scammed, unfortunately, and rarely have any way of recourse. When paying with card, they are rarely paid in a timely manner, if they get the proper amount at all. This is even before uber made medallions worthless. When I was growing up, it was a matter of common courtesy to use cash in situations like that, where you know the employer is going to play games with the employee when you pay with card, like a cabbie's fare or a waitress' tip. As we got older, most of us who worked in service industries & survived on tips knew this the hard way because we were also a victim of wage theft via skimming tips, etc.
I'm glad my city isn't allowing certain businesses to go completely cash free for this reason. The push to force credit card payments everywhere just hurts a class of people that are already vulnerable.
This incredible scope creep in the customer's responsibilities (not just price, but I somehow have to adjust for a vague sense of the employer-employee relationship, for ethical/ESG considerations, etc. etc.) is just... overwhelming. I shouldn't be responsible for your employment relationship, that is between you, your employer, and the relevant regulatory authority.
Yes I totally agree. When businesses push for going cashless, they are often doing it to claw back the tips customers are giving their workers.
Tips that have become customary because it's become accepted that a waiter mustn't be paid a living wage. Why has it become accepted, because we have a hidden caste system.
But the customers get to feel cool to frequent a place that 'gets it' because cash is or old people.
The so-called 'hidden caste system' that has tipped employees at the top of the F&B food chain, earning significantly more than back-of-house staff like bussers and chefs?
Yeah, exactly the same caste system. I didn't say only waiters were in a lower caste. This kind of bullshit is everywhere.
Some establishments pool the tips (cash ones) and use to distribute it to the bussers (don't know about the cooking staff). Obviously this was not a universal practice.
> I'm glad my city isn't allowing certain businesses to go completely cash free for this reason. The push to force credit card payments everywhere just hurts a class of people that are already vulnerable.
And forget about the vulnerability of the merchants who have to worry about being robbed.
I don't believe this. I think that the real reason that cab drivers don't want to accept credit cards is because they don't want to pay taxes on the money like everyone else has to. Sorry buddy, your inability to evade taxes is not my problem.
I refuse to believe that not cheating people by default, and not expecting others to cheat me by default, is synonymous with acting "more like machines than people". What a cynical, depressing world view.
That comment wasn't about cheating it was about the communication medium. I.e. communicating via text or app vs. face to face. I.e. talking to each other like we're computers instead of face to face like people.
> It can produce plenty of insights, but insights almost never lead to change.
Insights by themselves can't won't lead to change, but they can be a starting point.
Look at it this way, say I am overweight and want to get in shape. The insight that I need to eat less and exercise by itself of course won't make me immediately fit.
But that insight combined with work and support might.
Also therapy, to me isn't about self improvement, it's about feeling better in one's skin. Often it not that the presenting problem even goes away, but that the way you relate to it changes.
> Look at it this way, say I am overweight and want to get in shape. The insight that I need to eat less and exercise by itself of course won't make me immediately fit.
> But that insight combined with work and support might.
Putting aside the fact that your example isn't actually an insight (diet and exercise as a way to lose weight is also something you hear suggested from every corner, although with more justification), the "insights" produced in therapy are supposed to lead to change largely on their own. That is, it's assumed the client already has all the resources needed but, poor dear, he's held back by flawed beliefs, which therapy is supposed to undo. Needless to say, this has little resemblance to reality.
> Also therapy, to me isn't about self improvement, it's about feeling better in one's skin. Often it not that the presenting problem even goes away, but that the way you relate to it changes.
Putting aside the fact that this kind of contradicts the first part of your post, where you argue for how therapy can in fact help solve your problems, sorry, this is pure cope. Changing the way you relate to a problem, in that sense, or reframing, is talking yourself into believing something bad isn't actually that bad. Auto-gaslighting with a therapist's assistance, really. I prefer to solve my problems instead of trying to trick myself into thinking they're not what they are.
>Putting aside the fact that your example isn't actually an insight
So put it aside then, and think of your own better analogy. It changes nothing from the point I was making.
> the "insights" produced in therapy are supposed to lead to change largely on their own.
No one has believed this in a long time.
> I prefer to solve my problems instead of trying to trick myself into thinking they're not what they are.
So do I but sometimes things break, permanently.
I can't bring dead people back to life, if I'm injured or disabled by an accident I can't 'fix' that, but I can find a way to change how I relate to that unfix-able problem. This goes beyond re-framing, of course.
As to childhood experiences and trauma, they are real and often elicit means of coping which later become ingrained habits which can cause dysfunction later on.
Therapy can help you recognise these (insight!) and then start you on the long slow path of unlearning them so they don't cause you problems anymore.
> scientific endeavors revise themselves when they learn that they are wrong
Exactly. And scripture is notably not revised when it is found to be wrong. I ask, which worldview should you trust more based on this observation?
I felt that the article is written is a style typical of conspiratorial literature, i.e.: presenting lots and lots of evidence for a false or straw-man claim.
The true message of the article seems to be buried in the subtext. they mention the cost of therapy (to the individual and to society) and they mention churches too.
To me it reads like this: I don't want to pay for your expensive psychotherapy through my insurance. Go to church instead (where, depending on the church, we might also get a chance to fill your mind with our regressive version of christian values.)
> Exactly. And scripture is notably not revised when it is found to be wrong. I ask, which worldview should you trust more based on this observation?
Clearly the scientific one. I think we're in complete agreement here, and that's why I highlighted that part of the article. My point was that it seems laughable to raise issues with therapy while presenting church as an alternative.
The sentence you quoted was directed at the other commenter's seeming implication that homosexuality's removal from the DSM is somehow an indictment of the psychiatric discipline (maybe I'm misreading them, hoping I am).
> The sentence you quoted was directed at the other commenter's seeming implication that homosexuality's removal from the DSM is somehow an indictment of the psychiatric discipline
There must be some logical fallacy named for this. I've often seen this critique in terms of pandemic policy. ("Why should you believe what you're saying, when you've changed your mind before...")
> This was very different; prior to that I used to do 1-2h of strong cardio or lifting activity a day, was studying at multiple universities and worked multiple consulting gigs.
I'm going to suggest that with this intense pace this might have happened one way or another. Take it from someone who has been there.
When we push too hard for too long, and ignore our bodies and minds pleas for rest, at some point the body is going to put the brakes on us.
I don't think this is necessarily COVID specific, my speculation is that long COVID is the kernel around which the fatigue episode crystallised, and thatif it hadn't been COVID it would have been something else.
My theory is that as COVID depletes a month-worth of NAD+ in like 3 days, it leads to energetic deficit throughout the body, and the weakest links start failing first. So I assume I had some predisposition coming from my intense lifestyle and COVID just initiated the domino effect. I wish I knew about NAD+ prior to that, I might have skipped it altogether if I resupplied it right away.
Interesting theory but I wouldn't be so sure. I've been through healing journeys where the websites suggested all sorts of deficiencies and supplements, but in the end I came to believe I just needed to slow down.
We know that COVID depletes NAD+ reserves and NAD+ is the main electron transport molecule in the body (second one is FAD+ in some cells in the brain). So if you suddenly run out of electron transporter, it would inhibit most of your systems, making you tired all the time, and the systems that are already operating near their maximal capacity will start failing. This might kick off a chain reaction that is later transformed into condition we call long covid. It would also explain why it is different for each person as everyone has different organs in bad shape and why people with certain organ damage have similar symptoms.
I can speak from experience having gone through a healing journey where the online sites promoted a single supplement as the cure.
I later felt that this focus on this 'replace lost nutrients' approach, while it might have had some merit in the acute phase, also kept some people in denial of the factors which led them to their health crises.
And this is why I hate having to deal with AWS. Learning this stuff isn't technical knowledge, it's product knowledge.
I read the TCP/IP illustrated series cover to cover and learned that stuff cold, and this was useful knowledge to me for decades.
However I always find myself resisting learning this AWS stuff, which is just as complex in its own way too. This diagram makes me feel that if the goal was to simplify things, then I'm not sure how successful they were at that.
> if the goal was to simplify things, then I'm not sure how successful they were at that.
Maybe if they have other goals that are tradeoffs vs. simplicity, then it's more understandable?
What if another goal is allowing enterprise customers to recreate a virtual enterprise network? Or a virtual data center network? Those are much more complex than a client TCP stack.
The defaults are simple for simple uses. And yes, for those complex cases, you'd need AWS specific product knowledge, but most of the underlying concepts are shared in common with other clouds and on prem networks. Like learning your Nth programming language.
AWS used to be not only sane but elegant: every instance had an entirely-arbitrary internal/private IP address, some could optionally have a second public address, and which instances (including external IP addresses) could talk to which other instances was entirely and solely defined by security groups (as well as, of course, any OS-level firewalls that you'd generally disable), which were pretty much just flexible and reusable firewall rules where the concept of a "security group" replaced entirely the concept of a "subnet", which became an obsolete legacy concept.
They needed to support multiple adapters per instance, which they later added (maybe with a separate security group per adapter, which they might support now but I don't know off-hand); and they also needed hierarchical security group inheritance (the same way traditional subnets can nest into each other), which they didn't add but I guess you can now simulate them (though this sucks and I think is part of the downfall of the elegant stack) using multiple non-hierarchical security groups (which was not supported originally: security groups were permanently fixed in a one-to-one relationship with an instance).
This original elegant cloud-first model of instances and groups made network engineering pleasant for once... even fun! I remember thinking how great it was that all of my arcane physical networking and routing knowledge might soon be obsolete: that I could now think in terms of the abstractions of instances and how they talk to each other, drawing abstract circles around them without having to think about limited address spaces, and that they would assuredly fix the only two shortcomings of the original model...
...but then the network engineers showed up in force and ruined it all. There is simply no good reason for all of this VPC IP-address subnet focused insanity once you go cloud: they are just re-instating all of the frustrating limitations that come up when doing real world network engineering, presumably because they weren't willing to throw away their knowledge and realize all of that stuff is obsolete.
Like, seriously: we want to be able to replicate some enterprise network? That's madness, and it makes it all worse for everyone that this is even a supported goal. This is all virtualized networking: we don't need to be thinking in terms of subnets and gateways, we don't need to be manually configuring our egress... if you have a ton of hubs and routers and have to run cable all over the place, it makes sense, but this is the cloud!
And so now we all actually had to brush off all of that networking knowledge I was happy to give up as Amazon deprecated and fully removed "EC2 Classic" and have forced us all into this VPC insanity; and maybe if you never really tried to grok how AWS worked 15 years ago when it wasn't pretending to be a pile of legacy networking equipment you just shrug and accept that this somehow is all necessary, but it really isn't.
>...but then the network engineers showed up in force and ruined it all.
I've never met a single network engineer who had anything good to say about any of the cloud networking environments. I have met a bunch of network engineers who were told by management "go recreate our data center network in the 'cloud'. We're moving everything there over the next 18 months. No, we aren't going to re-factor any of our apps in the process."
That's why all these kludges exist in AWS and other public cloud environments.
On the flip side, the unnecessary AWS complexity is a great make work program for developers. You now need an army of developers (and AWS "architects") to make a truly complex behemoth that fully replicates the insanity of a 50 year old enterprise system. A system of such complexity no single person can understand it all, all changes take days to weeks to make, and its behind black boxes everywhere. That's progress.
They recently launched https://aws.amazon.com/vpc/lattice/ which basically feels like EC2-classic emulation layer on top of VPC. which is a funny full circle but it works.
What they need to make are standards. Then it becomes technical knowledge for civilisation and not just single-company product knowledge. It would be great if cloud companies made cloud networking standards. I mean big competitors used to collaborate and make standards before but all that has petered out over the last couple of decades.
I thought the other goal was to make it easy to get in but very difficult to leave so you are practically forced to keep using their services. Customer capture.
> Learning this stuff isn't technical knowledge, it's product knowledge.
Not really, and mostly I think you're looking at it through the lens of a different field. TCP/IP is going to be the knowledge useful to your network programmer. One of my college courses was networking: we covered networks, subnets, route tables, routing protocols (such as RIP, OSPF, BGP), NAT, etc. We did all this on actual hardware, and the course was heavily sponsored by Cisco (so much that by the end of the semester, you were CCNA certified). In that vein, yes, I picked up a lot of "product knowledge" on how Cisco products behave, 95% of which I've probably forgotten. But that was to give us hands on experience, and the underlying concepts translate well into Azure, AWS, or GCP. These cloud VPCs are mostly virtual analogs to the real deal, much like how VMs are analogs to a real machine. If you understand a real machine, a VM (and associated resources like cloud disks or NICs) aren't going to be that mysterious.
In particular, NAT confuses the living daylights out of people. But, that's almost to be expected. More down to earth, many eng struggle with CIDR notation, or even — but this gets back to your stuff — TCP (e.g., they think that a send() will send the passed buffer as a unit, or that a recv() will always receive a full "message" of some sort; most eng struggle to understand the difference between connection timeouts and peer resets, and when one can happen and the other cannot).
The dark side of this coin is that I really wish I didn't need a lot of this knowledge; it is a lot of junk. IPv6 makes networks so big that a lot of network planning and subnet sizing and "will it have enough room to grow but also not exhaust the range?" just goes away. NAT can die in a cold icy hell. If I could never see another VPN in my life, that'd be cool. (Just use TLS, for the love of everything dear.) I could also do away with cloud firewalls using IP addresses as a form of auth, and delivering misleading errors when triggered. (Azure is horrid at this.)
(I do hope that most products are technically simple enough to not need much of this knowledge. If you do TLS, you shouldn't need to be doing VPCs, non-default route tables, network peering, etc. I'm in a field where we integrate with a lot of people who have no desire for technical simplicity.)
I share this perspective. Most boxes in this diagram are AWS names for a thing existing in normal datacenter or TCP/IP networking. I am an old schooler who personally never worked a lot with AWS, but I think this is pretty clean.
I think it's a boiling frog scenario. AWS's goal is marketshare, not simplicity. Like many professional software products, it started simple by necessity and then grew more complex over time. In AWS's case it ballooned pretty quickly due to the compelling nature of fully-managed on-demand infra services and the huge amount of resources Amazon poured into it.
The value add for not having to directly interact with hardware is still pretty high, but you definitely pay a price (in addition to the sticker price) for it in terms non-transferable vendor-specific knowledge.
Yep, it would be nice if they had used standard terminology. Example: a "virtual router" that you could configure (with internet, NAT, connections to other VPCs, firewall rules, etc.) Instead, you have all sorts of one offs: "internet gateways", "NAT gateways", "egress only internet gateways", "transit gateways." We're going to wind up with a whole generation of engineers that only understand "cloud" and not how things actually work.
My suspicion is that they have distinct names/skus because (a) they're billed differently (b) they represent different security choices. If I grant a developer's account the ability to create "virtual router" entities, that means said developer can do all kinds of things I may not approve of. If I grant them only the ability to create "Internet gateway" entities, I know exactly what I'm getting into and (more or less) what I should expect the bill to be for that
I do agree with you that having a separate "egress-only Internet gateway" for IPv6 is dumb and confusing. I'm sure there's some number of pizzas which explains this Conway's Law instance
Undifferentiated heavy lifting. Companies don't have to train their engineers and find talent that requires deep knowledge of tcp/ip and hardware routers and clean up the mess when they leave and maintain them. Offload all of the "undifferentiated" components to AWS and you focus on what you are good at, your business.
The big 3 work very hard to make sure you’re learning their product so you can advocate for it (because it’s what you now live and breathe) and sell it to others.
Who needs a marketing team when you’re making everyone a “tech evangelist” for your product.
In the meantime this one site I worked on, which used Java for server side rendering¹ with a bit of JQuery and custom scripts is still going strong.
1: It's ridiculous to hear JS people say how awesome server side rending is when basically every other language used for the web was server side, sometimes decades before it.