13 ms·

“Code was never the hard part” is an insult to all programmers

• qwe516 2mo ago
  Starts with a rant that appeals to hardcore programmers and then tells them to adapt. Of course he is an AI consultant among other things.
  • senko 2mo ago
    OP here. You're absolutely right, I just want to add that "other things" include being a programmer since the nineties :) Edit to add: instead of "adapt" (which would imply "embrace AI", which I didn't say), my intent was more along the lines of "be adaptable."
    • jamauro 2mo ago
      > You're absolutely right Claude, is that you? :)
  • threethirtytwo 2mo ago
    Is what he said wrong? Why don’t you attack his argument rather than his background. Not snark. I want to see the holes in what he says and I literally don’t care about who he is. You must be anti ai among other things.
• doubleorseven 2mo ago
  I always said programming is 80% thinking and only 20% coding. nothing has changed since then.
• thomasjeff1 2mo ago
  Exactly! Try reading a large C code base.
• distantprovince 2mo ago
  I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.
  • hellisothers 2mo ago
    Or put differently: code as a means to an end vs code as the end. You need both types, the ratio changes as things change, neither is The Way.
    • crabmusket 2mo ago
      While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them. I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers. And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here. Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that. Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.
• effed3 2mo ago
  what is -coding-? only typing down some code? the hard part is always the design part, reading doc, reading other code, understanding the sum of the parts, making choices, until the code to write is (quite) -obvious-. Probably is a question of terms: there is two things: -design- and -coding- (but could be anything as: building, drilling, turning, traveling..) so to make things without a good design is the regal way to problems, many times is a problem left by others, and in a world more and more complex and fast-changing can only be more and more worst. Hard to say what part is really the hardest, but starting with a bad design is no good. And now probably LLM will solve some problems, but for sure these tech will create more and more new ones. https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf
• firebot 2mo ago
  > If coding is easy, why is software so damn buggy? Debugging is hard.
  • anonzzzies 2mo ago
    And people are very lazy; test one ideal path, works, done.
    • Ekaros 2mo ago
      It is usually forgetting that everything can fail and will fail. And I mean everything. If it shouldn't fail it will at some point. And you should take that into account. And we usually don't until third or so time...
• bob1029 2mo ago
  > If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place. Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
  • logicchains 2mo ago
    >Writing code is not hard. Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.
    • majormajor 2mo ago
      Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)
      • deleted 2mo ago
        [deleted]
      • Jblx2 2mo ago
        >Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE Average IQ of Electrical Engineers: 121 https://www.iqcareerlab.com/tools/iq-for-profession/electrical-engineer https://www.iqcareerlab.com/tools/iq-for-profession/electric... ...which is the top 10% of the population. https://www.desperateminds.com/blog/iq-120.html https://www.desperateminds.com/blog/iq-120.html
• a2ff6eeb0 2mo ago
  Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef. There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days. It's interesting realizing how mind numbingly thoughtless my job has become. Don't get me wrong, I wouldn't mind it if this was skilled work, but it just isn't.
  • leptoniscool 2mo ago
    /s
  • polotics 2mo ago
    Can you link us to your git repo(s) and/or other artifacts that demonstrate this take? I and many other here I think won't agree, and we mostly love being taught.
    • a2ff6eeb0 2mo ago
      Nope. I don't code for fun, and my employer will be very unhappy if I start sending people private repos.
  • ethin 2mo ago
    Interesting take. Can you link us to your (correct, maybe even formally correct) AI-generated software? Given how general this post is, I assume you wouldn't mind if I extend this to, Idk, aviation or spaceflight, so mind linking to any GH repos you have where you've written code to work in environments like that? I ask because all you said was "making software" and didn't say what kind of "software" we're talking about.
    • a2ff6eeb0 2mo ago
      Since you apparently work on this kind of software, here's a challenge for you: take the last several bugs that were reported and paste them into Fable, pointing it at your code. How long does it take? Does it find the issue? In more or less time than the engineers took? Ask it to review your code for design and cohesiveness issues. How does it do?
• add-sub-mul-div 2mo ago
  It's a strange choice of something to take personally. It doesn't mean code is supposed to be easy for everyone at all times, just that past a certain point of your own personal path towards mastery the utility of not having to write code diminishes and the complications of delegating rise in proportion to the shrinking gains.
• mrkeen 2mo ago
  The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms). Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard. You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook? When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right Coding is the easy bit.
  • varjag 2mo ago
    Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.
    • pjmlp 2mo ago
      Usually you don't have an option other than leaving, most organisations don't let seniors keep coding and nothing else. Either move up the ladder or leave.
      • varjag 2mo ago
        Non-coding architects were typically a by-track rather than superiors to ICs. Though I imagine some of them could think they were. Product managers also often don't have proper reports in the sense line managers would.
        • pjmlp 2mo ago
          Non coding architects, aka Solution Architects tend to be the next career level after Technical Architect in most organisations I have been part of. No one would jump directly into a Solution Architect. PMs yeah, those have had various backgrounds how they came there. Again, on my personal experience.
• threethirtytwo 2mo ago
  That quotation is coming from programmers themselves. Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part. It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part. That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.
• ReptileMan 2mo ago
  Code is the hard part if you are John Carmack or in a similar position where you have to squeeze every drop of performance from a hardware. That is the minority of programmers.
  • fooster 2mo ago
    I don't think that is true. coding at a baseline is hard no matter what. If it was easy everyone could have done it, and clearly that isn't true. Now there is hard-er coding. Novel algorithms, performance sensitive stuff, and so on.
• pjmlp 2mo ago
  Nope, only those without a degree that cannot do anything else, e.g. the bricklayers on a building. Real engineering has always been about talking with the multiple parties, organising architecture meetings, taking down requirements, if no infra team available setup the whole CI/CD pipeline, and so on. Programming could be done in whatever language, or low code/no code tool, solved the business problem. Now what will remain to humans is a big question.
  • HeadOfProbing 2mo ago
    Well said.
  • 12ahg11 2mo ago
    Oh really? I thought the language needed to be ALGOL on a Burroughs B6700!
    • pjmlp 2mo ago
      If it solves the business case. A proper engineer would actually recognise that should be NEWP in 2026.
  • gitremote 2mo ago
    It's not even about the degree. Fresh computer science graduates already know how to code but can't do the senior developer stuff. https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise https://www.nair.sh/guides-and-opinions/communicating-your-e...
    • pjmlp 2mo ago
      That depends on the quality of the degree. I was well served on my Software Engineering degree, coupled with the trader school in computing I went during high school. Then naturally seniority teaches office politics, and what to actually invest time on.
• gopher_space 2mo ago
  > I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho. This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.
• noman-land 2mo ago
  LLMs are the invention of the loom. Code is being industrialized. Yes, there always will be artisanal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else. Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor). We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value. Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly rising to a level above the code since the code is a fluid now that comes and goes easily.
  • 12ahg11 2mo ago
    Easy on the cocaine. There are no credible AI code bases on GitHub.
    • dnautics 2mo ago
      nah. my company (not a tech company)'s stack is ai generated and it has created credible value.
      • suttontom 2mo ago
        It seems so obvious that a non-tech company can benefit hugely from AI for their bespoke use case, especially if no one in the company knew how to write code pre-AI. But it's also easy to put some planks down across a stream and call it a bridge, that doesn't mean it's built well, going to last, or that there's no longer a need for structural engineers and architects.
        • dnautics 2mo ago
          good news, the ceo of this non tech company has years of experience as a competent sofware dev
• tehologist 2mo ago
  Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
  • teaearlgraycold 2mo ago
    Better to have a job you don't like that pays well than to have a job you don't like that pays poorly. But at the same time - if you're smart enough to program well enough to get paid while hating it it's such a shame to not find something you enjoy that will still pay you enough.
    • Aozora7 2mo ago
      I personally find that I hate any activity in a context where I'm paid for it.
      • teaearlgraycold 2mo ago
        Damn. I've definitely had jobs before where I'm legitimately excited when I go to sleep to do it in the morning.
• jmull 2mo ago
  A pretty weak essay. The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making. I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.
  • teache 2mo ago
    Those who know, do. Those that understand, teach.
• bluejay2387 2mo ago
  I agree, the whole 'developers don't code' AI defense was pretty ridiculous. I also concur that development is going to get a lot harder. Anyone that has successfully used AI coding tools knows that you can get massive productivity increases but now I have to figure out how to get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements. If you can do it, yeah you can get 10x results. But now I am engineering harnesses, architecture specifications, agent structures, statistically sampling, and formal verification systems to guide the code instead of writing the code.
  • maxrev17 2mo ago
    No one seems to mind the quality drop though. The buyers of this stuff could never discern.
    • jvanderbot 2mo ago
      You forgot "as long as" ... as long as the buyers could never discern
      • ryandrake 2mo ago
        The sad reality is that the vast majority of customers (whoever you are writing software for: clients, management, or end users) simply don't care as much about quality. If you give them the "time, cost, and quality" pick-two choice, 99.9% of customers are going to ask for fast+cheap. It's not the world I wish we were living in.
        • necovek 2mo ago
          This is why I believe true engineering art comes in actually marrying all three: build great quality quickly at reasonable (small) cost! If you need it to work for at least a month or two (instead of one and done, which some demoware is like). Following a few rules early on will ensure you can keep evolving it — even if it's MVP/demoware/whatever — as long as you know you need to evolve it soon after you build it!
• throwatdem12311 2mo ago
  Code generation was never the hard part. Knowing wtf you’re supposed to actually write was always much harder and this hasn’t changed. It’s not hard to write a loop or an if-statement. It’s hard to actually solve a problem with them at production scale. Carmack’s Fast Inverse Squareroot is not hard to write - it’s hard to figure out how to even do one in the first place. Writing it out is the easy part. Claude writes 90% of my code but the bottlenecks always were and still are: * getting clear requirements from product * getting the damn code reviewed so I can merge it Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hog wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing. No, using AI to automate code reviews is not acceptable. Code Review isn’t about a systematic checklist (though they can help) it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, getting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king. These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.
• Ozzie_osman 2mo ago
  Yes, writing code that (appears to) work was not the hard part. Even before LLMs you could find very cheap contractors on Upwork or through offshoring companies to write "code". Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.
  • bvcp 2mo ago
    customers very rarely have budget for the time it takes to produce well engineered code
    • tripleee 2mo ago
      And thus they end up paying even more for badly engineered code
• charcircuit 2mo ago
  The author's primary misunderstanding in my opinion is that time consuming is being conflated with hard. >If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves. >Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking. >Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy? Building software takes time and since velocity is important companies wanted people who could increase velocity. >If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it? So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program. If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius? The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program. >If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial? Again something being time consuming doesn't mean it was hard. >If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them? When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty. >If coding is easy, why is software so damn buggy? Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere. >If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers? People are clueless because it is hard. Pay is not based off of difficulty. >If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers? Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing. >If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for! Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature. >If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out? Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.
• overgard 2mo ago
  I guess my impression using these tools daily is that it hasn't diminished the need for my own technical expertise. The conversations I have with it are highly highly technical, and to me the insights come from both sides, I see things the LLM doesn't, and the LLM sees things I don't. It writes a lot of bugs that I have to spot, and writes designs that aren't correct. (This isn't a criticism, I do the same). I think the ideal world version of this stuff is complementary, but the current insane bubble economics mixed with the insane religious fervor make that unpalatable to the leading AI companies. (Like, I think Sam Altman said that anything below a trillion dollar IPO valuation is a "non-starter".) So, "nice coding tool", even if that's the BEST and most realistic outcome, is just not going to do it for them.
• chaps 2mo ago
  "Code was never the hard part" misses the point but so does this blog post. This blog post from 2011 is worth reading and really cuts into the middle of the dreads-of-programmer. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)
  • teaearlgraycold 2mo ago
    > There’s nothing wrong with this, by the way. You’re in the business of unemploying people. Occasionally I see a tech person in SV upset about AI automating away jobs. My dude, your whole job is to automate away jobs.
  • jdw64 2mo ago
    Good post!
  • Jach 2mo ago
    That patio11 post was good but you're overstating its relevance here by suggesting the thread's central topic is missing the point. The fizzbuzz part even undermines the "Code was never the hard part" message. If code was never hard, why has it always been so difficult to find talent that can do the most basic of tasks with code? Why was it considered a good average for programmers to only bang out 1000-2000 lines of code per year, measured by observing a team over 15 years, when it was well known even back in those days that skilled programmers could produce a lot more, and deliver even more business value quicker? Besides, there was a whole back-and-forth among multiple bloggers and comment sites (including here: https://news.ycombinator.com/item?id=3170766 https://news.ycombinator.com/item?id=3170766) from back then in response that agreed or disagreed with that patio11 post. Here's one: https://web.archive.org/web/20111126183459/http://www.jacquesmattheij.com/I+am+a+programmer https://web.archive.org/web/20111126183459/http://www.jacque... Here's another (though a couple years later): https://yosefk.com/blog/do-call-yourself-a-programmer-and-other-career-advice.html https://yosefk.com/blog/do-call-yourself-a-programmer-and-ot... From the second one's conclusion: > When I introduce myself, I usually call myself a programmer, regardless of my current work on chip architecture and management and stuff. I got into programming for the money, so it's not like I'm overflowing with pride when uttering "programmer". I just think programming is a great career and the right thing to call myself for me. > There's an alternative approach where you program, but you don't call it that, and you use programming as a starting point from which you transition to some form of being involved in business as directly as possible. > It sounds a bit roundabout to me – why not just get an MBA instead? – but maybe it's the right path for some (especially considering that some prestigious MBA programs want you to have industry experience before you can even enroll.) > The important thing is to choose the path that suits your preferences, follow it consistently, and realize where your approach is most likely to succeed. Because where I work, someone applying for a programming position and not calling himself a programmer will not make a good impression. Sometimes calling yourself a "Software Engineer", or focusing on "$X company revenue definitely attributed to my efforts" rather than the technical details, is the right thing to do. Sometimes it's not. In any case I'll continue explaining to outsiders that "software engineer" is mostly just a fancy term for "programmer", and to programmers to call themselves whatever they think will best give them a chance at working where, on what, and for how much money they desire.
• happytoexplain 2mo ago
  This is dishonest. Nobody said "coding is easy" in a void. They said "code isn't the hard part" - in the context of LLMs. The obvious implication being that the actual speed of writing code wasn't the bottleneck. The implication is not that it's easy to think of what to write, or that any of the other parts of coding are easy.
• phendrenad2 2mo ago
  It's more accurate to say "code was only the worst bottleneck in a multi-bottleneck system". The second-worst bottleneck has been promoted to first. And it might be only marginally better.
• jdw64 2mo ago
  No, code was always difficult. To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries. It's not that code wasn't difficult—it really was. In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small. Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied. The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult. In the end, whether coding was difficult or easy depends entirely on which layer you're working in. What's certain is that coding was difficult, and it still is.
  • skydhash 2mo ago
    If you’re struggling at formal thinking, coding will be hard for you. I’m not talking about designing software with higher concepts, like thread, network IPC, web application routing, gui,… but more simpler one like basic data structures (list, tree, maps, graphs,…), algorithms (search, sort, balancing trees,…), and paradigms (procedural, functional, oop, relational,…). I’ve met a lot of programmers where those concepts where only words and not something they have understood. A snippet of code is either something they have to learn or copy, it’s not something they can fluently manipulate. It’s the difference between having to use a dictionary and sample phrases and speaking the language fluently. The former is a chore, while you don’t even notice the latter.
    • jdw64 2mo ago
      I resonate with much of what you have pointed out, but I have a different perspective on certain parts. Software consists of various layers, and everyone has their own specific areas of strength. For instance, because I am an application programmer, I often need to write code that prevents the program from halting—aligning with recent programming trends that involve preserving the computation context using monads. In other words, my strengths lie in the overall architecture and interface design. This fundamentally relates to cohesion and coupling. I excel in this area, particularly when dealing with codebases around the 60,000-line mark. This is a realm where books like Clean Code are quite effective (many people dislike it, but it is actually a well-written book). Put differently, I possess the ability to mass-produce software (regardless of absolute quality). Over the course of 7 years, I have built CRUD applications for 43 companies across 16 different domains (ranging from drones and golf simulators to tax SaaS and supermarket POS systems). Therefore, I believe I have at least an average, solid capability in this regard. The primary area where I actually made money was PLC, so while I may not have deep academic expertise, I certainly do not think I lack capability. In Korea, the profession known as SI (System Integration) is a field where you enter contracts on a "project" basis. In that environment, I have encountered a wide variety of people. From those experiences, my takeaway is that programming is divided into quite several distinct layers. To speak of algorithms first: I learned basic algorithms and fundamental data structures in university. However, in the field where I worked, there were many people who struggled to implement those basic algorithms, yet they still built a large number of applications. Why is that? There was even someone who made an amount of money I could never dream of touching in my lifetime. Why did he make so much money when he didn't even know how to implement basic algorithms? The answer is quite simple. It is because the "implementation model" and the "contract and cost model" are different. The contract and cost model is a self-contained body of knowledge. It is the ability to know exactly where to fit a given piece into the puzzle. Implementation is simply the ability to build that piece from scratch. In fact, mostly due to issues like employee turnover and the organization's future maintenance capabilities, many teams (specifically, organizations with lower implementation capabilities) decide on an open-source library and design their architecture based on its API. In these cases, the primary technical challenge becomes how to connect those components based on the performance of that library. Yet, people tend to think that only those who can implement from scratch are capable of programming. A person who can take someone else's implementation and piece it together to fulfill their own contract is also a programmer, but people frequently forget this. Depending on which layer you exist in, certain knowledge requires you to implement it yourself, while other knowledge only requires you to understand the contract. I believe this is the core of programming. Those on the side that must design and build libraries or frameworks naturally have things they must know about implementation, as they are creating the SDKs. However, I have seen quite a few cases where these very people have no idea how their work is actually utilized in the upper layers. And these types of knowledge are highly fragmented. In my case, I am familiar with quite a few paradigms. On my personal homepage wiki, I can differentiate between OOP, DOD (Data-Oriented Design), and others, and in the context of relational databases, I know exactly where the ORM impedance mismatch occurs. However, this is largely an area intertwined with architecture, and its essence is closely linked to David Parnas's theory of information hiding. In other words: to what extent do we hide the internals, and where do we expose them to minimize the contact surface area and ensure a safe connection? For example, I can't implement PostgreSQL's B-tree. But I can design a business system using PostgreSQL. I only know the name of TCP congestion control—I don't know how to implement it. But I can build networked applications. That's what an 'industry' really is. The ability to trust the contracts of other people's implementations and assemble them. The ability to trust others. In that regard, I agree with many of your points. However, I actually believe the software industry needs more of those "average" people. I think the very definition of an "industry" should premise that average people can maintain their livelihoods simply by dedicating themselves to a single specific field. From that perspective, when building one's expertise within this fragmented landscape of knowledge, it is perfectly natural not to know much outside of your own specific layer. p.s https://www.makonea.com/en-US/casual/cargo-cult-programming-and-just-in-time-learning https://www.makonea.com/en-US/casual/cargo-cult-programming-...
• rufasterisco 2mo ago
  > I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho. Well, this is also an insult. Cleanest way I read this is seeing how basically none of it makes any sense for someone coding as a hobby, or in any non-business context. This is not an article about coding, it’s a promotional piece for business stakeholders.
• gaigalas 2mo ago
  > If deciding what to build is the hard part, why do so many product managers seem clueless? The divide between product managers and developers mimics the artificial divide between humanities and STEM. You divide workers into competing groups, then make they outperform each other. In reality, practically all humans can both become excellent coders and acquire deep product skills as well. We can also learn a wide variety of other skills in a single lifetime. The only blockers on that are social and psychological, you're meant to not believe that is possible. All this talk about code in this adversarial role with product comes from that, and all of it dissolves under almost any valid critical angle. The engagement with this kind of discussion takes place exclusively in that aforementioned social layer. TL;DR weak bait
• tikhonj 2mo ago
  Everybody saying "coding was never the hard part" is really telling on themselves. Coding was never "hard" because most organizations were absolutely unwilling to take on any technical work that was hard. That tells us about business strategy and culture rather than anything about the fundamentals of programming or technical work. The real conclusion is that programming is such a high-leverage activity that even technically trivial, low-quality programming is immensely valuable economically. That's not going anywhere, but maybe LLMs are going to make it all that much cheaper. (Which is mostly great! But I really don't look forward to the painful debugging and maintenance that reams of shit code will push down on programmers.) But also, there still is a ton of programming that is fundamentally difficult. That's not going anywhere either. And LLMs are useful there too, but they're currently nowhere near replacing the expertise needed to do novel and non-trivial technical work. In an ideal world, making mediocre code cheaper should leave more room for taking on harder technical challenges. In reality, this has always been dictated far more by non-technical factors—culture, leadership, trust, risk tolerance...—than by anything intrinsic to programming. But, at least for now, we can use the LLM hype to motivate the kind of deeper technical work that always made sense but was too uncertain or too open-ended or too long-term for non-technical leadership. And we should also drop the bullshit "code was never the hard part" framing.
  • pjmlp 2mo ago
    It is hardly any different from reviewing or debugging the code quality of most offshore deliveries.
    • deleted 2mo ago
      [deleted]
  • fragmede 2mo ago
    Those corporations that undertake the actually difficult bits of programming end up charging so much money, to the point that people go out of to not use them though. Splunk, Oracle Database, Spanner, Datadog, VMware. We don't live in an idealized world divorced from business and money, unfortunately, but worse, software developers are notoriously cheap and hard to sell to. If I did the hard work and made a compiler that generate code that runs 10% faster, I should have a solid business. Even Intel couldn't make a business out of icc though. So the code is the hard part but business is also the hard part and it's a miracle any of this stuff ever gets off the ground.
• peteforde 2mo ago
  I feel like you're getting hung up in semantics such that your essay doesn't say the obvious: coding is "easy" relative to confidently knowing how and what to do next at every stage. The comparison does not imply that coding is an easy thing to do, just that it's easier than being really, really good at the bigger picture. What Carmack did wasn't hard because writing C is hard.
• sunaurus 2mo ago
  Is it just me, or is this article arguing against a straw-man? Isn't the real argument that "writing code is not the hard part"? As in, reading and understanding is the hard part. Figuring out what and how to change is the hard part. Writing is the last 1% that happens after you have already finished the 99% of talking to people, figuring out what needs to be built, building up context about the codebase and surrounding infrastructure in your heard, planning the actual changes.
  • deleted 2mo ago
    [deleted]
• prinny_ 2mo ago
  I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers. Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment. There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
  • PunchyHamster 2mo ago
    I think it could be summed up with "it being easy part of the problem doesn't mean it is easy, just *easier than the rest"
  • mikojan 2mo ago
    > There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...] Why would they cover programming? That's what all the books on programming are for. Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard. You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
    • rcxdude 2mo ago
      A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though. And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.
• woodruffw 2mo ago
  It seems to me like two things can be (and are) true: programming can be hard in absolute terms, and is also the easy part of the thing that we call “software engineering.”
• raggi 2mo ago
  One of the strongest teams I worked with, working on an extremely large and ambitious project used to answer a lot of product/executive type questions regarding missing areas that we knew how to author and could safely assume general design consensus “it’s just typing”. It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus. I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author. As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.
• throwawayffffas 2mo ago
  Coding while definitely not easy, it was never the hard part. The hard part has always been how to solve x problem. Coding is the last piece of that part, which while not easy is not the hardest. The art of computer programming books are not about coding they are about computer science, i.e. figuring out how to compute solutions to problems. Figuring out what to build is definitely not the hard part though.
• desdenova 2mo ago
  Coding is not programming. Typing code is indeed not the hard part, programming is.
• rvz 2mo ago
  Maybe the author has a skill issue, as they conflated "software engineering" with "coding". It is all the parts of maintaining the software with time and engineering with all the moving parts (not the coding) is the point of why software engineering exists.
• BurningFrog 2mo ago
  Since not everyone seems to be familiar with human communication: The phrase "X is the hard part" means that X is the hardest part, not that all the other parts are easy.
• dofm 2mo ago
  Unpopular opinion: I fully believe that anyone who says "code was never the hard part" was an irresponsible coder who perhaps never had to work for themselves. No matter how long you spend on architecture, no matter how carefully you plan your features, if you are an actually good developer there are choices that emerge only from the first draft of the code — things that you could do better, broader ideas that suddenly emerge and change your view of your own work, abstractions that become possible once you internalise the project through writing it, realisations that a requirement is unscalable, unworkable or unsafe, etc. Nobody ever finds all those things only in the planning stage in any piece of code of consequential size or functionality: if it was easy, we'd all be doing waterfall development like 1970s consultants or using StP like 90s consultants, and none of those other ideas about coding would ever have emerged. LLMs will just write the code. They will never have the rest of that experience. And I think any coder who doesn't have a visceral feel for what I said above is just bad at it. "The code was never the hard part" is just edgelord AI evangelists masking denial with a pithy mantra. The code, its capabilities, the tooling choices, it's all indivisible from all the other hard parts. But then these are often also the people who think they can use AI song or image generators to do the bulk of the work and "add the finishing touches". They also think "taste is all that is left" when the thing that gets us paid is not just our taste, it's our responsibility for and to our work.
  • Toutouxc 2mo ago
    I think we should first define what “coding” is and whether “code” means “any code” or “optimal code”, because otherwise we’ll just keep talking past each other. But I enthusiastically agree with your point about engaging with your output and having that deep understanding of all the intricacies and, well, you already said it better. I also can’t shake the feeling that many hardcore LLM proponents are actually, genuinely worse at this than I am, and that’s simply it. In my vicinity, the loudest and most extreme LLM jockeys are all people who I personally don’t think are great engineers, or even that smart. They might be right in the end and I might be wrong, but these people definitely won’t become my role models anytime soon.
• BiraIgnacio 2mo ago
  I'm not insulted. I actually agree with that even when I was doing some more "hardcore" low level system programming. Figuring out what code to write and what not to write was always hard. The code would come out easier the more time I spent thinking and designing and talking about it with others. of course, YMMV
• PeterStuer 2mo ago
  Business has detested IT forever. It is basically considered blue collar work they felt held hostage to as it was 'brain' based instead of 'muscle' based, and it threathened to expose the grift of clueless "management" (not all is). They yried to placate with CTO, and l created tech diluted CIO and CISO titles for themselves, but the fear and loathing is as strong as ever.
• totallykvothe 2mo ago
  I don't think I've heard a lot of people say "code was never the hard part". I have heard "Code was never the bottleneck", which is a different thing altogether and is objectively true at my company. The bottlenecks were and still are integrations, QA, requirements refinement, coordination, etc.
• Frost1x 2mo ago
  To some degree the defense just popped up because it’s part of the AI effect, at least in my opinion: https://en.wikipedia.org/wiki/AI_effect https://en.wikipedia.org/wiki/AI_effect As computing systems become increasingly capable and encroach in our territory that distinguishes us and lead to our success as a species, intelligence (whatever that is or isn’t), we redefine the problem and handwave away the new capabilities. It’s getting increasingly more difficult to do that in knowledge domains with current frontier agentic systems. They’re not AGI, but they start to make it increasingly difficult to move the goal posts for many people’s comfort. We really need a lot more philosophers, sociologists, and frankly economists working on this problem: in an era where physical needs were mechanized away and increasingly aspects of the knowledge economy are shifting away, what does it look like in modernity? How do we sustain or adapt our current economic models? What new models may be needed? Do we need to continue to enforce this whole work to survive in an environment where much work is disappearing or at the very least shifting around. No, we’re not there yet. You still need experts to guide things around, but it’s becoming increasingly easier to do more in this space with less humans. That’s not a trivial change in the US where we put most our eggs in this whole knowledge economy basket.
• alentred 2mo ago
  Great article. Nice pragmatic and cool-head take on what is going on. Thank you for posting this. Side note: I so forgot about the "Don't make me think" book! Thanks for reminding this exists. I submit this should be part of "Software Development 101", right there alongside SICP.
• laughing_man 2mo ago
  Writing code to do a thing is easy. Writing code that's logical and easy to follow, that can be extended in several likely dimensions without major plumbing work, and that doesn't contain "gotchas" for the maintainer, is not at all easy.
• bloppe 2mo ago
  This is the kind of thing where everyone just talks past each other because "coding" can refer to a ton of different things. I think we've all had the experience of having to write large mechanical boilerplate or refractors which was definitely highly automatable coding. I think we've also all has the experience of being utterly dismayed at how hard it is to write certain logic, especially with LLM "assistance". I've spent the last couple days marveling at how consistently fable introduces race conditions into a complex state machine I'm maintaining. Coding can be hard, or easy sometimes
• makerdiety 2mo ago
  Then let the code monkeys be insulted then. Good riddance to the overpaid coders. And hello cheap replacements! The bottom line has improved. And that's good for business. Which was the only thing that mattered. Regardless of any reactionary sentimentalism.
• scoofy 2mo ago
  "The labor is valuable" is basically the refrain of every single laborer in every industrial revolution. The point isn't that labor isn't "valuable" it's that "value" here is a moral position. This same thesis could have been said about basically any mechanized industry. There is no putting the genie back in the bottle. You can't un-invent the nuclear bomb, or the printing press, or the steam engine. We need to find a politically stabilizing way forward, and that means we need political coalitions that don't consume themselves with infighting. Right now we can't even work together to build housing for young people... how the hell are we going to get through this mess without actually trying to build something bigger by making sacrifices.
• fantasizr 2mo ago
  whenever someone says this I assume they mean a crud react app which is a small part of what 'coding' encompasses
• thisisauserid 2mo ago
  Almost all of us would agree if this was just better articulated: "Code was never the hardest part." There you go. Doesn't imply that coding is easy.
• d0liver 2mo ago
  You seem to be misunderstanding the premise of the statement. Go write, "print 'foo';" and copy and paste that statement one hundred thousand times. Congratulations, you just wrote one hundred thousand lines of functioning code! Was that hard? No? Okay, so how is this different from other code? The difference is that it's easy to _understand_ how that code works, because it's the same behavior repeated over and over. So, writing code is easy, but understanding code is difficult! And, when we code with AI, undertanding is precisely the part that it can't handle, even though that's where almost all of the value is!
• dave_sid 2mo ago
  Coding is just a small part of a modern software engineers job. And some may think it isn’t the hardest part.
• wesselbindt 2mo ago
  > If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that. Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.
• poisonfountain 2mo ago
  >If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers? Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty well for this.
  • nunez 2mo ago
    Customer Success definitely doesn't get compensated what they're worth.
    • poisonfountain 2mo ago
      Sure, but not my point.
• Toutouxc 2mo ago
  It seems the author has misunderstood the point of the common narrative and has torn apart what’s essentially a strawman. The degrees, the books, that’s not the supposedly easy part. That’s the HARD PART, and it’s actually the “what you build” thing. What you build is the code architecture, knowing how to conjure objects, methods, modules, lambdas out of thin air in a way that faithfully represents a real-world problem. Literally the shape of the resulting code. It’s not product or CS. The easy part is supposed to be actually typing out the code, putting the methods together, remembering method names and syntax quirks.
  • electric_toucan 2mo ago
    I think a lot of the discourse around AI is imprecise, but you’ve done a good job of clarifying. AI is also changing the definition of some terms, so debates are happening where people use the same words, but mean very different things. Some people say “coding” to mean the process of converting a well-defined plan (requirements, architecture, everything) into executable code. Others use “coding” to also include all the small decisions you make when writing code, like the abstractions you build and how you handle ambiguous requirements. AI has decoupled “typing the code” from “making the decisions about what to type” because AI can generate code from very ambiguous prompts. So “coding was always the easy part” is meant to use the second definition and emphasize that you may be able to generate code, but having good decisions embedded in the code is still a difficult, unsolved problem with AI. There are also different definitions of “what to build” with some people meaning the technical details, as you’ve called out, and others (I think especially more business/product roles) meaning the functional requirements of the system.
• lowbloodsugar 2mo ago
  Good article if you read it all. > Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript. For most people sure. I’ve had GC kill a service in production, or even just tank p99. And I think a decade of C gives you a massive head start with rust. Less screaming “WTF WHY?” at the compiler anyway.
• to 2mo ago
  do you know how many eBay clones were out there after Ricardo? how many people built twitter clones? building the website was never the hard part, making people get to it and use it was always the costly and hard part. nobody talks about embedded device programming when they say code was never the hard part.
• kristopolous 2mo ago
  long said that success is 1% idea, 9% implementation and 90% other stuff like marketing that I don't care about.
• gagan2020 2mo ago
  He is right though Coding was hard for many. Farming was also hard, manual work wise and now machines overtook. It's still hard because of marginalization. It will happen to Coding, Consulting, Creating work, etc as well.
• hintymad 2mo ago
  > If deciding what to build is the hard part, why do so many product managers seem clueless? I'm not sure I follow the logic here. Wouldn't this mean that product design is hard? That said, yeah, coding is hard. I suspect that those who claim that coding is not hard are high-level ICs. For better or for worse, as the size of a company grows and as one's career progresses, engineers will often tranform to professional box drawers, expert meeting goers, seasoned report writers, fierce gatekeepers...Anything but deep coders. Over time, they lose touch of the actual building and think that any code can be handled by people under them. People like Jeff Dean, who still codes and optimizes things like TPU kernel code, is very rare.
• elendilm 2mo ago
  > If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out? Because it is hard. :). Writing good code - takes years of practice.
• codemog 2mo ago
  These comments reveal a stark reality: most HN commenters have never worked on a really hard problem. They think hard problems are leetcode hards that have a prescribed list of known techniques to apply. They think communication, alignment, gathering requirements, and other political bullshit is the hard part because they have never actually solved or had to grapple with a truly hard problem. That’s fine, but it shows the corporate programmer who is probably in meetings all day has a vastly different reality than those of us who have had to solve open problems with no solution written somewhere because there is none.
  • __MatrixMan__ 2mo ago
    Maybe the future has those as two different jobs re: hard problems. - The sorcerer: Have meetings with others until you know just how valuable a solution to this hard problem actually is, characterize it well, pool resources use cases and documentation, and then work with whatever wizard (or university thereof) is known to be able to solve that kind of problem. Have them find a solution to the hard problem and publish it. Use that publication as context, and have your LLMs integrate the solution. - The wizard: Find hard problems with adequate funding behind them. Solve them. Don't worry about stakeholders or integrations--the problems are hard enough on their own. It used to be we found ourselves jumping back and forth between sorcerer and wizard. But there are so many hard problems with solutions that are now in the training data for these models. A relevant skill for the sorcerer, besides the skills that are relevant in those meetings, is not solving hard problems head on, but being a sort of remixer of existing solutions to hard problems. I think this would actually be better, because more hard problems would get solved in the open where they can benefit everybody, rather than ending up as IP-shaped ammo for zero sum games.
  • jpleyden98 2mo ago
    Most useful software engineering work is doing fairly simple things and the numbers of people doing this work reflects that. > those of us who have had to solve open problems with no solution written somewhere because there is none. Probably because solving said 'truly hard problem' is niche with little or limited value as few people have tried to solve it (otherwise a solutions will likely have been written).
• xordon 2mo ago
  I agree with the author that coding is objectively "difficult" but this is something I am good at, while dealing with people, changing requirements, bureaucracy, and maintaining work relationships I find challenging. I always say coding is the easy part of the job (for me). The author's main thesis, that coding is hard, conflates what an individual finds easy or hard, with what is easy or hard for an average person.
• hintymad 2mo ago
  > Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.
• tegiddrone 2mo ago
  > Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy? Because companies resent that they have to take on risk and pay people to extract value from the market. Ugh, why do we have to pay people to code, maintenance, etc. Lets pay people to extract more value for our bonuses and shareholders. Lets try to only hire heavyweights so that we don't get hung up on that difficult-to-measure coding process, knowledge transfer, messy human-ness. Oooh how nice, we can hire a fewer employees that know how to leverage code agents that free them up to think about that what REALLY matters...
• throwitaway222 2mo ago
  Someone said this?
• ChicagoDave 2mo ago
  There is a half truth to code being the easier part. In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code. This has been around since the days of batch programming and evolved through domain driven design principles. The reality is the business can’t see that so they don’t invest in it and have no patience for it. Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster. Planning and modeling are the levers of complexity.
• dyauspitr 2mo ago
  Insult it one thing, it’s also not true in the slightest which is the bigger issue.
• austin-cheney 2mo ago
  Code was never the hard part I roll my eyes at this when thinking about the poor JavaScript developer that cannot write code without things like jquery or React. If code were so easy there wouldn’t be so much bloat and slow garbage in the world.
• robertlagrant 2mo ago
  This is a bit of a false dichotomy. The thing that isn't code (at least in some people's minds) isn't "requirements analysis". It's architecture, data modeling, deployment, inter/intra-team communication, triaging, prioritising, code reviewing, testing. It's all of software development, and not simply writing lines of code (which in itself can be hard of course.)
• PunchyHamster 2mo ago
  Don't get your panties in a twist over marketing slop selling AI to companies
  • keeda 2mo ago
    Hmm, hasn't "code was never the hard part" typically been said when downplaying the impact of AI-assisted coding, rather than highlighting it for marketing purposes?
• snickerbockers 2mo ago
  >If coding is easy, was Carmack just at the right place at the right time? Yes, it's fairly axiomic that he was "just at the right place at the right time" because there are dozens of modern "boomer shooters" on steam that are not nearly as successful as DOOM or Quake. You might counterargue that its always harder to do something thats never been done before but that would only be a tacit admission that coding actually was the easy part in that case.
• imoverclocked 2mo ago
  Code still is the hard part. Or at least one of them. Code, is written in a language. Language is opinionated. Things written in that language are also opinionated. LLMs often have horrible opinions.
• Waterluvian 2mo ago
  There’s too many dimensions to make broad claims like this and it always makes me wince a little. In my career code was the hard part for the first few years. Then I got over the hump and everything else about my job was harder. Today code is the easiest and least interesting part. But I’ve also experienced in 13 years maybe… I’m going to say 2% of the world of professional coding. I bet if tomorrow I was asked to do some kernel optimization or make Postgres better or reverse engineer an emulator for some PLC something something, I would be deep into a land where code is the hard part.
• HarHarVeryFunny 2mo ago
  The truth of that statement depends on what you consider as "coding". The way I would define it, coding is to software development as cutting is to open heart surgery. It is the final part of the process after 99% of the decision making and application of experience has already been done. There is still some craft or "surgical technique" to it, but the hard part was surely everything that came before (requirements, architecture, design, etc, etc) that got you to the point where all you had left was a bunch of classes and fully specced out modules (and implied test cases) to code up. I feel that some people, maybe including a lot of the people working at the AI companies, think that the software development job mostly consists of "coding", and perhaps in machine learning (not much code in an LLM!) it mostly does, but if you are a developer and define coding as the final "sit down and implement it" phase, then surely that is the easy part.
• kstenerud 2mo ago
  I've always taken it to mean "coding is the easiest part of a developer's job" That doesn't make it inherently easy, but it is the easiest part to automate. A modern LLM is perfectly capable of maintaining decent code quality and architecture (provided you ask for it) up to a few thousand lines of code, but after that it very quickly loses the plot if you're not designing your documentation right and keeping a hand on the architectural tiller. Architecture is about staving off chaos for as long as possible given the maximum functionality you expect it to achieve. That's hard enough for a human, with a deep understanding of your business, to do. Architectures that endure is a hard problem, dwarfing the difficulty of writing the actual code. Choosing what product to build is also a hard problem if you expect to meet any success. What it does, what it specifically doesn't do. Sounds easy on paper, and if all you're doing is Sunday prototypes it feels almost trivial. But once you're doing a real product with real consumers, it's a very different thing.
• theendisney 2mo ago
  The 8 hour work day was quite a victory but since it happened long ago i would really like to see how health and productivity in each occupation declines over time and by task. I expect not just the obvious jobs to have quite absurd numbers and vary a lot from person to person. One might imagine a gradually increasing hourly rate, a decreasing one or a combination of the two. Writing code i could probably do 2x an hour per day. Much respect for those who can do full days. If we imagine there to be roughly 500 defined occupations it seems quite doable to measure how "easy" coding really is.
• LAC-Tech 2mo ago
  The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming. I'm still not seeing it. I'm seeing a lot of loud people, a lot of LOC produced, and a lot of people angrily pointing to their sideprojects... but no massive impact outside our bubble. Remember it's 2026, we are 5 years into this hype, the models are better than ever, and all the software we used around us is basically in the state it would have been in had we projected 2021 tech 5 years into the future ("in 2026, there will be... another backend JS runtime!") I'm afraid all the personal anecdotes of technologists have not translated to real world results... other than negative ones like GitHub now having 0 9s of reliability. Of course I suppose I'm "coping", as if I wouldn't be over the moon if AI had made me 10x productive... but maybe, just maybe, a lot of people really like talking to chatbots?
• neya 2mo ago
  The "code was never the hard part" is a narrative pushed strongly by designers, MBA guys and product managers. Even before AI, they've always treated programmers like low-lives, someone beneath them and completely replaceable like commodity. Ironically, of this entire group, it isn't programmers that are being replaced left and right. Whole product teams, designers are being replaced. Good coders are still in demand - because, someone has to fix the vibe coded mess. In design, there is no reference for good and bad. You either like a design or not. In code, something either works or not. That's why it's always hard to replace a programmer as opposed to a designer. Has Claude code et al replaced programmers? Not really. And it will be a long time before it can - because someone needs to still instruct the direction of the code, the base architecture to build upon and that comes with real human experience.
  • ozgrakkurt 2mo ago
    IMO it goes both ways. Each side can look into how they see the other side to understand the psychology of the other side. Also I write good code and managers are thrash.
• JackSlateur 2mo ago
  Tech is not the issue, people are "If figuring out what to build is the hard part, why do so many product managers seem clueless" - because people "LLMs may be good at coding" - they are not;
• outside1234 2mo ago
  Microsoft did research on this and it was found that only 14% of time was writing code.* That 14% might have been hard, but it is definitely still the smallest part of being an engineer. * https://www.microsoft.com/en-us/research/wp-content/uploads/2024/11/Time-Warp-Developer-Productivity-Study.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
• jibal 2mo ago
  As a coder/programmer/programmer analyst/senior technical staff/software developer for over 60 years, I approve this message.
• nomilk 2mo ago
  > talking to users ... good code ... we should aim for both tl;dr nothing has changed.
• bvcp 2mo ago
  depends on the industry. but in consulting the hard part is dealing with customers who dont understand their own business and analysts who think writing software is rote factory work but somehow struggle to write a handful of coherent user stories not littered with subjective and ambiguous language these two groups are telling me my time is numbered because of llm and ai when in-fact im struggling to see how ai doesnt replace them both really good software engineers are expected to be experts in their job and that of the rest of the project team, these individuals are primed to be empowered by ai in a really disruptive way.
• bvcp 2mo ago
  interestingly ai has reignited the craft of performance and efficiency in programming. overall in the macro timeline i think the profession is going to be in a better place
• Madmallard 2mo ago
  Saying AI can do all the code isn't even accurate either though that's what's weird about all these takes As soon as the context builds up high it just starts doing things straight up wrong I've been trying to network a simple tactics game with AI and it just is a hydra of sync issues despite clear explanations of what they are and bug reports and desired end-states.
• nemothekid 2mo ago
  This feels like post-LLM coding romanticization. Before LLMs, people would regularly say stuff like "I could build this in a weekend" under a "Show HN" post. How many times have people said "I could build Twitter in a weekend". I've even found in a post-LLM world, that kind of language has only increased. When you are looking at something that already exists, where all the requirements are defined, when all the edge cases have been decided, then coding was the easy part. People didn't "burn out" because it was difficult to figure out how to write SQL. People "burned out" because the requirements constantly changed, demand was ever increasing, and edge cases were constantly being triggered. >If deciding what to build is the hard part, why do so many product managers seem clueless?Why aren't there rigorous 10-step interviews for them? Classic engineer type opinion where every else is dumb, except for him. So many people have come to see leetcoding as an intellectual badge of honor, when most of us know its cultural rigamarole and the code written on the job will rarely reflect the type of work that will done. I'm not saying coding is easy, plenty of people struggle with it. But as far as the job goes, unless you are a junior just grinding through JIRA tickets, coding was the easiest (and arguably the most rewarding) part of the job.
  • mawadev 2mo ago
    You are putting a lot of words and judgements into the authors mouth. Why exactly is it acceptable to not just do your role and expect the underlying requirements to be correct and measurable, especially when there are separate roles whose sole purpose is to do exactly that?
    • noman-land 2mo ago
      Because being a code monkey is getting devalued like crazy every hour that agentic coding improves in ability. If all you do is take well specified requirements and turn them into a piece of code you are going to lose your livelihood unless you can learn to do more than that or you're at the very top end of people who do that.
      • mawadev 2mo ago
        Getting the requirements did not work properly before, what makes you believe it is going to happen now?
• 0xbadcafebee 2mo ago
  Code really is the easiest part. That doesn't mean code is easy. It means everything is hard, and code is just the least hard part. The best programmer in the world will still create bugs. Therefore you need something else to account for and deal with the eventual bugs. In the rest of the engineering world, the way you do that is by standards bodies developing reliable, tested, certified methods to build things that avoid common problems. Pipes that are certified to a certain PSI or UV exposure. Wires certified to a certain amount of amperage, wetness, heat. Nails certified with a certain metal grade, tolerances. Those standard parts are then used in a certified building method for a specific application at specific usage criteria. 3x 12d nails in one kind of wood joint. Beams spaced 24" apart, with 3/4" CDX plywood spread load. You don't guess or follow trends. You don't do what you think is "clean" or "beautiful". You solely follow the engineering standards and code. Now you don't have to think much, and your results are highly reliable. The job becomes easy. Software doesn't have professional engineering and building standards like that. So humans literally just make this shit up as they go, making software however the zeitgeist of HN says "feels good". This results in unpredictable, unreliable software products that are hard to build because nobody agrees on the "right way". Somebody read a blog post, or a slogan or quip on a Wikipedia page, and decided on their own interpretation of how that generic advice would drive their work. Software engineers only talk to other software engineers, so they don't realize how incredibly unscientific, inefficient, unreliable, and difficult their work is. Trying to make something predictable and reliable is therefore very hard. Not because writing the code is hard, but because the entire software product lifecycle is basically vibes. The uncertainty, variability, and lack of reproducible standard parts makes figuring out how to build something become way more complicated than it should be. The actual lines of code are easy to read and write. But without the standards common to every other engineering discipline, the rest of the job is a slog.
• d--b 2mo ago
  Geez people. Sometimes coding is hard. There are two types of hard things: algorithms and architecture. LLMs are good at algorithms, not good at architecture. Most of the time coding is not very hard, it’s filling in the blanks, implementing the business logic, writing boilerplate code. LLMs are good at this too.
• Invictus0 2mo ago
  Too many people on hacker news sound like blacksmiths at the beginning of the industrial revolution. Get with the times, artisanal handwritten code is worthless
  • rightbyte 2mo ago
    Blacksmiths were petite bourgeois. We are not.
    • Invictus0 2mo ago
      idk what the point of a 5 word argument is but I'm going to assume you're talking about blacksmiths being business owners? most SWEs have equity as part of their compensation
      • rightbyte 2mo ago
        Yes something like that. Devs are in the position of apprentices and helper boys in the context of blacksmiths. Equity is mostly not handed out in a way that grants power but the opposite to tie the dev to the workplace. Some lottery tickets are winners though.
• willjp 2mo ago
  Agreed. "Code was never the hard part" is the dumbest thing I've ever heard. Making something work, has always been easier than making something someone can read. AIs also, seem to benefit from clean abstractions, appropriate code reuse, etc. (coincidentally, the thing they suck most at). It's the same thing with english, except that english doesn't have a compiler. Comprehension is the only measure of communication if you're talking about a human language. Programming shares the same goal. Both, often also need to do something else useful. Programming, and lawyering, have a lot more in common than people think. We're creating a culture of sh*tting on codebases so the highest paid execs can cash out when things get tough. It isn't a new phenomenon, but it's one we'll need to endure until enough people lose enough money that the accountants start taking notice and start saying "you should be more careful, or you'll lose your shirt". In the interim, the people that care are working insane hours to try to protect the things they believe in from inevitable doom, and risking being fired to do it. There is a balance to both sides, and the jury is out on whether or not anthropic/openai/alibaba can save us from the future we are creating now with short-term goals.
• fireflash38 2mo ago
  I think it can be pretty hard. It can be hard to find the right fit/abstractions. LLMs don't fix that though. I see some truly awful code come out of them. And no, it's not just better context or use more skillz.md.
• voidfunc 2mo ago
  Ive been doing this for enough time. Code is rarely the hard part. Code rarely matters at all in my career experience. Shipping a working service or product matters and theres a lot of ways you can get there. The upside of good code is usually in maintenance and extensibility but theres a limit to how much those matter in the grand scheme.
• deleted 2mo ago
  [deleted]
• 0x457 2mo ago
  I never had burnout from writing code; I had burnout from PM changing priorities every day or from tickets being half-baked. Also been burned out from being awakened that switch in somewhere in the Middle East had high CPU usage, which I was on call for for some reason (I wasn't on the network team, but that team didn't have bandwidth to be on call) Writing code is easy; that's why I do it as a hobby on weekends as well. I don't have to sit through five arch review meetings that talk about how we are going to name the class rather than what the API contract is supposed to be. Sure, writing good C is hard, and writing PHP (used to be) hard because language design is full of inconsistencies. There is so little "hard" code that I wrote for money. Plenty of somewhat harder things that I wrote for myself because it's entertaining. There was a time when I had to spend more time getting a pull request ready than actually writing code in that PR.
• pjmorris 2mo ago
  > If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? My take on that question is that programmers were in high demand because, for the last 60 or so years, it has been cheaper to write software for general purpose computers to automate things that were done by people and more rudimentary machines, e.g. accounting, manufacturing, music production, etc than it was to pay the people to continue doing those jobs. So, it continues a trend for programmers to be replaced by software, at least until something in the process breaks. At its core, there is something difficult about programming. Fred Brooks talked about the need for perfection, Don Knuth about there being about 1 in 50 persons who had the mindset for computer science. But we haven't really been paid because it's difficult, we've been paid because we're cheaper than the alternative.
• jongjong 2mo ago
  I think the statement "code was never the hard part" is true but it's relative. Programming is not easy and it takes years to master. Some people became really good at solving complex programming puzzles and 'Code Jams' and focused on it. Unfortunately, the same aspect which made this skill highly visible and highly praised, is what made it easiest to automate. All those medals, trophies and certificates... not the mention advantages at big tech software job interviews... Came at a cost. Meanwhile there is a whole group of people who have been honing their skills in software design, architecture, distributed systems, security and other less visible, less rewarded skills who have been ignored by the markets. These people still can't be automated. It's a large problem space so after a decade or two, the coding aspect feels small relative to all the theory and experience surrounding it. I met many senior people who didn't take programming seriously as a skill, long before LLMs. One time, when I was at university, one of my math lecturers was boasting about the superiority of math as a discipline and said to the class "Software engineers... There are no software engineers; they're programmers." That statement was never true but it's much more obvious now. The fact that a lot of people shared this belief highlights the fact that these other skills were invisible. There is probably as much engineering (if not more engineering) involved in delivering a complex, reliable software project as there is delivering a complex skyscraper project in civil engineering... It's the same kind of activity; lots of interdependent parts, each with their own constraints and requiring many decisions to be made with lots of tradeoffs. At least with a skyscraper, the customer requirements are relatively very stable.
• steelkilt 2mo ago
  It’s not that coding is easy. That misses the point. The point is, coding is recurrent. Automation follows recurrence, not ease.
• JKCalhoun 2mo ago
  Code was never the hard part… once you made it to some level of advanced programmer. Then clarity, maintainability, etc. became the next tier of Maslow's Hierarchy of Coding.
• lowsong 2mo ago
  I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. Then you have met many programmers but very few engineers. The kind that want to avoid thinking about the wider context and only be told what to do will never progress past a mid-level. By the time you get to staff+ it truly is never about the code, and there's a reason why staff+ salaries are an order of magnitude higher than mid-level ones.
• deleted 2mo ago
  [deleted]
• a3w 2mo ago
  Coding something for the second time is much easier. Therefore, coding is easier than some other tasks in software engineering. Getting the spec is usually the harder part, except if following the spec is for really complicated products, like "one does not simply rewrite VIM" shows.
• galaxyLogic 2mo ago
  Well it's easy to come up with code, not hard at all. But what kind of code? Does it work? And more importantly, can it be maintained and adjusted to evolving requirements? Coding is easy just like writing is easy. What makes the difference is what you write.
• agentultra 2mo ago
  The author might be missing the intent of the observation. Maybe they’re misinterpreting it. What I, and many people who’ve said, “code was never the hard part,” aren’t referring to the skill of an individual. It’s not the hard part of the engineering process of developing software. Programming languages have manuals. Many data structures are well documented. There are frameworks for damn near everything. While the difficulty of producing code varies by the skill of the programmer and the complexity of the problem domain; writing and understanding the code is a tractable and straight-forward problem. I can and have taught many people. People can learn. What most people are referring to is that the hardest parts of producing software are all the things an organization has to do in the production of it. It’s not writing the code that is the hardest part for an organization. It’s getting everyone to understand the problems, working together, gathering requirements, developing specifications, validating releases, testing, etc. It can often look like herding cats and is probably harder.
  • blub 2mo ago
    Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations. They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :) Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.
    • agentultra 2mo ago
      I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability. But these are skills that can be taught to individuals. But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder. Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization. What we’ve been delving into for the last decade has been a decline in the value of labour and work. “Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.
• kevwil 2mo ago
  To be fair, the use of absolutes like "never" is a red flag. If the statement were "code is often not the hardest part", that's certainly plausible and debatable depending on context. The implication that coding is easy is what's offensive.
• idan 2mo ago
  This post misses the point about what has changed. It's not that coding is or was easy, it's that coding is _more than typing code_. Typing is easy. Coding is hard. LLMs eliminate the typing and aid with all the other parts of writing code (where is the system that I want to mutate, how does it work today, debate the tradeoffs inherent in the potential plans of action). What remains after factoring out the typing and the time spent assembling an understanding of code is opportunity cost. That's not an insult any more than memory managers are an insult to languages like C.
• nikanj 2mo ago
  Insisting that code is the hard part is like insisting that spelling & grammar are the hard part of being a writer
• fHr 2mo ago
  Depends on what you work, if you optimize algos and low level stuff I think it's an insult if you're like 95% that have fairly easy issues and just juggle data around it isn't and code has never been the problem. Even now the issue where I work is the actual solid requirements and technical plan before the implementation. I move higher up to something like architecture/rm since AI coding is pretty decent and does the job.
• sitzkrieg 2mo ago
  i’d bet half of my normie programming career was spent capturing requirements, understanding the target domain problems etc for easy normal web development. once that is done code is a grocery list for 90% of it
• blub 2mo ago
  The software world has an abundance of mediocre coders that just happen to be good at writing e-mails, meetings, architecture (but not really), powerpoints, navigating customer requirements and product design. It’s in their interest to downplay coding skills. While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level. Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.
• bluegatty 2mo ago
  "If coding is easy, how come programmers were in high demand, and have demanded large salaries for years" It's like saying 'Lawyers write documents!' for their job ... no, that's just an artifact. Architecture, Systems, State, Integration, Algorithms, Pipelines, Platforms, Ops, Design, Communicating with other Eng, Working on a Team, Understanding Product/Product Marketing Requirements ... and of which the 'code' is just a small bit of the written part. Honestly ...
• ilovecake1984 2mo ago
  Typing up English language logic into code hasn’t been a job for 40 years. That’s what people mean by this.
• etothepii 2mo ago
  Nothing is ever hard that you've done 100 times before and know how to do. Creating documented step by step instructions that cover all or most eventualities is.
• al_borland 2mo ago
  It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities. A lot of people enjoy coding, it’s the rest of the job they don’t like. That’s why it feels hard. If a tool was going to come along and automate away a huge part of a programmer’s job, I think most would want that tool to eliminate the meetings, ambiguity, scope creep, and administrative work… not the coding itself. My best days at work were days with nothing on my calendar, when I could just put on some headphones and make something. At the end of the day I felt like I accomplished something and had something I could see and use to show for it; I finished the day happy and energized. Contrast that with a day full of meetings, fire drills, and busy work, where at the end of the day I’m mentally and emotionally drained, wondering if I should quit to stock shelves at the local grocery store. Which day sounds “harder”? I don’t know about where everyone else works, but defining the details of what to build seems so hard that no one actually does it, so it falls on us as we build things. During one project I got a directive from the CIO (which has only happened 1 time in 20 years) to get what I was working on done in 4 weeks. I made all the decisions myself when it came to the details and had something mostly working in 2 weeks (I skipped all meetings and any other distractions during this time). Several months later, the bureaucracy came into play. The principal architect on the project, who I never talked to before the CIO told me to get it done, finished his design and some details needed to be worked out. One such detail was a port list. It took 4+ months of meetings to get that done, and it still required constant tweaking after that for another year. There was a half dozen other things like that in the same project. So yeah, the initial code was pretty quick and fun to write, and then it was followed by 2-3 years of hell, that probably should have been worked out before we started coding. I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me. In most cases, I think the updated code is worse, as the bureaucratic design creates a lot of operational work that my original design avoided entirely, but I digress.
• CivBase 2mo ago
  > Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Programming used to be a rare skill. Not so much now. In fact, it hasn't been for well over a decade. My current employer started aggressively hiring for programmers in India in the early 2010s. They get paid a fraction of what our software engineers do in the US. There are many talented engineers in India, and those who get hired by us either find a way to come to the US for an enormous pay increase, or use us as a stepping stone to quickly find better work. And my employer is seemingly fine with this. They expect these cheap employees to do programming, not engineering. Programming may not necessarily be easy, but it is cheap. It has become a relatively common skill, driving down its market value. A lot of tech companies were slow to figure this out because times were good, interest was low, and investment was flowing. AI is waking people up to a truth that has been around for a while now.
• jeffaf 2mo ago
  Chainsaw isn't better than the lumberjack.
• purplemoonx 2mo ago
  No, it means you’re more than just syntax. And that if you make a bot that produces syntax you haven’t produced a programmer. Some workers are more 1:1 with syntax, like a developer from a gig platform or overseas contractor, the deliverable being code files. But the staff software engineer deliverable should be software, novel outputs, a face in meetings, someone to blame if it all goes wrong, a member to fill out the ranks, a person to get coffee with and talk about adjacent things that open new doors, in a sales capacity it might mean travel and interpersonal stuff like drinks and talks to convince people to integrate, it’s thoughtful often emotional back-and-forth from frustrated contributors on GitHub that lead to changes and innovations, and other things of value that language models can never do. I would say further that even if you model emotional intelligence, or the whole world even, unless AI has a face I can punch if it crosses some line and it knows it has a face, what its own face is and why that matters to itself, it will always fall short in terms of empathy. Our sense of empathy and emotion originated in the wilds among fear and terror and the thrill of catching and eating food, discovering others, and understanding the consequences of everything before me in this moment.
• dimgl 2mo ago
  > Code was never the hard part And yet I spent a majority of my career fixing mistakes, including my own
• stevekerr 2mo ago
  I like heuristics, but find broad statements are usually a bad idea in IT/Software. Developers in particular are very quick to find holes in logic. When I think of code, I like to compare it to old complex physical machines. Think automaton. If you zoom in enough, what you see is indeed somewhat simple. But zoom out and the answer changes. Then there is maintenance, manufacturing, tooling, etc. I suspect that as humans living in a physical world, we understand intuitively the vast knowledge and skills required to design and build different kinds of machines. Software tends to hide inside boxes that look similar, but are infinitely variable.
• greenyhuman 2mo ago
  [dead]
• YuukiJyoudai 2mo ago
  Well written. I completely agree with you.
• holyknight 2mo ago
  In which world are you living? For most programming jobs, the code is absolutely the easiest part of the whole thing, which is just gatekept into absurd bureaucracy and ceremony. Even if coding became 100x faster with 0 errors tomorrow, the software in most companies would still move at a snail's pace.
• plasticchris 2mo ago
  Shots fired
• efficax 2mo ago
  writing code is hard. building a successful product is harder, and is only sometimes a consequence of the code.
• theflyingelvis 2mo ago
  The real insult… “That’s a five minute change”
• Ozzie-D 2mo ago
  [flagged]
• travishcronin 2mo ago
  [dead]
• andai 2mo ago
  For me the hard part is remembering the "long tail" of the stuff I don't use long enough for my brain to consider it worth putting in the permastore. So I just spend a lot of time googling stuff I already "know" how to do, because the frequency is too low. It's not hard, it's just bloody annoying. And that's my favorite use of AI so far. Telling it what the code should do, and it translates that into language X's stdlib incantations. I also find this to be the optimal level of AI usage. If I let the AI run around the codebase doing other stuff, then I need to spend more time and energy later catching up. Whereas, if I stay "in the driver's seat", ask for tiny changes, and approve them manually, the mental model doesn't never gets desynced.
• dismalaf 2mo ago
  2010 - "Everyone can learn to code, come work at my startup." 2026 - "Coding was always hard, please don't lay me off."
• stefangordon 2mo ago
  In my experience the complexity of the coding challenges tackled correlates well with the talent of the engineers. It is uncommon to find engineers doing work they find trivial outside of some consulting niches.
• ChiperSoft 2mo ago
  At the start of my career I was being paid for the code I wrote. By the end of my career I was being paid for the code I didn't have to write. One of the nicest complements I ever got from a coworker was that he was astonished how much I accomplished with so little code. Everything I built was designed to be easily and quickly extensible with minimal changes, I planned my structure for future needs. That is why high paid programmers have been in demand, because learning that takes more than intelligence, it takes wisdom.
  • tripleee 2mo ago
    Right. The big misconception is that really good programmers just write code at 10x the speed of bad ones. Nope, the complete opposite in fact.
    • imron 2mo ago
      And what does this mean now that AI can write at 10x this speed again...
      • inigyou 2mo ago
        They're saying the 10x programmer is really using 0.5x the code but 20x as powerfully. The AI uses 10x the code 0.2x as powerfully. And code is a liability.
• gt0 2mo ago
  I think "Code was never the hardest part" is more fair. Code itself can absolutely be difficult, but it's seldom the most difficult part of a project. Generally the hard part is actually figuring out what you want, and how to achieve what you want, then the actual code is pretty straightforward in most cases. I've been programming since the the 1980s and I'm not insulted by the idea that code isn't the hard part.
  • __s 2mo ago
    Yes. I've also heard it said "code was never the bottleneck"
• p5v 2mo ago
  In my peak programming years in Germany, about 5-6 years ago, every company that ever tried to hire me, wanted to do some sort of CRM for xyz. It’s fun when you build it once, but then you change the domain, and realize you’re essentially building the same thing, but for different people. I’d gotten so bored of it all by 2020 that I’d approach them right away, asking “are you building yet another CRM for xyz?” They didn’t like it, because it would undermine their work. But it’s true - thousands of highly-educated, well-paid people in Munich at the time, were essentially paid to build and maintain glorified sheets software for managing people and resources. You can guess which companies and people were hit the hardest, when it turned out that all that software could eventually be generated by a machine.
• pranjalsd 2mo ago
  ya, it wasn't hard and that's why one of the highest paid jobs for decades
• esjeon 2mo ago
  By saying coding is the hard part, you're insulting all engineers. Edit: Although the current job market is heavily distorted, there used to be distinction b/w developer and engineer in the past. As the mainstream development model shifts from waterfall to iterative models, it became necessary for everyone to be engineering-capable -- only up to a certain point. So, every developer now carries a certain amount of engineering knowledge, but now they started to misunderstand and underestimate the value of engineering, and this is what you would get at the very end.
• tunesmith 2mo ago
  All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".
• nesarkvechnep 2mo ago
  I currently work on a glorified admin panel. The code should be the easy part. Unfortunately, the codebase is absolute trash. The code and the requirements are hard. My colleagues which drove the codebase to this miserable state think they’re developer extraordinaires. They don’t see the problems, at all. I can’t change anything and if I ask to be put on a different project I might be fired.
• ochronus 2mo ago
  The author is conflating coding with other parts of the sw engineer role.
• nurettin 2mo ago
  I mean, yeah, we are pretty trash without years of domain knowledge. But programmers do have a large domain. Some are experts at a/v, some security/networking, some like to make games/demos. These domains were highly accessible to us and still are. It's not like we solved coding exercises all day when we weren't leasing our souls to companies.
• yieldcrv 2mo ago
  > If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Programmers are the only[1] hired professionals that can compete directly or go off the market entirely in their own venture with either: A) nearly zero overhead costs B) can afford the overhead costs The compensation is to discourage programmers from doing so, make life comfortable enough for them to not want to bother with getting around IP assignments The major market of California barring and invalidating non compete clauses in case law, and strengthened by the legislature, also codifies this premium Make the software alchemist’s lives comfortable [1] feel free to find counterpoints, and what is their compensation like?
• torinhq 2mo ago
  [flagged]
• shahzaibmushtaq 2mo ago
  > "Code was never the hard part" It always comes out of the mouth of no-coders, vibe-coders and people who misunderstood coding.
• altern8 2mo ago
  Has been true my whole career as a freelance web developer. It's been mostly gathering requirements, trying to understand why something was getting build and chasing clients to get paid.
• classified 2mo ago
  > 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. Fully agreed. Nevertheless, I feel that the author took that “Code was never the hard part” way too personally and way too seriously. I think it's still a valid counterpoint to AI coding, even if it's very simplistic. If you look at the slop that LLMs spit out, then coding is still very much a hard part, for them at least.
• figassis 2mo ago
  I use this expression as well, but I think it has a different meaning when a programmer says it vs anyone else. In my pov, it is not the hard part because I have already mastered it to the point where it feels like breathing to me. So the next stage is simply how to build something that people want to pay for. So what I mean is I've moved on to challenge #2. When a random person says it, they mean it was never the hard part, learning it was never required and programmers have just been holding everyone hostage for decades and now AI came to reveal the truth that product had always been the hard part. Which, well, good luck. I think this has been the misunderstanding.
• 8by3 2mo ago
  Maybe "Code was never the hardest part" is more accurate. Code can be hard, though as others have said, 90% of code out there is crud apps plus forms. The other really hard part of getting people to do any complex work together.
• benfortuna 2mo ago
  > [..] developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder [..] lol, I hope most coders are not this jaded.
• ankurdhama 2mo ago
  Coding is the act of translating an algorithm or system design into a specific programming language/framework/libraries domain. That part was never the hard part as it was mostly about learning the syntax/conventions etc of that stack and then doing the translation. The hard part is about coming up with righ algorithms and system design for your particular software and evoling that over time without breaking it (the "evolving over time" part is the most tricky part).
  • oreoftw 2mo ago
    > That part was never the hard as it was mostly about learning the syntax/conventions etc of that stack and then doing the translation. Everything is hard until you’ve done it at least once. Making shit work is hard (excluding cases when your particular task has been solved and shared with you) If it was that easy I would never miss my ETAs.
• captainbland 2mo ago
  I think "code isn't the bottleneck" is often accurate though in organisations with high friction processes.
• 453yuh46 2mo ago
  >>“Code was never the hard part” It really depends on how that phrase has been used, as coding to me and to others was never hardest part - dealing with other BS however still is. I don't feel insulted at this expression at all, but it sure sounds like something that "modern audience" members would say, where it does not matter what you say, but how insulting it is perceived by others - by their definition and withing their limited scope of perception. >>If coding is easy, was Carmack just at the right place at the right time? Yes, coding here is not so much important as mathematics and algorithms and showman figure of John Carmack makes him more than just a coder that goes to recluse to do coding. The successful engine for DOOM and licensing it to other (lazy?) developers that did not want to make their own engine(or were unable to make their own) is comparable to success of coder known as Bil Gates(notoriously known by directed hate at him). Apart from those games, that were successful with DOOM engines, there were many that were not so successful and even failures, but those are not(and should not) attributed to success of DOOM engine. Not to mention, that there were also successful games that did not use DOOM engines, but it seems that it is hard to imagine such thing when new game developers only know and are using Unity nowadays... I enjoyed Sid Meyers and Jon Van Caneghem games more and I was spending more hours with Civilization and Heroes of Might and Magic games than Wolfenstein and DOOM. Also, as someone that was marveling at demoscene that was thriving at that time, it sounds like insult to think that gaming industry and coding as art was thriving only because of few people - it was a culture, where giants like IBM were molding it for decades. >>>Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript. LOL. When dealing with myths surviving from past you need to develop whole new mythology. If you fought memory bug once you don't need decades to deal with them repeatedly... also Rust clearly is not ready to be used to make games with "safe code". I would assume that you can make application made with Rust to slug your OS resources by intention as well - the fact that these things were done before unintentionally does not make much difference how language can be used. Python is not the best example as well, as wrong indentation can make your program behave in ways you did not expect and finding and correct that indentation can be a challenge if that indentation is not perceived as error by compiler - not a problem if you are only using Python as interpretative language with one line codes.
• frgturpwd 2mo ago
  A craft can be extremely hard while useful output from it is relatively easy to obtain. Case in point, I used to be a very serious baker. I mean, very serious. It started when I was a child. I made sure I understood things at a molecular level, cared about first principles, redid techniques thousands of times, spent hours on the craft in every axis imaginable. And yet people who baked ten times a year sometimes made better cookies than I did. A friend once made a better carrot cake than mine because she didn't waste time trying to figure out how to "bring depth to carrots." and the many ways of modifying textures. She just picked a very good recipe and had the tastebuds to know it's good enough to make for people. That didn't mean she understood baking better than I did. If something went wrong, I usually knew why and what to do about it. If someone gave me direction and wild requests, I could get us there, meanwhile she could not. If things didn't work out, her solution was more likely to be "find another recipe"... and finally, the part that "validates" the ego of bakers, if you looked at everything we both made, I'm sure mine was better on average. BUT... if what people actually value is "who made a great carrot cake tonight?", then yes, baking is easy. All she had to do was find a recipe detailed enough for her and apply it without majorly messing up. I think that's what the "coding was never the hard part" argument is getting at. The fact that programming has difficulty that people spend decades mastering it, or that the best programmers can do things ordinary programmers cannot does not tell you how much of that depth is actually required to produce the software people value. Which is, tbh, very little. Anyway, I could spread this analogy further but this is long as it is so I will stop here. It just reminded me of when people accused me of "just knowing how to pick a good recipe" as a way of reducing my development efforts, and it made me laugh.
• crabmusket 2mo ago
  I found this article interesting and valuable, and it's certainly started some great discussions in this thread. With one massive exception: the "There's no median programmer" section stuck out like a sore thumb. It seemed to be going out of its way to unload a bunch of chips from the author's shoulder about other developers in a way that... didn't really add any value? The title prepared me for a section about how actually, when we talk about software development, it's very risky to generalise. Instead I was mainly reminded of the Goomba fallacy. I think it's interesting to think about why software engineer compensation have looked different to management or product ownership compensation, but I also think trying to generalise suffers from the problem that... there's no median product manager.
• Gud 2mo ago
  > If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? high demand, low supply.
• blini-kot 2mo ago
  Isn't an insult really, just an argument about terms. "Code was never the hard part" in my opinion is more about the actual writing and making it compile and fit together. The hard part is one level above: figuring what to write, not only on the architectural level, but also implicitly during the writing itself. LLMs tackle a part of it, but not the whole problem, thus "the code was never the hard part" is about "how to make the already-present plan compile", not "knowing the system underneath is not hard actually" compare with something automotive: the process for changing an intake gasket and installing a turbo is roughly the same, but if you screw up the compression on your engine in the second case, you ruin everything - saying "installing was never the hard part" means that installation is the final step, however someone still might be upset, because he or she implicitly thinks "installing" means more than just the physical process of bolting the intake on. Is it an insult to all mechanics to say that "installing stuff was never the hard part"? No, because context here naturally points to a narrow definition which excludes cases requiring engineering, i.e. adding a part in a tight space, drilling the block to make a new auxilliary installed, machining a bracket etc
• daitangio 2mo ago
  I am still afraid of gen ai coding, and scared by its power. But I agree a lot with this article
• blitzar 2mo ago
  "Just learn to code" they said ...
• teleforce 2mo ago
  I truly believe that software industry in at the crossroads and need to adopt the best solutions for the quagmire it's in at the very moment and so called AI/LLM revolution mentioned in the OP article is only the tip of the iceberg problems [1]. Currently I'm reading the Software Wasteland and The Data-Centric Revolution books by software industry veteran Dave McComb [2],[3]. The books also addressed AI aspects but since it's published around 2018 before LLM, the information probably a bit dated on the issues. Hopefully the third book sequel in the trilogy can cover that aspect very well. Some key takeaways from [2]. 1) Almost all Enterprise Information Systems now cost vastly more to implement than they should 2) Most of the excess cost can be attributed to complexity 3) When you have hundreds or thousands of complex applications, you are completely stuck in what we call the Application Centric Quagmire 4) More large firms spend most of their IT budget on integration (without achieving more than ad hoc interfaces) 5) The fix is to become truly data-centric, where an integrated core model precedes the addition of functionality References: [1] A Tale of Two Projects: https://www.semanticarts.com/a-tale-of-two-projects-healthcare-gov-and-healthsherpa/ https://www.semanticarts.com/a-tale-of-two-projects-healthca... [2] Q&A on the Book Software Wasteland: https://www.infoq.com/articles/book-review-software-wasteland/ https://www.infoq.com/articles/book-review-software-wastelan... [3] Software Wasteland and The Data-Centric Revolution: https://technicspub.com/software_wasteland/ https://technicspub.com/software_wasteland/
• gum_wobble 2mo ago
  The stupidest part is that now we consider coding only the typing-on-the-keyboard act. Coding always included the “figuring out what to core” part. Developers were being called analysts back in the days
• erelong 2mo ago
  it's kind of like people talking about what makes a business successful: the idea or putting it in to practice some say ideas a "a dime a dozen"; the prevailing message that "code was never the hard part" is kind of the reverse of this In truth the top comment reports correctly that it probably varies from person to person; obviously for people working on intricate algorithms to solve cutting-edge problems, "code is the hard part"; for those who simply make use of existing algorithms like that but to maybe solve an existing problem for themselves or others, it's more about knowing that algorithm exists and making use of it and "code isn't the hard part" (for them) hence you can probably identify where code is and isn't the hard part with different pursuits
• armdave 2mo ago
  Given a well-defined set of requirements, writing correct code (pre 2026 LLMs) IS a hard task. There is only a small set of the population that, even after several years of training, can write correct code; this scarcity is what made coding one of the highest salaried professions. However, coding in itself generates no value to a business. A business makes money by solving its users' problems; coding is just one of the means to do so. This article is directionally correct (although a bit verbose) in adding that the best programmers did not ONLY write correct code, but also expanded their scope to understand how best to solve user problems.
  • ____mr____ 2mo ago
    > However, coding in itself generates no value to a business. A business makes money by solving its users' problems; coding is just one of the means to do so. Coding is the preferred means to solve many problems and the only means to some certain problems. How does it generate no value to a business when businesses are built on solving problem areas with code? What are you talking about?
• Sweetdevil144 2mo ago
  I think computer code is largely misunderstood by people as 'Python' and 'Javascript' because unlike some of us here, not everyone had to decide 'which language should we build this in?' I remember an year ago I was building a Version Control Database and i had to carefully opt out of python, Java etc. to choose Go due to dynamic concurrency control. Programming is not limited to building an "AI website" and believing 'Coding is the easy part', once you go beneath the iceberg and understand how Assembly interacts with different languages, what makes C faster than C++, how raw vector operations are more efficient that loop operations, then only a person understands the significance of this statement. This is more of a rant from my side, but I believe "Coding is the easy part, Programming and Designing an efficient system" is where true grasp of Programming is checked.
• pull_my_finger 2mo ago
  It's almost as if the business-side/idea-guy founders never really respected their tech co-founders/CTO's etc. The same people hyping up (beyond it's current due) AI are the business side that are a little too eager to dump what they thought was a necessary burden in "their" newest venture.
• jemiluv8 2mo ago
  This post misses a couple of points 1.”Writing software was never the hard part” - isn’t saying coding was easy. The comparison was against building a viable product. Doing business involves a whole lot more ambiguity than sitting in your room writing code. You could build anything and yet the hard part was building something that matters 2. >> Nobody knows how the AI revolution will play out in the end I disagree with this statement as far as Software Engineering is concerned. We kinda know. Everyone uses an agent harness to code this days - the only real difference is in how - and that still sets developers apart but most are using similar tools. This reads more and more like clickbait. Sorry. I always find posts like this outrageous but I suppose that was the author’s intent. Outrage will get you votes. Taking extreme positions in an argument will get you attention. Kuddos
  • jerhewet 2mo ago
    > Everyone uses an agent harness to code this days No we don't. I don't care what's at stake; I will never use spicy auto-complete.
    • jemiluv8 2mo ago
      Nearly everyone I suppose. There are always outliers I suppose. I’m going for 90%+ using llm in some capacity even if just a single ChatGPT prompt.
      • ____mr____ 2mo ago
        "just a single ChatGPT prompt" is quite far away from "everyone uses an agent harness"
• firemelt 2mo ago
  bro don't think in absolute, of course coding is easy like painting is easy everything have a floor and ceiling when coding is easy we talk about repetitive boring parts coding also could be hard its when you do with some square roots thingy and such
• firemelt 2mo ago
  bro is thinking in absolute everything have a ceiling and a floor when people said coding is easy of course they mean the easy repetitive and boring parts, like when making UI div, grid flexbox that is the easy part
• yawz 2mo ago
  First of all, I've only heard this from software engineers. Second of all, most of us haven't worked on the software that send people to space or similar. We unfortunately only move data from one place to another. People wrote production code after 6-months of boot camp. Writing code is easy. (Quality, scalability etc. are the harder parts). Part of this is captured with this famous quote: "The best minds of my generation are thinking about how to make people click ads." - Jeff Hammerbacher So the insult is probably to a negligible fraction of programmers.
• atoav 2mo ago
  Huh? I am a passionate programmer and I always say that code is not the hard part. And what that means is simple. Beginners in the field of programming will say things like: "Do you really understand what all this gibberish looking text means?". It is a bit like asking a sound engineer whether they really understand what all the knobs on their mixing console do. That is not the hard part, even it may look like that to the layperson. Understanding the knobs of an audio mixer or the syntax of one or many programming languages is not the hard part. The hard part is to know when to turn which knob, by how much and why.
• dennysora-main 2mo ago
  I've always hated that saying. It's like telling an artist that painting isn't the hardest part, coming up with the idea is.
• juliendorra 2mo ago
  If writing code is hard, how is it possible that so many kids learn it in a few months? I learned to program in basic at 9 with literally 2 books (no web back then), at 12 I was coding little programs in turbo Pascal, learnt with just the manual (it was a very good manual). I was not a genius. Granted it gets a certain type of mind to want to learn programming, but it’s far easier to learn than the pedestals it sits on (writing, reading, some maths and planning logic). Also code itself demands very few cultural background to start, hence why we have teenage dev genius but no teenage historian genius
• foxtrot8672 2mo ago
  coding was never the hard part...until today
• deterministic 2mo ago
  An excellent read. However, this part is wrong: > Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless. The world runs on C and C++, with billions of lines of code. That code isn't going away. And with AI, maintaining, debugging, and updating it is becoming much easier.
• highmastdon 2mo ago
  The things mentioned in the post aren’t code. That’s why code isn’t the hard part. Writing the algorithm to x y or z isn’t the hard part. Knowing that the algorithm is needed, it’s beneficial, there’s no alternative and the optimization isn’t in vein, that’s the hard part. Structure, design patterns, software architecture, systems engineering, optimization (not of the LoC but the system), data accessibility (in structure as in implementation like indexes etc)... those are the hard ones that require engineers to design and implement properly. And that’s only going to be more as it’s not the 20 medior SWEs that throw together a full stack application in two days but the untangling of AI slop as the architecture wasn’t built for hundreds of concurrent users
• dusted 2mo ago
  I think the author mistook the phrase a bit.. and there's nothing to be insulted about either.. "Coding was never the hard part" does not say coding is easy.. but that, in the context where this phrase is used, there are other things that are harder than coding. So, if you have some parts, and must pick THE hard part, then coding is not it. And honestly, I agree. There are more people who can write code, than who cannot. But among those who can write code, there are fewer that can build large, consistent, well-performing systems, or modify them while keeping them elegant. There are even fewer that can architect them or comprehend the nuances of that architecture. So, yes. It may be difficult to write code, but that difficult task often exists in a wider context, where even identifying what to write, and where, is orders of magnitude harder, and, it often requires you to not just be able to write code, but to read code very well, indeed well enough to build an internal model of the system which aligns enough with reality that you can decide where, what and HOW to write the code that must be written. And even harder to find the piece of code to delete instead of writing it, to fix the bug or achieve the desired result.
  • daymanstep 2mo ago
    > There are more people who can write code, than who cannot. Are you serious?
• MetroWind 2mo ago
  Well 99% of actual coding is just manual labor, nothing more. If that's not the case, either you are constantly at the cutting edge, which I cannot comment due to lack of experience, or your are constantly failing on the "engineering" part.
• smarm52 2mo ago
  That is an excellent rage-bait title.
• nellyt 2mo ago
  Perhaps it is an insult to some programmers, but not all. A lot of enterprise web systems are just CRUD with caching and a little bit of JavaScript. Modern frameworks take care of so much boilerplate that coding really is the easy part. I don't think its offensive to say that. My boss recently hired a vibe coder with zero experience in web development because he was an AI enthusiast and figured he could vibe code his way to success. He generated thousands of lines of code and presented pretty mockups giving the illusion of progress. But when push came to shove, he couldn't get the job done. He couldn't communicate clearly. He didn't know how to test or accept feedback. He didn't know how to manage expectations or scope creep (which was rampant). He was completely lacking the soft skills which are so often under appreciated in our industry. Frustrations boiled over and he quit in dramatic fashion. Later, my boss asked me what went wrong and I told him verbatim: "Code was never the hard part"
• GeorgeOldfield 2mo ago
  i think it's misunderstanding what people mean when they say that. i understand this as - bad code + good marketing == money. good code + bad marketing == no money. code isn't the bottleneck.