"How to tell people their code is bad"

While reading the book Microsoft .NET: Architecting Applications for the Enterprise (Esposito & Saltarello, 2nd ed), I find quite interesting when they speak about this topic..

Because let's face it: architecting in an enterprise is much more than just doing the architecture, fighting with inconsistent requisites and meeting deathlines ;). It's -among other things- also about dealing with developers. As architects are some kind of  technical leaders, I've noticed they must be seen as some inspirational developer. Someone who not only knows and leads the coding aspects, but also someone who can guide other developers to enhace themselves, to write better and less dirty code. But we all know how difficult can it be to tell someone that their code isn't good, or even not good enough. In my personal experience, junior developers are open minded to enhancements, but semi-seniors and senior are most of the time very difficult to get through.

Well, what this book says about it is no key of the universe, but very usefull and easy to keep in mind: instead of telling someone that the code he/she wrote it's not good -and here I mean whatever nice way to tell this- it could be much, much better to ask him/her subtly why was the code written in this way. Maybe in a humble way of meaning "I don't really get what you did, but I'm really interested in it."

You can be suprised of knowing what was it, that toke that person to solve a thing that way. It can be lack of time, lack of knowledge or just a new point of view that you dind't consider. If you think it could be better done in other way, you can tell the developer.... but not as a correction, rather as an opportunity to enhance his or her knowledge.