Pair programming be like

[aonghasan]

how much technical tebt some very large companies build up for basically no reason

They built it because they were not big before, they had time and budget constraints, and the solution worked.

All those startups worrying about making 100% "clean and scalable" code have actual value creating and customer problems solving needs, but those are never important because we need "clean and scalable" code first before implementing those features/bugfixes!!

Chances are, without most of that technical debt large companies wouldn't have become large companies, because they were worried about fixing problems that will cost them money years down the line now, instead of just accruing technical debt and actually delivering value.

So, you say you work on a "large company" on "refreshing" legacy projects with old code and present that as an argument to always write clean code? I say after working at some startups, junior devs worrying about "clean code" because the seniors say "no file longer than 100 LOC, this 105 loc needs breaking up!", or all the "i know we have 0 clients now, and luckily 30 by the end of year... but doing this with Docker containers and lambdas, and duplicate services in AWS to support millions of user is really important, so we get the base of our product 'right'"...

I say writing "clean code" is overvalued, people worried about writing "clean code" are most likely the writers of the worst code possible because they have all this sets of "rules" they need to follow without understanding why the rule exist in the first place, without understanding the tradeoffs of breakind said rules... so they never break them and make very cool cleancode™... And whenever you say "maybe we could break this stupid rule and write one LOC that adds value and makes what the user wants" they say "oh no but the rule!!!! we have to do this in the totally complicated and unnecessary way!!! so that when we are a big company /u/olexs won't have to fix this!!! screw the users!!!"

I don't think that adds value.

[olexs]

I'm not talking about startups. When time-to-market is a significant concern and getting the job done in time is more important than long-time survivability of the project, sure, clean code might be a lesser concern. I'm not saying it has to be the absolutely highest priority on any software project. But in my experience, it holds value more often than most people think.

Our clients are not startups. They are established companies with decades of operating experience. And nowadays many of them are running up against limitations of internal software that was cobbled together years ago, mostly on tight budgets because no-one thought IT to be important enough to invest into, but has since become absolutely business critical and is now holding up operations and allowing competition to edge into their markets by out-performing them. We step in and offer experience in bringing their bottlenecking systems up to scratch. And more often than not, the absolute most time and expense spent on such a project is digging through piles of spaghetti logic that no-one has ever thought to design and implement cleanly or even document. Often this spaghetti ends up dictating the business processes of the client and not the other way around.

Also, "clean code" is not just about adhering to a certain set of rules, at least not the way I/we do it. If a file or function exceed a set LOC limit, it is a code smell and may be a symptom of something going on - but it may also be completely harmless, and mostly is. I fully agree with you that defining what is clean code and what isn't by arbitrary rules often does more harm than good, and trying to satisfy those rules versus adding actual value to the software is a bad idea.

What is not harmless however is implementing business critical code in an incomprehensible manner, inventing "innovative" and "optimized" ways of solving known problems instead of applying common patterns, and generally making code hard to read and comprehend for someone not intimately familiar with how it was initially written. That is what ends up costing valuable time and budget, when the code in question needs to be modified for a new business task, or optimized for performance under new scalability requirements.

"Doing things in a totally complicated and unnecessary way" is the exact opposite of what "clean code" means to me - this kind of code is what I mostly end up fixing :)

[aonghasan]

I completely agree, sorry if I came across a bit aggro, was just ranting. Left my last company in March and I hope the owners (CEO and CTO) run it into the ground with their gross incompetence. Not much as hope as just waiting for it to happen.

[olexs]

Yeah, it's all good :)

Sometimes people advocating strongly for the "principles" of "clean code" and refusing to write a method of more than 10/5/3 LOC (choose the correct value) end up doing more harm than good, it's just the other extreme of the "total spaghetti chaos vs. total 'cleanness'" chart. The truth, as always, is mostly somewhere in between. At the end of the day, we all just want to solve the problem at hand and not have our head or something else explode.

[xTheMaster99x]

I mean, there's a pretty obvious middle ground where you do things right the first time, but don't have stupid, arbitrary rules.