Earlier quoted context omitted.
Working with stored procedures is just the pits. I wonder why you would describe that as "great". Maybe it's optimized, but so would be a giant executable written in assembly.
It is great: your code runs right near the data it’s working with. If it’s the pits, you need a better suited development environment. I use emacs and interactively code inside the DB. Python, Lua, JavaScript, PGSQL, whatever.
What Happened to Lee
161–170 of 299 posts
Re: What Happened to Lee
#162Earlier quoted context omitted.
>For one thing, being in the U.S. healthcare system, if I did have the markers, would that then count as a "pre-existing condition" I'd have to disclose? I'm sure the people who pay premiums for health insurance would hope so. If you already know you have a condition that's going to cost a lot of money to treat, you're not looking for insurance. If you can't pay for it yourself, you're looking for charity.
> If you can't pay for it yourself, you're looking for charity. I hope you don't believe in Karma, because you're tempting fate. I doubt you'd strike the same tune if you or your loved ones had a severe and/or chronic illness that threatened to bankrupt you through no fault of your own. Also, in the US, your health insurance is probably tied to your employment. Expecting someone to stay at the same job (on the same i…
>Expecting someone to stay at the same job (on the same insurance) for the rest of their life after learning about some illness, and calling anyone who isn't able to do this a charity-seeker, is asshole behavior.
Suggesting that needing charity due to circumstances outside of your control is shameful seems like the real "asshole behavior", which, if you think about it, is exactly what you are doing. I'm not criticizing anyone for needing charity. I'm pointing out that's what it is.
I'm pointing it out to demonstrate that health insurance companies are acting like charitable foundations and filling their pockets while doing so, and their customers are getting robbed to pay for it.
Re: What Happened to Lee
#163I posted this hours ago and then stepped away. The story captures so much about the Lee I knew so well. I'll add one piece of praise for Lee's early architecture of Cloudflare. Everything was controlled by a single Postgres database that made very heavy use of stored procedures, that called other procedures, that called others. It was one giant program inside the database. It took me a while to comprehend what he'd d…
I’m sure he did a great job, but I’ve seen those things be a huge nightmare for anyone other than the irreplaceable genius code wizard who created them.
The interesting thing is that such cases can also actually be the huge nightmare you write about, in the sense that there are tradeoffs in the original design that originally made sense but become harder to deal with later, but also in the sense that their nonstandardness can be hard for more typical engineers to work with. (This is often referred to as the 'hiring problem', though that can be misleading.) The trouble with the typicalness of more typical engineers is that they're steeped in a technical culture which they regard as the proper and obvious way to do things, but which really is mostly just the set of conventions they're used to. Those two things are easy to conflate when all your peers agree on what's proper and obvious (for example that you should never build a complex system entirely in Postgres stored procedures, or whatever the weird thing is). Those conventional assumptions are at least part of what makes such systems a 'nightmare', because if you're working on a system that feels 'wrong', then you fight it rather than blend with it, and that makes it harder to maintain. Everything that's objectively wrong with it will loom larger in your experience than it would if you didn't have the feeling that it should never have been built that way in the first place. Worse, many things that aren't objectively wrong with it, in the sense that they aren't intrinsic to the system or the domain, end up blowing up into major issues because people find they can't work with this system in the way that they're used to, and it's too hard to abandon ways that you're used to—it always feels like the system is at fault. Meanwhile, everything it got right will fade into the background as you assume that any system that had been built 'properly' (i.e. the way you'd have done it) would have gotten all those things right too, at the same cost or better.
It's hard for the later engineer who experiences the 'nightmare' to fully appreciate that if it weren't for that weird, obviously 'wrong' system, they wouldn't have their job in the first place (nightmare and all), because the business that succeeded was built on the weird system.
I don't know anything about this case other than what John posted above, but I've seen something like it in other situations, and in fact I would say that PG and YC have this in common with the case of Lee and Cloudflare as John describes it—as remote from one another as Postgres procedures and custom Lisps must be in every other respect.
What I wish we could teach younger engineers is: when you run across a system like this, pause. Then, pause. Then pause again. The creativity at the core of it can be remarkable. Often you see things that one person did which would have required a large team in other hands, and therefore would never have happened otherwise. Maybe that's one reason why these systems tend to be found at the start of companies: more conventional approaches wouldn't have worked at a stage when hiring a team wasn't an option yet; and on the other hand, the teams you do hire at the later stages tend to have more conventional engineers whose minds (or rather, whose conditioning) can't grok why you'd ever have built something so weirdly.
Usually the later engineers bond with each other around how much they dislike the 'legacy' system, and lobby to replace it, and usually get their way in the end. That's a cycle-of-life thing, but it's also sad when we prefer our conventions and assumptions over seeing, and honoring, the creativity in what came before. Sometimes masterpieces get paved over because of that. Of course, not every nightmare system is an unappreciated masterpiece. But some are, and the bias in our industry is extremely strong toward perceiving them as nightmares. I've seen people take chainsaws to masterpieces without realizing that that's what they were doing, and it makes me sad to think of it. But it makes me happy to read what John wrote to honor Lee, because that's how I'd want someone to write and feel about something I'd built, if I built something like that.
Re: What Happened to Lee
#164Earlier quoted context omitted.
My suspicion would be that the general anesthetic is the primary cause.
I have been sedated a few times for minor procedures, propofol, I think, with no issues, and I’ve had a general once, for a laparoscopic cholecystectomy - about as trivial as abdominal surgery comes, only a few hours under. It had side effects. For the better part of a year afterwards, I kept finding myself unconsciously substituting completely incorrect words into written correspondence, I was irritable almost const…
Re: What Happened to Lee
#165Earlier quoted context omitted.
He's looking for health care, actually.
Yes, and he's looking for it to be financed by other people while giving them nothing in return for it.
Re: What Happened to Lee
#166Earlier quoted context omitted.
I’m sure he did a great job, but I’ve seen those things be a huge nightmare for anyone other than the irreplaceable genius code wizard who created them.
I guess you're using the word genius ironically, but I've also seen such things be radical in the sense that they're built in a way that no one else would have done, yet it ends up working perfectly for the business and being far more successful than anyone would have predicted. There's a certain type of mind that is immune to fashionable or normal technical choices, that often goes along with remarkable productivity…
Re: What Happened to Lee
#167Re: What Happened to Lee
#168Earlier quoted context omitted.
I guess you're using the word genius ironically, but I've also seen such things be radical in the sense that they're built in a way that no one else would have done, yet it ends up working perfectly for the business and being far more successful than anyone would have predicted. There's a certain type of mind that is immune to fashionable or normal technical choices, that often goes along with remarkable productivity…
And those conventions change over time. So you might write something using Java EJBs at some point and then the world moves on and engineers no longer know how those things work. What looked like a great architecture is now confusing for most engineers.
Re: What Happened to Lee
#169I posted this hours ago and then stepped away. The story captures so much about the Lee I knew so well. I'll add one piece of praise for Lee's early architecture of Cloudflare. Everything was controlled by a single Postgres database that made very heavy use of stored procedures, that called other procedures, that called others. It was one giant program inside the database. It took me a while to comprehend what he'd d…
Working with stored procedures is just the pits. I wonder why you would describe that as "great". Maybe it's optimized, but so would be a giant executable written in assembly.
I mean, if you stick to a rigorous procedure of automatically exporting your stored procedures to files and committing them to git with messages... how is that different from any other development?
Serious question -- I've done tons of database work but only a little bit with stored procedures, so wondering if I'm missing a crucial detail here.