Check out this interesting interview on Technometria with Joel Spolsky (from Joel On Software) on Hiring Technical Talent. I like Joel’s philosophy of focusing on the people causing great things to happen. Definitely a must listen for managers.
One podcast I listen to pretty religiously is the Entrepreneurial Thought Leadership podcast from Stanford University. Recently, Shai Agassi, formerly of SAP gave a talk called The Physics of Startups, which was very interesting.
There were a couple of things that stuck with me out of this talk:
- Money for a startup is like air. You shouldn’t be concerned with it unless you are in a vaccuum. In other words, money can’t be the reason you are in business.
- The difference between ‘success’ and ‘failure’ for a startup is microscopic. The difference between a Yahoo or Google and a failed startup could be just a matter of a few days
- Startups need to use the “gravity” of larger companies to stay alive.
- If you are working on anything Web 2.0 right now, its not new anymore. He compared it to a surfer catching the back of a wave. They don’t do it because all of the energy is gone by that point. “No one every caught the back of a wave and hit shore”. You need to catch a wave at its start, to utilize all of its energy. So surfers make a “bet” that the coming wave has the energy to get them to shore. The quote he uses is “If its already in WIRED, its already too late”.
It was a very interesting talk. Check it out if you have some time.
Dave Fayram sits in with Cote this week on his podcast talking about Rails backends. This was all interesting, but what really caught my ear was the last 11 minutes or so of the podcast, where Cote and Dave start talking about using OS X in businesses, and Dave describes his all Mac office and brings up the use of Bon Jour as “their own personal twitter server” and the use of dashboard widgets to perform work in context, much of what I was thinking about when I wrote Metrics As a Side Effect last week. Its cool to see that other people are thinking about this stuff, and a shame that businesses are so stuck in the “business use” of Windows that we cannot take advantage of some of the ultimately cool things available on the Mac to increase personal productivity, such as the dashboard, Growl, and Rendezvous.
It was interesting to hear Dave talk about how “beautiful” their infrastructure is, because they have been able to focus on things aside from security, VPN, notification frameworks and the like because a lot of the things that infrastructure folks spend most of their time on are taken care of already on a Mac network.
I have to say, I am at least 5x more productive at home on my Mac than I am waiting 15 minutes for my Windows machine to boot and log into the network in the office. I tend to do my most important work off hours now, just to be able to work on a more intuitive and easier to use machine. I feel like I can concentrate more on the problem I am working on than how to do it, which again, tied into the whole Rails conversation for me.
Very interesting discussion. Excellent content. I highly recommend this one.
I found a really good podcast called The Agile Toolkit Podcast, in which the host, Bob Payne, attends agile conferences and interviews people there. Some of the interviews include people like Bob Martin and Mary Poppendieck among many others.
For me, I think I found it interesting just in the fact that it is nice to hear someone that has the same views on development issues as I do. I’ve always been a big believer that methodologies are limiting and that each methodology should be tailored to the project team. One part of the conversation that I found extremely interesting was when Bob and Dave were talking about the dogma attached to many of the methodologies.
Recently I had attended an Agile Development training in which the instructor stated that if you weren’t using all of the components of XP, you weren’t doing Agile development. A good point that Dave made was that as XP was being developed, the teams it was being developed with actually evolved into using all of the practices at different stages of their team development. In other words, they didn’t start using all of the practices specified in XP – because they didn’t exist yet. Dave makes the point that teams need to evolve into all of the practices – and that its very difficult to implement all of them at one time. I actually think that each team will be sufficiently different enough that you may not need all of the practices, but only a core set of practices. Bob Martin also makes this point in his interview and lists the minimum set of practices that include very short cycles, an open office (a room which holds the identity of the project), test driven development (both unit and acceptance tests). He also mentions that its extremely difficult to do test driven development without continuous integration, so there are other practices that will be necessary as you begin to implement the minimum set. I actually believe that source control and automated builds are another of the core minimum practices that should be put in place before anything else – but thats just me.
Another area that Bob and Dave talk about extensively is the necessity of developers to look at other languages in the industry other than the core language they use day to day. One statement Dave makes is that he looks forward to the day that developers refer to themselves as “developers” rather than “Java developers”. I wholeheartedly look forward to that day as well.
I’ve always enjoyed learning new languages. If you run through the articles in this blog, you’ll see that every time I find some language that I don’t know – and understand the practical reasons why they exist, the chances are I start working in it right away (most recently, this language is Objective-C). I enjoyed this part of the conversation a lot, because Dave articulates very well how learning new languages can give you new insights as to how to implement things in different ways.
I’m a firm believer that in software development, you have to have a pretty large tool box. The right tool should be used for the right job. This is why in many of the things I’ve done over the years, different components are written in different languages depending on what I am doing. A web piece might be written in PHP, scripts done in PERL or Python, while other components could be written in C / C++. I’ve made a conscious effort over the years to expose myself to as many different languages as possible.
In order to have the flexibility to use the right tool for the right job, you really have to make an effort to get at least a high level understanding of the different tools available and what their strengths are. Thats the really nice thing about the conversation with Dave is that he articulates the idea that you don’t necessarily have to be an expert in all languages, but know enough to use them and glean knowledge from them and their design.
I have found each of the shows I’ve listened to from the Agile Toolkit Podcast very informative and totally worth the time investment. In the very least, I want my teams to make this a part of their learning program moving forward. There’s no better place to learn about Agile practices than from the people right in the middle of it.
There is a great talk by Googles Marissa Mayer on the Stanford Entrepreneurial Thought Leaders podcast (see the Spring 2006 section). Marissa talks a lot about Googles culture and what makes them a great place to work. There are some GREAT things in this podcast. A must listen!