I normally have `mtr 1.1`¹ running in the background, in the third display mode, which is a 2D histogram—time in the x axis, hops in the y axis, and ASCII character/colour for ping time. When problems occur, this tends to let you easily see the nature of the problem—total loss, elevated packet loss, elevated response times; and to see the location of the problem—local network, local ISP, public internet. There are definitely occasions for loss%, sent, last/average/best/worst/stddev ping and such things as are found in the first display mode, but most of the time I find the histogram view most useful as the starting point.
You can make mtr start in this view with --displaymode=2 (direct command line arguments, `mtr --displaymode=2 …`; or shell alias, `alias mtr="mtr --displaymode=2"`; or set environment variable MTR_OPTIONS=--displaymode=2).
I have often read books on topics I was already well-informed on. My philosophy is "think of it like a meditation". You might know very well about a psychological mechanism like the one described in Paradox of Choice (by Barry Schwartz) - you may have seen a TED talk and you already "get it". But it's rather different if you spent 10 hours of your life reading a variety of examples on the topic, and think about it (as you are reading it). The lesson sinks in far better - it is much more likely you will actually benefit from it.
We used this a couple times at Sandstorm back in the day. At the end of the interview the candidate would play Factorio cooperatively with the team for a while.
I think it is remarkably effective at identifying the kinds of skills and personality traits that a software engineer actually needs to have in day-to-day work. You can find out if someone is self-directed, how fast they work, whether they produce clean designs or spaghetti code, whether they are good at cooperating or tend to go off on their own, etc. Some people will just sit and watch and do nothing unless instructed... that's bad. Some people will build stuff, but with obvious efficiency flaws and "bugs"... also bad. Some people identify what needs doing and get it done effectively but without trying to be perfect... that's good. Factorio essentially compresses real-world work patterns into a shorter time period, giving you the chance to see how someone works in the space of a couple hours. I don't know anything else that does that.
But, obviously, it's problematic. A person who has played the game before will have a big advantage. A person who doesn't play video games at all will have a big disadvantage. For these reasons, I don't think I could seriously recommend this approach be adopted more widely.
But then, I don't know of any approach to interviewing that I think is fair. Everything has problems:
* Regular interviews bias towards people that are charismatic, not effective.
* Coding interviews bias towards people who can code under pressure with someone looking over their shoulder, which is almost nothing like real-world coding.
* Puzzle-y algorithms questions identify people good at clever solutions but that's hardly what most people need to do day-to-day when coding.
* Take-home assignments bias towards people who have lots of free time, and still don't really tell you how that person works with others.
* Looking at GitHub history biases against people whose lives are too busy to code in their free time (e.g. maybe they have kids) and who weren't lucky enough to have a previous job that touched a lot of open source.
* Looking at past work experience misses brilliant junior programmers coming out of college.
* Don't even think about using ML for this, that doesn't solve biases, it just hides them in a black box.
Great explanation. IMO the GameStop phenomenon is the result of the combination of democratization of trading through software (Robinhood no fee trading, doing it on your cellphone) + social media enabled mass scale online community building (around some previously fringe niche). Any area that is subject to this kind of combination of change could face similar situation where the old institutions guarding the area would face increasing challenge from grass root efforts ("retards/autistics" as in wsb's lingo).
No one objects that capitalism isn't a good optimization processes. Just that it's optimizing the wrong utility function. At one point something like 50% of STEM majors at MIT went to work on wall street. And the ones that don't go there go to work making more efficient targeted advertisements or addictive smartphone games or other unethical shit.
Our population has a limited number of "smart people". I don't think any alien looking in from the outside, would think we are allocating them even remotely efficiently. It would be pretty difficult to design a system that does worse than ours on this aspect.
The solution isn't necessarily communism, but perhaps a hybrid. E.g. the government funds things capitalism has no incentive to optimize for, like scientific research.
Google is using their vast profits from an unrelated market, tracking-based advertising, in order to subsidize their product in this market, that of video-streaming services. This is a textbook antitrust violation [1].
It is against the law to price a product below your costs in order to kill off your competitors and then jack up the prices later. This is what they have done by making it ad free for years, only to now force ads on everyone and upsell us to premium.
These laws exist to protect you, the consumer, by ensuring there is proper market competition for your goods and services. You should be up in arms about it because Google has illegally destroyed this market. This is why there are no competitors to YouTube.
Nature is important but people massively underestimate the nurturing component. Parents are most definitely key for these types of outcomes. If you're not familiar with the story already, read about the Polgar sisters. https://www.psychologytoday.com/us/articles/200507/the-grand...
To your question, my immediate answer was, "let them play outside". But it sounds dismissive of what you are asking. So the better answer is: provide them with the opportunity to learn, encourage their curiosity, praise them for their work not innate intelligence while still telling them that they are smart, create an environment that values and promotes education, create a program for them to follow when they show interest in a particular discipline, have great mentors help them develop, etc.
The truth is, there is always going to be a compromise between having a care-free childhood and top performance from an early age. You can't really have both no matter how smart your kids are. Asian parents stereotypically tend to opt for the latter end of the spectrum with, on average, very successful outcomes.
I think the problem I have with perfectionism, is that in a fairly connected world of 7+ billion people, the people that get "acclaim" are truly some of the most talented/lucky/good people in the world.
You never see mediocrity anymore, everyone has curated Instagram and Facebook feeds of their best moments. If you do see it, it's the process of something like America's Got Talent where it's laughed at.
Dave Grohl of the Foo Fighters said it really well [0]. Everyone that we see doing almost anything online is really really good at it, so people get intimidated that they can't do what 8 year old prodigies are doing. There is such a gap between good and great that people are afraid of taking the time to make the jump since the other side feels so far away. It's ok to be bad at things, it's ok if your art or passion doesn't change the world. It's ok if you enjoy the journey and the destination isn't the top of the charts or a world championship in whatever.
This reminds me of the following, from the book Team Geek[1], chapter "Offensive" Versus "Defensive" Work:
[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the
sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product
(e.g., code refactoring, feature rewrites, schema changes, data migra-
tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite
the fact that they’re absolutely critical, you get no political credit for
doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”
We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
There are a lot of "hacks" in this thread (put your phone in grayscale, put variable reward apps in a folder, turn off fingerprint sensor) but in my experience the mindset is by far the most important part.
What's worked for me (and the article talks about this too) is viewing my phone as a tool with a limited set of functionality. For me, that functionality is: calls, texts, Google maps, Spotify, Audible, podcasts, Uber, and a camera.
That's it, no email (technically have the ability to send an email if i need to, but no notifications and no checking) and no random internet browsing and twitter etc consumption. There are some blocking apps that might help with this, but the biggest thing is the attitude. Twitter in line at the grocery store is no longer what my phone is for. Not that reading tabloid headlines is any better, but the main point is stretching out your focus muscles, getting rid of the urge to immediately grab your phone anytime there's a lull or hint of boredom in your life.
Overall, it's nice. Almost like being back in the 90's pre smart phone but also with a super powerful computer that can play any song you want/give you directions to anywhere you need to go.
Just my two cents; I'm a father of 4 and I'm okay with not capturing those moments on film. And I mean that in two senses. One, I'm fine using my very imperfect memory to recall special moments and two, because of the logistical problems with grabbing the camera I'm not willing to risk missing out being fully in the moment. The occasionally photograph from an event or time period seems sufficient to conjure up the feelings from that time.
Regarding an always on camera - I'll second other comments in warning there are just so many concerns with abuse, I don't see how to get around those.
One of the main things I've noticed is that every person is different and therefore every team is different. Also teams evolve over time, so even when compromised by the same people you can look at them differently "each" day.
I think the management should start with observing and listening. By paying attention to what's going on in the team you can start influencing it by praising beneficial (e.g. helping to meat the team goals) behaviors and preventing the un-beneficial ones. Then of course, when you have expectations from people, its best to get them on board as soon as possible and not leave them wonder why they've been praised and why "punished". Providing clear feedback as soon as possible seems to really work.
Another big thing you should watch out is what kind of people you've got on your team - intrinsically driven or externally driven. The more intrinsically driven people you have the less structure you need - its more about setting goals for them and getting out of their way. The externally driven people require far more structure and management in order to make them meet their goals.
In the end, because things could change quite frequently, I think the most important thing is communication - clearly and as often as possible, go over what we are trying to achieve and what could we do better to achieve that faster. For instance, although I'm hugely internally motivated, I'm really happy when I meet my "boss" and we get through all the things we are doing properly and what things we are not. Not having this kind of meeting for a long time is actually really upsetting.
Of course this scratches only the surface of what management is. Good luck on making an awesome team.
Judea Pearl is tough going for me. I've never met him but he comes across as arrogant and condescending through his writing. I also find his writing very tough to follow. Even so, his Do-calculus is a valuable perspective on causal inference. Dawid is my go to source for clear exposition of causal concepts. Hard to find a clearer thinker and better writer in this area.
> Medrano comes from a Mexican-American family and speaks Spanish, so understanding the Spanish census document was no problem. Handling numbers and data came naturally to him as well, as an economics major. The challenge, as both Medrano and Urton note, seemed to demand a perfect alignment of his skills and interests.
I wonder how many unsolved problems there are out there with this problem. Problems that are solvable, they just lack one mind that can view the issue from the proper perspective.
I suspect that as the breadth of human knowledge increases, this type of problem will become more and more common.
There are many sources to develop an understanding of game theory. To build mastery in game theory, check out Osborne and Rubinstein's text. The authors offer it as a free download (http://arielrubinstein.tau.ac.il/books.html).
This is the text used by advanced graduate students, the material is explained precisely.
Feynman’s method to understand complex problems is so simple and elegant! Surely you’re joking, mr Feynman:
”I can’t understand anything in general unless I’m carrying along in my mind a specific example and watching it go. Some people think in the beginning that I’m kind of slow and I don’t understand the problem, because I ask a lot of these “dumb” questions: “Is a cathode plus or minus? Is an an-ion this way, or that way?” But later, when the guy’s in the middle of a bunch of equations, he’ll say something and I’ll say, “Wait a minute! There’s an error! That can’t be right!” The guy looks at his equations, and sure enough, after a while, he finds the mistake and wonders, “How the hell did this guy, who hardly understood at the beginning, find that mistake in the mess of all these equations?” He thinks I’m following the steps mathematically, but that’s not what I’m doing. I have the specific, physical example of what he’s trying to analyze, and I know from instinct and experience the properties of the thing. So when the equation says it should behave so-and-so, and I know that’s the wrong way around, I jump up and say, “Wait! There’s a mistake!”
> In fact, according to behavioral neuroscientist Stephen Porges, because recordings played at higher speeds are at a higher pitch, they are actually easier to hear.
Uh... that's not how modern speedup works. Here's a brief rundown:
1. break the audio up into very small windows
2. FFT audio in a window from time domain to frequency domain
3. FFT the audio back from frequency to time domain, with an even smaller window (or larger, if you want to slow playback down).
The frequencies resulting are the same, but shorter in duration. Obviously there's some sampling bias that can creep in, but these algorithms are generally pitch-stable.
I didn't say they were identical, but there are some important similarities:
To tulips and beanie babies: There were direct substitutes (other flowers and other stuffed animals) in terms of the actual utility, but tulip prices shot up in 1637- even investors bought tulip contracts not because they needed them, but because they were speculating on the value. Eventually demand leveled out, and the prices stopped going up. When the prices stopped going up, the speculators got out, and prices went down fast. The premium status of being the preferred flower or the preferred toy didn't help any more. How could this be like BTC? There are cryptocurrencies that are direct substitutes like LTC, but BTC is preferred and has a lot of investors purely for speculation. Once demand levels off (it must, there are a max of 7 billion people that can buy it), the speculators will get out, and prices will come down. Why hasn't it happened yet? BTC is artificially scarce due to block difficulty increases and fixed BTC being added for each block. The limited supply is maintaining price support for now, but like I said, once demand levels off, the fixed supply won't be as big of a price driver.
Similar to houses and .com stocks: Houses have real utility (you can use it for shelter). Stocks have real utility (you own a piece of a profit making entity). BTC has some real utility (you can transfer wealth outside of the regulation of governments and banks). However, these bubbles happened because instead of trading on a firm foundation value, people started expecting profits. The castle in the sky theory does work, but only if enough people believe in it. Once confidence faltered (either that people would continue to buy houses or that .com stocks would continue to print money), the castles in the sky fell, and prices fell back to their firm foundation value (a house in Las Vegas that I looked at went from $400k down to $100k- basically the price of raw materials and cheap labor). BTC's price right now is WAY over it's firm foundation utility of being a wealth transfer vehicle. It does have some value, but if enough people decide that a couple other cryptocoins can do the job with less risk than BTC, then prices for BTC will go down to it's intrinsic value- mostly related to the price of energy. It's hard to tell where this will settle, because ASICs are getting more efficient, and the block difficulty changes. But I guarantee you it will be way under $6k.
So these things aren't exactly the same, but there are lots of similarities with previous bubbles in the past. I'm not saying to stay away from BTC, but you had better be willing to lose your investment. There are a lot of people in the market that are only looking for a quick buck, and if they get out before you do then you are going to lose most of your investment. If you aren't desperate to make money off your investment, you will be happy with closing a position early instead of riding the crash into the ground. Closing early makes you the person with the quick buck and makes someone else the fool that lost their shirt.
You make some good points. We benchmark LMDB against LevelDB and its derivatives even though none of the LevelDB family offer ACID transactions. (http://symas.com/mdb/ondisk/ ) Despite this fact, people will ask the question and try to make the comparison, so we run those tests. It's silly, but most people seem to pay attention to performance more than to safety/reliability.
From my totally biased perspective, MDBM is utter garbage. They use mmap but make absolutely zero effort to use it safely. This was the biggest obstacle to overcome in developing LMDB; I had a few lengthy conversations with the SleepyCat guys about it as well. It's the reason it took 2 years (from 2009 when we first started talking about it, to 2011 first code release) to get LMDB implemented. If you want to call something a "database" you have to do more than just mmap a file and start shoving data into it - you have to exert some kind of control over how and when the mapped data gets persisted to disk. Otherwise, if you just let the OS randomly flush things, you'll wind up with garbage. As Keith Bostic said to me (private email):
"The most significant problem with building an mmap'd back-end is implementing write-ahead-logging (WAL). (You probably know this, but just in case: the way databases usually guarantee consistency is by ensuring that log records describing each change are written to disk before their transaction commits, and before the database page that was changed. In other words, log record X must hit disk before the database page containing the change described by log record X.)
In Berkeley DB WAL is done by maintaining a relationship between the database pages and the log records. If a database page is being written to disk, there's a look-aside into the logging system to make sure the right log records have already been written. In a memory-mapped system, you would do this by locking modified pages into memory (mlock), and flushing them at specific times (msync), otherwise the VM might just push a database page with modifications to disk before its log record is written, and if you crash at that point it's all over but the screaming."
The harsh realities of working with mmap are what dictated LMDB's copy-on-write design - it's the only way to ensure consistency with an mmap without losing performance (due to multiple mlock/msync syscalls). None of these design considerations are evident in MDBM.
LMDB's mmap is read-only by default, because otherwise it's trivial to permanently corrupt a database by overwriting a record, writing past the end, etc. MDBM's mmap is read-write, and the only "protection" you get is a doc that tells you "be Vewwy vewwy careful!" Ridiculously sloppy.
Leaving reliability aside for a moment, there's also the issue of performance and efficiency. We used to use DBM-style hashes for the indexes in OpenLDAP, up to release 2.1. We abandoned them in favor of B-trees in OpenLDAP 2.2 because extensive benchmarking showed that BDB's B-trees were faster than its hash implementation at very large data sizes. The fundamental problem is that hash data structures are only fast when they are sparsely populated. When the number of data records you need to work with increases to fill the table, you start getting more and more hash collisions that result in lots of linear probes (or whatever other hash recovery strategy you're using). The other problem is that the very sparse/unordered nature of hashes makes them extremely cache unfriendly - you get zero locality-of-reference for groups of related queries. So as your data volumes increase, you get less and less benefit from the amount of RAM you have available. When the data exceeds the size of RAM, the number of disk seeks required for an arbitrary lookup is enormous, and every read is a random access. Using a hash for a large-scale data store is just horrible. (We tested this extensively a decade ago http://www.openldap.org/lists/openldap-devel/200401/msg00077... )
Great question. I think it's on more people's minds than you think. I have friends that have brought this feeling up with me. HN brings a lot of great minds together, including your own. It can create feelings of inadequacy in many readers, but it shouldn't. Everyone is always growing. You can write well too.
As with any skill, there are specific quick hacks you can apply to get a lot of gain really fast, and there are well-worn paths that you should travel to maximize gains and minimize time spent. Regardless, the best way to learn any skill is through sheer practice.
My methodology for posting comments on HN or any social news site is based on my values. I value production over consumption, and so to curb my consumption and increase my production I created a rule for myself: If I read a post on social media(HN, reddit, etc), I have to leave a comment on it. No ifs ands or buts. I almost never actually want to comment, but by the time I'm done commenting I'm always glad I did.
This is amazing for becoming a better writer and researcher, and forces you to dive into things that you normally would only attain a surface-level understanding of.
Every time I decide to go to a social media site, I have to be very conscious of the titles I click on to read. I understand that the moment I begin reading an article, I am committed to adding something of value to the discussion. Sometimes I wind up clicking on an article that is way out of my domain-knowledge, and so I have to read WAY more about it before I can even try to add to the discussion. I end up learning far more and also upping my ability to explain and present myself in situations where I'm uncomfortable with the domain.
So while I encourage you to practice your writing, I also encourage you to limit your consumption, strongly link your consumption with your practice, and most importantly, step out of your domain knowledge and never be afraid to learn something new.
People also tend to sound far better in writing, precisely because they have the opportunity to compose and edit; you don't necessarily see the volume of composition and editing that goes into the average post. Anecdotally, I'd suggest that it takes far longer to write a quality post than you'd guess. Short content can take all the longer to write, precisely because of its brevity. ("I have made this letter longer than usual, because I lack the time to make it short." -- Blaise Pascal)
And that's just on an individual level, comparing yourself to one specific other person. When you compare yourself to an entire community of people and their highlights, you run into exactly the issue mixmax noted: the most knowledgeable and confident people will post, and a subset of those will get upvoted.
Comparing yourself individually to the best of what a large community can offer is like asking why you're not an Olympic athlete.
If you want to build up your skills in writing specifically, consider focusing your writing on areas you already have expertise in, or on areas that you're actively learning about to provide an "experiences" type of writeup. And compare yourself primarily to your past self.
There's a fallacy here, and interestingly it's also at play on facebook.
You know when you look through your feed on facebook, and every single day you see that at least one of your friends has done something amazing, commendable or just interesting? That makes you feel that you aren't doing anything with your life, and that all your friends seem to be living more interesting and happier lives.
But stop and think for a moment. Approach it from the other side. If you have 365 friends, and you post one interesting post a year you are faring as well as the average of your friends. It just seems that everyone is doing more interesting things than you because you only notice the interesting things your friends post. You only see the highlights. Nobody posts a "today was boring - I did absolutely nothing" status.
HN is the same. Think a bit about it.
If 10.000 people see a comment thread then statistically someone will be knowledgeable about the subject, whether its the French Revolution or the finer nuances of L2 caching. The most knowledgeable ones will feel they have something to contribute and write a comment. The vast majority won't. On top of that the top comment is (supposedly) the most well-written, eloquent and knowledgeable, and can thus be argued to be the best 10.000 people can come up with.
If I were to start commenting on threads about L2 caches I would make an absolute fool of myself, and prove to everyone that I have no clue what I'm talking about. So I don't.
* Resist all tasks that you and your team can't figure out next step for. (They're not actionable.)
* Find the maximum task length you're comfortable with doing yourself; try to delegate anything that you expect will take you longer. Keep this number very low (e.g. 15 min or 5 min).
* To balance the latter, find the maximum hours you're comfortable with having someone else do work you'd do in an hour. Keep this number high (e.g. 8 hours or 20 hours), and step in to do things yourself only when delegating will make you over it.
(Edit: Also, there are good lessons learned from the past; don't forget to read books books, like PeopleWare.)
Go have a listen to this excellent podcast on delegation [1] from Manager Tools. They hit the same notes you’re hitting, but provide some additional actionable tips and tricks for figuring out when things are going well, about to go wrong, or going wrong.
I'm in a role as manager/lead dev, so it's kind of mixed. The transition to the managerial part was pretty rough back then and I wished I had gotten more support, many companies don't know how to do that well.
With a developer mindset, what helped me was this (no particular order)
* Go about it as a problem solving task. This can be as complex and fun as building a new system - you are building organization and culture. The way you treat them will mirror in how they treat each other and your customers.
* Don't assume too much what a manager should do or what you have seen, but see your new job as an enabler of other people and find out what the particular needs there are. You're the user interface for other people to get things done in the company.
* The hardest thing is probably to stop solving implementation problems yourself. That's again an enabling position. All the stuff you were the expert in before you now need to transfer to other people. Don't just quickly solve their new problems because you know it better.
* One thing about micromanagement - If there's something that appears to be micromanagement, it's often a problem of too little actual management and not enough. That sounds weird, but the reason is that management interferes with people's work directly, where they actually should have given them the tools and the knowledge to do it themselves. So when you start hearing or sensing that notion, don't stop managing, but try to find out where you really need to help.
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us.
I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation.
This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough.
It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.
You can make mtr start in this view with --displaymode=2 (direct command line arguments, `mtr --displaymode=2 …`; or shell alias, `alias mtr="mtr --displaymode=2"`; or set environment variable MTR_OPTIONS=--displaymode=2).
Screenshot of this mode: https://temp.chrismorgan.info/2025-02-06-hn-42924182-mtr-dis...
—⁂—
¹ 1.1 = 1.0.0.1 = Cloudflare public DNS, a convenient nearby public internet endpoint.