Back at MusicIP, things were getting a bit hairy, coding reinforcements were needed. I call Larry. Doesnt matter that he wasnt up on the exact stuff we needed. Doesnt matter that he was in Canada and the core programmers are in California. All you had to do was read the guys blog, check out his code, and you could get a reasonable idea of what he could do. And after you meet the guy in person your expectations are exceeded.
After a quick call/phone interview, we flew Larry out to California for an intense 15 day get up to speed, code quick, learn fast, adventure. Larry dived in and I am using a freshly coded version of something he coded as I type this. The guy is a rock solid professional and, for bonus points, a super nice guy.
As a result, we have some new products and a trusted member of the MusicIP team. Larry makes a good recruiting poster for getting in there and just coding something.
Yeah yeah I know it seems like I pitch blogs as a universal panacea. I have cited them as an essential recruiting tool before.But after reading this post from John Montgomery, where he asks how to interview a developer, I couldnt help thinking why are you interviewing anybody?
Don’t you know who would be great for the team already? If not perhaps you’re spending too much time in meetings talking to Microsoft people, and not enough time reading blogs by outsiders.
Compare and contrast with this story from Rick Segal.
On that final point, it may be that Tuscany needs to be about “just coding something”, rather than spending a ton of time in a formal requirements gathering process. If Microsoft is going to build a “Writely for software development” you need to forget most of what you have learned at MS about software development processes. Who are the outliers that will help you with that exercise in amnesia? A lot of them probably have blogs.
That said, you need to worry less about scoping the product and more about just coding something. If you get something cool online then top notch coders will come to you and start building to the framework… Developers love to solve problems. If you have some code in place, which does one thing well, why not get your “interviewees” to quickly extend that code to do something else well.
You need to make blogs and source code part of your hiring process. Fewer meetings and formal HR processes, and more getting things done.