Live data from Hacker News

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

blog.senko.net

441–450 of 588 posts

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

#441
post #409

Earlier quoted context omitted.

English is a hard language to learn, especially as an adult. So many weird rules that everyone takes for granted.

No basic English is one of the simplest languages to learn as an adult. Perhaps it’s difficult to master. English has simple conjugations. That makes it much easier to learn to speak intelligibly even for adults. Old English dropped many of the complicated word endings because it was used by Anglo-Saxons with Vikings and Normans.

grammar and rules of language has almost nothing to do with the difficulty of writing good text (ala, written prose fit for purpose).

Understanding of grammar and rules of a language is like having good bricks, but building a stylish house is more than just using good bricks. It's a higher level cognitive exercise. Schools attempt to teach this, but i think they fail quite miserably (look at how essays had to be written by students, and how poorly most are written).

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

#442
post #282

Earlier quoted context omitted.

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…

JsonReader. CsvReader. JSON and CSV data fixtures. "Write tests," I said. "Use JSON fixtures, like the other tests," I directed. So it did:

    {
      "document": {
        "ElementA": "/home/username/project/valid-01.csv",
        "ElementB": "/home/username/project/valid-02.csv"
      }
    }
Then Opus had the audacity to couple the JsonReader to the CsvReader so that it could parse the CSV file contents during JSON parsing ... introducing at least five long-term maintenance issues along the way.

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

#443
post #437

Earlier quoted context omitted.

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…

> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.

I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said.

Anecdata time...

There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla.

The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win.

After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs.

The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent.

After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go.

Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.

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

#444
post #409

Earlier quoted context omitted.

English is a hard language to learn, especially as an adult. So many weird rules that everyone takes for granted.

Every language has it's specific difficulties as foreign, the French pronunciation, the Spanish speed, the Chinese ... well leave it. The English has the "easiest difficulty" among all: phrasal verbs, which are of moderate importance and can mostly be avoided.

The hardest part of learning English is the random way words are pronounced without almost any regard for their spelling.

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

#445
post #353

Earlier quoted context omitted.

> 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. On those complex systems in particular the problems start long before any code is written. A software engineer can create and understand the specs, requirements, design the system, architectural decisions,…

I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.

In the countries where Engineering is a professional title and not something people decide to call themselves, we still know the difference.

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

#447
post #113

Earlier quoted context omitted.

How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t. (In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)

Any coder with experience or ability imagines a world where software architects are regulated the way real architects are, and acts accordingly. I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use. For example, under what constraint regime should the cal…

In regards to (software) architects being regulated, the problem was always going to be that someone can jump in and build a "skyscraper" in their room/garage — and they have!

I honestly have failed to see the value of anyone wearing an official "Software Architect" hat in my 20 years of being in or leading high performing software development teams: yes, we built and maintained complex systems with multi-team dependencies, did that effectively and maintained and evolved them over time.

I've seen an Architect who is still doing the coding, but they are never available when you need them. I've seen an Architect who is always available, but so far removed from actual project that their advice is only somewhat worse (if they are good — or a lot worse if they are bad) than what a good senior in the team engineer or tech lead would offer. And an Architect who would happily design for the use cases that might come in 2 years (read never) using complex abstractions only they can understand, leading to decoupling of architectural pieces to 10 teams which could be built better by 1 or 2.

Do I want our industry to be regulated by these folk? No.

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

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

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

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

> Coding is not programming

Methinks you're splitting the wrong hair here.

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

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

Post reply on HN