August 29, 2019

Bitbucket and Mercurial


It has been recently announced that Bitbucket will be leaving Mercurial support in 2020 [1], defaulting to Git from then on.

A lot of things come to mind when reading the announcement, mostly because Mercurial has been my first distributed revision control system or at least the first one I understood. It's fairly simple to use, concise and with a simple interface, but sadly has fallen in popularity.

Git has won in other fields where popularity is more important that correctness and simplicity. If I would go back in time and choose between Git and Mercurial, I would still choose Mercurial, it's still a great tool.


[1] https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

June 5, 2019

Debugger usage as bad smell?


A lot of times development is not straightforward, you hit a corner and don't know what else to do to fix a problem. During those periods I've seen many developers do the following things:
  1. Start the debugger right away and go step by step into the problem
  2. Sketch all possible scenarios that would lead to the problem, then println-debug each scenario
  3. Take a walk for 10 mins to think about the problem
 While all these approaches have worked for me, I tend to ignore the debugger use more and more over time. The reason for it can be summarized as:

   "By using a debugger, I'm always avoiding to first understand the problem, but instead patching it with a single-scenario fix"

In the past I've used debuggers a lot, starting it as soon as some problem arose. But then a pattern started to show up,  fixes were coming back with other problems that the first fix didn't cover.

It took a while to understand this and slowly move away from debuggers, it all started when some production applications started to fail, and we didn't have the chance to debug in such environment, we just had the logs.

Reading the code, checking the possible inputs and flows, creating a test case (hopefully automated) and then attempting different fixes resulted in more consistent patches, fewer round-trips with the customers and higher efficiency in the team.

So, whenever someone's starting to fix a bug, my first instinct is to try to create a test case that reproduces the problem before firing up the debugger gun.

November 1, 2017

Review: Weekly Experiment: Standing desk

After a week trying this new setup for working, here the results.


The rules:
  • During mornings sitting will be the default
  • During afternoons standing will be the default
  • During lunch-time standing will be the default

The control:

  • Did it have any physical effect? 
    • A big physical effect, the body feels better, although there were some small pains after the first days
  • Did it have any food/drink related effect?
    • Clearly, I consumed much less sugared drinks, not even coffee, and the body didn't ask for it.
  • Did it have any sleep-related effect?
    • Not sure if related to this single event, but I've been sleeping better.
  • Did it affect in any way productivity and awareness?
    • This was the biggest effect, procrastination decreased, interactions increased, awareness increase, hence productivity increased as well.
Result:  This is a must-do practice, I'm going to extend it to full work-days and not only in the afternoons, the effects have been so noticeable that I can't avoid feeling weird by sitting down.