Live data from Hacker News

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

blog.senko.net

281–290 of 590 posts

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

#281
post #266
post #205

Earlier quoted context omitted.

I've been programming for 30 years and "Code was never the hard part" does not offend me. It's something i've been saying for a long time. You can teach anyone the mechanics of coding well in like 6 months. Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution. Designing algorithms, architectures, etc can be done w…

Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do). Advice to job seekers I remember in the 2010s was to not call yourself a programmer be…

I have called myself a programmer for most of my career. I have no concern about prestige.

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

#282

Earlier quoted context omitted.

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?

Fun example I've had (some weeks ago), Agent completely dismissed the lack of strong consistency in our db system, this tiny bug would have caused a massive problem in the future. A bug that is not immediately obvious, no syntax error, logic is sound, works as expected on local and QA envs. But let it run in prod for 2 months and you have a massive problem. I'm not dismissing LLM's here btw, just pointing out that th…

Ouchy. That isn't as bad as the slop I've seen: one example I saw a few weeks ago from vibe-coded software had this absolutely mind-blowing bit of Rust code:

pub(crate) fn zeroed_safe() -> T { unsafe { std::mem::zeroed() } }

pub(crate) fn read_unaligned_safe(src: const T) -> T { unsafe { std::ptr::read_unaligned(src) } }

pub(crate) fn box_from_raw_safe(ptr: mut T) -> Box { unsafe { Box::from_raw(ptr) } }

pub(crate) fn isize_to_wndproc_safe(value: isize) -> WNDPROC { unsafe { Some(std::mem::transmute:: LRESULT, >(value)) } }

No, I'm not joking either, this is actual code that Claude wrote (and I'm pretty sure it's the latest models too but I don't actually know for certain, since the "dev" never specified). This idiom is repeated about 238 more times through that one file. I have tried repeatedly to help this person out but they're the kind of vibe-coder who thinks they know best, and who will take your advice and drop it into CLAUDE.md verbatim, and then Claude will go off and do the most literal interpretation of that text and not best practice.

To be clear, I don't hate LLMs. They're really useful for very specific things or where you know the domain very well. But then I see slop like this (and the dependency many people have on them -- I have literally heard my own close acquaintances say that they could not see themselves without a Claude subscription) and it really hammers home that software quality is not at all going to get better because of these things unless something changes.

Edit: grammar/spelling

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

#283
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.

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

#284

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 probl…

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.

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

#286
post #174
post #47

Earlier quoted context omitted.

> 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. That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is". IOW, writing code is hard in every reasonable context.

Speaking/writing English is easy. Writing literature at the level of Shakespeare is hard. Writing educational content that makes hard concepts accessible like Grant Sanderson is hard. Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.

> Likewise, coding is easy. It's just writing, and any child can learn it.

Any teacher of a low level CS course knows this is completely untrue. In my CS 101 course our problems were relatively straightforward and short, and lots of people struggled mightily to the point of dropping the course. IMO coding requires a particular way of thinking that a large subset of people just aren't good at, and as someone whose done tons of screening interviews at college recruiting fairs where I give relatively easy problems and ask someone to code a solution, I will tell you the idea that anyone can do it is just false.

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

#287
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.

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

#288
post #266

Earlier quoted context omitted.

Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do). Advice to job seekers I remember in the 2010s was to not call yourself a programmer be…

I have called myself a programmer for most of my career. I have no concern about prestige.

I think some people are talking past each other because programmer/programming means different things to different people.

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

#289
post #72

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 incred…

IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't ev…

I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
Post reply on HN