Why you should never put “London” and “culture” together in a sentence (November 27, 2016)

I normally restrain from posting my gripes about current affairs or politics publicly, but why not try once? I’ll write about culture — and money! — in different countries. This will be a start of my series If You Think London’s Culture is Vibrant You Haven’t Been to Any Other Major City in the World.

This is the main building of the Bolshoi Theatre in Moscow. If you have a look at the headlines in The Guardian, you’ll learn that Russia is run by an autocrat, the corruption is rampant, the economy is stagnating, the best minds are fleeing. The country is not even in top 10 largest economies worldwide! Yes, yes. Nevertheless, in 2005 Bolshoi Theatre in Moscow closes for renovation, the largest in scope it has ever had, with a plan to reopen in 2008. Here’s what it looked like back then.

Come 2008, then Minister of Culture announces that it would be impossible to complete the works on time and provided everyone with a new estimate of finishing in 2010-2011. What follows in the years after is a story of several embezzlement scandals, incessant rotation of people responsible for the restoration works, and budget overruns. In late 2010, nevertheless, the theatre’s first hall becomes open for the public, with its building still being completely wrapped in scaffolding, and a year later, in October 2011, Bolshoi reopens completely. Official figures for the final costs are in the region of $700 mil, some sources quote estimates up to $1.1 bil.

Was it expensive? Sure. Did a significant part of that money landed in wrong hands? Absolutely. Nevertheless, Moscow now has a renewed Bolshoi for everyone to enjoy.

How about some stories from Europe? Hamburg — in 2007 works have started on top of the older port warehouses for the Elbphilharmonie building, a new seat of the Philharmoniker Hamburg orchestra.

In 2007 it was expected to finish the building in 2010, in 2010 the date moved to 2012, and the building was finally unveiled in October 2016. It costs between $800—850 mil, which is even more impressive given that Hamburg is not a large city by any measure and is not a nation’s capital. The Elbphilharmonie will be opened for performances in early 2017, ten years after the construction has started, and Hamburgers will have access to another world-class classical music venue.

Copenhagen — in the former docks area on top of the Holmen group of islands, a new opera house is built between 2001 and 2005.

The building is completely funded by a family behind the Mærsk shipping company, but — here’s the catch — is completely tax-deductible for Mærsk, which means it was the Danish government who paid for it. The price was in the $500 mil area, and don’t forget that Danish economy is not even in top 25 worldwide.

Now let’s move back to the UK, a fifth economy in the world. How sad and different is the state of affairs that we see here! From 2000, there were zero new development in the cultural sphere in the country’s largest city. A noticeable blip of that period is the 2001 relocation of the British Library into its own building which allowed British Museum to open its Great Court. Here it is, the pinnacle of sixteen years of British public architecture.

The Shakespeare’s Globe theatre, the only original conception in this field, was completed in 1997, almost twenty years ago. Tate Modern was opened in 2000, in the pre-existing building. Southbank Centre, which some may call a home for the most cutting-edge art in London, was built in the 1950s.

Now how about the UK government adopting “let’s build more cultural venues” instead of “let’s build more affordable housing to house drug addicts” mantra?

Later update

This post caused a lot of feedback from my readers. A typical complaint from die-hard Londoners was that I’m putting too much weight on what they call “investment in culture”. They invited me to look deeper into the actual events happening on the London cultural scene, as opposed (in their view) to the real estate development.

That’s a fair comment. Some of the best cultural events in London are truly great, and I can’t even imagine myself seeing them all. The thing is that investment in culture signals a certain worldview. When I praise Vienna for having not one, but two classical movie establishments (Filmmuseum that has its own screening space, and Filmarchiv that uses Kinokulturhaus to show its films), it’s not because I ever hope to see everything they have to offer. It’s because having places like this is what makes us members of a human race. And London sometimes works really hard to make Londoners forget they are.

Couple of good videos I watched lately — 3 (November 20, 2016)

Category Theory for the Working Hacker. Philip Wadler, one of the most important computer scientists in existence, a person who is extremely well known within Haskell community, and a (falsely attributed) author of the quote “A monad is just a monoid in the category of endofunctors, what’s the issue?” explains what is that that we all, as practicing programmers, need to know about category theory, while nicely illustrating his talk with slides full of handwritten code.

I personally think that category theory is a very promising direction to consider when finding ways to build very large software systems from modules. My intuition about it is that on a meta-language level it offers a very useful parardigm, which is absolutely comparable in expressive power with the “code as data” paradigm of Lisp, or “code as expression” paradigm of APL-derived languages. I’ll try to elaborate on that in one of the future posts, but you can watch the video straight away.

The Secret Life of SIM Cards. This is a video on security, which is normally not the topic I deal with, but this talk is particularly fascinating because it talks about “an OS within an OS within an OS” — a software running on a SIM card, which interacts with the baseband (another specialized operating system), which, in turn, interacts with the main operating system of the phone.

Teamwork (November 13, 2016)

The concept of teamwork I briefly mention in the previous post warrants a post in itself. I’m absolutely not an authority on building and running teams, but just like anyone else in the programming profession I’ve got some of intuition about it.

First of all, it seems like good teams are rare: most companies are dysfunctional in some way or the other that sometimes make Dilbert cartoons look like the bastion of good reason. Dan Luu wrote a long entry on that recently:

At the last conference I attended, I asked most people I met two questions:

1. Do you know of any companies that aren’t highly dysfunctional?
2. Do you know of any particular teams that are great and are hiring?

Not one single person told me that their company meets the criteria in (1). […] A few people had suggestions for (2), but the most common answer was something like “LOL no, if I knew that I’d go work there”.

Over years, advances in software engineering — which is most commonly defined as a set of practices allowing software development on an industrial scale — made it possible to at least partially work around human imperfections by established a software development process. Practices like writing unit tests, doing code reviews, adhering to coding standards and choosing low risk technologies made it possible to develop software of enormous size. Like any process, when being enforced unreasonably those practices have a chance of scaring away your best employees and potential candidates.

That’s simply because those things are not pleasant. Nobody likes writing unit tests, or renaming variables just because your reviewer has an idea of a better name. A job that advertises itself as being in a team that practices TDD to the book is most likely the one that you’d want to run away from.

However, encountering a good team that works together organically is possible. My intuition for recognizing a team like this is that it shouldn’t require you to be dumber than you are. You want to write smart code? Sure, go ahead, you shouldn’t have any reasons to think that your colleagues won’t be able to understand it.

How I learned to program pt. 2 (October 29, 2016)

This continues from part one.

First job and the discovery of teamwork

My first job was doing Java at an “e-commerce” firm. I spent some time churning out alone large amounts of code, and quickly understood that this must be the most inefficient way to deliver software. As cool as having the laser focus of the “lonely cowboy coder” is, you can achieve much more when people don’t see you as the hermit guy with the red stapler from Office Space but are instead enthusiastic about working with you and you are enthusiastic about working with them. Few years later, when I joined a really strong team at a company doing mobile call processing software, it felt even more true.

Several jobs and teams later, I still can’t really point my finger on what constitutes a great team. It may boil down to having some common ground with your colleagues, which leads to you quickly understanding each other without the need to resort to corporate speak, but I don’t know what is it.

Algebra and the rediscovery of abstractions

Turns out, reminding yourself about the math you studied in the university several years after graduating is a good way to boost your programming skills. I came back to abstract algebra recently and it feels like it’s worth it (for recovering programmers, this book may be a good introduction). Surprisingly many problems in very different domains can be expressed using a semiring or similar structure, which gives you lots of room in how you can reason about them. I, essentially, learn to write as little code as possible to achieve the same goal.

It looks like I’m not the only one out there trying to reach for this goal. Forth people have long ago discovered the usefulness of programming with as little as possible. Languages with strong type systems can help achieve the same goal.


This part is very much a work in progress, but one thing is clear to me: the problem of composing large pieces of code together without driving your development team crazy is both important and not solved. I saw many companies working with large code bases throw lots of manpower at it and I definitely would like to get better at dealing with it. It’s now fifteen years since I’ve started working in this industry — here’s for the next fifteen!

How I learned to program pt. 1 (October 22, 2016)

It’s very tempting to start this entry with a nostalgic description of all the old hardware and software I’ve ever worked with, but I’ll skip that part. When talking to other programmers, I’m more often than not astonished by all the different paths people follow on their way to this profession. Despite being immersed in a very similar spirit of time, even most programmers of similar age to me arrived where they are via their own unique way. So I thought it could be an interesting exercise to list the milestones on my own path that seem important in retrospect. Who knows whether skipping any of these would have had a profound effect on my career, but here they are.

8-bit assembly and the discovery of abstraction

During the school years, before I first started fiddling with programming in Z80 assembly, my view of computers was very romantic. When you encounter assembly, it totally sobers you up. This is partially due to the fact that it reveals the computer completely in front of you, down to the hardware rock bottom, so that no more mystery remains about it.

At that time I had a go at the demoscene, which forced me to think hard about the programs I was writing. Here’s why: to the high school version of me, the assembly program was just a sequence of elementary steps, nothing other than a straight flow of instructions. I don’t remember using any sophisticated data structures, or organizing code in any way, except minimal split into procedures. It obviously led to a code that was never up to the serious performance standards of the demoscene. Nevertheless it was inconceivable for me at first that some alternative way of writing programs may exist. Over time, different ways of looking at the same small operations slowly started revealing themselves to me. For example, if you need a series, you don’t necessary need the loop. A blob of data generated at right in front of your program counter becomes code. Stack is just a memory, and so on. I entered university suspecting that there was more than one way to describe what you want the computer to do — by abstracting yourself away from the sequence of instructions — and that this is actually important.

Pascal and the discovery of void

During the first university year, the teaching language of choice was Pascal and the teaching style of choice was asking students to implement many standard data structures in it. This wasn’t difficult in itself, and my main memory of that time was struggling to deal with the “absence” of something, like a search tree that has no nodes. Adding a node to a tree is simple, you just hook to a node’s parent, but how do you add a node to an empty tree? On one occasion, an algorithm required several nested loops with the innermost loop’s both lower and upper bound controlled by the outer ones and both starting from zero, which eliminated the inner loop for the at least one iteration. At 18, I found it so difficult to reason about the collapsed loop, that I instead chose to perform whatever the first iteration required outside of loops — by hand. My dorm roommates who were less clueless about writing programs gave me some hard time laughing about that. That was the beginning of my learning to juggle “absent” code or data in my head.

This is continued in part two.

← Later entries | Earlier entries →