> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position.
I have come across this although I think quite experienced engineers can suffer from this kind of immaturity.
Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't like the way it worked. I would start to do so and then, eventually, think that it was going to take ages and be unrecognisable to them. How could I help them by rejecting everything they thought?
I'd think about it again and realise that they weren't idiots - their approach probably could work with a couple of adjustments. I helped them make those adjustments and they were happy because they could understand the result.
After that I would find that my own way of thinking about the problem had changed and my own code would get much better from having seen the problem from a different angle. I should really have been the one thanking them.
I am still like this - still prejudiced - but in the back of my mind I know it and when I'm being sensible I remember to try to give the other viewpoint a proper chance and be happy when it really turns out to have more merit.
Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.
I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.
Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.
You still have to be sensible in the way how you ask questions. Very possible to intentionally or unintentionally insult and trigger lots of other things just by "asking a question" (my speciality).
I try to channel Terry Gross. “You say it’s very important to frob the encabulator before and after you linearize the splines? Interesting, tell me more about that.” I don’t just want to correct bad code, I want to understand the misunderstandings that produced it and fix those. Otherwise you just wind up with more bad code.
"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well.
In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)
Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform.
The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others.
Since then, I'm of the opinion you should aim to work with both the good and the bad to clarify the "why" of things.
I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why.
In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad tradeoffs, rather than the actual code itself.
It works better if you “split the axis”; (imo) good code is easy to modify, bad code is hard to understand. Everything else is, as you say, trade offs, and so only evaluatable within a specific context.
I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them.
I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths.
In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well.
In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.
The solution for prejudice, bias, and rigid thinking in general is education and experience outside of your personal worldview. Actively trying to understand the world through someone else's perspective is how you grow as a person/professional and expand your own perspective.
As an engineer and a strong generalist, I find that simply knowing that another angle or solution exists is enough to change my view of a problem and come up with solutions that are better than my first instinct.
This is why I like experimenting with lots of different programming languages, and why I try to make the next language to understand as different as the ones I know, as I'm having these "epiphanies" all the time, challenging my existing views, which I can apply across languages when suitable. You just need to accept that things feel "wrong" and "weird" initially, before you've grokked the whys and hows.
Your way of thinking is how I like to handle my direct hires. And people on a project that may not be my direct hires.
Recognize that there are different ways to get things done. Not everything needs to please my specifics, process, etc. if the end result or goal is met
>> I have come across this although I think quite experienced engineers can suffer from this kind of immaturity.
Experience does not always result in maturity. It is actually pretty common for engineers to become more set in their ways as they gain experience, especially if they've seen some success, because that success has convinced them that the way they do things is the right way.
I think a big part of it is also moving your value system from the code to people and you'll make this migration naturally.
Any code can be made perfect, but what could you help the person across the table with to make it good enough and also improve their understanding given their priors. Making the code perfect will simply be a bridge too far for them (and generally just means coding it up to your level of incompetence anyway.)
I had exactly the same experience with giving CS assignment help. Although at the time, I didn't quite have the wisdom to work within their existing approach and tended towards more radical rewrites. Not that I thought they were idiots, I just didn't like their approaches - and didn't take the time to try to understand them.
> Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.
I think there’s a very important developmental stage for programmers where they buy in to a set of principles past the point of all reason. It can be maddening to work with them at this stage. They’re all in on type systems or OOP or hexagonal architecture or what have you, and everything looks like a nail for that hammer. But eventually, some of them see the shortcomings of the one true way and come out better programmers for it.
It helps to remember that all code is bad, including your own code, and that includes your best code. You can make it a bit better, but it's still bad, and one should feel bad if they judge someone else based on their code.
I think that with experience, great programmers learn to recognize and differentiate subjective parts of software engineering form the objective ones; and then to have more lax and open approach to the former and stricter to the latter
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.)
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.
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.
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.
> 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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".
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".
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.
> 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?
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?
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.
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.
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).
"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.
>"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.
>> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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).
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?
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...
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.
> 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.
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
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.
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.
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).
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 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.
+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
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.
> 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.
I don't exactly disagree, but I also don't like how this article confounds concepts and considers the idea that "people value different things" in a bit of a vacuum.
Usually I would expect an engineer to be able to gauge roughly "what values" are most important in a given practical context. Let's call those the "hard constraints" of the problem being solved. Let's set the hard constraints aside and consider "taste" only in the context of the remaining degrees of liberty.
In other words, we often impose on ourselves additional constraints that are not strictly necessary. An artist in a given context may technically be required to use oil paint and a 4x6 canvas. But the work product will be judged on what additional constraints (or lack thereof) the artist plays by.
As a rule of thumb, I'll stick my neck out and say that good software engineering taste, while notionally similar to artistic taste, is unique in that it is 1) aesthetically minimalist, and; 2) maximalist in self-restraint.
I think the notion of taste still eludes this description, but whenever I've encountered something I found truly in bad taste, it usually went counter to these principles for no obvious reason: in other words it was sacrificing something without any benefit. Oftentimes bad taste is taking a loss and calling it a tradeoff: in my experience this often occurs when people confuse simplicity for familiarity.
I find a lot of these articles conflate two issues, which I have seen mentioned in some of the other comments.
1) There are objectively bad decisions that you can make regardless of "taste" or principles. If you search a list in O(n) for an items key, it is objectively worse than using a dictionary with O(1) search in most cases. It is not about taste or readability, there is a right way and a wrong way (or multiple right ways and multiple wrong ones).
2) Everything else is a matter of trade-offs. Map reduce or a loop? It depends entirely on performance requirements, what reads better in a specific scenario, maybe browser compatability or whatever but as long as the trade-offs are considered, I won't get bitchy to another Dev who decides that one is better than the other although I might disagree.
If something is wrong or the trade-offs haven't been considered though, that is a question of maintenance: do we care enough, is the performance bad enough, is the code visited enough to change it? In a lot of cases, the app will be deleted before it becomes a problem but it is still a question of trade-offs.
As someone said below, as long as someone has considered the "why" then its all fair game. I'm not sure that any of this is "taste" though.
Having architected some large projects, then coded, then refactored because original designs didnt work out, eventually getting a working project that does things.
Also now having done the same thing 95% ai coding.
Good taste is good architecting. Knowing what to use; how to use it and when. How to maximize KISS. Simplicity is key.
When is it right to keep it very simple and load it to a dict? When to upgrade to a panda/numpy dataframe? When to go sqlite3? When to go full on DB(postgresql?). Do you need to go that extra step in order to stay with your current design; will the code become complicated and ugly to do that? What are the upsides and downsides?
good taste is the comfort to try a new library that looks like it'll do a better job than what you know how to use now.
Does your script run in memory for long? Is that ok?
Good taste often comes from experience. And not just any experience, either. It comes from working with other peoples' "great ideas" and "brilliant hacks" and "genius architectures". When you're the person having to maintain them a decade later, you start to see whether they were great and brilliant and genius, or just clever but bad ideas. You start to develop a taste that says "that feels too complicated for what it does" or "that's not clear enough". Or, sometimes, "yeah, that really is about as simple as it can be."
It's hard to defend that taste to someone who doesn't have it. They say, "Yeah, well, that's just, like, your opinion, man". And in fact they're right. But it's an opinion honed by a fair amount of real-world experience, of seeing how fine-sounding ideas fail to work out in the long run.
The “values” in this article maps to Roy Fielding’s PhD dissertation on software architecture. Fielding’s dissertation is better known for REST, but his dissertation is much broader and more versatile. He actually organized a way to think about and reason about any software architecture and then presented REST as an example.
The “values” mentioned in this article maps to the architectural properties (versatility, scalability, observability, readability, maintainability, etc.), but I have found that understanding architectural constraints is even more important because that tells you where anti-patterns are, and how an architecture can evolve (or not evolve).
Bad Taste Leads to X; We're trying to avoid X. To me, it is closely aligned to predicting the future of a code base. So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.
> So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.
Absolutely! But also be careful not to over-engineer a solution for a situation that never appeared
- 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
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".
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" :(
> 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.
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.
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.
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".
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.
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.
This news story about AI simulating taste reads like a romantic dance between technology and humanity. It quietly suggests: One day, when you long for your grandmother's braised pork, you may no longer have to search through a faded recipe—AI can "taste" the perfect amount of sugar color and cooking time through the screen, allowing the flavors of memory to transcend time and space. Most touchingly, this technology attempts to gently translate the most intimate human sensory experiences—those indefinable "mother's taste" and "first love's dessert"—into the language of data. It's like a time machine for the sense of taste, immortalizing the destined-to-disappear world of everyday life in the digital world. When algorithms begin to understand the nostalgia inherent in sweet and sour spare ribs, technology truly possesses the warmth of humanity
> What kind of code “looks good” to you? What kind of code “looks ugly”?
IMO this is not taste, it's your pattern recognition skill based on what you think is better in terms of correctness, performance and maintainability.
> Which design decisions you feel really good about, and which ones are just fine?
It's not just a feeling, it comes from reasoning.
Good taste == good skill isn't it?
When someone chooses a functional lang over an object oriented one - is this because of better taste? They’ve learned, through experience, what kinds of problems map more cleanly to immutability and composition versus encapsulation and state. Their "taste" for one paradigm over another is just a reflection of the skills they’ve built up in recognizing tradeoffs, debugging pain points, and anticipating long-term maintainability. What looks like taste is really just expertise shaping intuition.
I get why the author feels a team member who doesn't align with the team's goals has bad taste. But it's really just this - the opinions they have formed from their experience don't match yours.
>> Personally, I feel like code that uses map and filter looks nicer than using a for loop
This is definitely not a taste thing. They are both useful in different scenarios.
For example if using async/await, you can use Promise.all with a map to execute some code on multiple elements in parallel. But if you want to execute the code on them sequentially, you NEED a for loop.
There are many situations where the second approach may be better for example you are calling an API with rate limiting and want to spread out your calls, one at a time, intentionally.
Sometimes I use both; if the amount of data is large; I break it up into batches. I use a for loop on the outside to execute each batch in series but then inside the loop I use Promise.all with a map to execute the items in the batch in parallel... And I make the batch size configurable depending on the capacity of the server.
Since this is just arguing over a definition, the best take I can give is what definition has proved most useful to me in the past.
That is thinking of taste as the ability to recognize something as good or bad when seeing or hearing a description of it, usually without it actually existing.
Let's say I have a plan for a new feature and a way of building it, if I show it to someone with good taste, they will be better at telling me if it's going to work out, and how valuable it will be to users, than someone with bad taste.
Viewed this way, it's almost quantifiable, and at the very least: good developers can usually agree on who has good taste. You can tell based on their actions not words. They will go out of their way to get feedback from people with good taste. IME the people with the best taste for a product are power users and evangelists.
> 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.
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).
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.
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.
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.
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.
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. :)
There's a deep fear that software engineering can't be reduced to correct and incorrect like a math formula or the scientific method. This leads to rigidity, and I'm glad there are articles like this calling it out.
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".
> 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.
> "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"
> 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.
I find that when people value vanity or discussions of how to proceed their confidence is low. These are red flags for me. It’s assumed that if you aren’t a junior you should be able to immediately reason multiple original routes to the goal.
I suppose the most important matter of “taste” is how deterministic the flow control is by just reading the code. It doesn’t have to be pretty. When this is absent I know the author values something other than maintenance or extension. When it’s hidden behind cultural conventions, like a framework, I know the author values those learned conventions more than a utility goal or objective criteria.
Since these observations reflect behavior they apply equally to many other non-code contexts in the real world.
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
This might count as "Readability" but it is more structural. If it is easy to remember how a system works it is a real benefit. This isn't traditional "simplicity" necessarily either. A system containing a lot of simple code doing simple things, together might be hard to remember in aggregate. I'm not sure what this metric is called but if I can't remember how something works a year after creation, it fails the test.
>> Languages like Golang don’t contain map and filter at all, for principled reasons.
Go is nice when working with other languages at the same time as there are few language specific things to remember. However, they really should add common things that exist in almost every other language (I'd argue map / filter would be good to have for instance). It isn't really easier if it is "simple" but unique to the language.
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.
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".
"How do you develop good taste? It’s hard to say, but I’d recommend working on a variety of things, paying close attention to which projects (or which parts of the project) are easy and which parts are hard. You should focus on flexibility: try not to acquire strong universal opinions about the right way to write software. "
> In other words, our disagreement comes down to a difference in values.
I don't think that's the whole story.
Us humans are not very good at recognizing it, but we all model and understand the world slightly differently.
So that even if you fundamentally agree with someone's values, you might prefer other code to that person because it fits better in the way a problem is modelled in your brain than in someone else's.
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"?
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.
I wish people tried to formalize what a "good taste" is in programming.
Here's a simple programming language - combinatory logic with S and K combinators, and you can create a new combinator by naming any expression of combinators, and use it.
What constitutes a "tasteful" or "readable" program in this language?
"Taste" is developed. If you have to stop and ask, you are not there yet. In the arts, artist that drive taste quietly observe and hone that in over many years, releasing works that drive people in that direction.
In addition to that, all of the real people with great taste I meet, are not out there talking about it. They confidently spread it.
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.
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".
i wouldn't use a phrase like "good taste", i would use readable, understandable, and maintainable instead. Good taste in software engineering sounds like good taste in music which basically boils down to stop liking what i don't like.
I'm not sure taste is a meaningful term in anything other than aesthetics.
One argument here was that good taste is about being flexible when picking technical solutions - I don't see how this is "good taste".
Readability and maintainability. When a new change is short you know the code has good maintainability, when you have to touch 30 classes to make a change, you know the code is not that well written.
Good taste implies there is more than taste. It implies there is a true nature of things and what we call taste is a recognition of things that are true to their nature.
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.
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 :-)
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.
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.
> 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.
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?
> 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.
> 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.
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.
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".
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.
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... ;)
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, ...
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.
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.
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.
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.
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.
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").
> good taste is the ability to select the right set of engineering values for the particular technical problem you’re facing
I don't think this makes sense. Firstly because engineering values aren't the same thing as engineering requirements; I don't want someone's "values" to end up making a product unsafe or unreliable (these aren't "taste", they're non-negotiable requirements). But secondly because, in engineering at least, your personal opinions shouldn't matter.
Taste is all about opinion and self-expression. Your taste is different than my taste? That's fine. Your engineering is different than my engineering? That's not fine. The same building, with the same architectural plans, same location, same everything, shouldn't be built 6 different ways depending on the "taste" of the engineer. Trusses and struts aren't to your "taste"? Tough luck, buddy. Engineering is about precision, science, math. It's not a plate of spaghetti.
A PR could be said to be a "review of taste", that nit-picks in a PR are just judgements of personal taste. But that's not what PRs are supposed to be. They're actually a replacement for QA. In normal products, a Quality Assurance process is a secondary one that verifies products are built correctly. But in software engineering today, PRs take the place of QA (and design reviews). This means a PR isn't about taste, but about quality.
Higher quality implies good taste, but they aren't the same thing. Style, fit, context, etc are as much a component of "taste" as quality is. Therefore I think "taste" in software engineering should be limited to the optional or irrelevant parts. All the things that you care about, but don't actually affect the engineering quality of the end result. And if that's true, then it means we probably need to have hard definitions of what affects engineering quality.
For example: most people would argue that variable names are very important. That how you name a variable affects its "maintainability". But in reality, the names could be random, and the program would operate the same way. That doesn't mean that variable names are irrelevant. But it does mean there's a categorical difference in what it is, and why it's important. That needs to be codified and taught to new CS students.
> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position.
I have come across this although I think quite experienced engineers can suffer from this kind of immaturity.
Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't like the way it worked. I would start to do so and then, eventually, think that it was going to take ages and be unrecognisable to them. How could I help them by rejecting everything they thought?
I'd think about it again and realise that they weren't idiots - their approach probably could work with a couple of adjustments. I helped them make those adjustments and they were happy because they could understand the result.
After that I would find that my own way of thinking about the problem had changed and my own code would get much better from having seen the problem from a different angle. I should really have been the one thanking them.
I am still like this - still prejudiced - but in the back of my mind I know it and when I'm being sensible I remember to try to give the other viewpoint a proper chance and be happy when it really turns out to have more merit.
Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.
I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.
Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.
You still have to be sensible in the way how you ask questions. Very possible to intentionally or unintentionally insult and trigger lots of other things just by "asking a question" (my speciality).
I try to channel Terry Gross. “You say it’s very important to frob the encabulator before and after you linearize the splines? Interesting, tell me more about that.” I don’t just want to correct bad code, I want to understand the misunderstandings that produced it and fix those. Otherwise you just wind up with more bad code.
"Do you know where you are wrong ?" will definitely trigger people's defense
This is why I never went into CS educationally. I was never treated in a respectful way by the Polish system. Always treated like ass
"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well.
In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)
I think this is only half of it.
Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform.
The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others.
Since then, I'm of the opinion you should aim to work with both the good and the bad to clarify the "why" of things.
I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why.
In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad tradeoffs, rather than the actual code itself.
It works better if you “split the axis”; (imo) good code is easy to modify, bad code is hard to understand. Everything else is, as you say, trade offs, and so only evaluatable within a specific context.
I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them.
I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths.
In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well.
In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.
I don't think code is inherently bad or good without defining the exact context and purpose of the code.
It all depends on what field you are in, the business requirements, the team and so many other factors.
What is the most important aspect: Easy to extend, easy to read or most optimal performance?
Is your team more comfortable with the functional style of programming or OO?
Do you follow existing conventions your team has established or current best practices?
Do you implement everything yourself or do you use external libraries?
Do you write code that makes you look smart using tech that looks good on your resume or do you use the simplest method to solve the program?
The is no one right way to program.
> Do you write code that makes you look smart using tech that looks good on your resume
> The is no one right way to program.
Those two statements taken together makes me suspect you think there is.
I do. I am not free of an ego. I just try to not confuse my taste for objective good or wrong though I sometimes fail.
The solution for prejudice, bias, and rigid thinking in general is education and experience outside of your personal worldview. Actively trying to understand the world through someone else's perspective is how you grow as a person/professional and expand your own perspective.
As an engineer and a strong generalist, I find that simply knowing that another angle or solution exists is enough to change my view of a problem and come up with solutions that are better than my first instinct.
This is why I like experimenting with lots of different programming languages, and why I try to make the next language to understand as different as the ones I know, as I'm having these "epiphanies" all the time, challenging my existing views, which I can apply across languages when suitable. You just need to accept that things feel "wrong" and "weird" initially, before you've grokked the whys and hows.
What a great comment.
Your way of thinking is how I like to handle my direct hires. And people on a project that may not be my direct hires.
Recognize that there are different ways to get things done. Not everything needs to please my specifics, process, etc. if the end result or goal is met
>> I have come across this although I think quite experienced engineers can suffer from this kind of immaturity.
Experience does not always result in maturity. It is actually pretty common for engineers to become more set in their ways as they gain experience, especially if they've seen some success, because that success has convinced them that the way they do things is the right way.
This principle (sorry ;)) is applicable to all domains. I'd wish I would remember this more often. Thank you for the gentle reminder!
It's close to the mantra "strong opinions, loosely held", which I appreciate a lot.
I think a big part of it is also moving your value system from the code to people and you'll make this migration naturally.
Any code can be made perfect, but what could you help the person across the table with to make it good enough and also improve their understanding given their priors. Making the code perfect will simply be a bridge too far for them (and generally just means coding it up to your level of incompetence anyway.)
I had exactly the same experience with giving CS assignment help. Although at the time, I didn't quite have the wisdom to work within their existing approach and tended towards more radical rewrites. Not that I thought they were idiots, I just didn't like their approaches - and didn't take the time to try to understand them.
> Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.
I think there’s a very important developmental stage for programmers where they buy in to a set of principles past the point of all reason. It can be maddening to work with them at this stage. They’re all in on type systems or OOP or hexagonal architecture or what have you, and everything looks like a nail for that hammer. But eventually, some of them see the shortcomings of the one true way and come out better programmers for it.
It helps to remember that all code is bad, including your own code, and that includes your best code. You can make it a bit better, but it's still bad, and one should feel bad if they judge someone else based on their code.
I think that with experience, great programmers learn to recognize and differentiate subjective parts of software engineering form the objective ones; and then to have more lax and open approach to the former and stricter to the latter
Maturity is not exactly correlated to time in experience, just as emotional and social maturity doesn’t exactly correlate with biological age.
I was 12 years into my career before the ideas in this article started filtering into my mind.
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.)
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.
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.
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.
> 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.
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.
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.
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.
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
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.
Yeah the Linux language gets most people's goats......
Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
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.
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.
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.
I thought by 72 they were using the electronic ignition module instead of points? I thought MY72 was the year it was introduced even?
The electronic ignition was an option at the time.
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.
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.
> Modern cars are more reliable
I would hope so, after 55 more years of development!
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.
My life as the leader of the D team is one of a constant battle against complexity.
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.
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.
> 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...
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.
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
> 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.
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.
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.)
One is an algorithm, a purely technical solution. The other is the way code is structured in an application.
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
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.
That's not good taste, it's good engineering.
./venn diagram comments...
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.
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".
Sometimes, simple code is viewed as an invitation to make it more complicated.
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".
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
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.
Do you mean local variables per se, or mutable local variables? Clojure, like most Lisps has let.
> 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?
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?
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.
Did someone claim readability does not exist?
> Readability is a non-concept really
Yes.
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.
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).
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.
>"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.
>> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Sure, but we do agree that Hello World is MORE¹ readable in Python compared to the equivalent program in say Brainfuck?
vs ¹: more readable means easier/faster to read for most human beings that know the languageI can't reasonably read whether this comment agrees or disagrees with the parent
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.
> 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
+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.
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).
Completely agree. Readability is actually in the word itself read + ability. The ability of both the code and the reader.
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?
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...
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.
> 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.
> 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.
Can you paint an example of a "partially broken compass" engineer?
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
becomes: Which is.... technically correct, instead ofI’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.
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.
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).
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.
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.
+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
Your phrasing makes it sound like you’re playing the same childish game they are; you just rank yourself higher than them.
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.
> 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.
so... you're suggesting I take things off my resume to avoid making interviewers feel bad?
I don't exactly disagree, but I also don't like how this article confounds concepts and considers the idea that "people value different things" in a bit of a vacuum.
Usually I would expect an engineer to be able to gauge roughly "what values" are most important in a given practical context. Let's call those the "hard constraints" of the problem being solved. Let's set the hard constraints aside and consider "taste" only in the context of the remaining degrees of liberty.
In other words, we often impose on ourselves additional constraints that are not strictly necessary. An artist in a given context may technically be required to use oil paint and a 4x6 canvas. But the work product will be judged on what additional constraints (or lack thereof) the artist plays by.
As a rule of thumb, I'll stick my neck out and say that good software engineering taste, while notionally similar to artistic taste, is unique in that it is 1) aesthetically minimalist, and; 2) maximalist in self-restraint.
I think the notion of taste still eludes this description, but whenever I've encountered something I found truly in bad taste, it usually went counter to these principles for no obvious reason: in other words it was sacrificing something without any benefit. Oftentimes bad taste is taking a loss and calling it a tradeoff: in my experience this often occurs when people confuse simplicity for familiarity.
I find a lot of these articles conflate two issues, which I have seen mentioned in some of the other comments.
1) There are objectively bad decisions that you can make regardless of "taste" or principles. If you search a list in O(n) for an items key, it is objectively worse than using a dictionary with O(1) search in most cases. It is not about taste or readability, there is a right way and a wrong way (or multiple right ways and multiple wrong ones).
2) Everything else is a matter of trade-offs. Map reduce or a loop? It depends entirely on performance requirements, what reads better in a specific scenario, maybe browser compatability or whatever but as long as the trade-offs are considered, I won't get bitchy to another Dev who decides that one is better than the other although I might disagree.
If something is wrong or the trade-offs haven't been considered though, that is a question of maintenance: do we care enough, is the performance bad enough, is the code visited enough to change it? In a lot of cases, the app will be deleted before it becomes a problem but it is still a question of trade-offs.
As someone said below, as long as someone has considered the "why" then its all fair game. I'm not sure that any of this is "taste" though.
Good taste, is what I like and advocate for. Bad taste, is the opposite.
You never advocated for something you agree is a huge kludge? :)
I think first step of having good taste is admitting that you probably have bad taste
Having architected some large projects, then coded, then refactored because original designs didnt work out, eventually getting a working project that does things.
Also now having done the same thing 95% ai coding.
Good taste is good architecting. Knowing what to use; how to use it and when. How to maximize KISS. Simplicity is key.
When is it right to keep it very simple and load it to a dict? When to upgrade to a panda/numpy dataframe? When to go sqlite3? When to go full on DB(postgresql?). Do you need to go that extra step in order to stay with your current design; will the code become complicated and ugly to do that? What are the upsides and downsides?
good taste is the comfort to try a new library that looks like it'll do a better job than what you know how to use now.
Does your script run in memory for long? Is that ok?
Recently I learnt about Python Slots and use them now. You look at: https://www.w3schools.com/python/python_datatypes.asp
And for some reason they dont even mention slots. but omg so much better!
Same here with regards to large systems, refactoring, and then getting things working.
I believe that is what builds taste: varied experience.
Good taste often comes from experience. And not just any experience, either. It comes from working with other peoples' "great ideas" and "brilliant hacks" and "genius architectures". When you're the person having to maintain them a decade later, you start to see whether they were great and brilliant and genius, or just clever but bad ideas. You start to develop a taste that says "that feels too complicated for what it does" or "that's not clear enough". Or, sometimes, "yeah, that really is about as simple as it can be."
It's hard to defend that taste to someone who doesn't have it. They say, "Yeah, well, that's just, like, your opinion, man". And in fact they're right. But it's an opinion honed by a fair amount of real-world experience, of seeing how fine-sounding ideas fail to work out in the long run.
The “values” in this article maps to Roy Fielding’s PhD dissertation on software architecture. Fielding’s dissertation is better known for REST, but his dissertation is much broader and more versatile. He actually organized a way to think about and reason about any software architecture and then presented REST as an example.
The “values” mentioned in this article maps to the architectural properties (versatility, scalability, observability, readability, maintainability, etc.), but I have found that understanding architectural constraints is even more important because that tells you where anti-patterns are, and how an architecture can evolve (or not evolve).
https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
Bad Taste Leads to X; We're trying to avoid X. To me, it is closely aligned to predicting the future of a code base. So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.
> So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.
Absolutely! But also be careful not to over-engineer a solution for a situation that never appeared
You can never predict with 100% certainty, unless you're building a clone.
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)
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".
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" :(
> 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.
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.
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.
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".
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.
I think we mostly agree here. I just found the preemption curious.
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.
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.
So who has the good taste when two different people distinguish the same code base differently?
> So who has the good taste when two different people distinguish the same code base differently?
The person with the good taste.
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.
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.
This news story about AI simulating taste reads like a romantic dance between technology and humanity. It quietly suggests: One day, when you long for your grandmother's braised pork, you may no longer have to search through a faded recipe—AI can "taste" the perfect amount of sugar color and cooking time through the screen, allowing the flavors of memory to transcend time and space. Most touchingly, this technology attempts to gently translate the most intimate human sensory experiences—those indefinable "mother's taste" and "first love's dessert"—into the language of data. It's like a time machine for the sense of taste, immortalizing the destined-to-disappear world of everyday life in the digital world. When algorithms begin to understand the nostalgia inherent in sweet and sour spare ribs, technology truly possesses the warmth of humanity
Principled engineering should be taken for granted. You can exercise it whether you are dealing with good taste or bad taste.
The reverse is not true; you cannot really exercise good taste whether you have good engineering or shitty engineering.
Bad taste can hamper engineering but not make it impossible; bad engineering renders taste moot.
Engineering serves taste, mainly.
Consider that something well-engineered can be entirely unnecessary and unwelcome.
> What kind of code “looks good” to you? What kind of code “looks ugly”? IMO this is not taste, it's your pattern recognition skill based on what you think is better in terms of correctness, performance and maintainability.
> Which design decisions you feel really good about, and which ones are just fine? It's not just a feeling, it comes from reasoning.
Good taste == good skill isn't it?
When someone chooses a functional lang over an object oriented one - is this because of better taste? They’ve learned, through experience, what kinds of problems map more cleanly to immutability and composition versus encapsulation and state. Their "taste" for one paradigm over another is just a reflection of the skills they’ve built up in recognizing tradeoffs, debugging pain points, and anticipating long-term maintainability. What looks like taste is really just expertise shaping intuition.
I get why the author feels a team member who doesn't align with the team's goals has bad taste. But it's really just this - the opinions they have formed from their experience don't match yours.
>> Personally, I feel like code that uses map and filter looks nicer than using a for loop
This is definitely not a taste thing. They are both useful in different scenarios.
For example if using async/await, you can use Promise.all with a map to execute some code on multiple elements in parallel. But if you want to execute the code on them sequentially, you NEED a for loop.
There are many situations where the second approach may be better for example you are calling an API with rate limiting and want to spread out your calls, one at a time, intentionally.
Sometimes I use both; if the amount of data is large; I break it up into batches. I use a for loop on the outside to execute each batch in series but then inside the loop I use Promise.all with a map to execute the items in the batch in parallel... And I make the batch size configurable depending on the capacity of the server.
I believe technical taste is a form of curiosity; it grows as you explore different paradigms and seek out good-quality software for your craft.
While many people program only for the salary, this lacks the obsession that good taste requires.
We can often recognize a person's taste by the content they share over their feeds.
Since this is just arguing over a definition, the best take I can give is what definition has proved most useful to me in the past. That is thinking of taste as the ability to recognize something as good or bad when seeing or hearing a description of it, usually without it actually existing.
Let's say I have a plan for a new feature and a way of building it, if I show it to someone with good taste, they will be better at telling me if it's going to work out, and how valuable it will be to users, than someone with bad taste.
Viewed this way, it's almost quantifiable, and at the very least: good developers can usually agree on who has good taste. You can tell based on their actions not words. They will go out of their way to get feedback from people with good taste. IME the people with the best taste for a product are power users and evangelists.
> 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.
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).
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.
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.
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.
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.
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. :)
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.
There's a deep fear that software engineering can't be reduced to correct and incorrect like a math formula or the scientific method. This leads to rigidity, and I'm glad there are articles like this calling it out.
"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
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.
> 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.
> "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"
> 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.
I find that when people value vanity or discussions of how to proceed their confidence is low. These are red flags for me. It’s assumed that if you aren’t a junior you should be able to immediately reason multiple original routes to the goal.
I suppose the most important matter of “taste” is how deterministic the flow control is by just reading the code. It doesn’t have to be pretty. When this is absent I know the author values something other than maintenance or extension. When it’s hidden behind cultural conventions, like a framework, I know the author values those learned conventions more than a utility goal or objective criteria.
Since these observations reflect behavior they apply equally to many other non-code contexts in the real world.
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
This might count as "Readability" but it is more structural. If it is easy to remember how a system works it is a real benefit. This isn't traditional "simplicity" necessarily either. A system containing a lot of simple code doing simple things, together might be hard to remember in aggregate. I'm not sure what this metric is called but if I can't remember how something works a year after creation, it fails the test.
>> Languages like Golang don’t contain map and filter at all, for principled reasons.
Go is nice when working with other languages at the same time as there are few language specific things to remember. However, they really should add common things that exist in almost every other language (I'd argue map / filter would be good to have for instance). It isn't really easier if it is "simple" but unique to the language.
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.
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".
Interesting article; one of the best takeaways:
"How do you develop good taste? It’s hard to say, but I’d recommend working on a variety of things, paying close attention to which projects (or which parts of the project) are easy and which parts are hard. You should focus on flexibility: try not to acquire strong universal opinions about the right way to write software. "
> In other words, our disagreement comes down to a difference in values. I don't think that's the whole story.
Us humans are not very good at recognizing it, but we all model and understand the world slightly differently.
So that even if you fundamentally agree with someone's values, you might prefer other code to that person because it fits better in the way a problem is modelled in your brain than in someone else's.
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"?
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.
I wish people tried to formalize what a "good taste" is in programming.
Here's a simple programming language - combinatory logic with S and K combinators, and you can create a new combinator by naming any expression of combinators, and use it.
What constitutes a "tasteful" or "readable" program in this language?
"Taste" is developed. If you have to stop and ask, you are not there yet. In the arts, artist that drive taste quietly observe and hone that in over many years, releasing works that drive people in that direction.
In addition to that, all of the real people with great taste I meet, are not out there talking about it. They confidently spread it.
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.
I heard readability is a touchy subject since some people say having your code easy to read would make replacing you easier.
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".
i wouldn't use a phrase like "good taste", i would use readable, understandable, and maintainable instead. Good taste in software engineering sounds like good taste in music which basically boils down to stop liking what i don't like.
Tabs instead of spaces.
Spaces have won already. It is the default setting across code editors now.
If your code editor told you to use PHP, would you?
Would that mean it's good taste?
Elastic tabstops are good taste. Tabs should tabulate.
But limited editor support, and some implementations have poor performance.
https://nick-gravgaard.com/elastic-tabstops/
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...
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?
For one tokenizer, a couple years ago.
I'm not sure taste is a meaningful term in anything other than aesthetics. One argument here was that good taste is about being flexible when picking technical solutions - I don't see how this is "good taste".
Discussing subjective things as if they are objective has to be what bad taste is
Names: Alan Kay, Ted Nelson, Douglas Engelbart, Dan Ingalls, Jef Raskin, Larry Tesler, Brenda Laurel, Bret Victor
Technologies: Erlang, Smalltalk(s), Lisp, Clojure, Query By Example, Programming By Demonstration, Logo
Hardware: Canon Cat, Xerox Alto/Star, Sketchpad, PDP-11, PERQ Workstation, SGI workstations, OLPC
Books: Computers As Theatre Second Edition, Computer Lib, "As We May Think" by Bush, Engelbart's 62' paper, Mindstorms by Seymour Papert.
Links:
https://worrydream.com/refs/Papert_1980_-_Mindstorms,_1st_ed...
https://archive.org/details/humaneinterfacen00rask
https://www.dougengelbart.org/mousesite/EngelbartPapers/Cont...
https://courses.cs.umbc.edu/471/papers/turing.pdf (for the AGI fuckheads)
Readability and maintainability. When a new change is short you know the code has good maintainability, when you have to touch 30 classes to make a change, you know the code is not that well written.
Not including dozens of packages from peoples random github repos.
Good taste implies there is more than taste. It implies there is a true nature of things and what we call taste is a recognition of things that are true to their nature.
No need to contemplate platonic ideals; we've all experienced code that is relatively easy to read and modify, performs well, handles error well, etc.
The author's definition of taste as a prioritization of various engineering values is one we can understand based on experience.
Id settle for "common sense" - seems to lack in a lot of codebases
Which doesn't exist, because it's not "common".
I’d suggest reading Hammond’s, The Art of Doing Science and Engineering. He literally ran a course to help people develop, “taste.”
For others trying to find this, the author's name appears to be Richard W. Hamming.[0] [1]
[0] Of Hamming distance fame
[1] Here's a link to the Wikipedia article about the book: https://en.wikipedia.org/wiki/The_Art_of_Doing_Science_and_E...
Oops, sorry. Was typing on my phone and misremembered his name! That’s the one.
> 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.
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 :-)
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.
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...
> 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.
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?
> 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.
> 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.
> 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...
Well, he can start citing Martin Fowler or Bertrand Meyer. Then what?
Arguments from authority lead no where here. Because these "authorities" also disagree.
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.
These are the posts I’m coming to HN for.
Great dimension to look at!
Good taste is what I do; bad taste is what others do
This is exactly what bad taste is. Not one mention of if the software is actually 'good' to use for the end user.
Every programmer now checking if hey ad good taste and who doesn’t. A ultimately waste of time
I think it is true. Also as a hiring criterion. Does this person know how to say 'it depends'?
It's what I have, and you don't.
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".
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.
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... ;)
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, ...
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.
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.
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.
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.
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.
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").
> good taste is the ability to select the right set of engineering values for the particular technical problem you’re facing
I don't think this makes sense. Firstly because engineering values aren't the same thing as engineering requirements; I don't want someone's "values" to end up making a product unsafe or unreliable (these aren't "taste", they're non-negotiable requirements). But secondly because, in engineering at least, your personal opinions shouldn't matter.
Taste is all about opinion and self-expression. Your taste is different than my taste? That's fine. Your engineering is different than my engineering? That's not fine. The same building, with the same architectural plans, same location, same everything, shouldn't be built 6 different ways depending on the "taste" of the engineer. Trusses and struts aren't to your "taste"? Tough luck, buddy. Engineering is about precision, science, math. It's not a plate of spaghetti.
A PR could be said to be a "review of taste", that nit-picks in a PR are just judgements of personal taste. But that's not what PRs are supposed to be. They're actually a replacement for QA. In normal products, a Quality Assurance process is a secondary one that verifies products are built correctly. But in software engineering today, PRs take the place of QA (and design reviews). This means a PR isn't about taste, but about quality.
Higher quality implies good taste, but they aren't the same thing. Style, fit, context, etc are as much a component of "taste" as quality is. Therefore I think "taste" in software engineering should be limited to the optional or irrelevant parts. All the things that you care about, but don't actually affect the engineering quality of the end result. And if that's true, then it means we probably need to have hard definitions of what affects engineering quality.
For example: most people would argue that variable names are very important. That how you name a variable affects its "maintainability". But in reality, the names could be random, and the program would operate the same way. That doesn't mean that variable names are irrelevant. But it does mean there's a categorical difference in what it is, and why it's important. That needs to be codified and taught to new CS students.
A: Experience
Have your 10 mins back.
Good taste = pleasurable.
How one defines pleasure? Depends. Simplicity is certainly a dimension.