Are people still under the impression that testing candidates with coding challenges is in preparation of a job where real world problems are described like "invert the binary tree"?
There was never any value in simply the ability to invert a binary tree from memory. First, contrary to popular belief, this particular challenge is quite trivial, even easier imo than fizzbuzz. The value of testing candidates with easy problems is their usefulness in quickly filtering out potentially problematic coders, not necessarily to identify strong ones.
Second, another common take on coding challenges is that they're about memorization. Somewhat, but only to a point. Data structures and algorithms are a vocabulary. A big part of the challenge of using them "creatively" in real life is your ability to recognize that a particular subset of that vocabulary best matches a particular situation. In many novel contexts an LLM might be able to help you with implementation once the right algorithm has been identified, but only after you yourself have made that insightful connection.
Having said this I generally agree with the philosophy [0] that keeping things simple is enough 95+% of the time.
Do some people really believe that SaaS margins are dropping because the public at large has discovered that to save 20$/month on some app they can instead vibe code their own and use that instead?
My current guess about the future is that the age of SaaS is coming stronger than ever. I expect many vibe coders to come up with half-assed prototypes that will be copiously replicated and improved by more qualified devs aided by LLMs. In a similar way, I also expect smaller qualified teams (3 to 5) to leverage LLMs to become more relevant competitors of medium to large SaaS players. By 2029, we'll have more, but smaller SaaS companies.
Margins wouldn't drop because every consumer is going to vibe code their own apps. It's going to bring down the barrier for competition creating natural price pressure in the market. That is of course if all other factors end up equal such as quality, security, performance, etc...
This of course will be software in general imho. It's not that the profession will disappear overnight. There is going to be this tight squeeze until all the margin/excess salaries/etc.. is gone. There is also going to be immense pressure to produce as much as possible and productivity expectations are going to go way up (even if it is unjustified).
Basically, the good days are over. It's going to be a miserable profession.
SaaS companies have a big dilemma. Agents make your SaaS app more useful if there's no lock in and data is easy to access, but if that is the case, you have no lock in and the app is easy to migrate away from.
If you've already figured out what features are actually needed and which workflows work best, somebody can use AI to replicate those. This is the part of programming that AI is best at and accelerates most. The hard part, coming up with ideas, is far harder to copyright.
I could be wrong, but my understanding is that when people talk about the Death of SaaS, they are not talking about $20/month consumer apps. They are talking about six-figure+ enterprise deals that are the source of so much profit for SaaS companies.
> it's failing to keep up on the skills that keep you employed.
I judge "failing to keep up" by my ability to "catch up". Right now if I search for paying courses on AI-assisted coding, I get a royal bunch for anything between 3$ to about 25$. These are distilled and converging observations by people who have had more time playing around with these toys than me. Most are less than 10 hours (usually 3 to 5). I also find countless free ones on YouTube popping up every week that can catch me up to a decent bouquet of current practices in an hour or two. They all also more or less need to be updated to relevancy after a few months (e.g. I've recently deleted my numerous bookmarks on MCP).
Don't get me wrong, LLM-assisted coding is disruptive, but when practice becomes obsolete after a few months it's not really what's keeping you employed. If after you've spent much time and effort to live near that edge, the gap that truly separates you from me in any meaningful way can be covered in a few hours to catch up, you're not really leaving me behind.
"It will grow more complex" is never a good reason to get into things early. It's just your mind playing FOMO tricks on you.
Many developers who picked up the web in the early years struggle with (front-end) web development today. It doesn't matter if they fetched jQuery or MooTools from some CDN as it was done in the mid 00s. Once the tooling became too complicated and ever changing they couldn't keep up as front-end dilettante. It required to commit as professionals.
If you started today, you'd simply learn the hard way, as it's always been done: get a few books or register for a course. Carve some time every day for theory and practice. All the while prioritizing what matters the most to get stuff done quickly right now, with little fluff. You will not learn Grunt, Bower, and a large array of historic tech. You'll go straight for what's relevant today. That applies to abstractions, frameworks, and tooling, but also to the fundamentals. You'll probably learn ES6+ and TS, not JS WAT. A lot of the early stuff seems like an utter waste of time in retrospect.
This is true for all tech. If you knew nothing about LLMs by the end of this year, you could find a course that teaches you all the latest relevant tricks in 5 to 10 hours for 10 bucks.
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.
> Once the tooling became too complicated and ever changing they couldn't keep up as front-end dilettante. It required to commit as professionals.
The best professionals did not fall for insanity of the modern front-end dilettante and continued hacking shit without that insanitity.
> You will not learn Grunt, Bower, and a large array of historic tech. You'll go straight for what's relevant today.
which will be outdated "tomorrow" just like grunt/bower... are looked at today
> A lot of the early stuff seems like an utter waste of time in retrospect.
This cannot be further from the truth, if you learned Javascript early, like really learned it, that mastery gets you far today. The best front-end devs I know are basically Javascript developers, everything else is "tech du jour" that comes and goes and the less of it you invest in the better off you'll be in the long-run.
> If you knew nothing about LLMs by the end of this year, you could find a course that teaches you all the latest relevant tricks in 5 to 10 hours for 10 bucks.
Hard disagree with this unless you are doing simple CRUD-like stuff
> The best professionals did not fall for insanity of the modern front-end dilettante and continued hacking shit without that insanitity.
"Front-end professional" and "no tooling" have been exclusive propositions since the early 2010s. You either learned to use tools or you were out of the loop.
> which will be outdated "tomorrow" just like grunt/bower... are looked at today
Not really. Historically, the main problem with front-end development has not been change, but the pace of it. That's how it ties in with the current discussion regarding the (now) ever-changing terrain of LLM-assisted coding. Front-end development is still changing today, but it's coalescing and congealing more than it's revolving. The chasms between transitions are narrowing. If you observe how long Webpack lasted and familiarity with it carried over to using Vite, it's somewhat safe to expect that the latter will last even longer and that its replacement will be a near copy. Someone putting time to learn front-end skills today might reap the benefits of that investment longer.
> if you learned Javascript early, like really learned it, that mastery gets you far today.
I did. I got a copy of the Rhino book 4th ed. and read it cover to cover. I would not advise to learn JS today with historical references. JS was not designed like most other languages. It was hastily put together to get things done and it had a lot of "interesting", but ultimately undesirable, artifacts. It only slowly turned into a more sensible standard after-the-fact. Yes, there are some parts that are still in its core identity, but a lot in the implementation has changed. Efforts like "Javascript: The Good Parts", further standardization, and TS helped to slowly turn it into what we know today. You don't need to travel back in time for that mastery. Get a modern copy of the Rhino book and you'll be as good as the best of them.
Yeah, I still get use out of XMLHttpRequest to this day good thing I got in early and variable hoisting isn't gonna get me! /s
A lot of snark aside there's a bit of a false dichotomy (I think) here at work. Whenever or wherever your jumping in point is into $something it will always pay dividends to learn the fundamentals of that $something well and unless you interact with older iterations on that $something then you'll never have to bother learning the equivalent of Grunt, Gulp, Stylus, Nunjuncks and so on for that $something.
With that being said it's also good to put aside time once a year to check out a good recommended (and usually paid) course from an established professional aimed at busy professionals.
As for LLMs I feel it's slowly becoming a thing big enough where people will have to consider where to focus their energy starting with 2027. Kinda like some people branched from web development into backend, frontend and UI/UX a good while back. Do you want to get good at using Claude Code or do you want to integrate gen AI features at work for coworkers to use or customers/users? It's still early days just like when NodeJS started gaining a lot of traction and people were making fun of leftpad.
The software identified the person as Angela Lipps. According to the court documents, the Fargo detective working the case then looked at Lipps' social media accounts and Tennessee driver's license photo.
In his charging document, the detective wrote that Lipps appeared to be the suspect based on facial features, body type and hairstyle and color.
The software worked exactly as intended. It's a filtering tool that sifts through data for common patterns to provide leads, not matches. It raises a flag on persons of interest. You can be a "match" anywhere between 0 and 100% and only relative to some specific input (like that picture taken from the top of the woman at the teller). In that sens mismatches are within acceptable parameters and have been known to happen.
A "match" is a pronouncement ultimately made by the humans that uses the tool, after they've checked out the leads. Someone slept at the wheel here.
This LLM ability is directly proportional to the quantity of encoded (i.e. documented) knowledge about software development. But not all of the practice has thus been clearly communicated. Much of mastery resides in tacit knowledge, the silent intuitive part of a craft that influences the decision making process in ways that sometimes go counter to (possibly incomplete or misguided) written rules, and which is by definition very difficult to put into language, and thus difficult for a language model to access or mimic.
Of course, it could also be argued that some day we may decide that it's no longer necessary at all for code to be written for a human mind to understand. It's the optimistic scenario where you simply explain the misbehavior of the software and trust the AI to automatically fix everything, without breaking new stuff in the process. For some reason, I'm not that optimistic.
You don’t have to convince me of that, I’m feeling quite secure in my job for the minute. I’m just aware that we may look at the actual code less and less as confidence in it grows or outpaces confidence you’d have in a an equivalent human reviewer. There’ll always be jobs in handling the riff raff of the machines at some level of abstraction.
The phrase does not make more sense even if we go all the way back to Beers. I certainly don't feel alone in not understanding how he went from his (fair) observation that "[There's] no point in claiming that the purpose of a system is to do what it constantly fails to do" to his more controversial conclusion: "The purpose of a system is what it does (aka POSIWID)".
Surely, there were many more sensible (but perhaps less quippy) stops between the two.
Being quippy is the point. That's how aphorisms work: creating a short, pithy distillation of a complex argument, that you can then use pars pro toto to make a point.
I certainly agree that POSWID is easily (and perhaps frequently) misused. But that doesn't invalidate it in general.
> Are the AIs stumbling into these mental models? Seems like it.
Since nature decided to deprive me of telepathic abilities, when I want to externalize my thoughts to share with others, I'm bound to this joke of a substitute we call language. I must either produce sounds that encode my meaning, or gesture, or write symbols, or basically find some way to convey my inner world by using bodily senses as peripherals. Those who receive my output must do the work in reverse to extract my meaning, the understanding in my message. Language is what we call a medium that carries our meaning to one another's psyche.
LLMs, as their name alludes, are trained on language, the medium, and they're LARGE. They're not trained on the meaning, like a child would be, for instance. Saying that by their sole analysis of the structure and patterns in the medium they're somehow capable of stumbling upon the encoded meaning is like saying that it's possible to become an engineer, by simply mindlessly memorizing many perfectly relevant scripted lines whose meaning you haven't the foggiest.
Yes, on the surface the illusion may be complete, but can the medium somehow become interchangeable with the meaning it carries? Nothing indicates this. Everything an LLM does still very much falls within the parameters of "analyze humongous quantity of texts for patterns with massive amount of resources, then based on all that precious training, when I feed you some text, output something as if you know what you're talking about".
I think the seeming crossover we perceive is just us becoming neglectful in our reflection of the scale and significance of the required resources to get them to fool us.
There was never any value in simply the ability to invert a binary tree from memory. First, contrary to popular belief, this particular challenge is quite trivial, even easier imo than fizzbuzz. The value of testing candidates with easy problems is their usefulness in quickly filtering out potentially problematic coders, not necessarily to identify strong ones.
Second, another common take on coding challenges is that they're about memorization. Somewhat, but only to a point. Data structures and algorithms are a vocabulary. A big part of the challenge of using them "creatively" in real life is your ability to recognize that a particular subset of that vocabulary best matches a particular situation. In many novel contexts an LLM might be able to help you with implementation once the right algorithm has been identified, but only after you yourself have made that insightful connection.
Having said this I generally agree with the philosophy [0] that keeping things simple is enough 95+% of the time.
[0] https://news.ycombinator.com/item?id=47423647
reply