This is the 53rd episode of the StackOverflow podcast where Joel and Jeff sit down with Wil Shipley of Delicious Monster to discuss the shifting sands of Apple and Microsoft APIs, the value of software development conferences, intuition versus empiricism for developers, and "parrot programming".
Like all the coolest developers, Wil wrote a web browser. And he's not shy about mentioning it!
Wil and Joel reminisce about NeXT computers, Steve Jobs' gig after he was unceremoniously ousted from Apple by John Sculley. Wil wrote a lot of Objective C for NeXT before it was popularized on the Mac.
We complain about the fact that Microsoft seems to release a new framework every other year that seems to obsolete the previous framework, as famously documented in Joel's article How Microsoft Lost the API War.
Joel announces Stack Overflow Developer Days, in the platform agnostic spirit of the site. Five cities, a great set of speakers from many different disciplines, one day, $99. And yes, we're trying to get Wil Shipley to speak at the San Francisco leg.
Wil has some fantastic advice for software entrepreneurs -- witness his presentation How to Succeed Writing Mac Software (pdf). It motivated at least one developer to enter the priesthood.
Some thoughts on the utility of conferences for software developers. You should probably try to go to one conference per year, either because you're interested in the speakers, or you're interested in networking with other programmers. Beyond that, the benefits are unclear.
Wil notes that WWDC is a unique opportunity to get a lot of your detailed Mac programming questions answered by the people who wrote the APIs. Remember, one of the biggest reason to attend these conference is to hang out in the hallways with your fellow developers!
I don't think the legendary Apple secrecy is a good strategy for a developer platform. Witness the absurdity of the iPhone developer NDA.
On the other hand, all those developers who learned about WinFS at Microsoft conferences from 2005 to 2007 must be a little cheesed that the feature never shipped. So it is possible to talk about stuff too early.
Is excessive reliance on unit testing a case of Empiricists versus Intuitionists, as dramatized in the book The Intuitionist? As you get more years of programming experience under your belt, you could argue that you have a (slightly) better "spider sense" of what the problem areas may possibly be in your code. Ideally you should use both empiricism and intuition, of course. Nobody programs using the force. Well, except for Knuth.
Even a programmer as experienced as Wil occasionally runs afoul of the First Rule of Programming: It's Always Your Fault. His anecdote involves writing an email to a VP at Apple, though. Humility is often the best approach; "I think I'm doing something wrong here, can you help me figure this out?"
Joel says no question is too simple for Stack Overflow, and we discourage people from responding with RTFM or "too trivial to even ask". These questions may be simple, but think about each question in terms of future programmers who might encounter this question; is it relevant enough to the world to help them, and not just the one guy or gal with that one ultra-narrow question? If so, then it's worth asking.
Joel calls it page faulting in knowledge. Wil calls it "parrot programming": newbie programmers who don't really understand what they're doing, but occasionally get a search result cracker, so that particular programming behavior is rewarded and reinforced. This is why we encourage neophyte programmers to buy a few key programming books, so they can underpin their giant heap of randomly page faulted knowledge with deeper principles and concepts.
We answered the following listener questions on this podcast:
Kris: "What are your thoughts on the value of attending conferences?"
Clay: "As you become a more experienced programmer, do you use more intuition as a part of your decision making?"
Our favorite Stack Overflow qustions this week are:
- Objective-C: what does @private mean? Is this question too simple to be asked?
If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to firstname.lastname@example.org. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879.
The transcript wiki for this episode is available for public editing.