Tasks un-owned are task that go forgotten

If you are a tech company, and your people commit code, then you probably have some code review policy. And if you do not, you definitely should: you want to have an extra pair of eyes on the code that goes live. You certainly do not want a mistake to break things. And that is why you do pull requests to contribute to GitHub repos, and why Google employees must have a certain degree of maturity to commit code without review.

BUT, as long as that is a good idea, we must be careful to implement it the right way. Just enforcing reviews is not enough. You want to make the time between the code is sent for review and the code is deployed as short as possible. The longer the review time span is, the more work will be needed when the review comes. That is because:

  1. Who wrote the code simply does not have it fresh in their mind anymore. The context switch between the current task and the code he wrote days/weeks ago is just more demanding;
  2. Conflicts are more likely to arise, and then more work is needed in solving them;
  3. Other issues may depend on the code being held for review. Other people may spend (waste) time debugging an issue for which a solution is already available;
  4. If the repo is public, it makes more difficult for other to jump in and contribute, because they also have to be aware of all the pending code.

The right way to implement a code review system in a tech company

I think the best way to implement a code review system is to:

  1. Assign each code review to a particular member of the team. If everybody owns a task, then nobody does as well. That is why you want that particular review to be a responsibility of someone specific. An automated system can randomly assign a review to a team member.
  2. Each code review comes with a deadline. That’s it: code reviews are as important as any other task – basically because every other task often generates a code review at some point, so if we lag on those, nothing gets carried to the end and we are getting no work done at all! We may have different priorities associated with different deadlines, but we want each review to expire at some point (with the longest being a couple days)!
  3. Team members can turn down their assignments, but only if they have a good reason to. Again, if code does not get reviewed, it cannot go live, and thus the work has been done for nothing. Reviews are important and must be considered as such.
  4. Then just track how it goes: who is turning down most assignments? Is the weight uniformly distributed across the team?

A tale in topology – The large clovers meadow

A small tale with a topological soul, with the aim of providing a very high level intuition for the notion of density and dense set in topology.


Smally Open was a cheeky youngster of the Open family who lived in a large meadow. It was a very nice and green meadow, well cared for and abundant in clovers. Smally Open liked it much because he found it magic. Oh, I wish you were there as well, my smally readers: Smally Open climbed the highest trees, went as far as he could from his home, went down below the blades of grass, but there was no way: anyway he was, Smally Open would always see his verdant meadow, as if it moved with him and changed its look. Anyway he looked, Smaly Open would always see a large green meadow.

You will wonder, my dears, if Smally Open did not get bored to death in always seeing the very same meadow anywhere he went… well, I hope you do not believe that it was just all alike! The meadow looked all the same if you looked from afar and without attention, but sometimes there was a butterfly here, some other time there was an amazingly beautiful red leaf there: at any rate, there was always some new thing to fascinate him.

Anyway, when Smally Open did get bored, there always was a nice way he liked to use to spend his time: go and bother Mr. Dense-D. He was pretty a weird and extraordinary sir, in fact he had a lot of heads (how many, you ask? Try to count the stars in a cloudless night: Mr Dense-D had at least three-times-twice-one-thousand-times-that-number-of-heads!) You should not however think of D-Dense as a green weird martian with several scary heads, going away pecking at children’s ears, no! D-Dense was a very distinguished man, very kind and happy.

Indeed, D-Dense was the happiness of the meadow in which he lived together with Smally Open, because he was its clovers. But not a few crumpled and frail clovers, oh well stop with these prejudices towards Mr. D-Dense! No, those were beautiful clovers, big and comfortable, and above all there was one in any part of the meadow you would look for. When Smally Open was tired, he would look around and immediately find one of the heads of Mr. D-Dense, upon which he could rest under the sunlight.

Apertolo, paying, would often jump from one blade of grass to another. When he would lose his balance and fall in the void he was always lucky that Mr. D-Dense lived in his same meadow, because were it not for his many heads that would catch him, falling on the ground he would at least get a big bruise! But Smally Open sometimes take advantage of Mr. D-Dense’s kindness: he would jump on his heads from tree tops on purpose, he would eat on the clovers, crumbling on D-Dense’s heads, or he would ruffle all his hair intentionally. At any rate, he would really bother him! Mr. D-Dense was a patient man, but one day he was fed up and said: “Enough, I am old and tired: I need a quiet holiday. I am going to leave.” And so he started lifting himself.

First, Smally Open fell on the ground. Then he heard a great rumble, as if the whole land was shaking, and saw all the clovers moving and lifting, with mountains of soil up in the air, until Mr. D-Dense headed with all his clover-heads towards the horizon.

Continue reading

A/B testing on WordPress: a framework for developers and tutorial

Some months ago, I changed one link in the menu in my website postpaycounter.com. After that, it looked to me more people were purchasing products, i.e. the conversion rate had increased. But how to check whther that was really the case, or if it was just an accident/impression? Use an A/B test, I told myself!

With an A/B test, half of the users are served one version of the page, the one with the old link, and half of them another version of it, the one with the new link in place. When a sale happens, we may then log that as a success for the kind of page that was used, be it the A version or the B one.

In my case, the two versions of the page simply consisted of two different links in the menu, while I wanted the success to be logged when the user purchased something (I use Easy Digital Downloads to handle purchases).

I could find a bunch of plugins that allowed to set up A/B tests, but they all seemed pretty difficult to customize from a developer perspective, and I was already seeing myself wrestling with someone else’s code that provide tons of features useless to me, but through which was nearly impossible to interact with Easy Digital Downloads. So I decided to build my own, simple implementation, with the aim of it being tailored to developers rather than users who needed an interface. 

An A/B test implementation example

This is an example of how to use the little framework. To set up a test, you only need to provide two functions:

Continue reading

Numpy histogram density does not sum to 1

During a Computational Vision lab, while comparing histograms, I stumbled upon a peculiar behavior. The histograms pairwise kernel matrix – which is just a fancy name for the matrix holding histograms correlations one with another – did not have ones on the diagonal. This means that one histogram was not fully correlated to itself, which is weird.

numpy histogram integral not 1The comparison metric I was using is the simple histogram intersection one, defined as

    \[K_{hi} = \sum^{d}_{m=1}min(x_m,y_m)\]

Continue reading

The Distributional Hypothesis: semantic models in theory and practice

This was the final project for the Data Semantics course at university – A report on distributional semantics and Latent Semantic Analysis.

Here is the nicely-formatted pdf version (with references).

What is the Distributional Hypothesis

When it comes to Distributional Semantics and the Distributional Hypothesis, the slogan is often “You shall know a word by the company it keeps” (J.R. Firth).

The idea of the Distributional Hypothesis is that the distribution of words in a text holds a relationship with their corresponding meanings. More specifically, the more semantically similar two words are, the more they will tend to show up in similar contexts and with similar distributions. Stating the idea the other way round may be helpful: given two morphemes with different semantical meaning, their distribution is likely to be different.

For example, fire and dog are two words unrelated in their meaning, and in fact they are not often used in the same sentence. On the other hand, the words dog and cat are sometimes seen together, so they may share some aspect of meaning.

Mimicking the way children learn, Distributional Semantics relies on huge text corpora, the parsing of which would allow to gather enough information about words distribution to make some inference. These corpora are treated with statistical analysis techniques and linear algebra methods to extract information. This is similar to the way humans learn to use words: by seeing how they are used (i.e. coming across several examples in which a specific word is used).

The fundamental difference between human learning and the learning a distributional semantic algorithm could achieve is mostly related to the fact that humans have a concrete, practical experience to rely on. This allows them not only to learn the usage of a word, but to eventually understand its meaning. However, the way word meaning is inferred is still an open research problem in psychology and cognitive science.

Continue reading