Things I read and thought of vol 1

Very unstructured, pardon my train of thought, but it's my attempt to get back to writing after a longer break!

Show me one person working close to software that hasn't heard of this phenomenon before - technical debt. The dreaded phrase, for me, mostly shows how deeply spoiled we are. Prima donnas (stolen from Queen's Gambit) - each and every one of us, meek and complacent when faced with adversity. This is one of the most overused phrases in our industry (at least in my opinion) - we throw it around so lightly - at the first sight of anything we would have done differently, whenever the code we are working with won't just miraculously transform into what we need it to be, even when we screw up and are late with delivery we sometimes blame this mysterious DEBT. Don't get me wrong here, I am equally guilty of abusing the term as you are. The article below is a great reminder (along with the links it point to from Fowler and following the chain Uncle Bob) of what it should actually be understood as, namely:

a useful metaphor to inform the business we are taking a shortcut now to enable delivery, but will have to rework the piece if the project / software we are building survives long enough

Since I like parallels to the real world and proper tangible (and very often monetary problems) the ideas the above puts forth make me think of this one as well. It in turn presents an approach to dealing with debt (mind you we are talking about the deliberate-prudent category here) or rather why NOT dealing with it as soon as possible is DNTSIOE (definitely not the smartest idea on earth - I have a thing for "acronyms"). Bonus points for comparing project maintenance to building/house maintenance!

Following this rabbit hole has led me to many thoughts on how we can avoid incurring it in the first place. Best practices and design patterns to the rescue - but do they always deliver on this promise? While I know that a clean codebase and industry standard patterns will make my / future developers lives easier if the project lives long enough, how do I decide if the overhead that the abstractions often introduce will not end up as a classic case of incurring the dreaded tech debt?

I had been quiet about these doubts for a while. Over and over I thought I was deeply wrong about my hesitance towards ALWAYS clean codebases or using the onion architecture for the simplest tasks. It's only because of Dan Abramov and his great talk (you can watch it here) that I finally decided to make them public. Dan also get's bonus points for his name and the fact that he throws in a new metaphor to the mix!

Oftentimes this is how I feel about over-structured codebases. You come there to do one thing, and because of the artificial separation imposed by the abstractions everything is still so interrelated that you have to change 10 files to add another prop to the transport.

There is this great book - just look at the title - If Hemingway Wrote JavaScript. There is a warning there not to fall prey to the thought of a rewrite lurking in the back of your head. Resist the temptation at all costs! Or

Do not go gentle into that rewrite,
Good code should factor well at close of day;
Rage, rage against the gnarliness and blight.

Though sage minds craft their logic late at night,
Because it reads like forked spaghetti, they
Do not go gentle into that rewrite.

Brave Model View exponents, burning bright;
Their layers become lasagna down the way;
Rage, rage against the gnarliness and blight.

Bold men who mostly think in black and white,
Then learn, at last, to think in shades of grey,
Do not go gentle into that rewrite.

Tired heads, near death, who work with failing sight
Step back and move beyond this tangled fray,
Rage, rage against the gnarliness and blight.

And you, dear reader, faithful acolyte,
Audaciously address this sad decay.
Do not go gentle into that good rewrite.
Rage, rage against the gnarliness and blight.

This is a must have for any book worm who somehow found their way into coding. The story of how it was written is the epitome of nerd creativity, just check out parts of it here! https://javascriptweblog.wordpress.com/2015/01/05/if-hemingway-wrote-javascript-explained/ - some of the code samples there are really weird, weird enough to shame Brian Leroux who gave us the original WTFJS - make sure to check out an extensive collection of JS weirdness here https://github.com/denysdovhan/wtfjs

The poem calls for a rereading of a classic from Joel - warning us of the perils of rewrites as well. There is this phenomenon of backwards rationalisation that I feel is somehow neglected here (read on it). In software we tend to believe the 2nd time we build something we will avoid the issues we've struggled with on the first take! Instead of giving "rational reasons" for why we've written our spaghetti in any given way we default to concocting a new battle plan and want to "repent" for our sins by crafting "the perfect solution".

I am always amazed by the creative use of tooling (and also using the tools totally not for what they were meant for!) and absolutely love the repo below depicting the historical changes to the US constitution. Who knew you could use git to teach history or track documents - I sense an influx of paralegals to Git soon!

What also kept me busy was a 1.61$ bill from AWS that I got for July. Much as I am dead sure I have no services running (and there is no hacker in the universe who would stop at 1.61$ had they gotten access to a service account that can provision anything) I chose to just nuke the hell out of my AWS account with this amazing tool! Use at your own discretion!

Tools are the bane of my existence. Especially the configurable ones. I've spent a couple hours trying to understand why my VSC wouldn't underline the errors properly on a TS code I was writing. After uninstalling VSC, nuking Node from my system, getting rid of NVM (I had an old install that didn't support updates anyway) it turned out I had strict mode disabled by default for the compiler settings (I think that's just the default for VSC, but I might be wrong) - if you ever run into similar issues - check the ts config on the ts playground that gave you the error you were after!

It made me think of a piece from Lea Verou - about the state of over tooling in the JS ecosystem. JS is not a beginner friendly language and hasn't been for quite some time. I share the sentiment that the innumerable wrappers, builders, and ways to write modules and compile stuff are driving even those of us who work with it daily crazy - I can only imagine what people who are not part of that madness regularly feel.

Happy Sunday!