Hacker News Reader

Comment by mberning | Hacker News Reader

Having a distinctive style is also going to become increasingly rare in the age of LLMs. I see it with people at work already. They have no style. They learn very little. They get something to work but have no ability to discern whether it is a “good way” of doing it or simply “a way” of doing it. They have little interest in how or why things are built. I get the sense that they have little or no enjoyment or interest in deep understanding.

As a concrete example I just reviewed a PR for a feature that someone wanted to add to a flask app. It had a ton of terraform code, an aws api gateway, a lambda, etc. then on the flask app frontend they added a page with a call to this new API. I asked why they didn’t just add a route to the flask app. Blank stare response.

View on HN

The Daily WTF is going to enter a new era soon.

(For those not familiar https://thedailywtf.com/)

I know exactly that blank stare response.

Very sad to me because the building and solving puzzles is the fun part.

Distinctive style is actually bad. You want your code to be uniform, readers should not be unable to tell who wrote what.

Otherwise you run into the danger of having parts that are peculiar and or obscure to everyone except the one who wrote them. That's if you are lucky, if you are unlucky the person who wrote them won't be able to decode them either.

A drive to simplicity and elegance can be a distinctive style.

I wouldn't get caught up in the word "distinctive" to the detriment of losing the larger point about creators being thoughtful and opinionated.

Simplicity is the most underrated attribute of a well-designed system.

There is a tendency for smart people to want to build complex solutions when often, the best solution is one that simple.

We had a dev recently write a whole source generation library to verify configuration at application startup. I pointed out that it would only save -- at most -- 14ms over a reflection based approach and that our application at startup is rolling over nodes in K8s and not a serverless function where cold starts matter.

It went from a 1600 line PR to a 60 line PR.

Obviously there’s a line to draw somewhere so that your code doesn’t end up looking like a YouTube comment section or have half of its API with Spanish names. And if by style you mean that overly “clever” or dense code without detailed comments and formatting for readability ought to made digestible by those who lack context about the why/what of it, or that “dangerous” or unsafe practices like rust’s unsafe/python’s exec/C++ UB ought to be only permitted in exceptional situations, sure.

Everything else is so inconsequential that it truly pains me to see people spending hundreds or even thousands of dollars of their time having to indent, comment, or space things in a certain way just to get CI to pass or merge a PR.

I don’t give a fuck that Jeff wants to use 4-space tabs and I cannot tell you how much I resent spending tens of thousands of dollars of Google’s time pleasing the fucking Go linter or trying to figure out errors like “ERROR: const/var” that I can’t turn off because some master artisan truly finds it meaningful and important to make me declare const blocks before var blocks, and their OCPD and fulltime bikeshedding is more important than whatever actual work I’m trying to do to get them paid.

> Everything else is so inconsequential that it truly pains me to see people spending hundreds or even thousands of dollars of their time having to indent, comment, or space things in a certain way just to get CI to pass or merge a PR.

I generally agree with that sentiment, but the solution is to use automated formatting and lint fixing.

I as a mostly python developer have my gripe with mypy. The powers that be decided all code must pass mypy which means I have to spend hours of their money typing out trivially inferable types because myph can't infer the type of the empty dictionary I just defined when just two lines below I proceed to initialize it. Or it can't infer the return type of my function that returns true in half the return statements and false in the others.

If I wanted to write down types I would use another language. And if I didn't want duck typing I would write somekind of ML. In short I would never write out the types because that's compiler work. But nooooo All the cool kids use mypy and typescript so we have to as well.

You say that, but sufficiently advanced automated formatting and fixing can be its own kind of footgun. The unsung heroes behind making absolutely sure my code passed Go linting also enabled an automatic formatter that would constantly remove imports immediately after adding them, because they were now imported and not used.

However a normal person might actually handle auto formatting in their CICD still requires spending a decent amount of upfront time and ongoing maintenance on running scripts/containers that convert true tabs into 4-spaces tabs. Most of the time, anything that’s fully automatically formattable into something that passes linting is so trivially superficial like reordering or replacing or spacing out things, so if it’s necessary for anything more important than that I’d be questioning things.

I can actually see value in encouraging explicit types for most of the kind of stuff I work on, but I’d never choose Python for them to begin with because of that. LLMs make some of this stuff a lot easier to handle in one shot, but the ceremony and constant implication that you can’t be trusted to good work without being forced to wear a monkey backpack with a leash just wear you down when you run into them consistently over long periods of time.

I think you're conflating the look and feel of the website/app with the code itself

I don't think so, the parent is taking about the code.

Within a module, yes. But it's ok for one module to be different from another because, you know, they are different modules that do different things (the difficult part is deciding what level your modules are split at, of course).

"Style" here isn't about "formatting"; it's about construction and technique.

I'm kind of confused by your post, as if you didn't read your parent poster at all and wanted to use the chance to write a lecture about CS101 concepts. Can you explain how your uniform code argument fits in at all with their example of introducing multiple other system components in a PR because they lacked the knowledge to add it in the correct area? Every piece of code they brought to that PR could have followed a uniform standard and still be considered a failure at understanding proper system architecture for their app, which is the discussion everyone else is actually having.

Reply on news.ycombinator.com