You're reading this wrong. The real ID (the Snowflake) is exposed in the API, and the UI if you turn dev tools on. That's the one I use. You don't use @username#1209 but 1247755691426542433.
The Central Limit Theorem (which says if we add a bunch of random numbers together they'll converge on a bell curve) only guarantees that you'll get a normal distribution. It doesn't say where the mean of the distribution will be.
Correct me if I'm wrong, but if your resistor factory has a constant skew making all the resistances higher than their nominal value, a bunch of 6.8K + 6.8K resistors will not on average approximate a 13.6K resistor. It will start converging on something much higher than that.
Tolerances don't guarantee any properties of the statistical distribution of parts. As others have said, oftentimes it can even be a bimodal distribution because of product binning; one production line can be made to make different tolerances of resistors. An exactly 6.8K resistor gets sold as 1% tolerance while a 7K gets sold as 5%.
> Tolerances don't guarantee any properties of the statistical distribution of parts.
That's incorrect. They, by definition, guarantee the maximum deviation from nominal. That is a property of the distribution. Zero "good" parts will be outside of the tolerance.
> It will start converging on something much higher than that.
Yes' and that's why tolerance is used, and manufacturer distributions are ignored. Nobody designs circuits around a distribution, which requires luck. You guarantee functionality by a tolerance, worst case, not a part distribution.
> The Central Limit Theorem (which says if we add a bunch of random numbers together they'll converge on a bell curve) only guarantees that you'll get a normal distribution. It doesn't say where the mean of the distribution will be.
That's kind of overstating and understating the issue at the same time. If you have a skewed distribution you might not be able to use the central limit theorem at all.
>If you have a skewed distribution you might not be able to use the central limit theorem at all.
The CLT only requires finite variance. Skew can be infinite and you still get convergence to normality ... eventually. Finite skew gives you 1/sqrt(N) convergence.
There's a discrepancy that the top comments here say that "some people can produce a ton of value by not caring about code quality" and "I didn't care about code quality and got bit later on". And people discuss that incurring technical debt with bad code can sometimes be worth it and sometimes not be worth it.
The logical implication of technical debt having an interest rate (i.e. It costs more to fix something later than now) is that like money, features have time value. This is what makes it worth it to incur technical debt.
Thinking about the implied interest rate of technical debt makes it easier to rank what should be prioritized for a fix. High interest debt should be paid off first. But you might also focus on refactors that reduce the interest rate, such as by modularizing your code so it's easier to replace down the line.
Btw, if you like the financial metaphor, then technical debt is a bit of a misnomer. 'Technical debt' behaves a lot more like equity you sold than like debt you issued.
In the sense that the 'technical debt' is only something to worry about in the future, if your project goes anywhere. But if no-one ever uses your product, you don't need to fix the 'technical debt'.
Thank you! I like the metaphors because they allow me to think about related variables. What metrics would I use to compare different technical equity options? Is there an implied valuation of my project based on the % of developer time I have to spend fixing an issue related to the feature value?
I learned this lesson when working on very fast paced projects with way fewer developer resources than needed. to ship a feature on time, shortcuts in quality have to be made, but you learn to make the shortcuts in a way that are easier to go back and clean up later.
My manager gave me gruff the other day for adding a TODO that I had no intention of ever doing. TODOs are like a get out of jail free card. Don't want to do something the reviewer is likely going to call out? Just add a TODO.
I still find them helpful when the change is outside the cope of the current task. I especially like the ones that include both a reference to a Jira ticket (or similar), and an explanation of why, or any gotchas:
# TODO: (CAFE-1256) Refactor steamed-liquid stuff to support non-dairy options
# We don't currently support non-dairy coffee additives, but once we do
# we will need to ensure that the steamed-liquid transport
# also alerts when users have a dairy allergy.
This is a lot of stuff to add for some things, so we might not want it everywhere, but it helps explain to a reader why we don't currently have it built (product doesn't need X yet), but also has hooks to existing (planned/canceled) tickets and is easily greppable (e.g. "non-dairy" or ticket name).
I've declared quality bankruptcy. Decisions are now driven by user needs. Did I half-ass that feature? Yes. Is anyone actually using it despite crying it's essential? No. Then it's not getting cleaned up. Are they not using it because it's shoddy? I guess we'll never know.
Any intelligent criminal will just meet face-to-face to discuss their criminal activities. None of these apps protect against someone taking a photo of the screen and snitching to the authorities about what was said in exchange for less jail time.
To be fair, criminals are (fortunately) not always intelligent, especially the rabble they are trying to catch; or at least, the "small fry" isn't, but that's precisely how - I suppose - they hope to catch the bigger fishes who may be more cautious.
it's pretty easy to do these days. even in the browser you can use WebRTC for P2P and Web Crypto on top and knock together an e2e encrypted messenger in a few hours. assuming you can trust the browser crypto of course.
I haven't confirmed this, but I would expect that creating E2EE chat that doesn't follow this new law would itself be prosecutable? Now criminals can be picked up for merely using secure chat, if the government can't easily get them for human trafficking/drug trafficking/whatever. Reminds me of how the twentieth century US gangster Al Capone was prosecuted for tax evasion.
Anyone who is not explicitly privy to a fully bespoke, end to end encrypted data transmission and retrieval system has no way to determine the function or purpose of that system.
It could be text, audio, video, raw signal bitstream from an IoT sensor, or a full duplex async combination of anyone of those.
It wouldn't be a "chat service" to an outside observer, it would just be seemingly random, opaque bits between two endpoints.
well, for example, you could roll your own secure messaging over WebRTC data channels using Web Crypto. There won't be anything unusual looking about the traffic as it will all be wrapped up inside DTLS/SRTP which is the transport for WebRTC. so, it's encrypted twice and would look perfectly normal to any outside observer. there's no way to tell what is happening in the messaging layer WebRTC "encapsulates".
At end of day, if someone wants to do this, there is no way, afaik, it can be detected. so, all these laws won't really help combating serious criminals who have some savvy.
If you're running a criminal organization, a bigger threat than a wiretap can be someone wearing a wire, so to speak. Talking about anything over text creates a ton of evidence about the criminal conspiracy that you are currently engaged in. That evidence can be screencapped or recorded or whatever else by the person at the other end of the conversation. Since you don't have physical control over that person, it's possible they could be compromised.
If you keep everything in-person, even if someone becomes a snitch, you can still check them for hidden recording devices. At best, this means the evidence against you is that person's recollection of your conversation.
This is the same reason why it's much harder to pirate a movie in theatres than one released on streaming. Physical control over the environment that information is disseminated in is the gold standard, just look at the US military:
A common good like security should be socialized because the alternative is multiple independent groups enforcing property rights, and when they start to conflict, you get a civil war won by the person who spent the most on security.
The idea that police are inherently corrupt because they developed from paid security forces ignores that the very process of development is what enshrined the rule of law over power.
I don't disagree that security should be a socialized good, it's a good idea. That doesn't change the fact that police in the United States and elsewhere were formed in the basis of law not to protect people but to protect property.
Even today courts have ruled that police are under no obligation to protect civilians from direct, inevitable harm. They are not there to protect you, they are there to protect "the peace" which can be fucking anything.
They are to protect order. So you, as a victim of a crime, are only a concern to them to the degree you make your harm public enough to disrupt order. Then they might attempt to solve a crime or make an impression they are doing something to prevent similar ones, but dissuading you from complaining too publicly about it (both by taking your report and showing it was useless) works just as well.
Let's also not forget that cops also pointedly refuse to their do their job when their feelings are hurt when people complain that they don't clean up the corruption and abuse in their ranks.
See: Chelsea Boudin and the SFPD. See DeBlasio and the NYPD.
> Even today courts have ruled that police are under no obligation to protect civilians
Yeah, LAPD's "protect and serve" was dreamed up by the City's marketing arm in the 1950s.
And those rulings have come because PDs have stood up and said "We have no obligation to prevent crime or protect people" and the courts have said, "Yup, you're right."
I'd love to disrupt the dating app industry with a non-profit charitable model.
There are many ultra wealthy people that recognize declining birth rates and population will destroy economic growth, and that this isn't a problem that can be solved with more competition.
In software, when there's a technology that can benefit everyone in an industry but individual control creates perverse incentives, companies will band together to create standards organizations or non-profits to harness the tech in a way that benefits everyone. This already happens with the Linux Foundation and open-source more generally.
Dating apps should have the same model because the negative externality of a perpetually single society is going to kill the economy and possibly destroy the world.
Taking a page from the Signal Foundation, it could have operating expenses of $50+ million per year. After bootstrapping for the first five years, donations might begin to recover 33% of the operating expenses per year. Even with extremely efficient software and lean operations, the expenses could probably be halved at best. Adjust for 5% inflation and 20% growth per year. I think this could basically be a national service as important as social security, but for the world.
>There are many ultra wealthy people that recognize declining birth rates and population will destroy economic growth
Hence the corporate and government push for open borders and mass migration despite citizen/voters opposition and the shift towards right wing populism.
> Being very good at most disciplines is about having the fundamentals absolutely nailed.
> In chess for example, you will probably need to get to a reasonably high level before you will be sure to see players not making obvious blunders.
To extend the chess analogy, having the fundamentals absolutely nailed is critical at even a mid-level, because the payoff/effort ratio in avoiding blunders/mistakes is much higher than innovating or being creative.
The process of getting to a higher level involves rote learning of common tactics so you can instantly recognize opportunities, and then eventually learning deep into "opening theory" which is memorizing 10 starting moves + their replies because people much better than you have written lengthy books on the long-term ramifications of making certain moves. You're learning a vast repertoire of "existing solutions" so you can reproduce them on-demand, because those solutions are battle-tested to not have weaknesses.
Chess is a game where the amount you have to lose by being wrong is much higher than what you gain by being right. Fields where this is the case want to ensure to a greater extent that people focus on the fundamentals before they start coming up with new ideas.
https://support.discord.com/hc/en-us/articles/206346498-Wher...
reply