skysight-inc/HackerNews huggingface dataset:
The legal limit might be 70mph, but when traffic is not heavy it typically flows much faster than that in my experience. I used to make a regular commute along I95 through Delaware, and even though the speed limit was 55 (later upped to 65), it wasn't uncommon to be going 75-80 alongside other cars. Not everyone went that fast, but most people seemed to. Note that the speed of traffic hardly changed when the limit was increased.
It is true that becoming rich requires luck. So does completing college, landing a plumbing apprenticeship, or learning how to race a horse.

I see life like I see poker. You need to learn enough about the rules to know when the odds are in your favor, then make your bets to take full advantage of the odds. In life, raising your skills in specific and deliberate areas will improve your odds. Then, you have to have enough agency to make the bets.

Is that a guarantee that you'll achieve wealth? Certainly not. But you can learn how to improve your odds, and then take actions to put yourself in that improved position, and then be persistent and attentive to your progress. Analyze, adjust, optimize.

Persistence is the thing, and by persistent, I mean over decades. If you're a solid poker player, you can make money over time. You may or may not ever have the right luck at the right time to win a major tournament, but you can still make a living at the vocation you choose. It's the same in building wealth. Have a deliberate plan that his high probability, but be open to identify windfall opportunities, and make a bet if you see the odds are worthwhile.

There were a few deliberate choices I made to grow wealth. Each also took some amount of luck to transpire:

- Choice: I put myself through college. My parents couldn't help, I had to pay for it myself.

Luck: There were state and federal loan and grant programs to help with the cost, or I'd never have finished.

- Choice: I decided to major in computer science instead of music.

Luck: My dad's advice was that I'd be able to afford a more comfortable life in computer science. He'd chosen music.

- Choice: I made the choice to move to Silicon Valley from the Midwest. That's where technology seemed to happen first.

Luck: The only way I could do that was by living rent free for 3 months with a friend in Santa Clara that I happened to know.

- Choice: I intentionally asked by boss for more responsibility.

Luck: The company was in a growing market and needed engineering leadership. Promotions and raises followed.

- Choice: I developed a business plan to open a new sales/services office in a foreign country.

Luck: I had spent a lot of time traveling to that country on business and made friends with the people who established the business based on my plan and hired me. It was a lucrative choice.

- I chose a lifestyle that left extra $ in the bank each paycheck, and then invested that money.

Luck: My partner happened to have conservative approach to money management, and I listened to her.

Each step was about improving my odds. Once I determined what to do, I had to find a way to make it happen, even if it took other people's assistance in some way. Finding that assistance at hand was the lucky part. I just had to have the agency accept it and act.
This is... kind of precisely the distinction between technical leadership in a medium sized team vs in a really large team. It's one of the hardest challenges I work with senior devs to overcome as they move up to larger and larger scoped roles, up to principal engineer positions. Because what they have learned that got them that far stops working as they develop into more expansive roles and responsibilities.

Basically, the problem solving approach of 'I'll go away and work out how we're going to do this, then bring back a masterplan', while it offers a good path to successful project delivery early in your career, does not scale.

What worked for you when you were building a system with one or two teams working on it for three to six months is not a viable approach for systems which will have five to ten teams working on them, over multiple years.

You have to adopt approaches that decentralize decisionmaking - else you'll become a bottleneck; you have to adopt approaches that are adaptable to information that will be uncovered later and to requirements that will shift; you have to adopt approaches that acknowledge that you are never going to be 'full stack' enough to be able to make smart decisions about every single part of the solution - the mobile apps, the backends, the financial system integrations, the frontend caching, the analytics and reporting... and you need the expertise of different teams to deliver that.

You basically have to unlearn the pattern of 'let an experienced person set out the whole plan' that has been successful for you so far as you move to higher level leadership roles.

As a principal/staff/whatever in a big engineering org, your role is much more about making sure that the right people are having the right conversations and negotiating the right boundaries and not getting caught up on artificial constructs they think are being imposed by you from above. You need to leverage all the intellectual capabilities of the senior engineers on every team, not tie their hands by thinking you know more than them.

Same as as you become more senior, you shouldn't be writing critical code - eventually you also get too senior to be making critical architectural decisions.
Package managers solve distros' own problems. For an outsider, it's still a massive pain.

Distros are usually tied to specific versions of libraries. Your package can't require a library that is too old or too new, because the distro won't have that version, or won't install it, because it'd conflict with other packages. The way around it is to prefer static linking, but then you're reducing the whole dependency and packaging system to just being a zip file with extra steps.

There are many package formats, and many distros with different versions. It's a PITA to set up a build farm for everything and keep it from bitrotting.

And even if you build a two dozen packages, you need to help users download the right version, and tell them how to install it (my pet peeve in many distros is that when you double-click a deb/rpm, they won't offer to install it, but browse it like a folder or treat as an unknown file).

All of this is so much more fuss than "Here's your Windows.exe, or Mac Universal.app".
Big fan of the two you mentioned. A couple more to add would be:

- Use black to format your code. No exceptions.

- Very modular code.

- Tests, although this costs time of course. Focus on meaningful rather than trivial ones if needed.

- Write comments explaining reasoning for particularly dense pieces of logic.

If you practice most of the above, hard to see where you can go wrong.
> I have to tell myself every day not to go do the POC

What is a "POC"?

Side Rant : It's really helpful if an acronym is at least expanded in the first use. I don't find the acronym in the article or the parent comment. I am not sure why and how this is a norm but it's frustrating as someone who wants to understand a conversation.
The best way to value startup equity is based on their last valuation. Then you can quickly compare the offer apples to apples to cash offers. Obviously startups don't like this when you figure out the 50k shares they offer you is only worth $10k a year at current valuation.
The privatisation of the railways was always a complete and utter fudge. Not that the nationalised system was any better, but privatisation hasn't been exactly a resounding success for market forces either.
Is there quick primer on what and why of state machines?
Anything can be a weapon if you use it as one. That doesn't mean they are meant to be weapons.
Would wearing gloves prevent DNA from appearing on a wooden handle?
Seems zheap didn't make it this time either?
> 5. The “right database for the job” syndrome

I once saw something a little similar to this, except with one flavor of DB rather than several.
A company you've likely heard of went hard for a certain Java graph database product, due to a combination of an internal advocate who seemed determined to be The GraphDB Guy and an engineering manager who was weirdly susceptible to marketing material. This because some of their data could be represented as graphs, so clearly a graph database is a good idea.

However: the data for most of their products was tiny, rarely written, not even read that much really, even less commonly written concurrently, and was naturally sharded (with hard boundaries) among clients. Their use of that graph database product was plainly contributing to bugginess, operational pain, mediocre performance (it was reasonably fast... as long as you didn't want to both traverse a graph and fetch data related to that graph, then it was laughably slow) and low development velocity on multiple projects.

Meanwhile, the best DB to deliver the features they wanted quickly & with some nice built-in "free" features for them (ability to control access via existing file sharing tools they had, for instance) was probably... SQLite.
It would be nice to not need pgbouncer
This one doesn't includes GNU, but it is required for building it. I like the idea that knowing GNU/Linux like this allows for some makeshift tools to salvage or recover from situations that would be lost without it.

Needs a server or router and all you have is an old computer with some NIC's? All you have is a pendrive and needs to recover some files from an unbootable machine? Do not have msword but can use gzip and grep and wants to extract text or images from a docx? Got an old computer without harddisk but working floppy drive and needs linux running on it? Need to send an SOS AM signal and all you have in an old CRT? A modern linux distro with a few dev packages and system tools is like a digital swiss army knife on these situations.

Some of these scenarios are stretching the reality, but some are not. These skills are the modern IT equivalent to MacGyverisms.
You only be hit by a tax bill if you chose to exercise the option, which only make sense if the stock is worth more than the strike. If you are "given" something that is worth more than $1, the IRS will want a piece of it.

If you worked at a startup (not a small business), the most likely outcomes after 4 years is either 1) Company went bust, 2) Company grew.

The option protects you from the not having to pay anything if scenario #1 happens. If scenario #2 happens, then you should be happy: you have an option to pay X for something that is usually worth multiples of X after 4 years.

I actually think the IRS is being nice not to tax the at-the-money option grant. They essentially assume zero time value, which would be quite high for a startup given the high volatility and the potentially long term for the option.
Commodore 64 Software Development Kit
Yes, it's a do-while loop.

It takes two arguments ("cond" and "proc") which would both be bracketed lists.
"unless" is common sugar for a negated if statement.
"run" evaluates a list as an expression. You'll notice that if/unless also take their bodies as lists, rather than any sort of special-purpose block syntax.
"stop" short-circuits the current procedure and immediately returns.

Since Logo has dynamic scope, any variable references in "cond" and "proc" will resolve the same within "while" as they did in its caller; no nasty visibility surprises. Since Logo does not eagerly evaluate lists, there is no need to "quote" or otherwise escape the lists in the caller's context. It is precisely that one can define such a construct without defining new syntax per se that is useful.
Australian Aboriginal Memorization Technique Is More Effective Than New Methods
This has a real "I've read Rand and I'm using cocaine" vibe.
Oh man. Just got that!
Right. The McDonald's food is generally higher quality.
That’s true, but the entrepreneur owns some piece of an income-generating asset. If the exec stops working, their income immediately goes to zero, and if they didn’t save or get some equity, their wealth could be near zero too. The entrepreneur can stop working, but still be left with both income and a valuable asset (their piece of the business).
Unfortunately what you're describing never actually occurs in practice, unless you're simply rebuilding an existing piece of software, which has only technical improvements (ie. better performance, fewer bugs, etc).

The cases where you are starting from zero are also the cases where you don't understand the problem domain to a sufficient degree. You can try to get clients involved earlier, but that is very dangerous:

- It's hard to get a sufficient diversity of early users.

- Clients are incapable of prioritising what's important. Everything feature they think of (even the things they won't actually use) will be essential to them if you ask.

- The actually essential features will be so obvious to them that they won't even think of mentioning them.

- They don't understand abstractions: any concept you try to define with their help will become amorphous and therefore useless.

- Engineering is fundamentally subtractive: with zero code a product could eventually do anything. As you add code, you are restricting what it can do so that the results are the "useful" ones. For example. when you create a "user" table with an "email" property, you are restricting users to have one email address. You cannot make progress without these restrictions, but if you actually spell out those restrictions, you'll get massive pushback.

This is why so many engineers like building things for other engineers - because they can be their own client.

It's also why it's impossible in most cases to go from zero to a well-architected product in one go.
I sometimes seriously wonder if you born around the 1960s, how didn't you become a millionaire?

Rents were lower, wages were higher, safe investments like T-bills and CD had higher yields, homes exploded in value, education and health care were a fraction of the cost. If you worked at even a minimum wage job you were on track to being a millionaire just by putting money in the bank.

I asked my parents about this recently and it turns out they actually are millionaires... I knew the were well off, but thought they had a third or a quarter of that, I literally had no idea.
Could you do this with regular Patreon?

I am not familiar with details how exactly it works, I guess you are supposed to provide some media to your subscribers, but I guess you could simply publish videos from your training, or make a vlog before/after a competition. The idea is that people would not pay you because the videos are super awesome, but simply because they are your fans.

The subscriber tiers could be like "sponsor", "sponsor who gets autograms", and maybe something special for those who pay really lot.
? What's wrong with pg_upgrade?
Most doctors retire with millions if they want. Pediatricians make more than most engineers
Only if you own them, right? Otherwise they are just debt you owe a bank.
My father tested negative for spike specific antibodies 2 weeks after the 2nd Pfizer vaccine (he's not the only one), and as I didn't find any data on people who test negative (and I know that the vaccine has 94% efficiency preventing COVID), he's still mostly not leaving his apartment.

He'll have a test against the viruses themselves next week, but he'll need to wait 2 weeks for the result for that test.
I don't agree. There is a big difference between "there will always be some grey areas" and "it's all a more or less uniform grey". Your warning of the dangers of dihydrogen monoxide reads more like a joke than serious attempt to misinform, because the reader will presumably know that everyone drinks water and most people who have lived are now dead. But it isn't too hard to come up with similar statements where anyone who knows the actual facts will realize the statement is intentionally misleading, whereas people who don't might be mislead.
You got your answer: seriously, just do a cursory search about the reliability of eyewitness testimony.
You really can do all of these things and you don’t have to be very smart.

AirBnB exists, for example. There have been people who sleep in trains and rent out their apartment in their absence - it’s not fun, but it does reduce rent.

Potatoes can be grown, for example.

You can shop around for a place where utilities are included, for example - and many utility companies will give you rebates to do things that lower your bill.

None of these are really a path out of poverty though.
It’s a risk you were capable of taking. People without family they can depend on cannot take these risks. If some of us fall we fall into homelessness, for others their parents just bail them out. The people that risk homelessness do not start startups.
> You forget one value in your dependency list and the weirdest things happen.

There's an eslint plugin specifically for detecting this, which should probably be considered mandatory.
at my work, I'm a principal and my boss is a partner. he spends a lot of his time doing organizational stuff and coming up with plans to solve problems, but he also still writes PoCs. he'll take the downtime he has between meetings, solve the really hard parts of the problem and hand it to the team for incubation. I do the same thing now - I pitched an idea which requires a fair bit of pure research, and I'm going to get a rough prototype going that vets the idea, then build out my team to make it better and turn it into a robust product.

the trick is to keep the PoCs lean enough that it's easy for your reports to flesh out and change the architecture as they need, but developed enough that it's working code, so people can run it and start working from a grounded product.
American here. I feel like I’ve heard both ways about equally. I’ve lived all over, so maybe it’s regional.
This also has something, if not, a lot to do with millionaire farmers, mostly funded by incredible and often corrupt subsidies from the government. So before subsidies and pork, they would have made a more modest wage, but the game can be abused pretty easily. If its not designed to be abused because what benefits big agriculture also benefits medium sized "family" farms. Family farms may actually be a series of a dozen or more farms where the owning family does no actual farming on their own, but still live a rural lifestyle (pickups, bud light).

Secondly, its also skewed by government workers on fat pensions who can become millionaires pretty easily due to these collectively bargained benefits but also inflated salaries, especially overtime which is often abused in government jobs.

Lastly, a lot of this is self-reporting. Some people like to put on a modest front for their own reasons. The author got to see their pickup truck and muddy workboots, but not their Florida vacation home or Wisconsin lake house. Or the Corvette under a cover in the 2nd garage.

So some of the advice is hard to handle and not applicable to most. You can sort of FIRE your way into wealth and live like a miserable miser or hope you were born into a socio-economic culture where buying a lot of farmland is possible or getting a public sector union job is possible.
It might be easier to think about these numbers if you know that the average mass of an amino acid is 110 daltons. So 180 kda is around 1,600 residues.

From this paper https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3055910/

> Peptides from 10 to 30 kDa typically fold into a single domain. Peptides larger than 50 kDa typically form two or more domains that are independently folded.

So most larger proteins are formed from complexes of smaller ones. That said, there are some amazing examples, such as the proteasome, or the vault.

See https://pubs.rsc.org/en/content/articlehtml/2015/cs/c5cs0015... for more detail
The same applies for increasing your income - if you can't afford to be without a job for some time, then you'll earn less money since you can't credibly negotiate a pay increase, your situation shows and you'll have to take a lesser offer.
Also being able to procreate and reliably raise children (also with physical help from servants) is probably a bigger wealth enhancer, especially over generations.

In our modern world, being poor means you are going to either not procreate, or suffer while doing so. An iPhone does not cure that.
The idea that eyewitness testimony obviates the need to examine hard evidence is absurd, given how poor people are at providing accurate eyewitness testimony. It’s not that DNA evidence is perfect, it’s that eyewitness testimony is hot garbage.
>Never meant to, just pointed to a direction that you seem to be unaware of.

What gave you that impression? In my initial comment I acknowledged the concept of excusing suboptimal decision making due to "psychology of decision making when poor and struggling". How is that different than what you're saying?
>houses and cars are assets.

I would guess that the majority of people do not own their house outright. Just because you have a mortgage on a one million dollar house, doesn't mean you have one million dollars worth of wealth in your house.
More discussions about whether ownership can be tacked onto another language.
I very rarely write macros but Elixir is much, much nicer to work with for having them.

Probably my favorite overall library in Elixir is Ecto. It's the go-to relational DB library and makes great use of macros for its query syntax DSL. The Phoenix router, controllers, etc also benefit quite a bit.

The thing that makes Elixir's macro implementation a really big win for me as a user is how explicit it is.

There is never a case of hidden magic. Just as you can see what functions are brought into a module by scrolling up and looking for the keywords "alias" and "import", you can find macros by looking for "use" and "using". This is very different from JavaScript, where another module could alter the prototype chain or overwrite attributes on any non-const object it has access to.
Why is it nuts? Being fluent is all about implicit knowledge.

> we Brits don’t know the rules

Every native speaker of English in Britain knows the rules - implicitly. Which should be good enough for non-linguists.
If you are injured or get sick in that situation you can fall into a hole that you never get out of.
There is also Floppix, and their FAQ lists a few more [1]

[1] https://www.floppix.com/faq.html
An Illustrated Guide to Split Windows in Irssi
It's gonna be interesting to see how it will affect the kernel ABIs. High level languages have features that produce nightmarish binary interfaces and it's unrealistic to believe existing code will be able to interface with them. So will the code be restricted to a minimalist subset of Rust?
Author here. Yes, I made a series of videos about it, starting here: https://youtu.be/N0OaRdJuVlc
You’re right, a typo. Question still stands.
Somebody did the calculation of how many bitcoins we can mine with the energy released by burning the entire planet? That would be great
Key points:

Upside decay means that an organization doesn’t get any lucky breaks.

Upside decay is hard to spot. It’s invisible if we’re not specifically looking for it, because the absence of rare positive events is unexceptional.

Upside decay is preceded by a lack of virtue that leads to zero-sum or even win-lose transactions

Leadership choices

1. virtuous culture -> positive sum interactions -> weak ties help -> lucky breaks

2. unvirtuous culture -> zero sum interactions -> weak ties abandon -> upside decay

“The right culture, the highest and best culture, is a seamless web of deserved trust.” Charles Munger

Note: Clayton Christensen makes the same point for individuals who prioritize "winning" and "career advancement" over relationships in "How Will You Measure Your Life (https://hbr.org/2010/07/how-will-you-measure-your-life). Summary at https://www.skmurphy.com/blog/2020/02/16/clayton-christensen...