What They Don't Teach You In Computer Science
With nearly two decades of experience, research and continued education in Computer Science, Mathematics and Engineering, I have taken away a few axioms.
80% of writing code is thought
We're not just staring at the screen. We're thinking. Imagine putting together a jigsaw puzzle completely in your head. Now imagine you have to paint the full picture, cut each jigsaw piece, then carefully put them all back together. You haven't even written a line of code yet and you still may have gotten it all wrong.
90% of thought is simplification
Short Hand Guide To Identifying Crappy Code:
- Complexity is a trap. If I have to make more than a few function calls to get what I want, its too complicated
- If the class is longer than a few function calls and a few properties its too big
- If it requires longer than a few minutes to understand what its doing and how it fits together, It's too abstract
- If one class knows too much about another class, its too coupled
- If any piece of code makes more than a few assumptions about its input, its doing too much
- If the language (api/interface) between two objects is inconsistent, the code is not well thought out
- If there is code that is never used, it is over designed
- If it can be simplified, simplify it.
20% of writing code is actually typing code into your editor
This looks like a flurry of activity on the keyboard and ends in a short lived triumph. You're not nearly done yet and you realize that there is a very good chance you'll need to throw this all away should a simpler, more coherent design presents itself (see rules of simplification).
Let Your Customers Deisgn Your Software
Even the best laid plans of mice and men can't forsee the off-the-wall ways your end consumer decides to use your product.
I am never surprised at the myriads of creative ways consuemers try to tweak, fit and change your product to suit their needs.
This inevitably leads to a considerable re-thinking of what you built. This doesn't mean you'll need to change anything, but it should very strongly encourage your future product roadmap.
Make the least amount of assumptions as possible and build the bare bones product. I call this MVP, or minimum viable product. Let your early adopters guide what features you add. This is a fundamental step towards avoiding bloat, bells and whistles, saving time and delivering value to your consumers. This is also called the maturation of your product. We typically do this through a limited beta.
