Neat advice for programmers from an application writing perspective, but it made me consider something else that I think might have value as well. I'm one of t

Neat advice for programmers from an application writing perspective, but it made me consider something else that I think might have value as well. I'm one of those people who started out writing code but ended up taking on more of a management role. I like to think of myself as being cut from the same cloth as Rands (randsinrepose.com), in that I'm reflective of the programmer's point of view when I engage in management practice. One thing I've noticed in the HN community, and the technical community at large, is that "idea" people are often dismissed out of hand. Don't get me wrong, the vast majority of ideas that "beginners" pitch are ill-informed or naive to the point that the idea is just unusable, but occasionally, you'll come across a rare gem contains some insight that is outside the reach of a master. The key is that the beginner very rarely frames their ideas in the language of the programmer, so we have a tendency to simply check out of the conversation. I like to engage idea people and use them as a springboard for ideas. They're often so excited to talk to someone who they know can make their idea happen that they'll take direction from you. Then again, they're sometimes completely hard headed and stuck in their idea rut. As the master, you get to decide who you want to engage and who you don't. I've worked hard on building my skills at gaining trust and guiding the conversation with idea people. I find that if you open your mind and listen, you can extract the valuable parts from their ideas, reframe them in the language of the programmer, and become a facilitator of great ideas that otherwise wouldn't get traction.