Most guru's take an 'all or nothing' approach, this goes beyond programming, look at food-guru's "eat only carbs, never eat refined sugar" etc. This is for me the same as "always do TDD, never use static methods".

People without experience often look at guru's because they can not yet think for themselves.

I'm a developer in my 40s, have done a lot of projects in a lot of different companies. Having this experience gives me intuition about what to do in what situation. I just (think I) know when I should write a unit test and when not.

The 'all or nothing' attitude is created by people who want to be guru's and is followed by people who want to have some guidance.

This is not a bad thing, it takes time to shape yourself as a programmer. This takes years: http://www.norvig.com/21-days.html

Learn from the guru's, and be consious, people preaching an 'all or nothing' view of the world are NEVER right :)

IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof').

Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter how well it started ;)

This just seems like poor justification for laziness.

You need to keep a project clean. This means profound refactors when concepts for the product change. Some rules are:

- Keep it readable

- Don't over engineering

- Easy to remove

- Good tests (complete, min stubbing, interface oriented. Never refactor and change tests at the same time.

A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant. It takes effort to maintain a clean project, many will try to say "it's not worth it". That's just out of the question, it's your job, it doesn't have to be always pleasant or easy. If you don't suffer for it a bit now, someone else will in the future (maybe clients or users).

This is what I like about open source projects, it teaches maintaince discipline. In the end, you can sum up all rules into one:

- Make it easy to maintain

So no data, no examples, no anything. Full of such wisdom as "Testing isn't as important as it might seem but it's still important"

The only thing actually articulated was "you don't need 100% test coverage", which is not contrary to existing practice (afaik). I'm not sure the singular point nested in platitudes can be useful to me.

On my side projects at home, I can't even remember the last time I had to slow down or got stuck on maintenance/integration type stuff (as opposed to new functionality or algorithms, which don't rely on existing code). And I have a couple of fairly big ones, it's not all "Todo list" stuff.

It's happened constantly at work though, throughout multiple jobs. Sometimes I've been so stuck I've got basically nothing done for days or weeks at a time. Sometimes that happens a few times in a row and I feel like I'm an inch away from being fired for incompetence. This even happens on relatively small projects. It's not confined to big 10 year old monstrosities.

The sad thing is, I work for startups, which should be all about lean, clean code and making big changes rapidly to respond to business needs.

I think a lot of it comes down to how hard it is to work on other's code. I don't think any of the conventional wisdom is a solution to this problem either. I haven't noticed any discernable difference between projects with big fuck off linters, or 50 page style guides. It's not a mish mash of semi-colons that's causing trouble (although consistency is nice).

"Dirty code" is really the crux of the problem. But like the author of this article, I don't always agree with what the conventional wisdom says about writing clean code.

To me, the most important part of keeping your code clean is always having the minimal solution to the problem. Your code shouldn't do one thing extra it doesn't need to. Half of this is YAGNI, half of it is being a good enough developer to come up with simple solutions that aren't too fancy.

On that note, don't get too fancy, and don't take DRY too seriously. Whatever complicated mess of higher order functions you're writing probably isn't going to phase other experienced devs in a vacuum, but combined with all the other icky parts of the code base and it might just be the straw that breaks the camel's back. If you need to write twice as many lines to make it more grokable, that's fine.

Speaking of YAGNI, people should be applying it somewhat to dependencies as well as functionality. It's just far too easy for a simple React project to blow out in complexity because of an over-reliance on other's code. Sometimes it's easier to build something out of code than NPM Lego.

Criticizing code for not being "clean code" is 70% of the time "I don't like this code for various reasons"

Not to mention of the pedantism of one of the biggest proponents of clean code.

So, in essence, worry that your code has a certain quality but in the end all projects will end up in the trash can. It's software, not the Mona Lisa.

I think the problem here is that 'clean' is an umbrella term for a bunch of different things. To sum them it is: 'how does this code make me feel inside'. But what goes into that are: readability, extensibility, maintainability, testability, clarity, correctness, simplicity, and yes, aesthetics. Some of these are objectively always good, and some of them are contingently good.

For instance, a simple algorithm for distributed consensus is probably not correct, and you should rightly not view it as 'clean'. Some things simply aren't simple. The goodness of simplicity is contingent on the complexity of the problem.

But aesthetics is at the final end of the spectrum: it's purely subjective. And yet we wrap all these things up under the term 'clean', and so it is confusing. People will defend their notion of cleanliness using the objective standards, and then apply it to the subjective cases.

Given how young the practice of programming is, I doubt anyone alive today knows how to write truly good code. Just look at the kind of code people used to write 30 or so years ago. It's interesting to think about: what will "clean code" look like in 2047?

RE: Automated testing.

Modulo certain forms of static analysis, your code is ultimately only as good as it is well tested[1]. Non-automated tests do count here, but for long-maintained codebases the cost of automating pays for itself very quickly.

1: Note that pretty much all code has been informally integration tested (A "can I run it" type of smoke-test is a very simple integration test). Similarly all compiled languages (and any interpreted languages that parse an entire file before running code) has some static analysis, as syntax errors will be caught. Unless you check in code without compiling or running it, you are already doing some testing.

I don't understand the negativity in the top voted comments here! It's almost as though I read a completely different article than the one being commented on.

The comments here are being dismissive and then reiterating what the post said! Here's the summary from the post :

> So I stopped worrying about whether my code is perfect. And I just accepted that if I can't see any immediate flaws with the code, and if all the tests pass (whether automated or manual), then it's fine. And I trusted that if I ever come across a bug, I can fix it.

Why, specifically, is that a bad thing?

I love the story about a group of American car manufacturer executives visiting factories of Japanese car manufacturers in the 80's. After returning to the US they were asked about their visit and they remarked that the Japanese did not show them their real factories, as the Japanese factories were too clean according to the American executives. As it turns out, a clean work environment (and that includes source code) has benefits if you are doing logical work.

Sometimes the warts are just warts and mistakes, sometimes there is a deep undocumented reason for it. Which indicates a problem as reasons like that should be explicitly documented.

And yes, often clean code actually is finished. Mess is often produced by wrong architecture or rushed development which means not finished if maintainability is in your definition of code being done. What the author probably meant is concise code instead.

There is something really cool about looking at a large enough codebase, and just reading it. Then when you absorb it, then you might see a way to refactor it. I did this with the error handling code in the VCL module of LibreOffice. Frankly, I just did some renaming and a small bit of logic changes, but it just made the code far easier to understand and work with.

Promising title, but not enough content.

Shitty documented code beats clean undocumented code for maintenance. Maybe we need more "how to document my codebase" tutorials than "how to reinvent the wheel in this shinny new language" ones.

Attended a couple of clean code trainings, always wrote the shittiest code for a week or two afterwards. ¯\_(ツ)_/¯

Essentially you are recommending that people slack off as soon as they face trouble instead of spending time making sure they don't break stuff. Had you mentioned Continuous Integration and many commits per hour I would agree that tests and nurture is less important but you seem to base your thoughts on the laziness of old people.

What's the fence story?

YAGNI?

This guy mix and match totally unrelated things.

- clean != finished

- clean != perfect

- ugly is not clean

- you can understand a code and find it still ugly

What is he actually talking about?

> Automated tests are not that important

I agree with the content of this section, but the title is bad.

> A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant.

Sometimes, your new paradigm is actually something that they tried 10 years ago.

> In the end, you can sum up all rules into one: Make it easy to maintain

That is only one of the many facets of programming that you have to balance: performance, memory consumption, ... .

If you want to push your system performance to the extreme, believe me, "easy to maintain" is not going to happen. But that is the trade-off that you will have to make at that point.

Veterans know that everything is a trade-off.

Let me give you one extreme: you are writing a throw away prototype. How much time and effort are you going to spend (=waste) on making your code easy to maintain?

I'll give you my veteran answer:

- If you are in 100% control of the project, you know you will throw away the prototype, and you can throw things quickly together.

- If you have a manager, he will take 1 look at the prototype and say "Wow, it's almost complete! Don't start a new project, just add these features to your prototype and it's done.". So in that case, make the "throw away prototype" easy to maintain.

That is what veterans bring to the table: making trade-offs in specific situations. And they've been through a lot of situations.

I experienced while writing a lot of tests, the code suddenly became - more readable - less over-engineered - replaceable - easier to maintain since it's easier to write tests for "clean code".

I'm 33, and while I don't think I'm "at the top of my field", I have experienced quite a bit and am confident that I can both produce and identify high-quality code.

In my mind, the biggest change as I've grown in my career is that I've gone from judging code quality to judging code suitability.

For example - the application I'm working on right now, there is is a javascript file that initializes complex data tables using the jQuery DataTables plugin. It's several hundred lines of redundant code, with several functions that actually do the initialization differently depending on the classes that are applied to the table element. It is unquestionably "low quality" code, but I have no intention of attempting to refactor it. Why? Because there are customers whose UIs are dependent upon the bugs and undocumented assumptions that are baked into that code, and refactoring it would break things from their perspective. If I did that, by the time I dealt with all the bug reports and feature requests from customers, the nice clean code that I'd written would look like the code I have now. Instead, I've written a new JavaScript file to initialize data tables going forward, and all new instances use that. They are slightly visually distinct from the "old-style" versions so users know to expect the slightly different (but now consistent) behavior. I'm very resistant to adding features to the legacy code, and instead, offer to "convert" the legacy tables to the new layout one-by-one when a new feature is requested. Eventually, we may reach a point where we can retire the legacy code - but in all likelihood, that code will be there longer than I will work here. This approach of "walling off" code that has become unwieldy and difficult to modify is one of the things that I look for when determining where a developer is in their career.

> You need to keep a project clean. This means profound refactors when concepts for the product change.

If the purpose of a company were to produce the most excellent software possible, I'd agree with you, but the purpose of a company is to make a profit. If you do a "profound refactor" every time requirements significantly change you're likely to never launch a product at all, much less iterate quickly enough to build a profitable product. You have to learn to deal with cruft and manage its lifecycle, not try futilely to prevent it from ever occurring. Part of that is learning to break things down into discrete components and limit interdependencies so you can refactor each component in isolation, but another part is learning to segregate cruft that has accumulated and keep shipping without creating a mess that slows down how quickly you can iterate in the future.

> It takes effort to maintain a clean project, many will try to say "it's not worth it".

"Worth it" doesn't necessarily mean "worth it from the perspective of the developer". It can also mean "doing this right is going to take longer, and in order to meet our business goals we can't take the time". As long as the long-term impact of these decisions are passed on to the decision-makers on the business side, there are absolutely times when "it's not worth it" to write clean code.

> That's just out of the question, it's your job, it doesn't have to be always pleasant or easy.

Nope. Your job as a developer is to provide more business value than you consume. If you're getting paid $100k you must provide more than $100k of value or you will eventually be out a job, regardless of how clean your code is.

Do you have examples of things you learned on the courses that you thought made your code more difficult to understand and modify?

After that, did you completely switch back to the code style you were using before the courses? Did you cherry pick some things and not others?

Just to make my view plain, for me 'clean code' was the most important book I've read in my career, and what I learned from it has (in my view) massively positively influenced the quality of my code over the years. I'm really interested in getting an opposing viewpoint. At the end of the day I'm aiming for my code to be understandable and maintainable by other people as much as myself.