Coaching at

Last night I had a chance to coach at a Codebar event for the first time. They offer free basic programming and web development workshops to people who are underrepresented in the tech industry.

For me it was a great reminder of how difficult it is to learn how to code. Even though my student was following a "getting started" tutorial, the amount and complexity of new concepts involved was overwhelming at times. Luckily there were always small rewards (for both of us, mind) when each new concept "clicked" after getting a particular set of commands working.

For example:

basket = {"apple" => 3, "banana" => 1}
cities = ["London", "New York"]

puts basket["apple"]
puts cities[0]

cities.each { |city| puts city }

Looking at this simple piece of code, there are many syntax concepts we just take for granted:

  • The [ and ] can be used to define an Array and to access elements in both Arrays and Hashes.
  • Sometimes { and } are used to define Hashes. Other times those are actually blocks.
  • The |city| is a parameter to that block, but for methods we define parameters using ( and ).

Even the words I've just used to describe them (access, element, define, parameter, block etc) are a whole new vocabulary to people new to programming. The tutorials do their best to introduce them gently, but there's no escape that programming at the beginning will be challenging.

I can't remember the last time I had a chance to see someone take their first steps in programming but being there to make their path easier was definitely worth it.

Also, thanks to Samir for mentioning it and despo for organising it. I hope to be able to do it again soon.

3 key skills for software design

On his talk at the Java Zone 2014, Kent Beck listed what he considers to be key skills in software design. According to him, they don't come naturally to programmers, but can be learned. Those skills are:

Tolerance for ambiguity

Developers must be able to accept that their design will never be completely clean. There'll always be forces pulling it in different directions and assuming there's only one "correct" solution will most likely just lead to frustration.

Ability to wait

Ambiguity can only be tolerated when developers are able to postpone a design decision to the last responsible moment. Many will be tempted to jump to a particular design change too soon. Or worse, ignore relevant design aspects completely.

Treating design as a social process

That's what Kent considers to be the biggest cosmical joke on programmers. Effective design requires an understanding of the human side of software. The skills and dynamics of the team will inevitably affect how software is made. And grasping what the next person is going to think when they see the solution requires as much social as technical skills.

Personally, I'm not sure if the first two can exist separately. The last I consider to be the most important, and definitely the hardest.

Back from the ashes

It's been over two and a half years I don't post anything here. In the meantime I've used Github Pages and Jekyll mainly as a backup of my old posts.

Today I've found that I was running a version so old of Jekyll that it was breaking this site almost completely, so I've decided to upgrade it and apply the Lanyon theme so it looks at least half decent.

All the old posts are still available in the Archive page.

If you saw this post in your RSS reader:

  1. Thank you for staying around (or for just not cleaning up your feed that often)
  2. Let me know if anything breaks!

Git will start asking people to explain their merges. Finally!

Annoyed by too many pointless merges in your git history? So here's some good news for you:

[...] in 1.7.10 and later, the git merge command [...] will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.

My hope is that this simple change will make people start thinking twice before merging, instead of just doing it because git makes it easy. And I'm glad the git team and I share the same vision about the subject:

[...] Merging updated upstream into your work-in-progress topic without having a good reason is generally considered a bad practice. Such a merge in the wrong direction should be done only when it is absolutely necessary, e.g. your work-in-progress needs to take advantage of recent advancement made on the upstream.  Otherwise, your topic branch will stop being about any particular topic but just a garbage heap that absorbs commits from many sources [...]

Apparently that was a design mistake from the early days of git, for which Linus also adds his point of view:

[...] if you don't like explaining your merges, this might be annoying. Of course, if you don't explain your merges, you are annoying, so it all evens out in the end. "Karmic balance", so to say.


Considering migrating from svn to git?

In December last year we decided to migrate our whole codebase from Subversion to git. Here is a few tips I'd give to someone considering taking the same route:

Evaluate the reasons for the migration. Think about specific scenarios where Subversion is not meeting your project's requirements. Check if too much time is being spent trying to make the current version control work with your workflow. There must be an opportunity to make things simpler or more efficient by switching to git in order to justify the switch.

In our case we were already working almost exclusively with feature branches, which is a great way to isolate our different pieces of work, but was becoming a hell due to svn tree conflicts. Even though that was the single problem we faced with subversion in years of use, the time wasted with merges lately was enough to justify moving all our code to a more "branch-friendly" system.

Do your homework. In other words, before starting anything, learn more about git. The best places to start are probably the Git Community Book for theory and GitHub for practice. For me it was really worth learning git's key concepts before moving to practice. It's also a good idea avoiding comparisons with svn until you are comfortable enough with these core concepts. Trying to simply map commands from one tool to another can make life harder, mainly because they don't share the same principles.

Consider not migrating the whole repository history. Although the process is not necessarily complicated, it'll probably be time consuming. To give an idea, our 4GB codebase took almost 3 weeks (!) to migrate using git-svn. That's mainly due to the fact it had to magically create git branches (which are copies of the full repository) from svn branches (generally partial copies). If I had to go through that again today I'd probably migrate trunk only, or even consider starting fresh by splitting our codebase into smaller git repositories and keeping subversion just for reference.

Spread knowledge before the final switch. Having the whole team up to speed with the new tool before starting using it on the day-to-day work is a no-brainer. Having a few people willing to train others and help them during the first weeks is also very important to make the transition the less painful as possible.

Accept the fact all version control systems require discipline. Don't expect git will solve all the problems in your project. What I noticed is that most of the problems with version control systems start when people get to weird workflows and forget that their work needs to be in a shared repository. Mixing branches, merging wrong content, losing uncommited changes and trashing the local repository will happen regardless of the system. We all make mistakes sometimes and it's best to learn from them instead of cursing the tool.

Now, almost two months later, I can say migrating was a good decision. Branching and merging feel more natural in git, and it has some cool features that are surprisingly useful, like cherry-picking. There are still some rare cases when a developer ended up having to recreate a local branch or even having to clone the local repository again, but even these operations are simple enough and I imagine they would probably be avoided if they had more experience with the tool and its workflow.

In any case, just the fact of not having to deal with merge nightmares in subversion again makes me really happy.