dasil003

I don't feel threatened because no matter how tools, platforms and languages improved, no matter how much faster I could produce and distribute working applications, there has never been a shortage of higher level problems to solve.

Now if the only thing I was doing was writing code to a specification written by someone else, then I would be scared, but in my quarter century career that has never been the case. Even at my first job as a junior web developer before graduating college, there was always a conversation with stakeholders and I always had input on what was being built. I get that not every programmer had that experience, but to me that's always been the majority of the value that software developers bring, the code itself is just an implementation detail.

I can't say that I won't miss hand-crafting all the code, there certainly was something meditative about it, but I'm sure some of the original ENIAC programmers felt the same way about plugging in cables to make circuits. The world of tech moves fast, and nostalgia doesn't pay the bills.

In big companies there is always waste, it's just not possible to be super efficient when you have tens of thousands of people. It's one thing in a steady state, low-competition business where you can refine and optimize processes so everyone knows exactly what their job is, but that is generally not the environment that software companies operate in. They need to be able innovate and stay competitive, never moreso than today.

The thing with AI is that it ranges from net-negative to easily brute forcing tedious things that we never have considered wasting human time on. We can't figure out where the leverage is unless all the subject matter experts in their various organizational niches really check their assumptions and get creative about experimenting and just trying different things that may never have crossed their mind before. Obviously over time best practices will emerge and get socialized, but with the rate that AI has been improving lately, it makes a lot of sense to just give employees carte blanche to explore. Soon enough there will be more scrutiny and optimization, but that doesn't really make sense without a better understanding of what is possible.

I agree with both you and the GP. Yes, coding is being totally revolutionized by AI, and we don't really know where the ceiling will be (though I'm skeptical we'll reach true AGI any time soon), but I believe there still an essential element of understanding how computer systems work that is required to leverage AI in a sustainable way.

There is some combination of curiosity of inner workings and precision of thought that has always been essential in becoming a successful engineer. In my very first CS 101 class I remember the professor alluding to two hurdles (pointers and recursion) which a significant portion of the class would not be able to surpass and they would change majors. Throughout the subsequent decades I saw this pattern again and again with junior engineers, bootcamp grads, etc. There are some people no matter how hard they work, they can't grok abstraction and unlock a general understanding of computing possibility.

With AI you don't need to know syntax anymore, but to write the write prompts to maintain a system and (crucially) the integrity of its data over time, you still need this understanding. I'm not sure how the AI-native generation of software engineers will develop this without writing code hands-on, but I am confident they will figure it out because I believe it to be an innate, often pedantic, thirst for understanding that some people have and some don't. This is the essential quality to succeed in software both in the past and in the future. Although vibe coding lowers the barrier to entry dramatically, there is a brick wall looming just beyond the toy app/prototype phase for anyone without a technical mindset.

This take is pretty uncharitable. I write high quality code, but also there's a bunch of code that could be useful, but that I don't write because it's not worth the effort. AI unlocks a lot of value in that way. And if there's one thing my 25 years as a software engineer has taught me is that while code quality and especially system architecture matter a lot, being super precious about every line of code really does not.

Don't get me wrong, I do think AI coding is pretty dangerous for those without the right expertise to harness it with the right guardrails, and I'm really worried about what it will mean for open source and SWE hiring, but I do think refusing to use AI at this point is a bit like the assembly programmer saying they'll never learn C.

The Anna Karenina principle looms large in software engineer projects. Basically there are an infinite failure modes that can occur due to small actions or wrong thinking by one or more influential people, but there is only one way to make large projects successful. Basically the team has to have sufficient expertise to cover the surface area, and those individuals need enough trust from leadership to navigate the million known and unknown pitfalls that await.

Yes I remember those days! I joined a startup whose first product was a Facebook app in 2007. We were right around the corner from Facebook HQ on Forest and High, and we were alpha partners for the launch of Pages. We created a feature film streaming app (the learning was: no one watches 100-minute videos on Facebook). While we never intended to be a Facebook-app company, technically it was the first thing we launched.

Fast forward 18 years, and the company is going strong with millions of subscribers and distributing Oscar winning films such as Demi Moore’s The Substance.

Because it was a middlebrow dismissal of the GP

I get the sentiment, but if you can't acknowledge that AI is useful and currently a lot better than search for a great many things, then it's hard to have a rational conversation.

No doubt! Collective action is a solved problem! Why do people do things other than the obvious Right Things we can all agree on? Must be some kind of mass psychosis…

I've been invested largely in US index funds for a while now, and I've definitely thought about this. My conclusion is S&P 500 is too big too fail, everyone with various forms of power in the US (economic, political, etc) are incentivized to keep the music going. Sure it feels unsustainable, but there is no way going active can help me—I don't have enough access to the right people, and even if I did, it's better as a hedge strategy. Someone who has a billion dollars can easily pace a bunch of $10M bets on long-shot hedges that will mint a fortune when the music stops. Theoretically I could do something similar at smaller scale, but the people smart enough to have credible strategies are not talking to me, and even if they did I don't have the expertise to judge the advice (the super rich don't either, but at least AUM volume is some signal of competence).

This seems like a purely cynical lacking any substantive analysis.

Despite whatever nasty business practices and shitty UX Windows has foisted on the world, there is no denying the tremendous value that it has brought, including impressive backwards compatibility that rivals some of the best platforms in computing history.

AI shovelware pump-n-dump is an entirely different short term game that will never get anywhere near Microsoft levels of success. It's more like the fly-by-nights in the dotcom bubble that crashed and burned without having achieved anything except a large investment.

Halfway to The Last of Us conversion for Fortnite

Yeah or “the signs all say to walk down this long passage, and then back via a circuitous route for flow control, but my destination is actually 100 feet away through this unmarked passage so I’ll just go that way” situation at Bank

London and Berlin felt pretty comparable to me, with the airport situation better in London but the biking situation better in Berlin (marginally).

Tokyo is just on another level entirely.

Middle management is a tremendous market for lemons. It's difficult to do well, and each layer requires a very different skillset. One of the side effects of the hypergrowth era of big tech between 2008-2023 is that a lot of managers were needed to support the amount of hiring, and they weren't very well trained, and often they could claim success for a rising tide almost by default as long as they didn't do anything too blatantly stupid.

The Peter Principle is of course well-known, but one of the insidious things is that once you have enough incompetent management and they are entrenched for a while, they will teach all the wrong lessons to an entire generation of new hires coming in. Due to the incentives and optics of large orgs, managers tend to spin everything in a positive light publicly, and the real unfiltered discussions of failure happen in tighter circles. At some point a lot of "successful" folks can have job hopped their way through a bunch of brand name companies just cargo culting on what they've seen done before with no real understanding of how their work actually impacts the company's bottom line.

This is one of the reasons I'm incredibly thankful to have spent most of my early career in small companies and startups where the big picture was so much easier to see.

The “How it works” section is an absolute mess. Each bullet uses a different pronoun, so it’s not clear who the actors actually are and how this all fits together. How are the “crypto bros” who approach the “tech person” related to the “fame hungry tech bro” that vibe-coded the failed app?

I’m sure there’s a tremendous long tail of scam attempts these days, but I’d be surprised if crypto scams haven’t already seen their high watermark in terms of actual victims.

You’re taking it too literally, it’s not saying don’t be useful, it’s saying don’t make yourself a bottleneck. It’s a very common failure mode for new engineers turned manager, leading to a frustrated team that feels micro-managed and the perception from leadership that you don’t have your shit together and can’t adequately handle the scope you’ve been given.

How does a football coach do their job if they can’t run or throw or block as well as the players?

This is a great insight and something every engineer should reflect on in the context of their own orgs:

> estimates are not by or for engineering teams.

It's surprising the nuance and variety of how management decisions are made in different orgs, a lot depends on personalities, power dynamics and business conditions that the average engineer has almost no exposure to.

When you're asked for an estimate, you've got to understand who's asking and why. It got to the point in an org I worked for once that the VP had to explicitly put a moratorium on engineers giving estimates because those estimates were being taken by non-technical stakeholders of various stripes and put into decks where they were remixed and rehashed and used as fodder for resourcing tradeoff discussions at the VP and executive level in such a way as to be completely nonsensical and useless. Of course these tradeoff discussions were important, but the way to have them was not to go to some hapless engineer, pull an overly precise estimate based on a bunch of tacit assumptions that would never bear out in reality, and then hoist that information up 4 levels of management to be shown to leadership with a completely different set of assumptions and context. Garbage in, garbage out.

These days I think of engineering level of effort as something that is encapsulated as primarily an internal discussion for engineering. Outwardly the discussion should primarily be about scope and deadlines. Of course deadlines have their own pitfalls and nuance, but there is no better reality check for every stakeholder—a deadline is an unambiguous constraint that is hard to misinterpret. Sometimes engineers complain about arbitrary deadlines, and there are legitimate complaints if they are passed down without any due diligence or at least a credible gut check from competent folks, but on balance I think a deadline helps engineering more than it hurts as it allows us to demand product decisions, designs, and other dependencies land in a timely fashion. It also prevents over-engineering and second system syndrome, which is just as dangerous a form of scope creep as anything product managers cook up when the time horizon is long and there is no sense of urgency to ship.

Software itself is not inherently valuable, the value is in running and maintaining its data and any necessary integrations to other systems.

The bar for me to pay for a $10/month software subscription is pretty high, but once I make the decision that it's valuable, the actual cash cost is pretty low. Vibe coding something will never approach the quality of something that someone put enough thought and effort to turn into a product. The main place where I'll write my own software is when it's truly custom to my own needs, AI is a force multiplier for this type of work, but at the end of the day I still have very limited time to run and maintain a lot of custom software and data, so it's not going to cannibalize any of the SaaS I'm willing to pay for.

Obviously for younger software guys with more time than money, the equation will be different, but those were never the make-or-break demographic for SaaS anyway. I don't think the equation has meaningfully changed for SaaS sales due to AI, I see it more as continuously rising bar over the last two decades due to UX expectations, market saturation, limits on human attention and complexity tolerance.

Agreed, optimism/pessimism is just about our disposition to the world as we perceive it (ie. glass half full or half empty). It is orthogonal to understanding and prediction. A perfect Buddhist is neither an optimist or pessimist but can still be better or worse at predicting the future.

I do think pessimists, especially of the depressive variety generally do not get rich. The reason is that getting rich is hard, everyone nominally wants it, so it’s highly competitive and there are no easy paths. To find a path generally you have to take an action that almost by definition is low probability of success. You don’t have to be a beaming cheerleader to make this happen, but being an eyore is most likely disqualifying.

People are not inspired by institutions and committees, you need a personality that can articulate a vision.

Oh man do I have opinions.

First of all, I've seen all type of teams be successful, ranging from zero QA at all, to massive QA teams with incredible power (eg. Format QA at Sony in Europe). I have absolutely seen teams with no QA deliver high quality full stop, the title is nonsense.

My firm belief is that QA can raise the ceiling of quality significantly if you know what you're doing, but there is also huge moral hazard of engineers dropping the ball on quality at implementation time and creating a situation where adding more QA resources doesn't actually improve quality, just communication churn and ticket activity. By the way the same phenomenon can happen with product people as well (and I've also seen teams without product managers do better than teams with them in certain circumstantes).

The most important anchor point for me is that engineering must fundamentally own quality. This is because we are closer to the implementation and can anticipate more failure modes than anyone else. That doesn't mean other roles don't contribute significantly to quality (product, design, QA, ops absolutely do), but it means we can't abdicate our responsibility to deliver high quality code and systems by leaning on some other function and getting lazy about how we ensure we are building right.

What level of testing is appropriate for engineers to do is quite project and product specific, but it is definitely greater than zero. This goes double in the age of AI.

> …when you’re in a position to help

This clause is doing a lot of heavy lifting. One needs to have good judgement about when and how to help. A lot of people can imagine how things could go better if a bunch of other people changed their behavior in surprisingly simple ways. It's a much smaller subset of people that can correctly push the right buttons to get the other people to actually make those changes succeed at a systematic level.

In a small org it's actually not too hard for good ideas and feedback to get traction. In a larger org for broad concerns it can be fiendeshly difficult. Often the reason why a large project will fail is only truly knowable by a few senior technical people with enough experience and broad context to see the forrest for the trees. Past a certain volume of people involved you can not explain to people why it will fail fast enough to offset the army of clueless stakeholders incentivized to socialize a good-sounding narrative convincing everyone that we need to try. In these cases reductive explanations with the right counter-narrative can work, but they require significant reputational and/or hard authority to pull off.

This is why the article advocates picking your battles in a large org. Often the chance of actually helping is much lower than destroying your own reputation, even if you're right.

Yeah, ultimately you're paid to deliver results. Criticism is only of value to the degree that it leads to better results; there is zero value in predicting failure per se. Some people place so much value on being right that they lose sight of the actual goals (and I won't say I'm immune to this, but marriage helped). Nothing with a high upside is low risk, so as en employee you need to inherently frame all risks in terms of identifying the most likely path to succeed.

The only alternative is to advocate for inaction, but then why are they paying you? Those kind of bets can make sense for private equity investors, but not for employees, and my builder-brain just finds them dull and annoying.

I'm sorry you have to use Teams, but at least they let you smoke

SaaS is not just software though, it’s operationalized software and data management. The value has increasingly been in the latter well before AI. How many open source packages have killed their SaaS competitors (or wrappers)?

No that’s not really how it works in tech at all. There’s a deep recognition that individual engineers (and other functional practitioners) have important knowledge and expertise that is essential. Of course you do need some overlap and redundancy so that people can take sick days and avoid the wheels falling off through attrition, but competent shops aren’t ever treating people as numbers. To the contrary good ICs are widely recognized as being much less full-of-shit then management.

They also get crappier though. I am generally okay with a lot of the tradeoffs to reduce the cost of construction and mass production. We definitely have more crappy stuff than we need—I'd prefer if we had a little less, higher quality stuff, but the balance is not too far out of whack.

With media though, I feel it's a lot worse. It's already been trending that way for text with blogspam already diluting the value of the web even before AI. But with AI this is accelerating to video and audio as well. Not only does the AI slop drown out the best of human creativity, it also raises the floor on superficial production value so that if you don't use AI you fall behind on the initial attention-grabbing first impression. I acknowledge a big part of this is due to where we are in the hype cycle, and once we absorb the capabilities of the tools, we'll figure out how to use them more tastefully, and human creativity will shine through again. But no I don't think always making everything easier and more efficient is necessarily always a good thing a priori. Friction and effort sometimes leads to positive outcomes.

I've gotten way more out of open sourcing software than I ever could have by trying to sell the same software. Not all value is monetary, and participating in open source creates different types of technical capital (reputational, barter, scratch-your-own-itch, etc). If you want to sell software, all of a sudden you're playing a very different game that is way more marketing/sales and way less technical.

There's nothing wrong with that, but know what you're signing up for. If you just want to be paid like a carpenter, contracting for time and materials is the standard way to do that, much easier than starting a software company.