jroseattle

I like Boris's list, if only because it's obvious. Anyone responsible for solving a problem goes through these steps, either pro-actively or re-actively.

Organizations usually suck at this part. Being time & resource constrained, the focus on anything but actual problem solving is just staggering to me. I haven't worked at every place, so your mileage may vary.

Watching the demo video, they haven't created open executives. They've created open managers.

It looks like most of the work of the package is reactive -- monitoring external things and responding. It's not proactive just because a person didn't dial it up.

But, here's the thing -- this can likely replace many executives right now, at least those who are reactive managers. I'm in full support -- automate those things if you can.

AI is coming for judgment jobs. It seems it's turtles all the way down.

True, things in the west tend to cost more than elsewhere (I'm in Seattle WA.)

My mother-in-law lives in rural Missouri and had her 6x10 bathroom remodeled in 2025. Full gut replacement of everything. Total cost: $5600. I got a quote for something similar in a bit larger bathroom in our house in Seattle. Quoted price: $31,000.

Labor is a good chunk of cost, and the OP presented that he simply didn't have the time available to him to do that work himself. On the other hand, I built 20-ish feet of fencing for our backyard this summer, matching an existing design we had done several years ago. Quoted price from the same company that did it the first time: $9800. I did the work myself. My total cost: $1400.

That works out great, right? I also have a significant investment in all the right tools: compound mitre saw, construction-grade table saw, nail guns, impact/hammer/regular drills, angle grinders, power sanders, every drill bit in captivity -- I don't really lack for anything. These make a huge difference in the workmanship of the final outcome.

And that was just a fence. I've considered building an external office here at our house. When I start to take into account the scope of converting an outdoor shed to an acceptable backyard office, I hit the brakes. Electrical power under proper permits, adequate security, something that holds up under our weather, potential water/sewer access, and sufficient space to work (I can't live without a whiteboard)...there is more scope than meets the eye.

All things considered, I think the OP did a pretty good job here in terms of cost control and recognizing what he could do (windows) vs. needed someone else to do (proper electrical.)

Heartily agree with the metrics for analysis, but this seems anchored around a focus on introduction of "something else" without regard firstly to correctness.

> The server is not the most important thing, and each new kind of server that exists in the system is an appreciable increase in maintenance burden.

Sure, but compared to what? It's right to consider complexity, but understanding tradeoffs requires depth. The OP's original premise was that learning all the things about specific queuing services was unnecessary chafe; that INSERTs, SELECTs and UPDATEs are all anyone needs.

The maintenance burden sits with your producers & consumers (or publishers/subscribers, whatever your nomenclature...), whether you want it there or not.

My learned experience is that as soon as you start moving messages that are beyond trivial and carry different operational characteristics, you're going to have to understand those deeper concepts anyway.

> Events, queues and persistent logs are getting more and more important in today’s software systems. Systems like Kafka, RabbitMQ, SQS and others provide that functionality. But maintaining them is annoying, custom and you need the skillset.

In tech stack choices, I prefer staying simple as long as feasible. That said, you also need to know and understand concepts at a thorough level.

The above comment from the article suggests PG as a central server that simplifies event architecture. As if the "annoying, custom and needed skillset" around those specific alternatives are unnecessary baggage.

If you know anything about queues, scaling, availability, access semantics, message formats and concepts such as delivery guarantees, you find out very quickly that the server which stores a queued message is not the high-order bit in that equation.

> VG didn't do a great job there but the idea of doing it remotely being evil or whatever was ridiculous

I don't think the issue was the communications medium (Zoom.)

> I don't think much about my time at Better but it was fine.

That's the biggest tell about leadership at any company.

This is exactly how we arrived at our solution. We needed to satisfy the constraint; locking was one means of addressing the constraint.

Maybe we were lucky in our implementation, but a key factor for our decision was understanding how to manage the systems in our environment. We would have skilled up with Redis, but we felt our Postgres solution would be a good first step. We just haven't had a need to go to a second step yet.

> up to 50000 atomic, short-lived transactions per second

50000?

> You need distributed locking if the transactions can take seconds or hours, and the machines involved can fail while they hold the lock. From my experience, locks are needed to ensure synchronized access to resources. Distributed locks are a form of that isolation being held across computing processes, as opposed to the mutex example provided.

And while our implementation definitively did not use a distributed lock, we could still see those machines fail.

I fail to understand why a distributed lock is needed for anything due to it's duration.

We reviewed Redis back in 2018 as a potential solution for our use case. In the end, we opted for a less sexy solution (not Redis) that never failed us, no joke.

Our use case: handing out a ticket (something with an identifier) from a finite set of tickets from a campaign. It's something akin to Ticketmaster allocating seats in a venue for a concert. Our operation was as you might expect: provide a ticket to a request if one is available, assign some metadata from the request to the allocated ticket, and remove it from consideration for future client requests.

We had failed campaigns in the past (over-allocation, under-allocation, duplicate allocation, etc.) so our concern was accuracy. Clients would connect and request a ticket; we wanted to exclusively distribute only the set of tickets available from the pool. If the number of client requests exceeded the number of tickets, the system should protect for that.

We tried Redis, including the naive implementation of getting the lock, checking the lock, doing our thing, releasing the lock. It was ok, but administrative overhead was a lot for us at the time. I'm glad we didn't go that route, though.

We ultimately settled on...Postgres. Our "distributed lock" was just a composite UPDATE statement using some Postgres-specific features. We effectively turned requests into a SET operation, where the database would return either a record that indicated the request was successful, or something that indicated it failed. ACID transactions for the win!

With accuracy solved, we next looked at scale/performance. We didn't need to support millions of requests/sec, but we did have some spikiness thresholds. We were able to optimize read/write db instances within our cluster, and strategically load larger/higher-demand campaigns to allocated systems. We continued to improve on optimization over two years, but not once did we ever have a campaign with ticket distribution failures.

Note: I am not an expert of any kind in distributed-lock technology. I'm just someone who did their homework, focused on the problem to be solved, and found a solution after trying a few things.

Congrats on writing and completing a book! I was involved in a few myself long ago, when I had the time available to contribute to those endeavors. In a world that often measures "the juice being worth the squeeze", I'm not sure authoring technical manuals would ever meet the criteria.

One of my personal photos I keep around was taken long ago in what was the biggest bricks/mortar bookseller. I was looking at the selection of books on Java available at the time. O'Reilly was the dominant publisher, and thus had several offerings on the wall. Most of the books were at least 2 inches thick. (If you were ever involved with writing a technical book in the early 2000s, you'll understand the publisher metrics at the time were based on the width of the spine on the shelf.)

Among the many Java manuals of significant girth was a small, THIN book with the title "Java -- the Good Parts". :-{}

> The vulnerability was addressed with the release of Docker Engine v18.09.1, but it was not included in subsequent major versions, causing a regression.

Without further information, this sounds like code introduced in a hotfix that wasn't merged back to feature branches.

Surely it's not that simple?

> Resume fraud is rampant.

So is interview fraud. The remote-interviewee-answers-questions-while-her-face-reflects-windows-popping-up-on-her-screen is tiring at this point. So, I decided to find a way to inform me if someone was being fed answers in a tech interview.

Behold, the low-tech whiteboard. Also known as a piece of paper and a pencil. With the candidates I've run into that do not pass the "smell" test -- where I think they are being fed answers -- I ask them to draw some things, on paper. It's not a true validation, but it gives me something of a clue.

I ask for a simple diagram. Different services in a network, for example. Or a mini-architecture. For their level, I'll ask for something that should be drop-dead easy.

I ask them to show me their drawing.

The responses I've received run the gamut of "I don't know" (after 5 seconds of deliberation) to "I don't understand the purpose" (after 5 minutes of silence) to "I need to shut off my screen for a while" (while refusing to explain why) to "it depends if your cloud is AWS" (not in any way remotely related to the question.) I did have a candidate follow-up with a series of questions about the drawing, which were feasibly legitimate.

This hand-written diagram is not an absolute filter (I've only used it maybe four times), but rather it can confirm some suspicions. I think I can generally gauge honesty from questions/tasks like this. And that's really what I'm after -- are you being honest with me?

It's imperfect, but it has been helpful.

What I find more important than the timestamp format -- the timestamp source.

Centralize from where the ts is set (the db is a great place to do this.) Don't let client-code set the timestamp.

You learned some great lessons there, but I would challenge one item early in the "script":

> 2. Verify if it’s a problem from search volume.

It contextually depends, but correlating a problem-to-be-solved with search analytics can be really tenuous. I'd suggest a different phrasing:

  Verify it it's a problem by speaking with customers.

You can still use all the tools, but in the end you want to talk to those who you intend to serve. At that point, you'll have zeroed in on the actual problem they may have and are willing to pay you to solve.

Do it better the next time!

I really like your on-device storage approach. I did something similar with an app for my smartwatch a few years ago to prompt/track my gym workouts. At the time and on the particular platform, other apps felt very spammy/scammy, and I just didn't care to go through the hassle of pushing/pulling my data with another application for what seemed like little to no value to me.

I haven't touched it in a while, but I've been thinking of a sync-to-another-device capability that I could then use with a locally-running AI instance to dig into. (Disclaimer: this is purely exploratory on my part; I'm sure someone will say 'why not do so-and-so'). As always, your mileage may vary. :-)