Tags: software development

Los defaults malvados

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…

Tags: clean-code

IAR: a mnemonic for a clean controller design

¿How do you design HTTP controllers? ¿How do you make sure responsibilities are correctly assigned? ¿How do you reduce maintenance issues? I'll introduce you to three letters that might help you remember the essentials of every controller…

Tags: best practices

The principles and habits of healthy software

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.

Tags: refactoring

Obvious Programming

A technique to know how much refactoring you need on a piece of code. Refactor your code until it looks obvious to you and your team

Tags: agile

When not to pair

Sometimes, pairing is not going to add this extra value we're looking for... which are those moments? let me go over some scenarios where it's probably better to work alone.

Tags: agile

Leaving a codebase

I'm leaving a codebase where I contributed for 6 years. I've made more than 2000 commits and I've added, modified, and removed a lot of lines of code. Here are some things I have in mind as part of my offboarding process.

Tags: maintenance

Dealing with upgrades

A very important part of software maintenance is to keep languages, libraries, and framework versions up to date. I've experienced this many times and I've collected some tips or patterns that helped me to deal with future cases.

Tags: refactoring

El arte de las pequeñas mejoras

Refactorizar es lindo. Pero la realidad nos presenta restricciones (tiempo, alcance, tecnológicas, políticas). Ahí es donde la creatividad toma importancia y debemos lograr un alto impacto en poco tiempo, mientras hacemos crecer nuestro software.

Tags: tdd

El primer test

Quizás la mayor dificultad al trabajar con TDD es empezar. ¿Cómo ir más allá de la hoja en blanco? TDD nos invita a aprender muy rápido, a sabiendas que nos vamos a equivocar mucho. ¡a prepararse, pues! ¿Qué características debería tener ese difícil primer test?

Tags: refactoring

Clean Code Cleanups

I’ll walk you through different stages of code cleanup, and things to have in mind to make it in an efficient way, based on my experience.

Tags: experience

8 years, 8 challenges

I'm very happy to complete my 8th year at 10Pines, and I would like to share, for each year I've worked here, the biggest challenge I had and what I think I could have done better. In other words, the most important lessons learned each year.

Tags: tdd

6 tips para una exitosa sesión de TDD

TDD es ~95% práctica. La teoría seguramente la conozcas o la hayas escuchado, el ciclo de Red-Green-Refactor te sea familiar y sepas qué es lo que se hace en cada paso. La práctica es lo difícil... esta es una simple lista de cosas que funcionaron para mí, y que quizás funcionen para vos.

Tags: oop

Reifying problems in our software: a short story

Yet another lesson from a large project with legacy code. Did you happen to see “known issues” in software that you have worked on? And how many times have you seen them “solved” with “quick fixes” or “workarounds”?

Tags: software development

The Evil Defaults

Working on a project with a lot of legacy code always leaves good lessons. This time I’ll present you what I like to call “evil defaults”, pieces of code that can do a lot of harm in any software project.

Tags: tdd

6 tips for a powerful TDD session

TDD is ~95% practice. The theory about it is really simple. Practice is harder, and it's always beneficial to have some guidance as you practice it. Here's a quick list of six tips that may work for you!

Tags: oop

Collection Filters in Ruby

There should be a filter object, and it should be placed between the user and the filtered object. Imagine you are modeling a person using a pair of glasses...