dasil003

How big is your company?

Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhausting, and it doesn't inherently get better with knowledge and experience as the gap to the lowest common denominator only increases; the only balm I've found is focusing on what I can control.

This is not true. Most fast-growing private tech companies with valuations a fraction of OpenAIs switch from ISOs to RSUs because exercise costs start to become prohibitive.

Of course they aren’t liquid yet, but they’re still RSUs, and it’s much more common than OpenAIs profit shares structure

That's just it though, the "news" is not providing valuable information to the majority of people, it's mostly a series of takes designed to fit into easily digestible narratives so they can attract enough viewers to survive as a business.

No we don’t need to open an entire website to learn x simple thing. However we DO need meaningful competition among information providers. I am not looking forward to the enshittification phase of AI.

Who are the people in the room (including you) and what are they responsible and/or accountable for? There's a time and place to say "that's a bad idea", but typically it's 1:1 or very small groups not in a broad team setting. You also can't always be the naysayer, it is political capital based on a proven track record of saying what we should do instead—not necessarily in the same venue, but if you're just a perpetual pessimist it's of no more value than the irrational exuberance of the naive optimist.

What makes you think Visa is the only player in the payments chain between the merchant and your bank?

Not sure if I understand your question but nothing "happens to the rest", overcommitting just means processes can allocate memory in excess of RAM + swap. The percentage is arbitrary, could be 50%, 100% or 1000%. Allocating additional memory is not a problem per se, it only becomes a problem when you try to actually write (and subsequently read) more than you have.

Isn't there a Chris Pratt movie about this coming out in January?

Really depends on the problem. Cancer, yes. Banking, no.

I think your definition of character is useful, and I tend to agree with Drucker that it's the most important thing, because otherwise a manager will subject to whatever political winds are blowing higher up without any grounding or point of view on what should be pushed back on. On the other hand though, "do[ing] the right thing regardless of negative consequences to oneself" is easily stated, but in practice is not effective without influence—if you are constantly saying no, you'll quickly be replaced.

The uncomfortable truth is that "the right thing" depends a lot on the point of view and narrative at hand. In large organizations political capital is inherently limited, even in very senior positions. It's especially challenging in large scale software development because ground-level expertise really is needed to determine "the right thing", but human communication inherently has limits. I would say most people, and especially most software engineers, have strong opinions about how things "should" be, but if they were put in charge they would quickly realize that when they describe that a hundred person org they would get a hundred different interpretations. It's hard to grok the difficulty of alignment of smart, independent thinkers at scale. When goals and roles are clear (like Apollo), that's easy mode for organizational politics. When you're building arbitrary software for humans each with their own needs and perspective, it's infinitely harder. That's what leads to saccharine corporate comms, tone deaf leaders, and the "moral mazes" Robert Jackall described 30+ years ago.

Everything has tradeoffs and unforeseen effects and social structure is a slow moving ship. Food security is pretty obviously compelling, and creates a stability that allows a society to scale and grow more wealthy and powerful. The loss in autonomy and flexibility is part of the cost. Individuals see things different ways, but the only vote they get is within a social context that has its own momentum. What wins is not necessarily the society that the individual feels happiest in, but the one that is most evolutionarily fit over many generations and conflicts.

That’s funny because I have seen this advice most needed in large projects, where things drag out because people keep having new ideas that they think will make it better. The insidious part is that certainly some ideas are good, the issue is that identifying the most critical changes is never definitive until you ship and see if it works.

(Obviously this advice can easily go horribly wrong in the hands of incompetent leadership, context matters, etc)

I understand the distinction, but at some point it's not super helpful, and I would argue even counter productive.

If you have a system that is big enough and has had enough change over time that it's structure is no longer well suited to the current or near future job-to-be-done, then it doesn't really matter how you got there, you need to explain to non-technical stakeholders that current business requests will take longer than it would intuitively take to build if you just look at the delta of the UX that exists today compared to what they want (ie. the "why can't you just..." conversation). This is a situation where the phrase "technical debt" is a useful metaphor that has crossed the chasm to non-technical business leaders, and can be useful (when used judiciously of course).

It actually undermines the usefulness of the metaphor if you try to pedantically uphold the distinction that tech debt is always intentional, because non-technical stakeholders will wonder why engineering would intentionally put us in this situation. I understand we all get to have our techie pet peeves (hacker != black hat), but this is really not a semantic battle I would fight if I'm dealing with anyone non-technical.

The production side is the problem. Netflix churns out shovelware crap designed to be on in the background. Every once in a while they get lucky or stick their neck out to acquire something good, but the batting average is very low. HBO on the other hand has the highest batting average, and the brand actually still stands for quality.

Of course Netflix is saying all the right things now to keep anti-trust off their backs, but at some which culture do you think is going to win out?

Yeah sorry if my assessment was a bit callous and overly critical, and I hope you don't take it personally. I meant what I said up front that it was very well articulated and made a lot of sense.

The reason I wrote what I wrote is because I came into the industry in the year 2000, and multiple times throughout my career experienced a rug pull of my own mental model of my value as a software engineer. It's very painful and something that I think ICs in deep-thinking professions like software are very vulnerable to.

Huh? The next sentence is: "The difference lies in what to do once one has rendered oneself redundant."

That entire paragraph is a string of poorly-articultated, cringeworthy sentences. In fact the whole article seems to be a series of strawmen set up on the basis of oddly specific and naive interpretations of management concepts like "servant leadership". There's basically nothing in here that I would agree with as a blanket statement without a lot of company and org-specific provisos.

All that said, to be charitable, I think what the author meant to express is that you don't want to make yourself a bottleneck as a manager, which is a common failure mode for newly converted IC to junior manager. Where he goes off the rails in the most tone-deaf way is describing that as "not doing useful work". As a manager your work is constantly observing what people are doing, staying the hell out of the way when things are working, and leaning in when things are not going well from a team and outcomes perspective. Doing that well is incredibly challenging and important work.

This is a well articulated article and the OA makes some good observations about the differences in evaluation between a product engineering org and an infra engineering org. It's also clear he's got real technical chops to finish a masters degree and then make L7 at Google in just under 8 years, and clearly that doesn't happen without an ability to navigate some level of large org politics.

I will say though, that there is still a good amount of naivete in the reasoning presented. The bottom line is that these generalizations and rationalizations are based on a single vary large company and implicitly dependent on the viewpoint and priorities of a bunch of VPs and executives whose mental model may or may not align with how you see the world in the infra trenches. Now Google is an engineering-driven culture, so the author is probably not too far off, but it also represents a particular time and place. Google has enjoyed one of the strongest and most profitable market positions that was cemented years before he entered the work force, and so there's a level of comfort and sheltered existence that infra teams at most companies do not enjoy. Make hay during the good times, but always be aware leaderships attitudes and priorities can change very quickly due to market or investor pressure, and at that point you need to be ready to adapt and articulate your value in a new environment of greater scrutiny, or to a new company (in the case of layoffs).

Sure. My point was AI was already 25% of the way there even with their verbose messy style. I think with your suggestions (style guidance, human in the loop, etc) we get at most 30% of the way there.

Sorry but from where I sit, this is only marginally closes gap from AI to truly senior engineers.

Basically human junior engineers start by writing code in a very procedural and literal style with duplicate logic all over the place because that's the first step in adapting human intelligence to learning how to program. Then the programmer realizes this leads to things becoming unmaintainable and so they start to learn the abstraction techniques of functions, etc. An LLM doesn't have to learn any of that, because they already know all languages and mechanical technique in their corpus, so this beginning journey never applies.

But what the junior programmer has that the LLM doesn't, is an innate common sense understanding of human goals that are driving the creation of the code to begin with, and that serves them through their entire progression from junior to senior. As you point out, code can be "too DRY", but why? Senior engineers understand that DRYing up code is not a style issue, its more about maintainability and understanding what is likely to change, and what will be the apparent effects to human stakeholders who depend on the software. Basically do these things map to things that are conceptually the same for human users and are unlikely to diverge in the future. This is also a surprisingly deep question as perhaps every human stakeholder will swear up and down they are the same, but nevertheless 6 months from now a problem arises that requires them to diverge. At this point there is now a cognitive overhead and dissonance of explaining that divergence of the users who were heretofore perfectly satisfied with one domain concept.

Ultimately the value function for success of a specific code factoring style depends on a lot of implicit context and assumptions that are baked into the heads of various stakeholders for the specific use case and can change based on myriad outside factors that are not visible to an LLM. Senior engineers understand the map is not the territory, for LLMs there is no territory.

Of course Google is mature enough that this particular failure mode probably won’t happen, but there may be other more concerning failure modes for individuals who are reliant on a broad swath of Google services.

Diversity of tech companies is an important consideration for me, one that definitely outweighs one-time issues, especially in a field where credible competition is limited.

That's such a reductive statement. Yes there are always some unproductive meetings one has to attend. On the other hand, you'd be surprised how many leaders and middle-managers viscerally understand the cost of low-value meetings, and are doing everything they can to empower individuals to manage their own time. They might not call bullshit in a group setting (after all, as the slides call out: critical feedback should be given 1-1), but rest assured plenty of folks understand and will not hold it against you if you vote with your attendance.

Ah fair point. Yeah I don't consider science fiction any more informative or legitimate than your opinion.

Who said that?

Why? This is arbitrary speculation on your part. We can't know such a mind through our imagination any more than an amoeba can know ours.

I value objectivity and truth as much as the next nerd, but would never set not-being-wrong as my highest value. Such a path can only lead to misery and alienation.

Automating away software engineering entirely is nothing new. It goes all the way back to BASIC and COBOL, and later visual programming tools, Microsoft Access, etc. There have been innumerable attempts to do somehow get by without need those pedantic and difficult programmers and all their annoying questions and nit picking.

But here's the thing: the hard part of programming was never really syntax, it was about having the clarity of thought and conceptual precision to build a system that normal humans find useful despite the fact they will never have the patience to understand let alone debug failures. Modern AI tools are just the next step to abstracting away syntax as a gatekeeper function, but the need for precise systemic thinking is as glaringly necessary as ever.

I won't say AI will never get there—it already surpasses human programmers in many of the mechanical and rote knowledge of programing language arcana—but it it still is orders of magnitude away from being able to produce a useful system when specified by someone who does not think like a programmer. Perhaps it will get there. But I think the barrier at that point will be the age old human need to have a throat to choke when things go sideways. Those in power know how to control and manipulate humans through well-understood incentives, and this applies all the way to the highest levels of leadership. No matter how smart or competent AI is, you can't just drop it into those scenarios. Business leaders can't replace human accountability with an SLA from OpenAI, it just doesn't work. Never say never I suppose, but I'd be willing to bet the wheels come off modern civilization long before the skillset of senior software engineers becomes obsolete.

Why is it "precisely the wrong approach"? And why does it have to be just one?

I agree looking at the quality of life of the poorest is a valuable barometer for the quality and success of a society to serve all its people. Similarly I think looking at the richest and what checks exist on their power also says a lot about the health of a civilization. It also makes perfect sense to me that we would look at wealth distributions as well. After all comparison and competition is core to the human experience, is entirely relative, and more visible than ever in the age of the internet and social media. These dynamics massively impact individual perceptions of success and political priorities, fairness being a deeply baked value in the human wetware (just ask any 5-year-old), so not sure why we wouldn't want to address them directly. Certainly there's more value than in the superficial tribalism and dog whistle culture that passes for political discourse today?

Not just the poor, how about the bottom 99%? This is what's so frustrating to me about the culture wars and identity politics. Regardless of ones views on the hot button cultural issue du jour, at best they are a distraction, and at worst actively exploited by moneyed interests as a political smokescreen to prevent changes that would be obvious wins for super majorities of the population if analyzed and viewed through a more sober and objective lens of the net effects.