As someone who used SoftLayer shortly after it was acquired (and it was still pretty much untouched by IBM) - SoftLayer was pretty bad to begin with. And I'm not only comparing it to AWS. It was bad even when compared to RackSpace.
I left Amazon a few years back because this ending was the inevitable outcome. Amazon had a chance to reinvent themselves as the scrappy startup that they claim to want, but instead they went full IBM.
Basically, the management class despises SDE worker class, and thinks of them as overhead. Recent statements by the aws head about chatGPT replacing SDEs is along the same lines.
SDEs are tools that just do what mgmt tells them. mgmt holds the decision-making and all the cards.
periodically there is a whipping (pipping) in the form of a layoff to keep the troops in fear.
I’m curious: what, in your experience, was the root cause of this contempt? Other skilled professions can make decent money as SDEs do. Is it a love/hate thing? Feeling like the tools could easily not need them if they had sufficient gumption and will?
you touch on a raw nerve that could be the subject of a long post.
in summary, the attitude of management in many large companies is that code is just work that needs to get done, and any engineer who can type on a keyboard can do it equally well (cue in ai-coder). so, the smarts is embedded in defining requirements and managing execution of said-code which resides in management.
The problem with this is many-fold.
1) it encourages a culture of top-down decision making including technical decisions and the person making designs is not the one doing the work
2) as tech evolves, the org is unable to catch up since the decision makers are the elite few.
in short, a manufacturing line mentality where the supervisor holds the cards and workers are tools.
It becomes apparent as you move higher up the IC ladder that technical work becomes slightly taboo. And it is precisely because of the attitude that the actual work is something for line employees, not them. This belief is passed down not overtly, but through gentle nudges: "you could fix that in 15 minutes, but is that really maximizing your impact?" Or the ever-present, "but how does this improve your promo packet?"
It all feels like a giant psyop on staff engs to constantly gaslight themselves into immolating themselves to the god of Impact. Little wonder they exhibit much higher rates of burnout: they're told to be responsible for things without the full range of authority.
I was $TOO_OLD when I learned that most of the actual coding on Google's systems was done by L4/L5's.
Agreed. It’s classism institutionalized in MBAs. The managerial class despises low level execution and instead considers strategy to be the most important thing. And they consider workers as replaceable pawns and not partners.
Essentially the problem is that Kafka doesn't have a way of managing acknowledgements on a per-message basis. This means that consumers from Kafka topics are assigned exclusive access on a per-partition basis and the consumer group manager only tracks acknowledged offset of each partition.
As such you end up with a few main problems. The first is head of line blocking, what this means is that if a consumer reads a message from a topic it's unable to process or will take an inordinate amount of time to process it can't move forward without potentially having to replay every message since the problematic message if it doesn't want to risk not replaying a message that wasn't processed correctly. Secondly it means that you can end up with hot partitions if the "cost" of messages isn't uniformly distributed across partitions because load isn't balanced across consumers, i.e there is no work stealing or other mechanism for other consumers to help out processing a hot partition.
Log systems with queue/subscription overlays like Pulsar and GCP Pub/Sub solve this by doing per-message acknowledgement (sometimes referred to as selective acknowledgement vs cumulative acknowledgement that Kafka does) usually by layering a persistent subscription abstraction over the top of the underlying log.
This is in contrast to pure queue systems like RabbitMQ, SQS etc that use a heap or mailbox approach where messages are simply emptied out as they are processed and don't share the log style struction of systems like Kafka.
So TLDR. If you use Kafka like a job queue you will end up in situations where queue processing gets stuck behind a single or patches of unprocessable messages.
The mitigations for it aren't pretty. They either involve building your own selective acknowledgement layer or a series of retry queues that messages are pushed onto using Kafka transactions with a final dead-letter queue at the end etc. Instead either wait for https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A... if you really want Kafka or use something that already does this, i.e Pulsar.
Modern SUVs are mostly not on truck chassis anymore. The body-on-frame breed of SUV is growing increasingly rare. Modern SUVs are a lot closer to larger sedans (for example, a Mazda CX5 is not remotely close to a truck).
Dad with wife, two kids, and a dog here. We are a one car family, and we intend to stay that way due to pretty real parking constraints.
We tried to hold out for as long as we could without an SUV. Ultimately, taking a week long trip with the family became focused around space management, having to play packing tetris and telling my wife "I don't think we have space for the pack and play". Sure we made it work, but it was stressful.
We got a 3 row SUV (3rd row collapses), and the additional space is just fantastic when it comes to packing. And when the cousins or grandparents are in town, the 3rd row comes in handy.
What about a minivan? All of my siblings with kids use them, and I genuinely think you can fit more cargo in them. My parents take the seats out, and use it to transport stuff from the hardware store, it can a bunch of kids, etc.
I recently rented a car for a camping trip, and they only had minivans - we had a ton of room to fit everything. Only real disadvantage is they look less "classy" than SUVs to some.
I don’t own either, but modern midsize SUVs and Minivans (for instance, a Honda Pilot and Odyssey) are essentially the same thing with different styling. I don’t get why folks think minivans are significantly better from an environmental, safety or utility point of view.
Lower clearance mainly, mean lower gravity center, generally more space (not always) and better front visibility (The A-pillar in newer minivans are a bit worse than SUVs, so point for them at least).
Lower clearance is really, really nice. 95% of deathly accidents involve a single car that went out of control, that's why road death increase with the %age of SUVs in a country despite better tech.
Wouldn’t a people carrier have been adequate? I don’t think people have an issue with the desire for interior space for families, it’s more an issue with the unnecessary extra size and weight brought on by the offroadesque styling
I'm not familiar with the term "people carrier", sorry. Is this like a minivan?
If so, many minivans are ~similar in size, weight, and capacity to modern SUVs (not all SUVs are a Chevy Suburban :-)). For example, you can compare the Honda Odyssey to the Mazda CX9 and the specs are actually not too different:
Mazda CX9: weight: 4,409lbs, 199″ L x 78″ W x 68″ H
A minivan allows much easier ingress, egress with large doors. Also, there are no SUVs with 8 seats that I know of. There are minivans with AWD or even limited 4WD. But they definitely carry social stigma and don't look sporty. That's important for a lot of people, I guess.
Also, wheel base and weight are not the best way to compare overall utility of a vehicle.
A lot of modern SUVs are actually pretty similar in specs to minivans:
Mazda CX9: weight: 4,409lbs, 199″ L x 78″ W x 68″ H
Honda Odyssey: 4,482lbs, 205″ L x 79″ W x 70″ H
For us, it mostly boiled down to us needing to periodically drive in snowy conditions. Obviously an SUV is not a magical vehicle for wintry conditions, but 4wd is big advantage.
reply