I wouldn’t necessarily agree. I owned a few domains related to my name (e.g., variants of <firstname><lastname>.com), but nothing as obsessive as what Steven Wolfram is known for, and I’ve probably owned them for as long as domains have been available. I never found much utility in it. Toward the end of my career, I considered using one as a professional profile not tied to LinkedIn, but I wouldn’t say it was a better use of my time than spending it with my grandkids. Many people in our industry could benefit from stepping away from creating work solely to stand out and instead enjoying their free time.
I'm a top 5% contributor to SO with around 300-400 answers (haven't actively answered a question in a while). One of the highlights of my career was seeing people benefit from those answers, post commentary, and update my answers. In the last year, there's actually been 0 engagement on all of my questions. One of the rare/sad aspects of how ChatGPT has impacted our community.
I have a love/hate relationship with the site, and I'm likewise conflicted by its eventual demise.
On one hand, it's an incredible place full of smart people and has some of the best rabbit holes to fall into. On the other hand, portions of the site (programming among them) has the worst culture imaginable and has likely turned as many people off from learning as it has helped.
Not only does GPT lack the pretty nasty culture of SO, it’s so much faster to work with.
I anticipate SO will go into decline and get worse as a result. I wonder how much GPT will suffer without it as a source.
In a way, they’re kind of a match made in heaven: domain experts who share experience and knowledge not found in the user docs alone, cleaned of the antisocial nastiness usually filtered by tech writers and PR peeps.
This is honestly one of the worst blog posts I've ever read, and probably does a disservice to representing MIT grads (who shaped my entire career 20-30 years ago). Anyways, as someone who was in this space, my 2 pieces of advice are: 1) either get a PhD in the field (and Apple would pick you up relatively easily) 2) have a small history of contributing to languages like rust, go or be prominent on the clang committees, llvm, ghc.
At least up until 5 years ago, the bar to join compiler teams was relatively low and all it required was some demonstration of effort and a few commits.
Not sure why they down voted you. I agree about the quality of this post. It is low and lack substantial advices. Too many words. I suspect they used AI to generate text maybe.
I'm retired from the industry, and posts like these take me back to the early days of cybersecurity (where people memorized scripts). Talking with my nephews and nieces, I can already tell that many new grads struggle with fundamentals—things like choosing the right data types and containers for short-lived strings, understanding how memory allocation works, or even marginally improving a basic hashing function. I worry the next decade will bring an influx of undertrained engineers.
>>I worry the next decade will bring an influx of undertrained engineers.
How can it be the other way? No one is investing into education of their developers, also trying to save some money on them. Get cheap fresh grads and make them develop new stuff!
I agree understanding how memory allocation works, but not sure I would agree that understanding how to _improve_ a basic hashing function is very important.
I'm somewhat surprised to see this on the front page of HN. I distinctly remember this material being covered in a single lecture during our freshman CS course 20 years ago. I doubt this would've reached the front page in HN's early days, and it makes me wonder if we've moved away from teaching these fundamentals due to the heavy reliance on abstraction and ai agents in today's industry.
I've never taken a lick of CS in a formal setting, and I feel like that's increasingly common as programming has broadened its employment base. Most of the people I work with haven't done formal CS, either. Consequently I've had to learn all of this stuff on my own. There are communities out there that value education this kind of education. I can vouch for the Rust community, which has helped me learn _a ton_ about this kind of "lower level" stuff over the last 5 years despite starting my career doing Ruby.
One of the neat things about programming is that you can develop a high degree of skill in it without any formal education at all.
But it does mean that we've always had those programmers who have had characteristic holes in their education as a result.
Personally I enjoy having a mix of self-taught and formally-taught around; I think there quite a few things the self-taught are often better at than the formally educated as a group. I respect both sides. I'm just saying that there has always been a market for this sort of thing on HN because the self-taught have always been around.
First, there are people who manage the best of both worlds, so bear in mind I'm talking about the ones who only manage the one side or the other.
The self-taught ones are often much better at diagnosis of problems in my experience. "Hey, the servers are blowing up, own the process from diagnosis to deploying the fix" is something I can generally throw at a self-taught dev faster than a school-taught dev. Often because even if they've never owned a server they've already been through the "my graphics driver is crashing my desktop when I plug in my USB drive" dance on Linux a number of times and know how do go through diagnosis processes.
They're also often better out-of-the-gate at being handed a large task and knowing how to break it down quickly without much direction. Sometimes they should be getting more direction than they do; this is often the source of bits of the code base that seem to be completely foreign in style, library usage, etc. Gotta watch the PRs.
On the other hand, the self-taught will sometimes blunder into some critical O() mistakes because they haven't been taught to think that way, and may never have worked at any real scale before. They can also end up doing too much without using a library because they're used to just doing it themselves. (Not that school teaches you to "use libraries" exactly, but the school-taught are just generally less fluent and as such more likely to look for easier solutions... which is often exactly what we want!)
Where the holes really develop is when we get into heavy data structures, or a compiler-like code base (though sadly many school-taught people escape without compilers), or heavily recursive code, which doesn't just include "recursion" per se but also things like working with DOMs that are recursive tree structures. A lot of time the self-taught are great at straight-line "do this, then do that, then do that" code bases but struggle to build longer-term maintainable code that has good reuse.
And I'll say it again, these are all absolutely, positively, generalities and they do not apply to everyone. Some self-taught people are great at creating high quality, well-architected code bases. Some people escape school not just without compilers, but without any discernible skills whatsoever. (Those are some sad interviews.) These are just broad patterns I've observed.
I have a degree in CS from around the same time frame, and we never covered topics like this. So I think it varies widely, and is not necessarily a modern thing for people to not learn about struct sizing.
