- > There's been a strong theme recently here on HN of confusing programming (the act of writing code to meet specifications) and Engineering(the writing of specifications, and the oversight of said process, along with overview of testing).
You're making a distinction that might be interesting in some esoteric sense, but that doesn't exist in the industry. When it comes to software, the architects are also the construction crew. There's nothing to confuse if the terms are effectively synonymous.
- Nah. Every company has its lore about what makes a good candidate and they try to test for that. The lore is often rubbish (as in: there's often little correlation between interview performance and on-job performance), but there is still a process and that process rejects most applicants.
- > One great piece of advice and informal mentor gave me long ago is that there is no information in a rejection.
I mean, there might be, in two ways. Sometimes, you just mess up in some obvious way and can learn from that. But you also get a glimpse of the corporate culture. Maybe not for FAANG and the likes - the processes are homogenized and reviewed by a risk-averse employment lawyer - but for smaller organizations, it's fair game.
But as with layoffs, there's nothing you can win by begging, groveling, or asking for a second chance. The decision has been made, these decisions are always stochastic and unfair on some level, but you move on. You'll be fine.
- It's moving in the right direction, but I'd still say that CSS has more quirks and misbehaviors than the common subset of JS...
- So... how is it useful? You're trading one oracle for another. Either of these oracles can be manipulated or compromised.
I think one could argue that it's more elegant from the point of view of blockchain maximalism. But I don't quite understand the utility in any other sense.
- I've been in engineering, TLM, and management roles in multiple companies. In terms of output, TLMs are not held to the same standard as full-time engineers at the same level, period. Their engineering contributions are dissected only if their performance as a manager is in serious doubt.
In any role, there are some folks who push themselves too hard, and there is no one to tell them "stop", but that's their choice.
- Look, I'm trying to describe reality; you seem to be expecting me to defend it. But briefly:
> Inevitably because why?
Because proven, effective managers are always in short supply, so when you hire new people, or if any of the existing managers leaves, it's the default pick.
Plus, most people want to make more money over time. And on the management track, this means angling for that director / VP role down the line, even if it wasn't your childhood dream.
> If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
They can, but in big and / or growing companies, performance problems are addressed less vigorously than they probably should. This cuts both ways: neglecting problems is wrong, but cutthroat performance management makes people cranky too.
- > Role power is by far the least effective.
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
- In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.
- The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers.
Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people.
But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
- TLM roles are a trap, but not in that sense. There's no expectation that you do two jobs at once.
It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time.
Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those managing dead-end projects on dead-end teams; or those who desperately cling on to the engineering past and actively refuse to take on more people. From a corporate point of view, none of these situations are great, hence the recent pushback against TLM roles in the industry.
- I'm surprised this is aliased to char*, not const char*. The benefit of the aliasing is convenience, but the main risk is absent-mindedly passing it to a libc function that modifies the string without updating the SDS metadata. Const would result in a compiler warning while letting the intended use cases (e.g., the printf example) work fine.
- > Toxic expert here! I hate when blog posts try to teach complex subjects. It's almost always a non-expert doing the teaching, and they fail to do it accurately. This then causes 1) the entire internet repeating the inaccuracies, and 2) the readers make no attempt to do further learning than the blog post, reinforcing their ignorance.
Ask yourself why. The usual answer is that top experts either can't be bothered to create better content, or they actively gatekeep, believing that their field must remain hard to learn and the riff-raff must be kept out.
I think the first step is to accept that laypeople can have legitimate interest in certain topics and deserve accessible content. The remedy to oversimplified explanations is to write something better - or begrudgingly accept the status quo and not put people down for attempts that don't meet your bar.
It's also good to ponder if the details we get worked up about actually matter. Outside the academia, approximately no one needs a precise, CS-theoretical definition of big-O notation. Practitioners use it in a looser sense.
- Such is the curse of blogging: when writing a series of posts, authors naturally assume that the readers are as engaged and as familiar with the previous discussion as they are.
In reality, even regular subscribers probably aren't, and if you're a random visitor years later, the whole thing may be impossible to parse.
- I don't think there's anything that would put some new, esoteric math concept in your mailbox every week, although there's plenty of books that cover recreational mathematics in an accessible way (Martin Gardner, Ian Stewart, etc). And for QM articles, I recommend searching the web - you can often find better explanations on some 1999-style blog somewhere.
The problem with this particular article is simple: busy beavers numbers aren't interesting because they're big. They don't break mathematics because of that; you can always say "+1" to get a larger number. There's also nothing particularly notable about Knuth's up-arrow notation, which is essentially a novelty that you're never gonna use. Instead, the numbers are interesting because they have fairly mind-blowing interactions with the theory of computability.
- You can say that about 99% of the tech that people use today. Windows and MacOS don't serve you. Your browser doesn't serve you. Heck, Hacker News doesn't serve you - it serves a bunch of VCs!
But the reality is that most of the time, this is not an adversarial relationship; and when it is, we see it as an acceptable trade-off ("ok, so I get all this stuff for free, and in exchange, maybe I buy socks from a different company because of the ads").
I'm not saying it's an ideal state or that there are no hidden and more serious trade-offs, but I don't think that what you're saying is a particularly compelling point for the average user.
- > I don't understand why we would ever want an agent to buy stuff for us.
Why not? Offload the entire task, not just one half of it. It's why many well-off people have accountants, assistants, or servants. And no one says "you know, I'm glad you prepared my taxes, but let me file the paperwork myself".
I think what you're saying isn't that you like going through checkout flows, just that you don't trust the computer to do it. But the approach the AI industry is "build it today and hope the underlying tech improves soon". It's not always wrong. But "be dependable enough to trust it with money" appears to be a harder problem than "generate images of people with the right number of fingers".
No doubt that some customers are going to get burned. But I have no doubt that down the line, most people will be using their phones as AI shoppers.
- There is a downvoted comment that reads "ah yes the totally new math of exponentiation". The snark is uncalled for, but that's actually the essence of this article: it talks about repeated exponentiation as if it were some profound mathematical discovery.
It isn't. The article neglects to explain what makes busy beaver numbers interesting in the first place. And I think it's symptomatic of Quanta Magazine articles that feature on HN several times a week. A profoundly-sounding title and pleasant writing, but not much essence beyond that.
- The main difference between democracies and secular autocracies isn't that they have a vastly different approach to run-of-the-mill moral vices, such as prostitution or porn. It's that democracies tolerate a much wider spectrum of political opinions in public discourse and don't kill or imprison people who try to start an opposition party.
I think we can agree that the UK is moving in the wrong direction without drawing parallels to a place where dissidents are disappeared, both off the internet and in real life.
The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.