foobiekr

If you go back a day or two I'd have said the thing for The Escapist not being willing to put themselves in jeopardy but here we are.

Companies are stupid sometimes.

this breaks select to send and is a terrible reduction in capability.

you can always wrap channels to make them worse and less capable, but your API should expose the more capable option.

exactly.

you can't abstract over channels easily unless you're missing the point of channels.

For literally decades.

Exactly this.

Someday I would like to understand how we got here as a society.

I agree with you that people are noticing that Twitter going back to the size it was in 2015 has not really impacted the product, but it has definitely impacted the business. Musk's handling of twitter has been awesome for correcting his public image.

I think everyone who is honest accepts that Twitter was massively bloated. By the time Musk made his offer, it was 8x the size it was in 2011 and the product really hadn't changed much in a way that required that kind of increase. But Twitter is an awful experiment because of Musk's clownish handling of just about everything.

Without insider information, which I don't have, who knows.

But I will say this:

1. cisco is not a consumer company. they tried with linksys, bailed. tried with scientific atlanta, bailed. no surprise that they bailed on PD.

2. having seen a lot of ASIC acquisitions in my lifetime, which is basically what Pure Digital was - apple knockoff packaging and branding plus an encoder - in my experience tons of startup teams get their first ASIC done, but then totally flub their second (and some of this is the layoff dynamics of how ASIC startups operate on the HW side - unless you immediately start the next chip before finding fit, you have dead weight that you cut). Also, once you show how it's done and have fit, the professionals show up, like Qualcomm, which makes that even harder.

It wouldn't surprise at all if (2) was the culprit.

Flip basically shows up at the same time the iPhone got video. They were dead already and only Cisco didn’t realize it.

Someone knows Qualcomm.

I don’t think most of the coders who end up in glue code positions are actually trainable.

Agree solidly on the gating aspect though.

The problem is that quality hires continue to be rare and at some level you are doing area-under-the-curve reasoning.

This does not honestly seem true for the main sql databases. For everything else, yes, but if people were actually learning databases instead of hiding from them most of the uptake there wouldn’t exist anyway.

Yes, I don’t disagree, I just think in practice they do the job very poorly. I’ve tried many things over the years trying to make this work but honestly have found nothing that works at the high end.

At the low end of engineering, yeah, code reviews matter a ton and do catch bugs even if they’re basically just peephole inspections.

Are there employers that insist on an always on camera in the working area? Who?

In the real world. I’ve been working for large vendors for literal decades and I can tell you outright that you own us if you’re a big customer, even if we are the only vendor in sight, and no one gives a shit if you’re spreading out your business.

This is 100% a natural consequence of the need to make your quarter. A bigger deal is much more influential than a small one, consistently. Sales incentives also do this.

People who have not actually worked in the industry with a solid eye for how this works often think that having multiple vendors is a good answer, but it’s not. Having optionality helps, but in the end it’s all about deal size.

Whenever someone on the projects, I’m attached to tries to create a new service, first I asked them what data it works with, and then I ask them what the alternative to making this a service would be. Usually, by the time we start answering the second question, they realize that, actually, adding the service is just more work.

To me, what’s amazing is that in almost no organization is there a requirement to justify technically the addition of a new service, despite the cost and administrative and cognitive overhead of doing so.

At 30 years of coding professionally in great engineering-focused organizations, and that on top of nearly a lifetime of having coded for myself, I’ve concluded code reviews barely work.

I agree with everything you say here, but honestly it’s quite ineffective. I wish we had found something better than unit tests (often misleading and fragile) and the ability of a qualified reviewer to maintain attention and context that a real review entails.

You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices.

That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance.

I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.

I’m going to start having a seizure if I keep reading this thread because I agree so strongly.

It is painful looking at modern software development. They don’t know the basics and the whole Agile/TDD thing I think was the start of the end because table schema (and every other kind of planning) is not really compatible with agile.

Not having replaced a bulb due to failure for ten years (and to be clear not having replaced an LED bulb ever) is not the same as not having bulbs that are under 10 years old. We have a variety of LED bulbs from 2013 and then others I’ve incrementally replaced either as they annoyed me (heat, in almost all cases) or because I just got around to it (our external security bulbs most recently).

If LED bulbs are inherently prone to failure I’m not seeing it.

I do agree they’re more expensive, even if you adjust for inflation, but as far as I can tell they last forever.

Most large companies. There is a stark difference between the distinguished engineers and the tier below them in terms of asking people to stop doing things badly.

I know of an engineer who built a work queue by having a chain from an app to kafka to a processor to Kafka to a database writer.

Literally instead of a table.

This stuff is everywhere. Microservices made it worse and half legitimized it.

I see stuff like this every day. It is a natural consequence of people who only “develop” by gluing things together. God help them if they’d actually have to write some core function themselves.

This doesn’t work in practice since your costs scale with vendor count and theirs don’t.

In reality being a single big customer for one vendor is far more influential than being a small one with other options.

Qualcomm is the single worst company to work with. They try to negotiate % of revenue deals instead of cost-per-unit deals and they make Broadcom look like Stallman-level open source fanatics.

If you are using Cloudflare DNS, that's why. This comes up frequently, CloudFlare always comes along and gives a vaguely dishonest answer as to why they won't fix it. Stop using 1.1.1.1; if you are using private relay (which implicitly uses cloudFlare) that's why this is happening.

see: https://news.ycombinator.com/item?id=19870415

Felt, GE, Philips. I have ~20 bulbs, including several on dimmers, in the house and have never had to replace a failed LED bulb in ten years.

Are you sure your power isn't bad in some way?

"all" is doing heavy lifting here in a way that distorts the observation the person you are replying to was making.

ORMs basically exist because people doing coding refuse to learn the relational model and want to program with OO instead. Most of the time they are, at best, irrelevant but eventually become expensive, slow, complex and painful. Everyone in coding knows, once they get a lot of experience, that translation/mapping layers are a waste of cycles, memory, and are complex and where assumptions mismatch results in tons of bugs, and that applies to ORMs in partcular.

There's also a ton of optimization savings in doing this. your DB already has to move from media to cache, so why not do the pipelined processing in place where it's cheapest?

Instead, we haul that shit to the NIC, then across the network, then copy it into memory on some server (probably inefficiently), do the operations there, or we have to reinvent this with pushdown functions for distributed databases.

There are many cases where moving function-to-data is the right answer.

I used to feel like you - the non-removable battery thing was annoying, the non-modular flash was a deal breaker, etc.

None of them turned out to matter, at all. What does matter is a solid feel and solid construction and the flash and batteries lasting the lifetime of the product. I'd rather have that than replaceable.

50+ includes half of GenX, many of which are more sophisticated technologically than their successors.

60+, yeah.