Live data from Hacker News

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

blog.senko.net

531–540 of 590 posts

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

#531

Earlier quoted context omitted.

You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these t…

These are called Fermi problems.

yup! And no SWE in the history of mankind that can code has lost an employment opportunity because of it.

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

#532
post #467
post #465

Earlier quoted context omitted.

In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?

In many, I am at least aware of Portugal, Germany and Canada. https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60... https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-... https://engineerscanada.ca/become-an-engineer/use-of-profess... You can call yourself engineer if you feel like it, however in case it comes to some court case due to liabilities and such, there might be some issues coming up with…

We laugh at people who call themselves swe, like you're a code monkey not anything near an engineer little man.

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

#533

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 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 agree that all those pieces are important, for sure. But it can all be undercut by a few for-loops that don't consider string re-allocations. That covers the "don't understand good code in the slightest, make big mistakes" side of things, but the other side is being able to think about the algorithm that is being run in your system (sometimes across multiple layers of code) and writing code that eeks out the highest performance from the system you're on in the programming language you're using. Also, to be clear, "the algorithm" here doesn't have to be super complicated or theoretical it can be as straightforward as assembling some data structure in response to a user's query across a few different sources. That process requires being able to write good code.

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

#534
post #445
post #353

Earlier quoted context omitted.

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.

This is such a tired take.

Aerospace engineers who build rockets do not have some certification body allowing them to be called engineers. Same with most electrical engineers working on almost everything.

If you think a government deciding who is an engineer is a *good* thing then maybe you should ask yourself why the United States which doesn't require this for the two non-software engineering disciplines has the best engineers in the world.

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

#535
post #467
post #465

Earlier quoted context omitted.

In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?

In many, I am at least aware of Portugal, Germany and Canada. https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60... https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-... https://engineerscanada.ca/become-an-engineer/use-of-profess... You can call yourself engineer if you feel like it, however in case it comes to some court case due to liabilities and such, there might be some issues coming up with…

European countries, historically known for their dominance in the field of software.

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

#536
post #465

Earlier quoted context omitted.

In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?

Before I retired (in the US) the organization I worked for was heavily civil engineering oriented, and they were pretty insistent that the computer folks not call themselves engineers. The state licensing board was pretty insistent too.

I think civil engineering is the main field in the US that relies on certifications/tests for FE/PE, there's probably more I'm unaware of though.

As I pointed out above though, aerospace engineers (working on rockets/space applications anyway, IDK about planes) and electrical engineers don't need those tests. Requiring it for CEs seems like a historical artifact more than anything.

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

#537
post #307

Earlier quoted context omitted.

No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software. Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc. The idea that code is mere transcription - which I see a lot in these AI discussions…

> but many details Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete. > Code is a form of low-level design and is where the rubber hits the road. Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to c…

Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely stood the test of time. Then ripgrep comes along, it has the same contract as grep (with I think a few inconsistencies that were intentionally tweaked for modern use-cases...and also I'm sure a few edge-cases from its design), but is significantly faster. The fundamental contract with the user stayed the same, I'm sure some of the design changed, but fundamentally the only difference is the underlying code. And that makes such a big difference that I *always* use ripgrep over grep now as do many others.

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

#538
post #353

Earlier quoted context omitted.

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.

Each unit of work in any given feature of a Web app has been implemented 500 times yesterday alone, and nearly each time exactly the same way. I mean that’s what programming basically is right? I’m surprised these patterns that are repeated so often by developers could have been/still be automated away even without AI/LLMs.

One thing I wonder about is how applicable your statement about web apps is to something like lamps or lighting generally. How many electrical engineers have re-designed a circuit that turns on/off a light? Are EEs who wind up doing mundane engineering like this still engineers?

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

#539

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…

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.

I did not mean to imply that consensus, stakeholder buy-in, and strategic direction are easy, or even that they are easier than writing good code. My point is just that the code part is not easy either. I think the article's point that "if good code was easy, we'd have amazing software everywhere instead of crappy software everywhere" is a very good one. The average code that gets written is horrendous, interviewing people who are presently employed and struggle to write a for-loop makes this really apparent.

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

#540

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…

> 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. I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement. In your framing, you're kin…

I think architecture is overemphasized a lot.

I am quite plainly talking about writing code that runs efficiently to support a wide-variety of tasks. To do that, one needs to write code that runs fast on your targeted platforms and is extensible/easy-to-modify (not necessarily the same thing to be clear).

We may have different definitions of "architecture" though, I tend to think of "architecture" at the system level, i.e. "this service handles these responsibilities, this other one handles these, they communicate with this interface/contract, etc". I can see how you could take the term "architecture" down to a lower level where you talk about classes/files passing information between each other too. I think to do that sort of lower-level architecture well though you basically need to write code in your design, even if it's just pseudocode.

Post reply on HN