Typing the code isn’t hard.
Figuring out what code to type is.
Coding is problem solving, and solving problems can be very hard depending on the problem you’re trying to solve.
Yeah, there was a running joke in our comp. sci. program that “we thought we’d make great comp. sci. majors because we had the typing skills (and desire).” The major says as much, you gotta understand the problem to work out a solution… and a solution may not be the solution — since we’re human so… get learning.
Cooking is easy. That’s not an insult to a chef.
The same phrase would be “cooking was never the hard part of running a restaurant”
But yes. It’s one thing to code. It’s a very different one to code well.
How do we thrive?
Accept that change happens. Be equal parts curious and critical about the new stuff.
That is not the solution. One cannot thrive if one cannot be seen or has been discarded as a relic no matter how up to date that person is. They will never be granted the opportunity to thrive as they have before as an employee. Their only hope to thrive is if they (magically) gain all the skills and networks necessary to be an entrepreneur that can do it all themselves. Nearly a unicorn.
Meantime while trying, they burn through what savings they have on the hope and dream of “being relevant again” and have about a 5% chance of success.
Maybe the author is misunderstanding the gist of the original article. Regardless, he raises an obviously accurate assessment of those who hold the hiring power. When I was recently out of college learning my craft, it was a common sarcastic refrain of either, “What could be so hard about it, it’s all 1’s and 0’s” or “What’s taking so long - you’re just typing on a keyboard”.
This has been a problem since long before I graduated from college (when classifieds called for 10 years experience on an IBM system that was released two years ago) (see, things don’t change so much - names and places, sure, but not much else). People who are in leadership positions, who think they’re better and smarter than most everybody else, frequently belittle those who do the grunt work, both physical and mental. It’s gotta be a corollary to dunning-kruger theory (or maybe an example of it).
I read “Code was never the hard part” as “Writing the Code down is easier than the stuff you do before it (like Architecture, Design Patterns, Requirements) and after it (Testing, Troubleshooting, Refactoring, etc)”.
Yeah, I feel like the author of this blog post read the referenced piece in a quite adversarial manner. Even if a programmer does no talking to stakeholders at all, the planning and design part of the process is still huge, and largely invisible if all you’re looking at is the end result. That invisible skill and labour is the difference between a mediocre personal project of mine, and the output of a seasoned professional.
Writing code was never more than 20% of what I do as a programmer. All those other things are where I have always spent me time, and those are the hard part.
And to me the least fun. Programming is the fun part, everything else is stuff I have to deal with to do the fun part.
All of it has parts I hate there is a lot of boring code I’ve had to work on. And sometimes the fun code is things I finish and say nobody should every do that…
Then look at it again in a year and go, “Who wrote this?!” Do a git blame then go, “Oh, why did I do this?”
For me the part before it is the only easy one lol. For the rest, I don’t even know how to program anything more than a basic Hello World in Python.
How could you possibly do things like architectude and design patterns without being able to code…?
I’m not sure why, maybe is because I live perpetually overstressed and I’m dyscalculic, but I can’t just understand anything about the part of actually writing code. Like, I can conceptually and theoretically know really much about programming, programming languages and how they work (and how they would work better), but when it comes to start learning the syntax and what every symbol, word and all that means and how do they combine… Oopsie.
In few words, I do understand the theory, all the concepts and the programming semantics, but the code grammar is hard for me, and the syntax is nearly impossible as it involves too much maths.
As architecture and design are more about natural language and logical reasoning, and I’m actually good in those two things (I have hyperlogia [if “hypercalculia” is the polar opposite of dyscalculia, then this is the same for dyslogia]), or at least can be totally done without any maths and totally with only these two things (because yeah, symbolic logic is also hard for me), I can do these things to a pretty good extent.
Hope this allows you to better undertand. 😄
Code is integral. Everything they add to it, and build around it, is to support the code. Code is the God in the machine.
Code is the God in the machine.
Then God has no soul.
Yes, code defines what happens, how it happens. But what defines what the code is intended to do? Where is the intelligent design? You can wire up a bunch of relays with intelligent design, simple electrical work, define gates, build the gates into memory registers and arithmetic processing stages, make a CPU - but… are you any closer to achieving the goal for having done all that work?
Are you better off for having a hands-on deep understanding of the machine from electrical first principles, or does the warehouse full of circuits and wires and the power it consumes outweigh that benefit?
If you use a modern processor do you need to have hands-on the assembly code? Do you need to deconstruct and understand every stage of the compilers and linkers and optimizers? In the 1990s I did, because those stages weren’t reliable enough, yet.
There’s nothing different about “deterministic code” built on layers and layers of tools today than there was about assembly code built on the processors before than there was about assemblies of modular circuits that form processors and memories and peripherals… it’s all parts of the system. And for critics of the “unpredictability” of LLM code generation, you might want to look into the mysteries of “garbage collected” languages.
If I eventually stop writing C or Rust or Go or Python or Javascript or any of the other hundreds of common choices of languages out there and instead learn to feed a LLM with instructions that generates the Rust that generates the Assembly that drives the CPU that manipulates the electron flows - that doesn’t change the intelligent design of: making a thing do what it is intended to do.
My oven is a bunch of components. I might be able to do a 5 dollar soldering fix but now need to buy a 100 dollar component to replace the one that’s not working. I guess I agree that soldering a wire or replacing a component requires the same amount of intelligence, but it’s not he same “system”.
deleted by creator
“Code was never the hard part” is probably made up by someone who never had to program anything serious.
“Writting the code was never the hard part”
It’s figuring out in detail what the program is suppose to do (i.e. Requirements), how it can and should do it given the technical constraints of the available deployment environment and performance & reliability requirements (i.e. Technical Analysis) and how it all gets structured from the highest level to the lowest level so that bugs are minimized, performance is suitable with the appropriate margin to absorb expect unexpected problems and costs for maintenance and future requirements implementation are low (i.e. from Technical Architecture and Systems Design down to Software Design) that are hard.
And I say this as somebody who has done all of those professionally, plus the coding (oh, so, so much coding) for systems of all kinds and sizes in various countries and industries, including some mission critical high performance distributed systems (which if they failed would have cost millions of $$$ in lost business income).
Fly by the seat of their pants coders who have never worked in a properly professional environment have no fucking clue just how much more there is to it than “coding” to go from no software at all to “reliable and robust software system that serves existing business needs”.
A lot of “coders” are like I was in the beginning of my career: they think they’re the shit, know nothing but a very limited range of work environments which they think “that’s how things are done” when those environments are actually, amateur hour, every hour of every day, every day of the month, every month of the year - they’re basically at the peak point of the Dunning-Krugger curve for software development knowledge.
For me, that is all integrated part of “programming”. You missed the documenting the code part, but i consider this as an oversight.
It says a lot that you think a coding good practice like “documenting things in code” which is at the level of using descriptive variable and function names, should be in the same bucket as structural non-coding processes (which are often entire professionions or very senior professional branches) like Requirements Analysis or Technical Architecture, both highly-complex things (the latter being the very top in seniority of the technical career track) which are non-existent in a formal sense in improvisational (read: amateur as fuck) “programming” companies.
You’re making my point on the whole Dunning-Krugger thing.
The interesting thing, to me, is how much/little architectural level design matters depending on the complexity of the system you have built, and the longevity of its maintenance in the field.
I watch things get built with bad architectural compromises for what appear to be bad reasons all the time, and they rarely “come home to roost” until years later… then the question becomes: was the implemented design a success for having gotten to market quicker and lasted so long without serious problems, or a failure for having created a mess 5 years down the road that could have been addressed with a 5 day delay of launch for a refactoring? Or, should we instead spend 5 weeks attempting to predict the optimal architecture before we even start and maybe get a good solution or maybe still end up learning things we didn’t know during early development - and when we learn those things down the line from the initial architecture specification, when it it time to slaughter the sacred cow and re-arrange things?
Oh, they “come home to roost” almost immediately - you just don’t see it because whole teams are doing everything they can to hide it or ignore it - nightly manual data update statements, etc… Here’s just one real example.
In my last (read: final) job as a senior software engineer, I discovered dozens of serious problems with the system I was assigned to “maintain”. They ignored all of them - wouldn’t let me fix anything. Meanwhile I was responsible to solve production problems on the daily (duplicate data, insert failures, performance slow-downs, etc).
It wasn’t long before the fact those problems weren’t going away that they became problems I “caused”. Meanwhile, all the fixes I wanted to make were ignored. I had one problem I dissected and and gave my boss a brief write-up of the scenario. He told me I needed to do deeper analysis. When I came back a few hours later with a considerably more detailed explanation, he didn’t read it and complained of a “wall of text”, which he literally told me to write. Then he created a random-number hack to “fix” the problem.
They did not grasp the concept of data normalization and primary keys as they had one particular table that represented two levels of detail (for example, account -> order). They put both in one table and had a code based special update to the “account” number so they would not get a PK violation rather than just fix the data structure.
They had as single database connection open all the time to handle all inserts in a singleton service, then launched as second one on the same database to process messages faster - and couldn’t understand why it didn’t double performance.
The main routine had a cyclomatic complexity of 360! I shit you not! And everybody agreed it was “95% working” even as we continued manually fixing (the same) problems daily.
Week after week, the customer (internal) would raise more data issues as “new” problems. I’d routinely ask two to three questions about the data set and explain that’s the same problem that’s been going on for six months, and if we could just get my PR reviewed, we can test it and deploy it.
All these problems were in a single service.
I was let go not long after the 1 month probation they soon initiated and told I was not performing at the level of a senior developer.
This is how delusional these people are. They refuse to acknowledge their flaws even after hiring someone specifically to solve them. They blithely call their monstrosities “successful” while committing many staff to late nights and weekends “managing” it.
Not only in code. Documentation for the end user (or at least halfway there, the final document is done by a separate department), is important, too.
There is a reason that my job description is “Embedded Systems Architect”. But I see this ccomplete packet as “programming”.
Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than “working with a team” of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we’re all sick of the process and late for delivery of the documentation products.
When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told “do it again in Go” and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.
You missed the documenting the code
Your words.
As for your job title, don’t take this badly but “Systems Architect” is not at all the same as “Technical Architect”.
If you’re actually designing or at least tuning software development processes and coding standards across multiple teams (so, not just optimizing how teams work but also optimizing cross-team work), you’re a Technical Architect.
A Systems Architect, when the title is properly used, just means that you’re designing software whose operation spreads across multiple platforms (so, for example, multiple tiers in a multi-tier system).
Also there is quite a range in Systems Architect - knowing how to code in two or more platforms (say, STM32 and some Android, to make a bit of home electronics with a microcontroller be controllable from a smartphone) is not at all the same as knowing how to design a high-performance distributed system running in multiple machines, integrated with multiple external system working for ten/hundred of thousands of client front-ends and supporting things like Distribute Transactions so that any failures don’t leave half-complete operations.
You can be a Systems Architect and be isolated form most of the concerns of the software development out there. especially if you’re a team of one developing the software side of products based on some marketing person’s idea of what customers supposedly want.
Unsurprisingly, Technical Architects are non-existent outside large companies and even there they’re pretty rare.
Again, still making my point on Dunning-Krugger.
Define “serious”.
An OS, a compiler, any complete application. Or at least significant parts of it. And I mean programming from A to Z: defining, detailing, implementing, verifying, documenting.
any complete application
An OS, a compiler
Quite the hefty examples lmfao, holy hell. Guess all of us “regular” software engineers in the business are just plebs huh.
I’ve wrote my first pre-emptive multitasking OS as a teenager. I also wrote my first compiler back then. I’ve worked on everything from industrial controllers to a Cray YMP. And I’ve forgotten more programming languages than most hacker kids can list. I consider myself as a seasoned programmer.
Don’t take this badly, mate, but you sound like me when I was a “kid” thinking I was truly the shit for all my technical achievements as a self-taught programmer.
Absolutely, really impressive 1 in a really-big-number kind stuff, just the most pure technical track imaginable and not the same as understanding software development the process as whole, at all.
Decades later, 3 countries later, several industries later, various different environments and kinds of projects later and all sizes of company later, I’ve figured out that they pay us the big bucks to make software for OTHER PEOPLE, to serve THEIR needs not ours needs and certainly not for our personal enjoyment, though a good dev will always find some enjoyment in cracking complex problems, IMHO - from were a fuckton of constrains and dependencies on what and how you make it and whom do you have to work with are born - and if you want to achieve something that’s great in more axes of greatness than just pure technical impressiveness you need to actually learn how to effectively work in a team and with other teams even non-technical ones, including, beyond a certain point of experience, how to empower other more junior people in your team rather than just be pissed off at how little they know.
(And I don’t mean going into the Management track, I mean staying the Technical career track and still progressing as a Software Engineer).
And don’t get me started on the engineering-style concerns of software design around software live cycle in production and how to prepare for expected future directions of change.
Mind you I’ve crossed paths over the years once or twice with people who never moved beyond “technical excellence” as their one and only metric for software development (typically “rockstar coders”) and they were invariably miserable people who bitch and moaned about “lusers” and how other developers don’t know how to use the (not really properly designed for robust usage by people that can’t read your fucking mind) libraries they made.
Unless you find yourself a nice niche where you can be a solo rockstar hacker, technical excellence is only a good software development metric up to maybe the 5 years experience mark. Beyond that, unless your career has stagnated you’re supposed to be delivering the results the customers need to the customers and doing so in complex environments in cooperation with various teams, some of whom don’t at all understand most technical language and certain don’t have a fucking clue what “pre-emptive multitasking” means.
Love this reply. One hundred percent agree. Well said.
Right, you’re a little more than a seasoned programmer, buddy. You are extraordinary.
You can’t expect “an operating system” or “a compiler” to be the bar for “doing anything ‘serious’” 😂
I consider myself as a seasoned programmer.
Is that hot pepper, salty, or both?
This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?
I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.
First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.
The things that take up more time in software development just for engineers, leaving aside things that design and pms do.
- Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
- Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
- Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
- Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.
There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.
Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.
I’m a mediocre hobby programmer, and for me, the hardest part is coming up with the concrete specifics of what to implement.
I’m actually half decent now (for a hobbyist), but I remember that when I first moved from coding along with worked exercises in textbooks, to actually trying to solve real life problems, it got exponentially more difficult. The textbooks say “use this tool to achieve this goal”, and even if you’re bad at using that particular tool, you can put all your effort into doing it well. However when you’re having to make the bigger decisions for yourself, you have to choose what tool to use, and I found that super hard — especially when having to choose between an approach that I felt confident with that wasn’t quite the right tool for the job, and a new tool that was completely new to me (and if I am unfamiliar with a new approach, am I sure that it’s the right tool?).
At one point, when I was deep in a personal project, I had a period of a few weeks where I had no reliable access to internet, and so I did most of my coding using paper and pen. It forced me to think more deeply about the implementation I was using, rather than just diving straight into the code
For me it was trying to interpret vague business requirements. But I was a designer / coder. I tried to insulate the other programmers from that nonsense.
You nailed it.
It’s literally þe IRL perverse incentives case where a company payed bonuses per LOC and found devs were just spewing unneccessary verbosity which made products slower and harder to maintain.
Whoever you are, don’t outsource your understanding, judgement, empathy and taste to AI. Don’t abdicate your responsibility. Don’t be a meat proxy.
By expanding the ability to program to people without the knowledge of how that code works in the first place, it’s naive to expect that most uses of AI in programming will be informed uses by senior developers able to recognize errors and security flaws.
Such a pro-AI position also ignores the enormous amount of theft that these tools are built on.
the ability to program
people without the knowledge of how that code works
Ain’t that the biggest oxymoron you’ve seen today.
They are not given the ability to program, per se, in my opinion. They are doing something else.
Maybe I’m misunderstanding your comment though. Not sure if you’re referring to the code output when you said “that code”, or some other code. Please let me know if I got it wrong.
Such a pro-AI position also ignores the enormous amount of theft that these tools are built on.
Or, less likely, it could be that person knows and just doesn’t care. I certainly don’t because I believe intellectual property is bullshit.
It’s one thing for individuals (particularly those without the means of paying) to pirate content that its original creators have already been compensated for and now exists to milk money for an IP holder for a century; it’s another matter entirely when AI companies with multi-billion dollar valuations scour the internet for content to include in their models to then profit from without permission from or compensation to the millions of people whose work they depend on.
The problem in there is corporations. AI is just the means of the dickery, not the cause.
I would also go further and say the root cause is capitalism, and that someone being able to eat or be housed should not be based on whether or not their art has met the criteria for corporate purchase. But I digress.
Yeah that’s the thing: I don’t believe it’s wrong to profit from people’s content without their permission, because I don’t believe they own that content after they share it with humanity and I absolutely don’t believe they should get to enforce that “ownership” via state violence. Everyone should get to use anything they want in derivative works, whether for profit or not. The fact that this could plausibly affect people’s livelihoods (but IMO wouldn’t; if there were significant profits in IP “theft” corporations would already be doing it) is a failure of capitalism and frankly not the reproducer’s business.
As an artist that see his work opportunities reduced by the IP theft, stfu, and maybe evenn go kys.
The entire AI industry is built on IP theft; even if you don’t believe in IP ownership, companies like OpenAI and Anthropic rely on their ability to scrape the internet for content, with only largest of publishers having the resources to sue for anything in return.
So long as copyright is being enforced at the individual level for consumers, large corporations shouldn’t be allowed to get away with infringing on it for profit.
So long as copyright is being enforced at the individual level for consumers, large corporations shouldn’t be allowed to get away with infringing on it for profit.
Sure, but my conclusion from that isn’t “IP law should be enforced on the big corporations too;” it’s “IP law should be abolished and also down with capitalism.” Why should I want an unjust law to be enforced even more vigorously?
One of the big reasons IP law exists as it was to encourage people to not hide innovations and keep them secret to themselves. If anything you (not you specifically as a person) spend time and resources to create can be trivially taken away from you if people know about it, you then either have to keep it secret or you simply have no incentive to make anything new. Now if your argument is that current IP law has been totally perverted and abused to extreme levels and should be completely redone, you’ll get no argument from me. Just killing IP laws entirely would pretty much break our current society. Maybe out of that chaos would come something better, but make no mistake, shit would be fucked in the meantime.
I’m baffled I just downvoted a comment saying “intellectual property is bullshit”. There’s a first time for everything I guess. And yes it is bullshit but gosh, what a weird place to take that stance.
I mean, a key element of the anti-AI movement is that AI “steals” art, but I fundamentally believe in that art (and ideas) can’t be owned and therefore can’t be stolen. Ditto for code or what have you.
They CAN be owned. Particularly art.
And I say this even when I’m anti-copyright and pro-copyleft, but even then I don’t want to lose my means of work and subsistence and my moral rights.
Also, much of that gets even worse when AI gets trained with works that you didn’t even published yet, but that a hidden background AI process scraped in the platform you used to backup, plan or talk about that works. I’m talking out of experience.
AI training is data theft not IP theft
It can be both…
Yeah, it can be both, like, if you want to argue that in our current capitalist society people need to be compensated fairly for their work, I’ll hear that argument, but I don’t think it’s the best or most accurate framing. I think it’s just as obnoxious reddit made a deal with google to train on my (and everyone else’s) comments throughout the website as I do the possibility it was trained on my artwork, and I’m not alone in that.
The data theft is another story, but there’s clearly an IP theft angle to anti-AI arguments, as seen in the other person response.
His other comment applies just as easily to to stolen medical images, like this woman’s , as it does more creative works. It feels violating either way. Virtually no one is worried about Mickey Mouse appearing in data sets, but lots of people do feel wronged when their emails are trained on without permission or compensation, even though they’re not really IPs.
I appreciate the intent behind that sentence, and the problem is that is written (or said) by people who don’t understand coding.
Syntax was never the hard part. Code syntax is a set of rules that you can teach a machine and it’s “easy” enough for an LLM to grasp it. The problem here is that this phrase does a “code = syntax” but ignoring all the difficult things that actually are in the code. Architecture, design, tradeoffs, translation of vague requirements into concrete software components…
All of those things are terribly hard, and the reason why many LLM-first coding projects get abandoned at 70% and then companies need to hire a Software Development consultancy to mop up their mess.
Interestingly what I’ve said here ☝️ ️comes with an interesting implication. There used to be a type of software “engineer” that couldn’t actually think through a problem and implement a good software solution. They were valuable because they could refactor, write code, but not think through a problem. These are the people who have the most to lose at the moment, and also the ones that find the least value on AI, because AI only does really well the single thing they could do.
That style of software developer used to be called “monkey coders”.
Employing “monkey coders” because they are cheaper is a great way to end up paying a lot more money over the long run because their work is unmaintainable, ureliable, not robust and stupidly hard to be upgraded to implement new requirements.
Which, if you think about it, it’s pretty much what you get with AI code.
And yeah, totally agree that these are the people who are most threatenned directly by AI at the moment. Then again, they were the ones most threatenned by outsourcing already (to India especially, since when they grew massive as an outsourcing place for software development they started hiring tons of people there who had no skill whatsoever for it and would never have gone into software development and were pretty bad, so most coders based in India were eventually this kind of code writter).
Hiring “monkey coders” was always the product of bad management: they looked good on paper - cheap, made lots of code, bums on seats, often the kind of person who worked long hours (which in low efficient management cultures makes a manager look good because of “making their people work hard”) - whilst creating massive costs spread over time and hitting everything from production downtime costs to future system improvement costs. In some ways the mass replacement of developers with AI is born from the same management incompetence as outsourcing, which is probably why it is hitting the US so hard.
Which brings us around to how, indirectly, even good software developers are right now threatened by AI - the kind of incompetent manager who thinks code lines is a productivity metric aren’t replacing just “monkey coders” with AI, they’re cutting down head-count with no selectivity or even replacing first the more professional coders because they’re the most expensive.
This might not be sustainable in the mid and long term because AI, like “code monkeys”, just piles up massive less obvious over-time costs on software systems (I expect a lot of companies will go under from this shit) and some are already getting desperate for the kind of professionals that can fix their self-inflicted AI problem, but people who aren’t prepared for up to two years of being out of well paying software development jobs (so, most people) are getting screwed instead of aligning themselves to really profit from the wave of post-AI “oh, shit or systems are unreliable shit” work for senior types that’s just starting, plus if indeed as I expect companies will fail due to this, the Tech boom will be over and there will be fewer positions than there were 2 or 3 years ago.
That try, the hard part is algorithmic and avoiding archictuctural traps and experience. Pissing code which didn’t work or look like it work but don’t is easy.
Remember that story about the chalk mark engineer with Ford? Chalk mark 1$, knowing where to mark 1000$ ? Same with code. “Code” is easy. Knowing what to write, why and where, that’s the hard part. LLMs have somehow managed to automate the code part, without the abstraction, at least in an error proof way. I don’t think “coding isn’t that hard” is insulting, and I don’t use C++ because I think it’s hard. But it’s not because writing something is hard, it’s because writing precisely what is needed is hard.
Anyway, this debate doesn’t matter, negotiate better, be active politically to ban stuff or not, complaining on the internet won’t do anyone any good. I know you’re emotionally invested in this, just… breathe and do something else? Idk. Also I’m not your enemy on this, so no need to attack me.
Funny; I always heard þis fable as a plumber and a hammer-tap.
deleted by creator
I won’t miss writing code. In part because I still do when I feel like it, but also because most of the time it is extremely boring. A mere mean to a goal for which you probably have the path mapped out in your brain already. It is basically just busywork at that point.
There are these moments where you need to squeeze out performance, where you change something about the UI or generally visuals and get a pleasing result, or where you discover a small tweak that collapses a lot of complexity you originally planned for - but that is, in my humble experience, not the norm in programming. The vast majority of code is boilerplate or stuff you have already written a thousand times in some variation. The more experience you have the worse it gets.
I was ecstatic when I realized how good agents have gotten, realized how I could focus on design and architecture and with small corrections, get more than adequate software. Because for me personally, programming is the least fun part of software development. Most of the time that is. And you can hate it all you want, but programming is a skill worth nothing on its own now, and it will never be again. You can take solice in the fact that you can still do it for fun if you want to.
idk, code was always written only once, but it will always be read many times. Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong. When you have 100k+ line codebase with multiple contributors with LLM it can very quickly turn into a black box, which nobody understand anything deep down anymore and everybody are more and more incentivized to use LLMs to interact with the thing to get anything real done. Then it’s couple hallucinations away from turning into a fragile mess, where things break unexpected and nobody knows why.
code was always written only once
What universe do you live in? My whole life has been modifying code. I may spend 20% of my time on “greenfield” writing of new code, but the rest is modifying other people’s code, modifying my own code, explaining to people how my and other peoples’ code works so they might modify it.
Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong.
In my industry we spend a significant amount of effort to ensure that “something goes wrong” before we ship, rather than after. Of course, we’re only human, bugs do ship, but they’re relatively rare - and field fixes get 10x the scrutiny of the already heavily scrutinized greenfield code.
For the past 6 months or so, I have come to respect LLMs’ ability to find more bugs earlier in the process - doesn’t matter if the code is written by people or LLMs, bugs happen. LLMs don’t find them all, but people find even fewer.
The other thing LLMs are starting to excel at is verifying that the documentation says what the code does, and the code does what the documentation says. Docs out of sync with code has been the bane of my past 3 decades, and before that I just didn’t write a lot of docs.
Programming on its own was never what got you paid.
It’s just like the oldest profession, you’re paid to scratch an itch - make someone happy. They rarely care about exactly how or why you’re doing it, just that you do it.
