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.

Building this I used information from CB Insights, which looks at companies that receive VC funding by cohort. Their most recent report covers companies that raised seed rounds in 2008-2010: https://www.cbinsights.com/research/venture-capital-funnel-2...

Then you're stuck: there isn't any way to value shares in something without knowing the denominator. Your company should be willing to provide the "fully-diluted basis" for your shares if you ask.

Building this tool we purposefully steered away from education. We found that the users we talked to, people considering startup jobs who didn't know how to value options, were frequently overwhelmed and discouraged by tools with more educational content.

This tool might spark someone's curiosity, but we purposefully built it for a group that didn't want to have to learn about venture finance and still wanted to work at a startup.

If you are looking for more detailed scenario modeling, we've also built a free cap table management tool that takes into account the specifics of a particular company: https://captable.io/

Only if it exits at that seed stage: if it raises more money, the number goes up. If the company makes it to Series C+, the number is probably going to be higher than $35M. Which is what taking the average does: for about half of exits that number will be higher and for about half the number will be lower.

Rather than complicating the model here to try to illustrate the difference between exiting at this stage versus raising another round, we went with an approach that demonstrates how preferences work. Even if the number is lower for a Seed company that exits at Series A or higher if it exits at Series C, there is still a number under which you'll get nothing even if the company has a profitable exit.

Thanks for the feedback! That's a good idea; I'll add it to our list!

It's fun to watch a market that's actually nearly perfect: no barriers to entry or regulation to capture means that lead time is about the only source of surplus and profit consistently trends to zero.

When TDDing the tests are going to change a lot, just like the code you are saying you write anyway. I recommend the book Refactoring for the tools so you can make the changes without breaking the test, then clean up the now-unimportant tests, and then clean up the unused code. That way the tests stay green even when making major, breaking changes.

Being able to slice projects that way, in terms of functional behavior, is absolutely a skill that requires practice. You are already thinking about what your code needs to do: the practice is to get good at expressing that in terms the computer understand. Once you are in the habit, the tests make it easier to evolve the code rather than harder.

It is possible to be a good developer without that skill, but learning and practicing the skill will make you better.

This only comes up if you have data that isn't bundled with logic: as long as there is some logic to test, even enums end up with full coverage.

The outstanding issue with Java code coverage tools is switch statements, because there are unhandled paths generated by the compiler, but there is an easy solution: don't use switch statements. Enums are basically always a better option anyway.

Your assumption that they generate more revenue is sexist and incorrect. In 2015, when the complaint was made, the women's team raised more revenue than the men's team: https://www.si.com/planet-futbol/2016/04/06/uswnt-us-soccer-...

(The reason is simple: the men's team sucks, while the women's is one of the best in the world and is the only reason why the US has ever won a World Cup. The revenue discrepancy would be even more, of course, if both World Cups received equal rewards for winning.)

You are probably correct, though, that sexist assumptions like yours are why they are paid less. You aren't helping your case about how we should assume the best of the people speaking out in support of discrimination, though.

Certainly once you control for mechanisms by which discrimination is enacted some of the effects of discrimination disappear. I don't understand why people think that is exculpatory rather than explanatory, indicating which interventions might effectively address the discrimination.

This is interesting less for the science and more for the conflicts between different camps of "rationalists" about what "science" means. Especially given that the "rockstar physicist shows up with a model, gets angry when everyone doesn't accept their conclusions" dynamic is hardly unique to paleontology.

https://tldroptions.io is all about estimating the approximate upside under a wide variety of exit scenarios. Even the basic answer ends up being “it depends...”

One of the prime advantages for me is that I could find a company with women in leadership roles and I could interview everyone at the company before taking the job. I am absolutely willing to give up monetary compensation in exchange for working in an environment without sexual harassment, where I can have a significant cultural impact and with fair compensation & career progression.

The downside is that there isn't a good way to find startups where that is true (and especially not where it is actually true rather than just PR), and it is not what startups in general are known for. I networked my way into this particular spot, but if I were looking for another similar opportunity I'm not sure where I'd look.

Well, she didn't disrespect Wu-Tang.

More seriously, this is why often people who know they've been caught dead-to-rights settle early: the government wants the W and doesn't want to have to spend money to get it. Shkrelli made them go for the conviction, and so he got the actual, un-discounted penalty.

The advice is not all bad. I certainly agree that slicing a problem into small, concrete steps that can be achieved in less than a day (and then less than an hour, and then in the next five minutes...) as one of the central skills a programmer needs to develop.

I think what is missing is the exploration of how thinking of ourselves as "smart guys" makes us worse at our jobs. Intelligence isn't a substitute for being a good programmer. Churning out lots of useful, dependable, maintainable code involves a large body of acquired skills, habits and knowledge. When we pretend what matters is how "smart" we are, we get defensive when we get advice that we could do better, because "what, are you calling me dumb!?!!" We also blame other people's mistakes on their lack of intelligence, instead of considering how they could learn or how the system could change to better support them.

Study after study shows that a growth mindset leads to better outcomes: programming should embrace it.

This has interesting implications for organizational dynamics: the more you can allow people across the organization to innovate, rather than relying on promotion and formal recognition to pre-pick winners, the more likely the company will benefit from future luck. And it may be more valuable for a company to hire a bunch of people who are just "good enough" than one person who is a super-genius, because it makes it more likely the company will get lucky.

This is why Sarah Mei's idea of Livable Code is so exciting to me: it talks about context-dependent quality code, and lets us talk about developing the context needed to move our definition of "quality code" to a more effective/more reliable/faster/faster-to-develop place.

I think we tend to forget this because we so often muddy management and technical work, but management's job is to tell you what to build. You are the professional and it is your job to know how best to build it.