wpietri

The last couple years I've been prototyping a not-for-profit pinball museum in Chicago. In the coming weeks we'll be opening 7 days a week in a 2900 sq ft space in the Loop: https://theflip.museum/

It's my first time starting a physical, retail business and it has been quite an education in the small details.

Your theory is that emergency room workers would think "make sure patient X gets operation Y" so unimportant that they'd just leave it off the board? I have more faith in them than that.

There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.

It's also a barrier to interested users. I'm one. I am currently using 3 kanban solutions for different needs. I'm always looking for better solutions, but I'm not going to invest much in something with no docs and one screenshot.

That said, your answer here tells me what I need to know about the product.

This is such an important lesson. To me so many things from the "agile" toolkit appear to fail in ways where people tend to blame the tools, but instead are exposing people/process problems. The intent was that organizations use the pain points to improve process and solve problems. But in my experience a lot of organizations would rather remain dysfunctional than work effectively, and so will then shift to tools that don't expose the problems.

Sorry, but I don't think that's correct.

One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.

It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.

I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.

I think not having much documentation is fine, but please make the demo something where people can use it without logging in. E.g., they can click a button and just start messing with a demo project. Then you regularly reap the demo projects that haven't been used in the last 48 hours.

It could in theory, but purchasing decisions for tools like these are generally made by managers or executives, so they end up being optimized for what those people want. Or, more accurately, what they think they want.

It has worked fine for me on a variety of software projects for more than 20 years. Here's a project I documented back in 2004, where we used physical cards: https://williampietri.com/writing/2004/teamroom/

These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates.

I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists).

An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on.

I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion.

Happy to discuss further, but kanban approaches definitely work well for software.

Do you seriously blame the death star technicians? The cooks at the death star canteen? I find that extremely hard to understand.

You must be working very hard to not understand that, as it's very simple. They signed up for a job on a thing called the Death Star. Its only job is to commit genocide at a planetary scale.

They are morally responsible for the consequences of their choices. We all are. Getting paid doesn't negate that. If anything, it amplifies it.

You are confusing pointing out that people are morally responsible for the their actions with suggesting "that someone should leave their job on ideological grounds".

I get that you (and most of them) want to cash the checks without feeling responsible. Tough. People make the choice to work there, and they make the choice every day to keep working there. Other people get to make choices too, including about how they think about, describe, and treat people who profit from harming others.

Freedom of speech and freedom of action does not include freedom from consequences. Your freedom, or that of people making bank at Meta, is not more important than anybody else's freedom.

What's this website? Who put it up?

Those have always been good questions to ask, but especially these days.

For those interested in a keep-everything-hot approach like this, it's worth checking out the 25-year-old library Prevayler. Full ACID guarantees, and radically faster than a database. I happily used it for a project forever ago and was disappointed to see it so thoroughly ignored.

I read that as being his emotional reaction, not something he'd say in an interview context. This being an internet forum and all.

What I think he's sincere about is not wanting to work at a place that builds unnecessary stuff. And if people are asking for answers that require building unnecessary stuff, I think it's a reasonable inference that the place is not right for him.

I think interviewing is always a two-way street. If I got the feel that a place was going to have a lot of over-complicated code for me to deal with, or expected a lot of status-driven deference against actual user and business need, I wouldn't just give an interview-ending tart reply. But I would politely finish out the interview and then write them off unless there were other signals that redeemed the bad interview questions.

When I ask an interviewee a technical question, what I want is an answer that is correct technically.

If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.

I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.

I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯

Agreed. To me that's related to the question of minions vs professionals.

If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.

The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.

We could be different, though. There's the ACM code of ethics, for example: https://www.acm.org/code-of-ethics

Or the IEEE-CS code of ethics specifically for software: https://www.computer.org/education/code-of-ethics

We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.

Just to be clear, I'm absolutely not kidding here. E.g., this is the kind of hiring process I favor: https://williampietri.com/writing/2015/slightly-less-awful-h...

To rethink hiring, you have to spend some time understanding why most hiring is terrible both in terms of candidate experience and actual result. In my view so much of both hiring and general business operations is about managerial status and ego. https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

Humans are primates, and primate dominance dynamics are going to be the default absent some conscious choice otherwise. Our whole executive/worker dichotomy is a descendant of the British class system. (E.g., note that airlines specifically have a "business class".) And MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.

I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.

I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.

Although it was originally intended to be cash it actually now is used as a "store of wealth"

It's also terrible at that. Bitcoin is down by something like half off its peak. The odds of me losing money to "government intervention" if I'm not actively criming, are quite low. Certainly well under 50%.

Bitcoin works because you can technically have your wealth memorized.

If you are having to reach for increasingly absurd fantasy scenarios to justify something that was supposed to have thoroughly quotidian users, maybe you should take that as a sign?

because you have ideas which they do not agree with

Oh, that's who's using bitcoin the most? Philosophers and the like? I had no idea.

Right? I'll often structure interview questions like this. I give a basic problem, hoping for a basic answer. Then I add complexity, seeing how they respond.

In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.

yes you might be right but you also understand what the point of the interview is

To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?

I'd call it an interviewer failure, not an interviewee failure.

I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.

Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.

The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."

Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.

It seems entirely accurate to me, at least in a POSIWID sense.

The original theory of Bitcoin was, as described in the paper, decentralized digital cash. But in practice it was never optimized for what normal people use cash for. As system like that would be something like M-PESA.

Even at the time, cash was declining in usage. In the 18 years since, it has declined a lot more. And for good reason, because what most people want for most things isn't digital cash, but digital money. E.g., debit cards and Venmo.

So pretty naturally Bitcoin has value only for a few niche use cases that are not well served by more effective systems. Various sorts of crime, mostly. Digital cash, sure, but the kind that's transferred in unmarked envelopes slid quietly across the table. The kind that is delivered in a briefcase.

As a side note, it also failed in its goal of being decentralized. The mining power is very concentrated. Much more so than the banking industry, for example. And most users keep their Bitcoin on deposit in centralized services. So it's again basically banking but worse.

As a former Wikipedia admin, I think the best way to think of it as a massive text-focused battle MMORPG that happens to produce an encyclopedia as a side effect.

Instead it's usually used as a last resort when the "exploiter" doesn't get their way

I am not saying the phrase can't be used legitimately. Like the article's author, I just think it's often used in a way that isn't. Perhaps we're sampling from different areas of open-source culture, but when I think specifically of HN, I think just-fork-it style responses of the kind that the author is criticizing are common.

A community is much more than the sum of it's members.

Sure, I agree with that. But you write it as if it's in contradiction with my point, which I'm not seeing.

Sure.

As background, when power is misused, you'll often find somebody immediately showing up to explain why it was the fault of the person harmed. In the US, for example, this happens basically any time a cop kills somebody. In analyzing the situation, the agency of the person with power is minimized or ignored; the agency of the person harmed is maximized.

Open-source project are often run as little fiefdoms. Power is concentrated; checks and balances are minimal or nonexistent. Note that I'm not saying that this is bad or good; that's just how it is.

The "just fork it" style of response that the article is addressing, which I don't ever think I've seen in an issue but often see here on HN as a response to some complaint about a project. It's not part of a careful analysis about the costs and benefits of forking. There's also little or no attempt to understand who a project's audience and community is, or the value of the complaint in that context. It's a drive-by response to shut-down a complaint in a way that treats the complain as illegitimate, suggesting that person is wrong for wanting something different from what's on offer.

Does that help?

Every community is the sum of its members. Each person who joins changes it, at least a bit. And each of those members is changing and growing.

When community members have different needs, forking should be a last resort. It's expensive, and it's wasteful unless two different groups have irreconcilable needs. It should only ever be suggested as a last resort, after other options have been exhausted.

However, it's often used as a first resort to shut down criticism and to protect existing power structures. The person who speaks up is, as here, treated as an outsider and an exploiter.

Ooh, this is gold: "The slogan pretends to be anti-authority, but in practice it is used to protect informal power."

Spot on. I almost never see "just fork it" brought up in a context that acknowledges what that would actually take. It mostly shows up as a way of shutting down discussion, and often has a flavor of victim-blaming to me.

Drive-by PRs don't come from people interested in participating in the community in question. They have infinite places to juke their stats.

I see plenty of nuance beyond the bold print. They clearly say they love to help junior developers. Your assumption that they will apply this without thought is, well, your assumption. I'd rather see what they actually do instead of getting wrapped up in your fantasies.

"Good artists borrow. Great artists steal." -- me

Well, this is explicitly public ridicule. The penalty isn't just feeling shamed. It's reputational harm, immortalized via Google.

One of the theorized reasons for junk AI submissions is reputation boosting. So maybe this will help.

And I think it will help with people who just bought into the AI hype and are proceeding without much thought. Cluelessness can look a lot like shamelessness at first.