Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.senko.net

Post reply on HN
Print view View original

571–580 of 590 posts

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

#571

Post by jhbadger »

zero_shift wrote: post #464
bramadityaw wrote: post #411

Earlier quoted context omitted.

> ...it's better to be a goat than a cow. That's the first time I've heard that idiom. What does it mean?

I made it up on the hoof (pun intended) Cows are the most common animal on the farm, and overall they produce the most value. But they are very replaceable. When times are bad, you slaughter them. Cows are like your rank-and-file application developers: you scale them up and down with the times. Goats are more niche. You don't have many of them on your farm. But they solve important problems (eating weeds), and they…

>so you seldom slaughter goats.

Maybe in Western culture, but a lot of cultures (Middle Eastern and Indian for example) really like goat meat and even raise them specifically for that.

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

#572

Post by munksbeer »

bayindirh wrote: post #251
ivanjermakov wrote: post #244

Earlier quoted context omitted.

I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Might be more about web backend than the whole field, but the challenge always comes from formulating requirements in a rigid form with all edge cases considered. This might be the reason why many personal projects are so technical and impressive - it's the itch…

This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for. Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise p…

> Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects.

I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure.

But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules.

You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part.

I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.

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

#573

Post by rightbyte »

Invictus0 wrote: post #526
rightbyte wrote: post #456

Earlier quoted context omitted.

Blacksmiths were petite bourgeois. We are not.

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

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.

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

#574

Post by lomase »

maxrev17 wrote: post #30
bluejay2387 wrote: post #25

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

No one seems to mind the quality drop though. The buyers of this stuff could never discern.

[dead]

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

#575

Post by agentultra »

satvikpendem wrote: post #392
hannofcart wrote: post #372

Earlier quoted context omitted.

If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above. And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above. Even much of…

Well, it's true. In a world where code is commoditized, a PM who knows exactly what the customers' needs are will be much more successful than an engineer who does not. Not sure what is controversial about that.

I think the controversial part is that an engineer cannot talk to or understand customers.

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

#576

Post by ____mr____ »

jemiluv8 wrote: post #546
jerhewet wrote: post #530

Earlier quoted context omitted.

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

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.

"just a single ChatGPT prompt" is quite far away from "everyone uses an agent harness"

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

#577

Post by ____mr____ »

armdave wrote: post #521

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

> 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?

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

#578

Post by bayindirh »

munksbeer wrote: post #572
bayindirh wrote: post #251

Earlier quoted context omitted.

This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for. Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise p…

> Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for st…

> I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.

This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high performance programming in Boundary Element Method space.

The knowledge is not novel, but the formulae is. We developed the math, not optimized something already out there. Moreover, we had to optimize to the hardware architecture we had. This means tons of runs, profiles, optimizations, and even more runs.

There are some bottlenecks here. You can't make profiling faster since you're already going flat out. Memory bandwidth, processor's internal pipelines, load and store units are completely saturated. Perf returns numbers close to theoretical maximums, the systems are running at TDP limits, you're done. AI can't make it faster.

Developing the math, chopping the formula and sprinkling at different levels of the loop to minimize step count to use what you have at hand becomes important. You also check modeling accuracy here, testing around 32 significant digits precision, again takes time.

If you're changing processor architectures, load/store widths change; pipelining behavior change, memory bandwidth per core, NUMA structure change. You have to fine tune here and there to get the same efficiency from a different core.

So, method is not the bottleneck, but the novelty of the problem and method and runtime is. When testing engineering stuff precision and accuracy both matters, and seeing tradeoffs take time.

When there's nothing to draw from, maybe AI can point out blaring issues, but without running the code and seeing it for yourself, you can't reach to the point where you need to go.

For the "codification of it" part, humans have something called intuition which is a kind of tacit knowledge which shows us the way based on a wide network of knowledge. It's not easy to surface, define, codify and transfer. That knowledge esp. helps when systems act contrary to guesswork and rules break in myriad of ways. "Having a feeling of the machine" is only possible with experience, and can't be codified and transferred easily. This is why we have master/apprentice model and why it's so important in transferring knowledge.

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

#579

Post by munksbeer »

bayindirh wrote: post #578
munksbeer wrote: post #572

Earlier quoted context omitted.

> Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for st…

> I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules. This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high perfor…

Thank you for writing that. It's a good example.

I think 99.999% of all coding/engineering is not like this example though.

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

#580

Post by bayindirh »

munksbeer wrote: post #579
bayindirh wrote: post #578

Earlier quoted context omitted.

> I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules. This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high perfor…

Thank you for writing that. It's a good example. I think 99.999% of all coding/engineering is not like this example though.

> I think 99.999% of all coding/engineering is not like this example though.

No, it's certainly not. Even for really high-utilty personal projects, what you do, esp. when you compare to the previous example, is extremely simple. Some parsing here, some SQL there, a HTTP POST somewhere else.

Unless you're rendering something, developing a custom, binary file format, talking with the hardware, or doing something extreme like I have given in the example, most programming is very similar. Re-organizations of the very same building blocks.

Post reply on HN