Good taste in software engineering refers to the ability to make design decisions that are simple, intuitive, and maintainable. It involves having a deep understanding of the problem domain and being able to craft solutions that are elegant and efficient. Developers with good taste can balance complexity with simplicity, avoiding unnecessary abstractions or over-engineering.

What is 'good taste' in software engineering?

lofties

3 months ago

1 reply

Good taste, is what I like and advocate for. Bad taste, is the opposite.

actionfromafar

3 months ago

1 reply

You never advocated for something you agree is a huge kludge? :)

autonomousErwin

3 months ago

I think first step of having good taste is admitting that you probably have bad taste

OtherShrezzing

3 months ago

1 reply

> One interesting consequence of this is that engineers with bad taste are like broken compasses. If you’re in the right spot, a broken compass will still point north. It’s only when you start moving around that the broken compass will steer you wrong. Likewise, many engineers with bad taste can be quite effective in the particular niche where their preferences line up with what the project needs.

This paragraph really gets to the idea of why I think discussing someone’s taste is basically useless in an engineering context. This “predictably broken compass” person stands out like a sore thumb, and you can just hold a 20min behavioural interview to filter them out.

A far more dangerous engineer is the “partially broken compass”, which appears at first sight to be working because it spins around like you’d expect, but is actually 127degrees off at all times.

medstrom

3 months ago

2 replies

Can you paint an example of a "partially broken compass" engineer?

maccard

3 months ago

2 replies

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like

    func isEven(s string) bool {
        num, _ := strconv.Atoi(s)
        return num % 2 == 0
    }

becomes:

    func isEven(s string) (string, error) {
        f, err := strconv.ParseFloat(s, 64)

        if err != nil {
            return "invalid", err
        }
        num := int(f)
        if num%2 == 0 {
            return "even", nil
        }
        else if num % 2 != 0 {
            return "odd", nil
        }
        return "invalid", nil
    }

Which is.... technically correct, instead of

    func isEven(num int) bool {
        return num % 2 == 0
    }
    func isEvenSafe(s string) (bool, error) {
        num, err := strconv.Atoi(s)
        if err != nil {
            return false, err
        }
        return isEven(num), nil
    }

Zanfa

3 months ago

I’ve definitely seen way too much code like the examples above. Another side effect to this is it tends to leak all over and can result in exponentially more code. What would’ve been a 2-line change at the API boundary, becomes ten lines of manual edgecasing every time it’s used in business logic and results in impossible states that need even further typing and handling. And don’t forget the tests that now need to cover invalid inputs everywhere, not just the API boundary.

skydhash

3 months ago

Also the ones that can’t understand abstraction and are happy copy-pasters. Or the ones familiar with some paradigms (ex OOP) that brings it everywhere.

There are a lot of ways to accumulate tech debt so fast you’d think you’re in a code casino.

DavidPiper

3 months ago

OP may be talking about cargo culting, but it actually just triggered two examples in my mind:

1. Someone who has only ever written code by tutorial, and has no idea of the architecture, performance considerations or usability implications of the code they're writing.

2. Someone who has got to a point in their career LLM Coding and is unable to write code without it because they don't understand what they're doing.

The problem occurs when one of these people:

- Is required to be good at the things they are not yet

- Proceeds as they always have because they are unaware of their skill gap

- (Optionally) gets promoted while things are still _just_ working

IME you hit these silent inflection points as a system begins to scale beyond the experience of the people involved. They survive for a while (Coyote time / the compass is still pointing north) until something happens (the whole thing falls off a cliff / starts to go south).

foofoo12

3 months ago

2 replies

Tabs instead of spaces.

cake-rusk

3 months ago

3 replies

Spaces have won already. It is the default setting across code editors now.

000ooo000

3 months ago

If your code editor told you to use PHP, would you?

foofoo12

3 months ago

Would that mean it's good taste?

sparkie

3 months ago

Elastic tabstops are good taste. Tabs should tabulate.

But limited editor support, and some implementations have poor performance.

https://nick-gravgaard.com/elastic-tabstops/

aitchnyu

3 months ago

2 replies

One user is able to fit more code into LLM context window since tabs take one token and spaces take 4.

https://old.reddit.com/r/ChatGPTCoding/comments/15s62yl/save...

zahlman

3 months ago

Did these systems really not learn to recognize a run of four spaces as a single token, despite all the Python source code fed to them?

cap11235

3 months ago

For one tokenizer, a couple years ago.

gyulai

3 months ago

6 replies

Lecturing on "good taste" is a huge red flag for narcissism. "Taste" implies subjectivity. Pairing it with "good" is presupposing something along the lines of "my subjective evaluation of things is superior to yours", or "my subjective choices are superior to yours".

antirez

3 months ago

1 reply

That's exactly how it works in most fields that are not purely engineering but where the space of design solutions to do X is huge. Architecture, software development, ...

gyulai

3 months ago

2 replies

If I correctly catch the drift of your argument, you're saying “engineering is objective”, so there is such a thing as a right and wrong choice in any given situation. ...well, to the extent that that's true, the word “taste” is a poor choice of words then. Actually, I think that's the case for this article. I think the article is fine, but the title and “taste” as a choice of word is not great. The article is more about intellectual humility and subordinating your individual priorities underneath the requirements of the project, which is all perfectly fine.

There are some domains where the word “taste” can still properly be applied, for example “vi vs emacs” comes down to individual taste. But then, “emacs people have poor taste” is something that only a narcissist would say. (The “narcissism of small differences” is a well-studied phenomenon).

Or perhaps one uses this choice of words because one feels some sympathy for people who say this in other domains, like “This room, filled with IKEA furniture and film memorabilia, was decorated in poor taste”

… either way, the red flag seems to stick.

The reason it's worth mentioning is that the notion seems to be catching on, and I've seen it applied, for example, in hiring decisions, where I think it's quite dangerous and counterproductive. It lends itself to rationalizing hiring only like-minded people, even where there is no objective ground for preferring one candidate to another.

t43562

3 months ago

I couldn't say emacs developers have poor taste but I could say its' not my taste. I don't have to disrespect them. People think in different ways and get used to different things.

e.g. I might decide that some clothes, although well made and possibly even very fashionable, are not my taste. The superiority/inferiority of taste is something that insecure people focus on IMO. A tasteless thing would be something that doesn't seem to show any overall philosophy of design or something which is bombastic - it goes to town on some aspect at the expense of all others - there's a lack of balance. Even then, who cares?

If I wear a bright tomato-coloured suit because I like colour, why should that make me a bad person? It's only when other people have to accept your tastes because they work with you that they're going to moan about them.

hyghjiyhu

3 months ago

The problem with software is that while it is in some sense objective, one of the most important properties of good software is that it can adapt to future requirements, and that's something that can only be evaluated in hindsight.

Lacking an objective way to predict that, we turn to taste.

whalee

3 months ago

Not at all. Vanishingly few things during the development process of a novel thing have truly objective measures. The world is far too complex. We all act and exist primarily in a probabilistic environment. A subjective evaluation is not so different than simply making a prediction about how something will turn out. If your predictions based on subjective measures turn out to be more correct than others, your subjectivity is objectively better.

Hence the author's main point: a good taste is one that fits with the needs of the project. If you can't align your own presuppositions with the actualities of the work you're doing then obviously your subjective measures going forward will not be very good.

nickd2001

3 months ago

This is something I wrestle with. Objectively, it'd seem true that say, a Henry Moore sculpture is of "better taste" than Disneyland. ;) But I 100% wouldn't wanna criticise anyone who preferred Disneyland. Its up to them, they don't have "poor taste" for preferring that... its arrogant indeed to make such a judgement, but then again... surely.. Henry Moore, Disneyland... there's no comparison? ;) so I go around in circles... ;)

t43562

3 months ago

I think taste is one of those things that we use to describe something that is a bit difficult to judge.

Something might not be to my taste but it can be good and workable nonetheless. It has taken some decisions that lead to solving a problem in a certain way and I can see that that way works and can be extended but it might not be a way that pleases me. Perhaps this is because it forces me to think in a mode that I am not generally accustomed to.

KempyKolibri

3 months ago

I think that depends on context. In some cases (sweet vs salted popcorn) perhaps we could say that, but in others (rotten vs fresh meat) it may well still be subjective (there are people with heterodox taste preferences out there!), but I wouldn’t take it to be a red flag for narcissism.

There are plenty of subjective preferences that we can make comparative claims about without any risk of narcissism.

laurent_du

3 months ago

Subjectivity is fine when it is backed by experience and knowledge. If anything, the narcissist perspective is the one where you claim expert opinion doesn't matter because it's all subjective and it hurts your feelings when people criticize your work (or your "taste").

WalterBright

3 months ago

12 replies

Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"

chii

3 months ago

5 replies

> everyone else says "pshaw, anyone could have written that!"

it really depends on the problem domain tho, doesnt it?

Would you call the fast inverse square root[0] code good taste?

[0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

Etheryte

3 months ago

2 replies

Being a good fit for a given purpose doesn't mean that something is in good taste. That piece of code is very performant, yes, but I'm pretty sure none of us would want to meet it in code review, save for a few niche edge cases. To draw a parallel from fashion, for most part, arctic snow gear does not win fashion prizes, but it does keep you alive. There's a time and place for both, doesn't mean that everything useful is in good taste.

AlotOfReading

3 months ago

What is "most" here? Traditional Arctic clothing (e.g. Inuit clothing) has huge fashion aspects. Being able to look good and stay comfortable in a blizzard are both important to many people in the far north.

I highly recommend checking out the clothing and fur stores to accessorize if you're in an Inuit town with nothing but "purely practical" Western clothing. A fashionable design will improve both the look and the cold weather performance.

This sometimes gets taken to the extremes of high fashion, like this design by an Inuit woman:

https://vafashion.ca/pages/the-ukiaksaq-collection-nyfw-2020

01HNNWZ0MV43FF

3 months ago

> I'm pretty sure none of us would want to meet it in code review, save for a few niche edge cases.

It does no I/O and has no action-at-a-distance. The float-long-float casts are the worst part.

If a coworker brought it to me with a performance justification and some unit tests I'd be pretty happy to pass it.

rapsey

3 months ago

One is an algorithm, a purely technical solution. The other is the way code is structured in an application.

peterfirefly

3 months ago

Yes, but the "good taste" part lies mainly in three things: 1) recognizing that a reciprocal square root is more useful than an actual square root (and likely cheaper), 2) recognizing that full precision isn't necessary, 3) recognizing that one (or two) Newton-Raphson iterations is good enough with a decent starting approximation.

The starting approximation is just magic.

WalterBright

3 months ago

As a young programmer, I would have also written the the function name "Q_rsqrt".

As an old programmer, I would write "FastInverseSquareRoot()".

It took a looong time for the penchant to write identifiers adhering to the FORTRAN limit of 6 characters to fade away.

(Yes, I know Q_rsqrt is 7.)

RHSeeger

3 months ago

Really the post you're replying to should have been written the other way around

Writing code that looks so simple, everyone else says "pshaw, anyone could have written that!" is good taste.

Not all dogs are golden retrievers, etc

pyrale

3 months ago

1 reply

Obligatory simple made easy.

Just because something is simple doesn't mean anyone has the wherewithal to understand it.

[1]: https://www.youtube.com/watch?v=SxdOUGdseq4

dominicrose

3 months ago

1 reply

I loved working in a team that wasn't allowed to use local variables (Rich Hickey decided that Clojure shouldn't have them). The menu of the website was basically implemented as a state machine and it just worked because every possible user interaction was taken into account.

arunix

3 months ago

Do you mean local variables per se, or mutable local variables? Clojure, like most Lisps has let.

nickd2001

3 months ago

1 reply

And the tragedy is that authors of such code often (usually?) don't receive recognition for saving time and effort on others' part by following KISS principles. For whatever reason its apparently opaque to others. And so there are entire jobs or even teams in the tech industry whose purpose is to work with and/or maintain systems that have needless complexity.

WalterBright

3 months ago

My life as the leader of the D team is one of a constant battle against complexity.

kmoser

3 months ago

1 reply

That's not good taste, it's good engineering.

RHSeeger

3 months ago

./venn diagram comments...

WalterBright

3 months ago

3 replies

I have another example. I have a '72 Dodge Challenger. I've taken the thing apart, and put it back together. I never cease to be surprised at how well-engineered it is in its simple, direct, and inexpensive solutions to making an amazing car.

For example, consider the instruments. They run off of 5 volts, while the system voltage of the car is anywhere from 10-18 volts. How to get 5 volts? It has a sort of buzzer which is an electromagnet. When the voltage is above 5 volts, it breaks the circuit, when it is below 5 volts, it closes the circuit. It happens fast enough that the result is a rough 5 volts.

Many restorers of these cars decide to replace it with an electronic voltage regulator, that gives it a rock solid 5 volts.

Then they discover the instruments don't work.

It turns out that the (mechanical) instruments tend to get stuck. The roughness of the 5 volts keeps them from getting stuck. So now the the electronic voltage regulator needs another circuit added to make the 5 volts rough.

That little, simple voltage regulator hidden inside a can is a marvel of simplicity and effectiveness.

sethhochberg

3 months ago

1 reply

I think you've actually buried a much broader commentary on tolerances and complexity and interoperability in here, too.

The mechanical-averaging voltage regulator worked for the design because it only had to work in the context of the specific model of car it was going into. It didn't have to produce 5v for any application that needs 5v; it just had to produce "5v" for the instruments in the '72 Dodge Challenger. That makes it a pretty terrible 5v regulator, but a pretty great part for the system it was designed to fit into if the mechanical-averaging version is more reliable or cheaper or more robust than the fancy electronic versions.

But if I'm designing a 5v regulator to be sold as a 5v regulator, well... I don't know what system its getting installed into so I won't have much luck selling one that, over a long enough time span, averages out to supplying 5v of power when its supplying power. So I have to design in tight tolerances, and everyone integrating my regulator has to design for tight tolerances, etc.

The good news is that now anyone can buy my regulator and get a reliable 5v - interchangeable parts! But the bad news is now every system on both sides has additional complexity for the sake of complying with our standard.

We see this _all the time_ in software, especially comparing old software to new. Why is Roller Coaster Tycoon so much more elegant and efficient than a modern game written on Unity? Sure, good tastes probably factor in - but that taste from the author was allowed to shine because it was designed as a complete system, not a bunch of component subsystems from different teams and vendors stitched together.

WalterBright

3 months ago

1 reply

You make a great point. With the Dodge regulator, I seriously doubt it was just for the Dodge Challenger. It was probably used across the entire Chrysler line, for years. Enough cars were built to totally justify its design. I don't know when semiconductor voltage regulators appeared in a single package.

In 1972, the electro-mechanical regulator was also likely far cheaper than a solid state one. The car didn't have a single transistor in it outside of the (rather expensive) radio. (There was an upgrade available for the ignition to make it "electronic" - it had one transistor!) The alternator of course had diodes in it.

The rough 5V also enabled the instruments to be made cheaper.

Aloha

3 months ago

1 reply

I thought by 72 they were using the electronic ignition module instead of points? I thought MY72 was the year it was introduced even?

WalterBright

3 months ago

The electronic ignition was an option at the time.

stickfigure

3 months ago

1 reply

I don't know that I'd describe this as "good". It's a hack solution that mostly worked at the time.

Those mechanical voltage regulators wore out and had to be replaced periodically. They weren't great at maintaining consistent voltage so consumers had to accept loose voltage tolerances. They made noise and generated electrical interference.

Modern cars are more reliable, despite their complexity. I'll take solid state.

WalterBright

3 months ago

> Modern cars are more reliable

I would hope so, after 55 more years of development!

WalterBright

3 months ago

Another example. The V2 rocket engineers had a problem with the nozzle. It would burn through. The flame was just way too hot for any known metal.

The solution was simple and pure genius.

The nozzle was composed of tubes welded together. The liquid oxygen was run through the tubes, which pre-heated the oxidizer and cooled the nozzle. But that still wasn't enough. Then the engineers simply drilled tiny holes in the tubes, so some of the oxygen would leak out into the nozzle. The gas would form a barrier between the flame and the nozzle, and would carry away the heat. (This is known as boundary layer cooling.) If you ever get a chance to look at a rocket nozzle, you'll see the tubes and the holes.

WalterBright

3 months ago

1 reply

Another one:

People will watch a ballet and remark "they make it look so easy and effortless!"

The reality is, it is easy and effortless to them, because they practiced it 10,000 times.

HPsquared

3 months ago

That's the best kind of work to get into. Something where you've got a rare skill, do something that looks amazing, but it's easy. Like ballet, the hard part is getting yourself to that skill level and finding opportunities to use it.

dkarl

3 months ago

Exactly. It's occasionally handy if your engineers are capable of doing extraordinary things, but it's even better if they consistently find simple, ordinary solutions to problems that seem formidable at first glance.

silisili

3 months ago

That's always been my benchmark as well. I'm always super impressed by people who are able to distill complex things into simple steps. Much like K&R C example code, but please, please leave better comments.

jongjong

3 months ago

Yes. It's a great irony. It's so simple that anyone could have written that and yet it feels like less than 1% of people write code like that in practice.

Cthulhu_

3 months ago

The challenge though is getting people to appreciate it, because the code looks / is boring as well. A lot of junior but good and driven developers (...myself included) want to write clever code, code that makes them feel smart, but often in an environment where the problem doesn't need it. CRUD back & front-end has this problem, where the complexity isn't (shouldn't be) in the code itself but the higher level stuff - domain, architecture, etc.

And then there's a class of people that overcomplicate the architecture out of boredom, perceived possible problems (like scaling) or cargo cult, and they introduce stuff like microservices or lambdas instead of just solving the problem at hand with proven and simple solutions.

But you won't find good developers if your job listing is "looking for a java developer for a straightforward CRUD application".

WalterBright

3 months ago

Sometimes, simple code is viewed as an invitation to make it more complicated.

asmor

3 months ago

While balancing that to performance requirements appropriate for the project. And picking dependencies that do the same while having a healthy community likely to keep going.

The same applies to picking vendors, asking questions like "will they extort me next contract renewal" and "what options do I have if they extort me".

bob1029

3 months ago

2 replies

> In my view, your engineering taste is composed of the set of engineering values you find most important. For instance:

Strange how absent the customer or underlying business always is in this discussion.

I've seen a LOT of software that could have literally just been a spreadsheet on a file share or a simple SQL ETL job. When reviewing the actual business requirements, we will often find that we don't even need a goddamn web interface. It's just assumed we're gonna build some full stack slop so we never bother to stop and ask why.

I'm watching a client (despite my advice) self destruct on yet another rewrite of a piece of software that doesn't need to exist in the first place. Looking forward to having this exact same conversation IRL in a few months.

I think the heart of bad taste comes from obsessing over tools and techniques and not ever getting meaningful things built and shipped to real customers. Being exposed to unfiltered criticism of the people who actually use your software is the fastest way to drive the noob behavior out of a developer. It's amazing how quickly you drop weird principled takes when your monkey brain senses it is disappointing others.

bubblyworld

3 months ago

1 reply

Can you provide examples of software that should have literally been a spreadsheet or an ETL? Not to call you out specifically but this feels like "I could have written that in a weekend". Personally whenever I have felt that way about a project it turned out I was just missing 95% of the business context/domain knowledge (part of the reason I think rewrites are a bad idea - chesterton's fence).

t43562

3 months ago

I can give you one - a billing system with reporting features that suck dreadfully compared to what can be done with a spreadsheet. Why not "just" let the user download a CSV and then do whatever they want with it?

I was working on this project and I kept suggesting it. It was seen as inferior and yet the system we were going to produce was far inferior in every way.

eXpl0it3r

3 months ago

I agree that the customer / business focus is often very lacking. Sometimes because engineering is put too much into focus, but very often because of politics. At the same time it's not an easy thing to do. The "business" is usually quite bad at verbalizing their needs and requirements, especially at the level of detail that engineering requires.

Having done at least one migration from "could have literally just been a spreadsheet" applications into proper applications, I'm very careful with recommending spreadsheets. It's great how flexible they are, but that's also their major down side. If you want to enforce anything within a spreadsheet, you have few options and it's very easy for something to break. For example someone deleting a formula, a formula not including the full range, or copy & pasting breaking the references. Not to mention the performance issues you'll run into once you've collected a few rows.

ajuc

3 months ago

1 reply

Good code is invisible - either there's no code at all (because the requirements and architecture are well adapted so that code isn't necessary for a particular feature), or the code is so simple and boring that you skip over it without pausing.

Not all code can be like that, sometimes you need to write clever code, but it is an ideal to strive for.

BTW this is why egoless programming is so hard. Not only you have to accept criticism and let go of the idea of ownership of "your" code - you also have to write the code in a way that strokes ego the least.

rawgabbit

3 months ago

I like this idea. Good code does what it needs to and no more. Adding cognitive load that isn't absolutely necessary is the opposite of readability.

OhMeadhbh

3 months ago

3 replies

I would say limiting the braggadocio is important to "good taste" as well. I interviewed once for a dev role on the email team for a very large free software company you've heard of. The team's egos were so large I could hardly fit in the room. "Oh! I see you wrote the control system for a nuclear power plant. That's cute, I once inverted a tree data structure!" or "I see you wrote the modular exponentiator that was in half the ATM machines deployed in the US in the mid-90s. Whatever. I wrote code that changes the background color of our web page."

I did not take the job.

jackblemming

3 months ago

2 replies

Your phrasing makes it sound like you’re playing the same childish game they are; you just rank yourself higher than them.

laurent_du

3 months ago

1 reply

There's nothing wrong with that. The problem is not that they were playing a childish game, it's that they were over-estimating their own abilities by a lot. It's ok to acknowledge you are good at something if you are, in fact, good at this thing.

scottlamb

3 months ago

> The problem is not that they were playing a childish game, it's that they were over-estimating their own abilities by a lot.

Why not both?

In an interview, you need to impress, and that's true for both the job-seeker and the hiring team. So yeah, you need to talk a bit about your accomplishments, and it's hard to do that without being a little braggy. But you can let your work be measured on its own. If you directly measure your accomplishments against the other person's, and especially if you put their accomplishments down, you're not selling them. You're showing off your personality flaws, even if you "win" the pissing contest.

OhMeadhbh

3 months ago

so... you're suggesting I take things off my resume to avoid making interviewers feel bad?

nickd2001

3 months ago

+1 to limiting braggadocio. Maintaining code written by someone with humility, and consideration for the subsequent maintainer (including themself, as they don't assume they're super(wo)man and will understand their own code immediately after time away) is much easier than code written by someone with a large ego who likely thinks anyone who doesn't understand their code is "dumb" / "a wimp" etc

t43562

3 months ago

I do understand the feeling. IMO it could be a bit of ageism. I think it's worse when the company (or team) management strategy is to keep everyone feeling insecure and seeing each other as competitors and potential enemies.

I also agree that you sensed the environment and avoided it and were probably right. When looking for a job this can be very dispiriting but then you occasionally do interviews where people are more friendly and secure and it reminds you that it is possible to find a reasonable place.

mojuba

3 months ago

10 replies

> Is the software easy to take in at a glance and to onboard new engineers to?

This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement?

"Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.

So when someone says "code should be readable", to whom exactly?

zx8080

3 months ago

3 replies

Theere are two quite a widespread classes of not readable code:

Some code is not readable by _anyone_. That's not readable code.

Some code is readable by its author only (be it AI or a human). That's also not readable one.

Saying readability is not a concept is really strange.

mojuba

3 months ago

3 replies

I have a formal proof for you that it is a non-concept. If code can be read and interpreted by a computer, it means it can in principle be read by a human. There are of course some edge cases like obfuscated JavaScript or binary executable that some people are able to read and understand.

The question comes down to being reasonably readable and we are back to square one: "reasonable" is very relative. In my early days I could read 8086 binary code (in hex) and understand what it does, it was literally at the very edge of readability but it wasn't unreadable.

atoav

3 months ago

Sure, but we do agree that Hello World is MORE¹ readable in Python compared to the equivalent program in say Brainfuck?

  print("Hello World")

vs

  ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

¹: more readable means easier/faster to read for most human beings that know the language

eithed

3 months ago

I can't reasonably read whether this comment agrees or disagrees with the parent

RHSeeger

3 months ago

You are using a different definition of readable than most people are. Most people are using it to mean "the target audience can read and understand the code, and do so in a way/context that allows them work with it". Your definition seems to be "can read the symbols on the screen".

I can read Assembly. I can, in some cases, figure out what that Assembly is doing. I can not, however, work productively with it. I can read Assembly but would not consider it readable.

Yoric

3 months ago

1 reply

I'll have to disagree.

Developers coming from functional programming and developers coming from C programming, for instance, have very different definitions of "readable", and neither is obviously wrong.

Similarly, developers used to channel-based, async-based or mutex-based concurrent programming will all have very different criteria for "readable" code, again none of them obviously wrong.

skydhash

3 months ago

1 reply

Those are just paradigms, ways of solving problems. There’s a difference between familiarity and readability. Sometimes you have to learn stuff before understanding them. Readability is how easy it is to do that, given familiarity with the base concepts that the code use.

Yoric

3 months ago

You are correct.

Yet it's pretty easy to find people who consider that `map()` or `filter()` are simply not readable – or, on the other side of the aisle, that having a loop variable is detrimental to readability.

And of course, these criteria change with time, industry and programming language used.

epolanski

3 months ago

Readability to a certain degree is heavily influenced to the reader's experience and familiarity.

If somebody has spent lots of time in specific patterns he/she'll find them natural to read and mentally process.

To others, they'll be unreadable.

ibash

3 months ago

1 reply

I disagree. The ability of someone to read code doesn't grow exponentially, after a few years of experience everyone hits the same plateau. More years of experience does not mean you can understand more complex code.

That is to say, if you target "readable to the majority of engineers with 3-4 years of experience, without them getting confused" then you've hit the mark.

mojuba

3 months ago

> after a few years of experience everyone hits the same plateau

I'm sorry this is a very naive take, I presume (I could be wrong) coming from someone with just a few years of experience.

pbalcer

3 months ago

4 replies

Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.

Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses is equally readable as Seuss's The Cat in the Hat?

PickledChris

3 months ago

1 reply

I see this argument pattern a lot, so looked into what the name is. Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.

kaffekaka

3 months ago

1 reply

Did someone claim readability does not exist?

hhjinks

3 months ago

1 reply

> Readability is a non-concept really

Yes.

mojuba

3 months ago

2 replies

Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.

virgilp

3 months ago

1 reply

Add "to most developers" for context and you'll probably get exactly what original claim meant.

It's not a non-statement. Rich Hickey explains it well, readability is not about the subjective factors, it's mostly about the objective ones (how many things are intertwined? the code that you can read & consider in isolation is readable. The code that behaves differently depending on global state, makes implicit assumptions about other parts of the system, etc - is unreadable/less readable - with readability decreasing with number of dependencies).

Bjartr

3 months ago

It can be further refined to

"to most developers who are most likely to interact with this code over its useful lifetime."

This means accounting for the audience. Something unfamiliar to the average random coder might be very familiar to anyone likely to touch a particular piece of code in a particular organization.

pixl97

3 months ago

>"Code should be readable" is a non-statement, yes.

Oh, I completely disagree here. Take obfuscation for example, which you can carry on into things like minimized files in javascript. If you ever try to debug that crap without an original file (which happens far more than one would expect) you learn quickly about readability.

osigurdson

3 months ago

1 reply

>> Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.

Usually that means something less than "perfect" from the perspective of the writer. Applying to much DRY, SOLID, DI and other "best practices" will make it very hard to understand. Pretend you have about 20 less IQ points than you actually have when writing the code - you will thank yourself when you come back to it.

pepoluan

3 months ago

Reminds me of someone's quote:

> Reading -- and understanding -- code requires twice the brainpower of writing code. So if you used every bit of your intelligence to write 'clever' code, you won't be able to maintain it because it requires twice your intelligence to read it again.

Einstein's words are oh so suitable as well:

> Everything should be made as simple as possible, but not simpler.

bcrosby95

3 months ago

The trap people fall into is calling The Cat in the Hat unreadable compared to Joyce's Ulysses because The Cat in the Hat they're reading is written in German and all they understand is English.

mojuba

3 months ago

I didn't say readability is subjective. I'm just asking, when someone says "code should be readable" without any clarifications, what does it really mean?

Big companies may actually have an answer to that: "since we require at least 2 years of experience in the area from new hires, all code should be readable at that level".

However startups may prioritize something else over readability at that level, for example: move fast, produce the most minimalist code that would be easy to maintain for people like you.

My point being, "code should be readable" should always come at least with a footnote that defines the context.

pjaoko

3 months ago

Completely agree. Readability is actually in the word itself read + ability. The ability of both the code and the reader.

DanielHB

3 months ago

It is hardly worth bothering how readable is "local code".

Following the same patterns across large parts of the codebase is what makes the codebase as a whole readable. Those patterns may even be complex, as long as they are used over and over without too much deviation and flag-explosion the codebase will be readable.

In short local isolated code can be as bad to read as it wants, as long as it doesn't infect the codebase as a whole (like through the use of shared mutable state or through a bad API).

epolanski

3 months ago

+1, to come back to the author's own narrative, familiarity plays a big role here.

If the new engineer is well versed in mapping and filtering he/she'll have an easier time onboarding a codebase that's rather void of manual loops.

atoav

3 months ago

Code readability isn't a metric. It is a tradeoff. It basically boils down to: if in doubt will that programmer go with the more readable version of the code or do they stick with the slightly terse, clever hack?

rob74

3 months ago

Call me naive, but I would presume that even a junior, once they start working at a company, should be familiar enough with a language that they know all the basic syntax, idioms etc. Still, even if they are, over-using some language features will make your code less readable (to anyone). E.g. some will prefer good ol' if/else to the notorious ternary operator and its many descendants. But that brings us back to your own personal taste...

djmips

3 months ago

Speaking of those equations, as he wrote them they were considered rather impenatrable and the modern ones are considered much more beautiful and 'readable' but that was the work of Heaviside and others.

MaxBarraclough

3 months ago

> Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.

When we talk about a language's readability we're typically talking about 'accidental complexity', to use Brooks' term, [0] and not the 'essential complexity' of the problem being solved. For a hairy enough algorithm, even pseudocode can be difficult to understand.

Readability applies in mathematics too, as a bad notation may make formulae unnecessarily difficult to comprehend.

> So when someone says "code should be readable", to whom exactly?

I'll have a go: to another competent engineer familiar with the general problem domain but not familiar with your specific work. This includes yourself in 2 years time.

This seems rather like the question of readability for scientific writing. Research papers should be readable to other researchers in the field, but they aren't generally expected to be readable to a general audience.

[0] https://en.wikipedia.org/wiki/No_Silver_Bullet#Summary

necklesspen

3 months ago

6 replies

When used in the domain of fashion "good taste" describes someone who has a unique way of selecting clothes that just mesh well together - clothes that by themselves independently are meaningless, no matter their make or quality, but when combined together create a powerful effect - much greater than the sum of their parts.

I was hoping the article would go in that direction - what subjective combination is a software engineer deciding on that you can argue is truly a matter of taste and not just a technical decision about a trade-off.

I would say this this article itself may be an example of bad taste. It meanders across a couple of disparate topics in software engineering, independently each section is competently written but as a whole they really don't sell the "look" the article was aiming for.

(I don't mean to discourage future writing by the author - I think it's a potentially excellent choice of topic. I'm just giving my two cents here on the execution.)

whstl

3 months ago

1 reply

I don't agree with the statement that clothes can be "by themselves independently are meaningless". Garments carry cultural, historical and symbolic weight even before they're combined. And fashion is hardly mainly about combining outfits.

And fashion is a lot about tradeoffs too. Not just in the production, but also in the day to day wearing and mix-and-matching part.

necklesspen

3 months ago

Meaningless in the context of an outfit - not necessarily whether the garment itself may have meaning to someone. You may surely be in possession of a couple of random trinkets of great historic significance but if you just mesh them all together into one outfit you might simply end up with a mess on your hands. A garment may well be the centerpiece of an outfit - but it is ultimately always the combination that is important.

Im sure you've seen examples of this yourself - you can absolutely sport a Ray Ban in good taste and you've almost surely seen someone believe themselves to be fashionable because they are wearing a Ray Ban.

Also, I'm not suggesting fashion as a whole is about combing outfits - merely that being able to combine varying pieces of clothing into a cohesive whole is an expression of good taste.

blub

3 months ago

2 replies

Most engineers and technical persons don’t have good fashion taste, so they have a hard time understanding good taste in general.

The great majority of technical things are not cool to normal humans, they’re geeky. Programming languages are not cool. In programming one has to therefore start from “not cool” and move down the scale:

Uncool: Rust, C++, most languages

Painfully uncool: anything functional and weird. Bash, Linux, etc.

wredcoll

3 months ago

1 reply

This comment annoyed me so much I had to get an actual keyboard to respond.

First off, the concept of "good taste" is much, much broader than only applying to clothing based fashion. You can have good taste in practically any field that involves any amount of creativity/choice: cooking, painting, writing, music, programming, video game design, etc, the list is practically infinite.

As such, the idea that most "engineers and technical persons" don't "understand good taste" is incredibly silly. It's entirely possible, perhaps even probable that the average programmer lacks good taste in terms of fashion, but that says nothing at all about good taste in other areas.

Secondly, having good taste and being able to apply it is also wildly different. I can recognize what looks good in fashion or paintings without being myself able to achieve that.

Thirdly, there's really no such thing as a "normal human". The longer you live, assuming you're willing to actually examine your experiences, the more you'll learn that the trite expression "everyone is unique" really is accurate.

Just as a semi-random example, it might be tempting to think of watching football (nfl) as "normal". According to a quick google, the average nfl game gets like 17-20million viewers, and even assuming that's accurate/all unique people/etc, it's a very large number in absolute terms but its less than 10% of the population of america.

So if you took a random group of 100 americans, something like 6-7 would have watched a football game last week[1]. Now that's still many times larger than the number of people who wrote code last week, but it's not some kind of overwhelming majority that "everyone" does.

[1] Yes these numbers are extremely imprecise, it's rhetorical

blub

3 months ago

It is broader since it applies to things which can be perceived visually, but does not apply to any random creative activity. The list is finite and programming is not on it.

Furthermore, taste in one area is more likely to manifest in other areas. Somebody that has good taste in fashion would likely have good taste in interior decoration or art.

> Secondly, having good taste and being able to apply it is also wildly different. I can recognize what looks good in fashion or paintings without being myself able to achieve that.

Ok, but applying it is the interesting part.

> Thirdly, there's really no such thing as a "normal human". The longer you live, assuming you're willing to actually examine your experiences, the more you'll learn that the trite expression "everyone is unique" really is accurate.

The things that make individuals truly unique are often irrelevant in the greater scheme. One could draw a line across continents and ages to connect quite similar people.

jm547ster

3 months ago

Yeah the Linux language gets most people's goats......

bryanrasmussen

3 months ago

> what subjective combination is a software engineer deciding on that you can argue is truly a matter of taste and not just a technical decision about a trade-off.

I put down to taste many things that I believe are technical decisions about trade-offs but that I cannot absolutely verify or which I believe the trade off is so very small that it doesn't actually matter.

HenriTEL

3 months ago

You're comparing apples and oranges. Good taste in fashion is much more subjective than in software engineering, obviously because one stays a subjective discipline while the other always ends up in formal science.

What's interesting is that software engineering starts in social science where most choices are made subconsciously or at least not discussed with other people.

bcrosby95

3 months ago

Funny, I think it was one of the more insightful and well put together articles on a subject that usually elicits very hand-wavy unactionable statements.

hosh

3 months ago

I think the line of thinking you want to explore has more to do with how we perceive beauty and elegance. That has been the subject of philosophers all over in our recorded history, and I doubt a single article will be able to cover this.

Christopher Alexander studied this deeply for building architecture, and his ideas had influenced many thinkers of software architecture; Alexander asserts that there is a thing to objective beauty. Alexander’s keynote to the OOPSLA conference is worth reading, as is Roy Fielding’s dissertation. The “values” mentioned in this article is organized as “architectural properties” in Fielding’s dissertation.

JulianHC

3 months ago

1 reply

I heard readability is a touchy subject since some people say having your code easy to read would make replacing you easier.

8-prime

3 months ago

If you write your code such that you are hard to replace, because noone else would be able to understand what you were doing, I would consider that to be "bad taste" and "bad form".

eimrine

3 months ago

1 reply

Those who have a good taste can distinguish a good taste from a bad taste. Those who don't have a good taste can not.

chii

3 months ago

1 reply

So who has the good taste when two different people distinguish the same code base differently?

antisthenes

3 months ago

> So who has the good taste when two different people distinguish the same code base differently?

The person with the good taste.

marginalia_nu

3 months ago

1 reply

The portable definition of good taste in software development is likely something like fitness to purpose, i.e. how well does the taste lend itself to producing good software, where good software in turn is software that does what it is indented to do.

If you want to go more concrete than that, you need additional parameters, otherwise you risk ending up with a broken compass that only points north in organizations similar in size and other properties to the ones you've worked in before.

Mikhail_Edoshin

3 months ago

Fitness for a purpose has a very deep meaning. In "The Timeless Way of Building" Christopher Alexander used this term as the last attempt to describe "the quality without a name".

epolanski

3 months ago

2 replies

> Are functions relatively short and named well?

I was hoping we moved beyond this "clean code"-ish nonsense of functions having to be short.

Quality of a software design, maintainability, etc, have virtually no relation to length of functions and the most respectable software out there contain functions hundreds if not thousands of lines of code long without being impacted by its own weight.

imiric

3 months ago

1 reply

Eh, hard disagree. (Though I didn't downvote you, since it's silly to downvote out of disagreement...)

Readability, while subjective, plays a large role in software maintenance. Developers will be more reluctant to change code they don't understand, and more likely to introduce bugs. "Long" functions require following large blocks of code that work within the same context, and relying on comments to explain functionality, which could be wrong or outdated, rather than descriptive function names.

Also, "long" functions are typically difficult to test. They either require complex setup and mocking, or are only tested under very specific conditions in end-to-end tests, if at all. Chances are that only users are actually testing them, which is not a good place to be.

We can argue whether "AI" tools help with this or not, but while humans are still reading and writing code, following standard conventions of keeping functions relatively "short", "clean" (whatever those terms mean for you and your team), and with a single purpose, makes maintenance and testing easier, and, in turn, produces more robust and higher quality software.

epolanski

3 months ago

1 reply

You break up things when it makes sense, not for the sake of it.

Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (same functionality, but higher api surface).

You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of syscalls run generously in the thousands or tens of thousands of lines.

Stanford professor Jon Ousterhout (among other things the author of the Tcl language, the Tk framework, the Raft consensus algorithm and many other things) has an entire paragraph in his book "A philosophy of software design"[1], on why the argument "functions should be short" is short sighted and should never be taken at face value.

[1] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

imiric

3 months ago

2 replies

> You break up things when it makes sense, not for the sake of it.

I never claimed otherwise.

> Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (higher api surface).

I don't buy this argument. The code you're reading should do one thing according to what it says on the tin (the function name). When the code does something else, you navigate to that other place (easily done in most IDEs), and change contexts. This context change is important, since humans struggle with keeping track of a lot of it at once. When you have to follow a single long function, the context is polluted with previous functionality, comments, variables, and so on, not unlike the scope of the program at that point. If you're changing the code, it becomes easier to shadow a previous variable, or to change something that subsequent code depends on. Decomposing the large function into smaller ones avoids all of this.

As well as aiding in testability, which you conveniently ignored from my previous comment.

The criteria for determining what is "short" and "long" is subjective, of course, and should be determined by whatever the team collectively agrees on. But there should be some accepted definition of these.

> Stanford professor Jon Ousterhout

Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours.

epolanski

3 months ago

1 reply

> Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours.

John has spent his entire life to learning and teaching general principles of good software design and their limits.

His opinion definitely has a different weight than ours.

https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/inde...

illuminator83

3 months ago

1 reply

Well, he can start citing Martin Fowler or Bertrand Meyer. Then what?

Arguments from authority lead no where here. Because these "authorities" also disagree.

epolanski

3 months ago

John has had meaningful impact to computing from algos, operating systems, programming languages, frameworks, etc.

Fowler has written *nothing* anybody ever cared for. Nothing.

Ousterhout has taught Software Design at Stanford where he's had students implement the most diverse software and finding the limits of his own theories and having them questioned rigorously year after year.

vendiddy

3 months ago

1 reply

If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right?

Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same?

Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow.

So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months.

Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?

imiric

3 months ago

1 reply

> If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right?

You're misunderstanding. Code is not broken up because it's "long". It's broken up because it is difficult to comprehend and maintain, and its length is one criterion that might signal that to be the case. Another sign is cyclomatic complexity, which is another arbitrary number left for teams to decide how to use best.

The main topic, and why it is so widely argued, is that readability and maintainability are entirely subjective concepts that are impossible to quantify. This is why we need some specific guidelines that could point us in certain directions.

This doesn't mean that these guidelines should be strictly enforced. I've often decided to silence linters that warn me about long functions or high cyclomatic complexity, if to me the function is readable enough, and breaking it up would be more problematic. This is open to interpretation and debate during code reviews, but it doesn't mean that these are useless signals that developers should ignore altogether.

marcosdumay

3 months ago

> and its length is one criterion that might signal that to be the case

You seem to be the one misunderstand it.

It's just not. Function length is not a useful metric, at all. The probability of some problems increase with length, but even then it's not the length that will tell you if your code has a problem or not.

If you have length guidelines, your guidelines are bad.

And, yeah, cyclomatic complexity is almost as useless as function length. If you have warnings bothering people about those, you are reducing your code quality.

BenoitEssiambre

3 months ago

To add to this, there are fundamental information-theoretic principles that support inlining code and components. It's about reducing code entropy, reducing length and referential distances. https://benoitessiambre.com/entropy.html

The good thing is LLMs try to optimize for information theoretic measures of language so they naturally generate better scoped more inline code. LLMs might help us win this battle :-)

imiric

3 months ago

1 reply

I like the article. Most engineering decisions are indeed a tradeoff that should be carefully considered.

That said...

> I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing.

There are indeed general best practices that are applicable to most, if not all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.

Context does matter, but within specific contexts there are practices that can be generally considered "best", because applying them delivers more value than not, and their drawbacks are manageable.

For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically "simple", can only get you so far. And so on.

These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn't necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that's just human nature.

t43562

3 months ago

1 reply

It gets used whenever someone doesn't like something for a reason of personal taste and people who don't really know (like your boss) immediate fixate on it and think "well, we must do that then and why is the other guy (you) suggesting that it doesn't apply in this case? Best practises ALWAYS apply surely? I will have a quiet word with him about standards..."

IOW it's a short circuit to not justifying something. If something is best practise you can explain why it suits the current situation and if you can't explain why then it doesn't matter.

imiric

3 months ago

1 reply

Well, sure, but since every decision has tradeoffs, sometimes when arguing for or against a decision, it's easy for managers to side with the person they have more rapport with, who may or may not be correct, rather than decide on technical merits alone.

So, in some cases, it's more beneficial for the company to adopt a "best" practice, than to have engineers engage in arduous discussions, which can cause resentment and further problems within the team.

Needless to say, it's a delicate balance, which is why I wouldn't want to be a manager. :)

t43562

3 months ago

Oh, you're so right about setting some default standards to prevent arguments!

The most simple and easy one is to auto-format code. That kills so many ridiculous arguments. I wish all problems could solved that simply.

mrkeen

3 months ago

1 reply

"Good taste" is just advice or guidance that you haven't thought through enough to turn into actionable principles.

Compare:

* I apply the dependency inversion principle to keep my code testable

* I minimise the scope and mutability of all my variables

With:

* These methods do what they say they do

* This code is good because it's declarative

* These functions have the right number of lines

8-prime

3 months ago

1 reply

I may be misunderstanding what you're trying to say, but I feel like this still suffers from one of the mentioned issues - situationality.

Even the best actionable principles can be incorrect given a certain set of circumstances. If in those cases you choose to uphold your priciples, rather than choosing what is "right" for the project you would fall into the camp of "bad taste".

That is at least how I interpreted the article.

mrkeen

3 months ago

2 replies

> Even the best actionable principles can be incorrect given a certain set of circumstances.

If they are principles, the discussion around whether to apply them can at least be fruitful. "Taste" is bound to devolve into "I like this" vs "I like that".

I don't buy into the "everything has its upsides and its downsides" advice given in the article for the same reason. It's a useless truism. It's a taste:-

I have 1 new feature ticket in my backlog, 3 support tickets, 2 failing tests, and 2 performance regressions. "Premature optimisation is the root of all evil" informs me about the feature work, as does "Make it work, make it right, make it fast". "Reproduce locally" will be my north star for the support, the test failures, and the performance work. Add "Find and measure the bottleneck(s)" for the performance work, as well as "make sure the new code is actually faster than the old code" before checking it in.

I don't need to invoke the maturity of any particular coder for any of this.

Another problem with letting "taste" into the discussion is that you can cheapen principles: you think this code needs tests? "Well, there are upsides and downsides with that", "You're just being inflexible, which is immature". Neither tasteful reply will help you answer whether the code needs tests, and it stirs up shit in the team because it makes it about people, not work, so egos will get inflamed.

>> Personally, I feel like code that uses map and filter looks nicer than using a for loop

I'm not going to argue the person, I'm going to argue the principle. I use map and filter in my business logic because I can do so without mutability. My business logic should reflect the requirements and customer expectations - deterministically. The principle of making the source code pretty is a distant second to the principle of making the code deterministic. If the requirements change from "apply the correct tax rules" to "apply the correct tax rules, if the system is in the right state", then I might well bring in a bunch of mutations to make that happen.

>> is more straightforward to extend to other iteration strategies (like taking two items at a time).

Nope, items.pairs.map((x,y) => ..). Didn't need to discuss maturity.

eowyn

3 months ago

> "Taste" is bound to devolve into "I like this" vs "I like that" My read of the article was less "I like this" and more "I've seen xx work best in a situation like this where we're optimising for yy but if we're optimising for zz then something else would be more suitable"

It's less about what you like or dislike and more about aligning a collection of practices you've seen work well to the situation and constraints, which is why variety of experience helps

I'm not sure why stirring up shit or inflaming egos would necessarily happen with such conversations. Skilled engineers often start a solution proposal by explicitly outlining what they are optimising for, known limitations etc which all help create a baseline to describe "taste"

boxed

3 months ago

> for loop

The language matters a lot here too:

> For instance, map and filter typically involve pure functions, which are easier to reason about, and they avoid an entire class of off-by-one iterator bugs.

That's not how "for loops" work in many programming languages! Python being the most obvious, and by some measures the largest programming language of all.

fiftyacorn

3 months ago

1 reply

Id settle for "common sense" - seems to lack in a lot of codebases

rswail

3 months ago

Which doesn't exist, because it's not "common".

yegle

3 months ago

1 reply

How to distinguish "good taste" vs "opinionated" though?

If you can articulate why certain code is better with convincing justifications, I would say that's "good taste". Coding styles are often examples of these.

But if you can't articulate or don't have a convincing reasoning for preferring certain coding patterns, isn't it just "opinionated"?

eowyn

3 months ago

I think good taste and opinionated aren't quite the same thing but you do need to have some opinions to have good taste, it's almost like a precursor. Good taste then comes from knowing which of your opinions you're optimising for in the current situation and which of your opinions are either not relevant or perhaps the situation is not suitable or ready for them.

brunorro

3 months ago

2 replies

I have bad taste. So I will say suckless.org

- software should do one thing and do it well - code should be understandable, easy to build, easy to port - dependencies should not be a problem - the chosen language must not be a burden - resources are scarce: if you say "unused memory is wasted memory" you are part of the problem

(I know, I'm a horrible person)

asmor

3 months ago

1 reply

It's not wrong per-se, but they practice it to a level of extreme that it seems more like a principled art piece than usable software. Software engineering is all about knowing your project-specific constraints, it should not be wasteful - and that goes for runtime performance / memory usage as much as the time invested. Usability is another factor - suckless software is very inaccessible to people who don't know how to use a compiler by default.

> (I know, I'm a horrible person)

You made a throwaway just for that? I'd hope most people are capable of differentiating the engineering ideology from the (ironic?) nazi reference and tiki torch march ideology bit.

brunorro

3 months ago

1 reply

Holy sh... I didn't expect that Godwin's law would apply that quickly. IMHO, I'm also part of the problem and I think I am a horrible person, but at least I don't consider myself superior to anyone in any way no matter their race, gender, software philosophy or their political views as far as they don't fall in the tolerance paradox.

asmor

3 months ago

1 reply

It's pretty well documented that they called their mailserver "Wolfsschanze" (which was one of Hitler's military bunkers). Whether or not that's just edgy behavior or not, I don't know, but my guess it's a bit of both considering suckless people have complained about "cultural marxism", which is a term with pretty straight lineage to the Nazi's "cultural bolshevism".

So... is that not a nazi reference? Why else would you preempt being "horrible".

brunorro

3 months ago

1 reply

By the way, just wanted to be sure about this: Tiki Torch parades have been documented since the XI century on the Pyrenees, I just wanted to be sure how old was the tradition. That's the first place that came to my mind and the place where I myself have gone down a hill with some other hundreds of people carrying a torch... When we finished, in the town in the valley, there was a reggae concert and most of the guys down the hill went there, no problems at all.

Actually my country had a fascist dictatorship until the end of the 70s. I'm old enough to have been hit by nazis in the early 90s. I have seen fascists in a parade and policemen doing nothing.

IMHO, software philosophy does not have anything to do with some developer philosophy. IMHO again, that is like comparing journaling filesystems and B+ trees as apology of gender-based violence because ReiserFS was one of the first mainstream filesystems that implemented it.

asmor

3 months ago

I think we mostly agree here. I just found the preemption curious.

scottlamb

3 months ago

1 reply

Are you quoting suckless.org? Or paraphrasing? In a skim, I see some philosophy stuff there but not exactly this.

I think those are platitudes: they sound good but aren't specific enough that anyone disagrees with them, so they're not saying anything. Imagine:

> - software should do one thing and do it well

No one ever says "let's do a bit of everything, badly".

And there's tons of wiggle room in "one thing". Imagine a few, very different huge codebases. Let's say Linux, Photoshop, Rust. I think their proponents would say they're each focused on one thing (kernely-stuff, photo editing, foundational software). Their detractors would disagree: use a microkernel instead, separate out the filters or something, people are using it for scripting. Who's right?

> - code should be understandable, easy to build, easy to port > - dependencies should not be a problem > - the chosen language must not be a burden

Again, no one ever says differently, even if the result they end up with is none of these things.

> - resources are scarce: if you say "unused memory is wasted memory" you are part of the problem

I think this is the most interesting one, because it's contrasted with something I have actually heard people say (maybe even said myself on occasion). But still, I generally haven't heard people say it for no reason. There's some other attribute they're getting for that RAM, whether it's a compute-vs-RAM trade-off or the ability to use a (believed-to-be) simpler programming language or some such. This one might be more interesting if prioritized relative to "code should be understandable".

brunorro

3 months ago

1 reply

About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!

About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(

scottlamb

3 months ago

> About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!

People have asked the systemd folks about this, and their answer is that these are separate things because systemd-resolver is a distinct, optional binary that does one thing well. Is that enough to say they're totally separate things? Opinions obviously differ!

It is really hard to come up with rules of taste that are generally applicable yet specific enough to that people interpret them in the same way to make the same decisions. I don't really have any such rules of my own to offer. I've written coding standards for multiple projects but I definitely can't copy'n'paste one to another and have it still make sense.

> About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(

Yeah, there are plenty of examples of poorly written applications around. [1] But I don't think someone said "let's write this code really badly and just buy bigger machines". Could be wrong, just never heard anyone say that. On the other hand, I do almost universally see people prioritize the next "critical" feature over clearing the bug tracker. So if you said for example "fixing customer-reported memory leaks always takes priority over new features" that'd be making a real, controversial taste choice.

[1] ...and my guess is this was a poorly written application—keeping around reachable references too long, thus forbidding GC from cleaning them up, rather than a flawed Java GC algorithm that didn't detect the parent was also unreachable in a timely way.

h1fra

3 months ago

Good taste is what I do; bad taste is what others do

cjfd

3 months ago

I think it is true. Also as a hiring criterion. Does this person know how to say 'it depends'?

neximo64

3 months ago

This is exactly what bad taste is. Not one mention of if the software is actually 'good' to use for the end user.

Daub

3 months ago

I'm not entirely sure what op means by good taste in this context.

If we can seperate good taste from best practice, it's that good taste is commonly associated with restraint and economy. Hence, no one can say that Liberace or Elvis had good taste. On the other hand best practice is primarily governed by efficiency and is driven by commonly practiced principles.

ramon156

3 months ago

I feel like the last point "development speed" is dependent on all previous points.

When I do a new project I always try to focus on a tech stack where - if i need to replace a part - i could easily do so. All these components are part of the decision

kingkongjaffa

3 months ago

I was nodding along to this. It mostly feels like truisms.

The point about varying levels of skill vs taste is accurate in my experience.

I think I fall into the more taste than skill camp, although neither are particularly large in an absolute sense.

I switched to product management quite early in my career and pivoted to learning design and product “taste” more than software engineering.

What is 'good taste' in software engineering?

Resources