Clean code bullshit?

Well, what is all this about clean code that we all hear?

To quote what clean code is from A Handbook of Agile Software Craftsmanship by Robert C. Martin is

Clean Code refers to writing software in a way that is easy to read, understand, and maintain.

Well, now I am not going to bore you by saying all the advantages and all the shitty things you can get from the internet and ChatGPT/LLM's. I am here to rant about my experience of writing "clean code" and what I actually learned from following the practices.

Okay so, a back story to this, I switched from a pure tech startup company that has been there for around 7 years or so to a primarily non-tech based company where they recently acquired another small service-based company to build software for them. And I wasn't expecting the experience that I got over here. Coming from a pure tech company, I was on top of my world, I know things and I was pretty confident about whatever was about to come until I saw the code base. And I remembered the line by Mike Tyson:

Everybody has a plan until they get punched in the mouth.

And all my confidence was shattered just by seeing the code base that was written by a single person and that happens to be my manager. Oh man, I can't still forget that day. And I didn't even see the complete internal code working flow at that point. Just a couple of files and I was feeling terrible, and the imposter syndrome hit me, I know nothing and all.

And then I got to know that I have to work completely on a new project and a new empty repo where I will have to write everything from scratch and follow the code standards as maintained by him. And god, seriously, I just felt like how the fuck will I be able to maintain this, even though I can write the code, I have to write the documentation for every function that I am writing, full proper doc-strings and the function params documentation as well.

Here is a sample function that I wrote as an example.

def op_numbers(a: int, b: int, op: str = "add") -> int:
    """Do some operations on the two numbers.
    : param a: the first number
    : type a: integer
    : param b: the second number
    : type b: integer
    : param op: operation, optional, defaults to add
    : type op: string
    : return: the number post operation
    : rtype: string
    """
    #if op == "add":
    #    return a+b
    if op == "subtract":
        return a-b
    return a + b  # need to return the valid data or else it takes None as return type

Now here I can't leave a commented code and not have docstrings in the function and the return type and all sorts of nonsense bull shit things, that are managed by a hell long list of the pre-commits config file having around 20 configs for every possible python code quality you can imagine.
A few being (the most painful of all): pylint, ruff, mypy. There 3 just became my arch enemy whenever I tried to commit my code in the initial days.
I had to make sure that the code I had written was according to the Python coding standards and the rules that they had been laid out.

And initially, I used to love Python because of the extreme flexibility that it provides, but daam it, those pre-commit configs and the rules.

It's just the tip of the iceberg I am writing about, every function should be decoupled!

Give me some peace in this life!

When I finally adapted to this after a week or 2 things just started to fall in place, at least I was able to write code without much of a hassle.

But it was not until a month or so after, that I realised the bitter-sweet part of writing "clean code" and that changed my view of this "clean code" thing entirely!

The project that I started and thought that the code for was super good, initially, each module separated out and did just what it wanted to be.

But then later down the line came, the interlinking of those modules and that's the point, that just fucked up the complete repo. We,(I and my manger) thought its not going to be this big of a project, so let's not write a connection class for each of them, rather just directly write functions to call the APIs and process them there itself, and just to separate the very common stuff like DB connection managers and other utils functions, like datetime functions and all.

But god knew that it was about to get this interlinked and end up like a spider web, every function being interlinked with each other. Importing stuff from 2 different modules into the third one and having other calls as well.

This just so fucked the code base that, we ended up re-structuring the project, with the connection managers in one repo, i.e. connection manager wrappers to be exported as a package and that will be imported into our main business logic repo.

This just made so much sense and the level of abstraction and code de-duplication we achieved was at next level. Just write the connection modules, and that later can be used by other teams as well for their direct integration.

Just made so much sense. Wished that we would have planned this earlier and that would end up saving so much time, but then I wont get to know the importance of that!

Okay, so now we know that writing better obviously will make your code more readable and more clear for others to understand.

But more than that, it will prevent you from situations like this:

It happened. I was just so frustrated with the piece of shit that I wrote that I thought was at the next level while writing, but...

Anyways, its a part of the learning curve. And we all have something to learn from our mistakes, no matter how small they might be. But we learn and we grow.

So, next time you plan to write a piece of code that only you understand, make sure you don't write that code.

And just please for your own's sake, plan the code architecture up front and dive into every possibility and future enhancements that might come up to not being frustrated at very down the stage and having that urge to fuck the repo and starting again with a clean slate.

Until then, Peace.