Lessons Learned for Getting Better Results from Developers

This is an excellent list, and I would love to work with someone who ascribes to it. I also find it a very depressing list, because almost all of those items involve an awful lot of effort. It's really hard to imagine many people even half-way living up to it. It ends up making me think of the times I've done projects for people who have done just about everything the author is cautioning against.

I manage a team of 6 software engineers, and while I like most of this list, I think #3 will only work for a small team and small-medium projects.<p>If I took most of the burden on to myself to do the work my engineers don't like I would be a major bottleneck.<p>Alternatively, what I like to do, is couch and encourage my engineers through these less savory tasks so they can get to the development as quickly as possible.<p>Edit: You could also argue that it might be worthwhile hiring a business analyst, but I haven't had much good experience with BAs.

"designers speak human and developers speak computer."<p>I hate this generalization because it can be used as a blanket dismissal of a developer's opinion.

Pretty good list but I think the author contradicts the notion and importance of iteration. No design doc and no code base is free from changes and improvements, particularly in startups. If you can't deal with changes, you probably should go work for an enterprise company where you spend half your time blowing hot air across the table. You can't just write once and leave it be, the problem with design mockups and wireframes is that they don't really encapsulate the element of interactivity, and certainly lack customer feedback.<p>I also think designers and developers are very much alike even though we often bang heads. It's a creative process to write code, and I think a lot of people outside the circle don't appreciate how mentally draining "creation" really is.

When I read this title, the first thing I thought was, "Oh no, another poser telling the rest of us what to do based on what they <i>think</i>".<p>Boy was I wrong about that. This is an excellent post that could have only been written by someone who has suffered in the trenches and knows what he's talking about.<p>Many of his points:<p><pre><code> 2. Get in bed with the business people 3. Ease their pain 5. No one gives a rip what the artist thinks 6. You get to control those lovely details 7. Write it down, write it down, write it down 8. Get in bed with the QA team 9. You have to have a middle man 10. Proximity breeds understanding 11. Learn to articulate well </code></pre> emphasize that the people part of the process is just as important as the technical part. This is easy to overlook and we need to be reminded every once in a while. The main reason we do what we do is not because it's cool (it is), we do it for and with other people.<p>The only point I challenge is "4. Force business to iterate in design, not in development." This is perplexing because it runs counter to most of his other points. The reason people tend to iterate in development instead of design is because it's much easier. They're not sure what they want, but once they see something, they know what they like and don't like about it. I'd alter #4 to something like, "Learn to prototype well, so everyone is equally comfortable iterating toward the most desirable outcome."

Very good, the first item is "Be a developer", the author gets it.

"If you need an artistic outlet, do it at home, or you’ll always be bitter."<p>This is equally true for developers.