The Stack Overflow Podcast

The Stack Overflow Podcast

By The Stack Overflow PodcastSociety & CultureBusinessTechnologyManagement
Download on the App Store

The Stack Overflow Podcast episodes

  • Podcast #61
    In this episode of the podcast, Joel and Jeff sit down with Miguel de Icaza of the Mono project to discuss Mono, Silverlight / Moonlight, and the pros and cons of open sourcing your code.
    Miguel is one of the lead developers on the Mono project, which is an ongoing effort to bring the .NET framework to Linux and other non-Microsoft platforms.
    Miguel characterizes Silverlight (known as Moonlight on Mono) as "the good parts" of WPF. It's a newer way to build a cross-platform GUI app, an alternative to GTK and Windows Forms.
    A brief discussion of the implications of cross-platform GUIs, which lack that native flair. Do you have the manpower to maintain three distinct versions of your GUI application -- one for Mac, one for Windows, and one for *nixes? Do only programmers notice the subtle differences?
    Revisiting Fitt's Law, and applications and operating systems that don't make good use of it. Certain areas of the screen, mostly the top and bottom and to a lesser extent the sides, are infinitely large, and should be used prominently in the UI to leverage Fitt's Law.
    Mono runs on the iPhone, through the Unity game engine! This was challenging for the Mono team to develop, because interpreters and runtimes are explicitly disallowed in terms of the iPhone SDK. Mono had to be converted from a JIT to a static compiler.
    Per Miguel, programmers wanted Mono because Objective-C is fairly primitive in memory management and requires a lot of repetition and boilerplate. With Mono "this is all taken care for you", as a higher level language.
    Due to concerns within the free software community, Microsoft made a legally binding promise that it will not enforce patents against Mono -- for the core framework.
    It turns out that the Microsoft Office 2010 web component, which is free for consumers, is 100% JavaScript + HTML. If Silverlight wasn't required to pull off Office-in-the-browser by Microsoft itself, is Silverlight really necessary in the bigger scheme of things?
    Miguel divides the world into PutPixel Programmers and printf programmers. Which type are you?
    Some big game projects that use Mono for scripting: Second Life, and The Sims 3. Also, a very large social networking site I can't mention by name was recently ported to Mono.
    One of my long term 5 year goals is for the Stack Overflow discussion engine to become a go-to choice for public internet discussion, on par with phpBB and its kin.
    Miguel offers his insight into the controversial discussion of whether open sourcing Stack Overflow would destroy our business model.
    We actually have contributed one open-source component of Stack Overflow back to the community -- the Javascript WMD editor. Also, we provide all of our question and answer content back to the community licensed as cc-wiki.
    Our Stack Exchange hosted solution will offer free versions for non-profit organizations, and we're also looking at provided an ad-subsidized version of it as well.
    Miguel de Icaza is also a Stack Overflow user -- with 22 answers and 3,484 reputation.
    Check out the Mono Migration Analyzer, which will tell you how easily you can (or can't) port your .NET project to Mono and run it on other platforms. Please do, because feedback from this tool is used to prioritize future Mono development!
    Miguel committed to speaking at the Boston Stack Overflow DevDays and presenting some of the same Mono goodness he talked about here.
    In other Stack Overflow news, the Super User semi-public beta is now open. Come join us!
    Our favorite Stack Overflow question this week:
    Is Mono ready for prime time? but of course! See for yourself with a new Mono Visual Studio plugin!
    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 [email protected]. 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 que...
    1 hr 12 min
  • Podcast #60
    This is the 60th episode of the StackOverflow podcast where Joel and Jeff discuss the value (or lack thereof) of meta-discussion, how much "big iron" popular websites need, and whether code forking is sometimes inevitable.
    A discussion of our newly launched outlet for meta-discussion at meta.stackoverflow.com. We view this as a pressure release valve. Why is meta-discussion necessary? What purpose does it serve, and for who?
    Joel and I are both headphone enthusiasts. It's also a key part of the programmer's toolkit for getting "in the zone", so it's worth investing in this area. A quality set of headphones can deliver an audio experience equivalent to floor-standing speakers worth thousands of dollars!
    After three logo contests, we are becoming experts in crowdsourcing design. There is a risk here when people don't know what criteria they're supposed to be judging on. Joel brings up the point of televisions which all have a "store mode" which maximizes brightness and contrast to the actual detriment of the overall image quality. And if you use a LCD at its out of box brightness (always the maximum) you're going to go blind!
    We took the plunge and upgraded our database server to its maximum of 48 GB of memory. This is mostly a cheap form of insurance against future growth. We may also end up taking advantage of SQL Server's database compression. The old memory will be eventually used in a second database server we anticipate needing by the end of the year.
    I was spurred on to do this after reading about the massive 512 GB monster server that Plenty of Fish bought. It's interesting how the cost of "free", at that scale (they're a top 20 website in the US and Canada), is no longer cheap. Joel points to a scathing New Yorker review by Malcolm Gladwell of Chris Anderson's book Free, which covers similar topics.
    As Joel notes, paying $100,000 for a server could be more effective than spending $100,000 for a year's worth of programmer time to convert your database from single and monolithic (the traditional, classic SQL / Oracle model) to sharded (Hadoop and BigTable).
    Twitter, for example, has moved to an almost all in-memory database architecture. The downside is that it is literally impossible for me to get to any of my Twitter messages older than the middle of 2008. Still a fan of twitter, though; it's actually useful. Consider the story of an indie musician who made $19,000 in 10 hours on Twitter, while netting exactly $0 from 30,000 traditional record sales.
    What are the ethics and legality of using code from one job on a different job? If you get a job as a programmer and you never signed anything, then you own all the code you wrote. Most employers sign a Work for Hire agreement which means they own all the code you write while on the job.
    Should Stack Overflow be eventually open-sourced? Joel is concerned that open sourcing the code would interfere with the hosted product Stack Exchange that Fog Creek is building out right now. I don't see a conflict between these two audiences; one has infinite time and no money, and the other wants a turnkey, "it just works" solution for a reasonable price.
    Joel thinks that hosts deploying open source software crash the business model down to the cost of the hosting itself. I wonder how companies like Six Apart (of Movable Type fame) continue to survive if that is the case. And eventually, won't someone create an open source clone of what you're doing anyway? Why not beat them to the punch and take control of the situation, by open sourcing the real thing yourself?
    I continue to have deep skepticism that the hosted Fog Creek version of Stack Overflow cannot avoid a serious fork with our code. The audience of the ad-supported general internet, versus the audience of paying customers building topic-specific 'stacks, is very different. Can version control tools save you when you're building the "same" products for such different audiences?
    We answer...
    1 hr 9 min
  • Podcast #59
    This is the 59th episode of the StackOverflow podcast where Joel and
    Jeff sit down with Damien Katz (of CouchDB) to discuss non-conventional databases, non-conventional programming languages, and taking on non-conventional programming projects.
    Stop, do not pass go, do not collect $200: watch Damien Katz' outstanding Rubyfringe presentation, CouchDB and Me. It is a hugely inspirational presentation for any working programmer. I can't recommend it enough. Go watch it now!
    We have forgiven Damien Katz for working on Lotus Notes. Mostly. To his credit, he did write some very cool code, as documented in his famous formula engine rewrite.
    You can think of Damien Katz' CouchDB project as the distilled "good stuff" from Lotus Notes. Wait! Why are you running away? Come back! It's not that bad! We swear!
    Damien used Erlang to build CouchDB, largely because it makes error recovery and multiprocessing so much easier. Or as Damien says "what happens when everything goes to s**t". In other words, networking fails, or you don't have enough memory to complete the operation. This is stuff that is very tricky in C++, but almost trivial in Erlang.
    CouchDB took off when the JSON and JavaScript bindings were produced -- and were a big hit. This probably says something about trying to popularize your open source project: is it accessible to the average programmer?
    On Damien's journey as a software developer: "eventually you get tired of working on stuff for other people."
    The negotiations with IBM included the synonyms "douchebags" and "vapid bureaucrats". They seemed to appreciate his honesty (at least for the set of bad eggs he's referring to), and Damien is a guy who has spent some time in the bowels of IBM and knows what he is getting into.
    I liked that Damien, when he reached analysis paralysis in the middle of his project, turned to the soothing, calming midwestern voice of Steve McConnell -- and the classic (and my favorite) book Code Complete 2.
    While building up two new 1U servers for superuser.com, powering on the server with the cover off would trigger the Moro reflex in our 3 month old baby... two rooms over! That's how loud they are. REALLY loud. I was happy to have UPS take those out of my house.
    I didn't appreciate how much happier I would be with community moderation -- I am unburdened from being the judge, jury, and executioner of the occasional serious misbehavior. It's a group discussion now -- thanks to our awesome community moderators, we can reach a concensus together!
    What does it mean for an open-source project to be version 1? Version 0.1? Version 0.5? When is it good enough to use? Should you look at commit activity; is the project alive? Or should you look at how many people are actually using the software, regardless of version number or commit activity?
    If you're a developer, and wondering what specific problem CouchDB could solve for you, Damien says: "would the data you have typically be stored in a document in real life?" The classic example is a contacts database. Do you have a phobia of storing large blobs in a database?
    I think most hardware-oriented software developers have gone through this thought process at least once: "Hmm. I have gobs and gobs of system memory. Do I really need a swapfile on disk any more?" Don't try to outsmart the operating system designers, unless you're an operating system designer. And that goes triple for programmers who think they are language designers!
    We answered the following listener questions on this podcast:
    Maayan: "What is your stance about using open source software in production code, when the open source project in question is working, but is either below 1.0 or is not actively maintained?"
    Our favorite Stack Overflow questions this week are:
    Can I do transactions and locks in CouchDB? A brief discussion of how this works in CouchDB versus a typical SQL database.
    Any benefit or detriment from removing a pagefile o...
    1 hr 8 min
  • Podcast #58
    This is the 58th episode of the StackOverflow podcast where Joel and Jeff discuss HTML encoding, designing "safe by default", whether a question can be too simple, and the art of beta testing.
    Joel wonders if doing his Visual Studio development in a virtual machine is a viable solution. I say in this era of cheap 8 GB RAM and quad core CPUs, why not?
    As always, Naming Is Hard. We're struggling with naming the hosted Stack Overflow that Fog Creek is working on. Joel likes the name "Stack Exchange". It's not bad, but we wonder if anyone listening has a better idea?
    I admit, finally, that Joel was right about something. Don't HTML encode data that's stored in your database! Take the good advice of Damien Guard and Joel Spolsky! You can choose to store both representations, but don't store just the HTML; go with the raw data at the highest level of precision.
    A brief political rant about the evil of view engines that fail to HTML encode by default. The problem with this design choice is that it is not "safe by default", which is always the wrong choice for a framework or API. Forget to encode some bit of user-entered data in one single stinking place in your web app, and you will be totally owned with XSS. Believe it. I know because it's happened to us. Multiple times!
    Joel maintains that, with a strongly-typed language and the right framework, it's possible (in theory) to completely eliminate XSS -- this would require using a specific data type, a type that is your only way to send data to the browser. That data type would be validated at compile time.
    We continue to ramp up on our computer enthusiast site, superuser.com -- we just launched a logo design contest at crowdspring. This will be as close as we ever get to an "anything goes" website, and I'm excited to see what happens.
    I maintain your online behavior shouldn't be all that different than your general public behavior. I say "don't post anything you wouldn't want your mom to read." Joel cites the Wall Street rule: "don't ever write anything you wouldn't want published on the front page of the Wall Street Journal." Also, systems where people are able to behave as if nobody is watching are fundamentally broken systems.
    Joel says that the only bad simple question is a duplicate simple question. I say simple questions are OK as long as they're actually interesting (in some way) for other users to consider and answer. To prove his point, Joel actually asks the question on Stack Overflow: How do I move the turtle in LOGO? Do you think this question adds value?
    Some ruminations about the challenge of asking questions when you are a total beginner and not even sure what you should be asking. Perhaps the best solution there is "screenshots", or in code parlance: just shut up and show us the code!
    Beta testing is an art, and perhaps the first beta test barrier is if people can actually understand whatever the heck it is you're trying to do. There's often a disconnect between what beta users say (particularly gung-ho early adopters who love betas) and what typical users do. Unfortunately at the early beta, you lack the one thing you'd benefit from most: lots of usage data!
    The absurdity of the term "Content Management System". It's for, y'know, managing.. content. What does this even mean? Trying to be everything to everyone means you solve nobody's problem particularly well. Maybe this is why Fog Creek's hosted FogBugz is not attempting to expand thematically beyond their core business: software bug tracking.
    Remember that random NTP server that Joel ran into? They're back -- and they made a slightly .. uh.. disturbing .. theme song for us! Thanks! We think!
    We answered the following listener questions on this podcast:
    Joseph: "Now that you have the jobs connection up and running, how do you think that will affect the questions and answers on the site -- that some future employer might see what they're doing?"
    Frank: "What are your th...
    1 hr 5 min
  • Podcast #57
    This is the 57th episode of the StackOverflow podcast where Joel and Jeff discuss the relationship between speed and skill, iPhone development, and the value of programming fundamentals.
    Joel comments on the surprising correlation between how fast you can solve a simple problem, and your overall skill level as a programmer. This is why giving even a very experienced programmer a simple problem can still work. If you can't truly master the fundamentals, it's hard to work at higher levels of abstraction.
    We agree with Paul Graham: in general, there tends to be a correlation between the length of a response and its quality. We've also observed this pattern on Stack Overflow. It isn't always true (TL;DR), but it's a verifiable pattern. Either be the first and quickest, or be the best and most comprehensive!
    Due to high demand, five new cities were added to the Stack Overflow DevDays: Boston, Austin, Los Angeles, Cambridge (UK), and Amsterdam.
    I was quite impressed with the striking design Mike Kus put together for the Stack Overflow DevDays website. He breaks it down step by step for us. Like most programmers, I'm a terrible designer, but at least I know what's good enough to steal!
    As promised, we released a creative commons data dump of all the Stack Overflow data including all questions and answers. We're excited to see what the community can do with this data; Brent Ozar put together a data mining video to get people started.
    Stack Overflow has become a very popular destination for iPhone development. This is completely accidental, but it is a valid reflection of the vibrant and growing iPhone development community. If you're an iPhone developer, check out the Mobile Orchard website and podcast, which even has a best of Stack Overflow for iPhone developers!
    Joel and I are tremendously impressed with Apple's development push for the iPhone, including the App Store. It is remarkably Microsoft-like, in a good way -- it's completely driven by developers, developers, developers! "If you want to be a mobile developer, your #1 choice has to be Apple."
    Some comments on the sad state of Windows Mobile (rumored Silverlight reboot), Google Wave (go HTML 5!) and the Palm Pre (is HTML/JavaScript/CSS a viable development platform)?
    One downside of discussing questions on the podcast is that it leads to the Hawthorne effect, and sometimes radically changes the state of the question.
    Joel recommends SICP, The C Programming Language, The Unix Programming Environment, and Introduction to Algorithms as solid books for programmers who want to brush up on their fundamentals and potentially do well at programming interviews.
    We recommend checking out Jason Calacanis' podcast, This Week in Startups.
    We answered the following listener questions on this podcast:
    Josh Hunt: "The first answer to my question, the answer that got the highest number of votes, was not correct -- has Stack Overflow failed in the 'first answer is best' aspect?" and "We've been taught algorithms in our high school using pseudocode. What do you think of this?"
    "If I've applied for a job at Fog Creek (or anywhere else) and didn't quite make it, what can I do to improve myself as a programmer and have a better chance next time?"
    Our favorite Stack Overflow questions this week are:
    Bubble Sort Homework. Homework questions are frowned upon on Stack Overflow, but there is a right way to ask them -- and a way to get the community to help you while helping each other.
    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 [email protected]. 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.
    1 hr 9 min
  • Podcast #56
    This is the 56th episode of the StackOverflow podcast where Joel and Jeff sit down with Jason Calacanis to discuss the business side of software, including Mahalo's "Skee-Ball" economy, when VC funding is appropriate, and whether SEO matters.
    Jason Calacanis regales us with his tales of being a BBS script kiddie on his IBM PC Jr. He later got fired from his job in the Fordham computer lab for setting up a warez partition on one of the computers in the lab. Oh, and he installed a keylogger on his boss's computer, and sold pirated software on floppies, too. :)
    Jason was one of the earliest internet reporters on the east coast with Silicon Alley Reporter.
    Apparently the Q&A format -- dubbed "Knowledge Exchange" -- was pioneered in Korea with Naver and Daum, which Yahoo Answers copied for the US. In Korea, the primary way to get information is through users exchanging knowledge, not search algorithms.
    Rather than translate the app, Facebook apparently let users volunteer to translate different parts of the Facebook UI itself. Jason's Mahalo is not localized.
    In Korea, the main knowledge exchange sites are all noindexed, so Google is a non-starter there. If all the newspapers in the US noindexed as a consortium, Google would be screwed.
    Jason is a big fan of the badge system on Stack Overflow, which he plans to add to Mahalo. This of course is modelled on the Xbox 360 Achievements system; every badge in the system is there to encourage community building (and not inadvertently community destroying) behavior. It's a surprisingly fine line.
    Joel's big objection to Mahalo is that, like the now-defunct Google Answers, it turns an intrinsic motivation for asking and answering questions into an extrinsic motivation (hey, I can get paid real money for this!)
    Jason maintains that money is not the primary motivator on Mahalo. He calls it a "Skee-Ball Economy", where you are playing skee-ball for fun, and getting lots of tickets to cash out and buy fun things. It's a "token economy". You can't make a lot of money, but it (theoretically) adds a secondary driver to an already fun activity.
    Jason equates the Stack Overflow community with an "expert economy", akin to the open source software ecosystem. Jason mentioned that he has used nginx and hadoop mailing lists to identify people to hire and/or bring in to teach the other developers at Mahalo. My question is, why shouldn't Mahalo also be an expert economy?
    Jason says "I'm not so much into creating the financial system to get something out of people, it's more that I like to take work that was previously undercompensated or not compensated and make it into a career. I'm very proud of the fact that we [WebLogs, Inc.] were the company that made blogging into a career."
    Jason famously offered the top 25 users of Digg $1,000 a month to become community managers at Netscape. And 23 of the 25 users took that offer. Joel says this is like paying for sex -- applying money at the one point where most people do not have a problem getting people to contribute to a community. Jason: "I may have made a mistake", but traffic increased, and he maintains there was already a shadow economy around paid submissions to Digg.
    Jason, who has a reporting background, ultimately wanted to add a layer of journalism and editorial control to the stories submitted to Digg. Even on "anything goes" vote driven sites like Digg, they do have one level of editorial control, in that stories can be "in dispute."
    Joel asks Jason -- with your background in VC and funding, what would you do with Stack Overflow? Would you raise money? How, why, and for what? (Which reminds me: what's the difference between VC funding and a flaming bag of poop left on your doorstep? Trick question! There is no difference!)
    We now offer an integrated job board -- if you're looking for gigs, or looking for a great programmer or sysadmin, check out jobs.stackoverflow.com a...
    1 hr 16 min
  • Podcast #55
    This is the 55th episode of the StackOverflow podcast where Joel and Jeff discuss killer IDEs, how much interview feedback is appropriate (for both parties), and how to teach young programmers who think they know it all.
    Server Fault has launched! If you're a sysadmin or IT pro type, please join us there.
    You may have noticed that woot! is the launch sponsor of Server Fault. These sorts of (hopefully) tasteful advertiser relationships underwrite continued development of the site -- and let us do cool things like bring on Geoff Dalgas as Stack Overflow Valued Associate #00003!
    What does it mean to be successful as a writer online? Perhaps one metric of success is getting people you respect and admire to link to your writing in an organic, natural way (that is, without asking them to).
    Steve Yegge indicated he may blog anonymously or not at all in the future. We suspect that Steve's high profile as a notable software blogger makes it difficult for him at Google, which is a notoriously secretive company. Not Apple secretive, mind you, but close. We agree that as much as Steve writes, it's coming out of him one way or the other, but unfortunately it may be anonymous from this point on.
    If we can render virtual 3D worlds at 60 frames per second, why haven't our software development IDEs evolved much beyond ASCII text for layout? How about visual comments? And Lutz Roeder wonders about Interactive Source Code (ppt). Why not have diagrams in the code, or even better, dynamic visualization of the data structures in that code?
    My thoughts on what it takes to build a killer IDE. I'm still waiting, by the way.
    An analysis of what it takes to have a vibrant add-in ecosystem, while still folding in the most popular add-ins to the core of the product, where they rightfully belong. This is a fine line to walk, particularly for commercial software.
    It really is amazing how many problems go away when your software is all open source. Except for the "how do we pay our employees" one.
    How much feedback should job interview candidates get when the interview doesn't work out? Joel and I have an extended discussion. This is a lot trickier than it seems at first glance. At some level, perhaps you have to treat job interviews (particularly at extremely selective companies like Fog Creek) like romantic relationships -- sometimes there just isn't chemistry. Rather than over-analyze it, learn what you can, and move on to the next relationship.
    Don't ask what programming language beginning programmers should learn -- ask what type of programming do you want to train people to do! Do you want to teach theory, or skill?
    Joel's example of the MIT curriculum of robot programming is a fantastic one: "what they care about is not the actual language. It's not a matter of teaching you the Python, it's teaching you to be a programmer in an environment where everything is constantly falling down around you, nothing as works as documented, even if there were documentation, and there isn't, and if there was documentation, it was probably written by a technical writer who was afraid to go into the programmer's offices because the last time she went in she got her head bitten off."
    How to deal with headstrong know-it-all beginning programmers? Been there, done that. And by that I mean I was one, too. You have to fail. In fact, make them fail, if you can. As Joel says, they have to learn that "no code that you write can ever possibly work." We know. Alternately, throw a copy of Code Complete at them, if they're in a place where they can actually learn from it.
    Possibly one of the worst scenarios for beginning programmers is to be in a company where everyone is a beginning programmer. It does help to have some seasoned veterans in the mix, otherwise you're basically living out Lord of the Flies -- and if you don't know who Piggy is, then it's you.
    We answered the following listener questions on this podcast:
    "I...
    1 hr 7 min
  • Podcast #54
    This is the 54th episode of the StackOverflow podcast where Joel and Jeff discuss bespoke software development, URL routing, the God Algorithm, and getting your database under version control.
    We need to talk to you about your flair. Specifically, your User Flair! It's a small badge you can embed in your own website to show off your identity and "street cred", such as it is, on Stack Overflow and Server Fault. If that's not enough, you can also put it on a t-shirt. Or dress up like the Facebook guy. Hey man, these are your life choices, not ours!
    A brief discussion of how ASP.NET MVC URL routes should be declared. We do it through an custom attribute attached to the top of the method signature, which we feel provides excellent locality of information.
    Part of the promise of Stack Overflow was that it would be run by the community. We are trying to continue delivering on that promise by electing new community moderators, and having a moderation policy that all the moderators (including the core team) abide by.
    Speaking of Stack Overflow DevDays, "the" Jon Skeet is confirmed to be a speaker at the London DevDays; Scott Hanselman will be at the Seattle and San Francisco DevDays.
    We now have better, AJAX-y support for handling duplicate questions. We believe duplicate mapping is mostly a human-driven task, but we want to streamline the workflow as much as possible.
    Part of our development style on Stack Overflow is to build features as they become needed, rather than coding speculatively, trying to guess what will become important later. Our UserVoice site has been very helpful in this regard, as we try mightily to retire the top rated user feature requests and bugs. Well, the ones we agree with, anyway..
    How do you bid on software development projects without cutting corners and still stay competitive? Joel shares his thoughts. "Your job is not to deliver a spec, it's to step into the client's shoes and figure out what their problem is, and how it can be solved with computers."
    I maintain this is the blessing and curse of contract software development -- you are a proxy employee during the contract. This can be good, if it's a client you like and have empathy with, or it can be bad, if it's a client that you don't respect, or that you have absolutely nothing in common with. Would you work for that company?
    On the topic of bespoke software, Joel recommends the oddly named book How to Castrate a Bull: Unexpected Lessons on Risk, Growth, and Success in Business. Consider selling coffee makers to a hotel -- hotels don't really want a bunch of coffee machines (even if that's what they ask for), they want a system that guarantees they never have to think about coffee makers in their rooms again. This is what it means to be "enterprisey". This is what big consulting firms do.
    If you're worried about backdoors in your code, first, don't work with scumbags. But if you work at an industry where there is a lot of risk, such as banking, then you need an audit trail on everything, and perhaps an internal audit department that does nothing other than check things periodically. A certain percentage of random auditing may be preferable to strict gates on every action.
    A discussion of O(1), which sort of seems like "The God Algorithm" at first glance. But you do have to define how 'big' that 1 is. There are dimensions of space and time here that aren't immediately apparent.
    One quirk of keeping your database under version control is that you have to make a distinction between the schema, the data, and the fixed data. At the very least, have tools that let you diff your database! And ideally integrate with your build and deployment. Have you looked at the Rails way of handling database changes, with Migrations?
    Thanks to our podcast sponsor, Mint -- they're looking for a great developer!
    We answered the following listener questions on this podcast:
    "Is it true that the more the complex the softwar...
    1 hr 10 min
  • Podcast #53
    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.
    Wil Shipley is also agnostic about unit testing: Unit Testing is Teh Suck, Urr. Isn't using programs to test programs a case of "who watches the watchmen"? Also, is every bug ultimately worth fixing?
    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 principl...
    1 hr 1 min
  • Podcast #52
    This is the 52nd episode of the StackOverflow podcast -- our one year anniversary -- where Joel and Jeff discuss the launch of Server Fault, how you determine if your code is smelly (or just aromatic), how programmers learn by doing, and how good ideas are often too crazy to copy until it's too late.
    We've been podcasting for one full year now. Hopefully we've gotten better at this podcast stuff and not worse, but the jury is still out.
    Server Fault, the first sister site to Stack Overflow, is now in private beta. Server Fault is for system administrators and IT professionals. If that's you, come join us!
    We've only done one major branch in Stack Overflow to date, and it was excruciatingly painful in Subversion, even after updating to 1.6 which has "better" support for merging. We're considering switching to Mercurial to make future merges feel a bit less like gnawing our own limbs off.
    Joel announces that Fog Creek is working on a hosted version of Stack Overflow, and they are looking to hire a software engineer to work on the project. If it works out, you get the whole Fog Creek relocation package! If you've ever wanted to work on the Stack Overflow codebase (and you're looking for a full time gig) this is your chance!
    The prospect of an outside developer looking at our Stack Overflow code base makes us nervous. Maybe this is a healthy reaction -- is any code ever good enough? Probably not.
    We do believe in continuous refactoring, and part of that is developing free from fear. Don't be afraid to break stuff! Have some unit tests, and when things do break, be able to fix it very rapidly.
    Test Driven Development is possibly the worst and most incorrect name ever applied to a concept in software engineering, ever. And that's saying a lot. TDD is more about design than testing, but when every TDD tutorial starts with "ok, we write a test to verify.." it's sort of hard to justify. Perhaps Behavior Driven Development would be a better name.
    TDD, as far as testing is concerned may be a bit too programmatic. Never underestimate the power of a skilled human tester.
    We learned ASP.NET MVC as we went. This is a surprisingly common pattern; Joel can't ever remember a time when he wasn't building a new application in a new framework. Programming is, almost by definition, continuously learning: your entire career will be one long, unbroken string of learning one new bit of technology after another. Programming is shorthand for learning how to learn.
    Joel asks: as a professional programmer, how often do you start a new major project that's going to have a long life expectancy? It's startlingly rare. Even at Fog Creek they've had maybe four in the entire time the company has existed. So when you start a new project, you almost have to bet on the new framework that you think will be vibrant and alive five years from now -- that means you'll be learning as you go, again! There is a double whammy of learning the framework and a language at the same time though -- that's extra-risky.
    A brief discussion of why unconfirmed "no-touch" user actions are so dangerous on the web; they are a XSRF playground! If the user holds a cookie to your site, and an attacker can get them to click on a GET or POST, they have just forced the user to take that action. We added an interstitial confirmation to a few actions to prevent this; the particular case that was extremely dangerous was associating a new OpenID provider in one click. If that OpenID provider was rogue and controlled by the attacker, they now own the account.
    Joel notes that if you're shy about putting things online, you are letting other people control your online identity -- and that will hurt you much more in the long run than any potentially questionable things you might possibly put online.
    One of the goals of creating Stack Overflow was as a vehicle to build your online identity as a professional programmer, a virtual set of bread crumbs s...
    1 hr 5 min

About The Stack Overflow Podcast

From the publisher's feed

For more than a dozen years, the Stack Overflow Podcast has been exploring what it means to be a developer and how the art and practice of software programming is changing our world. From Rails to…