Trabajar en un proyecto con mucho código heredado siempre es una fuente de grandes aprendizajes. En esta ocasión les presento a los "defaults malvados", como a mí me gustan llamarlos. Son partes de código que pueden hacer mucho daño en una aplicación. Veamos cómo…
Throughout the last few years of my career, two words have been present almost every day: principles and habits. I believe both can help us be better people and drive positive change around us – in general, but in software in particular.
¿Qué hacer y, sobre todo, qué no hacer cuando un sistema se cae? Algunas ideas para atravesar lo mejor posible esta experiencia y obtener aprendizajes en el proceso.
We name objects, we name variables, we name classes, messages, functions and types. We name all the time because names allow us not only to reference “something” but also to understand what that “something” means.
Un análisis sobre el artículo "Test Desiderata" escrito por Kent Beck, en donde se listan 12 propiedades deseables de los tests.
We surely agree that there’s nothing better than users telling the dev team such stories. But, How should we call them? User stories, backlog items, story cards? And even more important: what is the most efficient way to write and manage these stories?
Does anonymity play any role in agile teams? Even more, can we pretend to pursue a mature agile environment when members of the team are afraid to take ownership of their opinions? Let's think of a few tips to evolve into trust and self-confidence on agile teams.
Inspired by the success of the series about the Chernobyl disaster, these are 10 lessons learnt from it so you too can make sure your project is a bomb.
It's been less than a year since I joined 10Pines, and a little more than two since I started working officialy as a programmer. I don't like calling myself a junior developer because
Have you ever heard about the Rails way? I would like to introduce some pains that I've seen and keep seeing in all the Rails projects due to the Rails way... ActiveRecord How
There is an often unresolved question in software about comments and documentation. It is said that code should be "self-documenting", thus comments can be a sign of a lack of clarity in the code.