Live data from Hacker News

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

blog.senko.net

211–220 of 553 posts

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

#211
post #205
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…

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…

I don't even sit in front of a computer to write programs, I do that in the car.

I type them in when I'm in front of the computer.

All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.

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

#212
post #9

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

I'm beginning to wonder if a lot of commenters have forgotten that waterfall is a failed methodology in part because you can't always just gather requirements by say introspection or interrogating the customer for them. In order to reveal the true, accurate requirements, you often need to write code. Not always, sure, just like some code is relatively easy to write, some requirements are easy to both accurately specify ahead of time and even satisfy. (An old XKCD hinting at this distinction: https://xkcd.com/1425/ Only nowadays we actually can easily satisfy a lot more of those old easy-to-specify-difficult-if-not-impossible-to-satisfy requirements. That's the way progress in the field often goes.) Decades of startups support the iterative approach, along with pivoting, the successful ones learning the lessons of writing less committal code and discovering requirements iteratively. And it's hard to actually pull that off -- so many companies have gone under or lost out significantly to competitors because they couldn't write code fast enough, or change code fast enough, either with the goal of discovering the real requirements or adequately satisfying those requirements once known. Code is hard in general.

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

#213
post #95

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

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.

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

#214
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 even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.

If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.

All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.

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

#215
post #73

Earlier quoted context omitted.

Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.

Coding just often has a fast feedback loop. If you can't do it people are going to notice pretty fast. You can fail as an architect or prod management for a long time before people discover you are not good at it. One thing that is good to have in all those positions is an understanding of the code base and where it can slowly evolve to and how that positions the code base best in the market. I'd say the best way to…

Yup you'd fail fast because you could not at the time bullshit and handwave the computer. When you don't do the implementation work itself your sloppiness is mostly the concern and inconvenience of implementors. And I concur the best way to understand the system is through the code, and the best way to understand the code is to write it.

We aren't going to understand the systems we whackchitect from now on. It's the endless prodding and begging instead, something that makes me infinitely sad.

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

#216

Earlier quoted context omitted.

You forgot "as long as" ... as long as the buyers could never discern

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.

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!

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

#217
post #205
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…

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…

the article means code as a whole not just the moment you input some if else in a screen but the whole act from thinking about it to make it live in prod.

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

#218

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.

I suspect the massive shitshow of Windows 11 and all of its failings is a result of large quantities of vibe code being merged into the OS. People are noticing.

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

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

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

#220

Earlier quoted context omitted.

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

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.

"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.
Post reply on HN