Yeah, this is exactly what I thought when I read this post. It seemed like the author either hasn't worked in big tech, or hasn't worked in the industry very long. It's extremely likely that the engineer who designed this was standing on his desk shouting "it's going to cost THIS MUCH MONEY. I want to make sure that EVERYONE IS OK WITH THIS." and was met with shrugs.

Here's how a big tech reporting chain sees this situation when everything is smooth sailing: "We're growing 3x year-over-year? After 2 years, the cost will be an order of magnitude higher no matter what solution we pick. The constant factor doesn't matter that much. But we have such an incredible roadmap that we will book more than an order of magnitude of revenue, backed by this new ledger project. The cost will always be a nonissue because of growth."

And then 2 years go by, and this incredible product growth adds a bunch of ledger entries that weren't there 2 years ago, someone nudges your reporting chain with the question, "this is pretty expensive.. what gives?" and then someone with a good combination of social and technical skills points out that a migration to your existing storage solution would be a cost effective way to continue growing.

At every step of the way, everyone is generally happy with what's going on.

And even still, it’s hard to ignore him because he’ll still have some insight like “token efficiency is going to be the big thing we care about in the future,” which was a small section of one of his Gastown blogs. And after you’re done asking yourself if that means Gastown is performance art, or he just said that as a hedge against his “vomit tokens” approach so that he could say “look I knew it all along” when this is all proven to be misguided, you’ll start to mull on just the concept of “token efficiency” and realize “someone who can do work in 1/10th the tokens will be king.” I mean hell, Gastown preceded real support for multiagent orchestration in Claude and potentially nudged it along that path.

Yeah, it's just depressing because one of the links in here took me to his Twitter (my mistake) and I was just like, "Oh, got it, life event (maybe a divorce, maybe just aging) turned you toxic and now you're lost in the wilderness. +/- 6 months until he is claiming ketamine solved/ broke him.

(It's nice to have the superpower to judge people on social media posts, I know. It's a gift, I try not to use it for evil.)

I have some blog posts coming out soon. I’m also trying an experiment where I make YouTube videos[0] on each of them. My first video was a huge lift, since it was my first time doing everything.

Random observations from my first one: - presenting my idea visually helped crystallize my thinking in a way that writing doesn’t. And writing was already very good at crystallizing my thinking. - even making a bad video was a lot of work - making a video presentable is a deep subject. Subtle changes were throwing off my setup. Now I understand why so many influencers are fitness and lifestyle; the demand side is obvious, but when you’re already camera-ready you have a huge advantage on the supply side - described something I built felt natural. I do that for a living. The intro was like 45 seconds and took me like 45 minutes to film because it was acting and I don’t know how to do that - learning about video editing features had an immediate payoff because video is so long

[0] I’m posting the videos at https://m.youtube.com/@bitlog-dev . I said if the first one got to 100 I’d commit to making at least 10, and I just crossed that threshold

An old neighbor of mine was a headhunter. He once told me that some companies had a trick to get around the law. Upon getting hired, you'd sign a document saying that you'd agree to all policies in the employee handbook. Pretty standard stuff. One of the company policies was that you needed to prove any previous salary you stated in the negotiation. If it was too far off, they'd just terminate you. The trick is that they didn't ask at all during the hiring process; you're already hired and onboarded and then HR puts a meeting on your calendar to explain the policy to you.

That seems like a great way to open your company up to a discrimination lawsuit (whether warranted or not). Not to mention the costs of hiring a new employee you only fire a month later - why bother?

Sounds like HR mythology.

> The trick is that they didn't ask at all during the hiring process; you're already hired and onboarded and then HR puts a meeting on your calendar to explain the policy to you.

Yeah, "all bets are off" once you are a FTE.

Isn’t that too late to negotiate compensation? I had figured most of the value is knowing how to properly lowball candidates

It sounds made up. Who would go through the negotiating phase, hire the person go through all paperwork only to then gotcha them and fire them if they lied about their past salary? I've never seen an org that actually played games like that.

It sounds like negotiation would still be done however it normally would before things got to this point.

Dunno, kind of sounds like hiring and then negotiating compensation.

I call BS. Why would they hire you at an agreed to price, go through the cost & effort and then try and "get you"? Your old neighbour was either in bed with his hiring clients or not very good at his job.

He recruited for wall street trading firms; based on the finance types I've met over the years in NYC I would 100% believe some did this just because they hated losing. He was just making the point that you should never lie about your salary history, because he can help you if you didn't want to give it but he couldn't help you if you BSed everyone and got caught.

It’s definitely made-up. I worked for a Wall Street trading firm in the securities division for 8 years. People lie about comp as a matter of course. Secondly, many/most senior-ish jobs in those firms come with a guaranteed bonus for the first year or couple of years. If they were to fire the person before that period elapsed they would have to pay out the bonus.

I know of many people who were fired the day their guarantee elapsed- I can’t think of a single person on a guarantee who was fired before then. To put this into context, we had a guy on a guarantee on our prop desk who came in for one week after he joined, put on a (massively winning) trade that got him enough to get his guarantee and then literally didn’t set foot in the office for the rest of the year[1] until the day he came in to collect his bonus and resign/be fired.

[1] And it’s not like he was working from home because people in trading were (for compliance reasons) not allowed to work from home unless there was an emergency like a terrorist incident where the trading floor was closed.

Christ, that sounds like a colossal waste of time for everyone

There are some rose-colored glasses when people say this.

Programs didn’t auto save and regularly crashed. It was extremely common to hear someone talk about losing hours of work. Computers regularly blue screened at random. Device drivers weren’t isolated from the kernel so you could easily buy a dongle or something that single-handedly destabilized your system. Viruses regularly brought the white-collar economy to its knees. Computer games that were just starting to come online and be collaborative didn’t do any validation of what the client sent it (this is true sometimes now, but it was the rule back then).

> Viruses regularly brought the white-collar economy to its knees.

Now, it's anti-virus (Crowdstrike) that does that. I don't think many or any virus or ransomware has ever had as big an impact at one time as Crowdstrike did. Maybe the ILOVEYOU worm.

crowdstrike is not your average antivirus like malwarebytes or avast. the whole point is you can remote control everything with custom rules and enforce a security policy by locking the device until someone updates it. that update system is the main reason the bug was so dangerous. its built for corporate places who care about compliance more than actual security.

It's amazing that the world has largely forgotten the terror of losing entire documents forever. It happened to me. It happened to everyone. And this is the only comment I've seen so far here to even mention this.

Bad old days indeed!

Indeed, but it was pretty easy to develop the habit of hitting whatever function key was bound to "Save" fairly frequently. I certainly did.

Also auto-save is a mixed bag. With manual save, I was free to start editing a document and then realize I want to save it as something else, or just throw away my changes and start over. With auto-save, I've already modified my original. It took me quite a while to adjust to that.

If your program's auto-save works like that, it's broken.

Almost none do, though. Auto-save almost always writes to a temporary file, that is erased when you save manually.

Google Docs and VS Code are the first two that come to mind for autosave and they don't use a temp file.

Fun fact: I was on the Google Docs team from 2010-2015. Save didn't do anything but we still hooked up an impression to the keystroke to measure how often people tried to save. It was one of the top things people did in the app at first; it was comparable to how often people would bold and unbold text. And then as people gained confidence it went down over time.

This is DELIGHTFUL.

Yeah, source code editors tend to do that. They integrate with external tools that expect to read those files, so if they don't overwrite them, those tools would run the wrong version. It would still be better if they didn't.

Text editors shouldn't do that though. And those shared-view editors that don't have the concept of saving have this very relevant drawback.

I still occasionally make that auto-save mistake.

AI tools have caused me to trip up a few times too when I fail to notice how many changes haven’t been checked into git, and then the tool obliterates some of its work and a struggle ensues to partially revert (there are ways, both in git and in AI temporary files etc). It’s user error but it is also a new kind of occasional mistake I have to adapt to avoid. As with when auto-save started to become universal.

Saving also often took a long time, so people didn't do it very often.

Certainly depended on the software. But disks were slow back then, and a save would commonly block the entire UI. If your software produced big files you could wait for an inconvenient amount of time

I’m on tirzepatide and it’s crazy how it can truly reform habits. I’ve been a night snacker my whole life. I don’t even think about food after dinner anymore. At a bar, I used to pound down the last quarter of a beer so I could go get another. Now I might forget to finish it and I probably won’t get another. Now I feel full while eating for the first time in my life. It’s going to be truly transformative at scale, even knowing it doesn’t work for everyone.

My doctor, who is on the older side, told me that he went through his records when GLP-1s started being prescribed for weight loss. He wanted to calculate what percentage of his patients (a) he had advised to lose weight, (b) reduced their weight to healthy levels, (c) and kept it off.

From the starting population of overweight people, only 3% of people dropped down to, and stayed, a healthy weight.

I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.

For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.

I’ve been playing around with these kinds of prompts. My experience is that the prompts need a lot of iteration to truly one-shot something that is halfway usable. If it’s under-spec’d it’ll just return after 15-20 minutes with something that’s not even half baked. If I give it an extremely detailed spec it’ll start dropping requirements and then finish around the 60-70 minute mark, but I needed 20 minutes to write the prompt and I need to hunt for the things it didn’t bother to do.

I’ve gotten some success iterating on the one-shot prompt until it’s less work to productionize the newest artifact than to start over, and it does have some learning benefits to iterate like this. I’m not sure if it’s any faster than just focusing on the problem directly though.

The dropping requirements problem is real. What's helped us is breaking the spec into numbered ACs and having the verification run per-criterion. If AC-3 fails you know exactly what got dropped.

I'll try that out, thanks for the tip!

As someone who took German in high school, Dutch had my brain flailing for vocabulary to understand but nothing connected.