Hands

That piece is called hands and yes, it is made of LEGO® bricks. Thousands of blocks painstakingly arranged to express an emotion deeply personal to the artist Nathan Sawaya.

We need to work with the tools we have; you can paint a wall with a hammer or build a sculpture out of LEGO. The end result is always a painted wall or sculpture. The trick is in the approach.

It takes as much time as I have. Some sculptures take hours, some take days and some take months.

Nathan Sawaya, http://brickartist.com/about/

I suck at writing code alone, I get bored or I get rushed by perceived deadlines. So I take shortcuts.

Look at this kid.

Awesome Baby

Smart kid. Right?

That is what we do; we look at solutions like that and praise them.

But was that really a good solution? That depends on the problem. Was the problem to get the square peg into the bucket or was the problem pairing shapes with holes?

Path of least resistance is the norm. The problem being that the simplest path for someone might be the most difficult for someone else and vice versa. The way to alleviate this is to work with and not just in your team.

The way to alleviate this is to work with and not just in your team.

As a developer there are a few places common to many processes that are really good for this.

Code Reviews This is a very common practice but is often completely broken. If you go through a code review without a single change being made something is wrong. If you go through a code review and you have to go back and fix things you should not feel bad. You should be happy because that means that the code you are about to go and fix will be better than if you had written it alone. You have not failed.

Planning Sessions This is where you can be sure that you are working on the right problem and are choosing the best solution. Don’t rush through planning sessions earmarking problems for yourself. Take time to talk through the problem and the solution certify that your understanding of the problem and solution is the same as your team.

Pairing This is what works best for me. Having another dev right next to you throughout the whole problem solving process is invaluable. At any time you can be sure that your pairing partner understands what you are doing and vice versa. Taking shortcuts becomes harder because you can only take a shortcut if you convince your partner to take the shortcut. Pressure is less daunting because you share it with your partner.

If you ever feel like your tools suck take a step back, look at the problem and discuss it with your team.