Let’s say you need to plow a large field, and for the task, you are given a machine. How would you plan your work to be as effective as possible? I assume the first questions you want to ask is — What is this machine I have? How does it work? What can it do? I think these are great questions, ones that we should ask ourselves whenever we have a project to do, for which we are going to use the machine we call our brains.
This post will try to use cognitive science insights to create a methodology…
This happened to you: you’re having a nice day, minding your own business, then an ad (or person) pops up saying: “Improve your productivity by 700% with this one simple trick! Won’t you try it? I mean, come on”
It can be a tool, a gadget, a method or an idea. I refer to all those things that are designed to save you time as “productivity boosters”, and they all seem to follow this basic logic:
Time something takes you now - Time it would take with the booster = New time you magically created = Profit
the single worst strategic mistake that any software company can make
To be fair, the post talked about rewriting the entire system, giving the Netscape 6.0 rewrite as an example, but I strive to be cautious in cold water, so I thought, am I making a mistake?
I was alarmed to read that:
there is absolutely no reason to believe that you…
Austrian philosopher Ludwig Wittgenstein, commonly considered one of the greatest philosophers of the 20th century, was very skeptic of philosophy in general. He thought that many philosophical questions were really just misunderstandings, by the philosophers, of the way language works.
Philosophers, for example Socrates, would have the assumption that words have definitive, non changing meanings, and that it’s the role of the philosopher to find this meaning. Wittgenstein would say that this assumption is like assuming that when children play with a ball, at every single point in time there are definitive rules to the game they’re playing.
In my last post I talked about anti-fragility, which is a way to design software systems that can successfully cope with the complexities of the outside world. This time I want to talk about the internal complexity of our systems, and how to avoid it.
To start off, how do we define complexity? In a classic talk titled “simple made easy”, Rich Hickey defines the difference between things that are easy and things that are simple. Something is easy when wee know exactly how to do it, it’s “within our reach” and we have the tools for it. …
All too often we find ourselves deploying software that works flawlessly on our the drawing board, only to see it underperform or fail in production. Sometimes it happens quite fast, other times it takes a while.
The problem is, shipping a complete system to production after only testing it locally is a little bit like trying to go surfing after you’ve thoroughly and absolutely learned how to surf — in a classroom.
This is because production environment are complex. There’s a lot of unknowns: your business needs can change. Customer behavior can surprise you. Third party services can change their…
A name can say a lot about something. For example, CJS and ESM.
To read “CJS”, you read every letter, understand its reference, and go on. C(ommon)J(ava)S(cript).
“ESM” is a bit different. When I first looked it up I found that “ESM = ES module”. Gee, thanks. What’s ES? well apparently it’s a short for ECMAScript, which is some prototype language JS is based on. I still wanted to understand the acronym so I looked into why ECMAScript is called this way, turns out it was created by ECMA — European Computer Manufacturers Association. So finally, ESM = European Script…
This is the actual story of the Buddha (as told to programmers), and how over 2500 years ago he invented functional programming.
Well, that’s clearly false. The Buddha didn’t know the first thing about computers and programming, he lived way before they were invented. But still, he invented functional programming… sort of.
To put it more accurately, the following story is an analogy to the original story of Buddhism. Better, it’s an analogy that uses software engineering concepts and terminology (hurray!).
I argue that this kind of analogy makes sense. If you think of your brain as a computer (how…