[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"sanity-UtpIRPp2VmVgEV6Y-k4cdPI83cI_pUJUlZ1n3O4QPYA":3,"sanity-U6hWlI9dp4rMaEks1xIAZxZ-kBI3euPa6ui6GjkYhYA":437},{"data":4,"sourceMap":-1},{"latestPodcast":5,"latestReleases":14,"post":39,"recent":412},[6],{"_id":7,"publishedAt":8,"slug":9,"sponsored":12,"title":13},"f83eb5f0-1237-487f-84d8-f7abf2318c39","2026-06-25T07:40:00.000Z",{"_type":10,"current":11},"slug","code-isnt-causing-your-production-failures",null,"Code isn’t the only thing causing your production failures",[15,21,27,33],{"_id":16,"publishedAt":17,"slug":18,"title":20},"eb5b66eb-9410-4329-83bb-22bbff39402a","2026-04-28T13:00:00.000Z",{"_type":10,"current":19},"turn-scattered-knowledge-into-trusted-intelligence","Turning scattered knowledge into trusted intelligence: Stack Internal 2026.3",{"_id":22,"publishedAt":23,"slug":24,"title":26},"369c2401-b62e-4a37-8ff8-bf603023ecad","2026-03-02T15:03:00.988Z",{"_type":10,"current":25},"what-s-new-at-stack-overflow-march-2026","What’s new at Stack Overflow: March 2026",{"_id":28,"publishedAt":29,"slug":30,"title":32},"5e9053a4-07ea-447c-91ea-29e0b6228537","2026-02-02T15:00:00.000Z",{"_type":10,"current":31},"what-s-new-at-stack-overflow-february-2026","What’s new at Stack Overflow: February 2026",{"_id":34,"publishedAt":35,"slug":36,"title":38},"a1b538eb-a8a6-46d0-80a1-ac70ec9bb935","2026-01-05T10:00:00.000-05:00",{"_type":10,"current":37},"what-s-new-at-stack-overflow-january-2026","What’s new at Stack Overflow: January 2026",{"_createdAt":40,"_id":41,"_rev":42,"_type":43,"_updatedAt":44,"author":45,"body":59,"comments":384,"dateUrl":385,"excerpt":386,"image":387,"legacyBody":391,"product":12,"publishedAt":394,"slug":395,"sponsored":12,"tags":397,"title":411,"visible":384},"2023-05-25T09:36:59Z","wp-post-3672","dgl3SCUzppW3U2LvCoS5oq","blogPost","2023-07-13T14:54:30Z",[46],{"_createdAt":47,"_id":48,"_rev":49,"_type":50,"_updatedAt":51,"avatar":52,"employee":54,"name":55,"role":56,"slug":57},"2023-05-23T16:27:18Z","wp-author-114","07ZbrKPSUrjrV4wQ6fam8u","blogAuthor","2023-08-29T11:49:01Z",{"_type":53},"image","former","Jeff Atwood","Co-founder",{"current":58},"jeffatwood",[60,71,93,121,151,170,231,239,247,266,285,293,307,315,327,365],{"_key":61,"_type":62,"children":63,"markDefs":69,"style":70},"fb39c69a9fd4","block",[64],{"_key":65,"_type":66,"marks":67,"text":68},"fb39c69a9fd40","span",[],"In this episode of the Stack Overflow podcast, Joel and Jeff discuss GitHub, the value of formal code documentation, and how to decide what features belong in the next version of your software.",[],"normal",{"_key":72,"_type":62,"children":73,"level":87,"listItem":88,"markDefs":89,"style":70},"439239f36deb",[74,78,83],{"_key":75,"_type":66,"marks":76,"text":77},"439239f36deb0",[],"We've had some difficulty adapting to GitHub, where the reverse engineering of",{"_key":79,"_type":66,"marks":80,"text":82},"439239f36deb1",[81],"c3f352f573af"," the Javascript Markdown (WMD) editor",{"_key":84,"_type":66,"marks":85,"text":86},"439239f36deb2",[]," was performed. It regularly confuses everyone that encounters it, and that's frustrating from a support perspective.",1,"bullet",[90],{"_key":81,"_type":91,"href":92,"reference":12},"link","http://github.com/derobins/wmd",{"_key":94,"_type":62,"children":95,"level":87,"listItem":88,"markDefs":118,"style":70},"e948c738b267",[96,100,105,109,114],{"_key":97,"_type":66,"marks":98,"text":99},"e948c738b2670",[],"For example, why does ",{"_key":101,"_type":66,"marks":102,"text":104},"e948c738b2671",[103],"4338cd2c6ada","the MangOS project on GitHub have 854 branches",{"_key":106,"_type":66,"marks":107,"text":108},"e948c738b2672",[],"? How is that useful to ",{"_key":110,"_type":66,"marks":111,"text":113},"e948c738b2673",[112],"em","anyone?",{"_key":115,"_type":66,"marks":116,"text":117},"e948c738b2674",[]," The project network is so complex it can't even be rendered! What I specifically object to is that all pulls show up in the timeline as forks; I'd like to see an ability to nominate your pull timeline as either private or \"not intended for merging\" so it won't show up in the main network.",[119],{"_key":103,"_type":91,"href":120,"reference":12},"http://github.com/mangos/mangos/network",{"_key":122,"_type":62,"children":123,"level":87,"listItem":88,"markDefs":146,"style":70},"c6621c8dbc32",[124,128,133,137,142],{"_key":125,"_type":66,"marks":126,"text":127},"c6621c8dbc320",[],"Joel is writing a series of articles about distributed version control in ",{"_key":129,"_type":66,"marks":130,"text":132},"c6621c8dbc321",[131],"1530a7091bb5","Mercurial",{"_key":134,"_type":66,"marks":135,"text":136},"c6621c8dbc322",[]," -- I'm hoping they will clear up some of my confusion about GitHub. I personally find ",{"_key":138,"_type":66,"marks":139,"text":141},"c6621c8dbc323",[140],"910fb1e083ef","Google Code",{"_key":143,"_type":66,"marks":144,"text":145},"c6621c8dbc324",[]," much easier to work with.",[147,149],{"_key":131,"_type":91,"href":148,"reference":12},"http://mercurial.selenic.com/",{"_key":140,"_type":91,"href":150,"reference":12},"http://code.google.com/hosting/",{"_key":152,"_type":62,"children":153,"level":87,"listItem":88,"markDefs":167,"style":70},"f9cc171c1227",[154,158,163],{"_key":155,"_type":66,"marks":156,"text":157},"f9cc171c12270",[],"As part of ",{"_key":159,"_type":66,"marks":160,"text":162},"f9cc171c12271",[161],"82d08b0970cd","MarkdownSharp",{"_key":164,"_type":66,"marks":165,"text":166},"f9cc171c12272",[],", our open source C# Markdown implementation, I've experimented a bit with turning a regex into a state machine -- and I was a bit shocked how many lines of code it takes to \"unroll\" a regex. Is it really easier to troubleshoot 25 individual lines of state machine code (all with potential bugs) or 3 single line regular expressions?",[168],{"_key":161,"_type":91,"href":169,"reference":12},"http://code.google.com/p/markdownsharp/",{"_key":171,"_type":62,"children":172,"level":87,"listItem":88,"markDefs":220,"style":70},"0866a4ae52b3",[173,177,182,186,191,195,200,203,208,211,216],{"_key":174,"_type":66,"marks":175,"text":176},"0866a4ae52b30",[],"Stack Overflow user ",{"_key":178,"_type":66,"marks":179,"text":181},"0866a4ae52b31",[180],"8417b1aee64f","William Shields",{"_key":183,"_type":66,"marks":184,"text":185},"0866a4ae52b32",[]," has taken up Joel's challenge to write a Markdown parser the right way -- and produced an excellent series of articles about what he's learned in the process: ",{"_key":187,"_type":66,"marks":188,"text":190},"0866a4ae52b33",[189],"2008546a5f50","one",{"_key":192,"_type":66,"marks":193,"text":194},"0866a4ae52b34",[],", ",{"_key":196,"_type":66,"marks":197,"text":199},"0866a4ae52b35",[198],"c4932777ce09","two",{"_key":201,"_type":66,"marks":202,"text":194},"0866a4ae52b36",[],{"_key":204,"_type":66,"marks":205,"text":207},"0866a4ae52b37",[206],"2dd525fb8306","three",{"_key":209,"_type":66,"marks":210,"text":194},"0866a4ae52b38",[],{"_key":212,"_type":66,"marks":213,"text":215},"0866a4ae52b39",[214],"e3bed61024db","four",{"_key":217,"_type":66,"marks":218,"text":219},"0866a4ae52b310",[],". It's a perfect example of the type of learning that Stack Overflow itself is all about; kudos to William for sharing it!",[221,223,225,227,229],{"_key":180,"_type":91,"href":222,"reference":12},"http://stackoverflow.com/users/18393/cletus",{"_key":189,"_type":91,"href":224,"reference":12},"http://www.cforcoding.com/2010/01/jmd-markdown-and-brief-overview-of.html",{"_key":198,"_type":91,"href":226,"reference":12},"http://www.cforcoding.com/2010/01/more-details-on-jmd-markdown-parsing.html",{"_key":206,"_type":91,"href":228,"reference":12},"http://www.cforcoding.com/2010/01/markdown-musings-on-unintended.html",{"_key":214,"_type":91,"href":230,"reference":12},"http://www.cforcoding.com/2010/01/markdown-headings-grief-and-unknown.html",{"_key":232,"_type":62,"children":233,"level":87,"listItem":88,"markDefs":238,"style":70},"cb95a961ef3f",[234],{"_key":235,"_type":66,"marks":236,"text":237},"cb95a961ef3f0",[],"Joel and I have mixed feelings about documenting a large code base. Rather than wasting time generating reams of documentation that may never be read, and will rapidly get out of date -- we offer some alternatives. Come up with a unit test suite that lives symbiotically with the code, or spend time documenting the key, central data structures instead of the code. Also, have the new hire guys and gals who encounter the code be in charge of keeping the \"how do I get started with this stuff?\" bootstrapping information up to date.",[],{"_key":240,"_type":62,"children":241,"level":87,"listItem":88,"markDefs":246,"style":70},"66be1cc3c9b4",[242],{"_key":243,"_type":66,"marks":244,"text":245},"66be1cc3c9b40",[],"Joel says the least amount of work you need to do to capture how many hours are spent on programming tasks, is to make each source code checkin assume that all time since the previous checkin was spent on whatever the current task is. This is \"good enough\" in his experience and produces solid, useful future estimates.",[],{"_key":248,"_type":62,"children":249,"level":87,"listItem":88,"markDefs":263,"style":70},"6e842c9c352c",[250,254,259],{"_key":251,"_type":66,"marks":252,"text":253},"6e842c9c352c0",[],"At Fog Creek, to determine what features make the cut for the next version of the software they get developers, customer representatives, and the sales team together and do ",{"_key":255,"_type":66,"marks":256,"text":258},"6e842c9c352c1",[257],"c080c4a5844c","T-Shirt size estimation",{"_key":260,"_type":66,"marks":261,"text":262},"6e842c9c352c2",[]," (S through XXL) of development time for the desired features. Then everyone in the meeting has a dollar to spend on their favorite features. Then, just fit the winners into the allotted schedule.",[264],{"_key":257,"_type":91,"href":265,"reference":12},"http://30secondblogs.blogspot.com/2006/10/t-shirt-estimates.html",{"_key":267,"_type":62,"children":268,"level":87,"listItem":88,"markDefs":282,"style":70},"154b75549a1e",[269,273,278],{"_key":270,"_type":66,"marks":271,"text":272},"154b75549a1e0",[],"Stack Overflow is a community driven site, so many (but not all) of the new features come from top voted ",{"_key":274,"_type":66,"marks":275,"text":277},"154b75549a1e1",[276],"e0df218e4f92","Meta Stack Overflow",{"_key":279,"_type":66,"marks":280,"text":281},"154b75549a1e2",[]," requests. We try to avoid devolving into design by committee by heavily weighting feature requests that match our vision for the site. Most feedback is not terribly useful -- but if you're willing to spend the time it takes to filter out the bottom 90% of feedback, you may be pleasantly surprised by the cool ideas the community can come up with.",[283],{"_key":276,"_type":91,"href":284,"reference":12},"http://meta.stackoverflow.com/",{"_key":286,"_type":62,"children":287,"markDefs":292,"style":70},"506d1d5848c5",[288],{"_key":289,"_type":66,"marks":290,"text":291},"506d1d5848c50",[],"We answered the following listener questions on this podcast:",[],{"_key":294,"_type":62,"children":295,"level":87,"listItem":305,"markDefs":306,"style":70},"a371c061748e",[296,301],{"_key":297,"_type":66,"marks":298,"text":300},"a371c061748e0",[299],"strong","Dave",{"_key":302,"_type":66,"marks":303,"text":304},"a371c061748e1",[],": \"I work at a large company with an enormous code base in many different languages. As a new guy trying to find my way around, I get frustrated by the lack of documentation. How much documentation is appropriate?\"","number",[],{"_key":308,"_type":62,"children":309,"level":87,"listItem":305,"markDefs":314,"style":70},"a61ccb5f9fd8",[310],{"_key":311,"_type":66,"marks":312,"text":313},"a61ccb5f9fd80",[],"\"We had a new year's resolution to capture an accurate work log of hours worked, but we've already relapsed. How do the Fog Creek developers manage to do this?\"",[],{"_key":316,"_type":62,"children":317,"level":87,"listItem":305,"markDefs":326,"style":70},"633aa1bba5a6",[318,322],{"_key":319,"_type":66,"marks":320,"text":321},"633aa1bba5a60",[299],"Chap:",{"_key":323,"_type":66,"marks":324,"text":325},"633aa1bba5a61",[]," \"How do you prioritize features and functionality for your products, and how do you decide what to spend time on and what's worth doing?\"",[],{"_key":328,"_type":62,"children":329,"markDefs":360,"style":70},"1dcdb08fdd66",[330,334,339,343,348,352,356],{"_key":331,"_type":66,"marks":332,"text":333},"1dcdb08fdd660",[],"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 ",{"_key":335,"_type":66,"marks":336,"text":338},"1dcdb08fdd661",[337],"2eb552a342d2","podcast@stackoverflow.com",{"_key":340,"_type":66,"marks":341,"text":342},"1dcdb08fdd662",[],". You can ",{"_key":344,"_type":66,"marks":345,"text":347},"1dcdb08fdd663",[346],"47147a09cbb4","record a question",{"_key":349,"_type":66,"marks":350,"text":351},"1dcdb08fdd664",[]," using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at ",{"_key":353,"_type":66,"marks":354,"text":355},"1dcdb08fdd665",[299],"646-826-3879",{"_key":357,"_type":66,"marks":358,"text":359},"1dcdb08fdd666",[],".",[361,363],{"_key":337,"_type":91,"href":362,"reference":12},"mailto:podcast@stackoverflow.com",{"_key":346,"_type":91,"href":364,"reference":12},"http://blog.stackoverflow.com/index.php/2008/05/recording-podcast-questions-using-your-telephone/",{"_key":366,"_type":62,"children":367,"markDefs":381,"style":70},"1a191b2f9038",[368,372,377],{"_key":369,"_type":66,"marks":370,"text":371},"1a191b2f90380",[],"The ",{"_key":373,"_type":66,"marks":374,"text":376},"1a191b2f90381",[375],"aa267bed7c11","transcript wiki",{"_key":378,"_type":66,"marks":379,"text":380},"1a191b2f90382",[]," for this episode is available for public editing.",[382],{"_key":375,"_type":91,"href":383,"reference":12},"https://stackoverflow.fogbugz.com/default.asp?W29122",true,"2010/01/21","",{"_type":53,"asset":388},{"_ref":389,"_type":390},"image-2e7e2d828ffbb0404d422ecab697f29109a4339b-1500x1000-jpg","reference",{"code":392,"language":393},"\u003Cp>In this episode of the Stack Overflow podcast, Joel and Jeff discuss GitHub, the value of formal code documentation, and how to decide what features belong in the next version of your software.\u003C/p>\n\u003Cul>\u003Cli>\n\u003Cp>We've had some difficulty adapting to GitHub, where the reverse engineering of\u003Ca href=\"http://github.com/derobins/wmd\"> the Javascript Markdown (WMD) editor\u003C/a> was performed. It regularly confuses everyone that encounters it, and that's frustrating from a support perspective.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>For example, why does \u003Ca href=\"http://github.com/mangos/mangos/network\">the MangOS project on GitHub have 854 branches\u003C/a>? How is that useful to \u003Cem>anyone?\u003C/em> The project network is so complex it can't even be rendered! What I specifically object to is that all pulls show up in the timeline as forks; I'd like to see an ability to nominate your pull timeline as either private or \"not intended for merging\" so it won't show up in the main network.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Joel is writing a series of articles about distributed version control in \u003Ca href=\"http://mercurial.selenic.com/\">Mercurial\u003C/a> -- I'm hoping they will clear up some of my confusion about GitHub. I personally find \u003Ca href=\"http://code.google.com/hosting/\">Google Code\u003C/a> much easier to work with.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>As part of \u003Ca href=\"http://code.google.com/p/markdownsharp/\">MarkdownSharp\u003C/a>, our open source C# Markdown implementation, I've experimented a bit with turning a regex into a state machine -- and I was a bit shocked how many lines of code it takes to \"unroll\" a regex. Is it really easier to troubleshoot 25 individual lines of state machine code (all with potential bugs) or 3 single line regular expressions?\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Stack Overflow user \u003Ca href=\"http://stackoverflow.com/users/18393/cletus\">William Shields\u003C/a> has taken up Joel's challenge to write a Markdown parser the right way -- and produced an excellent series of articles about what he's learned in the process: \u003Ca href=\"http://www.cforcoding.com/2010/01/jmd-markdown-and-brief-overview-of.html\">one\u003C/a>, \u003Ca href=\"http://www.cforcoding.com/2010/01/more-details-on-jmd-markdown-parsing.html\">two\u003C/a>, \u003Ca href=\"http://www.cforcoding.com/2010/01/markdown-musings-on-unintended.html\">three\u003C/a>, \u003Ca href=\"http://www.cforcoding.com/2010/01/markdown-headings-grief-and-unknown.html\">four\u003C/a>. It's a perfect example of the type of learning that Stack Overflow itself is all about; kudos to William for sharing it!\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Joel and I have mixed feelings about documenting a large code base. Rather than wasting time generating reams of documentation that may never be read, and will rapidly get out of date -- we offer some alternatives. Come up with a unit test suite that lives symbiotically with the code, or spend time documenting the key, central data structures instead of the code. Also, have the new hire guys and gals who encounter the code be in charge of keeping the \"how do I get started with this stuff?\" bootstrapping information up to date.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>Joel says the least amount of work you need to do to capture how many hours are spent on programming tasks, is to make each source code checkin assume that all time since the previous checkin was spent on whatever the current task is. This is \"good enough\" in his experience and produces solid, useful future estimates.\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>At Fog Creek, to determine what features make the cut for the next version of the software they get developers, customer representatives, and the sales team together and do \u003Ca href=\"http://30secondblogs.blogspot.com/2006/10/t-shirt-estimates.html\">T-Shirt size estimation\u003C/a> (S through XXL) of development time for the desired features. Then everyone in the meeting has a dollar to spend on their favorite features. Then, just fit the winners into the allotted schedule.\u003C/p>\n\u003C/li>\n\u003Cli>Stack Overflow is a community driven site, so many (but not all) of the new features come from top voted \u003Ca href=\"http://meta.stackoverflow.com/\">Meta Stack Overflow\u003C/a> requests. We try to avoid devolving into design by committee by heavily weighting feature requests that match our vision for the site. Most feedback is not terribly useful -- but if you're willing to spend the time it takes to filter out the bottom 90% of feedback, you may be pleasantly surprised by the cool ideas the community can come up with.\u003C/li>\n\u003C/ul>\u003Cp>We answered the following listener questions on this podcast:\u003C/p>\n\u003Col>\u003Cli>\n\u003Cp>\u003Cstrong>Dave\u003C/strong>: \"I work at a large company with an enormous code base in many different languages. As a new guy trying to find my way around, I get frustrated by the lack of documentation. How much documentation is appropriate?\"\u003C/p>\n\u003C/li>\n\u003Cli>\n\u003Cp>\"We had a new year's resolution to capture an accurate work log of hours worked, but we've already relapsed. How do the Fog Creek developers manage to do this?\"\u003C/p>\n\u003C/li>\n\u003Cli>\u003Cstrong>Chap:\u003C/strong> \"How do you prioritize features and functionality for your products, and how do you decide what to spend time on and what's worth doing?\"\u003C/li>\n\u003C/ol>\u003Cp>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 \u003Ca href=\"mailto:podcast@stackoverflow.com\">podcast@stackoverflow.com\u003C/a>. You can \u003Ca href=\"http://blog.stackoverflow.com/index.php/2008/05/recording-podcast-questions-using-your-telephone/\">record a question\u003C/a> using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at \u003Cstrong>646-826-3879\u003C/strong>.\u003C/p>\n\u003Cp>The \u003Ca href=\"https://stackoverflow.fogbugz.com/default.asp?W29122\">transcript wiki\u003C/a> for this episode is available for public editing.\u003C/p>","html","2010-01-21T12:00:00.000Z",{"current":396},"podcast-80",[398,406],{"_createdAt":399,"_id":400,"_rev":401,"_type":402,"_updatedAt":399,"slug":403,"title":405},"2023-05-23T16:43:21Z","wp-tagcat-company","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":404},"company","Company",{"_createdAt":399,"_id":407,"_rev":401,"_type":402,"_updatedAt":399,"slug":408,"title":410},"wp-tagcat-podcast",{"current":409},"podcast","The Stack Overflow Podcast","Podcast #80",[413,419,425,431],{"_id":414,"publishedAt":415,"slug":416,"sponsored":12,"title":418},"28e560af-f0aa-4d46-bd90-f435ad604aa7","2026-06-26T14:00:27.102Z",{"_type":10,"current":417},"paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains","Paging Charity! How can engineering leaders avoid becoming Bond villains?",{"_id":420,"publishedAt":421,"slug":422,"sponsored":12,"title":424},"4b22c2a3-3779-4966-93eb-5230391dbdce","2026-06-23T14:08:58.595Z",{"_type":10,"current":423},"your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem","Your AI shipped a backend that boots. That is the whole problem.",{"_id":426,"publishedAt":427,"slug":428,"sponsored":12,"title":430},"5cf362e1-fe7b-45af-b69c-914731c6a052","2026-06-23T14:00:00.000Z",{"_type":10,"current":429},"the-2026-developer-survey-is-now-open-for-human-developers-only","The 2026 Developer Survey is now open (for human developers only)!",{"_id":432,"publishedAt":433,"slug":434,"sponsored":12,"title":436},"30b995f7-7cb9-4dd8-bf71-d0685940a32b","2026-06-19T14:00:00.000Z",{"_type":10,"current":435},"dispatches-from-o-reilly-from-capabilities-to-responsibilities","Dispatches from O'Reilly: From capabilities to responsibilities",{"data":438,"sourceMap":-1},{"count":439,"lastTimestamp":12},0]