nullspace

I think there's some misinformation in your replies about how this rating can be used.

As a parent, you can add screen time restrictions to your child's phone that prevent them from accessing apps that are above a certain rating. This is a very powerful feature, that's really hard (impossible?) to bypass without social engineering.

It's possible that discord is concerned enough with this so as to block out nsfw servers. Do they have a lot of teenagers on their platform?

Isn't it very similar for programmers? I don't get paid >100k for knowing how to create a button with boostrap and jQuery, but rather for the 1% of the time where I need to do something 1000x more complicated

I felt a tinge of sadness reading this. Len may or may not be Satoshi, and the article makes a strong case that he may be, after all. But it's really sad to lose such extraordinary people to mental health related issues, especially when we can do much better, with little effort.

> I would

From your comment, it looks like you have zero skin in the game here. Given that your comment is unproductive.

In my career, I have met exactly one short fat engineer with >5yrs of exp that I was impressed by. That person is now a Product Manager at a FAANG company (albeit PM-ing highly technical stuff).

I bring this up because I think there is a very good analogy to the point that the author is making and the distinction between PM and Engineers. Broadly put, PM's are good at figuring out the theta, and Engineers are good at the r.

I think that with the perspectives that short fat engineers have, they can play enormous roles as "PM" or "Engineering Manager", and definitely as ICs during early stages of startups. But they clearly don't enjoy depth, and this can be counter-productive for that 1% of the time where you really, really want depth.

I don't buy the knowledge vs wisdom thing though, there's plenty of wisdom to be gained from going deep into a subject. I'd actually claim that wisdom can only come from depth - though what depth means is different for different roles.

I was thinking about the same thing.

If the commitment of Microsoft is in question, there’s a good chance of increased resources by Dell, Asus etc towards Linux.

This is very interesting, but just curious, when would you use something like this versus, say, protobufs?

For my Masters degree, most of my courses were absolutely like this. Our assignments were difficult and heavy. There was no expectation that you should complete them without Google or reference material.

In contrast, the "final exams" were either non-existent or extremely easy and account for only 10-20% of the grade, where they existed.

I really liked this approach. Make your assignments very difficult. Alternatively, give difficult 10-15 minute quizzes every other week. IMO, it's a much better way of evaluating students.

Hi Asim, your project is really interesting to me. Just curious, do you have go docs or tutorials hosted somewhere?

My 2c, with all humility. But, I'm not sure you really understand why recruiters and companies are not taking you. For any serious business where it's senior managers or founders doing the recruiting, they are not after the "unicorn guys/gals".

My suggestion is to ask for feedback when you get rejected, most people will be happy to give it to you.

Well, kinda right? I think this may just be reflective of the long/fat tail of tech salaries.

The second column in that table shows how many people exceed the prevailing wage by 20% or more. In the case of Facebook, it's just 47.9%. And for Google and Amazon, it's 58 and 68 respectively.

Confusingly, they don't tell how many people exceed the prevailing wage at all.

Table 2 on Page 54 is even crazier.

Hey sisama, thanks for sharing this.

So, I highly doubt if Software Engineering salaries would follow a Gaussian distribution. My guess is that it would have both a fatter and longer tail than Gaussian.

Not an expert in statistics, but that's the case, wouldn't it push the 95-percentile wage level even higher?

Do you have a source for this? And what do you mean by “withdrawn”?

My initial reaction was to downvote you for your last sentence - I think OP has obviously worked on medium-large systems, and is just strongly opinionated.

However, I agree with your first sentence.

> If fixing a bug breaks a functional test, then either the test was correct and you changed your expected system behavior and the test saved your bacon, or the test was a change detector test not a functional test.

And I think this is a _hugely_ valuable for medium-to-large systems, which typically have many, many layers of abstractions.

I used to work on one such system that had a lot of, what this author would refer to as, functional tests. Sometimes, changing a couple of lines in one of the core modules would cause 50 tests to fail. While this is just a "change detector", it's still really valuable, say about 20/50 of these changes in behavior are unexpected but acceptable, 5/50 are actually intended, but 25/50 of these are actually regressions in ideal behavior. This means the layer at which you made the change is just wrong, or you didn't put sufficient nuance in your change.

It's a big time-sink for sure and made many new developers angry, but honestly the gain was that the overall product had fewer regressions.

I'm somewhat unsure what I would replace these "functional tests" with.

I have become exactly like this.

My experience with free (as in beer) software and services is that it's usually offered as a "strategic offering", maybe as an attempt to commoditize your complement(?) but I'm speculating here. The downside is that the wider business does not care that much about your software. It needs to work, but just enough that customers don't use your complement. And critically, when it comes to prioritization of resources (especially the most senior people who could mentor you), they would rather put their best people in other parts of the business.

I've become of the mindset that if you want to build best-in-class software with a best-in-class team, you should see if you can draw a direct line from the product to the revenue, or at least the core mission of the business.

As someone who recently did that after ~8 years, I found it useful to skim through Modern Java in Action. It should be pretty easy read if you've been doing more modern languages, but important to learn Java semantics and nuances. Also, I highly recommend Java Concurrency in Practice, but it's a tougher read.

That said, for most orgs, the biggest changes you might see would be in libraries and frameworks used. There will most likely be less XML, better build tools and more modular library usage than 12 years ago.

> And yet today in the United States, it’s basically a given that you will have a fast and reliable 4G connection available throughout the entire country, as long as you’re not in literal wilderness.

Don’t have a dog in this, but just wanted to say this is not at all true. There are so many places nowhere near wilderness where you would struggle to find a useable 4g connection.

(I’ve lived near some places like this in the northeast - I have to guess that the avalys has not traveled around that much in the US)

IME, not really. And to be honest, I don't think it's a good idea to delegate these tasks to a single person on the team.

I think it depends on the specific app. Does what you’re saying in Pocketcasts, but the Economist app does what parent is saying.

I think I vaguely agree with much of what you said, but just want to point this one out.

> It's a societal problem that we do not value art in the same way that we value science and technology.

Want to give a couple of examples against this:

- some of the most valuable software out there is free and open source. The authors of said software don’t get compensated anywhere near the softwares value. Coz everyone uses it for free.

- I very much value the games I play on my iPhone, but I have never paid any money for them.

- I will buy Opeth t-shirts, and Akerfeld custom guitars, but I’m never going to give Spotify as much money.

So, I don’t think your claim is so clear cut as you state it.

Skimming through the numbers in the article[1] linked to from here, it's very interesting to see the dynamic that Apple has managed to create around depreciation.

A 2 year old iPhone can still be traded-in at roughly 50% of the value (whether to Apple or a third-party). The effect that this creates is that it becomes quite reasonable to buy the latest iPhone every two years after trade-in. I'm sure this has a big impact on new device sales, one of the factors as to why Apple beats records every year.

On the flip-side, I believe the reason they are able to do this, as the article here notes, is that their phones just last long (hardware/software). My iPhone 8 is not very old, but I'm not planning to stop using it for another 2-3 years at least (unless it shatters). In some ways, this reminds me of ThinkPads, just in terms of how long they can serve their purpose.

I'm honestly getting kind of "bored" of Apple devices, but I fear Android devices may not have the same solid 5 - 7 years of support, and as is evident from this article, trade-in value.

[1] https://www.bankmycell.com/blog/cell-phone-depreciation-repo...

I'm just a mere software engineer, so I have no idea about this stuff. But, I feel like this sentiment "has to be an endgame to these measures" feels like wishful thinking.

Why is it impossible that we're headed for an economic catastrophe until a vaccine is out? I can totally see it happening - something where we will have to ration out our basic supplies even. <-- already happening wrt some stuff.

That would just be the cost of saving a few million lives.

Related, here's an excellent lecture by Sean Carroll on the Arrow of Time: https://www.youtube.com/watch?v=hagHHV6RYZ8

As far as I understand, his central (layman-level) proposition, is that time is just an emergent property when you consider that entropy always increases.

Fascinating stuff.

I’m confused? What’s WhatsApp being part of a big tech company got to do with 230 immunity?

That’s bullshit.

In reality (I was affected by this and it’s now fixed), this happened 3 days ago, and I kept watching the status to see if they would identify it.

I had to upgrade to premium support for them to even respond to the issue. I filed the issue on Friday or Saturday, and they got back to me on Sunday. And it looks like they have fixed it now.

This was not a quick response time, don’t give them credit for this one.

I don’t know whether you’re right or wrong, but calling someone a veteran based on 10 years of exp, and a director after 5 to 7 years sounds like a recipe for disaster. (Unless you literally started the company or something Like that).

Could this actually explain why a lot of people don’t like their managers? Because they are just too damn inexperienced.

Re: knowing few staff or principal engs, my personal anecdotal observation (and other people have told me the same), is that many engineers don’t change their titles on LinkedIn, or say they are “staff eng” etc in public. In fact, for some people, the higher they go the more they downplay their title in public. Don’t have data to back this up, just anecdotal convos with some people I know.

I’d also like to think the culture is slowly changing, about feeling forced to get into people management to progress your career. But that could be wishful thinking!

It really does depend on the organization IMO. In a healthy organization, the managers manager can easily distinguish between contributions and fuck ups of the manager versus the same for the managers reportees.

If a team hits their metrics a good (super-) manager knows if it’s because of the manager or in spite of them, and vice versa.

What we really need is to train people to be better at identifying these organizational concerns, and set the right incentives, so that people choose to be Engineering Managers for the right reasons.

Edit: and to answer your question directly, in a healthy org, it’s definitely possible (and in fact in some very rare cases easier) to fire your manager than for them to fire you. Also depends on the level of trust you have built for yourself as in individual contributor.

Well, good point. I think what the author is talking about can he implemented as a Monad, and he / she is describing a flatmap operation.

However, I’d hardly describe it as “just”, it’s a fairly interesting idea.

My predictions, not as grand as some others, but anyways!

Software Engineering / Startups:

- FAANG will be continue to provide the best monetary compensation, that no startup can beat. However, there will be a few startups that will figure out something to attract the best-of-the-best. Similar to how Google figured out how to do it in the early 2000s. I thought maybe something bitcoin would have been it, in 2010s, but I don't think that's come to pass yet. These companies will become HUGE, bigger than Google by 2040.

- UI development in the browser and browser based technologies will be dominated by one framework, and we will stop seeing new frameworks every other month. Think Qt but with web technologies. Performance afforded by native applications will still not be a priority for all but the biggest apps.

- Java will continue to be dominant in terms of market share, and JVM will be continue to be huge on the server side. In fact, Java will supersede Scala and Kotlin in terms of the most important features. As in it will have the best parts of both the languages, but designed better.

- There will be huge progress in developer tooling for machine learning. Just as how you can do `npm install`, run docker containers, and virtual machines very well, without knowing anything about how it works, you will be able to train and use "good enough" models without knowing how machine learning works. AutoML is just the start, I'm thinking the stereotypical 17 year old hacker who gets into JavaScript today as their first technology, will instead be getting into Machine Learning based stuff by 2030. Recruiters will be surprised if you've not been exposed to it in the past year, regardless of your background.

- People will continue complaining about agile, product management etc. :)

Stuff I have no idea about, but here it goes:

- The current world is fairly divided and fragile and changing. It's been a long time (> 75 years) since there has been a big crisis. By the beginning of 2030, we will start to see the sparks of another crisis. It may either be the biggest global recession ever, or something worse.

India related:

- The government in power will continue to be nationalist through this decade (though not necessarily the current party / leaders), however more secular than it is right now.

- There will be at least one startup from India whose product will be used widely around the world.

- There will be economic and infrastructural gains, but by the end of the decade, it will still feel meh.

- At least one place in India will get hit very, very hard by something caused due to climate change.

This is fairly controversial. Is there any example of a startup that actually made it by employing this strategy?

One of the truisms I've heard and have always followed is you need to release something you're embarrassed about, because that's the quickest way of getting user feedback, and understand if a user actually _wants_ that feature, and if it's actually worth spending time improving that feature.

It's easy to waste valuable capital paying attention to details that the user does not really care about.

EDIT: I've noticed that most of the software you posted here is very well established, most > 10 years. I'd be surprised if any of them follow "agile" by the books.