Hello World - Rebooting this Blog

Hi there, thanks for visiting. I love reading technical blogs and owe it to them for most of my working knowledge. And of course, Stackoverflow :)

I've always wanted to contribute back to the community that has given me so much. This blog is my baby step to put this into action. At least with this post, it has reached production unlike my other side projects.

There are already so many great articles and blogs on the interwebs. What more can I add? Should I  focus this publication on a single technical passion like GraphQL? Then it dawned on me.

There are a lot of great articles on specific technical topics, however, the most enjoyable posts are the ones with a T shaped view (wide breadth on the issue, deep dive into the issue).

Why? 💣There is no such thing as a purely technical problem in the real world. Yet in writing we try to distill our daily career challenges into a set of technical solutions.

A tale of two teams

Here's a hypothetical example. A company has a separate Database and Applications Development team. Most sides has a slight distrust of the other messing in their domain. Hey man, separation of concerns right?

The company is growing, the database is starting to backed up because it is harder to scale the DB horizontally. Without ability to do investigation across the whole stack for both teams, the DB team ends up doing the grueling task of increasing DB throughput. The Applications team has no visibility into production data and DB stats, so they introduced front end caching to reduce the number of duplicate calls.

The Real problem? An abstraction meant to prevent developers from writing SQL was introducing N+1s due to an unexpected difference in the production DB.

In this extreme example, we might end up a blog post on DB scaling and one on frontend caching techniques. Well, I hope to contribute the tale of how we managed to diagnose the root cause plus the technical and collaboration measures to prevent it from happening again.

It pains me to see teams not being able to take the best solution sometimes because of organization pigeon holes. It is heart wrenching to see that happen in smaller companies where the cost of communication is relatively low.

Henceforth, I like to dedicate this blog to writing on the vague notion of end to end problem solving ™️ . I'd like to chip in my lot to produce "medium" dives (e.g. A practical guide to CDNs for We) for specific audiences too. Some additional principles I like to abide by:

• Always respecting the reader investing time to read an article. Tell the reader upfront what's in the article.
• Not assuming that the reader knows too much (e.g. obviously is not a good word to use) but also respecting the reader's intelligence and curiosity in figuring things out.
• Don't assume. Gender neutrality in examples, don't presume the behaviors of certain group, especially having snark towards them.
• Have a target audience for every article (e.g. a frontend dev who only writes JS) but not presuming that frontend devs are not interested in learning about backend topics. No one has time to learn everything, I'll scope to the best of my ability.
• Write iteratively. I apologize for the typos, sentence structure issues in advance here. Writing is a muscle and I'm trying to improve mine. I'll take your feedback iteratively improve existing and new articles.
• Inject some humor and meme references. Sorry I can't help but make bad jokes :)

We can all strive to better ourselves to make life and vocation more enjoyable. I hope you find something useful here :)