That's true, I'm 2050-2100 lichess, around 1800 on chess.com. Never played a rated tournament but played some rated players who were 1400-1500 rated USCF, and they were roughly my strength, maybe a bit better. Still the Delta bot, easy mode, was much, much better than me.
I think it depends on the pool to which you're comparing. Being top 2% of all programmers is not so impressive if you include everyone who's ever taken an Intro class. Top 2% of people who do it for a living is much more significant.
I'm in a similar boat as the other posters (2050-2100 lichess, 1400 USCF). The median active rating for USCF is around 1200 and likely much higher if you don't include scholastic players, so if we compare against the OTB pool, "2000 lichess" is probably closer to top 50% than 2%
I mean, if you’re in the top 3 percent of anything, yes that’s pretty good, but not unbelievably so, especially in the field of chess. If for instance you randomly put together a classroom full of chess players, there’s decent odds one of them is better than top 3%. Two classrooms and it’s almost a certainty.
Put another way, looking at chess.com users, there are ~6 million people who would count as the top 3 percent. Difficult to achieve, yes, but if 6 million people can achieve it, it’s not really a “humble brag,” it’s just a statement.
It made me smile to hear “I’m only 97th percentile” isn’t a humblebrag. You may be employing an old saw of mine, you can make people* react however you want by leaning on either percentages or whole numbers when you shouldn’t.
* who don’t have strong numeracy and time to think
I'm 2100 rapid on lichess, 2050 blitz and bullet. I got destroyed every single time I played the easy mode version on Delta. It knew opening theory. It did not blunder a single time in the middle game. I never made it to an end game.
If we're talking about Wil Wheaton I'll also suggest giving Ready Player One a try. It's a short but very enjoyable book and Wil does a great job at bringing it to life.
Note that we didn't run stock freebsd. It was a custom freebsd4 with a custom gcc 2.95 toolchain. I don't remember all the mods, but migrating from 4 to 6 was a nice undertaking, and it was done in parts. People who worked there will remember the term "4 on 6". After the migration, the kernel was 6 (and you got the latest drivers) but we were still running those weird 4 user-land binaries.
Inktomi (YST) was acquired in 2003, later Overture (YSM) and both were linux shops. YST was the biggest property by far and we didn't have any kernel developers. We were doing just fine with stock debian, then stock RHEL. (I did a few very minor patches for 32-bit, like splitting user-space/kernel to 3.5/0.5G instead of 3/1G, and some caching improvements for /proc, but I wasn't a kernel developer). Linux just worked. Drivers were available and supported for the HW we needed. Oprofile, systemtap worked fine for the most part. We later hired one kernel developer to help Mail move to linux, but we always had more freebsd kernel developers.
For freebsd you needed to write the drivers and the tools. That took time and money. The community was also smaller and it was harder to hire people with experience. Acquisitions were running on linux too.
The decision was not easy. Y! already had great freebsd engineers. By announcing that linux would be the supported platform going forward it was a given that many of them wouldn't be happy and leave. Fortunately not all of them left. For example Peter W. still works there.
In any case I don't think there was really an alternative.
Even when Rick was at Y! the push to move to linux was there. Rick had written most of the base libraries for freebsd originally (mdbm, ylock, ylock_kern, yfor, etc.), and tools like the package manager yinst and ysar, but being the great engineer he is, he ported them to linux and got the same or better performance. (In the yinst case he delegated the maintenance to a very capable engineer)
Note that Yahoo! was employing a few very bright freebsd kernel engineers but when the decision was announced that linux was the future many of them decided to leave. That made the path forward even clearer. It wasn't just a matter of integrating new acquisitions easier, and the fact that it was easier to hire people with linux experience than with freebsd experience. That was around 2008 IIRC. I left in 2010, and Rick less than a year later.
Can you share the name of the recruiter? Just curious if that person is still working at Netflix.
I've been a happy Netflix employee for over 4 years and have never experienced a 'large layoff' event. All the layoffs I've witnessed were not a surprise for the people affected.
Senior engineers usually make more money than their direct managers, but I fail to see how that's an issue.
I'm guessing RayVR met with Patty who left Netflix 2 years ago. My interview with her was different but I guess it would depend on your background and what she was trying to determine. In my case it was mostly to see if I was going to be a good cultural fit since I was at the time working for Yahoo which had a completely different culture. To me that was an entirely reasonable thing to do. Actually the whole interview process was great, and it was one of the major reasons I chose Netflix over other companies.
The day after I took over the team, my director sat me down and said "I don't know if you've looked yet, but most of your engineers make more than you do. That's because they're incredibly valuable. Your number one job is to keep them happy."
In the last two years of managing this team, I've consistently gotten paid less than the top engineers on my team.
I've listened to this audiobook and I was hooked very early in the story. Jon Ronson is a very good story teller and he narrates his book. He's quite funny and engaging. "A Journey Through the Madness Industry" is the subtitle, and "journey" is indeed a very adequate description of what you'll experience with this book. Jon wanders from place to place where he'll meet psychopaths and people who work in the "madness industry" and relates his experiences and thinking.
It's not a definitive treatise on psychopathy, just the adventures of the author as he dives into this fascinating world. Definitely worth getting it at this price.
You can write to /tmp. But since most people are also doing that, /tmp/date gets overriden frequently. I'd recommend mkdir /tmp/CZ-18; PATH=/tmp/CZ-18:$PATH; And then you can figure it out :)
I agree that the biggest issue is #1. Another problems I've run into are:
- Operations are not automatically aborted if the client closes the connection. Suppose a case where the client is sending many queries that are queued by the server (usually waiting for a lock to be released). Client times out, re-establishes a connection, retries, etc. Mongo will execute the operations even if the client is no longer waiting for the response. Operations are not automatically aborted.
- Sending slaveOk() queries need to be sent to the slaves explicitly by the driver, and I haven't seen it work reliably. Ideally you'd send them to mongos and let it send slaveOk() queries automatically to the slaves. All the drivers would be simpler and just work. But this is not the case. You can't do it unless sharding is enabled. Each driver needs to implement this functionality.
But I must say that overall my experience has been very positive. It's very developer friendly. You can go from not knowing anything about it to having a working prototype in an hour or so. The flexibility in querying the system is awesome.
You just need to understand the limitations of the system. Once you start pushing the limits it gets significantly more complicated.
