Category Archives: Thoughts

The spiritual similarities between playing music and table tennis

Posted on by
Reply

As a fellow table tennis player and piano player, I have noticed some interesting spiritual similarities between the two arts. I’m pretty sure they are also common to other sports anyway.

Always think ahead: the next stroke, the next note

In table tennis, one should not think about scoring a point with the current stroke, but rather be prepared for the next. What ball will I get back given my current playing? What do I expect? How am I going to handle it? If we do not think ahead, we will always fall short when the ball comes back, we will not be prepared. In a similar fashion, when playing an instrument, it is vital to know what the next note will be, what the next musical phrase will be. Giving meaning to a speech is impossible if we do not know how it goes on beyond the very current moment.

Mistakes do not matter. If you make them matter, you lose

It is a common phenomenon to make a mistake followed by more mistakes, mostly in the attempt of correcting that mistake/with the case of overthinking the mistake that has already happened. It does happen to make the wrong choice when playing table tennis, or to not get our best stroke, as much as getting a note wrong. This is not a problem as long as we are able to go on and forget that single mistake. Instead, if we focus on that, we end up stressing it and it becomes much heavier.

Continue reading →

The need of teaching and learning more languages

Posted on by
Reply

For a second, stop to think about how many languages you know. With languages, I do not mean verbal languages: rather, any means of expressing thoughts and feelings, or of expressing a dialogue. I am here do advocate for the learning and teaching of more than just one.

Our western culture is based on the verbal language – the one you can speak with your friends, read in novels, and write in essays. We educate kids in that, and yet I would argue that very few of them end up being proficient in the verbal language. Speaking a language does not make you proficient in it: that skill is a much higher level one, and involves deep knowledge of the structure of the language, exposure to thousands examples of both good and bad usage of the language, and effortful practice throughout years. Often, people who venture in learning a new language (a verbal one) do not even ever get comfortable with their mother-tongue. What I mean is that although everybody can talk in their own language, few of them have a real mastery of it. Few people, for example, are able to tell a story (and not because of lack of ideas, but for inability of structuring it), and even fewer are able to read one out loud in a way that is vaguely engaging (for example, they cannot look away from the book to the audience, and fill in any gaps in their reading my making up appropriate fill-ups).

But even if people were proficient in the verbal language, this is just one means of expression. It is barely minimum. And even though we study several different subjects at school, they are all taken across through the same verbal language. But what about other, different languages?

Musicians, on the other hand, can rarely express the feelings and the moods of a musical piece through words. They have a different alphabet, one that does not have translation to the verbal one. The fact that sometimes, some situation reminds them of a tune, or inspires them a tune, rather than words, is a clear example that the musical language is different altogether. It is incredible that we are still studying Latin and we are not all studying music.

Sports is another example where a different language is in place. The main difference between experienced and beginners in table tennis, for example, is in how they frame/live the unfolding of a point. Experienced players see a dialog in it, a conversation that ultimately leads to scoring a point. But it is exactly this sense of structure, this ability to realize how each stroke is connected and what each of them can have as consequence, that gives experienced players an unmatchable advantage. They know what is going to happen, and they know it because they are building something with that language.

Continue reading →

The reasons why mathematics teaching is failing

Posted on by
Reply

As a mathematics PhD student, I have seen a lot of mathematics teaching. I have been lucky enough to witness some (very) good teaching, but I have also been inflicted with so much bad teaching. Sometimes, I just wondered whether the people do even realize that their teaching is horrible, and I most often believe they are just unconscious about it, since most of the teaching they were exposed to was bad for them as well. I guess they just believe there is no way of making a good teaching of math, since most of it seems to be so bad.

I genuinely believe all graduate students in any subject should care about teaching. Even if you do not particularly care about teaching others, it makes your knowledge and understanding stronger. Just thinking at what matters (which is what you would teach), and how it would be best presented, forces you to thoroughly understand the topics to a deeper level. And at some point, you will just wonder: what are the essential elements of bad teaching? How can I avoid them?

#1 – Too many answers, too few questions

I am genuinely convinced that the most essential element of bad teaching is providing answers instead/without questions. Too often we go to class and we get lectured about some method, some theorem, some theory – and too seldom we get lectured about the path that actually led to that method, theorem or theory.

Continue reading →

On knowing when to stop in software development

Posted on by
Reply

One of the very few things I learnt in art class is what the role of Jackson Pollock was in his art. Because, we were asked, what is the role of the artist, if the only thing he does is let paint drop on a canvas? His role is to decide when the work is complete.

This is something we most often overlook in computer science: there comes a time when a project, or a feature, is complete, and any more improvements, any more work put into it is likely to decrease its value and ruin all the good work. Too often we want progress in our applications, without realizing that it’s actually destroying them. Sometimes it’s just better to move on and work on something else. Even if a solution is 10 years old, it doesn’t mean it has to be updated because progress requires it.

Let me present a couple examples.

The Gutenberg editor in WordPress

WordPress 5 introduced the new Gutenberg editor, a project that has been rated with 2 stars out of 5 with a total of around 2000 reviews at the time of writing. It’s a product that is so buggy and un-usable that it is bewildering that it made it into Core, but whatever (in 10 minutes of usage, I found 7 crucial and unreported bugs just 4 months prior to release – see my review).

gutenberg reviewsLet us pause and ponder why it was introduced. Any apology of Gutenberg will say that is because the classic editor felt old. It looked so much like Office 2003, and it’s 2018, they say! You see, they say, 15 years in computer science is a huge deal!

But, you see, what is the main purpose of an editor? To write. And to that it must be apt. Gutenberg shifted the focus from writing content to designing a page, effectively forcing a progress in the wrong direction. Not much has changed in writing since Office 2003 came around: we still use bold, italic, headings, text alignment and little more. Anything else requires the careful crafting of a designer and writing of some HTML, as it should be. Nothing else is needed, really, when it comes to writing. But, they say, you cannot even create a table with the classic editor! And I say, that’s right, it should be possible! But that doesn’t require trashing a whole editor and building a cumbersome React-y thing just so that we can have tables, does it?

But, they say, this way you don’t need a designer to design your pages anymore. Of course, people must be really stupid if they have been paying web-developers/designers to put up their websites for the last 25 years, of course! So stupid of us! There, instead of hiring a professional photographer to shoot at your weeding, just give a compact camera to your uncle, since technology and progress have enabled you to do so. Because it really is just the same. When I was a kid, websites designed with Dreamweaver were looked down on, and anybody who wanted a real site should have hired a professional. Not it looks like everybody can do everything – expect that, uhm, they can’t.

Too often the right questions are not asked and carefully considered. Those are the most basic ones: do we really need this thing? How difficult is it to build it? Is it really worth it? What is the impact it will have on users/market? Does it add something really useful and needed without breaking anything else?

Continue reading →

A day tour in Cork, Ireland: the best things to see and do!

Posted on by
Reply

After spending two months in Cork, Ireland, I feel like I can provide good advice for a nice day tour in Cork. I stayed in July-August, so some of my comments may be affected (by good weather, mostly). Here is the photo album of the whole time.

I think the best way to go around is on foot, as you can really enjoy the town, but there are the Coca Cola bikes that can be rent for 3 days: you just need to register online, pay a few euros, and then pick a bike in the many bike points scattered around Cork, and return it in any other one.

A day tour in Cork

If you want to go to the tourist office, for example to take a map or ask for some information, the best time to do so in when you get in town. In fact, the office is near both the bus station and the CityLink stops. In the building just in front of the tourist office, at the second floor, there are free toilets, handy in any circumstance!

In Shandon (St. Anne’s Church) you can ring the church bells! It really is amazing! Music sheets are provided with popular songs (Hey Jude, Lord of the rings soundtrack, and many more) and the bells sequence to be played. It is a bit out of the centre, but it does even go through nice streets. For students, the entrance is just 4 euros, and you can also get to the top of the bell tower and see Cork from above. Beware that the last entry is early in the afternoon, at around 16. This church is also called The Four Liars because, with strong winds, the four clocks on its sides are said to never display the same time.

The four liars, St. Anne's Church, Shandon

The four liars, St. Anne’s Church, Shandon

Exactly on the other bank of the river there is Elizabeth Fort. It is not much, they are basically some high walking paths, but again you can see Cork from above (although not as high as the Church), and it is free! Closes at around 17. Near here there is also St. Fin Barre’s Church, which is patron saint of the city. The church surroundings are not bad, the church is huge (but entry is not free) and there is a very disappointing labyrinth.

On a clear day, Fitzgerald Park is a beautiful place. It’s the biggest park of the city, there are often events in the weekend (music/festivals). There is even a bar that makes nice launches for reasonable prices (~5 euros for a sandwich), and you can then eat on the grass on the river banks. It’s a bit out of town, like 20 minutes on foot, but you can go there basically all through pedestrian-only streets, and there is a walking route that goes along the river bank on the other side: it starts from Shandon’s side and is called something like Banks of Lee Walkway.

Continue reading →

Tasks un-owned are task that go forgotten

Posted on by
Reply

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?