willseth
Re:Fastpotify
on Tuesday September 01, 2026 @01:24PM (#49525029)
> each UI element or portion of back-end having a separate dev team
Really takes shipping your org chart to another level
Re:AWS Acquires DuckDB
on Wednesday August 26, 2026 @12:23PM (#49451729)
At Google's size, they're not required to disclose acquisition prices well into the hundreds of millions
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @07:10PM (#46459722)
Read more carefully
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @04:09PM (#46458012)
It literally doesn’t matter unless it impacts users. I don’t know why you would waste time on non problems.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @03:32PM (#46457751)
You gauge with metrics and profiles, if necessary, and address as needed. You don’t scrutinize every line of code over whether it’s “reasonable” in advance instead of doing things that actually move the needle.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @02:19PM (#46457091)
Sorry, you’re not allowed to discourage premature optimization or defend Python here.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @02:05PM (#46456981)
Then you should have written that. Instead you have given more fodder for the premature optimization crowd.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @02:02PM (#46456953)
Good callout on the paper reference, but this author gives gives every indication that he’s dead serious in the first paragraph. I don’t think commenters are confused.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @01:51PM (#46456851)
Knowing that an empty string is 41 bytes or how many ns it takes to do arithmetic operations is not general knowledge.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @12:35PM (#46456065)
Sometimes it’s as simple as finding the hotspot with a profiler and making a simple change to an algorithm or data structure, just like you would do in any language. The amount of handwringing people do about building systems with Python is silly.
Re:Python Numbers Every Programmer Should Know
on Thursday January 01, 2026 @12:10PM (#46455792)
Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.
Re:Speed matters: Why working quickly is more important than it seems
on Tuesday December 23, 2025 @03:34PM (#46369184)
It doesn’t. You’re welcome to do your own research to confirm
Re:We replaced H.264 streaming with JPEG screenshots (and it worked be...
on Tuesday December 23, 2025 @02:47PM (#46368683)
“We didn’t have the expertise to build the thing we were building, got in way over our heads, and built a basic POC using legacy technology, which is fine.”
Re:Speed matters: Why working quickly is more important than it seems
on Friday December 19, 2025 @11:43AM (#46327837)
On a trumpet? A clarinet? No, the motions don't simultaneously overlap. The fingering mechanics are slightly different at speed, but you would still start slow while using the higher speed mechanics and tonguing technique, not jump into high speed practice first.
Re:Speed matters: Why working quickly is more important than it seems
on Thursday December 18, 2025 @09:01AM (#46312765)
Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.
Re:The Connectivity Standards Alliance Announces Zigbee 4.0 and Suzi
on Saturday November 22, 2025 @10:18AM (#46015406)
What’s wrong with Matter?
Re:Removing XSLT for a more secure browser
on Wednesday November 05, 2025 @04:03PM (#45827979)
"[Y]ou're welcome to fork Chromium or Firefox" is the software developer equivalent of saying "you're welcome to go fuck yourself."
Re:Removing XSLT for a more secure browser
on Wednesday November 05, 2025 @04:00PM (#45827949)
It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.
Re:Removing XSLT for a more secure browser
on Wednesday November 05, 2025 @03:53PM (#45827857)
The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.
Re:Why I Code as a CTO
on Sunday October 26, 2025 @02:05PM (#45713929)
This is staff, principal, or even EM scope at many orgs. I have never seen anyone with a senior dev title directly managing juniors.
Re:Advice for New Principal Tech ICs (I.e., Notes to Myself)
on Saturday October 25, 2025 @10:49AM (#45704329)
Maybe you were just bad at management and didn’t know it.
Re:Python on the Edge: Fast, sandboxed, and powered by WebAssembly
on Wednesday September 24, 2025 @02:24PM (#45364157)
You were supporting the tail end of an era that is universally agreed upon as an ecosystem failure. The internet didn't provide a consistent user experience for developers or for users, it generated mountains of legacy baggage, and it was frustrating for everyone.
Re:Python on the Edge: Fast, sandboxed, and powered by WebAssembly
on Wednesday September 24, 2025 @01:24PM (#45363369)
Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.
Re:Dear GitHub: no YAML anchors, please
on Monday September 22, 2025 @11:13AM (#45334591)
I think the main reason you see overwhelming support for anchors is that the existing Actions functionality is typically so cumbersome to implement and often makes it harder to understand a workflow. Anchor syntax is a little esoteric, but otherwise very simple and grokable.
Re:Dear GitHub: no YAML anchors, please
on Monday September 22, 2025 @11:00AM (#45334423)
YAML anchors may be a sharp tool but no one is forced to use them. I have written many verbose Github workflows that would have benefited from using anchors, and I am relieved to learn I can clean those up now.
Re:Cat Aquariums
on Sunday September 14, 2025 @01:36PM (#45241644)
Our vet told us it is far more important that house cats get exercise than any potential frustration caused by a laser pointer.
Re:Testing Bitchat at the Music Festival
on Saturday August 09, 2025 @03:55PM (#44849585)
AWDL isn’t FindMy. It’s mostly for Airdrop and also uses Bluetooth for the initial connection then switches to WiFi for high bandwidth data.
Re:Testing Bitchat at the Music Festival
on Saturday August 09, 2025 @03:52PM (#44849548)
I’m not sure it would since the whole Bluetooth stack is already designed for P2P. Apple’s network is a true mesh though and not point to point. If you share locations with your friends on FindMy using iPhones or AirTags you will get updates via the encrypted mesh network (that includes other peoples’ iPhones) without being connected to a WiFi or cell network.
https://support.apple.com/guide/security/find-my-security-se...
Re:Testing Bitchat at the Music Festival
on Saturday August 09, 2025 @02:30PM (#44848890)
The FindMy network is already doing this at scale with location data. Offline messaging might be too niche of a use case for Apple but surely they’ve considered it.