As someone who learned to program from two gigantic tomes of C/C+ with a Borland Compiler, there was no copy/paste. You had to type every listing in to get it running, as well as find that semi-colon you forgot on line 16,46,102 of 200. Then you had to remember everything, take notes, and literally research answers. You couldn’t just ask a random person on the internet, at least for a few years after I learned how to program when online forums became a thing.
One big difference I can think of between my younger peers and myself: When I see an error message, I take it as a “hint that something is wrong” where my younger peers tend to take error messages literally. Probably because I “grew up” with terrible error messages that hardly ever pointed to the actual file/line the error was on.
The C64 wasn't as good a BASIC environment. You can overwrite text in a program listing and press ENTER to update a line, which can copy a line if you can squeeze in a new number.
Neither were as good as Acorn's BASIC.
For a couple of years in secondary school, my alarm was a program I wrote every night on my CPC 464. My tape drive was broken, so I had to type every program in fresh. If I wanted to wake up in the morning, I'd write a nested loop over the hours and minutes and start playing sound.
It explains some basic concepts beautifully, far better than I can.
I think all the “kids these days” gripes only apply to people’s first few years. You can argue they’re formative, but most professional programmers will quickly need to evolve beyond “take message literally, ask online for help, paste error message into google/SO” to be good at their jobs. I don’t know anybody beyond entry level who operates like that.
I rarely take things literally like you said (though I may start by giving it the benefit of the doubt), I always just check the actual code from the thing emitting the error message, read the source of libraries I’m using, seek out documentation. It just so happens I can do all of that from my computer rather than doing some of it with a book.
I haven't worked with a lot of people like that, but enough to guess that there is quite a bit of people who work that way.
But it's true that after a point, the only errors left are the ones that can only be resolved by reading the documentation and experience (only 4 DELETE per hour, and you throw me an undocumented 503 error? Really?), and llm can't really do it for you.
Interesting, because to me there still seem to be many public discussion forum questions where the answer is "Have you tried doing exactly what the error message is telling you?"
One of my cousins learnt to program as a teenager in Argentina, before the web. He told me about the difficulty of finding programming information over there. Apparently, people who knew any kind of programming had paid dearly to get that knowledge and in turned charged others for that knowledge. Needless to say, there were not many programmers in the country at the time.
In comparison, today's generation has access to vast libraries of knowledge.
Not talking about AI; but if you want to work on compilers, linux kernel, game engine optimization, GPU optimized code and many many other things than web development you need to be more than familiar with how to work with machine instructions, albeit not working with it every single day. These are significant parts of the industry which make the rest possible.
The thing is that web development has seen such a boom which has seemingly dwarfed everything else in its wake.
I'm interested in being an instructor, but not sure I would have anything useful to add. If you've read my blog [1], do you think I would?
If you haven't read it, feel free to ignore this.
Edit: I was specifically thinking about a course on fuzzing.
There are still areas in software development where (not systemized) failure is not an option and where AI generated code absolutely can be useful, but would need careful validation from a human. Not only for unintentional errors, but also for potentially maliciously seeded errors in the model that is being used.
Perhaps manually writing test cases for the AI generated code could meet the requirements for human validation.
Unlike traditional polymaths, detailed knowledge / familiarity with APIs and libraries is less needed.
Years later, I don’t think her driving has meaningfully improved.
To be fair, it is a bit older, so perhaps modern transmissions are significantly better, but any rentals I've driven were even worse, though they were lower class cars.
One of my vehicles even has the tranny cooler and the radiator in one unit and is prone to cracking, leading to running radiator fluid through your gearbox, destroying it. The first thing I did was install an external cooler, as the market was big enough for an aftermarket kit for such a part.
Cars are getting so much worse.
Other than that, it’s far less about logic, and more about the feeling of control and mastery that it gives you. True, this feeling is largely more inefficient and more prone to failure than an automatic system, but that feeling, man; that feeling is just so great!
I also live in a wintery country, with many winding roads, hills and mountains with diverse weather and road conditions. The argument was made that it’s better to drive “stick” under these conditions. However, I’m not sure the argument that manual is better for diverse conditions will hold for long, given the current advent of better AI.
I’ve already seen AI drive in very hilly and adverse terrain in the Hollywood Hills, rife with bushes hanging over junctions and pedestrians popping in and out of parked cars, and so on. Naturally, not much ice up there, but that’s a pretty difficult landscape for an AI to master, and the AI already masters it pretty well!
I think this would depend on the environment. If you live in a dry, relatively flat area and you mostly drive there, you're probably right, marginal difference in road safety.
But if you live in a country that has long winters or lots of mountains, having control over the engine is a integral part of staying safe on the roads.
You take a theory exam (which you actually do have to study a bit for) on the rules of driving.
This gets you a learning permission, that allows you to drive but only with a fully licences driver in the car supervising.
You then have to take a minimum of 12 driving lessons with an approved instructor, recorded in a log book, before you can take the driving practical exam.
You then take the driving practical exam, which involves driving in the approved fashion around a public area. This has a surprisingly high failure rate - "wrong hand position" on wheel, not looking around enough, looking around too much, etc all will get you a fail.
Assuming you pass, you are then a "novice" driver (have to display "N" plates) for two years and pay an incredibly high insurance premium.
Despite all this "barriers to entry", most people here are terrible drivers lol
I like that.
The mental overhead of producing softwares shrinks more and more. It will sure be at the cost of understanding and/or see errors as you say.
I already looking forward of being that graybeard. And show off to my neighbors or grandchildren
Then "explain why <my code> needs to be <new code>"
Oh this is called <new concept>, give me an example of it. Give me another example. Give me another example. Give me use cases where this would be better. Give me a short story where it was done my way but it lead to a mishap in production and the protagonist learned <new concept>. Explain it like I'm 5. etc
Basically the new generation is the training neural network, and they can keep flashing context until they absorb the material. Sure, some people are lazy and will go as far as getting something barely working. But superpowers are available for those who fight for their place in the world
but this is assuming this current level of progress stagnates for at least the next five years. Sigh...
I don't think so:
LLMs have used Stackoverflow's answers for training. Now, if people would stop going there for questions, people would stop giving answers, so LLMs would have no data to train on for new problems.
have used, perfect tense. But future tense? who knows.
We shouldn't assume future LLMs won't be able to parse documentation of new libraries and extrapolate full, detailed implementations.
In that world the skill won't be to code, but to accurately describe software/business requirements. Unless a future AI can do that too.
It misses that we won't be doing Old Thing. We'll be doing New Thing.
It's not a step change in an old medium. It's a qualitatively different change to a completely new medium, whose properties haven't yet been revealed.
It's like waving an iPhone at Babbage. An iPhone is so far ahead of an Analytical Engine that it offers a completely new and unimaginable set of affordances.
It's also faster, smaller, and more reliable, with much more memory - which is an interesting implementation footnote, but incidental to the fact that from a user POV it's a completely different class of device.
Imagine if a country banned computers in 1979 to protect jobs, other countries would have run circles around them and it would have had huge economic implications.
Not iteratively forever, the only feedback it will (eventually) get is it's own feedback, because humans will be using the AI best practices, and what it deems as best practice is almost certainly going to be too opaque to us mere mortals.
It would be nice, but until there's a breakthrough on having LLMs / other models generate, maintain and walk the user through a representation of their reasoning, these explanations are likely no more reliable than a random StackOverflow answer - except without the benefit of other users scoring / picking holes in the answer
For anything significantly higher complexity, I don’t find that typing is anywhere near the rate-limiting factor. Figuring out how to decompose the problem, how the code should be structured overall, and other high-level concerns take far time/effort than banging out boilerplate.
Now, if I wanted to pretend to be a junior developer for three different companies at once, it would be a heaven-sent technological marvel.
the killer use case is augmenting my own workflow. i have fully integrated ai into my development pipeline. i am using chatgpt and i am using copilot. I almost never find myself turning to any other resource for information other than occasionally having to reference documentation for very obscure libraries. I also use an IDE.
this gives me time to concentrate on things such as my ci/cd pipeline, architecture, UX, testing, solving how to install bitsandbytes and triton on windows and other difficult problems related to build processes that don't have clear cut solutions.
My theory is that people working inside frameworks (like me) are getting significantly better answers than people doing "freehand" coding because the training data's so much better in framework-world.
And they’ll get code which isn’t good, just a parroting of bad ideas widely disseminated. A bit like Casey Muratori’s concept of fake optimisation: https://youtu.be/pgoetgxecw8?t=600
I think what we have now is more productive but results in worse programmers. I.e. you fix the thing in context, but learn little out of context and have to go back to the source of answers when the next thing comes up. The rate at which answers are sought increases, doesn't decrease. Etc.
I think using AI to build a React app from Figma is closer than building a low level piece of infrastructure. Hence, the grey beards operating at the lower levels are slightly less vulnerable.
We are going to be vringes softwarearechologists and programmers at arms.
Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post.
People jumped at ORM, CSS frameworks and JS wrappers, and won the day because they traded memory and CPU for what the user wanted.
The new generation will do the same. They will figure out how to be super productive with AI, way more than what we are. And our superpower will be useful in specialized cases, but mostly, their impacts will be small compared to the order of magnitude of speed they'll gain by using the new paradigm.
People said interpreted languages were a waste, that you had to learn SQL, that Electron was an abomination.
But the people building stuff always win, not what we think is the right way.
That's why PHP won at some point. JS won at some point.
And something super practical (but that will make us say uhh...) made by AI will win at some point.
That's also why all the open letters and ethics committees will have no impact: the short term advantage given to AI users will be such that they will take everything over by storm.
It's already happening in porn: we just gave millions of teenage boys a shiny new toy, and they are spending days and nights on it. New incredible models come out every day. Some hyper specialized. Last week, I saw a publication of a new model specially trained on only vagina called "bettervulva" and one for boobs called "breastinclass". Somebody spent hundreds of hours on those, collecting the data, annotating it, and training.
I guarantee each niche of the world is doing exactly the same. Not to mention each new model is coded with somebody who has the previous models to help with the new one, code included.
This is snowball from now on.
The double meaning at play here...
People who have decided to go all in in learning an interpreted language like Perl or even PHP, had to continuously also learn react, js, ruby,... and gazillions of other languages and frameworks to remain in business over the last two decades.
While people who invested in learning C, Java or SQL have as much healthy opportunities to pursue today with almost the same amount of knowledge that they had accumulated three decades ago. Their life has been much less stressful, pretty much on auto-pilot, while those who were pursuing the latest technology are constantly living on the edge having to continuously relearn entire new framework on average every 3-5 years to remain relevant.
So yes all these glitzy languages have "won" but it wasn't by these "ancient" languages losing.
If I had to bet I would say a decade from now, based on the last 50 years history of computing, I can easily imagine the same amount of jobs for C programmers as we have today but there will be as many Ruby jobs as we have perl jobs today.
With less fashionable language that require significant expertise and experience in picking them up like C (understanding the hardware level) and Java (understanding the JVM and OOP concepts) the barriers of entry are much higher and this will mean you have to outrun fewer people in the long run to survive.
I am pretty sure that you can programm java without knowing details about the JVM and I would think, that most java programmers do exactly this. I think only in high performance scenarios knowing more is beneficial?
But I have not touched java in a long time .. as I have indeed choosen the web as plattform.
But I don't feel threatened by the high school kids coming from boot camps.
It's entirely possible that between your skill level and those boot campers is a few(dozen) percents of workforce. But at the same time it's entirely possible that if you are not as quickly progressing as the growth of the industry, you could become a part of the same percentile as bootcampers in no time.
Focus on what you can control and let go of that which you cannot.
A lot of them are senior or principal product engineers at companies you will have heard of.
Whereas with C, its extremely necessary to get into the weeds - otherwise your code just crashes or suffers some memory corruption issue, race condition, etc etc.
yeah that was the whole point of object oriented programming and Java to begin with. You don't need to know the details of the underlying implementation, focus on the problem you're trying to solve.
That's absolutely heartbreaking.
In the old days, we would have a team, that would compete, as a team, against other corporations. Our team would stick together, work together, and, quite often, function as a unit; leveraging each others' strengths, and compensating for each others' weaknesses.
Nowadays, we look at our team members as "the competition." In fact, we may actually be making plans to move to the other team.
But I have written programs in C, that were still in use, 25 years later. I have written programs in PHP, that were still (are still) in use, 15 years later.
There'll always be room for the classics.
That said, I'm quite looking forward to seeing what I can do with the new AI stuff.
And I am sorry. Things definitely used to be better than they are now, in some ways, and definitely used to be worse, in other ways (for example, it used to be a very white, very male demographic). It's not my fault that things went the way they did. Folks liked money, so folks built a culture that maximized profit, and eschewed humanity.
I am quite sorry about that, but it doesn't change the fact that it was not always so.
It's not in my personal interest to go about creating a slideshow on "how things used to be." I know what I know. I lived it. I ran teams, exactly like I described, and I was a proud member of very large, high-functioning teams that stuck together for decades without stabbing each other in the back.
Let's just agree to disagree, then, eh?
I don't disbelieve you, but I'm saying your experience can't be generalized in that way. Only aggregate data can tell us these things. Your experience may well have followed the exact trajectory you've described, but maybe 90% of people see the opposite.
Everyone is at best a temporary ally, friends and community groups are just atrophying daily as we continue to not invest in people and community and invest in more alienation.
Team is still very much a thing and if your team members are looking at each other as competition then that sounds like a culture thing, maybe the norm, still not acceptable.
This mindset will damage you over the long run, and the resulting career success may or may not be able to offset it. A zero sum mindset will lock you into this view along with the accompanying anxiety.
Problem with this approach is you run out of friends quick. People in bear country cary bear spray, have dogs to scare off bears and electric fences to keep them out.
We have tools and culture to not have to deal with/rely on survival of the fittest if we don't let fear control us - whether at work or in nature.
Most of them are maintaining existing codebases (not a fun job), and some are "help port this legacy codebase to not perl".
I'd not discount Perl. Its incredibly fast to develop services in, stable as fuck, runs anywhere, performant (relatively), flexible, and if you were a startup looking to get a product out the door, just offer decent TC to a couple of old hands you can ship something viable fast.
I get to see a lot of peoples code in my job. Most of it is ridiculous levels of over engineering
Indeed being able to auto-pilot your job allows you an amazing amount of time and freedom to learn new things deeply. See also the detrimental effects of "publish or perish" mindset in academia.
If you became more and more of a specialist in Perl on the other hand you would have had to completely relearn something new by now to find as many opportunities as you used to in the late 90s.
I'm saying this based on the fact the job market was amazing for software developers in the last decade or more. Things now might be different.
I have not stopped messing with Stable Diffusion and llms for like 7 months now and I've been a software engineer for 20 years. I use copilot and chatgpt and my own brain and have released two compiled python apps on itch ( first real apps I've ever built and released from the ground up on my own) - both are ai tools, one for stable diffusion one for flan-t5. I'll be releasing a unity solitaire game soon as well, and ive been training my own models.
This is the most fun I've had creating things since I started programming.
Definitely getting that vibe over here. I've been revisiting the exploration-style programming I was doing when I was young - Mandelbrot sets, Truchet tiles, all the old Computer Recreations columns stuff. Things you code up just to see what they look like.
Being able to say "Turn this pseudocode into a Processing sketch" is a joyous thing.
I've gone from hating PHP for most of my career, to now having a grudging appreciation for it. Its a clusterfuck, but it works really well, and deployment barely gets simpler than "untar into webroot, done".
I also forgot briefly what a complete fucking nightmare instrumenting/debugging PHP (on say, a LAMP stack) can be - which is the inevitable result when PHP decides to behave in "interesting" ways.
It’s a bit like calling e-scooters an abomination. It’s just an opinion, and one that certainly isn’t stopping money from being made.
Making something easier doesn't necessarily increase quality. It's early days. It's a fool's errand tp try to predict the future. Now more than ever.
Those programmers didn't need to know the subtleties of memory management because when they programmed in Ruby they didn't have to debug in C. GPT is very different.
The article says they “get the right answer 80% of the time”. That’s abysmal when you don’t know what you’re doing. Software which is 20% bugs is software you can’t rely on. Depending on what it does, it can be actively harmful.
Being a “magician (…) among mere mortals” is not a positive. We live in an interconnected society where the actions of others affect us. It would be nice if you can trust what other people are doing when they’re dealing with your water supply, electricity, food production, hospitals…
If you have years of expertise already they give you wings.
No one is saying to take the output and immediately ship it. It still needs to be finished and tested. What's important is what is ultimately delivered; less important is what steps brought you to that point.
That said I suspect good testing will become more highly-valued as AI use increases. Maybe there's a form of TDD that can develop, with the human mostly writing tests and AI prompts?
On the contrary, that is exactly what is happening: https://news.ycombinator.com/item?id=35384604
People are still actively acquiring the knowledge to do things the old fashioned way in those areas, a hundred or even thousands (for writing) of years later. But typically they only do it if they need to or find it interesting.
It’s hard for me to think of any technological advance (outside entertainment) that actually caused a mean regression in peoples’ effectiveness, or for people as a whole to completely stop acquiring the skills of doing something the old way to deleterious effects. Like, has there been any invention that was so easy to use that people got worse at the task the tool was invented for? In aggregate it may happen if the tool greatly reduces barriers (like training, experience, or study) to entry, but I kind of doubt it happens for specialists.
Note by effectiveness I mean the general task, not the specific skill that may have become obsolete. I’m not effective at all with a slide rule but I have a Python shell, the internet, and hardware capable of floating point operations.
This time its different... The written word might be able to write back. As a matter of fact, I already use chatgpt to learn new skills. Its a better way of acquiring knowledge. The job of teachers will change within 5 years.
Moving pictures in the newspaper? We have iPhones and tablets and tiny screens with interactive video...
Talking to people through the fireplace? We have video calls on our phones.
Writing words into a diary and having it write back to you? Well now we've got that too.
Now I'm just waiting for the flying broomsticks. Maybe we can do something with magnets inside an electrified metal Quidditch arena...
People pay for productivity, making a product of some sort that has value. These AI tools will increase productivity. And they will only get better with time. That translates into the productivity of people who have mastered these tools as more valuable. They just get more done.
Will syntax issues and other problems be an issue with early AI? Sure, but it will get better. The AI will start to catch more issues and move farther up the stack. We still need to know enough to guide it, but the details required will be fewer.
If every single person with that coding experience only coded, that's likely, but not every person who got their start that way focused on coding to the exclusion of everything else. There are at least a couple of us who are more oriented towards teaching, archiving, and knowledge preservation. Right now, people like us but don't tend to prioritize giving us their resources. Once those greybeards are in their 60s/70s/80s and looking at their work being lost forever, I imagine that will change. (Much in the same way that there's way more discussion now in tech spaces about raising kids now that more programmers are old enough to confront that issue).
That knowledge will likely be preserved by another greybeard cohort and it'll be specialized knowledge that only some people know, but it will be known. Some stuff will be lost because we'll prioritize money and copyright up until there's a crisis, but there are people prepping for this time period. It's not like trade knowledge loss is a new problem. It's just not a sexy one right now.
We will be the ones with the preattentive syntax parsing in our brains that let us simply see basic syntax errors; we will be the ones who can point out simple but subtle errors immediately—because we’ve made them 10000 times; we will be the ones who can take a ChatGPT response and immediately identify how it’s lacking not just in outcome but in edge case handling. We came of age before stack overflow, and have matured to the point where we treat stack overflow answers as mere suggestions for a possible approach, not as code to be copied and adapted.
And then, when we are no more, there will be no one left who can wrangle the turtles that reach the bottommost depths of the full stack.