Hacker News new | past | comments | ask | show | jobs | submit login

The point can be that the team can do it BETTER. If you run Sonar on a codebase and get 10K serious findings... then the code certainly is not optimal. There is no upper limit on how optimial it can be, but you'll certainly have an easier life and a better end product if you've followed best practices as opposed to "just getting it done" by the most junior, lowest payed code monkeys possible.

Then by all means improve or replace bad code and create an environment that will encourage devs to learn from previous mistakes and improve.

All I am saying (and I think the author tries to make that point) is that it is questionable that you are going to create such an environment by pointing fingers and treating devs bad.

My very limited experience (I am the mobile lead in a company) has taught me, having done all of that myself in the beginning, that I wont achieve anything this way.

What I saw is that people got defensive by default, protective about their work (so no one can attack them for errors they made), the company started bleeding talent (what person is going to like working in such an environment?) and so called "code monkeys" never improved, because they didn't believe that they could achieve anything meaningful by themselves.

For some companies this might work in a way that I can't understand, but I changed, because frankly I didn't like to work in such an environment myself, and it did have to some degree positive effects.

People share more information, there's less pressure generally and there is more trust in general that everyone is doing their best, and if unable to complete some task, will ask for help.

By the way, here's a Google I/O talk from 2010 about engineering leadership that covers the problems mentioned in the article - I cannot recommend it enough: http://www.youtube.com/watch?v=skD1fjxSRog

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact