Closing the Loop

As developers we should be experts in feedback: we want to learn about the consequences of our code changes as quickly as possible. For instance: The editor can tell if the new syntax is correct. Unit tests can tell if basic logic and interactions are as expected. Integration and Acceptance tests can tell how the change will affect the rest of the system. Continuous integration can tell if changes coming from different developers will work together....

December 1, 2014

Coaching at codebar.io

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....

October 9, 2014

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....

October 3, 2014

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....

February 28, 2012

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....

February 21, 2011

Newbie's reviews

It’s been a long time since I had to help a new team member to get familiar with a codebase I’ve been working on for a while. And although this process tends to slow development, I’m really liking the kind of feedback that can emerge from this fresh look at our existing code. After months of pairing the team developed a common understand of the system that makes sense for everyone involved, but can be really hard to grasp by an outsider....

April 28, 2010

The Joys of the Craft

The Mythical Man-Month is a great book not only because of its insights about software projects. Fred Brooks also writes about the “The Joys of the Craft": Why is programming fun? What delights may its practitioner expects as his reward? The first is the sheer joy of making things. […] Second is the pleasure of making things that are useful to other people. […] Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning....

February 22, 2010

Pomodoro Technique: are we using it wrong?

The Pomodoro Techinique has received a lot of attention lately. The reason is simple: it works. It improves focus, removes anxiety because of time and, most of all, help us getting things done. But the greatest benefit of the technique in my point of view is that it exposes all the interruptions and bad habits we have when doing our jobs. And that’s my reason to believe it should be used as a learning tool instead of a new way of working....

November 26, 2009

Behind green bars

Another day of coding is over and you produced some beautiful code. Now what? Do you know exactly how long it will take until that brand-new feature gets to its intended user? A week? A month? Never? It’s a shame that most code produced out there will park for all that time until is released. Maybe that was normal when it would take days just to compile the whole system. But today, even with all the processing power and automation, new releases are always delayed by deadlines, testing stages, approvals, sign-offs or any other form of bureaucracy....

November 13, 2009

Coding dojo etiquette

At the Ágiles2009 coding dojo, instead of trying to explain the whole concept of coding dojo, I jumped straight to a quick list of items that attendees should bear in mind during the session: If you know how to code, you should code. If you’re coding, everyone else has to understand what you’re doing. If you’re the next to code, avoid breaking the flow. If you’re not coding, don’t disturb who is....

November 6, 2009