This account is a replica from Hacker News. Its author can't see your replies. If you find this service useful, please consider supporting us via our Patreon.
| Official | https:// |
| Support this service | https://www.patreon.com/birddotmakeup |
swiftcoder
- 0 Followers
- 0 Following
- 12 Posts
Former BigTech engineer. Procedural generation and 3D rendering enthusiast. Restauranteur
This account is a replica from Hacker News. Its author can't see your replies. If you find this service useful, please consider supporting us via our Patreon.
This account is a replica from Hacker News. Its author can't see your replies. If you find this service useful, please consider supporting us via our Patreon.
The big one for me is ballooning dependency trees in popular npm/cargo frameworks. I had to trade a perfectly good i9-based MacBook Pro up to an M2, just to get compile times under control at work.
The constant increases in website and electron app weight don't feel great either.
Deal with really big log files, mostly.
If you work at a hyperscaler, service log volume borders on the insane, and while there is a whole pile of tooling around logs, often there's no real substitute for pulling a couple of terabytes locally and going to town on them.
I definitely was expecting "transported" to be some kind of teleportation when I clicked this link. Too much sci-fi!
This is substantially more useful than the marketing fluff in the press release. Probably would have made sense to post this in that thread though
I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
> I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update
I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first).
Pretty sure I also will not be adopting this particular solution, however
Don’t worry, it’ll come back in a couple of months. Not sure if has a timeout, or if it gets reset by app updates, but that checkbox is only sticky enough to gaslight you into thinking it works
Yeah, I'm afraid that's an engineering culture that is thoroughly cooked. Not much choice except keep your head down until you are ready to cut your losses
> 2. 90% of PR comments are arguments about variable names.
This sort of comment is meaningless noise that people add to PRs to pad their management-facing code review stats. If this is going on in your shop, your senior engineers have failed to set a suitable engineering culture.
If you are one of the seniors, schedule a one-on-one with your manager, and tell them in no uncertain terms that code review stats are off-limits for performance reviews, because it's causing perverse incentives that fuck up the workflow.
Never received a phone call at 5am on a Sunday because a bug is causing a valued customer to lose $10k/minute, and by the way, the SVP is also on the line? Lucky bastard