Joonas Pajunen

you know, stuff

Page 6


the abundance of javascript libraries

There’s this joke about a new javascript library manifesting every two hours. This is a kind of a follow-up, extension or explanation to a presentation I not-so-successfully delivered on HelsinkiJS this week.

Javascript by itself is a somewhat barebones of a language, with the exception of the coming ES 6/7 features. There’s the DOM, and the infamous 2 week or so creation time. There’s front-end and backend. There are build tools and transpilers. Visualisation, graphics, sound, game engines. Even though the purposes for these are many and diverse, the amount of javascript spawning from the internets is still plain ridiculous.

from libraries to frameworks

The smaller, “helper” libraries, like underscore and jQuery, tend to have better chances of staying relevant. They’re usable both in larger and smaller projects. There are quite a many of these smaller packages, which is not...

Continue reading →


the lindy effect

I’m intrigued by this notion of “reverse ageing”. Think about people. The older they get, the sooner they are expected to die. If you think about ideas and technologies, the expectation is that of the opposite. Because of survivorship bias, the short-lived and dead technologies are rarely remembered. That might render this concept somewhat unintuitive at first.

The Internet allows the spread of ideas, opinions, technologies, programming languages, libraries, opinionated frameworks and other non-perishable things. Much of this is just noise, and quite often, it is difficult to find the actual signal. There are fads, and there are some clear trends.

One example for an “old” library in this context might be jQuery, as it has been extensively used within the whole profession. In fact, think up the most boring job ad, and remove from it the newest, hip and cool techs. You are likely to...

Continue reading →


concentration and music

I take stretches where I shut down instant messaging software, quiet my phone and don’t answer any unknown numbers. I don’t check my email and to some extent, try to ignore everyone around me. The ambient babble and occasional shrieks in the office (especially on Fridays) break concentration and at worst interrupt any flow I might have achieved. To mitigate that, I tend to listen to a lot of music while working. Whilst not the most important thing in life, I seek to achieve high levels of productivity.

Reaching flow at work generally requires a clear goal or purpose, feedback, and a balance of challenge and achievability. I suspect developers tend to be more of the autotelic type than the population in general. Programming is abstract and requires interest in theoretic stuff right from the get go. Quite often, the programmer is intrinsically motivated beyond the business value or...

Continue reading →


programming, slow

Software development is generally considered a thinking person’s activity. Word thinking usually implies deliberate pondering and careful reasoning. However, there’s a clear-cut difference between thinking fast and slow (coined Systems 1 & 2, respectively). Thoughts in the first happen automatically, and in the second, more purposefully.

Keeping the systems completely separate would require some level of psychopathy. Too much of analytical, emotionless and autistic thinking can suffer from a similar problem to “paradox of choice”. There, no decision is achieved because of the lack of impulse or intuition. Without any intuition or plain risk taking, one can succumb to a circlejerk of useless comparison and speculation.

Programming is largely about managing complexity and being aware of the so called known unknowns. This means that in addition to the complexity of the software’s known...

Continue reading →


programming, fast

By programming fast here I speak about the effortless act of producing working or semi-working code. This happens without having to stop too much to ponder and plan how to implement something. On a more larger, architectural scale, this manifests as a direct understanding on how to structure software. For example, knowing what design pattern to use where, what things to decouple, and eventually what to just declare good enough.

This is something that is usually developed through years of practice and experience. The experience is generally gathered from simply programming, but perhaps also by other means of general logical thinking. It is a way of working where something just feels right, where one can rely on intuition and common sense.

trustworthiness of intuition

Intuition can more likely be trusted when the environment or context is regular enough. For intuitive predictions to be...

Continue reading →