dasil003

What was the Bjarne Stroustrup quote about two types of languages again? I certainly have gotten more mileage out of Markdown at this point in my long career as a programmer and web developer than I have out of hand-written HTML, XML, or other markup languages. The latter are good for automation and unambiguous representation needed for system building, but for the type of informal writing that is my bread and butter outside of coding, Markdown kills, and Obsidian is the killer app.

Define interesting. In my experience most business logic is not innovative or difficult, but there are ways to do it well or ways to do it terribly. At the senior levels I feel 90% of the job is deciding the shape of what to build and what NOT to build. I find AI very useful in exploring and trying more things but it doesn’t really change the judgment part of the job.

I agree that the way that today's generation of seasoned programmers learned their craft is going away, and that we don't know how the next generation will learn. I disagree very much with the conclusion:

> They didn’t trade speed for learning. They traded learning for nothing. There was no trade-off. There was just loss.

I believe this conclusion is due to a methodological problem, a form of begging the question if you will. One thing I am certain of is that humans who set their mind to something learn something, and good programmers are among the most tenacious in setting their mind to something. With agentic coding, they definitely learn different things, and so I would expect syntax knowledge to be weaker, but debugging and review skill will increase overall. Why? Because there will be more code, and more breakage, and I still haven't seen any tooling that allows a non-technical person to be effective at this.

Programming knowledge has always had a half-life. The way I see it, this is a big sea change that will fundamentally change the job of software engineers, and some non-trivial percentage will either change careers or find a sheltered slow-moving place to finish out their working years. But for those who were not attached to hand-crafted code, AI provides power tools that empower technically minded people more than anyone else. I have full faith that younger generation still has the same distribution of technical potential, and they will still find ways to develop their craft just as previous generations of hackers have always done.

It's wild to me to hear this being spun as vanity, like it's some influencer clickbait or linkedin slop. You could argue anyone posting anything online is driven by vanity, but in this case we're talking about someone who took agency in his own medical outcome, and essentially experimented on himself. Sure it was selfish in the sense that he didn't want to die and he bent all his effort and resources to it, so what? I don't see exercising ones will-to-live in this way being a huge moral gray area. Other commenters are saying why don't we fund more research? Well sure we should do that too, but it's important to recognize that the type of approach he took here only works because it was one individual willing to combine a significant amount of personal effort with his own moral authority to try out risky things on himself. Even with orders of magnitude more funding, you can't ethically do this kind of thing without the consent of the patients, and there's not enough data on these types of approaches to adequately describe the risks to patients if they aren't specifically motivated to lean into the details like this guy did.

Agreed. One thing I’ve found striking is how far LLMs can get with pure language and the recognition that humans often operate with a similar kind of abstract conceptual reasoning that is purely language based and pretty far removed from facts and tenuously connected to objective reality. It takes a certain kind of mind to be curious and unpack the concepts that most of us take for granted most of the time. At best people don’t usually have time or patience to engage in that level of thinking, at worst it can actively lead to cognitive dissonance and anger. So of course a consumer chatbot is not going to be tuned to bring novel insight, it must default to some level of affirmation or it will fail as a product. One who is aware of this can work around it to some degree, but fundamentally the incentives will always push a consumer chatbot to essentially be junk food for the brain.

This is a weird hill to die on. As much as I resonate with many of the concerns, I don't see refusing to use AI as something that will actually help any of those things. Forking a stable version of vim is something I guess, but I don't really see the sky falling with mainline vim or neovim.

Personally the leverage I have as a bit of a cranky graybeard myself is that I understand how software works and I can distinguish between good and bad uses of AI and think critically about how to influence things towards better software. Just declaring AI as unequivocally bad and evil will do nothing more than make me irrelevant. At some point being right is useless without some measure of also being effective.

I love your take, but I had a hard time getting through the article because “science of entrepreneurship” already feels like a contradiction in terms to me. Each startup is a product of its unique time and context. There are huge swings in fortune based on seemingly subtle factors that are not necessarily under the control of the founder but need to recognized and can force the whole vision, approach, or even the problem statement itself to shift wildly overnight. This happens over and over again, and so creating a successful startup is more akin to bull riding than any formulaic process.

Because entrepreneurship and markets overall are at the center of so many disparate human contexts, I just don’t think the scientific method is particularly applicable. I also think the minute you try to generalize between startups the fidelity of understanding the factors of success fall off exponentially. The most common failure mode—almost by definition—is failing to recognize that some seemingly good idea or pattern that worked in many other businesses just does not work in this particular context for whatever reason. This is why entrepreneurs that are too focused on theory and not enough on the details of their particular space tend to fail.

To me, The Lean Startup is useful food for thought, and can be useful in surprising ways (even in bigger companies), but the generalized ideas and statements are of very little value without a keen sense of applicability in context. Any “science” of entrepreneurship would basically be combining the systemic chaos of macroeconomics less the precision of standard financial metrics plus all the human factors of psychology. Fascinating to think about, but I doubt the best pundits and theorists would themselves make good entrepreneurs.

Agree the jury is still out, but "More code in less time" is a shallow strawman. The better question is what is it good at and what is it not good at, and what are the ways to best leverage those capabilities. I've seen enough use cases from enough engineers now that I firmly believe anyone saying "nope never useful" is sticking their head in the sand.

These rules aged well overall. The only change I would make these days is to invert the order.

Number 5 is timeless and relevant at all scales, especially as code iterations have gotten faster and faster, data is all the more relevant. Numbers 4 and 3 have shifted a bit since data sizes and performance have ballooned, algorithm overhead isn't quite as big a concern, but the simplicity argument is relevant as ever. Numbers 2 and 1 while still true (Amdahl's law is a mathematical truth after all), are also clearly a product of their time and the hard constraints programmers had to deal with at the time as well as the shallowness of the stack. Still good wisdom, though I think on the whole the majority of programmers are less concerned about performance than they should be, especially compared to 50 years ago.

Don't shoot the messenger, I'm just telling you how some hiring managers might think, not endorsing the opinion and it's definitely not something I consider in my hiring.

I will say it's a little weird to frame it as "every fad" though. Do you really not see any net new or lasting utility for software engineering in AI tools? If not then more power to you, but software engineering being a fast-moving field where there are (fair or unfair) expectations to keep up is nothing new.

Having taken a startup from 2 to 100 a lot of the comments here resonate, but now that I'm in a company of 10,000 and trying to get things down across wide areas, I would say efficiency and communication overhead are all relative and make sure you're solving the problems in front of you and not "playing house" on problems you anticipate having down the line.

You will need more structure than you had before. For instance at 15 the idea of managers is silly, everyone still needs to be contributing individually, the only thing is that you do need to minimally subdivide work so that everyone isn't doing everything. Be wary of process for processes sake, you will start to need some but you really want to stay focused on concrete progress; is everyone doing the most important thing possible at every given moment? How fast are you shipping changes, closing sales, etc? Also make sure you have the right people, don't get starstruck by big tech vets. They have many skills that will be useful—if you are phenomenally successful—but if they don't have startup experience they likely will overengineer things by default, and a significant percentage of them can not wipe their own ass without the best-in-class tooling and infra support teams that allowed them to focus purely on one domain at BigCo. Basically you need pragmatic hustlers, veterans are good so long as they aren't cathedral or empire builders. Also watch out for weird team dynamics and nip any toxic interactions in the bud, one bad apple really can spoil the barrel; that's probably the most important thing to watch out for in the 15-100 range.

I suspect it’s not about agentic coding being a special skill, and more about why a competent programmer wouldn’t have tried it by this point, and whether that is a sign of ideological objections that could cause friction with the team. Not saying I agree with that thinking, but I definitely see why a hiring manager could think that way.

Looking for 5 seconds at the github profile I see a bunch of music-related stuff, and also a bunch of contributions to private repos that we have no idea what they are. I get the productivity guru anti-pattern, but I honestly don't know what you're looking at that merits this kind of reflexive personal attack.

If this was done well in a way that was productive for corporate work, I suspect the AI would engage in Machievelian maneuvering and deception that would make typical sociopathic CEOs look like Mister Rogers in comparison. And I'm not sure our legal and social structures have the capacity to absorb that without very very bad things happening.

I've long thought of the analogy as useful for human teams, and it even shows up in the corporate jargon (eg. "I'm blocked", "We need to align", etc). It's surprisingly common for whole branches of a large org to be doing net negative work due to conflicting goals or not realizing some implication that cuts across teams and local contexts. Sometimes these issues are technical but just as often they are pure product or business decisions with no explicit dependency until a lightbulb goes off somewhere.

With hand-written code, things generally move slow enough, and there's enough common sense sprinkled across the org chart that things can get uncovered organically. With agent teams, speed increased by several orders of magnitude and common sense is out the window, so I suspect the ceiling on productive use of agents will be far more limited in number than traditional engineering teams, and it will heavily depend on who and how humans are plugged into the right places.

One thing I suspect professional researchers underestimate is how much positive output can be produced by a human team with vague or hand-wavy direction, and surprisingly little deep thinking, let alone a robust specification or structure to keep them on track. The reality is any large team regresses to the mean, and it's usually a few savvy people that actually drive outcomes. These people don't necessarily have official authority, just a nose for the right thing. This won't spontaneously emerge from agents (at least until they become a lot more human like in terms of big picture common sense, and dial down the sycophancy to a more "skeptical engineer" level).

In other words they haven't really pushed the vision forward since the Jaws 19 hologram in Back To The Future 2.

This is spot on. I'm always amused when people talk about how much staffing a given product "needs". That's not how headcount works or even system design works.

What actually happens is that company headcount grows based on how much money they make (or how much they raise), this justifies hiring more people. Then, structure is added, both to systems (eg. microservices), and to operations (eg. jira, workday, salesforce, etc) so that communication overhead doesn't grind everything to a halt. Then, once the business stops growing, headcount must shrink. This may take a long time, and it will be couched in all kinds of corporate bullshit to try to preserve morale and investor sentiment, but that is all window-dressing.

Have you looked at the actual expenses and where you think they should cut rather than people? Or are you saying with all those people they should be able to turn their growth story around?

It's also a function of young ambitious people just following the money over time. Finance has grown and grown and grown because it's the easiest place to skim the cream. Combine that with the fact that it's transferable from company to company and it's clear why the trend. Obviously the only innovation these people are capable of is financial innovation (repackaging derivatives, ever-more-convoluted deal structures to snow people, etc), but that doesn't much matter as long as there is a sufficient base of enough new companies with actual innovations sprouting up that it provides enough grist for the finance mill.

When you create a site with a tone this self-righteous and condescending, you should really double check your thinking to make sure there is not some glaring flaw invalidating the premise for the majority of people in the world:

> A US ZIP code is 5 characters. From those 5 characters you can determine the city, the state, and the country. That's 3 fields. Autofilled. From one input.

I guess this is par for the course in Trump's America, but I still feel embarrassed for the creator.

Yeah it proves nothing, but it hits. Felt good to read it, at a time when a lot of things don't feel good to read on the internet, so I'll call it a win.

Overall I liked the article because I think the secretary analogy is closer than any of the industrial revolution comparisons that are more common, but you do make some really good points about the nature of the work and how conditions are different today.

In terms of lowering quality, I don't think this is anything new. Volume of code and depth of stacks has been growing pretty much in parallel with Moore's law, and this has degraded code quality. AI is accelerating this, and creating a new kind of slop since LLMs are sloppy in a different way than humans, but directionally I see it as part of the same trend.

However despite lowering quality, and increasing messiness, capabilities and user expectations have steadily increased. After a quarter century in this industry, I am blown away by the capabilities of modern computing, and the polish level of the best apps. The median bar for successful software is higher than its ever been. And to achieve this we've had to navigate steadily increasing complexity (much of it incidental), and that is where senior software folks shine.

So yeah, I think your observations are prescient and I agree with a lot of your, but I wouldn't characterize it as "nothing good ahead". I see it as a mixed bag, like all "progress", it just needs time to bake and get our arms around the impact. Currently the rate of change and hype is far out-pacing our ability to reason about it, perhaps that's the single biggest difference in the smart-phone, internet-enabled era of humanity.

I think the analogy is directionally good, but it short changes the abstract and recursive nature of software.

We were already writing code that was automating not only manual work but also simpler programs. LLMs essentially just move us one more (large) hop up the abstraction ladder. And yes I get that it’s a different type of hop (non-deterministic, extremely leaky, etc), but it’s still a hop.

So if the only thing you want to do is manually write code in the traditional way (perhaps with vim instead of IntelliJ) then yeah I think you’re cooked. On the other hand, if you are willing to work with LLM-assisted tooling and learn how to compensate for its shortcomings then I think you’ll have a bright future.

I'm sort of shocked at how little of my argument seemed to land with you in any way. I'm wondering how many cycles of software hype have you been through? Were you here for the PC revolution, the .com era, smartphone mass adoption?

There's a lot of what-ifs, and worst case scenarios in your reply that I simply don't find likely. I am not drinking the koolaid from the AI maximalists or the doomers. I could be wrong of course, no one can predict the future, but to me the very real, novel and broad utility of LLMs that we are just learning to harness combined with the investment outlook are leading to a mania that has people overestimating where things will land when the dust settles. If I'm wrong then I guess I'll join the disenfranchised masses picking up pitchforks, but I'm not going to waste time worrying about that until I see more evidence that it's actually going that badly.

So far what I see is that software engineers are the ones getting the most actual utility of AI tooling. The reason is that it still requires a precision of thought and specificity to get anything sustainable out AI coding tools. Note this doesn't mean that engineers can design better apps than proper designers, rather my point is that designers and other disciplines still can not go much further than prototypes, they still need engineers to write the prompts, test the output, maintain the system, and debug things when they go wrong. I have worked long enough with large cross-functional teams to know that the vast majority of folks in non-engineering functions simply can not get enough specificity and clarity in their requests to allow an LLM to turn it into a working system that will work over time. The will hit a wall very quickly where new features add bugs faster than they improve things, and the whole thing collapses under its own weight like a mansion of popsicle sticks. And by the way, I don't consider AI-assisted coding to require less qualification than regular coding. Sure you don't need to know as much syntax or algorithms, but you absolutely need to know data modeling, performance, reliability, debugging, consistency, and migration knowledge in order to use AI to contribute to any software that powers a real business, and yeah you might need to develop your product and business sensibilities, but to me that's what been happening throughout the history of computing. Wiring up ENIAC, certainly required qualifications that were not needed for assembly programing, which in turn required certain things that C programmers did not need and so forth, but harnessing the increasing compute power and complexity required new qualifications. I don't think AI will ultimately be that different, it will change the way we work, it doesn't replace what senior engineers do.

It'll never happen because it shines a light on uncomfortable facts that would risk far too much cognitive dissonance across the political spectrum. Please keep the discourse to identity politics, culture wars, the Epstein files, and large-scale, unprovoked acts of international warfare; those will all be much easier for us to talk about as a nation than what we should do about housing prices.

Ah, I can't see that because I'm not logged into Twitter. Doesn't quite pack the same punch does it?

The graph does a really poor job supporting the conclusion, most obviously because it only goes back to 2016, the peak of boom times, it doesn't go anywhere near 2008 so why does the caption talk about that? Just this same graph alone going back to 1990 would be super eye-opening.

The other thing is it's showing first derivative, not absolute numbers, which is a very questionable way to derive "worst employment situation" in a field that has been on world-changing boom over the last 50 years.

The justification of better UX seems reasonable regardless of politics. I'd prefer not to have to log in on any HN link, and I also can't say I want to optimize for link health as this is super topical and I will never want to look at it again after this discussion is over.

I feel like this study is very naive about how corporate status and power works. Consider this part:

> Employees who are more likely to fall for corporate bullshit may help elevate the types of dysfunctional leaders who are more likely to use it

The rank and file don't elevate leaders, it's decided by higher-ups, and the higher you go the more they care about actual non-bullshit results. Where bullshit thrives is because higher level business strategy is actually hard and ambiguous, so there's a continuum of bullshit where you are expected to at least say credible things, but it's couched in bullshit terminology to broaden the range of success they can claim, and leave room and plausable deniability for failures. Strong leaders are keenly aware of this nuance, and therefore leaders are judged on reputation and outcomes over time, because any given thing they say may be wrong, but the track record is undeniable. This is why you never hear a bad word about leaders while they are there, they are just fired (or more likely "resign") one day seemingly out of the blue.

What this article misses is that to survive in a corporate environment everyone needs to put up and nod along to bullshit. Most of the time whether it's right or wrong and the level of bullshit doesn't really matter to most of the employees, they're just incentivized to play along and not express negativity. Within the rank and file, obviously some are more susceptible to bullshit than others, but I don't think this study necessarily gets at that, as a lot of people will act agreeable just to survive in corporate life, and their disposition will be largely independent of their true understanding and feelings about whatever bullshit they are presented with day to day.

You raise some good points about the economics, that's where I feel the least confident, but let me explain my reasoning.

Software has eaten the world, and thus the value of maintaining software has never been hire. Engineers are the people who understand how software works. Therefore unless we move away from software, the value of software engineering remains high.

AI does not reduce software, it increases the amount of software, makes messier software and generally increases the surface area of what needs to be maintained. I could be wrong, but as impressive as LLM's language and code processing capabilities are, I believe there is a huge chasm that will likely never be crossed between the human intent of systems and their implementation that only human engineers can actually bridge. And even if I'm wrong, there's another headwind which is that, as Simon Willison has point out, you can't hold an LLM accountable, and therefore corporate leaders are very unlikely to put AI in any position of power, because all the experience and levers they have for control are based on millenia of evolution and a shared understanding of human experience; in short they want a throat to choke.

The other factor is that while AI can clearly replace rote coding today, I think the demos oversell the utility of that software. Sure it's fine to get started, but you quickly paint yourself in a corner if you attempt to run a business on that code overtime where UX cohesion, operational stability and data integrity over time are paramount and not something that can be solved for without a lot of knowledge and guardrails.

So net of all this, where I think we land is a lot of jobs that are based purely on knowledge of one slow-changing system and specific code syntax will go away, but there will be engineers who maintain all the same code, they'll just cover more scope with LLM assisted tools. You put your finger on something, that I do believe this moves engineering closer to product design, but I still think there's a huge amount on the engineering side that LLMs won't be able to do any time soon (both for technical and the social reasons stated above), and ultimately I don't see the boundary the same way you do, as software engineers we have always had to justify our systems by their real world interaction.