> I have come to understand that there are two kinds of people, those who do things only if it helps them achieve a goal, and those who do things just because.
I think in this age of vibe coding where anyone can code anything, the discriminating factor between two developers, at a technical level, just comes down to "good taste" (lots of other more important factors, too, like a good human to work with).
And like the author, I agree that taste is acquired through tinkering and trying to be able to discern the qualities of one approach or one design over another. You can't have good taste in anything without having tried lots of variants in that domain -- wine, sushi, furniture, color, style, etc. Having this quality now is more important than ever for senior devs and mid-level devs that want to reach the next level.
When anyone can vibe code, it is the ones with "good taste" in the design of systems that will thrive. Anyone can use an agent and code fast; few will be able to do it fast and well and build systems that do not eventually collapse under the weight of their own tangled mess.
How to acquire it? Have a folder called `sandbox` and just build small projects in there and try new ideas, new techniques, new libraries you come across. Used a particularly interesting package? Go check out the GitHub repo and see how they did it; learn something new. Good taste can be acquired; it just surprises me how few devs actually care to seek it.
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.
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.
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.
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.
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.
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).
How do you deal with issues and feature requests? I used to put stuff on github, but nowadays I keep one off things mostly to myself. I don't want to do any support to strangers for things I have no interest in.
> When anyone can vibe code, it is the ones with "good taste" in the design of systems that will thrive. Anyone can use an agent and code fast; few will be able to do it fast and well and build systems that do not eventually collapse under the weight of their own tangled mess.
“He didn’t process information in any conventional sense. He didn’t read. He didn’t really even skim. Some believed that for all practical purposes he was no more than semi-literate.”
I think that's a sign of senility more than anything else. There's been articles which show clips of his speech in the 1980s and 1990s. His vocabulary was much more extensive, and he used more complex sentences than the word salad he spews out these days.
And like the author, I agree that taste is acquired through tinkering and trying to be able to discern the qualities of one approach or one design over another. You can't have good taste in anything without having tried lots of variants in that domain -- wine, sushi, furniture, color, style, etc. Having this quality now is more important than ever for senior devs and mid-level devs that want to reach the next level.
When anyone can vibe code, it is the ones with "good taste" in the design of systems that will thrive. Anyone can use an agent and code fast; few will be able to do it fast and well and build systems that do not eventually collapse under the weight of their own tangled mess.
How to acquire it? Have a folder called `sandbox` and just build small projects in there and try new ideas, new techniques, new libraries you come across. Used a particularly interesting package? Go check out the GitHub repo and see how they did it; learn something new. Good taste can be acquired; it just surprises me how few devs actually care to seek it.