I’ve just finished “Leadership and self-deception”, and it was eye-opening. It’s a book about management and leadership, but more importantly, about managing relationships with people. I’ll go over some of the things I found most revealing, and hopefully without confusing anyone with too much of the book specific concepts and ideas.

Personally, I expect the message of the book to induce a change in how I behave and think about others.

self-betrayal

The shit starts to roll downhill whenever people “betray themselves”. This would be a moment when they perceive certain actions as being favourable and “right”, but for any reason, act the opposite or not at all. From that moment on, people begin to think and generate reasons why they didn’t really need to act good on that particular instinct, and perhaps even why it was better this way. The situations of self-betrayal are many, ranging...

I’ve recently been playing Grim Fandango, a remastered release of a classic PC game from the 90’s. I find myself confused how I first have no recollection about what’s going to happen next, until a new screen loads. Broken parts of stories and and images instantly flood my mind from over 15 years ago.

What’s troubling, and interesting, is that some of those memories are blatantly false and inaccurate.

false memories

This particular game consists mainly of dialogue, problems and solutions. The more difficult (and sometimes ridiculous) solutions are usually achieved by interacting with the environment and different items. I remember things totally wrong, and actually remember seeing wrong items interacting in incorrect places and events happening in different order.

I’m not sure if I’m making these incorrect memories up as I go. Maybe I imagined these possible solutions 15 years ago...

I pondered about the abundance of Javascript libraries, about it being both good and bad. While I still think it’s both, I tend to think the negative aspects emerge from our established ways of viewing prowess in technology.

What I see as a problem is this notion that one should be proficient at some certain library or framework. Instead, I think we should be good developers in general, and be able to learn and adopt new stuff rather quickly. We should be open minded in trying out new stuff without fearing too much about the time used (and potentially wasted) learning.

expertise

Investing in one specific library might be daunting. A well versed generalist can learn (almost) anything in a relatively short amount of time. All of us developers know this. What’s disturbing are those old-fashioned requirements for job or project positions, that list a bunch of technologies an applicant...

I attended the first ever Tomorrow conference a few days ago. The mastermind behind the event is Lauri, and for a first time organiser of an event of that scale, he did an excellent job. Everything went smooth, and no problems could be detected whatsoever. In fact, the staff themselves were perplexed how well everything worked out.

The event was spliced into 4 sections, each having a somewhat vague sub-theme, of which the speakers followed with varying accuracy. Each of the sections began with a musical performance by Anni. Coupled with the proper sound systems of Musiikkitalo, they were a great mental reset before the talks.

As the name implies, Tomorrow was about things in the future. The talks were, in a sense, all over the place. Most of them dealt with how we influence what happens in the future, with our actions and behaviour. I won’t necessarily go into per-speaker details, but...

Data science, big data, data mining, MapReduce, buzzword. Data is being generated in an increasing pace as the amount of it is exponentially growing. Problems arise when handling such large amounts of information and interpreting what it all means. Drawing misleading conclusions from that data can happen by accident or in purpose.

flood

Data is being generated by both people and machines. As the adoption of some technology reaches saturation, new technologies and new types of information gathering become available. Meanwhile, as the saturation is reached, the accuracy of the data keeps growing well past the adoption. Machines collect data about people, each other, and generate more data based on the previously collected. It is all stored somewhere, where no one is likely to ever review it. Luckily, the costs of storing data seems to decline at a compatible rate. The costs of managing...

What could antifragile software be like? Or rather, what kind of a team and with what kind of a development process could produce software in an antifragile fashion?

This is one originally appeared in Finnish at Fraktio’s blog. Consider this half-repost, half-rethink and half-translation, as time has passed and lessons have been learned.

I’ve been rereading Nassim Taleb’s interesting book Antifragile, which introduces a new concept, called antifragility. It’s not really something that the author has invented, but rather described and profoundly specified for the first time. An opposite to fragile is often, perhaps intuitively, thought to be “robust” or “resilient”. In fact, they are attributes that make something withstand harm. So where a fragile entity is negatively affected, a robust isn’t at all, an antifragile one is positively affected by harm.

First of all, I’ll pass on any...

As the world keeps getting more complex, I’d argue there’s more decisions and choices to be made than ever before. Science and technology keep providing advances and new questions. The constraints and rules imposed by different religions, and geometrically local customs, are dwindling. This increasing amount of choices and freedoms can have a wearing effect on us all.

decision fatigue

Everyone has a limited reserve of willpower to spend. It definitely varies form person to person, but I doubt no one has infinite one. Choosing socks or what flavour of tea to have in the morning will consume the willpower, little by little. There are the legendary examples of Jobs, Zuckerberg or Obama, who wear the same clothing from day to day, presumably because of exactly the same reasons. Less choices generally ease the decision making, as more of them can steer to total decision avoidance.

One...

There’s only a couple books that I’ve read more than once. Most of all because I consider myself a rather slow reader. I’ve got too many unread books on my bookshelf to “waste” more time reading something again. The Amazon wishlist keeps expanding, and one book references multiple others. At the same time I know I’m unlikely to digest everything in one read anyway, especially from non-fiction books.

Be it fiction or non, a second or third reading will probably be valuable. Having an understanding of the whole first, helps with understanding the minute details on the second read.

Raising the time between subsequent reads ensures the reader will have changed themself. They are likely to have new experiences to compare the information to, and perhaps even experiences affected by the first read-through. The surrounding world is presumably different too.

retention (of non-fiction)

In...

I’ve done a few public presentations every now and then, and they’ve rarely been as smooth as I’d have liked. Honestly speaking, I’ve never enjoyed much of these smaller presentations that much. I usually start nervous and get to normal levels of adrenaline and other chemicals after several minutes. By then, the presentation can be over. The whole point, though, is not so much to enjoy myself, but to collect experience and step outside my comfort zone.

content & performance

I believe when giving a technical presentation, the performance is not as important as the content. If the content is useful or can raise some thoughts in the audience, I think it can overcome any oratory problems. It’s not that I need to inspire awe with my speaking skills, but I am seriously self conscious about this. Concentrating on the content and putting the performance secondary, relieves some of the anxiety.

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...