A few months ago I stumbled upon a way to do it. The idea is to copy how we use parenthesis and spaces in natural language.

So, instead of writing function(arg,arg2), I write function (arg, arg2). Instead of function() or function ( ), I write function ().

That is, I leave a space before each opening parenthesis, a space after each comma, and a space after each closing parenthesis. The same also goes for colons.

Also, when using square brackets, the same logic applies than with round or curly brackets. For example, instead of writing object[iterator] or object [ iterator ], I write object [iterator].

It doesn’t feel either cramped or longwinded, it’s just like reading text.

Just wanted to share it with you.

(if you’re a non-technical reader, whatever that means, there’s a brief explanation of some terms at the end, but you’ll get the gist anyway)

When your computer runs out of RAM, it starts using the hard disk as if it were RAM. The part of the disk that serves as this makeshift RAM is called the swap space.

Since hard disks are roughly an order of magnitude slower than RAM, whenever your computer starts swapping, it gets very slow, and you get very agitated. Usually, you start overloading your computer even more, because now you’re maximizing and minimizing windows and clicking everything just to see if your system is responsive or not.

Much in the same way, when you’re not focused on the task that’s right in front of you (either because you’re multitasking or you’re distracted by the internet), then you have too much on your plate, you run out of RAM, and so your brain starts swapping. This means that your brain becomes roughly an order of magnitude slower, and a part of you gets very agitated and starts worrying about deadlines and frantically putting your conscience in a blender.

In both cases, the solution is to close the tasks that you don’t need. So, when you find yourself doing many things at the same time or saying to yourself every 30 seconds “what was I going to do now?”, just say loudly to yourself: don’t swap!

For the non-technical readers

Order of magnitude is a way of saying “about ten times”. It is fancy, but I really like to use that term. Also, two orders of magnitude means “about a hundred times” (and not just twenty times), since it’s being implied that the magnitudes are multiplied, not added.

RAM = memory. Memory is volatile, so when you turn off your computer, everything in RAM gets deleted. You don’t store anything in memory – think of it as a highway where the computer places transient data.

Disk = space. Disk is not volatile (most of the time). This is where your data is stored – think of it as a garage.

RAM is more expensive than disk, and that’s why your computer has roughly two orders of magnitude (heh) less memory/RAM than space/disk.

Abel changed the face of mathematics, despite dying at 27. And here comes the thing – I give the mic to Wikipedia now:

When asked how he developed his mathematical abilities so rapidly, he replied “by studying the masters, not their pupils.”

By studying the masters, not their pupils.

The proposition is a bit like trying to climb a wall instead of a stair. Already I found straining to follow the gist of the textbooks of the subject I was interested – how could I deal with the masters?

Yet, maybe you don’t have to be Abel to do what Abel does.

Another thing that resonated deeply with me was how Newton studied a book by a French mathematician (I don’t remember which one): he started reading the book – when he found it too hard, he started over. That’s what he did until he understood the whole thing. So, he didn’t go and read something more basic, or tried to found someone who could explain it. He just stayed with the source until he groked it.

Again, Newton was a genius. But may be this kind of thing is what we need to truly learn, to truly get a shot at doing something of beauty and usefulness.

I’ve been reading the masters more and more. Usually it’s like reading a foreign language. You don’t understand almost anything and you feel like a baby.

But if you don’t mind too much feeling like a baby, and if you can create some space in your life where you aren’t forced to be an adult, then give the masters a try.

Below I put some links to works by masters of Computer Science – all the works below are available to download for free.

Shannon, 1948 – A Mathematical Theory of Communication

Shannon, 1949 – Communication Theory of Secrecy Systems

Turing, 1936 – On Computable Numbers, with an Application to the Entscheidungsproblem

McCarthy, 1960 – Recursive Functions of Symbolic Expressions and their Computation by Machine (Part I)

MIT, 1962 – Lisp 1.5 Programmer’s Manual

Ritchie, 1993 – The Development of the C Language

Thompson, 1984 – Reflections on Trusting Trust

Cerf et Dalal et Sunshine, 1974 – Specification of the Internet Transmission Control Program

Wu, 1997 – The Secure Remote Password Protocol

Strachey, 1967 – Fundamental Concepts in Programming Languages

Knuth, 1983 – Literate Programming

There are two reasons for choosing Redis almost always:

1) Redis data structures are far more intuitive and versatile means of storing data than relational databases.

To me, relational databases are a very limiting and antinatural way of structuring data. I’ve always felt that mapping the concepts of your program (whatever your style of programming, but especially if it is object-oriented or functional) to relational databases is both painful and frustrating. This is for two reasons:

- Relational databases have no concept of hierarchy – that is, no nesting. What you have is a set of arrays, instead of having a tree. There’s nothing bigger than a table, and nothing smaller than a field.

- The links between nodes are of a weak and limited type: foreign keys. So you have to bend over backwards to implement some sort of network model for your data.

(BTW, this is why ORM is a rabbit hole of the kind that nothing of real beauty can come from. No matter how good the solution is, it’s always a variant of fitting a square peg in a round hole).

Redis, although it isn’t a true tree or a graph, is far closer to either of them, because it has a rich set of data structures which are very similar to those of today’s high level programming languages. From what I’ve looked around, no other NoSQL tool offers a comparable set of data structures.

This means you’ll do far less violence to the concepts of your program when you persist its data with Redis. This makes for faster development and will considerably improve the quality of your code. More importantly, your code will be more beautiful.

2) Redis runs in RAM

Although it persists to disk, Redis data is read from and written to RAM. Since RAM is about an order of magnitude faster than a disk, this translates to queries and write operations that are roughly an order of magnitude faster. Sure, many caveats and exceptions apply, but that’s the essence of Redis’ blazing performance.

So, to sum up:

Redis will make your application 1) easier and more enjoyable to program, because it maps better to the concepts of your program; and 2) faster.

Yet…

You should not use Redis if your dataset is large (more than 2gb).

This is because it is non-trivial (though possible) to create a cluster of Redis instances, each of them holding up to 2gb (or 4, or 8). Also, if your application stores larges volumes of data, then probably Redis will never be your option because of economics (can you afford terabytes of RAM?). In that case, you should give a deep, meaningful look to Amazon S3.

(Did you notice I’m implying you should never use MySQL?)

These counterarguments to using Redis are invalid:

MySQL is the default and Redis is not production-ready: there’s much to argue against using the default technological choice for anything – and unless your clients insist of vanilla-grade software, you should seek something better than the median tool. And Redis is very, very production ready. Just look around and see who’s using it.

- Redis is not truly persistent because it runs in RAM: both of Redis’ persistence operations (journal and snapshotting) are good enough. For me, the ideal would be to have a reverse journal, where you store the negative changes (what you should apply to go back instead of starting from 0 and going forwards) – if you combine this with snapshotting, you’d have something that’s virtually lossless and fast. But going back to the main point, Redis persistence to disk is secure and reasonably fast.

Further arguments, counterarguments and objections

I’ll be glad to hear them: write me at fpereiro@gmail.com

I’m saying nothing new here, but I’ve found myself making this point over and over when talking with startup founders who have non-technical backgrounds. So I’ll just go ahead and try to spell it out, in the bluntest way possible:

For 99% of web startups, their main challenge is to deliver excellent technology. Delivering excellent technology is not enough to be succesful, but it’s the single greatest predictor of a startup’s success. Everything else is less important.

If you’re a startup founder and you have no technical knowledge, you may be frustrated by the number and weight of the technological decisions you have to take. You may think that this is just during the initial phase of your company and then you’ll just focus on marketing, sales and the IPO. But in fact, technological decisions will be the bread and butter of your reign as CEO. You’ll have to make decisions about sales, hiring and finance as well, but they will be less important than your technological decisions. (Note: decisions about hiring desginers & programmers are technical decisions).

So, if you’re a web startup founder with no technical background, you can do two things:

- Jump into the water and start learning about technology.

- Find a technical cofounder.

Technological consultants may be useful to help you take technical decisions (heh), but you need to learn and care about technology – or team up with someone who does. So let’s sum this up in an equally blunt corollary:

 If you’re doing a web startup, there must be at least someone with equity who knows and cares about technology. You can either become that person or find someone else who will be that person. If you haven’t done this already, it is the single most important action you can take right now.

This knowledge and love for technology translate to a great product in two ways:

- You work with the proper tools, so your product is far cheaper to make, faster to launch, easier to maintain and grow, and more resilent to the future (because, for example, it is not based on a technological dead-end).

- You hire the right designers & programmers. This point is probably more important than the previous one, because if you hire great people, they will help you choose the right tools and approaches.

There are a few exceptions:

- If you’re copying an existing product and launching it in a different niche or regional market (being first is probably more important).

- A business strategy that relies on privileged access to a restricted channel of distribution.

- Selling software to big companies or government institutions.

Here’s my final (and equally blunt) conclusion:

Unless you already feel an inclination towards technology, go find a technical cofounder. Now.

Here’s a brief outline of three ideas of Derek that I find refreshing and useful, particularly if you’re starting a web startup.

Ideas are a multiple of execution

It doesn’t matter how much you believe in the world-changing prospects of your startup idea: if you don’t act upon it, it isn’t worth anything. Of course, ideas are essential and without new ideas, nothing new will arise. But also as important, nothing will arise from an idea that’s not executed.

The great idea is wildly overrated, and everyone who has put startup ideas into practice will tell you exactly this. But Derek says it better than anyone.

I’ve fallen prey to this trap many times. What I found works for me is to get very excited about an idea, and at the same time work on launching an initial version of its execution. Which leads me to…

That’s version ∞. First launch version 0.1.

Take your current feature list for your new startup. Slash it by 90%. Choose only one or two points, reduce them to their minimal expression. And launch your application!

If you wait to develop your entire list of specs before launching, you risk two things: a) running out of money before launching something useful; b) focusing on the wrong features or executing them badly because of lack of user feedback.

I must confess that I’m preaching here what I don’t practice. I have an open source project which is half done (and which I routinely use for programming) which I haven’t launched yet. So do as I say, not as I do, and launch the damn thing already.

Business is not necessarily about money

Making a business can be about much more than just making money. You can start a business to create something useful, to bring about change, to free yourself from the office, to make people happy… Of course, a business must make money, but that is not necessarily the variable you should maximize.

As long as your business is profitable, you may well choose to develop other things in your business apart from profitability. So money becomes the means of your startup, rather than the end.

Although this idea is not for everyone, I find it highly inspiring.