Update: The Book Is Available Now
I've setup a pre-release for the book which you can buy now. You'll receive all updates as they become available!
I was in the middle of a conversation with a friend the other week and we started debating some data access nonsense. This friend (whom shall remain anonymous) asked me a simple question:
So you decided to go O(N^2) instead of just O(N+1) then?
I sort of laughed nervously, thinking that the definition would come. I swear it hurts to write this right now but... it's really what happened.
Yes, I'm your nightmare. The truth is I've known Big-O notation for quite some time, but the fact that I couldn't just call it up right then and there was ... quite frustrating.
I don't have a CS degree and the same can be said for a lot of my friends who write blog posts and get up in front of rooms of people to give talks on computer science stuff.
We could sit here all day and debate whether I'm truly qualified to do such things - but rather than do that I'll just throw in the towel and say you're right: I really should know these things.
My problem is that I a) don't have enought time and money to go back to school and b) I think I can dig in and figure a lot of stuff out using resources online (lectures, tutorials, etc) and books readily available for my Kindle/iPad.
But that's no excuse.
I don't know if this is nice of me, or "cool to do" in the online sense, but it's the truth so... whatever.
For me, spreading ignorance (or bad information due to ignorance) is an issue. If you are gonna talk about subject X, make sure you know subject X, well enough to talk about it. At least, make sure that you are not making gross errors about subject X. Is it really too much to ask?
I've been working as a professional programmer for years, and I've encountered many without basic scientific background. And that's FINE! Not everyone needs it, or wants it. But then these people read a blog post, and it sounds right, so they believe it. After all, they lack the knowledge to figure out which parts are true and which are don't. That's why they are reading the blog! And they learn stuff that is WRONG. And then they are going to implement this stuff, and argue about it, and generally BELIEVE that anything having to do with CS is either unpractical or is easily enough learned in 30 minutes of reading.
And then I have to work with these people, and manage them! They have no grasp of how much they simply don't KNOW. And at some point, their knowledge simply ain't gonna cut it. And they are going to argue with me, or write me off as a user of fancy computer science jargon. I mean, it's just register allocation, right? How hard could it be? It's only BSP tree optimization, let's just check all the options!
So I am trying to combat this ignorance for practical, selfish reasons. Programmers need to understand the problems they work on. They need to understand when they are out of their depths, and its time to hit the books, or call someone who knows. Or reject that project, or bump up the cost and time estimate. At least map out the areas of your understanding, so you'll know when you're on treacherous ground.
The other reason is a matter of principle. Ignorance is pretty bad, and I reject mediocrity for its own sake.
In less fancy terms, if you are writing technical posts, get the technical details RIGHT!
M1116: you're absolutely right. The main issue I have is that I don't know what I don't know. I set out to change that 6 months ago, and it's what I hope to share with you in a few months from now.
The Imposter's Handbook
I'm 80% of the way through this effort, and it's quite literally changing my life. Every single chapter I write has completely altered my outlook on things and, most importantly: made me see all too clearly just what I do not know.
Here's a list of the chapters I have so far (in no particular order):
- Computational Theory: Finite State, Pushdown, and Turing Machines as well as Geek Trading cards and P/NP "stuff"
- Algorithms: bubble sort, heap sort, quick and merge sort, selection sort and binary search.
- Big-O Notation: what each common asymptotic complexity means and why you should care.
- Linux Essentials: how to get around and do basic things
- Shell Scripting: How you can accomplish various tasks using the command line, including tossing Grunt/Gulp and using Make
- Software Design: SOLID, Gang of Four patterns, etc
- Programming Language Essentials: Compilers, memory usage, garbage collection, runtimes, TIOBE analysis, a quick overview of what's popular vs. what pays
- Data Structures: Arrays, linked lists, heaps, hash tables and binary search trees... what they are and why you should care
- Encryption: ciphers, encryption algorithms and basic hashing including the security/insecurity of each approach
I might add some things or prune back but as I mention: I'm 80% there.
Whatever Why Am I Telling You?
I thought if you had any ideas or requests you could let me know (do it on Twitter: http://twitter.com/robconery). These are things that I need to know more about, and writing/presenting things like this forces me to research them.
Which I think is critical: I don't take this lightly. One sure fire way that I'll learn this stuff is to have my ass on the line - and it really, really is with this effort.
Is This Supposed To Replace a Degree?
HELL. NO. My goal with this book is to show non-CS grads just how much they don't know. As I mention: the very act of writing this book has completely 100% no shit changed everything about how I approach programming. Absolutely everything.
I hope to fire up the non-CS grads out ther to go investigate subjects that interest them. To seek out the easily-accessible, free online courses from Harvard, Stanford, and other high-caliber schools. All links will be included in the book.
You Really Should Have a Chapter On X
Yeah, I probably should. Do me a favor and let me know if you have a request. If I have time, I'll add it in there.
Hopefully I'll have this thing ready to go in a month or so. It's taking me forever and it's mostly research - which is too damn fun.