How, What, Why: The Three Essences of Software Development


“Facebook is as much sociology and psychology as it is technology” – Mark Zuckerberg

In my previous article, Unitary vs Integral Understanding, I delved into how we understand a part of a system in terms of how it relates to the rest of the system. To recap, Unitary Understanding is understanding the part by itself, abstracting the rest of the system, e.g. “i = i + 1” understood as a unit means nothing more than “increment i by one”. Integral Understanding would require us to see how that sentences interacts witht the rest of the code, so for example that sentence could “move a loop forward”.

“How”, “What”, “Why” are three questions that are also helpful to see different facets of a system. A lot of what follows in this article might seem obvious to seasoned developers, but in my experience, these dimensions, because they’re intuitive, are often not adecuately explained to junior developers.

Be Careful With the Mocks

mocks, tests

Mocking objects is a common practice when writing tests, however it can be painful when refactoring a class tested with mocks. I will show a simple example to explain the problems that mocking can generate, but first I would like to give some definitions:

  • Stubs are objects that respond to a subset of messages from the object to be stubbed with specific responses.
  • Mocks are objects that verify the integration between the system under test and the mocked object.
  • Fake are objects with implementation that simulate the real one but they are simpler and/or faster.

Learning Programming


Dealing with failure and frustration

I’ve recently finished my apprenticeship program here at 10Pines. The experience was way beyond my expectations. Really. I’ve learned much more than I expected. In order to show some of my experience during my time here, I was asked to write a post about something I’ve learned. I’ve decide not to write about the techniques or tools I have gained, but about the human aspects of this educational period, which include, in my opinion, two very important concepts.

Caring About Coding


This is a repost of an article we wrote with our friends at 8th Light. See the original article here.

As a programmer I spend a lot of time in front of the computer. But despite appearances, I am not there. I am not in front of a computer every day for 8 hours drying my eyes and weakening my muscles. I am somewhere else.

Tips for Introducing Yourself in a Conference or ‘the Conference Elevator Pitch’

agile, conference, elevator pitch, introducing yourself, personal elevator pitch, tips

It could sounds basic, but when you talk with people in a conference, you have to think quickly. So it’s very important to have in mind a successful path to a productive five-minutes chat. After being talking with a lot of people and making a lot of mistakes (since not knowing what to say about what our company do, to not asking how to contact him/her back); I’ve decided to write down a guidelines to introduce yourself and getting to know the other person, avoiding typical mistakes.

Review of Agile 2015 @ Washington DC

agile, agile 2015, agile alliance, conference, summary, washington

The organization & the conference

This was the biggest conference I’ve ever attended. There was 2300 registered people. 5 days of talks. More than 13 tracks in parallel every hour. Everything was in big scale. One thing that called my attention was the average age of the attendees; I’m used to see young people in the agile conferences in south america. But here, it’s really different; most of the people were around 40/50 and even more. So I understood this conference and the US agile culture about software is in a later stage than in South America. And this is pretty interesting because you will find people who have been working with agile practices for more than 10 years. Even in the government there are a lot of projects working that way. So I think it is time to see agile software development as the “classic” way to develop software and not as the “new” way. Another weird thing for me is that the conference is designed for you to miss things. There is a lot of things going on at same time, beside the talks, you have a coaching clinic, lighting talks, TDD workshops, space jam, companies lounges with activities, boost, and more. So, I think it’s designed to cover all needs, but it’s impossible not to miss anything you are interested on. For a guy like me, who don’t like to miss anything, it was hard to be relaxed.

Tests: Paving Our Way

design, tdd, tests

Three Months have passed since I started working in 10 Pines as a participant of the apprenticeship program. Although we covered different topics and technologies, one of the things that has touched me most during my short journey as a programmer is that you can actually use your tests as the documentation of your system (you read it right, I’m not insane). This was a breakthrough for me so I decided to write this post to share some thoughts about it.

Why do we write tests?

I’d like to start with a short reflection about tests and the meaning we give to them. It’s true, testing gives us security and confidence. It lights our way, allowing us to perform changes without blowing the entire system into pieces. However, there is another (and equally important) reason to write tests: It’s the place where we write down the things that we’ve just learned about the domain we’re modelling. Bearing this in mind, tests have become a compilation of my discoveries and that’s what they must reflect.