There have been two interesting responses to the podcast I did with Om and Niall the other week. The first was Scott Johnson who responded in a podcast. As I expected, most people are taken aback by my statement to “let the engineers pick” what language and enviroment you use for your product. I think there is one important assumption that wasn’t articulated in that statement: you have brilliant engineers and you trust them. As a psuedo-engineer, I find it insulting when people suggest engineers are unable to factor anything other than their selfish language preferences, things like loaded costs, hardware costs, platforms, long-term viability, hiring, etc are simple variables that can be considered by any intelligent person. If anybody in Automattic came to me that was writing a tool in Python, C, Perl (it’s happened) or whatever, I might ask a question or two but at the end of the day I know they’re able to weigh the costs and benefits just like I would. If you’ve hired an engineer that isn’t able to make these decisions as well or better than you, then you’ve already lost the battle and over time more and more of your time will be spent plugging holes in a descent to mediocrity.
The second response was on the Pronet blog which in an amazing feat of blogging acrobatics managed to mention and link every single person tangentially associated with the podcast except me, even though I’m quoted in every heading. The Google Pages example is brought up again to illustrate that all the hardware in the world sometimes solve a scalability problem, but I still think that’s faulty because none of us had any idea why Pages was slow when it launched, it could have been a faulty router for all we know. Pronet responds to “Go with what your happiest working with” with a set of points to consider for a language, but again with the right people none of that matters. Happiness, in all things not just the language, should be the number goal and metric for everything in an early-stage startup. Happy engineers work smarter, longer, more efficient, attract better candidates, and have a better quality of life. (A corollary is that if you’re already set on a language path, don’t hire anyone who isn’t thrilled with working in that language.) For an example of how this can work in a really extreme case, I suggest everyone read the story of Viaweb and Lisp. (Another talk.)In my mind Lisp is a ridiculous language to build a web application in, but to them and their engineers it was heaven and they had better products earlier than their competition as a result of their unusual choice.
(As an aside, I wonder how many people said the same thing about Ruby for web apps before David Heinemeier Hansson, Rails, and 37signals, or even about PHP before Yahoo and Wikipedia? An example (and a little bit of promotion) is better than a thousand whitepapers.)
Smile.
. . . and Nod.
Matt,
I hope you don’t think that I meant anything with respect to you with my statements. I know damn well that you’d never fall into that trap but so many people have in the past I wanted to be clear.
And you’re definitely right about happy engineers.
Scott
Of course not, OS developers are used to flaming each other to a crisp and getting beers afterward. 🙂
That’s bizarre. I mean, I know you’re associated with competing products and all, but to use your words as the subheadings (and really, as the whole theme of the article) but not even mention your name is just plain weird.
At any rate, I enjoyed the podcast, and found myself talking along with your answers regarding optimization (yeah, I talk back to podcasts, deal with it).
That’s funny, I was thinking the exact same thing 🙂
Matt, you are correct, I should have mentioned your name and given you credit for the advice you gave in a podcast I enjoyed listening to very much. I was cautious to mention your name if only in fear of invoking “Nerd Fight!” in one of my favorite rags. 😛
The only thing I didn’t feel got adequately addressed was the issues with Google Pages. You are absolutely right, we don’t know what happened. It could have been a faulty router. But I personally have a real hard time believing that, because from what I know of Google Network Engineering, a single point of failure like a faulty router is not something that is very likely. But what do I know? Certainly not what happened. But man would I like to! Perhaps Google would like to share? Not bloody likely. Tsk. Tsk.
In regards to letting engineers choose their programming languages – I actually agree with you. But I also believe that leadership and those with the most experience should be at least tangentially involved to ensure that the engineers are thinking through the problem set completely. But I am operating under the assumption that the engineers are relatively junior…
Anyways, I enjoyed listening to the podcast very much – enough so that it inspired me to share my own thoughts on the subject. I am sorry I didn’t give you the link love. It honestly was not personal.
Did someone say “beer?” Hell, I’ll buy you a beer. Let’s go. 😀
Oh, c’mon, let’s have some perspective. You’ve got the word “Matt” linked to your site on pages all over the web; One single blog post won’t make a difference either way. And Mark, given that we’d probably be called to task whether we omitted Matt’s name or included it, there’s probably no way for us to participate in the conversation without somebody getting bothered. Heck, even you called out in bold that Byrne mentions our coworkers… on our own blog. What’s up with that? OMG scandalous respect for peers!
As much as I’m glad to have a dialogue around any interesting topic, I’d be even happier if it was more productive. Matt, you’re both the featured interview in a respected podcast and quoted in a fairly well-read blog, and it helped prompt a solid conversation: Be happy, instead of looking for slights. David Hansson and Cal Henderson were both omitted in the same post, both in name and in link, and so far they’ve been able to suffer the indignity somehow. 🙂
Good post, Matt, and timely. Here are some ramblings I had a while back on this same subject:
http://www.scottburkett.com/index.php/technology-leadership/2006-03-20/the-very-model-of-a-modern-major-er-technologist.html
Cheers.
Scott
Thanks for dropping by Anil, that sentence wasn’t really the meat of my post, just an aside mostly in response to a comment someone had left earlier. DHH and Cal are mentioned, not actually in the podcast. A link or mention isn’t a big deal, but sentences like “In this podcast, Om and Niall provide a great primer for people just getting started in building a scalable applications online” probably threw people off or lead them to suspect some sort of deliberate self-censorship. I don’t know myself, because I didn’t notice until a few people had pointed it out to me.
More importantly, what are your startup dos and don’ts? We have to atone our non-productive words.
Heh, these days my startup do’s and don’ts aren’t really about technology or scaling or any of the stuff that’s been mentioned above. I should really think it through enough to do a longer post, but one of the things I’m kind of surprised by is the lack of ambition of a lot of efforts today. Like, don’t set a goal of being “the fourth most popular application for tagging podcasts on mobile devices”. Try to change the world! I think that’s my “do”, “try to change the whole world”.
That might not be the answer you were asking for. 🙂