coverup

Where's the fallacy? She's saying the only systems that are beautiful are the ones that haven't been forced by massive spontaneous adoption to scale faster than the developer(s) can come up with and implement a beautiful design to meet the new requirements.

Maybe you think if the original system were _really_ beautiful and of high quality, it would have scaled with the adoption on its own, with no need for ugly patches... but in that case the original system would have had the capacity to do a lot more than what was originally required. It would have been overengineered, in other words, and it would have been more beautiful if it had met its original requirements more cheaply.

The notion that a sudden change in requirements that must be dealt with quickly results in an uglier system seems fairly straightforward to me, and certainly not offensive.

I find these types of questions invaluable as an interviewer, at least for mid-level to senior roles. And you're right, I am looking for an actual story, not just the lessons learned.

The problem with just asking about lessons learned is that anyone can memorize and rattle off a set of best practices they found in a blog post somewhere. That doesn't tell me whether they have relevant experience or not. Asking to tell me about a time when X happened and how they dealt with it cuts right to the chase, and I'm afraid there's a big difference in a response that comes straight from memory and one that's fudged or invented. The initial story might be great, but most people visibly struggle to keep inventing answers to probing follow-up questions about what happened. ("Did you consider Y as a solution? Would it have worked in this case?")

I sympathize, though - it's not like our brains have all our work experience indexed and readily available. The interviewer's choice of X is crucial. If the prompt is too specific, most candidates genuinely won't have a good answer. Too general and it won't help select for this role in particular.

An incidental nice thing about this type of question for candidates is that it can give them a sense of what this role at this company is actually like without their having to ask. I often even phrase it as "One of the challenges we're facing as a team is X. Can you tell me about a time when you faced something similar?" The discussions that follow tend to tell me loud and clear whether the candidate is a fit for the role.

Now, although I'm claiming fake stories are easy to spot, I don't know what I don't know. It's possible someone has taken me for a ride and I ended up giving them the 'strong yes'. I don't think there's anything wrong with that. If you're able to craft a sufficiently detailed fake story and talk about it off the cuff for a while in depth, then you probably have enough relevant experience anyway!

While it makes sense that the police would unionize for the same reason any other workers would, your second paragraph seems to contradict your first.

Your proposal to shift responsibility for "policing the police" up to elected officials means weakening police unions, does it not? Is there a political body out there that's even more fundamentally in support of police autonomy than police unions?

¯\_(ツ)_/¯

I like this. Here are a few more:

"We maintain a lot of BAZ we think no one needs anymore but we don't know for sure" is called a Yikes.

"You just have to know which alerts matter and which don't" is called an Uh-oh.

And of course "securing the QUUX wasn't an explicit requirement for launch so we haven't done it yet" is already called a vulnerability.

Just to add some color to your comment as I think the idea that philosophy can be therapeutic is counterintuitive for a lot of people: consider the loneliness of depression, a big part of which (at least for me) is the seemingly insolvable problem of being trapped in my own head. "No one else could possibly understand how I feel" seems to be true not even just for me, but for the human condition. We're not mind-readers.

Nonsense, Wittgenstein seems to argue. If no one else could understand how you feel even in principle, then neither could you. If you can talk about it then people will understand, because we use the same words the same way. And when we don't, it's not because of some kind of epistemological solitary confinement - it's just a misunderstanding, and there are language games for resolving those too.

You don't have to read philosophy to know that "no one else could possibly understand how I feel" is actually a common sentiment, though. The truly therapeutic part for me was the idea that even though there may be problems that can't be solved, they can sometimes be dissolved. (i.e. seeing the problem statement itself as nonsense)

It seems more likely to me that it's not a misspelling of "monjita" but rather just a naive application of the Spanish -ito/-ita diminutive suffix to "Mongo".

The US will suffer if its international students can't get an education here without being told by the government to pack up and head for their favorite Caribbean island because we don't value their desire to contribute to our society.

> This mentality leads to systems that are a mess of callbacks, don't scale, and practically impossible to maintain.

Why would it? I can put the same types of abstractions into my application layer in the form of a common library. Only difference is they can be a lot fewer and simpler because they only need to meet my exact requirements.

I often do make the same argument about SQL databases in cases where RDBMSs are not an appropriate tool for the job. In the case I mentioned, where I'm using it as a shared datastore that supports ACID transactions with concurrent access, I find Postgres (and many others, including many NoSQL stores) to be suitably placed in the abstraction spectrum to be worth using rather than rolling my own solution.

Sure! To start, just fundamentally—why assume workflows are DAG-shaped? Why no cycles? Lots of real-world processes contain unscheduled repetition that arises at "runtime."

Or what if I can only find out what the rest of the workflow looks like once I'm halfway through it? Why must workflow definitions be static? No "decision" elements as in a flowchart?

Someone might read these complaints and think I'm asking for a programming environment rather than a workflow tool, and that's kinda my point :P

The "unnecessary" side is typically project-specific, but I tend not to need a separate notion of `backfill`, or any of the `Executor` functionality for distributed execution. I suppose if I needed to run stuff on multiple nodes I would just schedule jobs on Kubernetes directly.

I'm gonna go out on a limb and say any purported workflow tool that comes with a data model you have to memorize (i.e. "Before we start building a workflow, let’s learn a little about the components of an SWF") is too complex to be effective.

My problem with tools like these is that I already know the components of an "SWF" or whatever—these are the tasks I have that need to be run/managed. When a tool starts telling me what the architecture needs to look like, then it stops being a helpful tool and starts being a little know-it-all.

My favorite workflow tool is actually two pieces of software: cron and postgres. Cron schedules tasks and postgres handles shared state. It's easy enough to whip up an ACID-compliant task queue in SQL that has whatever bells and whistles you want, and all cron wants is a command to run and a schedule. No need to read a bunch of documentation about what a "task" is supposed to be vs. an "activity" vs. an "execution" or anything like that.

Of course, what my setup does not do is provide common functionality out of the box like "just gimme a way to kick off a series of FS-dependent tasks every day and record errors/halt if anything fails." I don't mind. It's not like Apache Airflow (just to give another example) has saved me from having to think about and express my system's dependencies and failure modes—it has only put a lot of unnecessary and unhelpful constraints on how I am able to express them.

Dunno if it was you or someone else who clicked your link but it was nice chatting with a couple folks just now :)