Because a little learning is a dangerous thing.

When I started my software engineering journey (via Lambda School, in 2019), my instructor used to introduce hard and fast concepts by saying ‘you’re going to learn enough to be dangerous!’

I didn’t quite understand what that meant - even though I found it hilarious - but now I’m pretty sure that ‘knowing enough to be dangerous’ means knowing just enough to be a useful cog in a machine, without the rigor to extend and adapt to unexpected, unfamiliar situations. This isn’t necessarily a bad thing, mind; software engineering is the career of a lifetime (in that it’s going to take an entire lifetime, plus more, to even understand half of what you need to know).

‘Knowing enough to be dangerous’, then, to me, means knowing enough to think you know, which can make you undeservedly arrogant and less inclined to brush up and really hone your skills around things you merely have an introductory grasp of.

I’m still a relatively new software engineer (I have only a few months’ worth of work experience), and I keep tripping over my own feet. Neil Kakkar wrote once about how software engineers should keep a ‘slack’ (a list of things that surprise/confuse them in the course of work), with plans to revisit and beef up their knowledge whenever they have downtime.

I loved that idea so much that I’ve decided to create this newsletter around it. Craft Overflow is going to be a collection of essays, notes and experiments around my work and interests in web development.

I will write primarily for my tribe - which means it’ll be beginner-friendly to a fault - and will focus on both the front-end and backend, as well as devOps. It may be sometimes indulgent, over-explained and long-winded, but that’s mostly because I sometimes need things over-explained to me in an indulgent manner.

This newsletter will be structured insofar as my slack itself is structured (which means it really won’t be structured - if I get stuck on the entire philosophy of object-oriented programming, I may spend an inordinate amount of writing on OOP with no discernible pay-off).

Sometimes - a lot of the time - I’ll ask readers what they struggle with and try to provide a way to think about those challenges, because I think there’s value in getting better at explaining things.

All in all, this is designed to be an mutually-edifying project: the more I write, the better I’ll get at my job, and the better you will, as well.

Now let’s begin.