I was talking with a Cloudspace client the other day about engineers. He is a deeply technical individual, and his background is in the open source community. He made a very insightful comment that I wanted to share – although I’m going to let him stay anonymous unless he wants to claim credit for the comment.

A slight background: I’ve noticed that people with art degrees tend to be exceptional at taking feedback. A big part of any art program involves spending days or weeks making a piece, putting both time and mental energy/personality into it. Then you have to stand in front of a class while everyone (including the professor who determines your grade) tells you what they don’t like about it, what’s wrong, and what you should have done instead. This is painful – when people make something, they feel like a part of them went into it. When the thing gets criticized, it feels like they are also being criticized, and they have to pick themselves up and go onto the next project.

Engineers tend to come into the industry from another path. “Does it work?” is a common refrain. “It’s a hack, but it works” is how a lot of people start coding. There’s no emotion or opinion in this. The code runs or it doesn’t. The output is either right or it isn’t.

As programmers continue to grow, they develop to a sense of “best practices”. Best practices tend to be much grayer than “does it work, y/n?”. These discussion tend to evolve like “well if you do it this way, it means that long term you’ll gain benefit X”. For folks who have always used the binary metric of “does it work”, this feedback sometimes comes across very poorly – they internalize the feedback as an attack on them, the same way that a first year art student might.

The ability to be humble and take feedback constructively is a very valuable skill in many areas, but especially so for engineers who have to work with others. It is one of the marks of a professional engineer, as opposed to a weekend hacker. It also helps the person receiving the feedback improve their skills for the future, since they learn new things as part of the process.

This is where code reviews come in, and in the case of the person I mentioned at the beginning of the post, his open source experience. It’s not just any open source experience that counts (like releasing a piece of code under an open source license). His contributions were peer-reviewed. He had to stand by while other people told him the variety of ways in which he was not doing well enough. He said that he grew immeasurably as a result of this, and he continues to reap the benefits of this experience to this day.

The practice of working in a peer-reviewed team environment builds this character trait of separating the product (the code) and the producer (the coder), along with other benefits. I’m proud to add that Cloudspace does peer reviews of code, thanks to our team-based approach, and that our engineers have had their work accepted into other peer-reviewed open source codebases (like Rails Core).