bethly

Direct democracy is easier to buy than representative democracies for two reasons: first, voters have other things to do with their time than become experts on every bit of law that comes before them. And second, they don’t have the ongoing interest in rule-making, implementation & enforcement an interested legislator does.

Reading the book Street Level Bureaucrats was eye-opening for me on why seemingly “common-sense” solutions like Direct Democracy end up either just not working or having the opposite of the intended effect. Laws are less like writing software for a computer and more like designing processes for a team writing software.

I’m curious what maximization function you are considering

It is so interesting to me the way “nerd” and “geek” function as quasi-diagnostic categories for Boomers: not specifically medicalized, yet used to describe developmental differences.

It demonstrates both the power and limits of the social model of disability, in a way no amount of pure theory would.

(We can contrast this with the current Gen Z movement towards neurodiversity, which is emerging from solidarity across dramatically different subjective experiences, some regarded by the medical profession and others not.)

I would recommend reading the blog post; I think there is context you have missed.

I'm describing interactions here I am having with my peers, not people I'm in a service relationships with. We are practicing a highly-skilled trade, and acknowledging the times our skill pays off isn't a "continuous din", or even "positive reinforcement". It is just refusing to be dour sourpusses who have to pretend our work isn't super cool.

Code reviews are most closely akin to a Writing Workshop. When someone in a writing workshop says, "that description evoked Oregon in spring" or whatever, it isn't banal positivity: it is specific feedback on how the craft is functioning.

Is anyone else only able to see the first page of the PDF?

I am sorry your work has been frustrating.

Here I was talking specifically about code reviews, so the context is pretty different than an incident retro. A code review where there is nothing nice to say is probably not going to merge into the code base: it is going to get updated to address the issues, and then there will be something nice to say as I give it a plus one.

But when I run retrospectives, even in the most horrific cases we have a section on "what went right". Sometimes the answer is "nothing", but usually there is something that was helpful: a log message that helped us find the root cause, documentation that meant we didn't have to call someone, alerting that found the problem, a feature flag we could toggle off until it got fixed.

In a corporation, we are playing a repeated game. It isn't about just this one incident: it is about what all the people watching the retrospective are going to built tomorrow, and the day after that, and the day after that. I want people to hear what went right with this incident so they put the log statements & feature flags into their own stuff. Those are the kinds of things that may only be relevant when something goes really wrong, and it's easier to leave them off, so every bit of positive reinforcement we can manage makes our lives easier when we do get paged.

It's not like he's from the Middle Ages or something; 1964 is within living memory.

He was creepy and unprofessional, not a criminal. “Be fired” is the proportional and appropriate response.

This approval is just a first step; we intend to augment (subject to SEC approval) the exchange's listing rules with those innovations.

We are thrilled that the SEC has officially approved the Long-Term Stock Exchange as a national securities exchange!

In the data set I used for reference, Series C+ companies still mostly failed to exit. Even at the furthest extreme the data tracked, of the 35 Silicon Valley companies that raised a fifth round 18 failed to exit or raise more money.

On the other hand, there are some advantages that may make later companies less risky: the timeline to exit may be shorter (though that is less true in the case of an early M&A, which ~23% of the cohort found). The nature of the risks may change in ways that make it easier to evaluate. And cash salaries usually rise in the later stages, reducing the marginal cost to employees.

There was no stage at which venture-backed companies stopped being a risk, but that's also true of public companies that grant options: it is always possible that the share price goes down and the options are worth nothing. I think the takeaway is that in this 2006-2008 cohort, earlier startups were less at risk of running out of money that most people would assume.