Where we do this yet again

You'll want to ignore this post really. I'm keeping it up as a reminder to myself to not get too complex :). This was a post written to kind of reintroduce a concept I had called After two attempts at starting it up, I couldn't explain it to anyone including myself and decided to shut it down permanently. I did a quick post here and will probably do a fuller post later.

The past

There will be no link to the original post where I started up this site. Just this post talking of how I'll be getting back to work on a concept that never quite achieved it's purpose.

When I first started paste this code, I imagined a site where I shared tutorials of how to use software in production context. The premise was simple. That most tutorials either show hello world type tutorials or talk of doing specific tasks in an isolated context. Questions like secure settings, pros and cons of speeds in enabling certain feature flags would be left unanswered.

While a common lesson out there is to just do something without overthinking it. Want to write a book? Just start. Want to start a company? Go do it. Want to start a site that talks about software usage in a production context? Just do it.

The only wrinkle was that just writing about software wasn't going to cut it in this case. I wanted things to be useful. I wanted people to easily be able to follow a series of work. I wanted to work on actual production related projects at work and discuss it almost as a log of work done. A single blog doesn't lend itself well to this structure on its own. Besides, I thought. Do I really have time to try out software out there and use it in production related contexts and write about it consistently? Probably not.

The idea moved to the back-burner and eventually to the icebox.

The one you can't let go

I've read somewhere that if you have a bunch of ideas and can't decide which one you want to pursue, just stop thinking about all of them. You'll probably have one idea your mind just can't let go of. If you do, that's the idea you want to come back to. Paste this code, is that.

What's the reboot all about though?

There are a couple of things I've wanted to achieve with this idea I've had for a while now. Mind you, many of the statements below are very broad and it'll be quite easy to point to a number of examples that negate my statements. It's why I've been careful to use words like "most", and "main types of", etc.

The first thing is that I've noticed that there are two main types of structured technical education content out there.

The first falls into the category of hello world, non production context based tutorials. These are great but many times they'll skim past important pieces of information one only knows by learning at a higher level. Pitfalls, security, and clever optimizations that go beyond the scope of a single tool. They apply everywhere.

A sub category of the above are companies writing blog posts on how they moved to a new technology. Again these are light on nitty gritties of what moving to a new technology entails. They are even lighter on what details of what led them to choose the new technologies. The talking points are there. People with some interest in microservices are aware for example of reasons to move to microservices. But each company has a unique context under which microservices makes sense. Generally a four person shop may not need microservices for their MVP. That might not be true if you are building a tool for observability that needs to handle massive volumes of data to be analysed later. Either way, the point is that this category is useful but almost always, it's only at a shallow level.

The next major category of technical content that I see out there is deep deep almost academic level stuff. These ones usually deal with challenging questions that involve machine learning and tensor flow and what have you. Or it involves deep compiler level problems. Or deep dives into algorithms and their implementations. This is really valuable content, although it comes with the same caveat. It's generally not related to building ye standard software package or how you might learn software unless you are really deep into mastering that particular knowledge area.

Which brings me to the category I want to sit in, which should be obvious from the writing above.

Whatever I talk about, I'd like to discuss it within a context that would eventually be useful in building actualy software products. Even if it's solving puzzles on Euler, I'd love to try and figure out how I can apply certain production principles like TDD effectively for them. And the keyword is right there.


I want to make content that's 40% timely and 60% evergreen. And by that, I mean I want to write things from the higher/abstract level of principles. Not just an "oh I'm doing this with React JS", but instead:

"I'm doing this with React JS in this way but I'm concious of the fact that this would be good only until my software reaches X level of complexity, after which I'd need to abstract things away".

Or, "I'm working my way through Advent of Code, and here's how I'm testing the code to make things work, and this is what I would do (irrespective of language) when I run into a problem".

Or, "I'm designing this site, and I'm using Bootstrap to do it for now because I don't have time to learn the grid system and build my own nice CSS sheets. But the plan will be to either replace it to use lightweight browser native features, or recompile Bootstrap to provide just the grid and spacing modules because that's all I need for this"

Principle driven education.

What comes next?

At the time that I'm writing this, I'm busy hacking away on a really basic HTML static front end for the site that will link to my "featured" projects, active projects, and completed/abandoned projects (mostly abandoned). And for each project there'll be a log of content that one can follow along with and read. An example of what that might look like:

The front page

The front page WIP

A project log page

A project log page WIP

Not that any of this matters

None of the words above matter to be honest. They are my way of feeling good that I'm getting something done. What matters is what I actually get out there so it's time to jump off to go hack :).

Share this