xenotux

Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?

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.

> 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.