No, this thread and sub-discussion is about specifically early web fundamentals. The web is special in this sense, it's intentionally long-lived warts and all. So the fundamentals pay outsized dividends. The rube goldberg machine that is modern JS dev still spits out an index.html result.
Being a good professional developer means getting the primitives and the data model not horribly pointed in the wrong direction. So it's extremely helpful to be aware of those primitives. And the argument "nobody is better off knowing assembly as a primitive" doesn't hold because as-said the web is literally still html files. It's right there in the source.
The discussion is centered around the idea that "adopting early" provides some future proofing in a rapidly evolving (and largely non-standard) terrain. I share the FA's position that it does not.
> The web is special in this sense, it's intentionally long-lived warts and all. So the fundamentals pay outsized dividends.
Fundamentals pay dividends, but what makes you think that what you learn as an early adopter are fundamentals? Fundamentals are knowledge that is deemed intemporal, not "just discovered".
The historical web and its simplicity are as available to anyone today as it was back then. People can still learn HTML today and make table-based layouts. HTML is still HTML, whether you learned it then or today. But if back then you intended to become a professional front-end developer, you would still have to contend with the tremendous difficulties that some seem to have forgotten out of nostalgia. You'd soon have to also learn CSS in its early and buggy drafts, then (mostly non-standard) JavaScript (Netscape and IE6) and the multiple browser bugs that required all kinds of hacks and shims. Then you'd have to keep up with the cycles of changing front-end tools and practices, as efforts to put some sense into the madness were moved there. Much in all that knowledge went nowhere since it was not always part of a progression, but rather a set of competing cycles.
Fundamentals are indisputably relevant, but they're knowledge that emerges as victorious after all the fluff of uncertainty has been left behind. Front-end development is only now settling into that phase. With LLMs we're still figuring out where we're going.
This sounds exactly right. I'm someone who learned the web back when IE6 was something we wished everyone was on, and also someone who learned the fundamentals of the web and CS in general enough to try writing a book about it to teach everyone else.
Picking up the web early didn't help with the latter. I spent most of my early time memorizing tips and tricks that only applied to old browsers. I didn't pick up the fundamentals till I went back to school for CS and took a networking class.
web fundamentals and web development fundamentals are different.
How HTML, CSS and javascript come together is extremely relevant to developers 20 years ago and today.
I do support and agree with the parent comment, see the discussion, but I do credit getting into web development when it was raw and open paid dividends for me. Todays ecosystem is opaque in comparison. You don't think there's more friction today?
HTML CSS and JavaScript are just a small subset of web development.
And yes understanding them is still relevant. But when I started I was spending more time memorizing the the quirks of IE6 than I was learning how JavaScript, CSS, and HTML come together.
I think it you start directly in react you don’t learn the layer below it sure. But there’s no reason you have to start leaning react. There’s nothing inherent about starting today that forces you to start directly with React. You could start building a static webpage. And if you did that it would be easier and more fundamental than if you did that same thing 20 years ago because you can ignore most of the non-standard browser quirks.
You're right, fundamentals are distilled, so to think they are free just by getting in early is likely backwards. And earning one's professional chops doesn't stop or start based on when you enter.
Web dev definitely is nostalgic. I miss the early days but I also conveniently erased ie6, binding data to HTML, the need for backbone and jQuery to do anything. hmmm yeah doesn't matter when you start, it's all a grind if you dig deep enough.
The web/html is a great analogy. I too am in no rush to be hyper effective with LLMs. In fact i want to deliberately slow down because ai-native coding is so exhausting.
That said, your point about the leverage of learning html and web in the early days compared to now rings true. pre-compiled isomorphic typescript apps are completely unrecognizable from the early days of index.html
The llm person having a blast is compelled to push everyone to see what they see. If they have a leadership role at their company, then the getting-left-behind drum does get banged in the form of "ai native company transformation" initiatives.
But it doesn't make the survivors wrong about their experience. Two truths: their experience did happen roughly how they said it happened + they got very lucky.
Seems like all the other 9 that died insist on telling the one that survived that they were somehow wrong.
For sure, I do get that one can "do everything right" and still fail, I get that point, I get that there is no formula. But it seems like people want the reverse to be true: that everyone successful is only a lucky buffoon.
Sure, but I like it to my military service, I remember the good parts only, unless I start digging.
Nobody wants to read about normal life, either you claim success or you claim failure, in between sells no copies.
What do I know, I don't run a billion dollar startup. But there's a valuable "necessary but not sufficient" insight to all good advice. The lean startup IS good advice. The best I can do with your argument is "getting out of the building is no longer sufficient".
Sure. But it doesn't make the entire arch of how we got here "wrong". And yes, all companies were started with a few people, a few customers. So that's why there's nothing much here to see for me, other than defeatist sentiment.
Seriously, how do you even realistically approach taking on ASML. They spent decades and billions of (investment) dollars to do insane moonshot research and it paid off. But it also closed off the door behind them.
Entire countries (Russia, China, ...) have been trying to reproduce it. They have not succeeded yet.
I'm genuinely asking why are we goaling on overtaking the most valuable companies in human history?
Startup advice, as i understand it, is about innovation: expanding the pie. I sound like a VC shill. Don't mean to be, i know it's riddled with rich people passing money around pretending like value is being created.
It's just I don't get what's so wrong with the HN crowd here trying to be better at building a successful company?
Reproducing an ASML machine is a piece of cake. Okay, not a piece of cake but definitely doable. The problem is that you cannot sell your reproduction in rich countries because the US government will threaten you with sanctions and US companies will screech "patents!".
No its not, you have to be extremely precise when making the machine, and only ASML knows how to do that. China already have a big government funded project to reproduce ASML machines and they have failed so far.
Nonsense. Patents are a locked glass door; anyone can get in if they knock hard enough. And Chinese engineers wear heavy gloves and eye protection when going door-to-door.
I used to work for ASML as a design engineer, and I asked my manager why we didn't shred our paperwork, like some other companies I worked at.
"With all the trouble we've had, getting our designs to work? We should publish them to slow down our competitors!"
He wasn't wrong. “Nothing that's good works by itself, you've got to make the damn thing work.” — Thomas A. Edison.
> Reproducing an ASML machine is a piece of cake. Okay, not a piece of cake but definitely doable. The problem is that you cannot sell your reproduction in rich countries because the US government will threaten you with sanctions and US companies will screech "patents!".
... An argument that may not convince China and Russia, who have a track record of ignoring it - I doubt it is a significant reason why they have not achieved semiconductor manufacture tooling parity.
>I doubt it is a significant reason why they have not achieved semiconductor manufacture tooling parity.
It's not enough to reproduce just the work of asml, you basically have to reproduce their entire supply chain, because, same reason, their suppliers will have trouble obtaining export permissions.
It makes sense to me to try to be good at Capitalism. You're right, it may be a fool's errand, but what's the alternative?
FWIW, can't believe I'm replying to literally "throwaway random number" but Capitalism isn't my cup of tea. I rode around on a bicycle for the last decade.
It's not like the past generations didn't try to make it work, too, and for-profit development has failed to deliver the promise of technology that uplifts rather than oppresses by any metric i can think of. If capitalism doesn't work, and there are no alternatives, then perhaps we shouldn't be using chips at all and we should be focusing on other means to solve problems in our society.
Edit: wikipedia is nice. So are cheap universal personal cameras. Point to point communication is nice. None of these require capitalism at all; indeed, capital will want to rent out these as well (if you aren't already renting through a cell plan). why must our needs always be subservient to those of the market?
Insightful and helpful to peer into another company's experience. Mostly agree with your highlighted points.
> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
This is where unnerving exhaustion comes from though.
I know myself to be on the side of craftsmen. It does takes tons and tons of time to code, but I didn't get exhausted the way I do with AI. AI is productive, I am pro-AI. But boy is it a different kind of work beast.
The intention of the title is to say your main problem. The problem separating you from $PROFIT$:
1. Idea
2. ???
3. Profit
Coding effectively is definitely one problem. And you're right that AI helps with that problem. But for startups, side-hustles, VC-pitches and the inner-workings of companies (HN crowd) coding was never the problem.
edit to add: So for people working on professional software teams, the discussion is how a hyper-increase in raw code production affects everything down stream. There are many moving parts to building stuff and selling it to people. So there's not a 1:1 line to more code = better outcome from the system level view. It's not clear, at least.
> But for startups, side-hustles, VC-pitches and the inner-workings of companies and so on (HN crowd) coding was never the problem.
I'd say you're 180° wrong. Getting to an MVP fast is the most immediate problem when you've started a startup. Iterating on ideas fast is the most immediate problem once you've released your MVP. You need an MVP to get users, and you need to to iterate to find product-market fit. Perfectly crafted code is a luxury problem you can't afford in the early stages.
This isn't in defense of perfectly crafted code. It's about NO CODE. Do not write (ai-moar) code! It's not the code that is the problem.
I understand the need for MVP to bring an idea into reality. It's the feedback that's valuable not the code. This is not about the code. So why is the argument "write more code"?
In any case, I have yet to create a product on my own that has done well financially. So what the hell do I know. If you have, then I should probably listen to you. But I have worked on teams for successful companies and in my career, the best advice I can give to an engineer is that your code matters, do a good job and care about what you make; also it's not about the code.
It isn't, that's what you injected. The argument was "write [the same amount of] code faster". And that is undoubtedly a good thing, because execution speed can make or break your startup.
Thanks for the story. I also spent time as a delivery driver at an italian restaurant. It was a blast in the sense that i look back at that slice of life with pride and becoming. Never got the chance to be a waiter, but definitely they were characters and worked hard for their money. Also the cooking staff. What a hoot.
Being a good professional developer means getting the primitives and the data model not horribly pointed in the wrong direction. So it's extremely helpful to be aware of those primitives. And the argument "nobody is better off knowing assembly as a primitive" doesn't hold because as-said the web is literally still html files. It's right there in the source.
reply