I never really thought much of any vacuum I’ve ever own until I got a shark one. It picks everything, to the point where you have to be extra careful you don’t vacuum over things you don’t want to be sucked up into the vacuum. It makes total sense, who needs such powerful suction when you can instead just put a roller on the floor to pick things up. Never going back to a suction-only vacuum.
I read Atlas Shrugged recently. I went in not knowing anything about the book or author. I liked it for maybe half way through and despised it by the end. Reading about the author after finishing the book, it had a lot of her personality in it.
Just one more data point but this is what I’m seeing too. The extreme ‘ruthless’ prioritization has stopped and devs (who want it) have breathing room to make the enhancements they’ve been wanting all along. Turns out what is good for AI is also good for regular old school SDLC. All you have to do is say it will make AI more effective.
> One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.
This is a big caveat. I too, regularly find a fix problems that need to be solved. Very occasionally, something big blows up, and I already have a solution in progress. Those are curious, because it reinforces that I’m working on the right things, but also that I was too slow. Other times I fix things that never became a major issue. Is it because I fixed it in time? Or was it never going to be an issue?
Anyways, I’m a staff engineer, so I guess I’ve been able to demonstrate my usefulness well enough, but it’s a constant struggle. The new product features and support for new partners is what gets all the glory. At the end of the day I suppose that it is right for the glory to go to them. It’s important for the business to gain new business and market advantages. I really enjoy ‘greasing the squeaky wheel’ and generally making things run as smooth as possible. Depending on your leadership, this might not be the type of ‘staff engineer’ they are looking for.
I can’t say I know much about kernels, but what you say rings true. It’s not unlike the micro service vs monolith argument. It depends on the use cases, but in a system where the micro services depend on each other, all you have is a distributed monolith. All the complexity and overhead, and none of the benefits. Keep dependencies close.
With any ORM, N+1 queries can be major performance problem. They can be a bit tricky to identify because individually the queries are fast, but when you execute N of them per request, it adds up. It’s worth looking at. You can write units tests that assert the number of actual SQL statements get executed for a given function. N+1 isn’t just a database issue either. I’ve seen N+1 at the cache level too with Redis. The cache layer supports ‘get_many’ and ‘set_many’.
I haven’t stood up a ‘fresh’ Django app in ages, but some things I remember are worth looking at:
* compression middleware like gzip. There is a big scary warning on this, but modern Django has mitigations in place
* how your DB connections are managed and reuse them- I think Django even supports a DB connection pool these days
* serve static assets directly - skip hitting Django for anything that isn’t dynamic
I remember sitting in on a sales meeting early in my career. I kept quiet, but afterwards I complained to my manager that they were selling features that didn’t exist and conflicted with core concepts of the product. My manager told me that was how sales were made. I left the company not long after, I was already disgruntled prior to that discussion.
I’ve seen the same thing everywhere I go. I don’t have the disposition to be in sales, but I periodically daydream of making huge commissions by straight up bullshitting people. There seems to be no downside.
I work in consulting and have been in many projects where the client was sold promises and features that don’t exist in reality. If I had a firm I would have a rule that whoever sells a project worth > $5M would also be responsible for delivering it.
I think there’s a balance to it. You have to meet the customer, and also understand your boundaries. I’ve sold non-existent features that I was unsure if I could deliver, but always solved it since I’m good at smooth talking. I’ll make sure what I deliver brings value, and keep a dialogue with the client. Sales relations are rarely static from my experience.
I was doing contract work last year for a young solo founder, and he promised a feature to a big customer who only signed up because of this one feature. It was a feature he vibecoded and was able to demo in ways that made it look like it was working, when in reality it was a buggy POS. The customer was going to go live on the platform in a few weeks, and this kid expected me to work over my pre-planned holiday to actually get this (frankly rather complex) feature built properly. I told him good luck, ended the contract, and enjoyed my holiday. No time for that BS.
I don’t have great hearing, so I’m not sure I can really weigh in here (thanks punk concerts in my teens). I remember similar arguments around screens and 60Hz vs ‘the human eye’. I think a lot of people, myself included, can easily perceive the difference between 60Hz and something higher- given the right conditions. I would not be so quick to disregard claims of more sensitive hearing.
(I commented on this topic above/below in more detail.) Even with not-so-great hearing you would still be able to identify the difference (ie artifacts are pushed down, not up). Look up articles on the practical limitations of AD/DA converters and why the seemingly counter-intuitive claim that the difference between 44.1 kHz and above is noticeable, is actually a fully industry-accepted practical reality: aliasing, AD/DA lowpass filters, etc.
The human threshold-of-hearing curve intersects the threshold-of-pain curve at about 20 kHz.
Above that frequency (or thereabouts) the sound has to be so loud that it will literally instantly damage your hearing before you can hear it.
This has been replicated across many studies for more than 100 years.
Flicker threshold is completely different. You can’t damage your vision by increasing the FPS, and it has always been commercially desirable to use a lower frequency because that is cheaper.
Would you agree that a trained human could identify artifacts produced by an imperect conversion process? If you lean "yes", then that's your answer: AD/DA is not a Rust function perfectly implementing the Nyquist theorem, it's a collection of physical components many of which introduce artifacts into the audio path. This thread is not about the theory of human hearing, the electronic components are literally imperfect.
They're no more imperfect than the pickups on an electric guitar, the assembly inside the microphone, the circuit in the compressor and everything else in the analog signal chain that exists long before AD happens.
But the central point is that there's no reason to pick on the digital elements in any particular way. Recorded music in 2026 is a pretty good recreation of the original acoustic pressure waves when it is intended to be, but (a) not perfect, even in the pure analog domain and (b) it is frequently not intended to be.
The central point is that AD conversion can and will introduce artifacts. DA process wil intrduce more artifacts. The "imperfect" is a huge range and AD/DA converters play a role in that. We are not talking about "golden cables" bs here, conversion does introduce measurable artifacts in the audio path. The more tracks you record the more artifacts you have. Can everyone hear them? Definitely no. Can they be heard - yes, I can hear the difference between an old Digidesign interface and Grace Design interface.
No, the central point is that the analog signal handling before AD introduces vastly more "artifacts" than the AD or DA does.
In addition, nobody cares about "measurable" artifacts (or rather, they should not). What matters are "audible" artifacts. We have measuring equipment that is vastly more sensitive than human ears (e.g. your recording equipment that can pick up signals far above 22kHz). What's measurable is not particularly interesting - what's audible is.
Artifacts do not sum linearly, because they do not originate from correlated sources (unless you're doing something rather unusual).
Glad you can hear the difference between two converters, but I trust you've tested it in a double blind setting?
Hm, no. The discussion was never about analog artifacts vs AD conversion artifacts. Both are present. And not sure why you use "artifacts", do you not believe the artifacts are real? How can the lowpass filter not introduce artifacts?
And absolutely - I blind tested coverters extensively. Mbox2, Black Lion Audio upgraded converters, UA, Prism.
Note: blind testing is not double blind testing. Scientists evolved double blind for a reason: blind testing doesn't remove bias.
Yes, the discussion was "never about analog vs AD". But my point is that I see little point wasting time on one set of artifacts (in the digital realm) that are tiny compared to those introduced in the analog realm. If there's a mouse and an elephant about to enter your home, you focus on the elephant, no?
The big difference, of course, is that "everyone" has convinced themselves that most/all of the analog artifacts, as big as they are, are somehow "tasteful" or "artistic", whereas the digital ones are just "math errors". I don't think is too helpful.
And look, if lots of people could get through double blind tests and still show they can hear aliasing or whatever the digital artifact du jour is, then I'd say "yes, absolutely, we need to be very aware of this and do everything we can to reduce or eliminate it". But as far as I can tell, this just isn't the case.
This is a more philosophical take… And I totally agree with you. I mix at 16/44.1 just for the record. I do not buy into the idea of gold plated connectors or 96 kHz mixing. My point was never about quality - I can hear the difference (the point!), doesn't mean for me personally > 44.1 is "better" or "worse".
To your main point: yes, all artifacts are just our learned, cultural, developed preferences. In the exact same way major/minor thirds were considered dissonant just a few hundred years ago - it's all a learned perception, not an absolute judgment.
I would go even further, doesn't matter whether people perceive aliasing as a major issue, it's no different from the U47 "warmth". You can't afford this, probably, as a software developer in a way, but at the most fundamental level any sound's - or artifact's - judgment is based on our our current diagram of "sounds nice" vs "sounds bad".
So what should I do if I want to make an app with this functionality? Do I have to tell users to download and run some executable? You can imagine a case where that is a bit riskier than a nicely sandboxed web app with permission to access one directory.
Well there is a permission dialog and you need to select the directory to grant access and common sensitive directories are blacklisted.
A malicious ad would probably have an easier time tricking you into downloading and running an executable, which is something that has actually happened many times IRL. Worry about that before worrying about theoretical exploits that nobody has actually exploited in an API shipped in the world's most popular web browser for the past 6 years.
That isn't how any of these things work, though. This kind of thing needs a permission to be granted by the user and it does not extend to third-party ads appearing on the site that it is granted to (banner ads have, for a long time, been sandboxed in iframes in the browser to prevent such exploits). I wish native applications had this level of isolation from each other.
Apple will never implement anything in a browser that could make a web app as capable as a native mobile app, they are simply too greedy. Firefox typically doesn't implement these things unless they have to because they don't have the resources that Google and Apple do.
Apple is also on the W3C committee that approves new specs, where they abuse that power to prevent any spec that might cut into their app business from moving forward.
Just because a problem is not hard to imagine it doesn't mean that the problem is actually a problem in practice. It is worth asking if there are any signs of it existing for real.
I hear a lot of this "nothing has happened so far" from people who DUI before their first crash and people who use the same password on multiple sites before their first credential stuffing hack
to use your analogy you're claiming that half the population has been driving drunk for years and yet you aren't pointing to an increased rate of collisions on the road. This is not the same thing as an individual doing a dumb thing and getting away with it for a while.
Could it simply be because many use their smartphone to browse the web and of those many have an Apple device and Safari based browsers don't support that API?
It's like the eraly claims that MacOS has no viruses.
No the bad guys jsut didn't care enough because the ROI wasn't big enough
I’ve been very involved with the DNS blocking scene- and it’s extremely easy to circumvent. I always wonder if there are some principled nerds on the architecture side purposely designing things to be easily blocked with DNS blocking. Or perhaps the mercenary nerds are just that inept. Maybe a mix. I also don’t think the numbers of users with DNS blocking are large enough for the mercenary nerds to care about. However, the math for LoE to bypass DNS blocking has certainly changed recently.
It's not. You forget the disadvantage the mercenary nerds have - they do not, and can not, trust each other. So having the same company serve ads as is serving the content can never happen because mercenaries can't resist cheating and so advertisers won't trust them (after being burned way too many times)
reply