scott_w

30 ms·

511.
by scott_w 1y ago
They probably will but they’re the comparisons I have to hand and, let’s be honest, this entire discussion is based on anecdotes.
512.
by scott_w 1y ago
From playing video games, I'm going to say that generally games are more reliable today than they were in 2005, and I recall a few absolute fucking howlers from the 90s and 2000s (looking at you, Digimon World!) My comparison points: F
513.
by scott_w 1y ago
> I understand how it may sound like this, given that older people will talk about assembly and electronics which most young developers have absolutely no clue about today and are still considered "software developers". As a so
514.
by scott_w 1y ago
Ignoring the basics of a simple process doesn’t make the process “bad.”
515.
by scott_w 1y ago
So add yet more process and bureaucracy instead of following tried and true management techniques of having a synchronous meeting lasting 15 minutes every morning?
516.
by scott_w 1y ago
How? Meeting notes can never contain all the detail of the meeting and, if they do, there would be so much content that you'd likely miss them when you read the documentation. That's to say nothing of the time investment of the pe
517.
by scott_w 1y ago
When you get to that point, those two people should take the discussion outside of the sync call. The purpose of a sync is to figure out whether your current work is on track and, if not, who and what is needed to fix that.
518.
by scott_w 1y ago
> But you can share your daily status asynchronously as well. In practice, this is harder because people don't speak up unless prodded. And on Slack, I spend a lot of time and effort prodding people for that update, whereas a stan
519.
by scott_w 1y ago
The latter
520.
by scott_w 1y ago
From the OP: > It’s not the job of a bug reporter to figure that out What’s ambiguous about this statement?
521.
by scott_w 1y ago
> What do you disagree with, exactly? OP said it quite clearly and so did you: that it's the reporter's job. It's the maintainer's job to put in the bug report now.
522.
by scott_w 1y ago
As others have pointed out: if the complexity is in the domain then that's perfectly acceptable. I always remember reading some lines of code in Linux that had a comment above them: "This code is meant to be read by a CPU, not b
523.
by scott_w 1y ago
Just read Careless People.
524.
by scott_w 1y ago
> Well with that mentality this whole conversation is useless. Yes, it very well might be. Let’s look at the post I’m replying to: >> If it's free, people are suspicious and judge the cost to be something implicit, generally w
525.
by scott_w 1y ago
You're still inferring too much from it. Remember, this was a viral video, so there's also the simple explanation that it might have been staged. If it weren't, there are some really obviously, mundane, reasons that have noth
526.
by scott_w 1y ago
I'd be careful of inferring too much from things like this, particularly given how much criticism Freakonomics has received. One example from Youtube: https://www.youtube.com/watch?v=11eTG4_iwqw&pp=ygUVZGVhdGggb...
527.
by scott_w 1y ago
> the ICE gets stuck behind a slower train, increasing the delay, etc. Right here. Those slower (older) trains don't magically get any faster just because the train behind it sped up. > pack the schedule You actually can't j
528.
by scott_w 1y ago
I clicked on this report at random: https://hackerone.com/reports/2905552 This isn’t fuzzing, this is a totally garbage report that I’d have chewed out any security “researcher” reporting this to me. Given how it was t
529.
by scott_w 1y ago
> Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Look, I’m not the one making these arguments, I’m
530.
by scott_w 1y ago
> Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely
531.
by scott_w 1y ago
In the context of security holes.
532.
by scott_w 1y ago
> But when you talk about URL parsing in a linter or a regexp in logging code, I think you're implying that the bugs are unimportant, in part, because the code only handles trusted input. It is a bug but it’s not necessarily a secur
533.
by scott_w 1y ago
This reminds me of a thread a few days ago where I pointed out a similar thing you’re saying here. I think you make a strong case that, in the business context, this tie in is mandatory. It’s all well and good taking a principled stance on
534.
by scott_w 1y ago
Absolutely, you can still analyse the outcomes and try to draw conclusions. This is true even for A/B testing.
535.
by scott_w 1y ago
There is but you can decide that up front. There’s tools that will show you how long it’ll take to get statistical significance. You can then decide if you want to wait that long or have a softer p-value.
536.
by scott_w 1y ago
I think at that point you may as well skip the test and just make the change you clearly want to make!
537.
by scott_w 1y ago
Allow me to rephrase what I think you’re saying: Startups need to ship because they need to have a habit of moving constantly to survive. Stasis is death for a startup.
538.
by scott_w 1y ago
100% this. I’ve seen people get too excited to A/B test everything even when it’s not appropriate. For us, changing prices was a common A/B test when the relatively low number of conversions meant the tests took 3 months to run! I
539.
by scott_w 1y ago
This is a reasonable approach, particularly when you’re looking at moving towards a bigger redesign that might not pay off right away. I’ve seen it called “non-inferiority test,” if you’re curious.
540.
by scott_w 1y ago
> The consequences of getting it wrong are... you sell fewer widgets? If that’s the difference between success and failure then that is pretty important to you as a business owner. > do no harm, see if we're heading in the right

More ›