The Stack Overflow Podcast show

The Stack Overflow Podcast

Summary: Hosted by Joel Spolsky, Jay Hanlon, David Fullerton, and Ilana Yitzhaki, The Stack Overflow Podcast lets you listen in on discussions and decisions concerning the world's largest developer community. About Stack Overflow: Founded in 2008, Stack Overflow is the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. More than 50 million professional and aspiring programmers visit Stack Overflow each month to help solve coding problems, develop new skills, and find job opportunities.

Join Now to Subscribe to this Podcast
  • Visit Website
  • RSS
  • Artist: The Stack Overflow Team
  • Copyright: Copyright © Stack Overflow, 2019

Podcasts:

 Podcast #60 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #59 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #58 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #57 | File Type: audio/mpeg | Duration: Unknown

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 podcast@stackoverflow.com. 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.

 Podcast #56 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #55 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #54 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #53 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #52 | File Type: audio/mpeg | Duration: Unknown

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...

 Podcast #51 | File Type: audio/mpeg | Duration: Unknown

This is the 51st episode of the Stack Overflow podcast, where Joel and Jeff sit down with Joel's business partner, Michael Pryor of Fog Creek Software, at Stack Overflow world HQ (i.e., Jeff's house) in El Cerrito, California. At my home, Joel discovers my secret clock fetish. I have a pong clock, a nixie clock, and I'd love to have an oscilloscope clock! Joel and Michael went to the Computer History Museum, one of my favorite places in the world. It's not just big iron; Michael geeked out over his old Apple //gs, and Joel enjoyed revisiting old HP calculators. Stack Overflow comments are now elevated to the main page. We've gone through several user feedback cycles on this, and we feel the current comment layout is a good balance. The preference for this is still in the works. This was partially inspired by the way comments are displayed on SFGate articles (scroll to the bottom to see how comments are displayed there). A discussion of the value of meta -- discussing Stack Overflow on Stack Overflow. How much meta is acceptable? Where should meta-discussion go? Isn't the podcast and the blog meta enough? Is there a need for stackoverflowoverflow? One problem is that the system we've built is good at focused, directed Q&A but quite bad at arbitrary discussion. It's why Joel objected to me proposing the use of the Stack Overflow engine for the Joel on Software discussion boards and the Business of Software discussion boards. Not a good fit! Consider an analogy with school -- if you don't like the after school activities students are engaging in, it's because you didn't provide a good set of alternatives for them. But perhaps a better analogy is that of students who become teachers; they need a "teacher's lounge" area. The whole point of Stack Overflow is synthesizing _better _answers than what you can commonly find on the open internet. If the answer is already good and easily findable elsewhere on the internet, leave it there! Don't repost the answer on Stack Overflow unless you're enhancing and improving the answer in some small way. How is Babby Formed has been removed from Yahoo Answers, and we have removed Programming at Sea. Part of the philosophy of doing lower-level things yourself, such as building your own computers (or even learning C), is to do it enough to understand it -- and learn something along the way. It doesn't mean that you need to (or even should!) do those things forever, but the journey of learning and discovery is its own reward. The best reference for programmers who want to learn what goes on underneath their code is Charles Petzold's outstanding book, Code. Learning black hat techniques is important, because when good is dumb, evil will always triumph. Don't be dumb. Know what's out there, and how to exploit it. The morality of studying black hat techniques derives from what you do with that information. Will you sell it? Distribute it and actively attack ? Or quietly disclose it to the vulnerable software or website? Joel marvels at the enormous size of the Microsoft campus since he worked there; when he was at Microsoft in the early 90's, there were around 5,000 employees and it was not uncommon to see Bill Gates walking around the campus. The Redmond visitor center is a disappointment; it should be more like the Computer History Museum, highlighting Microsoft's central role in so much of that history to date. Apparently the best estimates are that there are around 9 million programmers in the world, roughly the population of New York City. Imagine a whole city of nothing but programmers. On second thought, that's too scary -- let's not. A small clarification on last week's Steve Yegge project; Steve is not the author of the Google JavaScript compiler, but a client of it. We answered the following listener questions on this podcast: Peter: "What do you think about the practice of finding an answer, and re-posting it...

 Podcast #50 | File Type: audio/mpeg | Duration: Unknown

This is the 50th episode of the StackOverflow podcast, where Joel and Jeff sit down with Steve Yegge of Google and the most excellent Stevey's Blog Rants. This episode was recorded on site at the Kirkland, Washington Google office, where Joel gave a talk earlier in the day. A brief discussion about the APL language, whose keywords are symbols. Imagine how challenging it would be to program in a language where you need a special keyboard. There's a more popular (not sure "popular" is the right word) version of APL named J which drops the symbols in favor of plain ASCII. How big a fan of working at Google is Steve? He worries that new hires from college will expect the rest of their working life to be as good as their Google experience. Steve can finally talk about what he was working on, which he was so vague about on our previous podcast with him. Mostly, he was disturbed at the state of JavaScript tooling at Google -- "dude, you spelled it fuction again." The state of the art in tools means painstakingly adding support for each individual language into each individual editor. What if there was a way to plug first-class language intellisense / compilation functionality into any editor -- in a generalized way? That's the problem Steve set out to solve. Take compilers that are defined for IDEs -- Eclipse has three Java compilers built into it -- a fast inaccurate one as you type, a better batch one, and then a great big one that does exhaustive analysis on large trees (Steve says Eclipse has "a better Java compiler than the Java compiler".) This is all necessary to get good editor support! Why not take these compilers and run them on the google infrastructure, so they are commoditized and available to any editor? Steve says the way tools and languages integrate today is utterly backwards. Languages should support the tools, rather than the other way around. "We should have been doing this for 20 years!" Prototype doesn't play well with the JavaScript compiler at Google, partly because nobody has actually tried to compile the code before! It exposes some problems that weren't immediately obvious. All the common JavaScript frameworks require some tweaking for the JavaScript compilation process. Steve likens the comparison between compilation and dynamic typing to taking a shower and brushing your teeth. You should do both! The only reason we can't do both of these things is because, as Steve points out, our tooling currently sucks. JavaScript has a more interesting origin than I realized -- it was originally based on Scheme. Per Steve, Scala is like Haskell but with more concessions to real world programming. He points out that the great thing about Java is the fantastic tooling, which means it's ultimately a better programming experience than a theoretically "superior" programming language. Joel doesn't hate Unix; FogBugz supports Unix (although that support tends to be complex and costly) and Joel regularly runs cygwin on his laptop. That said, modern Unixes have their faults too. Steve observes that the only way to determine what packages are installed on Ubuntu is to diff the dpackage output against a clean machine. Also, Firefox is very slow on Linux relative to Mac and Windows. Stack Overflow is for programming related questions, but defining programming related isn't easy. There will always be a gray area, which is further complicated by the fact that we do want the _occasional _fun questions -- we just don't want the system overrun with the stuff. Steve points out that even Amazon has examples of "fun" product reviews that wouldn't normally be permitted, such as On Amazon, All of a Sudden Everyone's a Milk Critic and The Story About Ping. We answered the following listener questions on this podcast: "What is Joel's history with Unix? He mentions Unix a lot in vaguely pejorative ways. Did he have a bad early Unix experience?" No, Steve, the caller did not say "eunuchs"!...

 Podcast #49 | File Type: audio/mpeg | Duration: Unknown

This is the 49th episode of the StackOverflow podcast, where Joel and Jeff sit down with Alex Papadimoulis of The Daily WTF to discuss the distinction between IT/sysadmins and programmers, online justice for webforums, user-friendly IDs for databases, and the future of software distribution. Some of our favorite Daily WTF entries: Spaced Out and Have You Tried JavaScript? Alex likens their writing process to the Vital Signs column in Discover Magazine. As we build up serverfault.com , the already grey area of "which question goes where?" becomes even .. greyer. The animal, vegetable, mineral problem is not going away any time soon. That said, if you can attach code to your question, it probably belongs on stackoverflow.com. And if your question involves a server (and no code), it probably belongs on serverfault.com. But there are always exceptions, like this question about working conditions. I was surprised to find that there seems to be no critical mass of sysadmin/it bloggers online, certainly no equivalent to the legions of high profile programming bloggers. Thus, we'll be initially seeding serverfault.com with those programmers from stackoverflow.com who cross over and also wear the sysadmin/it hat in their work. What if there was a programming language that used only abstract symbols instead of existing words in a human language? There is! But it's only a research project. (And I found out that Joel wasn't kidding about APL!) Some clarifications about the localization discussion last week. Joel and I continue to disagree about priorities here, is what it boils down to. Joel and Michael are fans of the hellban concept, but I find it to be a bit much like the guys in black masks making people disappear overnight. We implemented a penalty box instead. The hellban might be appropriate for random spammers, but for engaged members of a community, it's a terrible system of justice. We also improved our flagging system ala Craigslist so it's easier to communicate with moderators. The specific source of friction was editing. It turns out that the spirit of an edit is as important as the technical rationale for it. We love and encourage editing, of course, but it's possible to follow the absolute letter of the law and still be toxic to the community. Joel says that the typical programming mindset makes us particularly prone to this behavior. You have to be able to let things go. One of the curiosities of Wikipedia is that the most obsessed users always win. You can't compete with someone who devotes hours every day to maintaining their pet topic, with scripts to protect it. This system, on some level, must work because if it didn't Wikipedia would be permanently broken. In addition to software increasingly running in the browser via various mechanisms, we view services like Valve's Steam as the future of software distribution. Ultimately it should be as easy and painless to install software as it is on the closed-ecosystem iPhone and its App Store. The tension between digital distribution and traditional retail channels is still a major hurdle, however. Alex liked this Stack Overflow question: Database-wide unique-yet-simple identifiers in SQL Server. Great question having to do with the human readability of IDs for unique database records. Lots of food for thought. Alex recommends unique lengths per record type, or the "Smart Key" approach of encoding dates and other unique things in the id. We answered the following listener questions on this podcast: Andy Brice: "What will happen with the market with downloadable software? Everything in the browser? Hybrid between the downloadable executables and stuff running in the browser? Or will it be business as usual?" 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 podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser...

 Podcast #48 | File Type: audio/mpeg | Duration: Unknown

This is the 48th episode of the StackOverflow podcast, where Joel and Jeff discuss planning your career, the importance (or not?) of localization, what makes a good moderator, and dealing with programmers who lack interpersonal skills. Until 2004, I felt sort of like that feather in the movie Forrest Gump, or the plastic bag in American Beauty. I had no real plan for my career. This prompted me to think about what I wanted from my career, and it's why I wrote The Eight Levels of Programmers. Think about who you respect, and why, and whether those paths work for you. If you're very lucky in your career, perhaps you'll be able to build Bongo's Dream House. Joel and I have a long (REALLY LONG) discussion about the Chinese Stack Overflow clone, cnprog. It's excellent that we are inspiring other programmers, but we do draw the line at copying our look and feel down to the tiniest detail (including the blog). Don't be a content stealing jerk! One reason localization has been a very low priority is that we feel for our particular audience, namely programmers, English is the de facto standard language. Not that other languages aren't important, but it's easier to get engineering work done when everything coalesces around a standard language. It is true that localization is not even close to being on our radar. Programming communities need to form in local languages, too. We're open to providing a dump of our cc-wiki licensed content, but we don't want to have an AOL data scandal. That would be .. bad. It's the biggest risk blocking that from happening at the moment. Joel believes that there are five "important" languages that programming content should eventually be localized into: German, Spanish, French, Chinese, and Japanese. We're beginning the process of promoting a notable user from our community to full-blown moderator status. Shaya Loney, who works at answers.com, had some excellent advice for us -- one of the risks is that when you take one of your best teachers and turn them into the principal of the school, you lose a great teacher. We also want moderators with a variety of different backgrounds for diversity. We were able to test our datacenter disaster contingency planning a little with a recent server error. Lesson: always have your contingency plans ready to go in practice, not just in theory. We only lost time, but we're considering the use of remote KVMs if this becomes an ongoing concern. One way to deal with programmers who come off as abrasive and perhaps lack interpersonal skills, is to focus on the specific behaviors that are problematic. Detail the very specific, ultra-narrow things that they could change to improve the way other people react to them. There's a good reason to fix this, beyond the bad apple theory. As Joel points out, "for marginal performers, the people who don't get along, are probably going to get fired, and the people who everybody likes, are probably going to stay around." Revisiting the "architect" title. We still think it's a bad idea, but perhaps it's more palatable if you think of it as "software engineer with lots of experience." And get rid of the title! That said, there are the rare few, with Joel's example of Dave Cutler, who truly was the Architect of Windows NT in every possible sense of the word. We answered the following listener questions on this podcast: Demitrios from Brazil "What do you do with a solid contributor who on a personal level is very annoying, nobody likes him, and nobody can get along with him?" Rudy from Denver "Is it possible that Architect is a valid title, for those developers who have the skill to develop large applications?" 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 podcast@stackoverflow.com. 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 lea...

 Podcast #47 | File Type: audio/mpeg | Duration: Unknown

This is the 47th episode of the StackOverflow podcast, where Joel and Jeff discuss Eclipse, plugin architectures, sketching mockups, and optimizations that don't optimize. I had the honor of keynoting EclipseCon this year with Clay Shirky. Eclipse is an open source IDE with an excellent plugin ecosystem. It's also a great Java GUI framework. A brief discussion of the communal relationship between applications and plugins. I am cautiously optimistic about the release of Internet Explorer 8. The betas were very scary, but the final released version is surprisingly solid and fast. A totally respectable update from Internet Explorer 7, and it has a very convenient "switch to IE7 rendering mode" (along with a HTML header that does the same thing) that means it's super easy to essentially have both browsers. Joel explains that he'd rather spend any amount of money than have his developers "take a few weeks" to optimize the FogBugz compiler. Remember, hardware is cheap, and programmers are expensive. This may include buying 8 GB of memory (cheap!) and the super-fast Intel SSD hard drive. It's recommended by Linus! Be careful with SSDs, the only ones worth having at the moment are the very high end models like the Intel one. Cheaper ones can be slower than regular hard drives! I continue to recommend the two-spindle approach for desktops for optimal performance. It's the same reason, on a database server, you typically have the OS on one drive and the data on another drive. It reduces contention. We joke about pure architecture software releases, where nothing visible changes in the product, except the underlying code. There are reasons to do this, such as performance, scalability, and simplicity. But for a product users pay for, a pure architecture release would be suicide. Our live podcast from MIX went great -- thanks to everyone who participated! You can watch our 5-minute bit at about 50 minutes into the day one keynote on the official MIX website. The classic example of a free site attacking the business model of a pay site is Markus Frind's Plenty of Fish. What's odd is that PoF has been so successful that Markus is looking to acquire a pay dating site at this point. On the other hand, he's adding some pay features to his free site as well. Joel talks about how smart the design of Balsamiq Mockups is. It actually forces you to stay simple and abstract, which is the whole point of sketching. Sketching is on our minds because the Bill Buxton book Sketching User Experiences was provided to every MIX attendee, and Bill Buxton was the first day 1 keynote speaker. Joel complains that so many design books start by talking about the design of the iPod, to the point that it's cliche. Perhaps one design lesson is that people care more about the content than the design -- the websites they load are far more important than what browser widget they load it in, despite how important choice of browser is to us geeks. One of the points Clay brought to our EclipseCon keynote was that social software ends up being a mirror, a reflection of the community you drop it in to. Unlike PhotoShop, which works exactly the same no matter how many times you copy it or who is using it, the same social software may behave completely differently for different communities. This is why Reddit cloning itself into weheartgossip isn't really working -- the audience is too different. Make sure your "optimizations" are actually optimizing, otherwise you're pessimizing -- with the best of intentions, you make your code slower. Benchmark first, not last! There are huge categories of premature optimization you should avoid, but you also want to avoid making big design mistakes early on. It's not necessarily optimization, per se, but don't do things that are so incredibly boneheaded you will regret them forever. We answered the following listener questions on this podcast: "What about Stack Overflow for car questions...

 Podcast #46 | File Type: audio/mpeg | Duration: Unknown

This is the 46th episode of the StackOverflow podcast, live from MIX09, where Joel and Jeff answer questions from the live audience. This podcast is live from the MIX09 conference! Joel and I also had a small 5 minute segment in the Day 1 keynote, which you can view online. It's at around the 50 minute mark or so. We had a live audience, so the focus of this podcast is on questions from our live audience. We answered the following live audience questions on this podcast: "What's the point of Silverlight?" The short answer is, it's like Adobe Flash, but much more programmer oriented. Silverlight 3 beta was just launched at MIX, with lots of new developer-y goodness. "What's the most number of questions asked by an actual Stack Overflow user?" That would be Edward Tanguay with 210 questions, closely followed by Thomas Owens who asked 207 questions. One reason the "ask a question" button isn't more prominent on the site is that we encourage people to read and answer a while before asking anything. Good questions take some effort! "Have you ever considered moving Stack Overflow to the cloud?" The cloud makes more sense for experimental projects that may or may not succeed. We did the math and decided that owning the hardware was a better deal for our project. It could also make sense for hot-standby disaster recovery backup servers. It depends whether or not you prefer flexibility, or fine-grained control. "What issues did you have with using ASP.NET MVC?" Other than the typical beta issues, not much. The big advantage, to us, is that MVC is a much more web-centric development model. It is a much closer match to our mental model of how web programming should work, and how URLs should be formed. "What does the new guy do on the first day?" Fix the simplest possible bug in your product. And on the next day, fix a slightly more complex bug. It helps to do this in an environment of active pairing or mentoring. "Are there some things about the web platform (HTML, CSS, etc) that you wish worked differently?" Sure, the platform barely works. There's something inspiring about so many programmers are building great stuff on such a rickety platform. And it's creating a whole new generation of programmers. There's a certain inexplicable elegance to the madness. "We have a lot of relatively unstructured data that we're storing in a database, is there some other way do deal with this? And what about REST vs. SOAP access to it?" Joel points to Adam Bosworth's classic talk about the flexibility of loosely structured data. Perhaps something like Lucene or CouchDB would be a better choice than a traditional rigid database. And remember that meta-tags, while worthless on the open web, are trustworthy on local data. Sometimes you don't need a perfect 100% right answer back from the data. Joel describes the advantage of REST over SOAP thusly: you can just type stuff into the browser's address bar and see the results in real time. "Should you teach the framework, or the underlying languages?" Joel points out that maybe students shouldn't be studying programming at all. You can learn a lot about programming through related fields. Joel and I disagree a bit on this one. I think good developers are inherently curious, so they can learn the framework and dip into the lower level language as necessary to solve whatever problem is at hand. Joel says you should start with the language and scale up. "How different is the world view of a programmer who is twenty-something and grew up with the web, versus a thirty-something who didn't? How important is historical context?" Can developers who only know JavaScript, HTML, and CSS grow into being generally great developers? I argue that there's an inherent intellectual curiosity in all great programmers, so they can start anywhere and get amazing results. Joel notes that some of the historical context can become a burden and possibly even incorrect over tim...

Comments

Login or signup comment.