[HN Gopher] What is "good taste" in software engineering?
___________________________________________________________________
What is "good taste" in software engineering?
Author : olayiwoladekoya
Score : 300 points
Date : 2025-09-29 06:41 UTC (16 hours ago)
(HTM) web link (www.seangoedecke.com)
(TXT) w3m dump (www.seangoedecke.com)
| kingkongjaffa wrote:
| 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.
| cjfd wrote:
| I think it is true. Also as a hiring criterion. Does this person
| know how to say 'it depends'?
| ramon156 wrote:
| 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
| lofties wrote:
| Good taste, is what I like and advocate for. Bad taste, is the
| opposite.
| actionfromafar wrote:
| You never advocated for something you agree is a huge kludge?
| :)
| autonomousErwin wrote:
| I think first step of having good taste is admitting that you
| probably have bad taste
| OtherShrezzing wrote:
| > One interesting consequence of this is that engineers with bad
| taste are like broken compasses. If you're in the right spot, a
| broken compass will still point north. It's only when you start
| moving around that the broken compass will steer you wrong.
| Likewise, many engineers with bad taste can be quite effective in
| the particular niche where their preferences line up with what
| the project needs.
|
| This paragraph really gets to the idea of why I think discussing
| someone's taste is basically useless in an engineering context.
| This "predictably broken compass" person stands out like a sore
| thumb, and you can just hold a 20min behavioural interview to
| filter them out.
|
| A far more dangerous engineer is the "partially broken compass",
| which appears at first sight to be working because it spins
| around like you'd expect, but is actually 127degrees off at all
| times.
| medstrom wrote:
| Can you paint an example of a "partially broken compass"
| engineer?
| DavidPiper wrote:
| 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).
| maccard wrote:
| I've worked with engineers who can happily write greenfield
| code that passes the spec, but fails on any inputs that are
| not clearly defined as valid. In an effort to fix this, they
| add layers and layers and layers of complexity and edge cases
| to the app logic, and intermix the actual app logic with
| handling invalid input. something like func
| isEven(s string) bool { num, _ := strconv.Atoi(s)
| return num % 2 == 0 }
|
| becomes: func isEven(s string) (string,
| error) { f, err := strconv.ParseFloat(s, 64)
| if err != nil { return "invalid", err
| } num := int(f) if num%2 == 0 {
| return "even", nil } else if num % 2
| != 0 { return "odd", nil }
| return "invalid", nil }
|
| Which is.... technically correct, instead of
| func isEven(num int) bool { return num % 2 == 0
| } func isEvenSafe(s string) (bool, error) {
| num, err := strconv.Atoi(s) if err != nil {
| return false, err } return
| isEven(num), nil }
| skydhash wrote:
| Also the ones that can't understand abstraction and are
| happy copy-pasters. Or the ones familiar with some
| paradigms (ex OOP) that brings it everywhere.
|
| There are a lot of ways to accumulate tech debt so fast
| you'd think you're in a code casino.
| foofoo12 wrote:
| Tabs instead of spaces.
| cake-rusk wrote:
| Spaces have won already. It is the default setting across code
| editors now.
| foofoo12 wrote:
| Would that mean it's good taste?
| 000ooo000 wrote:
| If your code editor told you to use PHP, would you?
| sparkie wrote:
| Elastic tabstops are good taste. Tabs should tabulate.
|
| But limited editor support, and some implementations have
| poor performance.
|
| https://nick-gravgaard.com/elastic-tabstops/
| aitchnyu wrote:
| 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...
| cap11235 wrote:
| For one tokenizer, a couple years ago.
| zahlman wrote:
| 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?
| gyulai wrote:
| Lecturing on "good taste" is a huge red flag for narcissism.
| "Taste" implies subjectivity. Pairing it with "good" is
| presupposing something along the lines of "my subjective
| evaluation of things is superior to yours", or "my subjective
| choices are superior to yours".
| antirez wrote:
| That's exactly how it works in most fields that are not purely
| engineering but where the space of design solutions to do X is
| huge. Architecture, software development, ...
| gyulai wrote:
| If I correctly catch the drift of your argument, you're
| saying "engineering is objective", so there is such a thing
| as a right and wrong choice in any given situation. ...well,
| to the extent that that's true, the word "taste" is a poor
| choice of words then. Actually, I think that's the case for
| this article. I think the article is fine, but the title and
| "taste" as a choice of word is not great. The article is more
| about intellectual humility and subordinating your individual
| priorities underneath the requirements of the project, which
| is all perfectly fine.
|
| There are some domains where the word "taste" can still
| properly be applied, for example "vi vs emacs" comes down to
| individual taste. But then, "emacs people have poor taste" is
| something that only a narcissist would say. (The "narcissism
| of small differences" is a well-studied phenomenon).
|
| Or perhaps one uses this choice of words because one feels
| some sympathy for people who say this in other domains, like
| "This room, filled with IKEA furniture and film memorabilia,
| was decorated in poor taste"
|
| ... either way, the red flag seems to stick.
|
| The reason it's worth mentioning is that the notion seems to
| be catching on, and I've seen it applied, for example, in
| hiring decisions, where I think it's quite dangerous and
| counterproductive. It lends itself to rationalizing hiring
| only like-minded people, even where there is no objective
| ground for preferring one candidate to another.
| t43562 wrote:
| I couldn't say emacs developers have poor taste but I
| _could_ say its ' not _my_ taste. I don 't have to
| disrespect them. People think in different ways and get
| used to different things.
|
| e.g. I might decide that some clothes, although well made
| and possibly even very fashionable, are not my taste. The
| superiority/inferiority of taste is something that insecure
| people focus on IMO. A tasteless thing would be something
| that doesn't seem to show any overall philosophy of design
| or something which is bombastic - it goes to town on some
| aspect at the expense of all others - there's a lack of
| balance. Even then, who cares?
|
| If I wear a bright tomato-coloured suit because I like
| colour, why should that make me a bad person? It's only
| when other people _have_ to accept your tastes because they
| work with you that they 're going to moan about them.
| hyghjiyhu wrote:
| The problem with software is that while it is in some sense
| objective, one of the most important properties of good
| software is that it can adapt to future requirements, and
| that's something that can only be evaluated in hindsight.
|
| Lacking an objective way to predict that, we turn to taste.
| KempyKolibri wrote:
| 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.
| whalee wrote:
| 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.
| laurent_du wrote:
| 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").
| t43562 wrote:
| 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.
| nickd2001 wrote:
| 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... ;)
| WalterBright wrote:
| Good taste is writing code that looks so simple, everyone else
| says "pshaw, anyone could have written that!"
| silisili wrote:
| 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.
| asmor wrote:
| 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".
| chii wrote:
| > everyone else says "pshaw, anyone could have written that!"
|
| it really depends on the problem domain tho, doesnt it?
|
| Would you call the fast inverse square root[0] code good taste?
|
| [0]
| https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
| Etheryte wrote:
| Being a good fit for a given purpose doesn't mean that
| something is in good taste. That piece of code is very
| performant, yes, but I'm pretty sure none of us would want to
| meet it in code review, save for a few niche edge cases. To
| draw a parallel from fashion, for most part, arctic snow gear
| does not win fashion prizes, but it does keep you alive.
| There's a time and place for both, doesn't mean that
| everything useful is in good taste.
| AlotOfReading wrote:
| What is "most" here? Traditional Arctic clothing (e.g.
| Inuit clothing) has huge fashion aspects. Being able to
| look good and stay comfortable in a blizzard are both
| important to many people in the far north.
|
| I highly recommend checking out the clothing and fur stores
| to accessorize if you're in an Inuit town with nothing but
| "purely practical" Western clothing. A fashionable design
| will improve both the look and the cold weather
| performance.
|
| This sometimes gets taken to the extremes of high fashion,
| like this design by an Inuit woman:
|
| https://vafashion.ca/pages/the-ukiaksaq-collection-
| nyfw-2020
| 01HNNWZ0MV43FF wrote:
| > I'm pretty sure none of us would want to meet it in code
| review, save for a few niche edge cases.
|
| It does no I/O and has no action-at-a-distance. The float-
| long-float casts are the worst part.
|
| If a coworker brought it to me with a performance
| justification and some unit tests I'd be pretty happy to
| pass it.
| rapsey wrote:
| One is an algorithm, a purely technical solution. The other
| is the way code is structured in an application.
| RHSeeger wrote:
| 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
| peterfirefly wrote:
| Yes, but the "good taste" part lies mainly in three things:
| 1) recognizing that a reciprocal square root is more useful
| than an actual square root (and likely cheaper), 2)
| recognizing that full precision isn't necessary, 3)
| recognizing that one (or two) Newton-Raphson iterations is
| good enough with a decent starting approximation.
|
| The starting approximation is just magic.
| WalterBright wrote:
| 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.)
| pyrale wrote:
| Obligatory simple made easy.
|
| Just because something is simple doesn't mean anyone has the
| wherewithal to understand it.
|
| [1]: https://www.youtube.com/watch?v=SxdOUGdseq4
| dominicrose wrote:
| I loved working in a team that wasn't allowed to use local
| variables (Rich Hickey decided that Clojure shouldn't have
| them). The menu of the website was basically implemented as a
| state machine and it just worked because every possible user
| interaction was taken into account.
| arunix wrote:
| Do you mean local variables per se, or mutable local
| variables? Clojure, like most Lisps has _let_.
| nickd2001 wrote:
| And the tragedy is that authors of such code often (usually?)
| don't receive recognition for saving time and effort on others'
| part by following KISS principles. For whatever reason its
| apparently opaque to others. And so there are entire jobs or
| even teams in the tech industry whose purpose is to work with
| and/or maintain systems that have needless complexity.
| WalterBright wrote:
| My life as the leader of the D team is one of a constant
| battle against complexity.
| Cthulhu_ wrote:
| 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".
| dkarl wrote:
| 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.
| kmoser wrote:
| That's not good taste, it's good engineering.
| RHSeeger wrote:
| ./venn diagram comments...
| WalterBright wrote:
| 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.
| WalterBright wrote:
| 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.
| sethhochberg wrote:
| I think you've actually buried a much broader commentary on
| tolerances and complexity and interoperability in here, too.
|
| The mechanical-averaging voltage regulator worked for the
| design because it only had to work in the context of the
| specific model of car it was going into. It didn't have to
| produce 5v for any application that needs 5v; it just had to
| produce "5v" for the instruments in the '72 Dodge Challenger.
| That makes it a pretty terrible 5v regulator, but a pretty
| great part for the system it was designed to fit into if the
| mechanical-averaging version is more reliable or cheaper or
| more robust than the fancy electronic versions.
|
| But if I'm designing a 5v regulator to be sold as a 5v
| regulator, well... I don't know what system its getting
| installed into so I won't have much luck selling one that,
| over a long enough time span, averages out to supplying 5v of
| power when its supplying power. So I have to design in tight
| tolerances, and everyone integrating my regulator has to
| design for tight tolerances, etc.
|
| The good news is that now anyone can buy my regulator and get
| a reliable 5v - interchangeable parts! But the bad news is
| now every system on both sides has additional complexity for
| the sake of complying with our standard.
|
| We see this _all the time_ in software, especially comparing
| old software to new. Why is Roller Coaster Tycoon so much
| more elegant and efficient than a modern game written on
| Unity? Sure, good tastes probably factor in - but that taste
| from the author was allowed to shine because it was designed
| as a complete system, not a bunch of component subsystems
| from different teams and vendors stitched together.
| WalterBright wrote:
| You make a great point. With the Dodge regulator, I
| seriously doubt it was just for the Dodge Challenger. It
| was probably used across the entire Chrysler line, for
| years. Enough cars were built to totally justify its
| design. I don't know when semiconductor voltage regulators
| appeared in a single package.
|
| In 1972, the electro-mechanical regulator was also likely
| far cheaper than a solid state one. The car didn't have a
| single transistor in it outside of the (rather expensive)
| radio. (There was an upgrade available for the ignition to
| make it "electronic" - it had one transistor!) The
| alternator of course had diodes in it.
|
| The rough 5V also enabled the instruments to be made
| cheaper.
| Aloha wrote:
| I thought by 72 they were using the electronic ignition
| module instead of points? I thought MY72 was the year it
| was introduced even?
| WalterBright wrote:
| The electronic ignition was an option at the time.
| stickfigure wrote:
| I don't know that I'd describe this as "good". It's a hack
| solution that mostly worked at the time.
|
| Those mechanical voltage regulators wore out and had to be
| replaced periodically. They weren't great at maintaining
| consistent voltage so consumers had to accept loose voltage
| tolerances. They made noise and generated electrical
| interference.
|
| Modern cars are more reliable, despite their complexity. I'll
| take solid state.
| WalterBright wrote:
| > Modern cars are more reliable
|
| I would hope so, after 55 more years of development!
| WalterBright wrote:
| Sometimes, simple code is viewed as an invitation to make it
| more complicated.
| jongjong wrote:
| 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.
| WalterBright wrote:
| 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.
| bob1029 wrote:
| > In my view, your engineering taste is composed of the set of
| engineering values you find most important. For instance:
|
| Strange how absent the customer or underlying business always is
| in this discussion.
|
| I've seen a LOT of software that could have literally just been a
| spreadsheet on a file share or a simple SQL ETL job. When
| reviewing the actual business requirements, we will often find
| that we don't even need a goddamn web interface. It's just
| assumed we're gonna build some full stack slop so we never bother
| to stop and ask why.
|
| I'm watching a client (despite my advice) self destruct on yet
| another rewrite of a piece of software that doesn't need to exist
| in the first place. Looking forward to having this exact same
| conversation IRL in a few months.
|
| I think the heart of bad taste comes from obsessing over tools
| and techniques and not ever getting meaningful things built and
| shipped to real customers. Being exposed to unfiltered criticism
| of the people who actually use your software is the fastest way
| to drive the noob behavior out of a developer. It's amazing how
| quickly you drop weird principled takes when your monkey brain
| senses it is disappointing others.
| bubblyworld wrote:
| Can you provide examples of software that should have literally
| been a spreadsheet or an ETL? Not to call you out specifically
| but this feels like "I could have written that in a weekend".
| Personally whenever I have felt that way about a project it
| turned out I was just missing 95% of the business
| context/domain knowledge (part of the reason I think rewrites
| are a bad idea - chesterton's fence).
| t43562 wrote:
| I can give you one - a billing system with reporting features
| that suck dreadfully compared to what can be done with a
| spreadsheet. Why not "just" let the user download a CSV and
| then do whatever they want with it?
|
| I was working on this project and I kept suggesting it. It
| was seen as inferior and yet the system we were going to
| produce was far inferior in every way.
| eXpl0it3r wrote:
| I agree that the customer / business focus is often very
| lacking. Sometimes because engineering is put too much into
| focus, but very often because of politics. At the same time
| it's not an easy thing to do. The "business" is usually quite
| bad at verbalizing their needs and requirements, especially at
| the level of detail that engineering requires.
|
| Having done at least one migration from "could have literally
| just been a spreadsheet" applications into proper applications,
| I'm very careful with recommending spreadsheets. It's great how
| flexible they are, but that's also their major down side. If
| you want to enforce anything within a spreadsheet, you have few
| options and it's very easy for something to break. For example
| someone deleting a formula, a formula not including the full
| range, or copy & pasting breaking the references. Not to
| mention the performance issues you'll run into once you've
| collected a few rows.
| ajuc wrote:
| Good code is invisible - either there's no code at all (because
| the requirements and architecture are well adapted so that code
| isn't necessary for a particular feature), or the code is so
| simple and boring that you skip over it without pausing.
|
| Not all code can be like that, sometimes you need to write clever
| code, but it is an ideal to strive for.
|
| BTW this is why egoless programming is so hard. Not only you have
| to accept criticism and let go of the idea of ownership of "your"
| code - you also have to write the code in a way that strokes ego
| the least.
| rawgabbit wrote:
| I like this idea. Good code does what it needs to and no more.
| Adding cognitive load that isn't absolutely necessary is the
| opposite of readability.
| OhMeadhbh wrote:
| I would say limiting the braggadocio is important to "good taste"
| as well. I interviewed once for a dev role on the email team for
| a very large free software company you've heard of. The team's
| egos were so large I could hardly fit in the room. "Oh! I see you
| wrote the control system for a nuclear power plant. That's cute,
| I once inverted a tree data structure!" or "I see you wrote the
| modular exponentiator that was in half the ATM machines deployed
| in the US in the mid-90s. Whatever. I wrote code that changes the
| background color of our web page."
|
| I did not take the job.
| jackblemming wrote:
| Your phrasing makes it sound like you're playing the same
| childish game they are; you just rank yourself higher than
| them.
| laurent_du wrote:
| There's nothing wrong with that. The problem is not that they
| were playing a childish game, it's that they were over-
| estimating their own abilities by a lot. It's ok to
| acknowledge you are good at something if you are, in fact,
| good at this thing.
| scottlamb wrote:
| > The problem is not that they were playing a childish
| game, it's that they were over-estimating their own
| abilities by a lot.
|
| Why not both?
|
| In an interview, you need to impress, and that's true for
| both the job-seeker and the hiring team. So yeah, you need
| to talk a bit about your accomplishments, and it's hard to
| do that without being a little braggy. But you can let your
| work be measured on its own. If you directly measure your
| accomplishments against the other person's, and especially
| if you put their accomplishments down, you're not selling
| them. You're showing off your personality flaws, even if
| you "win" the pissing contest.
| OhMeadhbh wrote:
| so... you're suggesting I take things off my resume to avoid
| making interviewers feel bad?
| t43562 wrote:
| 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.
| nickd2001 wrote:
| +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
| mojuba wrote:
| > Is the software easy to take in at a glance and to onboard new
| engineers to?
|
| This is not as easy as it sounds. Who are those "new engineers",
| juniors? 10 years of experience? 30 years? What's your
| requirement?
|
| "Readability" is such a wildcard, with a whole range of
| acceptable levels from zero to infinity. Readability is a non-
| concept really. Maxwell's famous equations are readable to some
| and absolutely impenetrable to the rest of us.
|
| So when someone says "code should be readable", to whom exactly?
| zx8080 wrote:
| Theere are two quite a widespread classes of not readable code:
|
| Some code is not readable by _anyone_. That's not readable
| code.
|
| Some code is readable by its author only (be it AI or a human).
| That's also not readable one.
|
| Saying readability is not a concept is really strange.
| mojuba wrote:
| I have a formal proof for you that it is a non-concept. If
| code can be read and interpreted by a computer, it means it
| can in principle be read by a human. There are of course some
| edge cases like obfuscated JavaScript or binary executable
| that some people are able to read and understand.
|
| The question comes down to being _reasonably_ readable and we
| are back to square one: "reasonable" is very relative. In my
| early days I could read 8086 binary code (in hex) and
| understand what it does, it was literally at the very edge of
| readability but it wasn't unreadable.
| atoav wrote:
| Sure, but we do agree that Hello World is MORE1 _readable_
| in Python compared to the equivalent program in say
| Brainfuck? print("Hello World")
|
| vs ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>-
| >>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>
| >+.>++.
|
| 1: more readable means easier/faster to read for most human
| beings that know the language
| eithed wrote:
| I can't reasonably read whether this comment agrees or
| disagrees with the parent
| RHSeeger wrote:
| You are using a different definition of readable than most
| people are. Most people are using it to mean "the target
| audience can read and understand the code, and do so in a
| way/context that allows them work with it". Your definition
| seems to be "can read the symbols on the screen".
|
| I can read Assembly. I can, in some cases, figure out what
| that Assembly is doing. I can not, however, work
| productively with it. I can read Assembly but would not
| consider it readable.
| epolanski wrote:
| 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.
| Yoric wrote:
| I'll have to disagree.
|
| Developers coming from functional programming and developers
| coming from C programming, for instance, have very different
| definitions of "readable", and neither is obviously wrong.
|
| Similarly, developers used to channel-based, async-based or
| mutex-based concurrent programming will all have very
| different criteria for "readable" code, again none of them
| obviously wrong.
| skydhash wrote:
| Those are just paradigms, ways of solving problems. There's
| a difference between familiarity and readability. Sometimes
| you have to learn stuff before understanding them.
| Readability is how easy it is to do that, given familiarity
| with the base concepts that the code use.
| Yoric wrote:
| You are correct.
|
| Yet it's pretty easy to find people who consider that
| `map()` or `filter()` are simply not readable - or, on
| the other side of the aisle, that having a loop variable
| is detrimental to readability.
|
| And of course, these criteria change with time, industry
| and programming language used.
| ibash wrote:
| I disagree. The ability of someone to read code doesn't grow
| exponentially, after a few years of experience everyone hits
| the same plateau. More years of experience does not mean you
| can understand more complex code.
|
| That is to say, if you target "readable to the majority of
| engineers with 3-4 years of experience, without them getting
| confused" then you've hit the mark.
| mojuba wrote:
| > 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.
| djmips wrote:
| 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.
| epolanski wrote:
| +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.
| pjaoko wrote:
| Completely agree. Readability is actually in the word itself
| read + ability. The ability of both the code and the reader.
| rob74 wrote:
| 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...
| pbalcer wrote:
| Readable code is code that has empathy for the reader and tries
| to minimize the cognitive load of interpreting it. That's one
| of the goals of abstraction layers and design patterns.
|
| Yes, it's all subjective, and depends on the reader's expertise
| and existing familiarity with the codebase. But arguing that
| code readability isn't at thing, because it's subjective, is an
| absurd take. Would you claim that Joyce's Ulysses is equally
| readable as Seuss's The Cat in the Hat?
| PickledChris wrote:
| I see this argument pattern a lot, so looked into what the
| name is. Apparently it's called Sorites paradox:
| https://en.wikipedia.org/wiki/Sorites_paradox or the
| "continuum fallacy" in which something that's continuous is
| dismissed as not existing because we can't divide it into
| clear categories.
| kaffekaka wrote:
| Did someone claim readability does not exist?
| hhjinks wrote:
| > Readability is a non-concept really
|
| Yes.
| mojuba wrote:
| Readability without a clarification is a non-concept. You
| can't say "X should be readable" without giving some
| context and without clarifying who you are targeting.
| "Code should be readable" is a non-statement, yes.
| virgilp wrote:
| Add "to most developers" for context and you'll probably
| get exactly what original claim meant.
|
| It's not a non-statement. Rich Hickey explains it well,
| readability is not about the subjective factors, it's
| mostly about the objective ones (how many things are
| intertwined? the code that you can read & consider in
| isolation is readable. The code that behaves differently
| depending on global state, makes implicit assumptions
| about other parts of the system, etc - is unreadable/less
| readable - with readability decreasing with number of
| dependencies).
| Bjartr wrote:
| It can be further refined to
|
| "to most developers who are most likely to interact with
| this code over its useful lifetime."
|
| This means accounting for the audience. Something
| unfamiliar to the average random coder might be very
| familiar to anyone likely to touch a particular piece of
| code in a particular organization.
| pixl97 wrote:
| >"Code should be readable" is a non-statement, yes.
|
| Oh, I completely disagree here. Take obfuscation for
| example, which you can carry on into things like
| minimized files in javascript. If you ever try to debug
| that crap without an original file (which happens far
| more than one would expect) you learn quickly about
| readability.
| mojuba wrote:
| 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.
| osigurdson wrote:
| >> 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.
| bcrosby95 wrote:
| 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.
| atoav wrote:
| 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?
| DanielHB wrote:
| 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).
| MaxBarraclough wrote:
| > Readability is a non-concept really. Maxwell's famous
| equations are readable to some and absolutely impenetrable to
| the rest of us.
|
| When we talk about a language's readability we're typically
| talking about 'accidental complexity', to use Brooks' term, [0]
| and not the 'essential complexity' of the problem being solved.
| For a hairy enough algorithm, even pseudocode can be difficult
| to understand.
|
| Readability applies in mathematics too, as a bad notation may
| make formulae unnecessarily difficult to comprehend.
|
| > So when someone says "code should be readable", to whom
| exactly?
|
| I'll have a go: to another competent engineer familiar with the
| general problem domain but not familiar with your specific
| work. This includes yourself in 2 years time.
|
| This seems rather like the question of readability for
| scientific writing. Research papers should be readable to other
| researchers in the field, but they aren't generally expected to
| be readable to a general audience.
|
| [0] https://en.wikipedia.org/wiki/No_Silver_Bullet#Summary
| necklesspen wrote:
| When used in the domain of fashion "good taste" describes someone
| who has a unique way of selecting clothes that just mesh well
| together - clothes that by themselves independently are
| meaningless, no matter their make or quality, but when combined
| together create a powerful effect - much greater than the sum of
| their parts.
|
| I was hoping the article would go in that direction - what
| subjective combination is a software engineer deciding on that
| you can argue is truly a matter of taste and not just a technical
| decision about a trade-off.
|
| I would say this this article itself may be an example of bad
| taste. It meanders across a couple of disparate topics in
| software engineering, independently each section is competently
| written but as a whole they really don't sell the "look" the
| article was aiming for.
|
| (I don't mean to discourage future writing by the author - I
| think it's a potentially excellent choice of topic. I'm just
| giving my two cents here on the execution.)
| whstl wrote:
| I don't agree with the statement that clothes can be "by
| themselves independently are meaningless". Garments carry
| cultural, historical and symbolic weight even before they're
| combined. And fashion is hardly mainly about combining outfits.
|
| And fashion is _a lot_ about tradeoffs too. Not just in the
| production, but also in the day to day wearing and mix-and-
| matching part.
| necklesspen wrote:
| Meaningless in the context of an outfit - not necessarily
| whether the garment itself may have meaning to someone. You
| may surely be in possession of a couple of random trinkets of
| great historic significance but if you just mesh them all
| together into one outfit you might simply end up with a mess
| on your hands. A garment may well be the centerpiece of an
| outfit - but it is ultimately always the combination that is
| important.
|
| Im sure you've seen examples of this yourself - you can
| absolutely sport a Ray Ban in good taste and you've almost
| surely seen someone believe themselves to be fashionable
| _because_ they are wearing a Ray Ban.
|
| Also, I'm not suggesting fashion as a whole is about combing
| outfits - merely that being able to combine varying pieces of
| clothing into a cohesive whole is an expression of good
| taste.
| blub wrote:
| 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.
| jm547ster wrote:
| Yeah the Linux language gets most people's goats......
| wredcoll wrote:
| This comment annoyed me so much I had to get an actual
| keyboard to respond.
|
| First off, the concept of "good taste" is much, much broader
| than only applying to clothing based fashion. You can have
| good taste in practically any field that involves any amount
| of creativity/choice: cooking, painting, writing, music,
| programming, video game design, etc, the list is practically
| infinite.
|
| As such, the idea that most "engineers and technical persons"
| don't "understand good taste" is incredibly silly. It's
| entirely possible, _perhaps_ even probable that the average
| programmer lacks good taste in terms of fashion, but that
| says nothing at all about good taste in other areas.
|
| Secondly, having good taste and being able to _apply_ it is
| also wildly different. I can recognize what looks good in
| fashion or paintings without being myself able to achieve
| that.
|
| Thirdly, there's really no such thing as a "normal human".
| The longer you live, assuming you're willing to actually
| examine your experiences, the more you'll learn that the
| trite expression "everyone is unique" really is accurate.
|
| Just as a semi-random example, it might be tempting to think
| of watching football (nfl) as "normal". According to a quick
| google, the average nfl game gets like 17-20million viewers,
| and even assuming that's accurate/all unique people/etc, it's
| a very large number in absolute terms but its less than 10%
| of the population of america.
|
| So if you took a random group of 100 americans, something
| like 6-7 would have watched a football game last week[1]. Now
| that's still many times larger than the number of people who
| wrote code last week, but it's not some kind of overwhelming
| majority that "everyone" does.
|
| [1] Yes these numbers are extremely imprecise, it's
| rhetorical
| blub wrote:
| It is broader since it applies to things which can be
| perceived visually, but does not apply to any random
| creative activity. The list is finite and programming is
| not on it.
|
| Furthermore, taste in one area is more likely to manifest
| in other areas. Somebody that has good taste in fashion
| would likely have good taste in interior decoration or art.
|
| > Secondly, having good taste and being able to apply it is
| also wildly different. I can recognize what looks good in
| fashion or paintings without being myself able to achieve
| that.
|
| Ok, but applying it is the interesting part.
|
| > Thirdly, there's really no such thing as a "normal
| human". The longer you live, assuming you're willing to
| actually examine your experiences, the more you'll learn
| that the trite expression "everyone is unique" really is
| accurate.
|
| The things that make individuals truly unique are often
| irrelevant in the greater scheme. One could draw a line
| across continents and ages to connect quite similar people.
| bryanrasmussen wrote:
| > what subjective combination is a software engineer deciding
| on that you can argue is truly a matter of taste and not just a
| technical decision about a trade-off.
|
| I put down to taste many things that I believe are technical
| decisions about trade-offs but that I cannot absolutely verify
| or which I believe the trade off is so very small that it
| doesn't actually matter.
| HenriTEL wrote:
| 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.
| hosh wrote:
| 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.
| bcrosby95 wrote:
| 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.
| JulianHC wrote:
| I heard readability is a touchy subject since some people say
| having your code easy to read would make replacing you easier.
| 8-prime wrote:
| If you write your code such that you are hard to replace,
| because noone else would be able to understand what you were
| doing, I would consider that to be "bad taste" and "bad form".
| eimrine wrote:
| Those who have a good taste can distinguish a good taste from a
| bad taste. Those who don't have a good taste can not.
| chii wrote:
| So who has the good taste when two different people distinguish
| the same code base differently?
| antisthenes wrote:
| > So who has the good taste when two different people
| distinguish the same code base differently?
|
| The person with the good taste.
| h1fra wrote:
| Good taste is what I do; bad taste is what others do
| marginalia_nu wrote:
| The portable definition of good taste in software development is
| likely something like fitness to purpose, i.e. how well does the
| taste lend itself to producing good software, where good software
| in turn is software that does what it is indented to do.
|
| If you want to go more concrete than that, you need additional
| parameters, otherwise you risk ending up with a broken compass
| that only points north in organizations similar in size and other
| properties to the ones you've worked in before.
| Mikhail_Edoshin wrote:
| 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".
| Daub wrote:
| 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.
| epolanski wrote:
| > Are functions relatively short and named well?
|
| I was hoping we moved beyond this "clean code"-ish nonsense of
| functions having to be short.
|
| Quality of a software design, maintainability, etc, have
| virtually no relation to length of functions and the most
| respectable software out there contain functions hundreds if not
| thousands of lines of code long without being impacted by its own
| weight.
| imiric wrote:
| Eh, hard disagree. (Though I didn't downvote you, since it's
| silly to downvote out of disagreement...)
|
| Readability, while subjective, plays a large role in software
| maintenance. Developers will be more reluctant to change code
| they don't understand, and more likely to introduce bugs.
| "Long" functions require following large blocks of code that
| work within the same context, and relying on comments to
| explain functionality, which could be wrong or outdated, rather
| than descriptive function names.
|
| Also, "long" functions are typically difficult to test. They
| either require complex setup and mocking, or are only tested
| under very specific conditions in end-to-end tests, if at all.
| Chances are that only users are actually testing them, which is
| not a good place to be.
|
| We can argue whether "AI" tools help with this or not, but
| while humans are still reading and writing code, following
| standard conventions of keeping functions relatively "short",
| "clean" (whatever those terms mean for you and your team), and
| with a single purpose, makes maintenance and testing easier,
| and, in turn, produces more robust and higher quality software.
| epolanski wrote:
| You break up things when it makes sense, not for the sake of
| it.
|
| Having to jump out of the code you're reading comes with its
| own downsides and tends to compromise maintainability where
| you are increasing the shallowness of your code (same
| functionality, but higher api surface).
|
| You break up things when there are benefits to breaking them
| and Unix provides a very sensible reference to this topic
| where plenty of syscalls run generously in the thousands or
| tens of thousands of lines.
|
| Stanford professor Jon Ousterhout (among other things the
| author of the Tcl language, the Tk framework, the Raft
| consensus algorithm and many other things) has an entire
| paragraph in his book "A philosophy of software design"[1],
| on why the argument "functions should be short" is short
| sighted and should never be taken at face value.
|
| [1] https://www.amazon.com/Philosophy-Software-Design-John-
| Ouste...
| imiric wrote:
| > You break up things when it makes sense, not for the sake
| of it.
|
| I never claimed otherwise.
|
| > Having to jump out of the code you're reading comes with
| its own downsides and tends to compromise maintainability
| where you are increasing the shallowness of your code
| (higher api surface).
|
| I don't buy this argument. The code you're reading should
| do one thing according to what it says on the tin (the
| function name). When the code does something else, you
| navigate to that other place (easily done in most IDEs),
| and change contexts. This context change is important,
| since humans struggle with keeping track of a lot of it at
| once. When you have to follow a single long function, the
| context is polluted with previous functionality, comments,
| variables, and so on, not unlike the scope of the program
| at that point. If you're changing the code, it becomes
| easier to shadow a previous variable, or to change
| something that subsequent code depends on. Decomposing the
| large function into smaller ones avoids all of this.
|
| As well as aiding in testability, which you conveniently
| ignored from my previous comment.
|
| The criteria for determining what is "short" and "long" is
| subjective, of course, and should be determined by whatever
| the team collectively agrees on. But there should be some
| accepted definition of these.
|
| > Stanford professor Jon Ousterhout
|
| Eh, I'm not swayed by arguments from authority. Jon's
| opinion is as valid as mine or yours.
| epolanski wrote:
| > Eh, I'm not swayed by arguments from authority. Jon's
| opinion is as valid as mine or yours.
|
| John has spent his entire life to learning and teaching
| general principles of good software design and their
| limits.
|
| His opinion definitely has a different weight than ours.
|
| https://web.stanford.edu/~ouster/cgi-
| bin/cs190-winter21/inde...
| illuminator83 wrote:
| Well, he can start citing Martin Fowler or Bertrand
| Meyer. Then what?
|
| Arguments from authority lead no where here. Because
| these "authorities" also disagree.
| epolanski wrote:
| John has had meaningful impact to computing from algos,
| operating systems, programming languages, frameworks,
| etc.
|
| Fowler has written *nothing* anybody ever cared for.
| Nothing.
|
| Ousterhout has taught Software Design at Stanford where
| he's had students implement the most diverse software and
| finding the limits of his own theories and having them
| questioned rigorously year after year.
| vendiddy wrote:
| If you are breaking something up for "long" and "short"
| you're optimizing for the wrong thing. You don't care
| about code being short for its own sake or long for its
| own sake right?
|
| Ultimately, you're going to revisit this code to make the
| change after some time passes. Is it easy to follow the
| code and make the change without making mistakes? Is it
| easy for someone else on the team to do the same?
|
| Sometimes optimizing for "easy to understand and change"
| means breaking something apart. Sometimes it means
| combining things. I've read that John Carmack would
| frequently inline functions because it was too hard to
| follow.
|
| So, rather than whether something is big or too small, I
| would ask whether it would be easy to understand/change
| when coming back to it after a few months.
|
| Put another way: why not optimize for the actual thing
| you care about rather than an intermediate metric like
| LOC?
| imiric wrote:
| > If you are breaking something up for "long" and "short"
| you're optimizing for the wrong thing. You don't care
| about code being short for its own sake or long for its
| own sake right?
|
| You're misunderstanding. Code is not broken up because
| it's "long". It's broken up because it is difficult to
| comprehend and maintain, and its length is one criterion
| that _might_ signal that to be the case. Another sign is
| cyclomatic complexity, which is another arbitrary number
| left for teams to decide how to use best.
|
| The main topic, and why it is so widely argued, is that
| readability and maintainability are entirely subjective
| concepts that are impossible to quantify. This is why we
| need some specific guidelines that could point us in
| certain directions.
|
| This doesn't mean that these guidelines should be
| strictly enforced. I've often decided to silence linters
| that warn me about long functions or high cyclomatic
| complexity, if to me the function is readable enough, and
| breaking it up would be more problematic. This is open to
| interpretation and debate during code reviews, but it
| doesn't mean that these are useless signals that
| developers should ignore altogether.
| marcosdumay wrote:
| > and its length is one criterion that might signal that
| to be the case
|
| You seem to be the one misunderstand it.
|
| It's just not. Function length is not a useful metric, at
| all. The probability of some problems increase with
| length, but even then it's not the length that will tell
| you if your code has a problem or not.
|
| If you have length guidelines, your guidelines are bad.
|
| And, yeah, cyclomatic complexity is almost as useless as
| function length. If you have warnings bothering people
| about those, you are reducing your code quality.
| BenoitEssiambre wrote:
| To add to this, there are fundamental information-theoretic
| principles that support inlining code and components. It's
| about reducing code entropy, reducing length and referential
| distances. https://benoitessiambre.com/entropy.html
|
| The good thing is LLMs try to optimize for information
| theoretic measures of language so they naturally generate
| better scoped more inline code. LLMs might help us win this
| battle :-)
| imiric wrote:
| I like the article. Most engineering decisions are indeed a
| tradeoff that should be carefully considered.
|
| That said...
|
| > I will always distrust engineers who justify decisions by
| saying "it's best practice". No engineering decision is "best
| practice" in all contexts! You have to make the right decision
| for the specific problem you're facing.
|
| There are indeed general best practices that are applicable to
| most, if not all, situations. E.g. version control and testing
| (arguably even the testing approach) are practices that every
| competent developer would agree are pretty much requirements.
|
| Context does matter, but within specific contexts there are
| practices that can be generally considered "best", because
| applying them delivers more value than not, and their drawbacks
| are manageable.
|
| For example, after a certain team size, implementing a CI
| pipeline is a best practice. Yes, it takes time and effort to
| implement and maintain, but the benefits far outweigh the
| drawbacks. After a certain scale, implementing a robust and
| efficient infrastructure management and deployment solution is
| pretty much a requirement. Relying on ClickOps to provision
| infrastructure, and deploying with shell scripts over SSH, while
| technically "simple", can only get you so far. And so on.
|
| These practices become more evident with experience, and deciding
| when to vouch for them, even strongly, becomes more evident with
| wisdom. So I wouldn't necessarilly _always_ distrust engineers
| who want to promote best practices. I would listen to them,
| discuss it with them, and make a decision along with the rest of
| the team. If they do push back after a decision has been made,
| _that_ would be a bigger issue. Not necessarilly with that
| specific engineer--it could also be a sign of communication
| problems, egos, politics, etc. Unfortunately, there are many
| dysfunctional teams and companies with toxic environments, but I
| suppose that 's just human nature.
| t43562 wrote:
| It gets used whenever someone doesn't like something for a
| reason of personal taste and people who don't really know (like
| your boss) immediate fixate on it and think "well, we must do
| that then and why is the other guy (you) suggesting that it
| doesn't apply in this case? Best practises ALWAYS apply surely?
| I will have a quiet word with him about standards..."
|
| IOW it's a short circuit to not justifying something. If
| something is best practise you can explain why it suits the
| current situation and if you can't explain why then it doesn't
| matter.
| imiric wrote:
| Well, sure, but since every decision has tradeoffs, sometimes
| when arguing for or against a decision, it's easy for
| managers to side with the person they have more rapport with,
| who may or may not be correct, rather than decide on
| technical merits alone.
|
| So, in some cases, it's more beneficial for the company to
| adopt a "best" practice, than to have engineers engage in
| arduous discussions, which can cause resentment and further
| problems within the team.
|
| Needless to say, it's a delicate balance, which is why I
| wouldn't want to be a manager. :)
| t43562 wrote:
| Oh, you're so right about setting some default standards to
| prevent arguments!
|
| The most simple and easy one is to auto-format code. That
| kills so many ridiculous arguments. I wish all problems
| could solved that simply.
| mrkeen wrote:
| "Good taste" is just advice or guidance that you haven't thought
| through enough to turn into actionable principles.
|
| Compare:
|
| * I apply the dependency inversion principle to keep my code
| testable
|
| * I minimise the scope and mutability of all my variables
|
| With:
|
| * These methods do what they say they do
|
| * This code is good because it's declarative
|
| * These functions have the right number of lines
| 8-prime wrote:
| I may be misunderstanding what you're trying to say, but I feel
| like this still suffers from one of the mentioned issues -
| situationality.
|
| Even the best actionable principles can be incorrect given a
| certain set of circumstances. If in those cases you choose to
| uphold your priciples, rather than choosing what is "right" for
| the project you would fall into the camp of "bad taste".
|
| That is at least how I interpreted the article.
| mrkeen wrote:
| > Even the best actionable principles can be incorrect given
| a certain set of circumstances.
|
| If they are principles, the discussion around whether to
| apply them can at least be fruitful. "Taste" is bound to
| devolve into "I like this" vs "I like that".
|
| I don't buy into the "everything has its upsides and its
| downsides" advice given in the article for the same reason.
| It's a useless truism. It's a taste:-
|
| I have 1 new feature ticket in my backlog, 3 support tickets,
| 2 failing tests, and 2 performance regressions. "Premature
| optimisation is the root of all evil" informs me about the
| feature work, as does "Make it work, make it right, make it
| fast". "Reproduce locally" will be my north star for the
| support, the test failures, and the performance work. Add
| "Find and measure the bottleneck(s)" for the performance
| work, as well as "make sure the new code is actually faster
| than the old code" before checking it in.
|
| I don't need to invoke the maturity of any particular coder
| for any of this.
|
| Another problem with letting "taste" into the discussion is
| that you can cheapen principles: you think this code needs
| tests? "Well, there are upsides and downsides with that",
| "You're just being inflexible, which is immature". Neither
| tasteful reply will help you answer whether the code needs
| tests, and it stirs up shit in the team because it makes it
| about people, not work, so egos will get inflamed.
|
| >> Personally, I feel like code that uses map and filter
| looks nicer than using a for loop
|
| I'm not going to argue the person, I'm going to argue the
| principle. I use map and filter in my business logic because
| I can do so without mutability. My business logic should
| reflect the requirements and customer expectations -
| deterministically. The principle of making the source code
| pretty is a distant second to the principle of making the
| code deterministic. If the requirements change from "apply
| the correct tax rules" to "apply the correct tax rules, if
| the system is in the right state", then I might well bring in
| a bunch of mutations to make that happen.
|
| >> is more straightforward to extend to other iteration
| strategies (like taking two items at a time).
|
| Nope, items.pairs.map((x,y) => ..). Didn't need to discuss
| maturity.
| eowyn wrote:
| > "Taste" is bound to devolve into "I like this" vs "I like
| that" My read of the article was less "I like this" and
| more "I've seen xx work best in a situation like this where
| we're optimising for yy but if we're optimising for zz then
| something else would be more suitable"
|
| It's less about what you like or dislike and more about
| aligning a collection of practices you've seen work well to
| the situation and constraints, which is why variety of
| experience helps
|
| I'm not sure why stirring up shit or inflaming egos would
| necessarily happen with such conversations. Skilled
| engineers often start a solution proposal by explicitly
| outlining what they are optimising for, known limitations
| etc which all help create a baseline to describe "taste"
| boxed wrote:
| > for loop
|
| The language matters a lot here too:
|
| > For instance, map and filter typically involve pure
| functions, which are easier to reason about, and they avoid
| an entire class of off-by-one iterator bugs.
|
| That's not how "for loops" work in many programming
| languages! Python being the most obvious, and by some
| measures the largest programming language of all.
| neximo64 wrote:
| This is exactly what bad taste is. Not one mention of if the
| software is actually 'good' to use for the end user.
| fiftyacorn wrote:
| Id settle for "common sense" - seems to lack in a lot of
| codebases
| rswail wrote:
| Which doesn't exist, because it's not "common".
| yegle wrote:
| How to distinguish "good taste" vs "opinionated" though?
|
| If you can articulate why certain code is better with convincing
| justifications, I would say that's "good taste". Coding styles
| are often examples of these.
|
| But if you can't articulate or don't have a convincing reasoning
| for preferring certain coding patterns, isn't it just
| "opinionated"?
| eowyn wrote:
| I think good taste and opinionated aren't quite the same thing
| but you do need to have some opinions to have good taste, it's
| almost like a precursor. Good taste then comes from knowing
| which of your opinions you're optimising for in the current
| situation and which of your opinions are either not relevant or
| perhaps the situation is not suitable or ready for them.
| brunorro wrote:
| I have bad taste. So I will say suckless.org
|
| - software should do one thing and do it well - code should be
| understandable, easy to build, easy to port - dependencies should
| not be a problem - the chosen language must not be a burden -
| resources are scarce: if you say "unused memory is wasted memory"
| you are part of the problem
|
| (I know, I'm a horrible person)
| asmor wrote:
| 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.
| scottlamb wrote:
| 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".
| t43562 wrote:
| > 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.
| Propelloni wrote:
| This principle (sorry ;)) is applicable to all domains. I'd
| wish I would remember this more often. Thank you for the gentle
| reminder!
| andruby wrote:
| It's close to the mantra "strong opinions, loosely held",
| which I appreciate a lot.
| CaptainOfCoit wrote:
| 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.
| grvdrm wrote:
| 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
| JKCalhoun wrote:
| "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.)
| CaptainOfCoit wrote:
| 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.
| hellisothers wrote:
| I describe this as the Artist vs Scientist software
| engineer. I'm also an "artist" and approach the problem as
| a ball of clay, hacking away at it (and sometimes starting
| with a new ball) until the solution appears beneath my
| hands. The Scientist approach is to know the solution ahead
| of time , write tests to ensure it comes out the expected
| way, and then execute.
| matthewkayin wrote:
| In writing they call this the "gardener" (artist) vs
| "architect" (scientist). Some writers plot more at the
| beginning, and others just dive straight into writing,
| knowing that they'll have plenty of revising ahead of
| them.
|
| I'm definitely more of a gardener myself, and I've always
| considered the architect software engineers of the world
| to be silly and unfun and prone to locking themselves
| into an over-engineered architecture before they even
| understood the problem properly, but they really are just
| different approaches to software development and each of
| them has their strengths.
|
| In indie game development, the requirements are often
| unclear, and I am still exploring what the game idea
| might be, still trying to "find the fun" of a game, and
| so the gardening approach works quite well.
|
| In other fields, where you have clear requirements
| figured out from day one and the consequences for not
| meeting those requirements is much higher, the
| architect's approach has its wisdom.
| RangerScience wrote:
| It works better if you "split the axis"; (imo) good code is
| easy to modify, bad code is hard to understand. Everything
| else is, as you say, trade offs, and so only evaluatable
| within a specific context.
| johnh-hn wrote:
| 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.
| cardanome wrote:
| 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.
| enraged_camel wrote:
| >> 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.
| Retr0id wrote:
| 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.
| stronglikedan wrote:
| 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.
| idontwantthis wrote:
| 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.
| lukan wrote:
| You still have to be sensible in the way how you ask
| questions. Very possible to intentionally or
| unintentionally insult and trigger lots of other things
| just by "asking a question" (my speciality).
| hosh wrote:
| 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.
| BinaryIgor wrote:
| 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
| estimator7292 wrote:
| 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.
| heavyset_go wrote:
| 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.
| hobs wrote:
| 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.)
| 000ooo000 wrote:
| A: Experience
|
| Have your 10 mins back.
| austin-cheney wrote:
| 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.
| sauercrowd wrote:
| > 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.
| spacecadet wrote:
| "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.
| incomingpain wrote:
| 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!
| hu3 wrote:
| Same here with regards to large systems, refactoring, and then
| getting things working.
|
| I believe that is what builds taste: varied experience.
| alphazard wrote:
| 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.
| osigurdson wrote:
| 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.
| AnimalMuppet wrote:
| 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.
| osigurdson wrote:
| >> 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.
| epgui wrote:
| 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.
| chasd00 wrote:
| 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.
| emilsoman wrote:
| > 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.
| t1234s wrote:
| Not including dozens of packages from peoples random github
| repos.
| 0xbadcafebee wrote:
| > 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.
| nmeofthestate wrote:
| 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".
| js8 wrote:
| 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?
| jwpapi wrote:
| These are the posts I'm coming to HN for.
|
| Great dimension to look at!
| hosh wrote:
| 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
| ACV001 wrote:
| 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.
| dvcoolarun wrote:
| 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.
| Mikhail_Edoshin wrote:
| 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.
| nosefurhairdo wrote:
| 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.
| BinaryIgor wrote:
| 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. "
| ozgrakkurt wrote:
| Discussing subjective things as if they are objective has to be
| what bad taste is
| m3kw9 wrote:
| Every programmer now checking if hey ad good taste and who
| doesn't. A ultimately waste of time
| liquid_thyme wrote:
| 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.
| kazinator wrote:
| 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.
| AfterHIA wrote:
| 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)
| lbriner wrote:
| 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.
| agentultra wrote:
| I'd suggest reading Hammond's, _The Art of Doing Science and
| Engineering_. He literally ran a course to help people develop,
| "taste."
| cptroot wrote:
| 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...
| agentultra wrote:
| Oops, sorry. Was typing on my phone and misremembered his
| name! That's the one.
| jongjong wrote:
| >> 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.
| gafferongames wrote:
| It's what I have, and you don't.
___________________________________________________________________
(page generated 2025-09-29 23:00 UTC)