> 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.
"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.
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 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
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 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.
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 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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
>> 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.
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.
> 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.
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.
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.
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.
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).
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.
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?
> 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
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 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.
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.
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.
> 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.
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.
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.
"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 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.
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.
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 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.
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.
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.
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?
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
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.
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".
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.
> 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.
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.
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 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.
- 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".
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.
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 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.
>> 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.
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".
> 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.
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.
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 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.
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... ;)
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.
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 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").
"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 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. :)
> 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.
"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 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.
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.
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 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
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.
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 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.
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.
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 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.
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.
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.
> 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.
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
Yeah the Linux language gets most people's goats......
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.
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.
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.
My life as the leader of the D team is one of a constant battle against complexity.
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.
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.
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.)
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.
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
One is an algorithm, a purely technical solution. The other is the way code is structured in an application.
That's not good taste, it's good engineering.
./venn diagram comments...
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.
Sometimes, simple code is viewed as an invitation to make it more complicated.
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".
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.
> 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.
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.
>> 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.
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.
> 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
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.
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.
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.
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).
+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.
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...
Completely agree. Readability is actually in the word itself read + ability. The ability of both the code and the reader.
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.
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?
> 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 ofOP 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 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.
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.
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
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.
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.
> 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.
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
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.
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.
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.
so... you're suggesting I take things off my resume to avoid making interviewers feel bad?
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.
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.
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.
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 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.
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.
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 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.
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.
"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.
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?
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.
Discussing subjective things as if they are objective has to be what bad taste is
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
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.
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".
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.
> 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.
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.
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".
Not including dozens of packages from peoples random github repos.
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 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".
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.
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)
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.
These are the posts I’m coming to HN for.
Great dimension to look at!
It's what I have, and you don't.
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.
Id settle for "common sense" - seems to lack in a lot of codebases
Which doesn't exist, because it's not "common".
> 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...
>> 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.
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.
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 think it is true. Also as a hiring criterion. Does this person know how to say 'it depends'?
> 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.
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.
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.
Every programmer now checking if hey ad good taste and who doesn’t. A ultimately waste of time
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.
A: Experience
Have your 10 mins back.
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... ;)
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.
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 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").
"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 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. :)