Hacker News Reader

Comment by dkarl | Hacker News Reader

> 3) Nobody gives a f** about your clean code

This is true most of the time, but assuming your boss and coworkers are doing their jobs well (which is why it's not true most of the time) people will regularly communicate the things that are helping or hindering in their work.

Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean." You'll learn that people care about how quickly they can understand and use your code, and whether they can make changes without worrying about breaking things. That's all they care about, and that's what "clean" is supposed to serve and accomplish.

View on HN

If nobody gives a fuck about clean code in your org then you really need to find a new org. Perfect need not be the enemy of good, but if nobody cares at all then the problem will just get worse over time. Get out while you can and surround yourself with people and an org that take pride in their work.

Completely agree. It's the equivalent to keeping a tidy workspace with others in mind. Teams should spend time narrowing down coding styles, naming conventions, and general rules together over time, and stick to them.

As new people are onboarded, stick with those rules but have periodic moments where you solicit feedback from your team on the approach and make changes.

It really does help to have a team agreeing on these things collaboratively, and ideally having a more senior person enforcing it during code review where it's reasonable.

It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.

This is a great analogy.

There’s some related thoughts on safety practices that would be readily apparent to someone on a job site that apply to software as well. In my personal experience, people who don’t take pride in their work are the same ones that end up creating unsafe situations. The software parallels are easy to imagine.

> It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.

The Salesforce tower in San Francisco begs to differ: https://www.popularmechanics.com/science/a29329189/salesforc...

> for a high value construction site with top tier vendors and workers who value their craft.

Is it really that, or are there just so many parties involved, that a heavy bureaucracy/coordination layer is required to keep the project from collapsing on itself, and this happens to manifest as everything looking neatly organized and structured?

This and construction is governed heavily by codes (in the US, at least). This constrains how much freedom builders have to design any-which-way they want.

But to the OPs point, there is a stark difference in the quality of work between tradespeople who respect their craft and those who look at it as merely a means to a paycheck.

Is there such a thing as clean code? What’s perfect now can change at any moment.

New business or acceptance criteria, architectural changes, and other human created obstacles.

What exist is code that can be maintained, and code that just cannot (in practical time). There is no sharp cut, is a continuum. But if nobody cares, at some point it grinds to a halt.

Software has been around long enough that many companies have been burned by bad code and so they are willing to give training and time to making it better. While there are trade offs, spending several years of no features while engineering rewrites the whole thing isn't acceptable.

Extensibility is the term that speaks to this situation. Extensible code, updated by skilled developers, will allow for radical business logic changes without sacrificing the quality of the code over time.

It's like a skyscraper. The critical structural stuff is fixed but the architects and engineers try to minimize those pieces and create flexible spaces that can either be high density cubicles, enclosed offices, a cafe, etc...

Eventually it's true that you have to tear it all down and there's nothing wrong with that - a good developer will know when that makes sense based on the needs of the stakeholders and make that recommendation.

I like it, but I think how easy it is to replace is more important than how easy it is to extend. Otherwise it might end like those massive class hierarchies instead of a function.

For me, pure functions and enforced types do the trick.

the word 'care' is doing a lot of work here.

Not all code is created equally, not all code needs to be clean or have a lot of time spent on it. Many times those who "care" about clean code have difficulty understand when it is, and isn't appropriate.

I agree with this. The metaphor I use is restaurant kitchens. Some kitchens are permanently greasy and look like a bomb went off. The best 5-star kitchens are a whirlwind of constant cleaning and mise en place.

"Clean code" is useless when it's an artistic aesthetic, but operationalizing the sense of "everything has a place, clean up as you go" has concrete value. You can spot teams that DGAF vs. teams that treat their responsibilities like a 5-star kitchen. In both cases, it's "just" a job, but that doesn't equate to carelessness.

There is often no better feeling of leaving a job where spaghetti code is a constant problem. I've worked on projects where co-workers took numerous short cuts that I'd regularly have to fix months later after they ditched their role. There is no real way to fix the problems of that kind because companies that emphasize proper testing and clean code simply don't weather tight deadlines and cost cutting that the rest of the industry imposes on everything, that's why there is often no better feeling of leaving a job where spaghetti code is a constant problem, :P

Like with many of the examples in the replies - they may not care about how clean your code is, but they sure as hell care (and notice) if they're constantly having to untangle someones shitty code after it broke production again.

It's about where you are at relative to the median in the group, typically, not about any absolute standard.

> Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean."

To add to this, people will have different opinions on what is "clean". In fact you will have different opinions on what is "clean"!

I've lost count of the times I've written some code, only to come back the next day and re-write it into a "cleaner" version.

Like writing an essay, it takes time and iteration, and sometimes there just isn't a stable solution. This has somewhat helped me in just writing the damn code (but my ADHD brain still habitually reaches for "perfection" over "get it done")

I remember a time in my career when I looked at some code and I was truly impressed by whoever had written it. It was different from the code I was used to finding in the company's codebase. The intent was clear, it was efficient, etc. I looked into the source code history to see who wrote it. I was surprised to find that I had written it, but I'd entirely forgotten writing it. I got a good laugh out of that... but I was mildly disappointed that I couldn't praise someone else.

Of course this is the exception rather than the rule. I've done a lot of revision on my code. If you don't look back on your code and think of ways it can improve then there's a good chance you're not learning.

"If you don't look back on your code and think of ways it can improve then there's a good chance you're not learning."

I say this exact same thing to junior engineers who are acclimating to code reviews and might be suffering a bit from imposter syndrome.

I love these rare moments when I think of solving some problem, figure out what I need to do and where, proceed to get started - only to notice I have already done this exactly the way I had planned, but forgot about it.

Yuck, sounds like it's ego driven development.

Talking with team members to get everybody to agree on what the style is can fix this.

Talking seems to not happen, in my recent work experiences - instead it's a pain to talk to people because you have to do fucking zoom meetings and it has to be scheduled. Or the company actively discourages the team from setting their own technical goals of quality in the name of some ridiculous abstracted version of addressing customer interests. It's out of balance - customer interests are left on the ground while quality is also left on the ground.

Having a tight team is what we should be focusing on! ChatGPT is going to eat so many of our jobs. We should be focusing on being excellent humans.

I was warned about that ego driven development while I was at school by the teachers. Apparently it's been formalized as gospel ... people lie to themselves calling it clean. Basking under the warm smile of Uncle Bob. Creep.

The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.

> The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.

I disagree. I'll take a bet that given 10 experienced software engineers (we can define what this means -- title, years of experience, familiarity with language idioms, etc.) they'll mostly agree on samples A, B, C, ... of code if it's "clean" or not.

Code doesn't have to follow my preferred design pattern to be clean. The bar is don't be shitty, and I'll know shitty code when I see it[1].

1 - https://www.wsj.com/articles/BL-LB-4558

I really doubt there is any such consensus. Some people really care about superficial code quality (good variable names; short functions; consistent formatting and documentation; compiles without warnings). Other programmers care mostly about architectural quality (shallow call stacks; correct data structures; few dependencies and little scaffolding).

As stated in the previous comment, if you give code from group A to group B, they will tell you “I would prefer this and that, but still seems clean to me”

I don't agree. I know what the previous comment said.

Modern C++ codebases that make extensive use of templates, inheritance, exceptions, type coercion, closures are considered clean by many because the code looks nice. But code like that can be a nightmare to work with, because of long compile times, spooky action at a distance, etc.

Take these two files from LLVM:

https://github.com/llvm/llvm-project/blob/main/libcxx/includ...

Is this "clean code"? I'm confident there will be absolutely no consensus.

It depends on the language. Some languages are just poorly designed and make it really hard to write anything that’s clean without trade-offs.

I disagree. While one can argue pointlessly over which code is the cleanest, it's very obvious when the code has a complete absence of it. I think of some 3000 line classes that I have met and done battle with.

The sibling comment that talks about "how quickly they can understand and use your code, and whether they can make changes without worrying about breaking things" is on the right track.

Writing good code requires good taste. Taste is subjective and cannot be easily codified. That doesn't make it arbitrary. Ask ten people about their favorite movie and they'll name ten different films, but I'd wager no one will say "Gigli".

“All [clean codebases] are alike; each [ugly codebase] is [ugly] in its own way.”

-Leo Tolstoy

That's a bad analogy. People will certainly have different favorite movies, but they can also come to agreements on what's a "good" movie. There are a bunch of movies that I think are "good" movies in a more objective sense, but aren't my favorite things to watch. There are movies that I thought were excellent, but I have no desire to see again.

I agree. The hardest thing I had to learn as a professional programmer: There are multiple styles of good taste. You need to be tolerant. When I look at some GitHub code reviews, I cringe at the number of pure aesthetic (aka low value) issues that people endlessly nitpick about. It is discouraging towards contributors.

I work on a team now where the three main contributors (including myself) all have _reasonably_ different programming styles (naming, whitespace, structure, const/immutable, algos). Having read enough code from the other two: I am confident they are good programmers, but their style is different from mine. Still, we try very hard to accommodate each other's style. When we make changes, we try to stay with the current style in the class / method. It has been a real learning experience for me.

This would be a hard no from me. I cannot stand having to switch style when working on the same codebase or even in the same company.

codestyle enforcement via pre-commit hooks or CI build failure is the way to go. Trying to adpat to codestyle is a distraction. All distractions should be removed when coding.

No, it is not. That is like saying art is objective so we can't say if anything is good or bad.

Don't you know a bad API, variable name, or architecture when you see one?

I agree with you. From experience, this pain is a red herring, it’s symptomatic of a specific kind of change: new features or bug fixes that require tight coupling of previously-authored-as-decoupled things. Clean code, architecture, whatever - it always falls over in the specific transition from decoupled-to-coupled.

Why do programmers hate making those changes? They always require tossing out a lot of existing code. So I guess I could say the antagonist is inertia. Certainly has been my experience interfacing with vendors and BigCo developers. If you have the ability to suppress this feeling, to delete stuff that works but is not correctly coupled to the new problem, you will thrive regardless of the architecture.

The heart of your comment is true, but good organizations establish a set of standards for how they define clean code. At that point, it's no longer arbitrary.

Devs also overestimate the difference their "clean code" actually makes. Architecture is much more important.

Totally agree.

But still, we should strive for writing the best "clean code" that we set out to write. So "clean code" here is subjective and bound to the individual. Normally, business and absurd deadlines force us to lessen that principle—that's what I call "ugly code".

> whether they can make changes without worrying about breaking things

In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.

EDIT: A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.

> In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.

I think that's an issue with how people define "clean." It isn't just about surface aesthetics. Think of a cooking appliance that looks "clean" in its design, that might win a designy design award, but accumulates gunk in hard-to-reach crevices because it was only designed to look clean, not designed to be kept actually clean.

Fair enough - it may be that I've never experienced "real" clean code. But I've worked with many good engineers and seen this problem repeatedly. However, no matter how unclean the code is a rigorous test suite will find many regressions.

A modular architecture will prevent changes to one system from breaking other systems.

hard disagree, there are definitely ways to prevent this, it's a matter of do developers even consider it?

No, they don't. But that's the problem, you can't force all developers to consider these issues and adhere to coding standards. Sure, you can do reviews and then make them do that, but if they have to pass a suite of tests before it even gets to review then that's going to save everyone's time and train them to do it right.

Coding standards an cleanliness are at the wrong level.

What makes it easy to make changes, add features, find bugs, etc. is good design.

Testing can help find problems, sure, but you can't test in quality (you can only, to a degree, test in robustness).

The difference between a decent design and a mess is mostly what happens when your "simple, local fix" causes unexpected tests to fail. If your first reaction is "damn, guess we can't do that" three is a good chance you have a mess on your hands.

Clean code (yes some of this is just taste) is mostly a symptom that people have been thinking about this stuff, not a guarantee.

There is a corollary though, which is difficult. Quality of design and techniques used mostly put an upper bound on the complexity the system can have before it becomes unmanageable. If it grows long enough though, it will get there.

> A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.

This failure mode often comes from parts of the system being coupled when they shouldn't be, or it's not obvious that they are.

Have you ever had a change to a logging statement break cause some other code to stop functioning? I have. And I was thoroughly disappointed by the person who made a logging statement have any effect outside of logging.

Clean code needs to adhere to principles such as the Principle of Least Astonishment[0], otherwise code is bound to break when other people modify it.

[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

About "Principle of Least Astonishment": In theory, it is cool. In practice, it is often used by gate keepers to shutdown newbies. After seeing that behaviour too many times, I stopped using the term.

A nicer way to say it (from pair programming ethos): If someone asks you a question to clarify some code, then it needs a comment (or a re-write/re-factor). Note that I didn't say anything about the experience level of the asker.

One more thing: I've met (multiple) people who are firmly in the "Convention over configuration" camp and the "Principle of Least Astonishment" camp and cannot understand how new joiners are continuously surprised by this or that convention.

Sometimes what some people think of as clean is really more "optimized for the current state or the project." that seems fine, until next month the new feature requires that "clean" code be ripped apart because it encoded too much of the current program state as assumptions in how it worked.

Be careful not to conflate clean code with premature optimization. Clean code is easy to read and follow and works in obvious ways, it isn't necessarily the fastest or most efficient code and nor does it mean it has to use deeply nested knowledge of how the system works to function in ways that are non obvious to new readers.

I wish people would understand this better. "Clean code" doesn't exist. You should define (and automate) quality gates for your code base as a regular team excercise. I've seen enough teams not even having a common agreement on what a code review is and then trying to do them. When regularly wondering on a code review if change X meets the subjective taste of reviewer Y or even getting into fights you know somewhere something went wrong in team culture.

Tests matter, but elegance and simplicity matter, too. Tony Hoare said, "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it." All code needs module-level or API-level acceptance tests so that anyone can change it and deploy it with confidence, but well-written code needs fewer low-level tests of implementation details.

I agree with what you wrote, but I've worked with people who balk at even automatic gates. "Pass pep-8, as enforced by pycodestyle" was practically too much for one coworker I had, who, when it was pointed out in review that "the automated CI step was failing, can you please make it green?", would fix like one violation, then just ping their reviewer? And around the mulberry bush we went. Various odd arguments like, "well, my IDE has pycodestyle built in, and it's fine" (it seemed like his IDE had its own, separate, lenient config? … but like, nobody cares about your IDE…?) etc.

At $different_employ, there was lots of thrashing of teeth pertaining to `yarn audit` running against the codebase, and failing people's builds. Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed. Later, other people did much gnashing and wailing over being "confused" because the yarn audit step was red-X, and they were confused as to why it was breaking on their feature branch. It wasn't: it was failing, but marked to be ignored, so the build continued. Other, required steps, were failing. (And were also marked with red Xs.) This was "all too confusing", and it was petitioned for yarn audit's CI step to just "fail" with a green checkmark. You can imagine, I'm sure, how many vulns. were addressed after that point.

I've also worked with devs who are just amazing, and aside from being brilliant in how they architect their code/systems in the first place, … they have a definite tendency to view lint errors as just "oh, oops, silly me fixed" and just Get It Done.

QC is hard.

(Regarding our audit step, too: we also had an ignore list. You could just add the vuln. to the ignore list, and that would technically placate CI. Obviously not the best … but CI didn't demand that you fix whatever the issue was.)

> Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed.

Well, here is the problem this introduces. Who is supposed to fix this and which PM's bucket of time does it come out of? This implementation just makes it seem like the answer is "whichever team is unlucky enough to make a PR when it is discovered." The perverse incentives of that are enormous.

> You can imagine, I'm sure, how many vulns. were addressed after that point.

This tells me that the responsibility isn't specifically assigned. This seems to be the broader issue, with the audit in the pipeline a managerial attempt to get vulns somehow fixed without doing the work to figure out how they will be fixed and who will do the work.

Someone actually needs to be responsible for it and be given time to do the changes. It seems like this was not done.

> Who is supposed to fix this

The team of eng responsible for the code against which a vuln. has been detected, would be my answer.

> This tells me that the responsibility isn't specifically assigned.

Well, no, for the very reason you've highlighted: PMs will be damned to have that time come out of their bucket. That is a problem, and I rather doubt this subthread'll solve the idiocy that is PMs.

Nonetheless, if we accept that vulns. are something the industry should pay attention to, i.e., that "keep stuff using secure versions of dependencies" is actually a best practice the industry should adhere to, someone has to triage the audit report, and then someone yet has to do the deed of correcting it.

Yet both your comment & a sibling have advocated the position of "no, drown the test result, don't block builds". If builds aren't blocked, there is zero impetus towards ever fixing vulns., so they don't get fixed, ever. You cannot, IMO, ignore human nature when setting up these kinds of QC checks in CI: if you make them optional they're as good as dead, cause people are lazy.

You're missing the larger point of my comment, too: there is no sensible setting for that CI step. Say I don't care about what the CI step does, say I don't attempt to take a position in this idiotic debate. I can't: literally any configuration boils down to one of two cases: a.) we're flagging the problem, and devs don't like that and whine and complain or b.) we're ignoring the problem, and security people claim they don't like that, and whine and complain.

I think you're also forgetting how software is actually developed in the wild by many companies: this example, like so many, use a "monorepo". I don't like this (I'd argue for single-purpose repos, and it'd be obvious who the owner of a vuln. is, since the whole repo is only owned by one team.) but nonetheless I'm pretty consistently outvoted on this point, and the majority of firms out there seem to go the monorepo route. So, in a monorepo, "who" is responsible for a vuln. against a third-party dependency? (It can be figured out, but the answer is certainly not as straight-forward anymore!)

(Single-purpose repos aren't without issue here either: often I find in that case that establishing these sorts of "common" CI steps to be hugely problematic: you sort of have to c/p a lot of code between repos, keeping that step's code updated is then a PITA, and many CI systems lack good support for "use this common step, perhaps not even located in this repo".)

To me it seems like the better way to run such audit code is against the main branch periodically, and it's someone's job to triage failures at high priority. Attaching it to unrelated changes is half the problem. But it's not something that fits into the common CI workflow which assumes breakage comes from code changes, not updates in an external vulnerability database.

> Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed.

Well... yeah? They're working on a feature and get arbitrarily told that they're not allowed to merge the feature until they go fix some completely unrelated vulnerability problem. How is that reasonable?

Anything that can be automated for QC, should be. But if you want to completely eliminate subjectivity, you have to stop working with SW. There is nothing an will never be, something that can test if code is really easy to understand. Had you such tool, the tool will be able to code by itself.

> > 3) Nobody gives a f* about your clean code

> This is true most of the time, but assuming your boss and coworkers are doing their jobs well (which is why it's not true most of the time) people will regularly communicate the things that are helping or hindering in their work.

Code reviews seem to be the norm now. I'm struggling to see how that aligns with everybody not giving a fuck about code quality.

Maybe it was true. 40 years ago, we noticed code gets read many more times than it is written. It took us a long while to do something about it, but now insisting programmers produce readable code is easy to read where the industry is at.

It's not just "the industry" either. Try submitting a bad piece of code to the Linux kernel and see how many fucks they give you. It's the same for an open source project that does code reviews.

I think the problem is that, while most people agree that badly factored code that drags down productivity is a problem, people can't agree on how to make it better. So, discussions about code quality get mired in subjectivity, often people can't agree and if anything changes at all, you agree to some half-baked compromise that doesn't really address any of the issues.

I don't think how you can avoid that unless you find people that have similar ideas to you about how to write code.

That subjectivity also changes over time. Just go back and look at some code of your own after a few years.

Oh yes, I totally agree. Some things that I used to write, I would find insane now.

But it doesn't make the problem any less real. At my current job, I think our tests are really bad because they mostly don't test what really matters (also due to too many things being spread out across several services) and instead are coupled excessively to implementation details. That makes development slow and also means I can never be sure that my changes don't break something important.

having done this, I generally think my old code is fine.

When people say things like I this I always point out that this may be true for the first 2-5 years of you developing but if it's true 15 years in you're not actually improving you're just being mercurial.

At some point your growth as a developer moves outside of code and you recognize that there's beautiful code, devilish code, and then a huge grey area where things are just fine even if they aren't how you would have personally implemented them.

Having been in the industry for 10 years, I would agree that after a certain point, your personal opinions about code style tend to change less and become more consistent, but I still run into enough other people that also have a lot of experience, yet seem to have entirely different views.

Out of interest, what kinds of things would you consider "beautiful" or "devilish"?

I read through the CLANG code back in the early days of its existence and found it to be quite elegant in its structure.

devilish, I once came across where someone had accidentally written a FSM that used http redirects as the transitions between nodes. All to animate a progress bar for a job queue. It was so ridiculous it honestly took me longer than I care to admit to understand what I was seeing, who the hell expects to see that?

OTOH, we have a codebase at my current employer that opens up a TCP socket to a service and passes pipe delimited strings. And you know what? I give the thumbs up to that. Why? The service it's communicating with is an old C++ service that was written around the time that XML started coming onto the scene. That's how you did things back then and it works perfectly fine, albeit it's probably not the most familiar to younger developers.

I think the reality is you'll find that your universe of acceptable code is surrounded by a mess of infrastructure code that may or may not be clean because people don't have the ability to care about everything.

I'm talking about makefiles, build systems, shell scripts, packaging systems, installers and more.

I also think clean code is a luxury. The more your codebase is alive, the more likely that upgrades, features and fixes will go across the grain.

It's not like people are slobs, it's more like a living house where busy people come in out of the rain or snow, or put dishes in the sink for later, or occasionally spill a plate of food on the floor and have to clean it.

The ultimate proof of this is that the new AI models are VERY useful, but are stored as blob more similar to grey matter than structured modular code.

> Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean."

Yes, readable code is the winner. Not "ultra compact" or "so elegant you can't understand it". I once refactored an elegantly written but heavily opinionated codebase for a large feature - and my goal was to hand it off without any downstream complaints - so I doubled the LoC and the team that received it was very happy with all the non-terse logic and detailed comments (good code is self-explanatory on how it works, but not often on why it's there)

One of the highlights of my long career was a new member of the team commenting to me that my code was "the most beautiful" that she'd ever seen. This was in reference to its clarity and actual physical layout. On the latter, I've always been compelled to make my code "look good" as I have much more difficulty working with things that are well laid out.

Yip. A good mechanic has all their tools organised/clean workshop. A shit mechanic has their tools spread all across the shed on the ground, spare parts and other rubbish littering across the ground, etc.

This is why I go out of my way to praise good work loudly and publicly when I see it.

If everyone merely accepts good work silently, but talks about bad work all the time, then political focus within the org will shift to bad teams and bad people. At the extremes I’ve seen this result in the worst people getting promoted to the highest positions because they were infamous. That’s the same as being famous.

Think about Trump: he got elected because nobody could shut up about him, so to a lot of voters didn’t know anything about any other candidate. They voted for the one they recognised.

“He may have his flaws, but he’s not that bad.” is something I’ve heard at work and in the public sphere.

You’re immune to this effect, you’re about to say?

Name five good things that Hillary has done.

> Name five good things that Hillary has done.

You got me absolutely confused here. There are 5 good things she had done? I think this proves that a bad alternative can get anybody elected.

I think you’ve just confirmed my point.

She’s worked in public service for decades and has done many good things in that time. Most people can’t name any.

Everybody in the world can name five (fifty!) bad things Trump has done.

That’s why that man lives rent free in our heads. That’s why everyone knows his name. That’s why he got many of his votes: he’s recognisable.

This effect has nothing to do with any specific politicians.

It happens in workplace settings also. The quiet achievers get overlooked. The loudmouth screwup gets attention and even promotions.

I’m old enough to have seen this play out over and over again at every scale.

Or maybe she is as bad as the voters took her for and you are delusional.

You're missing the point.

The point is not whether Hillary is good or bad.

The point is that most people are unable to remember good things that even very famous career people have done, despite this information being in the public record. It's just not covered, repeated, and as memorable as bad things that people have done.

You're focused on "Hillary bad!", not realising that that's the point I'm making. You can only remember bad things.

The exercise is to see if you can name good things. You can't, not because she's unadulterated pure evil, but because good things are not as memorable in general.

Try for a moment to rise above your primitive animal tribal instincts and think like an anthropologist.

Sorry to disappoint you but you're thinking like a Hillary fanboy, not an anthropologist. Democrats had better options available that'd have beaten Trump but people like you decided that Hillary was supposed to be the next president. Not many opponents would be so good at electing Trump.

Do you... hear yourself?

I'm not even American!

I picked an example at random that I knew everyone would be familiar with. I have no skin in this game and who won or didn't win isn't the point. The point is the rules of the game.

> I'm not even American

Which proves the point you have no idea what you talking about. Go ahead then and list 5 great things she did.

I don't agree with your Trump example, but agree with your main point.

> This is why I go out of my way to praise good work loudly and publicly when I see it.

This sounds true. Some people do the boring job of cleaning code and keeping the system reliable never got a praise. But some people, who never care about the quality of the system, fight the incidents and are called "hero".

I honestly wish there were some kind of rating system for employers where their code quality is rated on a scale of 0: spaghetti/lasagne precious mess written by a sacred primadonna chief engineer who must be deferred to reverently and takes a year or more to get the hang of, to 10: fully unit tested, integration and pre-prod environments, minimal pagers needed, competent QA, etc.

> You can forget that your boss will tell you: "Congratulations on writing this elegant and clean code, I am gonna give you a raise!". Quite the opposite, nobody cares about your clean code.

> Don't get me wrong, people will expect you to write good and clean code. Still, you will rarely get any praise for it. Except sometimes from your colleagues who will review your code.

If I can read your code, I don't give a frog's butt if it's up to the nose in the air crowd's standards. That just isn't what is important to a business that actually wants to survive and make money. It's crazy, those same blog heads are the ones who are always so quick to advocate for a "total rewrite" every 6 mos. They think all this nonsense makes them Pros.

As most things in life it depends.

Especially true in game dev

Reply on news.ycombinator.com