Things I Learnt The Hard Way - Design Patters Are Used to Name Solution, Not Find Them

Most of the times I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.

Read more  ↩︎

Things I Learnt The Hard Way - "Right Tool For The Job" Is Just To Push An Agenda

A lot of times I heard "We should use the right tool for the job!" Most of those times it was just a way to push an agenda.

Read more  ↩︎

Things I Learnt The Hard Way - The Right Tool Is More Obvious Than You Think

Maybe you're in a project that needs to process some text. Maybe you're tempted to say "Let's use Perl" 'cause you know that Perl is very strong in processing text.

But that may still be not the right tool.

Read more  ↩︎

Things I Learnt The Hard Way - If Your Data Has a Schema, Use a Structure

You may be tempted to use a list (or tuple, if your language allows) to keep your data if it has, say, only 2 fields. Don't.

Read more  ↩︎

Things I Learnt The Hard Way - It's Better To Let The Application Crash Than Do Nothing

Although that sounds weird, it's better to not add any error handling than silently capturing errors and doing nothing.

Read more  ↩︎

Things I Learnt The Hard Way - Types Say What You Data Is

Memory is just a sequence of bytes; bytes are just numbers from 0 to 255; what those numbers mean is described on the language type system.

Read more  ↩︎

Things I Learnt The Hard Way - If You Know How To Handle It, Handle It

If you know an error can occur, then you should handle it properly, instead of ignoring it.

Read more  ↩︎

Things I Learnt The Hard Way - A Language Is Much More Than A Language

Picking a programming language is much more than just picking the words that will generate a code. They come with a community, a leadership, an ecosystem and a thread the binds them all together.

Read more  ↩︎

Things I Learnt The Hard Way - Don't Use Booleans As Parameters

When you're designing a function, you may be tempted to add a flag (a parameter in a function that it is a boolean). Don't do this.

Read more  ↩︎

Things I Learnt The Hard Way - If A Function Description Includes An "And", It's Wrong

Functions should do one thing and one thing only. I clear indication that you're breaking this principle is the need to add an "and" in its documentation.

Read more  ↩︎