Never stop learning

Have you ever learned programming paradigms outside of those that you where schooled to use or happened to use at your first job?

If we do not step away from the tools, practices and methods that we use, to learn others, how can we evaluate which tools are the best for the job at hand?

For example when I started to learn functional programming, coming from an object oriented background, I noticed that the more I kept digging the more valid critique I found to the paradigm I was used to and that there where ways to avoid much of the problems I had gotten used to.

An observation worth thinking about is reading about different paradigms of software development. When looking them up at Wikipedia (imperative, functional, logical, OO) only one of the articles have a “critique” section, and that is OO. That is the paradigm most of us likely is most familiar with.

There are several well known developers quoted on the problems of OO. But is it the object orientation as an idea or is it the usage in practice that are the focus of critique? That is certainly up for debate.

As an example, Joe Armstrong, the principal inventor of Erlang, expresses a situation I have been exposed to on multiple occasions:

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”

This little exercise of reading the critiques part, probably arouse some kind of emotions inside of you. Maybe you agree with the points made. Or maybe you think that the authors do not understand the paradigm as you do. Either way, the emotions that you discover show the value of investigating your assumptions.

What I have learned is that I have become a better developer by taking a step back from what I was good at and comfortable with and learn another paradigm.

So the overarching principle here is that whatever tools or design processes that you have chosen it is healthy to question them and learn others to be able to continuously improve. Our first principle here is to “never stop learning”.

Once we have accepted this principle, then it should be obvious to approach other peoples suggestions of doing things differently with curiosity and a humble openness instead of closed mind judgments.

It might also be obvious that this principle is valid in life in large not only in the domain of software development.