9 ms·

> 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

by dkarl 3y ago

> 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.

jebarker 3y ago
> 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.
- dkarl 3y ago
  > 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.
  - jebarker 3y ago
    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.
- kinonionioa 3y ago
  A modular architecture will prevent changes to one system from breaking other systems.
- PH95VuimJjqBqy 3y ago
  hard disagree, there are definitely ways to prevent this, it's a matter of do developers even consider it?
  - jebarker 3y ago
    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.
- ska 3y ago
  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.
- justin_oaks 3y ago
  > 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_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
  - throwaway2037 3y ago
    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.
Tainnor 3y ago
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.
- sroussey 3y ago
  That subjectivity also changes over time. Just go back and look at some code of your own after a few years.
  - Tainnor 3y ago
    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.
  - PH95VuimJjqBqy 3y ago
    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.
    - Tainnor 3y ago
      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"?
siva7 3y ago
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.
- dkarl 3y ago
  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.
- deathanatos 3y ago
  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.)
koolba 3y ago
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.
- docmars 3y ago
  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.
  - AdamN 3y ago
    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.
    - koolba 3y ago
      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.
    - randmeerkat 3y ago
      > 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/salesforce-transit-center-cracks/ https://www.popularmechanics.com/science/a29329189/salesforc...
manicennui 3y ago
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.
- esafak 3y ago
  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?
  - doctorpangloss 3y ago
    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.
- ctvo 3y ago
  > 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 https://www.wsj.com/articles/BL-LB-4558
  - gizmo 3y ago
kbenson 3y ago
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.
jiggawatts 3y ago
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.
- meiraleal 3y ago
  > 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.
  - jiggawatts 3y ago
    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.
    - meiraleal 3y ago
      Or maybe she is as bad as the voters took her for and you are delusional.
      - 3y ago
diyseguy 3y ago
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.
HumblyTossed 3y ago
> 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.
AceJohnny2 3y ago
> 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")
- justin_oaks 3y ago
  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.
  - foobazgt 3y ago
    "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.
  - 9dev 3y ago
    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.
- ncr100 3y ago
  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.
norwalkbear 3y ago
Especially true in game dev
rstuart4133 3y ago
> > 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.
r00fus 3y ago
> 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)
deleted 3y ago
[deleted]
fatnoah 3y ago
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.
m463 3y ago
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.
fennecfoxy 3y ago
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.
lobocinza 3y ago
As most things in life it depends.

by dkarl 3y ago

jebarker 3y ago

> 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.

dkarl 3y ago
> 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.
- jebarker 3y ago
  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.
kinonionioa 3y ago
A modular architecture will prevent changes to one system from breaking other systems.
PH95VuimJjqBqy 3y ago
hard disagree, there are definitely ways to prevent this, it's a matter of do developers even consider it?
- jebarker 3y ago
  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.
ska 3y ago
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.
justin_oaks 3y ago
> 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_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
- throwaway2037 3y ago
  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.

Tainnor 3y ago

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.

sroussey 3y ago
That subjectivity also changes over time. Just go back and look at some code of your own after a few years.
- Tainnor 3y ago
  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.
- PH95VuimJjqBqy 3y ago
  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.
  - Tainnor 3y ago
    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"?

siva7 3y ago

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.

dkarl 3y ago
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.
deathanatos 3y ago
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.)

koolba 3y ago

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.

docmars 3y ago
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.
- AdamN 3y ago
  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.
  - koolba 3y ago
    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.
  - randmeerkat 3y ago
    > 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/salesforce-transit-center-cracks/ https://www.popularmechanics.com/science/a29329189/salesforc...

manicennui 3y ago

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.

esafak 3y ago
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?
- doctorpangloss 3y ago
  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.
ctvo 3y ago
> 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 https://www.wsj.com/articles/BL-LB-4558
- gizmo 3y ago

kbenson 3y ago

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.

jiggawatts 3y ago

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.

meiraleal 3y ago
> 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.
- jiggawatts 3y ago
  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.
  - meiraleal 3y ago
    Or maybe she is as bad as the voters took her for and you are delusional.
    - 3y ago

diyseguy 3y ago

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.

HumblyTossed 3y ago

> 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.

AceJohnny2 3y ago

> 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")

justin_oaks 3y ago
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.
- foobazgt 3y ago
  "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.
- 9dev 3y ago
  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.
ncr100 3y ago
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.

norwalkbear 3y ago

Especially true in game dev

rstuart4133 3y ago

> > 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.

r00fus 3y ago

> 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)

deleted 3y ago

[deleted]

fatnoah 3y ago

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.

m463 3y ago

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.

fennecfoxy 3y ago

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.

lobocinza 3y ago

As most things in life it depends.