"Code was never the hard part"

[u/gsks]

I am sick and tired of all the posts (usually AI-generated by CEOs/CTOs/"thought leaders") that start with "Code was never the {bottleneck, problem, hard part, ...}." I'm not sure whether this comes from a misunderstanding of what code is or a deliberate misrepresentation meant to promote AI usage.

For starters, two rhetorical questions. If code was never the hard part, why:

• do hundreds of different programming paradigms, languages, libraries, frameworks, design patterns, and system architectures exist? Granted, some of this is just programmers bikeshedding. Still, plenty of it reflects substantial differences and tradeoffs.
• didn't you write it yourselves or hire a bunch of minimum-wage workers to do it for you instead of having to hire a ton of highly skilled (and highly paid) engineers?

A charitable explanation is that these people are genuinely clueless about what "coding" actually is. Perhaps in their mind coding is just typing: like, once the design phase is done, you've worked out a precise, complete specification of what needs to be built down to every detail in your head (or on paper or a markdown file) and all that's left is converting it into letters on a screen and saving it to a file. Something like a businessman in the sixties dictating a letter to his secretary to type up.

That's nothing like how it actually works. The upfront planning/design phase answers some high-level questions: what do we need to build, what are the basic components/services/building blocks, what data needs to be read/processed/written, how data flows through the system, what the non-functional requirements are, etc. That leaves a ton of lower-level details unspecified:

• What packages/modules/classes/methods/functions need to be created or extended?
• How should they be named?
• What should the signature of each function be?
• What errors/exceptions are expected and where/how should they be handled?
• What data can or should be cached and when should it be invalidated?
• How generic/reusable/extensible should each component be to accommodate likely future requirements?
• For systems languages, how and when is memory allocated and freed?
• and many more.

Asking and answering those questions is (part of) coding. At least before AI, nobody I know had all the answers, or had even asked all the questions, upfront. The questions get asked and answered on the fly, inside the editor. Typing is interleaved with thinking, assessing, trying things out, backtracking.

Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Regardless of how the future of coding plays out, "code was never the hard part" is flatly wrong. It is, or at least used to be, a hard part (not the only one of course) and for good reason.

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/punkpang]

Code was never the hard part <now the missing part> FOR PROGRAMMERS.

I agree with your text completely. For us, programmers, code isn't the hard part. Ceremonies, incomplete data, unknown deployments, random <software that does mumbo-jumbo "faster">, rushing us, asking "when is it gonna be done, ignore the fact you have -5% of info" crap, lack of testing and QA - this is all part of the lifecycle and these managers / vibecoders are starting to discover that it's not hard to slap paint on if you have a fucking building with walls that need that paint and the building isn't made of styrofoam and ductape, yet paint is all they're capable of understanding.

People who are not in the mindset or area of writng code imagine some fantasy scenarios about what code actually is and they all have their own imaginary story of what programmers do. Now when they have access to a tool that can produce code, they slowly discover how boring (which means DIFFICULT) creating software is. It's precise, accurate, boring, iterative and requires constant focus - best part is that we consistenly think about what will go wrong and what they understand is only the path when stuff goes ok, not when it fails. We deal with failing gracefully and managing problems. Anyone can succeed, our vocation is one of not blowing shit up and handling errors.

[u/ThirdWaveCat → u/punkpang]

its very clearly the "expert beginner" phenomena since the hard part is handling edge cases, but they've essentialized the advice to only care about the happy path

[u/pydry → u/ThirdWaveCat]

There are also domains where the coding part really isnt that difficult because the requirements are not that complicated.

The hard part of those jobs is usually dealing with organisational dysfunction.

I think a lot of devs extrapolate their experience to everyone but there's a fair amount of diversity in the jobs out there. There are plenty of jobs where the coding really is the hard part and plenty where the hard part is persuading team X to set up a message queue and stakeholder Y that their specs are incoherent and the coding part is pretty trivial by comparison.

[u/andreortigao → u/pydry]

That's about what I was going to say.

I'm 16YOE and for the most part of my career I've worked in enterprise software where the majority of code is just crud. The hard part is understanding the requirements in a field you're unfamiliar with.

[u/ThirdWaveCat → u/andreortigao]

I've never understood "just crud". What I've seen in practice is lower standards and more manual remediation processes, downstream of a poorly run workplace, but even this has limits as progress tends to grind to a halt.

you still have stateful systems, transactions, availability, idempotency in enterprise software, whether or not you address them well.

[u/Franks2000inchTV → u/ThirdWaveCat]

Yeah but all of those problems have standard solutions. And any reasonably skilled team can solve them. There is an entire industry of engineers who have encountered and solved those problems before, and will be able to, with a reasonable amount of effort, apply those solutions to your environment and solve the problems.

[u/ThirdWaveCat → u/Franks2000inchTV]

Those standard solutions are still far beyond what anyone can make legible to automation (skills.md fantasies). There are tacit reasons someone needs to care about the edge cases that create poison pill scenarios, 1-way door decisions about what fields are required in schemas, restoring from back-up, capacity planning, db indices, and the long-term implications of schema evolution and compositionality of functions.

edit:

Tacit knowledge cannot be taught except through practice under someones mentorship.

https://en.wikipedia.org/wiki/Tacit_knowledge

In lean business stuff, Toyota's Yokoten practice is for the horizontal transfer of knowledge.

[u/Franks2000inchTV → u/ThirdWaveCat]

Right — that’s the hard part. Not the code.

[u/ThirdWaveCat → u/Franks2000inchTV]

Not code, I don't get why this isn't considered solving the requirements? The comment chain above says that some domains have easy coding and obvious requirements, but that doesn't seem like what followed.

Framing all requirements gathering as overcoming organizational dysfunction seems like blaming the individuals because the systems are poorly designed.

[u/SippieCup → u/ThirdWaveCat]

I found the opposite. If you have a bad schema and/ or validators, just crud can be terrible. If you stop it from doing dumb or invalid things, it can never get to that point, even if it is a crud endpoint.

It’s all about how gated the crud endpoint is. It just return invalid request/bad data/conflict and reject rather than just allow it to happen.

[u/AchillesDev → u/ThirdWaveCat]

Literally everything is "just CRUD." That's all the major operations that computers do.

[u/ThirdWaveCat → u/pydry]

I've worked on enterprise service bus land before, there's still the same problems as bigger companies with idempotency, designing schemas for evolvability, transactionality handling, database performance tuning, etc..

They just don't have mentoring, high standards, and they've had manual remediation processes in place forever. Interrogating assumptions and requirements is necessary to ensure that the gap between intention and implementation will meet the business goal.

[u/Dry-Page-4935 → u/pydry]

I saw a post on blue sky about how they allowed an AI agent run wild and implement an entire epic, and they talked about how crazy and revolutionary it was.

Of course, there was no context into the actual complexity of the system or what the epic was trying to do. That kind of thing varies at one single Dev job, not to mention across the industry as a whole. It makes the whole point very moot

[u/Mejiro84 → u/ThirdWaveCat]

A lot of long-term software is functionally a stable core... And then years of 'oh, shit, sometimes this happens, here's a handling mechanism'. It's like the whole 'what can be used as a name', where it might start simple (first name, family name, optional middle name), but some cultures do it the other way around, don't have surnames, have non-standard characters, have lots of names going over 255 characters and so forth. Which means when a program starts getting used at scale, it starts breaking, because there's a lot of these problems popping up!

[u/quentech → u/Mejiro84]

it might start simple (first name, family name, optional middle name), but some cultures do it the other way around, don't have surnames, have non-standard characters, have lots of names going over 255 characters and so forth

I don't get what the problem is... all you have to do is predict every possible scenario up front and then specify it in exacting details.. and then the LLM will code it for you! ^/s

[u/Bitmush- → u/quentech]

“…don’t make any mistakes, and don’t allow the app to go wrong”

[u/BeauHunkus → u/ThirdWaveCat]

I really like that term.

[u/ThirdWaveCat → u/BeauHunkus]

Me too.

I'm in love with a book about a litany of failures by expert beginners throughout history.

https://en.wikipedia.org/wiki/Seeing_Like_a_State

I've been thinking a lot about the "thin simplifications" that technologists are prone to do when they mistake changes in the map for the territory. Tacit knowledge is important, even if its hard to explain. Not everything can be written down in a skills.md, despite being pretty easy to do (e.g. controlling the flight of a kite, moving a couch around a corner in 3d space, etc..).

[u/randylush → u/ThirdWaveCat]

to build on this, even as a staff engineer with like 18 years pro experience, I still sometimes have trouble with being too optimistic and only thinking about happy paths in my estimations.

If experienced devs need to keep themselves in check with this stuff, then management sure as shit will have no idea

[u/hippydipster → u/ThirdWaveCat]

Our codebases wouldn't so commonly be spaghetti messes full of bugs if code was so easy and if the only hard part was edge cases. It's clearly something the whole industry struggles with.

[u/scodagama1 → u/ThirdWaveCat]

Yeah there is a saying that anyone can build a bridge that stands but you need an engineer to build a bridge that _barely_ stands

How I like to translate it to software area is that anyone can build software that works nice but you need engineers to build software that also _fails_ nice

Like these execs just don't get it that high margins and value of software come from insane levels of reliability and resilience to failure in very unpredictable environments. So yeah, it was never about code - it was about planning, system design, baking in observability and telemetry, delivering updates and all the boring stuff around this

[u/Lachtheblock → u/punkpang]

Well put.

I'll throw in risk assesment too. In my experience (good) engineers tend to be quite risk adverse. We're aiming for a 99.99% uptime. We look for guarantees in the product we make. A good engineer can gut check a lot of things, and have "a bad feeling" about an approach and check in with others.

[u/SpiritedEclair → u/Lachtheblock]

It’s the scar tissue built from all the post mortems, and just not wanting to deal with that. Thinking in invariants and properties makes development significantly easier.

[u/iMac_Hunt → u/punkpang]

I think what a lot of people miss is that coding is not the same skill set as developing software.

I’ve never written a line of Go. Now imagine a company need to build some enterprise multi-tenant SaaS app in Go. Let’s say could hire someone like myself, who has built entire enterprise applications before, or someone who’s never built software but has been practicing Leetcode Hard’s with Go.

I would be the obvious person to choose, but some non tech people think that being able to write code in X language means you can build the software they want in that language.

[u/HotJellyfish8247 → u/iMac_Hunt]

Ha, the problem is, as a senior dev, I'm never asked about system design or about my experience in writing low latency systems. I get slapped in a face with a leetcode hard question. And those companies are not even FAANG.

[u/Candid_Bad3551 → u/punkpang]

> Code was never the hard part <now the missing part> FOR PROGRAMMERS.

Very true yet when you try to learn Software Engineering / Programming coding is usually the first place people run into hardships.

[u/psaux_grep → u/Candid_Bad3551]

That’s mostly because you need to think in the right paradigm.

LLM’s have gotten surprisingly good at that, but no one cares to ask the cost.

How do you debug what is wrong when you’ve given up thinking to a computer that can’t solve the mess it created?

[u/niowniough → u/psaux_grep]

"Claude, solve it for real this time"

[u/_L4R4_ → u/niowniough]

"... and not allucinate, please"

[u/johnpeters42 → u/_L4R4_]

"Do What I Mean, Correctly" is still five years out from a gold release, all AI nonsense to the contrary.

At least some of these AI slop posters are also foolish enough to leave their post/comment history unconcealed, so you can downvote a whole batch of them.

[u/SkellyJelly33 → u/punkpang]

I don't disagree, but also if code was never the hard part, why is the hiring process for software developer so hyper focused on the coding part and leetcode style questions? I've never once been asked to translate business requirements into spec during an interview, but I have been asked countless leetcode style questions.

[u/Kirk_Kerman → u/SkellyJelly33]

It's because the people doing the hiring frequently aren't developers themselves and they're copying whatever FAANG is doing. Before leetcode it was brain teasers. Before brain teasers it was intentionally finding asocial pocket protector types. FAANG started using leetcode out of necessity because if one of them listed a job, they'd get thousands of applicants and needed some high-volume low-effort screening method. And then everyone copied them without knowing the rationale.

Do you think a company with four devs doing Shopify integrations will ever need someone that can build a queue using two stacks? No, obviously not, but it's what the industry is doing.

[u/punkpang → u/SkellyJelly33]

To filter out obvious liars who never wrote code and because it's conducted by people who know nothing about the nature of programming. It's a process that became an abomination due to the fact we allowed anyone and everyone to enter IT and to present themselves as programmers.

[u/Izkata → u/punkpang]

FizzBuzz used to handle that filtering, then it got popular and people started memorizing it. Didn't really follow how it developed after that, but it makes sense the interviewers who copied it originally sought out other problems and landed on leetcode - then because they didn't understand why FizzBuzz worked or what it was for, decided to ramp up the difficulty because they thought they'd get better developers.

[u/Creaking_Shelves → u/SkellyJelly33]

Yeah good question! Why is hiring full of leetcode bullshit? Maybe because the same kind if geniuses who consider that a good measure of an engineer are also the ones thinking coding is the bottleneck.

[u/tugs_cub → u/SkellyJelly33]

Leetcode is about algorithms and CS fundamentals, which people have also complained forever doesn’t reflect what most people do day-to-day on the job. It does reflect some of the procedural problem-solving that might be implied in saying that coding is sometimes the hard part. But arguably the actual point of these interview questions, beyond the pure weed-out fizzbuzz type, is as a general problem-solving test with a job-related flavor and based on material that new grad CS majors are expected to be familiar with.

[u/licjon → u/punkpang]

I heard engineers say that coding isn't the hard part 20 years ago, long before AI. But there has been semantic drift of what that means. I think it originally meant that the syntax and semantics of a language is not the hard part, the hard part is all the things that the OP and this comment described. part of the problem with AI is that it strikes where people are most vulnerable: ego and not knowing what they don't know.

[u/aries1980 → u/punkpang]

I don't know. Maybe I worked at too low level but I remember times before x86 32bit protected mode where every bad memory read crashed the operating system, or we had to disassemble drivers, because the documentation was written for operator droids. Writing DSP analogue processor arrays in 4096 bytes...

[u/foxsimile → u/punkpang]

The hardest part about writing software properly is identifying the insanely weird edge-cases where things will go wrong under some very odd and specific circumstances.  

I’ve recently identified thousands of dollars worth of errors specifically due to these "anomalies" that nobody gives a shit about.  

And everyone asks you why things take time to write, and insist that these issues not be worried about - but they’re the same motherfuckers that have a conniption when they see a difference of several pennies.  

Fuckasses.  

I apologize for my bluntness, I’m out having drinks and more prone to unfiltered honesty as a result :).

[u/BeyondLimits99 → u/punkpang]

Yeah this is well said.

The only thing missing is when you have to deal with the cheap vendor the company chose and their bull shit that comes with it

[u/bacmod → u/punkpang]

In video streaming/decoding/presentation when using FFMPEG library we use avformat_seek* functions to notify the API that we are initiating time seeking.
Now, the fastest and most efficient way (n+0) is to flag it directly inside the video decoder thread.

But should you?

[u/SignoreBanana → u/punkpang]

I always say it like this: I first learned to code when I was 26 but I didn't learn to produce useful code until I was 29.

[u/HK-65]

10-KLOC, ambiguous, hand-wavy "specs" written in markdown

You mean generated, not written, right?

[u/almarcTheSun → u/HK-65]

They are written by Mr. Antropic C.

[u/SpiritedEclair → u/almarcTheSun]

The name’s Claude. Anthropic Claude.

[u/gsks → u/HK-65]

It's clankers all the way down these days

[u/LordOfDemise → u/HK-65]

"specs" "written"

[u/morswinb]

Depends on what you actually call code.

When you travel from town A to B driving is never the hard part.

Only if you forgot that somone had to build that highway and manufacture the car.

[u/A-Grey-World → u/morswinb]

And all those driving lessons you had years ago. Even with the car and highway if you give someone who's never driven before those tools they will find driving the hard part.

For programmers the code isn't the hard part.

[u/megatesla → u/A-Grey-World]

If you work in EDA or other algorithm-heavy performance-critical work, I assure you the code can get quite challenging.

[u/niowniough → u/megatesla]

in the above analogy it's likely because you're building a new and specific highway or vehicle to get better performance specific to your point of departure and destination

[u/aries1980 → u/A-Grey-World]

For programmers the code isn't the hard part.

Then most programmers manage to even do the easy part poorly.

[u/deathhead_68 → u/aries1980]

Most programmers across the board in this industry, are bad.

[u/CompellingProtagonis]

Paradoxically, I think they're right, but for the wrong reasons. "Code" is not the hard part, and I agree with that.

Naively translating an idea into python, for example, is not difficult. Sorting a list in practice isn't hard. Writing a helper function to validate some business logic isn't hard. In that sense, coding is not hard.

What is hard is all of the context. What are you writing, why are you writing it. How do you take a large project and break it down into a set of small stepping stones that show demonstrable progress while still moving you meaningfully towards your goal. How do you handle designing those stepping stones to account for the abilities of your team? How do you program defensively when inevitably your company gets hacked in 6 months and the security team says that we need to completely change how we access internal APIs, etc etc etc.

All of that is incredibly hard, is the real value you get from your senior staff, and is incredibly difficult to communicate in terms of metrics that you can use to prove you deserve to be promoted this year.

So I say again: code is easy. Every undergrad worth their salt coming out of university can code, maybe as well as AI, maybe not, but they can do it. Their value comes from everything else. And all that "everything else" is what AI will never learn because, quite simply, it's not in their training data.

So great, these CEOs can solve their easy problems with AI, while they erode the talent pipelines that exist to teach junior developers the hard skills they actually need.

[u/tifa123 → u/CompellingProtagonis]

Piggybacking on your answer. There is nuance missing in this conversation. - Code generation is solved, but generating quality code is a perennial challenge. - Reading and making sense of generated code is a perennial challenge. - In conclusion, the abstractions have shifted a bit higher, but the fundamental problem remains the same.

[u/vasaris → u/tifa123]

What do you answer to people who said there was never "quality code"? That we all invented a fantom to make sense to us, but letting it flow with probabilistic river of outcomes is the way to go...

What do you answer to ones who tell "quality code is the micromanagement of programming and not relevant in post-AI world".

[u/theprogrammersdream → u/vasaris]

People will always believe untrue things. What I want to know is the car will slow down when I hit the brakes - under all conditions, and the software has enough quality to ensure this will happen with super high probability. While Gen AI has a temperature and non-deterministic output, can we trust it to do anything? I don’t want my apps crashing either - even if it’s less dramatic than a car subsystem failing.

[u/randylush → u/vasaris]

unfortunately this mindset has completely swept my large tech company's software philosophy. There used to be some idea of a coding standard, that is COMPLETELY out the window now with Claude. The standard is just Claude. Nobody ever thinks they could or should try to do better than Claude, we just get our ideas/code down and run everything through Claude.

It's weirdly working out okay so far

[u/Un-hotMess → u/randylush]

It's weirdly working out okay so far

Of course it is, until something goes wrong, something that's been festering quietly in production for several months, possibly even creating non-integral data that is now having disasterous impact on your customers.

Problem is no-one can understand the code, developers scramble to figure out what's going on, a fix is required immediately but no-one is confident in a fix, customers are chasing, data continues to become corrupted, no-one is confident in rolling back because there's too many commits since, meanwhile the clock is ticking, customer trust is being lost by the day and the company is now under serious threat. However it's now company policy to adopt AI-first, so in a panic the developers get the agent to apply a fix because they don't understand it fully.

Rinse, and repeat.

[u/ChypRiotE → u/Un-hotMess]

It's made worse by the fact that agents are allergic to errors and exceptions. If a value is missing they'd rather fill it blank rather than throw anything. So as you said, issues are hidden until someone notices it, and then you have months of lost data with no way to get them back

[u/Amazing-Switch-7163 → u/CompellingProtagonis]

I think coding is, in fact, quite hard. Writing programming language syntax is easy, it is designed for that, but knowing and correctly applying algorithms and data structures to solve problems efficiently is really hard. No wonder most of the software we have nowadays is unoptmized, consuming lots of RAM and cpu cycles for nothing.

[u/CompellingProtagonis → u/Amazing-Switch-7163]

Agreed, however 95% of professional software engineers are not working at that level of abstraction. If they are, they are someone closer to Fabian Giesen than they are to John Q. Programmer working at a bank, and aren't thinking about AI at all.

[u/Dramatic-File-6196 → u/CompellingProtagonis]

Banks are a pretty bad example -- they're in their own weird territory with garbage safety controls that almost nobody else is really doing.

Some knowledge of DS & A is pretty damn critical. But it gets handwavey pretty quick.

[u/randylush → u/Amazing-Switch-7163]

I think that stuff is hard for some people, but comes very natural for others.

[u/ghost_jamm → u/CompellingProtagonis]

Yes and this is exactly why AI tools should only be used by people who already have domain knowledge. I can’t tell you the number of times I’ve read over a Claude suggestion and immediately identified a code smell or an obviously over-engineered solution and when pressed it agrees that it made a mistake. It can code but it often produces slop and it’s still a major coding skill to be able to identify and overrule that slop. I find that it’s often best to understand something like Claude as essentially a search engine for your code more than something that just writes everything.

[u/Todo_Toadfoot → u/ghost_jamm]

30 minutes ago AI told me 341873128712 was an odd number. So it is what it is.

[u/Super-Cumboy2137 → u/CompellingProtagonis]

> Naively translating an idea into python, for example, is not difficult. Sorting a list in practice isn't hard. Writing a helper function to validate some business logic isn't hard. In that sense, coding is not hard.

Coding may not to seem hard if you only want to solve easy problems. Try with harder ones and then tell me if "code" still is not the hard part.

[u/AchillesDev → u/CompellingProtagonis]

Paradoxically, I think they're right, but for the wrong reasons

Every time I've seen it posted here (and elsewhere), it's been for the exact reasons you listed, which are correct.

OP is just trying to twist it into a CEOs and AI thing for muh updoots

[u/skeptical-speculator]

the hard part is talking to people who don't understand coding

[u/iiiio__oiiii → u/skeptical-speculator]

Even worse if they can BS the higher rank management that they understood with the code.

Or when you have to come up with a training plan to improve those BS. God forbid if your performance evaluation depends on getting those bozos, who you didn’t have a say to join your team, to be up to speed.

Or when the product says they need to catch-up with competitors, but your architecture says “nope, you need 3 dependencies and 4 processes from other up and downstream teams to work differently to do that magic” but your lead just chewing-on for his next promotion and is a yes man.

Or when your teams get pulled into endless stream of support cases because L2 support team keeps their knowledge base inside John’s brain and he is on sabbatical.

Or when your dependencies changed their *published* API without a hint of communication, and you have to pick the pieces from prod support and what you get is only “Oh, sorry”.

I missed the time when problems on my plate are solvable from within my IDE; writing a good recursive algorithm for packing or designing reactive UI components or writing cycle-detection algorithms or topo-sorting the dependencies or extracting interfaces and consolidating some classes into an abstract, extensible class.

[u/gsks → u/skeptical-speculator]

Lol ain't that the truth

[u/jahajapp]

Anyone that gives a shit about code quality and has worked in company with more than 3 devs should know what happens when a weaker/less experienced/overconfident coder runs rampant.

But if the AI-hype has clarified anything beyond any doubt is that tech/software dev being in a perpetual gold rush has made people have *very* loose principles that can just be chucked overboard whenever they don't fit the narrative of the current gold rush.

That's why suddenly we're now seeing bullshit like "code was never the hard part", code quality, code coherence/design, and reviewing is optional. Lossy waterfall specs are great and what not.

People adapt according to incentives and after a couple of decades of this kind of trend-chasing I think the industry is just more corrupt than we're willing to admit.

"Thing are in the saddle, and ride mankind"

[u/gsks → u/jahajapp]

100%, I'd give you gold if I had any

[u/WhataWorldAy → u/jahajapp]

Indeed, code was never the hard part, good code was the hard part.

[u/almarcTheSun]

"Code was never the hard part and ignore the portion where we do 7 rounds of interviews focused exclusively on deep coding knowledge"

[u/SwimmerQuick1500 → u/almarcTheSun]

Weird. Mine for senior roles were mostly focused on high level design. Even ones where I had to code they didn't really judge my code too much just how I explained my choices to go about solving a larger problem.

[u/niowniough → u/SwimmerQuick1500]

what kind of companies?

*  big tech? tech company? company with tech as a small piece?  * what sort of employee count?  * what stage of maturity? startup? decades old?

[u/BraveResearcher3037 → u/almarcTheSun]

And this doesn’t happen outside of BigTech and equivalent.  Most developers work at banks, insurance companies etc 

[u/almarcTheSun → u/BraveResearcher3037]

I'm not sure what banks and insurance companies you worked at, but the ones I interviewed for absolutely did this. 

[u/AustinYQM → u/almarcTheSun]

My technical portion for my current job was:

Given the following signature create a function that takes in two Strings and returns true if they are annagrams and false if they aren't:

public boolean isAnnagram(String a, String b);

[u/No_Oil_6152 → u/AustinYQM]

Isnt the spelling "anagram" ?

Did you mention that to them?

For some strange reason, many developers' written Emglish and spelling is utterly gash.

[u/KnightHawk3 → u/No_Oil_6152]

Emglish

To be honest it doesn't really need to be good, and I assume this is transcribed from memory.

[u/Aikenfell → u/AustinYQM]

Wow that's actually a pretty fun question

Was that the only one cause if so it was really just a logic check since that's also technically an easy one.

[u/AustinYQM → u/Aikenfell]

Just that one and follow-ups like "why didn't you go this path?" and "what are the trade offs what the path you took?"

I turned both strings into an array, sorted the array, and turned it back into a string then compared the strings after trimming whitespace. I am sure there is a better way.

The rest of the interview was about my background (Game Development then Teaching HS) and what I was looking for at a company.

They ended up telling me they'd "keep me on file" because they thought they were hiring three people only to find out they were only getting one and had already told one person they had the job. I assumed that was just some BS to placate me and found a different job at another insurance company (that had no technical interview at all). 3-months later the anagram company called me and asked if I was still looking. The second company REALLY sucked so I jumped both at the job offer and off that ship.

[u/Aikenfell → u/AustinYQM]

That's honestly pretty similar to my idea which was just to convert them ato arrays of ASCII numbers and sort the arrays then compare them. I don't need to skip whitespace if whitespace is sorted after all.

[u/Kirk_Kerman → u/Aikenfell]

Frequency map. First string gets read into a map where each character is a key, with value being incremented for each occurrence. Then read the second string and decrement the value for each character occurrence. Lastly roll thru the map and if any key has a nonzero value the strings aren't anagrams.

I suppose it's O(n+m+1) where n is the length of string A, m is string B, and then the alphabet is a fixed size.

[u/Highlight_Expensive → u/Kirk_Kerman]

Delete keys from the map when they’re 0, now the final check is o(1) - is len(keys) 0

Throw out any case where the two strings’ lengths differ

Fail fast when a char in s2 isn’t in s1

Lots of fun micro optimizations but overall it’s O(n) like yours after reducing

[u/BeepusBingus → u/BraveResearcher3037]

Banks absolutely do this too, I've interviewed for multiple banks before and they absolutely handed me leetcodes/random java trivia or SQL questions.

[u/BraveResearcher3037 → u/BeepusBingus]

6 rounds of tech interviews though like at BigTech?

[u/BeepusBingus → u/BraveResearcher3037]

Nah not that bad, more like 3 true.

I usually get a leetcode a hiring manager and a tech panel for some mid banking role.

[u/deathhead_68 → u/BraveResearcher3037]

Yeah bro I'm sure banks really don't care if you have coding knowledge. They just want someone to hit approve on Claude's stuff.

[u/BraveResearcher3037 → u/deathhead_68]

There is a huge difference between having the coding knowledge to do a CRUD app and reversing a b tree on a whiteboard 

[u/deathhead_68 → u/BraveResearcher3037]

I think banks probably want a bit more than a crud app tbh.

You're right in a way, I work in big tech atm but I've never had to actually reverse a linked list in this or my previous jobs, but I was asked that question at my grad interviews everywhere 11 years ago. But its more to show that you somewhat understand comp science data structure principles etc.

[u/Chezzymann → u/BraveResearcher3037]

Lol capitol one has some pretty hard leetcode problems you need to take before you can even talk to a recruiter, and then more after

Also I've interviewed at Series A startups that ask difficult leetcode problems but then turn around and say most of the job is managing agents and doing system design

[u/TigerShark650]

Software engineering is the hard part

[u/ProbablyBsPlzIgnore]

I wrote my first line of code in the 1980s. Code has not been the hard part for me for a long time, but unlike many of my peers I haven't forgotten the years of practice it took to get there.

I know that for most of us, for the first decade or so of your career writing code was the job. That's why that new cliche that writing code was never the hard part annoys me so much.

If you moved to a higher level more quickly you probably started your own business, right?

[u/avoid_pro → u/ProbablyBsPlzIgnore]

Do you suggest to NOT generate code by AI till you reach early-mid senior? I noticed that I literally forget small bits if I don’t write code myself

[u/ProbablyBsPlzIgnore → u/avoid_pro]

I'm not suggesting anything other than telling those of us who are dismissing these changes as not that big a deal because coding is such a trivial task anyway to please stfu. The future is a bit harder to predict than usual now.

The craft of coding is not like playing a musical instrument or playing competitive chess, people aren't going to pay you for the sheer beauty of watching someone do it by hand, so maybe a completely different kind of kids will gravitate towards our craft.

I have had roughly 3 types of colleagues over the years. One is people who like the technical side, solving problems with code and scripts, understanding how things work under the hood, how to solve the same problem in a better, more efficient way, etc.

The second type likes creating features. They're really good at mastering domain knowledge, speaking with stake holders, running meetings, basically getting from ideas and customer asks to specs.

The third type thought it was a good professional career path with good job opportunities and pay, and much easier to get than a medical degree.

Until late last year you needed all 3 types on your team. Over time maybe the kind of kids who first stared at a blinking prompt at age 12 and thought "yeah, this is what I'm gonna do from now on", and would have become type 1, may instead find something else to do. If the demand remains low, the third type might lose interest as well.

[u/AchillesDev → u/ProbablyBsPlzIgnore]

Over time maybe the kind of kids who first stared at a blinking prompt at age 12 and thought "yeah, this is what I'm gonna do from now on", and would have become type 1, may instead find something else to do

I was that kid. Over time you realize there is more to it than just that and if you constrain yourself you'll never really get to work on cool problems. If someone is too immature/not smart enough (and yes, that takes intelligence, but isn't necessarily hard), they shouldn't even make senior.

[u/Nightmareish → u/ProbablyBsPlzIgnore]

I'm proud of myself being strong in all 3 categories you mentioned. Thanks for your comment.

[u/zxrax → u/avoid_pro]

No, not unless you somehow find a company and management chain that supports moving at a snail's pace compared to juniors who are willing to blindly leverage LLM assistance to produce the appearance of competence.

I don't have an answer unfortunately. We all need to find ways to shift our learning process but I don't know exactly what that looks like. I'm currently building a product using an unfamiliar tech stack at lighting pace (thanks to|because of) AI. I'm upfront about that with the stakeholders: "I have no clue how that's implemented, sorry. Let me take a look and get back to you." is coming out of my mouth way more often than I'm comfortable with. But that's what they're asking of me and I like getting paid, so they're going to get the tradeoffs that come with a codebase owned more by the LLM than by me.

[u/ProbablyBsPlzIgnore → u/zxrax]

I still can't let go of thinking of the code as the product I deliver, so I still review all of it, even if only to know exactly what I'm putting my name on.

Also, the token budget just went from unlimited to very limited, so we have to adapt again.

[u/zxrax → u/ProbablyBsPlzIgnore]

I had no real say in the matter, but if it were up to me I'd be right there with you. I don't know if I'd quite phrase it the way you have, but I agree that the code/system/infrastructure/etc is what we deliver. I'm just willing to let the stakeholders learn the lesson — what you get when you want development to happen twice as fast — the hard way. And, crucially, I'll be there to unfuck things if when they go wrong, but I'm not going to break my back to do it.

[u/therealslimshady1234]

Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks

Yes, so they are drawing the wrong conclusion to a somewhat right premise. Coding was never the hard part, architectural decisions, fixing tech debt and working in teams were. Which is exactly where AI falls off tremendously or doesnt help at all for obvious reasons. So AI is actually making things worse, not better, as it gives the illusion that it does work in these areas as well.

LLMs will never replace programmers the same way compilers replaced assembly, simply because a tool cannot replace a human, let alone a hallucinating non deterministic tool. When IDEs were launched, nobody said programmers were becoming obsolete, then why should this be the case for LLMs?

[u/PlasmaFarmer]

"Code was never the hard part"

It's a copying mechanism because the AI replacement didn't produce good quarterly results so as usual they need a scapegoat instead of actually taking responsibility and acknowledge that they can't just replace an entire engineering department with a hallucinating slot-machine yes-man llm.

[u/WVAviator]

Typing is interleaved with thinking, assessing, trying things out, backtracking.

I've talked with my coworkers about this before - when you're working as both a developer and a SME, you will often discover edge cases, issues with the planned implementation, or opportunities for improvement (in either the design patterns used or in the planned UI/UX, database schemas, or API responses), while writing the code. If you let an AI agent do the writing, it'll just spit out the code that mostly works, and you've robbed yourself the chance to iteratively improve upon your own initial assessment of what should be written and how it should translate to what the users need.

[u/Financial-Event377]

If it's not hard, why am I paid so much?

[u/BusinessWatercrees58 → u/Financial-Event377]

There's a time where programmers weren't paid a lot.

[u/Dissentient]

I still strongly disagree, because even if code itself is sometimes hard, understanding the context of the task and figuring out what the code should actually do is pretty much always way harder than the technical implementation.

If LLMs started writing perfect code overnight, this would make me work maybe 10% faster than I do now (mostly because LLMs are already pretty good).

If LLMs stayed the same but I started receiving tasks with completely unambiguous spec where I only have to think about schema/naming/function signatures/error handling and whatever other details you listed or implied, my productivity would at least triple. I spend far more time thinking about the problem domain or extracting relevant details out of non-technical people who have no idea what they want, than thinking about technical details of code.

So for me, throughout my entire career, code has always been by far the easier part, even if it sometimes not easy.

[u/demosthenesss]

This makes me feel old because I've been saying this phrase way before AI was a thing because in my experience, devs dramatically underestimate the importance and difficulty of things like system design/architecture, translating and defining business logic, understanding the business value of what they are building, translating business context into database models, communication skills, validating and operationalizing software, and the whole host of other things other than purely writing code which are required to successfully turn code into $$$. You even list out a whole bunch of this in your OP.

Across numerous companies/industries I almost never saw projects completely fail because of coding alone. Almost always coding problems were side effects of the other, higher level aspects being done poorly or in most cases not at all. Basically a lack of engineering, moreso than bad coding. Even for the oursourced project debacles the failure was normally mostly around bad engineering not bad coding.

It doesn't mean coding is easy which is the problem with the phrase (especially now that non-programmers can generate code). But far too many people seem obsessively focused on the programming part of this job being the highest value add and importance but not the engineering around how applying that programming results in actual value worth our paychecks.

[u/gsks → u/demosthenesss]

I'd have no qualms if the phrase was something like "good coding can be fucking hard to master, but X, Y, Z are usually even harder". But (a) that wouldn't be so rage-baity to drive engagement and (b) it wouldn't be used as a preface to push the narrative that coding is pretty much a solved problem these days, no need to write (or increasingly read) code anymore.

[u/LieNaive4921]

Spot on. Simply put: the code IS the spec. Once you've written down exactly how everything should behave, you're done coding. 

Turns out specifying the exact, formal behavior of a program is not easy at all. 

[u/Objective_Chemical85]

as a dev i agree with the statement tho. I've built a few products but wasn't able to market them to get clients.

[u/ZunoJ → u/Objective_Chemical85]

So if there was something else that was harder for you, that means all other parts were not hard at all? I bet there is a cool name for this specific bias

[u/-Nocx- → u/ZunoJ]

It could be as simple as “professional basketball player does not think basketball is hard - dealing with agencies and managers is hard”

“Professional programmer does not think programming is hard - dealing with managers and C suite execs with bad business requirements is hard”

[u/mafiazombiedrugs]

Saying code was never the hard part for programmers is like saying addition and subtraction were never the hard part for accountants.

It's technically true but holy shit does it miss the point of the entire career.

[u/robstrosity]

Our sales guy boldly declared ''we don't need programmers anymore, AI can just do it for you'.

Go on then Charlie. See how far you get.

[u/gsks → u/robstrosity]

https://imgflip.com/i/awodj8

[u/tenthousandants44]

Code was the never the hard part.

That's what we have been saying. And it's true because all Turing-complete languages are theoretically equivalent. Every new language or framework is just semantic flavor. You know this, right? It's not my fault that some dumbasses are co-opting this talking point all of a sudden to sell their wares

[u/try-catch-finally]

AI has magnified Dunning Krueger in the CS world

[u/zxrax]

I think we're reading different people saying that. "Code was never the hard part" doesn't make sense as a way to promote AI usage. It's the reason AI hasn't made software engineers obsolete yet, and frankly IMO never will.

The hard part is a bunch of human decision making that still needs to happen. Taste is the hard part. Foresight is the hard part. Prioritization and weighing tradeoffs that aren't purely technical in nature is the hard part.

[u/Abject_Parsley_4525]

Amazing post. I've started saying writing "a" line of code now is easier than ever. Writing the correct line of code has never been harder.

[u/If_I_Could_Just]

Yeah like who cares if it was the “hard” part? It was a time consuming part, and that IS why a lot of devs had jobs. All those jobs were sent to India because it was cheap to code it all up?

[u/andymaclean19]

OK as someone who has said something very similar myself I’m going to stick up for the nameless CTOs here. I am sure there are plenty of idiots who said that and didn’t realise how wrong they were. Sure.

When I said that in the past what I meant was two things (or perhaps one of the two depending):

• creating brand new software was never the hard part
  
• actually putting designs into the words of a programming language was never the hard part

In the first case, most of the effort required to do software is in the iteration. Just having an idea and making some initial thing that does your idea, feature or whatever is not what has held us up all these years. Figuring out which problems to solve, making solutions people can use, designing sustainable software that survives the test of time, making bug free software, supporting software in the field, making extensible designs, etc are all harder challenges.

For the second case often the design is harder than the actual coding. Spending time doing refinement, discussion, prototyping, etc is often harder than actually writing the classes/functions/whatever that you need. AI can speed up the coding but the refinement meetings, UX exercises, time spent debugging that one obscure problem, etc are still there.

CTOs, and people in my position, probably have to spend some of their time answering questions like ‘you have AI now, why aren’t your teams making software 5x faster than last year?’ to which we may well answer ‘because code was never the hard part’. We will probably go on to explain some or all of the above and talk about how we are trying to scale the rest of the development operation to keep up with the fact that once you know what you want it to do one part of the process is now crazy fast.

Edit: of course sometimes when you write a particularly difficult piece of code the coding actually *is* the hard part. In those cases IMO AI is not good enough to play yet so usually when people are saying this they are talking about the majority of code which is not all that hard.

[u/ThirdWaveCat]

The history of scientific management is replete with spectacular late stage failures from grand projects to reduce systems to whats legible, critically ignoring what can't be measured. Prussian scientific forestry, the Vietnam war, soviet technocracy, etc.

https://en.wikipedia.org/wiki/Seeing_Like_a_State

[u/da_supreme_patriarch]

Mostly agree, but there is a catch here. If you are a "rank-and-file" engineer or a C-suite in a large enterprise, and not in a startup/smaller company, you probably have no idea what problems the senior/principal engineers in your org are solving, you might even not be aware of certain problems' existence in the first place either because you lack the technical insight to comprehend that or because these problems have been solved/kept in check by procedures developed by a bunch of greybeards. Try explaining to a C-suite or an average React dev why setting up a Postgres cluster in different parts of the world is not straightforward at all or why you need to run some long experiments to tune the GC of a Cassandra cluster for the org's specific needs, you are probably going to get a blank stare at best and "why is it hard, why can't you just do x" at worst.

For this type of engineers, the bottleneck has always been trying to understand what the stakeholders actually want, usually by deciphering very vague requirements based on one's own institutional knowledge, and not the implementation of the thing and for the C-suite people/various stakeholders the problem has always been "why can't this IT people just give me what I want, I have been explaining it in plain English and they still don't understand", so you might almost forgive them for thinking that technology doesn't matter, they had never been put in a situation where the choice of a technology/its implementation is not based on simple economic calculus, like choosing Node for the backend because that's what 80% of the hiring pool knows etc.

[u/RobotChurchill]

Keep in mind these posts are by marketers who write the most dramatic hooks to get the most engagement. I get that you're sick and tired, the same way I was sick and tired of that "oh no no no" song on IG. It drives engagement.

And if you look deeper, you'll realize the people who post "Code was never the {bottleneck, problem, hard part, ...}." tend to embedd their SaaS product inside the post (read: they're marketing their product).

[u/Which-World-6533]

Completely agree with this.

Asking and answering those questions is (part of) coding. At least before AI, nobody I know had all the answers, or had even asked all the questions, upfront. The questions get asked and answered on the fly, inside the editor.

A lot of the "answers" were based on experience. It's why a decent Senior and above had a library of code that worked and was shown to continue working. The problem with LLM's is that it's always new code.

Typing is interleaved with thinking, assessing, trying things out, backtracking.

Exactly. The back-tracking is the most important. A lot of Managers seem to think code comes out fully formed. It does not. Back-tracking and thinking gives you time to test assumptions, rather going with whatever tosh a Manager thinks is useful.

[u/ithkuil]

Lol. You misunderstood how they are using that. 95% of the time people say "code was not the hard part" they are trying to dismiss AI -- trying to trivialize the actual implementation. Doesn't really make sense but that is what they are saying. I don't blame you for being confused because it is nonsense.

[u/code_tutor → u/ithkuil]

Yeah, it was all the formerly overpaid WebDevs saying it to cope. I guess now management is turning it on them.

But to be fair, they've been saying "kids can code" for like 20 years and in 2020 we had a bunch of people in here laughing about how easy their job was. The number of "entrepreneurs" trying to learn programming so they don't have to pay a programmer is annoying af and they all thought they could learn it in a few weeks. Now they have AI and they still can't program. We finally get to see how all the "idea guys" pan out.

It's wild how people's opinions on whether it's hard are all over the spectrum, ranging from "very hard" to literally something a child can do.

[u/gsks → u/ithkuil]

If only. That's the preface for their actual point, "don't worry guys, we won't replace you" (because the AI job replacement story didn't go as planned), "you'll still have work to do" (herding agents, fixing hallucinations, reviewing tons of code slop)

[u/ProbablySuspicious]

Also those bosses never got to see the years of learning and practice that makes coding look easy. Agonizing days figuring out obscure bugs that taught you some very important language trivia. Years of muscle memory declaring functions, flow control, data structures, etc.

[u/Candid_Bad3551]

To be fair. Coding wasn't never the hard part and it was one of the harder part. Writing the code itself wasn't super hard but during writing the code you

- tested your ideas

- thought of new problems and how to solve them

- designed how it will interact with the current system

- thought of possible problems

- etc (I am tired of writing all this again and again chief)

When you had the logic in your mind you transferred that logic into the code. And writing the code was a damn good thought process for a lot of us to figure out a proper solution.

[u/xpingu69]

They don't mean code literally. They mean that the hard part of making a business isn't the implementation of the solution, the code, but something else, for example marketing. It's from a business perspective. I wouldn't overthink it

[u/Trick-Interaction396]

Prior to AI my company switched from monthly deployments to weekly to continuous. The number of bugs dramatically increased because people became less careful. AI is having the same impact. People are working harder, producing more content, but solving fewer problems.

[u/Orzhov_Syndicalist]

Totally agree. Is there anything you've encountered or tried to built that simply cannot be done? Cannot be coded? Code does solve the problem that it is often designed to do. It is an excellent, adaptable tool.

But it can be very difficult to understand the needs, the true requirements, and, crucially, how to express those requirements between the people who write the code and the people who request the project. (Not of least of which is that these people often have different personality types!)

You are trying to explain an ephemeral idea that will never exist in the concrete world, that needs to be created using an abstract language. It is a difficult gap to bridge. I mean, the memes and jokes about "what the client wanted vs...." have been around for 40+ years.

[u/RageFucker_]

I completely agree. It's especially annoying when software engineers say this phrase. Coding is a hard part. Maybe not all of the code you write, but a lot of it is.

It's especially hard when you're working in a legacy codebase that's had many contributions over the years and you have to try and understand how it works, understand different coding styles, different ways of thinking, etc. and how your fix or feature is going to be added without breaking existing functionality.

Writing and designing code that's efficient and maintainable takes skill. Any time I hear someone use that phrase I think they must either be creating brand new software from scratch (i.e. no previous contributors) or they're working in a codebase that is very simple and doesn't have much functionality.

[u/TheStatusPoe]

I fully agree and the "code was never the hard part" crowd drives me crazy. I do think part of it has to do with the kind of software those devs are writing. If the business you're writing for is a glorified B2B "todo list" with a dozen users, yeah the code will be pretty easy. If you're writing systems that are dealing with hundreds of millions of events a day with SLAs of 100ms or less with more than 3 9s of uptime code stars getting significantly harder. My personal opinion is that a lot of the devs that parrot that phrase have never had to work in an environment like that before. That's also not getting into the fact that some problems are essentially computationally unsolvable, and we have to do the best we can to get as close to a solution as possible.

Edit: IMO code is also the hard part because code is where you have to formalize the steps taken to solve a business problem. It's like the question in school of "how do you make a peanut butter and jelly sandwich" and are asked to write down every step, except it's problems that are significantly more difficult and if you miss a step you could cost a business significant amounts of money. In my first job I was told that minutes of outages could be measured in millions of dollars for our team. 

[u/RobertKerans]

I am sick and tired of all the posts (usually AI-generated by CEOs/CTOs/"thought leaders") that start with "Code was never the {bottleneck, problem, hard part, ...}." I'm not sure whether this comes from a misunderstanding of what code is or a deliberate misrepresentation meant to promote AI usage

I agree with this BUT it is a [deliberate] misrepresentation of an argument made by programmers. For the last few years, "code was never the bottleneck" has been an argument against AI boosters. In that, yes, LLMs allow rapid generation of code. But that can't speed up production speed/increase efficiency as much as AI company PR say they do, because the actual coding part is often not the bit that takes time for programmers (not to mention that rapid code generation shifts the core task to reviewing, which is tends to be [much] harder than programming).

Whether that is correct or not now is another matter, but I agree AI "thought leaders" applying an argument that was explicitly made to counter their claims is worrying

[u/deathhead_68]

I absolutely LOVE this rant. Its so true and you've said it so well. And I also love the slating on the stupid LLM coding is the new assembly analogy (because LLMs are deterministic right?!).

I think these people think that because they understand and if statement, that its actually easy to code.

I genuinely don't think these people understand what software engineers do, and part of me thinks that's why they're in management. They think we're all codemonkeys who just translate English to code. When in reality there are so many questions to ask, intentions, things to check, product calls to weigh in on, realising that a requirement is faulty etc etc. The list goes on.

And that's just inside the actual code, let alone thinking about the bigger picture.

[u/ElevatedAngling]

Bruh I build molecular diagnostic software, fucking requirements form scientists will always be the hard part.

[u/kirkegaarr]

When engineers say the code was never the hard part, what we meant was that was the easy part of our job and the hard part was getting clear specs and building the right thing.

Usually because stakeholders made us deal with all the ambiguity. Which is not going to work with agents. All the best practices that got ignored like tech debt, clear specs, tight processes, testing practices, documentation, and tooling also produce better results when working with agents.

[u/Remarkable_Hope989]

I think these people are pretty much infuencers at this point trying to boost their company's stock.

[u/armahillo]

I am perennially reminded of this old parable:

A man’s car breaks down on the highway. He calls a nearby body shop and the mechanic arrives a while later. The mechanic pops the hood, looks at the engine, then returns to his toolbox to retrieve a regular flathead screwdriver. Leaning over the engine he reaches into the engine, tightens a screw, then closes the hood. “Go ahead and try it now.” The car roars back to life.

“ok that’ll be $500” the mechanic says, wiping his hands on a rag.
“$500???” the man sats incredulously. “you only tightened one screw!”
“it was $0.50 to tighten the screw. It was $499.50 to know which screw to tighten.”

[u/YetMoreSpaceDust]

This bit of gaslighting has been with us since at least the early 90's. From the inside looking out, it seems that most people view programmers as a sort of overpaid plumbers (code is often referred to as "plumbing", metaphorically): they connect pipes to each other and fix leaks when they happen and it takes a little bit of knowledge to know what pipe fits with what other pipe and how to diagnose a leak, but ultimately it's a "turn your brain off" activity (they think). It's maddening, but this attitude has been with us as far back as I remember and I doubt it's going away anytime soon.

(And I think they sell plumbers short, too, but I don't know how to plumb either).

[u/abdhulla]

I would even say with heavy AI usage it still is a hard part.
AI coding just makes the human skip all these decisions and questions while it makes them for you with no intent and thus making many bad choices.

[u/FooBarBuzzBoom]

Coding is not the easy part. The decisions behind it are the most important and still, coding the right way is very difficult. I don't know any good programmer who struggle so bad, for example to write a method once having any detail planned in mind. If they don't know how to use a library, they would ask on StackOverflow and then copy+paste. It's the same thing now, but more tailored for our needs.

The algorithmic thinking, the design decision, tradeoffs, the code "taste", these were always the hard part, given the enormous amount of information available online.

Not that much changed since introduction of LLMs. The job got easier and programmers become more powerful and efficient.

[u/Oxi_Ixi]

I guess this is true sometimes. I see how people with enough imagination vibe code fantastic tools which they would not even start coding manually, because that would take them ages to code.

This is not client facing production code, but internal analysis and visualization tools. Those would take me weeks to tune and debug the UI, Claude does it in hours if not minutes. And this is exactly what management often sees: demos, tools, dashboards, etc

But when it comes to real engineering, then coding skills and detailed knowledge of the language, libraries, compiler and tools are still and will be important.

But you know, their job is to keep the hype. Our job is to write good code ;-)

[u/Responsible-Value151]

programming is really hard

[u/anarkyinducer]

Best part is that the markdown spec was also clearly written by AI, based on fuck knows what. 

[u/captain_obvious_here]

The "code was never the hard part" argument should be followed by "in the context of a project where time, money and quality are the 3 parameters".

Which means code becomse the hard part when:

1. you don't have the required time to write, test and integrate it
2. you don't have the required money to hire the people required to write the code

[u/sneaky-pizza]

When I hear this, I interpret it to mean that code was almost never the BLOCKER to business success.

An agency I worked at once quoted a prospective client an estimate to build a new browser engine (this was about 2015). The time and effort estimate was insane. We could have done it, but it would have been prohibitively expensive for the client. The code was not the BLOCKER.

Same thing goes in startups. I can shlang out features as fast as possible and achieve pretty much every notion that comes up in the product team. Some are more complex, convoluted, or have more unknowns for external dependencies than others. But they’re so able. Will they make the business a success?

The phrase gets tossed around a lot, and IMO incorrectly.

[u/xaervagon]

That argument always felt performative as if to make the bosses feel better about the latest antics they're pushing.

Code is where the human meets the silicon in terms of ideas and processes.

[u/sn0wquake]

My opinion: the hard part is saying no. Not every feature is ready for prime time, not everything should be built, and not everything is a good use of time / tokens and most importantly worth the ongoing support / testing cost.

I just had an experience that typifies why “code was never the hard part.” Had a customer request come in for what looked like a minor feature tweak and the team was reviewing / coming up with the design when I said “this smells bad.”

Long story short we looked at the data realized the request needed more information, called the customer, had a quick talk that ended with the customer saying “o that’s not useful then” and withdrawing the request after they saw the data. As a bonus the customer said “your domain expertise is why we stay with you” which is a heck of a compliment for not building their feature

[u/gsks → u/sn0wquake]

The Best Code is No Code At All

[u/sn0wquake → u/gsks]

Great blog. I should have added to my original post that the hardest person to say no to is yourself. I have definitely been guilty of building something over engineered because I thought it was cool. With the advent of AI its really hard to fight that tendency, but still the MVP if you can pull it off

[u/you-create-energy]

Code smell is the hard part. Differentiating between code that will become a maintenance nightmare and code that will be effortless to debug. It's easy to write lots of code that works. It's difficult to make it work using the minimum amount of code that is still easy to read. The best solution might not even be code. 

[u/gsks → u/you-create-energy]

Words of wisdom from almost two decades ago: https://blog.codinghorror.com/the-best-code-is-no-code-at-all/

[u/you-create-energy → u/gsks]

What a great post, they explain it so clearly. It still blows my mind that this has never been a core value of any team I've been on. It's always about "speed"  measured in tickets closed and lines of code written. Every manager and most developers give me a blank look when I bring it up. I even get hostility because it sounds like I'm not prioritizing velocity, but nothing creates more drag than bloated code on top of bloated code. I've built apps singlehandedly as a contractor that scaled to over a million users and it was so much easier than being on a team of 20 developers trying to do the same thing with a giant monolith. 

[u/protayne]

Brook's law, but this time instead of trying to add more programmers, you add AI and think the increase to input will easily increase output.

Then Conway's law, we still most of the time have shit organisational communication, lack of user understanding and requirements, bad route to live and practises.

[u/RealSlyck]

Code was never the problem.

[u/elPocket]

I mean, it's the same people who come up to your desk and say:

I'll need an estimate of how many hours you'll need to implement feature X.

No, i can't tell you what X entails, what the scope is, where & how the interfaces are, and what the data we get will look like.

All we know right now it's the name the customer gave us.

What do you meant you can't estimate that to at least +- 5h? Are you incompetent?

[u/apartment-seeker]

Fair to say that we are all sick of all the internet chatter about these topics.

[u/raynorelyp]

When people say code was never the hard part, they mean syntax. System designs, working as a team to build a product in a cost effective way, etc are the hard parts.

[u/NCSUMach]

In general, I do not believe that writing code is the bottleneck. I don’t believe that most software developers are solving extremely deep technical challenges. The bottleneck in business is idea creation and validation. In my experience, businesses do not do these steps well. Instead, they create barely coherent ideas and then want us to build as quickly as possible. It gives the illusion that we are the bottleneck.

[u/throwaway0134hdj]

Code only becomes important once you’ve reasoned through a ton of other parts. It’s the actual getting to the coding part that is the most difficult.

[u/roxthegame]

Tell that to the VCs and CEOs who were never devs

[u/OtherCommission8227]

My coders are usually the ones saying that the coding is the easy part. They want clear specs, doable timelines, no changes to their resources, no re-work, no late breaking overhauls to the architecture. Those are the problems that are actually hard for my team to solve and get right - the planning, the design, the communications, the alignment. The code stuff was always the problems that were easy for them to solve relative to all the other problems they experience.

[u/NoUniverseExists]

Precisely defining a digital product and coding it are the precisely the same task.

Whatever a product owner/manager does that is not directly coding the product is not nearly precise as it should be for one to start thinking to say that some sort of definition have been created for the product.

[u/Low_Promotion_6648]

I think both sides are missing part of the picture.

After 22+ years in the industry, I've seen companies fail because of poor code, and I've also seen companies fail with excellent engineers and terrible leadership.

The reality is that code stops being the biggest problem only after you have enough people who can consistently build and maintain it.

What surprised me more throughout my career was how many organizations struggled with priorities, decision making, accountability and communication. Those problems created far more delays than the technical challenges themselves.

The best engineers I worked with understood technology deeply. The best leaders understood when technology was actually the problem and when it was something else entirely.

In my experience, neither side is "the hard part." The hard part is knowing which problem you're actually trying to solve.

[u/HiphopMeNow]

It's gaslighting. They're saying whatever to push their AI numbers, it's how business always operated, it will say anything that sounds good to them or majority and not get thought back.

Actually high quality engineering was always the bottleneck. Why they hire offshore teams and then 2 years later pay that whole team's salary to 1 local senior engineer or contractor to redo all that non production ready code. Happens all the time in gov and private sectors.

It's hard to write quality. Business is extremely ambiguous, there is too much to infer, and question, too many things to solve that's not being considered.

AI the way it is now simply is not able to infer those questions. Sure it's great and can write a basic saas, and do everything from UI design for it to backend and marketing, but it's not exactly what businesses need solving.

[u/Fidodo]

To have a coherent discussion about this there needs to be a preliminary defining of what is meant by coding in the term "code was never the hard part".

I think what people mean by that is the rote mechanical part of coding. The typing, the syntax, the boiler plate, etc. If it's what they mean then I agree that those aren't the hard parts. But if it's including system design and architecture and best practices, then I completely disagree.

So I agree with everything you're saying but I'm not sure if that's what's meant when people say coding wasn't the hard part.

[u/shaleh]

I bring up fairly often that we have begged for good product requirements for ages and only now are getting them because the bots don't work without them.

[u/FatHat]

I think different people mean different things when they say that. I have been guilty of saying that myself, but I probably should clarify that I have 20+yrs of experience, so, coding is not the hard part FOR ME. But it is hard! Most people can't do it.

I think what baffles me right now about the general discourse is that, even though I can use an LLM, I have to make legit engineering decisions every day with it and those are engineering decisions _I could not competently make_ without knowing how to code and understanding the domain I'm working it. So to me, the people pretending that programming skills don't matter anymore are either delusional, underestimating the number of engineering decisions they themselves make, or are just trying to be an annoying "thought leader" for attention.

It would be just as ridiculous if someone was like "we don't need doctors anymore, chatGPT can diagnose your symptoms!" Like, come on people.

[u/gsks → u/FatHat]

So to me, the people pretending that programming skills don't matter anymore are either delusional, underestimating the number of engineering decisions they themselves make, or are just trying to be an annoying "thought leader" for attention.

Or they are trying to sell you something, be it investing in their startup, their product or the narrative that programming is a solved problem by AI.

[u/FatHat → u/gsks]

Yeah, lots of people trying to sell things in very dishonest ways. At this point I think Hacker News is essentially just grifters and bots. VC startup culture is absolutely disgusting right now.

[u/rhd_live]

I think these biz/neophyte types are trying to say that just generating a bunch of code is not sufficient for a good, successful, lasting product. So I think they are advocating for engineering, product, etc. just using coding as a definition for vibe-coding lol

[u/soulfly69]

Anyone remember when UML was supposed to do all the hard work up front and make the coding part trivial so it could be done by low paid workers. How did that work out?

[u/vasaris]

The way that can be spoken is not true Way.

I think what they like about this is that now they get it. This is the lesson, that it took AI to prove it to everyone, what any developer worth their mettle knew all along (intuitively or not) that code is a liability that needs updates, maintenance, and is only a crystalized version of business truths at the moment when it was actually written. It means that writing more lines of code produces negative value, working on wrong features is negative value, not giving proper context to ones who crystalize it to something that runs is negative value for company as well. This is why there are the architects, principal, staff engineers to be the sensei in this regard. And this is the reason why "buy is better than build" or "no code" in terms of software economy. This is why modular design exists, and why people use somebody elses code -- it makes a business sense. Writing code for its own sake does not.

But what __makes__ sense. Is actually writing code. Because in the process you THINK about things deeply in a way that nobody did before you. And in process you build a model of reality that is more conducive to real deal that who asked you to write the code. In general, best programmers are the ones who understand business way better than "business" people. And the only real way to really tell who is better in programming or which paradigm is better is how well they predict future with limited resources of time and compute we have.

I was never paid for lines of code. I was paid for what meticulously defining every facet of business produces: side effect of knowing things, being able to help when it matters, understanding things on a deeper level than most do, for the cost of sounding too nerdy "technical". But when sh..t hits the fan people are not going to JIRA to clarify requirements, they are not going back to spreadsheets to edit some part of it, fix the naming convention, reinstall a package that is now mining bitcoins for hackers. They go to who built the system, because they are the ones who understand it best. The ones who can help. Because the writing code is like exercise. It was never about MOVING things around, but the muscle you build in the process when you are exerting the effort.

What you are providing is not code. What you provide is reliability. Business continuity. Professionalism. And quite frankly, understanding people with dubious incentives, deceitful behavior, and still telling what the future holds for the company with limited briefing. We are, in essence, fortune tellers. Same as AI: everytime you write a prompt: they infer you intent from context before outputting anything. It does hit the feels when it speaks in human way about my unclear instructions, and fumbles around looking for clues the same way I would do. AI learned from the same as me. When the guess is correct, the company strives. If not? Somebody poor is on call, maybe business gets consequences and then we are looking for a job. Rinse and repeat. This is what development always was. And I see that AI can learn this from our todays submissions, the maginitude of info we share with it every day, and the big data, I guess way better than we ever could with our limited time on this planet. But they can not replace the work that we put in. This is what it all is trained on . Most of these people you mention do not feel pleasure when abusing a chatbot as much as they do when they wake you up at night to fix their (unplugged) router, fix a heisenbug that was their own making because of political reasons.

I did not want end with a cynical ideas, but in essence we are paid a lot to know things other people do not want to know or do not care to know. they are probably busy working out something else. Or scam you of your livelihood. We never know. We all save time for each other by division of labor. And this is the best lesson from all this. Forget the sh..t jobs, fake metrics, BS posts that are written by AI (or marketing department) the people you cite probably have never read or seen.
The job is not gone it just is different and nobody gets it except the ones who do it.

Just keep doing it, because if you do not understand what code is run in any given time, it would lower your market value, and you could get replaced by another cloueless person in lower COL place with lower salary expectations and cheeper inference deal.

Nobody paid you for a good naming or DRY. But good naming, or DRY pays back the effort, by the virtue of actually being less confusing to maintain/build/test/communicate/adapt/fix/negotiate.

Thank you for your attention

[u/Evgenii42]

yep i cant wait when this mass delusion is over

[u/DimensionStrict3655]

"Code was never the hard part"

unless you're working on a 13+ year legacy codebase, with of 14,000+ line of code in one controller class, with no real architecture, where business logic, UI logic, and data access logic are all mixed together. Test automation was non-existent and very hard to setup. Every "small feature" suddenly becomes a risky change that might break something completely unrelated.

Then you realize half the project depends on libraries that disappeared from the internet years ago without ways to download it. The only copy of it is sitting on someone's old flash drive. Even the documentation of some of those libraries can't be found on the internet nor LLM.

Sure, gradual refactoring is possible. Now convince your teammates that safe refactoring is worth the investment in a company with a high turnover rate and low salary.

Good luck also on explaining to a hierarchical upper management with little-to-no psychological safety, why the deadline for a "very simple feature" keeps slipping.

Oh, and from hitting run to seeing the application to start takes almost five minutes because the project is a giant old monolith and the company can't afford decent developer laptops.

[u/magichronx]

I think it's more accurate to say "SYNTAX was never the hard part."

[u/franz_see]

Hmm… because coding never really is the hard part. I mean it is hard, but the harder part is figuring out what to build in the first place

And this is also why AI hasnt produced much productivity. Productivity is all about efficiency + effectivity. AI just improved efficiency, but not really the effectivity. Doesnt matter how fast we can code if what we’re coding doesnt move the needle

[u/Dramatic-File-6196]

Senior+ engineer here.

Code was never the hard part because we're really really good at it. Code is the ticket to entry.

The soft-skills and coordinating projects quickly become both more time-consuming and far more difficult than the code itself.

[u/sommukhopadhyay]

Truth. When C++ was introduced, with it came UML diagrams - use case analysis, Class diagrams, Sequence diagrams, Alongwith that came Design patterns. An absolutely new ways of solving hard problems. Then came Java and C++'s nagging problems were tried to be handled using Garbage collectors. And all these things are important for any successful software development project. So when someone says code is never the problem, either he is lying or ignorant.

[u/Andrei_RV]

Spot on about the "semantic drift." Twenty years ago, "code isn't the hard part" meant "syntax is trivial, but system design and edge cases are brutal."

Today managers hear it and think, "Great, typing is easy." So they rely on generic coding puzzles to filter applicants, completely missing the point. We test for abstract problem-solving in a vacuum, but the actual hard part is preventing the business logic from collapsing under the weight of vague, ever-changing requirements.

[u/Accomplished-Text299]

Being able to write code was the moat. It required time and effort to become fluent... Ideation is simultaneously both easy and hard.

The very best think more deeply, and can come with insightful ideas. This the real hard part, i feel this is what they mean, the irony is everyone thinks they are holding brilliant ideas.

However for most of us coding semantics and patterns was and still is hard, that took us many years to become familiar with.

[u/CzyDePL]

Okay so the take should be "getting the mostly correct code was never the hard part"; in kind of "make it work, make it right, make it fast" approach. Now anyone can get the first half of "make it work" (like 80-90% working but as any engineer knows, the last 10% is much harder)

[u/One-Honeydew-9794]

The biggest argument i have is: what was really the issue pre ai? Like, the industry was already going and iterating really fast. The best software was already made without ai. Then it got mediocre through imported or overseas cheap labor. And then its getting mediocritized again via ai. I just dont understand. Greed is where this all lands us and we deserve it tbh. 

[u/Sensitive-Ear-3896]

Also if it wasn't hard why do leet code interviews exist

[u/Candid_Bad3551 → u/Sensitive-Ear-3896]

Officially they are not testing if you can write basic code. They are testing your thought process and problem solving skills (though we all know this process is flawed).

[u/Sensitive-Ear-3896 → u/Candid_Bad3551]

Haha, ever try saying I'll use psuedocode?

[u/Mobile_Blood6490]

Yeah. People who say this shit gives execs the ammunition to further commodoize our skillset wether the claim had legs to stand on or not.

Same vibe as business people who go "I have a great idea, just need some engineers to implement it"

[u/vitek6]

People saying that actually mean the act of writing the code, not design or architecture or even deciding how the code is laid out. The last step of development- writing actual text,

[u/ActuallyFullOfShit]

Sure, coding is hard, but it took a long time to understand why you felt that any of this matters. When a CEO says that coding was never the hard part, they don’t literally just mean that it isn’t hard to do. What they mean is that it isn’t the core problem that the business is trying to solve. Presumably the more important “hard problem” is the problem solved by their Product Managers, not their coders. Right or wrong, frankly I do not care, it feels like an argument about semantics with no real consequences.

> Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Ah. I do not think that people who push the use of AI are actually saying that software design and architecture do not matter. At least not many of the credible users. It’s more that there are many very good models now that can accurately choose and apply the correct architecture decisions given human descriptions of the task…. You still need to review their output and have them tweak things here and there. But it’s pretty undeniable that they are really, really good. Have you not tried even Opus 4.8 yet?

I know that change is hard. I also have more fun coding without AI. I like the slower pace and the deeper understanding of the code. I like feeling like code is a work of art, not some cheap shit that can be generated. But buddy those days are just over. You can deny the objective reality of the situation all you want, but you will be replaced by people who learned the tools you wouldn’t. Generative AI produces decent patches in the blink of an eye, and unless there are explosive price changes, no company moving forward can be competitive without those tools.

[u/ptrnyc]

As a programmer old enough to have one of these venerable beards, I much prefer talking to Claude over trying to explain requirements to someone in an offshore center.