mason55

Yes, ultimately if you don’t have a clear vision of the problem you’re solving and the value you’re providing then success will be impossible. And most people confuse building features with providing value or solving a problem and so most projects fail.

If you’re able to define the problem you’re solving and what counts as “solved” then success it’s much easier. It’s also much clearer from the start when a problem is intractable. And it’s easy to tell if you’re not ready to start building yet.

> I would have imagined that most people with CF already had extreme anxiety - wondering when the infection that is going to end one's life will arrive. Is it really possible that Trikafta is causing noticeably worse anxiety?

There's a discussion of this in the article. Essentially, a bunch of people have said that they started experiencing extreme anxiety when they started Trikafta, and that stopping or lowering the dose helped immensely. However, clinicians have said that there's no actual evidence that the Trikafta is causal.

So it seems to be a bit of an open question and I'm sure an emotional one on both sides.

One problem is that there's a major lack of language support to make this easy.

IMO, every ID should be its own type. You shouldn't have a bunch of objects that have an ID of type string, you should have a User object with an ID of type UserID and a Post object with ID of type PostID, and then the compiler solves a lot of problems for you. Or make it so your functions that interact with the outside world accept a String, but they only return ValidatedStrings, and your internals only accept ValidatedStrings (and there's only one way to turn a String into a ValidatedString).

But in any kind of language with structural typing (e.g. TypeScript) this doesn't work, by definition. You can call a string a UserID and you can call it a PostID but if they're both Strings then you can assign them to each other.

And in Java, the concept of a typedef-like operation doesn't exist at all (I can't speak for .Net).

There's a whole class of bugs that go away if you allow for easy, nominal typedefs, but it's actually not easy to do in most statically typed languages.

> Why can't I as a regular retail investor trade a stock on Saturday?

Markets have chosen to concentrate trading to specific hours so as to concentrate liquidity and to help out the professional traders. If everyone's trading 24/7 then it means you need to be prepared to trade 24/7. Having defined market hours means defined hours in which important things can happen. And since the people who work in the market can also define the hours, they've chosen to give themselves reasonable working hours.

In a world where the major markets are trading 24/7, traders need to be at their desk 24/7.

> Why can't I move money from one bank account to another on Sunday?

Instant money transfer means instantly draining someone's bank account with no recourse. Checks have plenty of opportunities to stop the money, so you can write a check on a Sunday as easily as a Wednesday. Wires are more irreversible and so you can only send those when the bank is open and there's someone to double check any suspicious behavior.

Yeah if you look at products that went from good to bad and started getting good again, it’s almost always due to competitors starting to have an impact.

People will disagree with me but Jira is getting a lot better lately and I’m convinced it’s due to competition that popped up because Jira sucked so much.

The challenge is going back to a mode of building a good product again. Not only do you have to notice that you’re losing and be willing to invest again, you have to kick out all the extractors and convince the craftspeople to come work on a product that they all think is a piece of shit.

Whoa, I just recently started having issues with my watch battery dying overnight when it used to last without any problems. Guessing it’s the same thing.

If someone's targeting me specifically then I feel like it's easier to just watch my house in person. Plus there are all the neighbors with (I assume) their doorbell cameras that would also have my house in view. And this threat would have to, I don't know, run CV on the feed from my camera to see when I leave or when my car leaves, then figure out if everyone in the house left so they could break in?

For this to be worth doing with hacked cameras instead of in person, you need to be monitoring a lot of camera feeds. But to get any useful info out of it, you need to spend a lot of time putting together data about a single feed. And unless you've already evaluated the target, you don't know which feeds are from valuable houses.

I just don't buy this as a real threat for any but the most valuable targets.

I have an Amcrest doorbell and run amcrest2mqtt which sends messages that get picked up by Home Assistant. Keeps everything local and means I don't have to pay for a Ring subscription.

My only complaint is that when I blocked the doorbell from the internet, it just started rebooting every few minutes. If I cared, I'd tape over the camera, but I'm not too worried about someone spying on my front yard via my doorbell camera.

> Fingers crossed [...] that Harry doesn’t begin to think that the phone notifications are something to trigger his anxiety

We have essentially the same thing and I can confirm that my dogs now freak out at the critical alert sound on my phone.

If you know Kazakhstan is the biggest then you can get the rest. They're alphabetical going clockwise from Kazakhstan -> Kyrgyzstan -> Tajikistan -> Turkmenistan -> Uzbekistan

The other way to remember is, if you can remember that Kazakhstan is the biggest, then it goes alphabetically clockwise.

Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan

Neighborle is an ok daily geography game. If you're really good at geography then it's probably too easy but every couple days one of the puzzles actually makes me think (usually stuff on the Atlantic coast of Africa).

It's unclear. The Lions also weren't running down the play clock. Possibly everyone just accepted that the game was over and the Lions didn't run down the play clock and the Bucs didn't use their time out.

Or Bowles mentally marked the game as over and then didn't notice the Lions messed up with the play clock.

A good search term for this is "opportunity-solution tree". Basically what you said, first you identify a business opportunity, then you customer-facing outcomes that would help you achieve the business opportunity, and THEN you identify solutions that help deliver those customer outcomes.

E.g. You discover a business opportunity to build a simpler confabulator. Step one is to identify the different possible outcomes for customers that would indicate you had successfully built something simpler. Identifying what that means is actually hard. Maybe lots of people say they want something simpler, but to some people that means "less data to manually input" and to other people it means "better guidance in the configuration process". So there's value in this step on its own - it helps clarify your thinking and gives you ways to know if you're successful. And THEN you can identify solutions to help achieve those customer outcomes. Maybe for the "better guidance" one you have possible solutions of improving the UI or integrating an LLM to answer questions. But since you've tied it to a real outcome for customers, you can do a better job evaluating those options.

It's hard work but the process does a much better job leading to coherent solutions vs. "bucket of features".

> The US government has much stronger checks and balances than most parliamentary systems where the prime minister is elected by the parliament. This means that there's no split possible between the executive and legislative branch. I think the result of this in the US is that the government tends to deadlock, and has a lot of difficulty compromising, which leads to dissatisfaction and instability. Conflicts heighten without compromise or resolution for decades until they reach a breaking point. In a parliamentary system, the need to build a governing coalition can result in greater incentives to compromise.

Yeah, if I understand, the original idea of the checks & balances in the US was that each branch of government would be fighting to become the most powerful and so they all had ways to stop each other. But it wasn't really designed to deal with the idea that political parties would grow in power enough to supersede the branches of government as the top-level entities fighting for power.

This idea that you'd be able to form a large enough coalition across Congress, the Supreme Court and the Presidency that you could get all three branches to work together wasn't really considered back then. With more localized politics that was basically impossible and so the individual branches were fighting for power.

Our form of government should be updated to reflect the reality of more powerful political parties.

> Docs especially fall into the common trap of handling the happy path hello world quickstarts, then become increasingly useless as you want to get beyond that to real life use cases.

Yeah, Java is what I'm most familiar with. The "Getting Started" shows how to do some basic manual instrumentation and collect the output with curl. Then the "Next Steps" are just random things with no guidance about why I would or wouldn't choose any of them for my next step.

But, ok, I choose "Automatic Instrumentation", that sounds promising. And it actually is really easy to set up auto instrumentation. But then at the end it says

> After you have automatic instrumentation configured for your app or service, you might want to annotate selected methods or add manual instrumentation to collect custom telemetry data.

Uh... no... after I have automatic instrumentation enabled I want to do something with the output

The two major flaws in the docs seem to be

1. The common failure of docs to explain to users why they might choose one thing or another. "If you want to do x.. If you want to do y.." what if I don't know?

2. Because otel is agnostic to the consumer of the output, there's very little in the way of explaining how to get value out of what otel produces. To connect the dots, you really need to use the docs of your observability tool. Which I understand, but then most of them have their own setup directions because they want some extra fields included in the data, or they have their own fork, so not everything in the otel docs is actually usable.

I'm not sure what the answer is. It's not like I expect otel to document how to build a dashboard in Grafana. And a lot of frustration I've experienced has been with the observability tools themselves. But at the same time, I always feel like the otel docs just don't get you anywhere close to getting value out of the library. Which is a shame, because turning on auto-instrumentation and seeing all your traces with literally no extra work is a magical moment.

> The only metric that matters and one streamers keep tight lipped about, is how many people viewed the show.

I believe the new WGA contract is forcing them to release numbers now. NFLX just did a big dump a few weeks ago.

Funny. On the other end of the spectrum, I have zero. My dad was an only child and my mom’s brother didn’t have any kids. I have one sister.

Family events are not a thing for us.

> Because if you use the service you know it is capable of that and more today.

The numbers show otherwise and the FCC made it clear that Starlink presented no numbers to the contrary. This isn't even a case of the FCC's numbers saying one thing and Starlink's numbers saying another.

I totally believe that some places give you consistent 100/20 speeds, but aggregate numbers don't show that and Starlink made no attempt to argue otherwise.

> no, because the only reason Starlink doesn't currently hit the metrics is due to them having so many users joining. They could hit the metrics by temporarily halting signups, cutting off users, or delaying the Pentagon's massive deployment project.

I admittedly don't know much about this process, but with a billion dollars on the line, why wouldn't they have presented these options? It's not like this came out of nowhere, Starlink knew that they were not meeting their obligations and was given a chance to present their case.

I don't know, it just seems like it would be pretty easy to halt signups for a month, show that speeds increased drastically as my launches got ahead of my signups, and then explain to the FCC why this would be the normal state of affairs at some point in the future. Or, don't even actually halt signups, just make a convincing case about why halting signups would drastically increase speeds, and by 2025 you plan to do whatever you need to do to hit that 100/20 metric, but right now you're trying to do the most good for the most people, which means more signups and lower speeds.

For a billion dollars, these all seem like easy & obvious arguments to make if they were at all viable.

Anyway, I think that if Starlink can prove that they're making progress towards their commitment, they become eligible for the subsidy again, so if halting signups is really a viable strategy and they really care about the billion dollars then it seems like they should do that.

I think the key, as it is in most cases, is the "why". Sometimes there really are urgent deadlines that you really need to hit. Imagine you're building an app for the Super Bowl - if you miss that date then the entire thing is a waste. Other times the deadlines are made up or self-inflicted.

Understanding the difference and communicating which is which are one of the things that make a good manager/exec. If you're constantly telling the team "this feature needs to be done yesterday" you'll lose their trust very quickly. If you're good about saying "this thing is important and we can forget the rest" or "I know we don't do this much but this date is really important for <good reason X>" then you really build trust with the team.

Most engineers are smart enough to understand when dates are bullshit and when they aren't. If you push a lot of bullshit dates then you won't get the good effort when you really need it. If you don't trust the team to work hard without bullshit dates then you should find a new team.

> I suspect it would be better to allow multiple PRs per story

Yes. Stacked PRs are one way to accomplish this. Another would to have the dev write smaller tickets for PRs and then PRs are attached to tickets from the tech team.

Anything that relies on product understanding how to write a ticket that is the right size & scope for the dev team to create good PRs is doomed to fail.

> Every time I hear this claim "It's not that it's 'woke', it's that it's a bad movie" I ask myself: "what does 'woke' mean, then?"

I think the idea here is that "woke" is a loaded and controversial term. Even people who agree that "woke" movies are, by definition bad, can disagree on what exactly "woke" means.

But for these movies we can skip that whole argument because even if you forget about the wokeness argument, the movies are still bad. Even if all woke movies are bad, you can have bad movies that aren't woke, or are both woke + bad for other reasons. By removing the wokeness argument it makes it easier to form a consensus that the movies are still bad.

It’s absolutely intentional, they made a blog post about it.

> ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk.

Once you get to this point, there's no path forward. Either you have to making some breaking changes or your product is calcified at that point.

If this is a real concern then you should be asking what you can do to keep from getting into that state, and the answer is encapsulating services in defined interfaces/boundaries that are small enough that the team understands everything going on in the critical database layer.

Yes. If you look at, for example, Amazon's offerings, this is how they use the terms.

> HA in particular makes it very easy to chose how to install

This is the problem with lots of stuff similar to HA when it tries to break into a non-enthusiast audience: people don't WANT to choose how to install it. Most of the time they have no clue why they would choose one thing over another and giving them those choices is confusing and overwhelming.

It's like starting a an intro to Nix tutorial with by asking if the user wants to enable flakes.

I say this as a very active user of HA & Nix for 5+ years.

The difference is actually copying the data vs. copy-on-write. With the latter, you can make infinite copies without worrying about how much space you're using or the time it takes to make a copy, thus making it feasible to start with a fresh copy of the prod DB before you do literally anything. Have CI/CD create a fresh copy before every test. Have every feature branch start with a clean copy of prod and give people a button to do it again if they mess up a migration.

COW unlocks a ton of interesting use cases. It's easy to do on AWS Aurora but unfortunately their minimum instance size is way bigger than the regular RDS instances.

Well, that's why the word "official" is in there. Obviously you could mock up the entire github actions scaffolding locally and have it inject environment variables and support all the actions and everything, but keeping that up to date will be a nightmare if you're doing it on your own.

Obviously you could put the whole CI/CD into a bash script and not use any features or functionality provided by github actions but there are plenty of nice things that it does and it would be a shame to not use any of them.

> It is against the law for holders of nonpublic material information to use the information to their advantage in trading stocks.

The US and Europe differ on how exactly this should work.

In Europe, your view is correct. In the US, it's about obligation. You can trade on material non-public info if you discovered it on your own without doing anything illegal.