sethhochberg

l’altro ieridiscuss

The real takeaway for projects and companies should be that someone having historically behaved in a logical and responsible way doesn’t guarantee that they’ll continue to do that for forever.

Good security architecture has circuit breakers, even for people who are generally high-trust.

sethhochberg

3 giorni fadiscuss

I’m one of those people. Wore watches regularly through my mid 20s, completely fell out of the habit as I spent more years working from home and my routine around “getting ready for the day” loosened, and the Apple Watch was the thing that got me to put something on my wrist again - until I got sick of the screen and kept wearing watches, but now analogue ones.

sethhochberg

4 giorni fadiscuss

The concept of "tool building" is one of the areas my team has spent the most time coaching our less-technical employees on since widespread LLM rollout in our company.

Developers and developer-adjacent, technical people tend to think this way on their own... but every business has dark corners where repetitive, manual things still happen. We're leaning a lot on training and even org-wide LLM instructions to try and let the LLM (by its own assessment) be the vehicle use to codify a process and turn it into some good old-fashioned reviewable, deterministic automation.

sethhochberg

6 giorni fadiscuss

Honestly whipping up a lexer/parser and a REPL is one of my favorite ways to learn a new language. You can cover a lot of ground in a "real" language by just doing the frontend implementation of your own made-up language grammar and a little eval loop and its great for learning/teaching because you don't get bogged down in trying to solve some actual problem.

Which is to say: no shame in just settling for that simple C backend!

sethhochberg

24 giorni fadiscuss

Whats implied there is that the "human touch" will become a luxury.

I have a hard time seeing a future where retail doesn't bifurcate even further into ultra low margin, happy-path optimized megastores and concierge-style high touch boutiques. Places like Crutchfield that split the difference nicely seem to be a dying breed.

sethhochberg

mese scorsodiscuss

Even in a relatively open organization where conversations and work are public/discoverable by default, there's still a huuuge difference between the level of curiosity required to join a convo happening in the office kitchen while you're waiting for a coffee to brew vs needing to spend your idle time at work discovering places (Slack channels or whatever else) to chime in while hoping you're not a distraction for others.

I'm a pretty staunch defender of remote work for most roles, but outside of the smallest companies where the entire organization is on a single conversational thread, you really do lose the organic peripheral vision that comes with an office environment and deliberate effort is required to try and recreate some of that in your fully-remote org if you want some of the same upside. Even with deliberate effort, I'm not convinced you can match it perfectly.

sethhochberg

3 mesi fadiscuss

Corporate software in general is often chosen based on the value returned simply being "good enough" most of the time, because the actual product being purchased is good controls for security, compliance, etc.

A corporate purchaser is buying hundreds to thousands of Claude seats and doesn't care very much about percieved fluctuations in the model performance from release to release, they're invested in ties into their SSO and SIEM and every other internal system and have trained their employees and there's substantial cost to switching even in a rapidly moving industry.

Consumer end-users are much less loyal, by comparison.

sethhochberg

4 mesi fadiscuss

Manufacturers themselves generally don't want to sell directly to consumers: consumers are fickle and need support and have questions and sometimes want refunds or returns and if you sell directly to them, you need to have the staff and policies to deal with all of that. They're also located all over the world, and you might not want to deal with figuring out taxes and duties etc for shipping your product around and figuring out your warranty obligations everywhere you want to sell.

Much easier if you can sell wholesale (sometimes via distributors) to a retailer or network of retailers, and the retailer is responsible for owning the customer relationship, dealing with their part of import/export, local regulations, etc. Retailers are businesses who will buy hundreds of your product at a time, can accept it as palletized freight, and pay you via bank EFTs instead of credit cards.

There are notable exceptions to this model like Amazon's FBA system, but they're the outliers. I'm sure we can all point to inefficiencies in legacy product distribution networks but they solve some real problems.

sethhochberg

4 mesi fadiscuss

I think its at least as much of a working environment preference.

Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.

I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.

Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).

sethhochberg

4 mesi fadiscuss

High-protein everything is riding the wave of GLP-1 popularity right now. Doctors are begging people on that class of drugs to chase protein targets more similar to what might have previously been reserved for heavy weightlifters just to prevent muscle wasting.

As a result, the entire packaged food industry is pumping up protein numbers and marketing it as the primary attribute of the food (where they might have previously marketed low fat or low sugar or whatever else in the past).

So, saturated market... but certainly one people are investing in now.

sethhochberg

4 mesi fadiscuss

I don't have many regrets about having spent my career in (relatively) tiny companies by comparison, but it sure does sound fun to be on the other side for this kind of thing - the scale where micro-optimizations have macro impact.

In startups I've put more effort into squeezing blood from a stone for far less change; even if the change was proportionally more significant to the business. Sometimes it would be neat to say "something I did saved $X million dollars or saved Y kWh of energy" or whatever.

sethhochberg

5 mesi fadiscuss

My debit card is a direct line to my primary bank account. If something goes wrong there and an attacker gains access, my cash is simply gone. Yes, the bank will perform an investigation and yes they may issue some provisional credits as a bridge, but there's a window of time between the theft and that investigation concluding where my actual cash is not in my account.

With a credit card, if the card is compromised, its not my money being stolen - its the card issuer's money from my line of credit, and they were planning on settling up with me when my monthly statement closes. I still have to launch a fraud case with the issuer, but critically, _all of my money is still in my bank account_ and I can continue to pay my other bills and obligations as normal.

I think its reasonable to consider giving up that buffer to be additional risk for the debit card approach, setting aside any other advantages or disadvantages between the two.

sethhochberg

5 mesi fadiscuss

I've personally had a decent amount of luck with trying to reframe this sort of sentiment from "being useful" to "having purpose".

Right now, yes, its true that a lot of my day to day purpose is driven by participating in the economy and setting myself up for the life I'd like to have in my later years, and I get genuine validation from solving problems and collaborating with people in my day job.

But sometimes, my purpose is to go snowboarding and forget about work. Or to help a friend fix their bicycle. Or to get lost in conversation with a new person I'm dating. As far as any of us know, we only get one turn to be alive on this rock, so we might as well purposefully enjoy it as much as we try to purposefully be useful.

If you look at Ginny Oliver from the article, it might be fair to question whether she was as useful on a lobster boat at 105 as she might have been in her youth. But I doubt she was concerned with usefulness since she had such sense of purpose.

sethhochberg

6 mesi fadiscuss

Its less about torrents being the delivery mechanism and more about bringing data from a potentially unknown source, under potentially unknown licensing, and distributed for a potentially unknown reason into the corporate computing environment.

Torrents would be a perfectly valid way for Google to distribute this dataset, but the key difference would be that Google is providing it for this purpose and presumably didn't do anything underhanded to collect or generate it, and tells you explicitly how you're allowed to use it via the license.

That sort of legal and compliance homework is good practice for any business to some extent (don't use random p2p discoveries for sensitive business purposes), but is probably critical to remain employed in the sorts of giant enterprises where an internal security engineer needs to build a compelling case for spending money to upgrade an outdated protocol.

sethhochberg

6 mesi fadiscuss

The thing about trademarks is that, if you want to prevent other people from using them, you generally have to still be using it yourself and be able/willing to justify to a court that you're still using it. (At least in most legal systems that I'm familiar with)

Since the original company both changed names and was subsequently liquidated in bankruptcy nearly 20 years ago... that seems unlikely. There's only so many names out there, and occasionally they get fairly recycled.

sethhochberg

6 mesi fadiscuss

I have no insider knowledge here but it doesn't seem outlandish to think that the negotiations would go a little differently for an established product vs a brand new one. Goldman may have simply been the only bank willing to work with Apple when the customer base (in size, demographics, spending patterns, whatever) was hypothetical.

sethhochberg

6 mesi fadiscuss

Game mode being latency-optimized really is the saving grace in a market segment where the big brands try to keep hardware cost as cheap as possible. Sure, you _could_ have a game mode that does all of the fancy processing closer to real-time, but now you can't use a bargain-basement CPU.

sethhochberg

7 mesi fadiscuss

I think there's some real sample bias in that definition of "the community" though, because people who are passionate Ruby programmers giving conference talks, running meetups, etc are often a distinctly different group than the regular-old programmers making business software go 'round every day. The big players writing tools for bringing various flavors of type safety into Ruby are doing it because they're experiencing the pain of having lots of programmers working on large, complex software over years-long periods with the tools that Ruby gives you out of the box. They often employ some of those community fixtures, but thats not the majority of an engineering organization.

The reality is that there certainly are enthusiast programmers who can thrive with the lightweight elegance of stock Ruby, but most people writing code professionally aren't enthusiast programmers under ideal conditions. Everything is always a little more distracted, a little less well-defined, and a little more coupled to legacy than anyone would want. And those are the conditions where I want my tools working as hard as possible, automatically, for me / my teams.

sethhochberg

7 mesi fadiscuss

Shorter lifetimes means more renewal events, which means more individual occasions in which LE (or whatever other cert authority) simply must be available before sites start falling off the internet for lack of ability to renew in time.

We're not quite there yet, but the logical progression of shorter and shorter certificate lifetimes to obviate the problems related to revocation lists would suggest that we eventually end up in a place where the major ACME CAs join the list of heavily-centralized companies which are dependencies of "the internet", alongside AWS, Cloudflare, and friends. With cert lifetimes measured in years or months, the CA can have a bad day and as long as you didn't wait until the last possible minute to renew, you're unimpacted. With cert lifetimes trending towards days or less, now your CA really does need institutionally important levels of high availability.

Its less that LE becomes more of a single point of failure than it is that the concept of ACME CAs in general join the list of critically available things required to keep a site online.

sethhochberg

7 mesi fadiscuss

"Internal" is a blurry boundary, though - you pick integer sequence numbers and then years on an API gets bolted on to your purely internal database and now your system is vulnerable to enumeration attacks. Does a vendor system where you reference some of your internal data count as "internal"? Is UID 1 the system user that was originally used to provision the system? Better try and attack that one specifically... the list goes on.

UUIDs or other similarly randomized IDs are useful because they don't include any ordering information or imply anything about significance, which is a very safe default despite the performance hits.

There certainly are reasons to avoid them and the article we're commenting on names some good ones, at scale. But I'd argue that if you have those problems you likely have the resources and experience to mitigate the risks, and that true randomly-derived IDs are a safer default for most new systems if you don't have one of the very specific reasons to avoid them.

comments