People Are Really Just Json Files

People Are Really Just Json Files

The pandemic has taught us all a thing or two about life — such as that people are really just JSON files wrapped in a nice frontend. Slightly confusing to look at, potentially infinite layers of hidden depth — and if they are missing a bracket on either end of the file they quickly fall apart and become unreadable.

It is such profound wisdom that I acquired during the past year-that-felt-like-a-decade. Plenty of nuggets that I’m about to share with you, whether you want it or not.

Nobody bothered to document the code

And if they did, it’s grossly out of date.

Sometimes you look at a tangled mess of spaghetti code and can’t help but find it a little cute, from the messy hair to the internal issues that make you wonder how the whole system is even still running.

Any new developer will likely be thrown for loops and jump through hoops, slap their foreheads and be thrown into minor identity crisis as they try to understand the system infrastructure.

Where does it start, and for the love of god, where does it end? Who wrote this, how did they do it, how can a function called CreateSmile have the return type FitsOfRage?

It’s all reverse engineering with a steep learning curve — and answers hidden on the fifth page of Google Search results.

Many people use internal version pinning and can no longer update without crashing

People at certain points make the mistake of pinning single components to a specific version in order to avoid a lengthy, laborious update process. Then next thing you know they can’t update the Life solution to version 2.0 because it relies on Car v1.9 and Maturity 7.1 in order for the other components to work — and both are stuck at a pre-alpha build from several years ago.

Trying to update car produces the weird nullRef exception in the class BankAccount, and if they force the update it usually leads to race conditions and ends in a ditch or hitting a brick wall.

Trying to update House is nearly impossible because all functions are now costly and impede performance in other areas to the point of making the whole system sluggish and unmaintainable. The only way to fix this is to replace all dependencies with the RentalApartment package which can be updated a bit better with more manageable risks involved.

And then, slowly, developers start jumping ship for other tech stacks that are more modern, easier to work with, more fun to query. It becomes even costlier to bring in new staff that puts up with the old, never-updated systems and they are usually not around for long either.

Frequent monitoring is crucial to keep the systems running

Sometimes a system can be outwardly functioning, but accumulate silent errors under the hood that nobody notices.

It is important to monitor the people in your life, take time occasionally to run some unit and integration tests and maybe a few database selects to ensure the result set still comes out as expected.

Leave a system alone for a month and it may just still work, but leave it alone for a quarter and you’ll likely find a completely different one with plenty of avoidable bugs and possibly severe warnings that require long nights of patches and hotfixes.

Some people suffer from dependency injection more than they reap the benefits

Nobody can really exist in a void, we all rely on other people. The only ones who don’t are microservices that are only good for one thing that may or may not be needed.

However, it is easy to rely on external dependencies and build parts of your system based on components that you can not control . And now suddenly, you see the world around you move on while you are still stuck with a stagnant system that feels increasingly tangled and intertwined and works its fingers into tiny little cracks until they widen into gushing leaks.

Related  Programming Is Like Sex

Sometimes fixing a single bug would require a full rewrite of the system

Architectural choices are often made early on in the development process, often times by people who have long moved on and can’t even explain to you why they did what they did.

Maybe their parents meant well when they installed certain components, maybe others are the result of last minute change requests the original developers did not think through. Maybe it felt like a smart choice at the time to exclude the Fitness component from the project scope, maybe healthy world views and people skills were not important to the overall project success.

And maybe it’s the result of a developer who knew they were about to get fired and willingly installed malicious code in order to fuck with anyone coming after them.

What they all have in common is that they are not trivial to fix with how deeply rooted they are. You might even find yourself fighting windmills with the board members who do not see any issues — after all, that’s how the system always worked for as long as they’ve been at the company.

The log files are usually cryptic and stack traces don’t always point to the source

Sometimes it helps to just wait a day or two before trying to debug an error, just in case it was merely a temporary timeout or user error.

The system output is often times confusing as it spits out error codes rather than messages and often obscures the actual source.

It takes years before you understand a system enough to immediately connect the symptoms to the origin without a tedious debugging process.

Log outputs are often cut off before the actual source and leave room for interpretation. Different developers have already tried different solutions, some of them even seeming to work for a while — even if they make absolutely no sense. Installing chocolate seemed to fix the bug for a fortnight, but then the error returned and the same hotfix no longer worked.

A different developer was called in and found surprising success after hours of talking things through and putting up a device-listener on port 1137 that just accepts the random system outputs and returns status code 200 without even doing anything real.

Nobody understands the true cause of the error yet, but since all systems appear to be running fine now the board sees no issues to move on with the next project. Refer to Section 5 of this same guide.

Takeaway: People are fascinating and challenging

Many companies have produced their own versions of the Human from a shared framework — even though that framework itself went through several iterations in the past few generations.

All of those companies found their own unique solution to common problems, often times found truly fascinating solutions to unique requirements and change requests.

After a steep learning curve you will find that interfacing with these systems is almost an art form and most certainly fascinating. It’s easy to stop looking at them as work and start treating them as a hobby, a reason to get yourself off the couch and on the phone, into a different location. Sometimes you can even find several people in one room, at which point the results become truly unpredictable and often leave you exhausted, yet wanting to explore these hidden depths even further.



No Comments Yet!

You can be first to comment this post!

Post Reply