The Stack Overflow Podcast

This is the 41st episode of the StackOverflow podcast, where Joel and Jeff sit down with Robert Martin aka "Uncle Bob", and discuss software quality, the value of software engineering principles, and test-driven development.

Joel clarifies that some of his comments in Podcast #38 were a bit unintentionally ad-hominem, and apologizes to Uncle Bob for that -- see Bob's open letter blog post. But on the positive side, it did get us a podcast with Uncle Bob!

This was a big week for Stack Overflow; we moved to a new hosting provider -- PEAK Internet in Corvallis. We did have a few blips with DNS but other than that the move was relatively smooth.

Increasing our servers from 4 GB (web) and 4 GB (database) to 8 GB and 24 GB, respectively, opened up tons of breathing room and unleashed a lot of latent performance. Memory is incredibly cheap right now; there's no reason not to install ridiculous amounts. It is (almost) free performance. Bob reminisces about when he bought memory by the bit!

When I said "quality doesn't matter", I didn't mean it literally. If you deliver a software product that nobody likes or wants to use, it doesn't matter how great the quality of your code is. You can always fix code quality -- but fixing "nobody gives a crap about our product" is far more difficult. That's what you should be worrying about most of all.

Quality has many dimensions. The cleanest code in the world could utterly miss the point on usability, scalability, performance, and meeting users' expectations.

On the other hand, as Bob points out, there are companies that have shipped broken products which permanently damaged their reputations and, in some cases, even forced themselves out of business.

Bob's SOLID principles are based on some well known conventions. I talked about the first one, the Single Responsibility Principle, in Curly's Law: Do One Thing. You may have heard this before as Don't Repeat Yourself (DRY), Once and Only Once, or Single Point of Truth.

We wonder if some of these guidelines -- such as "deploy independently" -- are obviated by the inevitable forward march of technology, such as software delivered through the cloud, and virtual machines.

What happens when principles fall into the hands of people who don't really know what they're doing? Or people who become bureaucrats, rigidly enforcing rules on everyone? We think the existence of rules, in and of itself, isn't necessarily a net good. The types of developers who need those rules are often immune to them.

Often, software developed internally doesn't have to be good; users are forced to use it. This software would never survive as a real product that had users who actually had to want to pay for and use the software. Bob is fond of asking "why is open source software so much better"; part of the reason is that this software has to survive in the real world on its own merits to garner users and attentions. It's not isolated on some peculiar little corporate Galapagos island where it has no competition.

Joel worries that excessive TDD (say, going from 90% to 100% test coverage) cuts time from other activities that could benefit the software product, such as better usability or additional features users are clamoring for.

Unit tests are absolutely useful as a form of "eating your own dogfood", and documenting the behavior of your system. Even if you disregard the actual results of the tests completely, they're still valuable as documentation and giving you a fresh outside perspective on your codebase.

Joel notes the difficulty of testing the UI (web or executable) versus testing the code behind the UI. The classic method of doing this is probably documented in The Art of UNIX Programming, where you start with a command-line app that takes in and spits out text. The GUI is simply a layer you paste on top of the command-line app, which leads to perfect testability -- but perhaps not such great apps, in the long run. Which is...

This is the 40th episode of the StackOverflow podcast, where

Joel and Jeff sit down with Michael Lopp, aka Rands, to discuss how a geek manages other geeks, the dangers of working remotely, the pitfalls of offshoring, and some techniques for continual learning.

You may know Michael Lopp from his excellent blog, Rands in Repose. We highly recommend the Best Of category if you haven't visited Rands before. Heck, even if you have.

Rands is a Manager of Humans, and many of the entries on his blog are a fantastic resource for other Managers of Humans. "A lot of people stuff on a daily basis, it's 60 to 70 percent of my day." He wrote a book on this topic, Managing Humans: Biting and Humorous Tales of a Software Engineering Manager.

If you transition from being a software developer to a manager, you will almost never write code. As a manager, how do you balance writing code -- if only as a form of daily exercise, to keep your skills sharp -- with the rest of what you do?

The #1 management skill? Listening. Which means Joel and I should probably never be managers.

The magical number of people one person can manage without having serious problems is seven. Beyond that, you're probably not giving the people on your team enough attention.

On managing geeks and nerds: it should be done systematically. They like structure, and you have to put that around this messy business of us being human beings. Perhaps the handbook will be of use.

Leading by example can only get you so far. What do you do when you inherit the world's best programmer in some language you don't even know? It's much more hands on than that. Your strengths are not your team's strengths.

Building a so-called Nerd Playground is one way to attract talented developers. But as Joel says, "10% of the joy of coming in to work is that it's a great place to work, and 90% is that I love these people."

The danger of working remotely is that there's a lot of non-verbal communication that typically goes on. Our tentative recommendation for working remotely, if you must do it, is to have frequent intervals where you all come together multiple days and work together. In order for the remote relationship to work, there has to be a face to face relationship in place to support it.

Michael asks about the Stack Overflow badge system, which was explicitly modelled on the Xbox 360 Achievements system. The Bronze, Silver, and Gold badges are there to support beginners, intermediates, and the hardcore respectively. The idea that you have to figure out why you got a badge is there very much by design; the mystery is part of the fun.

There were complaints that answers came too fast on Stack Overflow, which we have hopefully addressed -- there is an art to answering questions quickly and effectively. If anything, Stack Overflow "games" you into learning how to progressively answering other people's questions more and more effectively over time. How, exactly, is this a bad thing?

A brief discussion of offshoring. "If people were getting as much value out of remote developers as local developers, then the price would be the same." It's also difficult to get good results out of teams when their skin isn't in the game.

While I am deeply uncomfortable with using Stack Overflow as a hiring tool, it is totally reasonable to use it as a "breadcrumb trail of your awesomeness" as a programmer. If your questions and answers are well written and clear, and getting upvoted by your peers, that is something to be proud of.

How do you manage continually learning? Reading, writing, and practice of the things you enjoy. It is possible to take this too far, though, and become a magpie developer. One advantage of older developers is that they have more failures under their belt.

Michael looks for a combination of ego and humility when he hires -- these are somewhat contradictory traits, but they balance and complement each other.

Our favorite Stack Overflow ques...

This is the 39th episode of the StackOverflow podcast, where Joel and Jeff discuss database design and the shell game of performance, the value of short, focused presentations, and the importance (or not) of a prestigious degree for software engineers.

Joel insisted that we run the stackoverflow.com books on QuickBooks. I was more open to using an online accounting solution, but we were worried about someone holding our business finances hostage. Joel also maintains that "every accountant in the world knows QuickBooks". I'm not happy about it, but small business reality.

Now that we can (theoretically) afford to pay ourselves to work on the site, we deployed two new features: reputation bounties on questions and new reply notifications.

Joel expresses some concern about the value of panel discussions at conferences. There are lots of variables: who is on the panel, what are the topics, and how skilled is the moderator? It's almost better to give each person on the panel a 10 minute window to talk about some topic they think will have value for the audience.

I often think of small, focused presentations as "Grok Talks". One presentation format which hews closely to this model is Pecha Kucha. It's generally a good idea to err on the side of keeping it small. The larger the talk, the more material you should have whittled away and deleted to get it down to size.

In building Stack Overflow, we copied a key part of the Wikipedia database design. This turned out to be a mistake. We are due for a massive database refactoring, which is going to be very painful, but it is necessary to avoid excessive joins in a lot of our key queries.

We also begin to appreciate why the giant multi-terabyte table schemas (like Google's BigTable) are completely join-free, basically simple hashtables or tuples spread across a server farm.

My benchmarking shows that CPU speed is surprisingly important on our database server. Going from 1.86 GHz, to 2.5 GHz, to 3.5 GHz CPUs I see an almost linear improvement in typical query times! The exception is queries which don't fit in memory, but right now with 4GB RAM most of our DB fits in ram; with the new 24GB RAM server I expect the database to be entirely in memory for quite a while.

Joel talks a bit about queueing theory, and its relation to OS scheduling. I propose that performance is a shell game with bottlenecks, where you're constantly trying to decide whether the bottleneck should be memory, CPU, or I/O.

More discussion about unit testing: when it's appropriate, when it isn't, and what it is for. Remember, 100% code coverage (or even 90% code coverage) is not free. You're playing another shell game, so decide what axes of that resource balancing equation are important to you. Perhaps the greatest risk is being dogmatic about it.

If you enjoy this podcast, you might also enjoy Hanselminutes -- Joel gives it his seal of approval!

Joel revisits the SOLID principles, and compares them to designing replaceable batteries, or a headphone jack, into your product. Appropriate in some narrow cases, but not all the time. Imagine a consumer product where every single part of it could be plugged in and replaced with another compatible part. Is that realistic?

Perhaps new language features will advance programming a lot faster than any given set of programming principles, no matter how good they are. I've often thought that design patterns are how languages evolve.

Joel says you don't have to go to a prestigious name brand school, necessarily, but you need to choose schools that have a rigorous selection process. "These people are a tiny little bit more likely to succeed at our rigorous selection process." I concur -- if you aren't seeking out challenges, whether they are large, small, or somewhere in-between -- what are you doing?

Our favorite Stack Overflow questions this week are:

Jeff: Is mathematics necessary for programming? It can't hurt, and often helps,...

This is the 38th episode of the StackOverflow podcast, where Joel and Jeff discuss YSlow optimizations for large websites, the value of unit testing, and the hidden pitfalls of asking questions to programmers.

Joel notes that simply paying attention to what your coworkers are doing is an effective way to build and lead a team. If you aren't interested in what your teammates are doing.. why are you on that team, again?

I've followed the excellent Yahoo YSlow tool for a while. It really is intended for large scale websites, as I've noted before. But Stack Overflow is exactly the type of website that can benefit from YSlow recommendations!

We've been using the Expires or Cache-Control Header since we launched. This saves the browser round-trips when getting infrequently changing items, such as images, javascript, or css. The downside is that, when you do actually change these files, you have to remember to change the filenames. A part of our build process now "tags" these files with a version number so we no longer have to remember to do this manually.

We also integrated the YUI Compressor into our build, to minify our CSS and JavaScript resources. We had bad luck with the .NET port of this tool, so we just shell out to Java in the build. Works great, although we had some crazy pathing issues that made us put the JAR file in the root.

It's also possible for Google to host your shared javascript files, if you're using a popular third party JS library. We chose not to do this because we package related JavaScript together, so it would defeat the benefits of packaging.

Browsers will parallelize their requests, but only so many requests can be "in flight" to the same domain. So it can be wise to split your website components across domains. Simple aliases such as a.mydomain.com seem to work fine for this purpose.

Joel explains CSS sprites, which is an effective way to minimize the number of HTTP requests your website is generating. This is particularly useful on toolbars and the like which contain a lot of related images.

There are analogs here in the Strings tab of Process Explorer, and the UNIX command Strings, as well as classic Windows resource browsing -- spelunking for whatever icons and image resources you can find in a file.

This is all important because I want Stack Overflow to be as fast as possible. Performance is a feature, and I think often underestimated. Even half a second delay can cause a 20% drop in traffic.

We discuss differential database backups and DNS time to live, to make the upcoming site transition to new harware as painless as possible, and minimize downtime. We'll also update the old site with a static HTML page that tells you you need to flush your DNS.

Joel notes that his partner Michael had to order thermal compound back in 2000 when he built up PCs for Fog Creek. This stuff is important! Please don't use vegemite.

We finally fixed our paging algorithm, which had some aggravating edge condition bugs. I dedicate this fix to John Topley.

Joel and I have some reservations about unit testing, at least the dogmatic test-first kind, where your goal is to have code coverage in the 95%+ range. It seems to us that this works best for legacy type applications that aren't changing very much. At some level, the tests become friction preventing you from making changes, as every change results in a stack of failing tests.

Joel talks about Robert Martin's (aka Uncle Bob) Solid Principles, as explained on a recent Hanselminutes podcast. Joel: "it sounded like extremely bureaucratic programming" that "could theoretically protect you against things, but You Aren't Gonna Need It."

On the other hand, if you're building a framework or API, something

designed to be used by thousands or millions of developers, then having

a lot of unit tests -- or Uncle Bob's Principles of OOD -- might make sense. Principles and rules are fine, but thinking about what you're doing should alw...

This is the 37th episode of the StackOverflow podcast, where Joel and Jeff discuss the expansion of Stack Overflow into non-programming IT topics, the pernicious problem of "systemitis", and how to reach the next generation of programmers.

I was star-struck that Alan Kay actually participated in Stack Overflow, both answering a question and even asking a question of his own.

We finally reverse engineered the WMD source code, thanks to the noble and herculean efforts of Dana Robinson. If you're interested you can pull the latest version from Dana's Git repository.

Joel recommends Eric Raymond's Understanding Version-Control Systems. Our (very, very limited) experience with Git emphasizes the importance of editing code with the goal of creating easy to apply patches. If your changes are hard to merge, they're likely to be ignored.

I've been having fun (for particularly small values of fun) configuring and building the new server hardware for Stack Overflow. I was moderately surprised to find that live rebuilding a RAID array with a 500 GB drive takes around 8 hours; rebuilding a simple 1-1 mirror array in offline mode takes 4 hours.

Joel recommends the built in Windows Server Network Load Balancer (nlb); there's also the open source equivalent, HAProxy, which the Reddit guys mentioned in our podcast with them.

We are planning to launch an IT-centric Stack Overflow in the next few months. This will be a place for System Administrator and IT professionals -- people who work with computers in a professional capacity, but aren't necessarily programmers -- can go to get their questions answered.

Our first challenge with the IT-centric Stack Overflow is naming it. Naming is extremely difficult, whether you're naming functions/variables, businesses, websites, or new human beings. We also need to find the leaders and moderators who will drive the community and set the tone for everyone else.

Joel heard the world population of computer programmers is 4 million. I can't find a source for this; does anyone have one?

Joel thinks the current downturn is unlikely to affect the tech sector, except possibly as a broad excuse to cut dead wood out of companies. It's interesting to contrast the Web 1.0 crash in 2000-2001 with the current environment; it certainly doesn't feel the same to us.

Joel and I don't agree with rigidly defined Project Manager, Programmer, and Test roles; how can you judge other people's competency in a particular discipline if you have zero competency in it yourself? Obviously this varies by company and person, but cross-training in related disciplines will make you a better programmer.

Joel talks about "systemitis", programmers who spend the bulk of their time creating giant universal programming solutions to business problems that don't really make sense. This is perhaps a sign of programmers who aren't being challenged in their jobs. Rather than letting them spend their time creating another Universal System, try to recognize systemitis, and encourage these programmers to improve their skills in related disciplines instead of building "the system"

We remember the classic BASIC programming that a whole generation of programmers grew up with. Typing in and modifying these simple little games was our first programming experience, an experience that launched a lifelong career. What is the equivalent for today's young programmers?

Our favorite Stack Overflow questions this week are:

Joel: Significant new inventions in computing since 1980? Joel picked Alan Kay's question, even before Joel knew it was from Alan Kay. We swear!

We answered several listener question on this podcast:

Alfred: "What will happen to the open source movement in a sluggish economy? Will it grow or shrink?"

Shawn: "On the Business of Software: why do companies sell only small personal pizzas instead of individual pizza slices?"

Daniel: "Large companies have...

Joel and Jeff, with special guest Eric Sink of SourceGear, discuss source control present and future, why writing a compiler is an important rite of passage for programmers, and how budding software engineers should be educated.

I was convinced Eric was going to agree with me on whether or not software developers should know C. Unfortunately for me, he agrees with Joel. Doh!

Eric's Source Control HOWTO should be required reading for every software developer. Eric literally wrote the book on this, and in fact this series is being converted into a book. Deservedly so; it's fantastic. The best person to explain source control is someone like Eric who literally wrote a source control system from scratch -- SourceGear Vault.

An extended discussion of the evolution of source control systems, into distributed version control (DVCS) such as Git, Mercurial, Darcs, and BitKeeper. Eric feels Linus Torvalds' video "evangelizing" Git does the opposite for many. He's also uneasy about branching and merging becoming easy, common operations, which is much of the promise of DVCS.

Eric feels DVCS solves certain edge conditions very well, but those edge conditions should only be explored when you feel the need, not promoted as broad feature bullets to the average developer. "The harder you try to explain DVCS, the worse it gets, so stop!"

Eric points to Eric Raymond's evolving Understanding Version-Control Systems as a pretty good survey of today's source control landscape.

Often, features aren't the point -- discoverability is. I was amused to find that Eric discovered how convenient background compilation is in Eclipse. This is something that Visual Basic developers have had for 8 years! Java and C# developers don't appreciate what they're missing because it hasn't been surfaced in the product, until now.

Eric and Joel note that, at some level, source control is about putting obstacles (let's call them safety barriers) in front of developers -- and the question is, how many does your shop need? Do you remember working without version control at all? It's incredibly fast, until stuff gets overwritten or lost, of course.

Joel and Eric maintain that writing a compiler is an important rite of passage for a programmer. There's an enormous class of programming problems where writing a lexer, parser, recursive descent, and parse trees will help you. Once you understand how easy it is to set up a state machine, you'll never try to use a regular expression inappropriately ever again.

Eric also wrote a web browser. It's interesting to contrast the experience of writing a compiler, which is typically extremely strict and will fail to compile if a single character is out of place, versus writing a web browser, which accepts all kinds of malformed and downright incorrect HTML and JavaScript. Eric and Joel think this was categorically a huge mistake; I'm not so sure.

On Postel's robustness principle: "be conservative in what you send, liberal in what you accept." This becomes a painful war of attrition at some level; everybody is vying to accept just a little bit liberally than the next guy, so isn't there an implied element of mutually assured destruction at the end?

Eric: "Computer Science degrees do not teach programming; they teach how to learn". And he's OK with that. We all agree that it's hugely important to complement your computer science curriculum with either hobby projects, internships in the so-called "real world" -- or both! These extracurriculars will improve your chances of landing that first junior developer job.

Congratulations to our new UserVoice community moderators -- Joel Coehoorn and Sean Massa. Do participate on the Stack Overflow UserVoice feedback site, we check it every day, and we read all the feedback we get!

Our favorite Stack Overflow questions this week are:

Eric: What is the single most effective thing you did to improve your programming skills...

This is the 35th episode of the StackOverflow podcast, where Joel and Jeff discuss the mysteries of server hardware, anomalous voting patterns, change fatigue, and whether or not Joel is the Martha Stewart of the software industry.

A discussion of the bizarre world of server pricing, as discussed in the Best (or Worst) Geek Christmas Ever. It is sort of mysterious how a lot of the same hardware parts are is rebranded "server" parts, along with an instant 50%+ markup.

Building your own servers up probably doesn't make any sense from a business perspective, but Joel and I both enjoy learning about this stuff -- and it is critical to our business. I doubt I would personally handle every server we ever use, but the first few, absolutely. I believe understanding the commodity hardware market is important for programmers.

Joel notes that you really, really want to test your RAID failover scenarios before deploying your servers. That's one of the exact reasons I wanted to have the servers here, for me to play with RAID scenarios while the servers are up and running.

After receiving a number of complaints, we now check for anomalous voting patterns on Stack Overflow. I guess it shouldn't be surprising that there were 4x as many anomalous upvote patterns as downvote patterns.

Answers to older questions don't tend to get voted up as aggressively as rapid answers. There's an aspect of the Fastest Gun in the West to our system. Joel and I believe there are two audiences here; the daily users and the long tail. Sometimes a little (or a lot) of patience in order.

We are now reverse engineering the JavaScript based Markdown editor we use on Stack Overflow. Believe me, we don't want to, but we have no choice. If you know JavaScript and/or GIT, we welcome your contribution!

Joel had a great response to a forum post by a programmer thinking of leaving the industry, which I summarized as Programming: Love It or Leave It. Apparently Joel thinks of himself as the Martha Stewart of the software industry? Who am I to judge; listen to the audio yourself.

If you're unhappy with your job as a programmer, it might simply be because your situation is not a good one. If you're in a bad situation, recognize that: either change your organization, or change your organization. Alternately, if you want to have a great 10 to 15 year career goal, why not start your own software company where programmers are able to work under great conditions, building awesome software with their peers?

The Joel on Software discussion forums may soon require (nominal) paid registration, much like MetaFilter. This is something we discussed with Josh Millard, a MetaFilter moderator, on Podcast #22.

Joel and I struggle with the definition of "change fatigue" as a career hazard for programmers. Isn't change the very basis of programming, and the reason most people enter the field? Rather than being a hazard, isn't the continual change a destination? Admittedly, it must be painful to be a specialist and have your knowledge obsoleted; Joel and I are both broad generalists, so it's easier for us.

I discovered a great Stack Overflow post through Damien Katz: Arrays, What's the Point? Good Question. This is a fine example of a question that seems sort of ridiculous on the surface, but can provide amazingly insightful answers -- and a deeper understanding of programming. Jonathan Holland's accepted response has 190 upvotes!

Our favorite Stack Overflow questions this week are:

Jeff and Joel: Arrays, What's the point? This is exactly why we created Stack Overflow; fantastic result. Understanding data structures is as fundamental as it gets -- and so is questioning them.

We answered one listener question on this podcast:

Ian Varley: "A lot of programmers eventually become exhausted by the pace of change in our industry. How do you keep from getting change fatigue?"

If you'd like to submit a question to be answered in our next episode, record an...

Stack Overflow Podcast - Episode #35 by The Stack Overflow Podcast

This is the 34th episode of the StackOverflow podcast, where Joel and Jeff discuss the following:

Joel recommends a pink HDMI cable as a christmas gift for the special ladies in your life. This will go nicely with her pink ethernet cable, pink USB cable.

We've placed an order for our dedicated servers and have found a dedicated host we tentatively like. We'll be exploring the "buy" axis of build vs. buy because it gives us greater power and control over our setup. This will also be my first time building a RAID 10 array, which is supposedly a far better solution than RAID 5, and I'm geeking out a bit over that.

Joel remembers George Orwell's 1984 and The Thin Red Line.

It's advisable for programmers to spend some time rotating through customer support so they can lean to share the customer's pain. Alternately, Joel has an even better idea: perform usability tests periodically, with your developers observing. Developers sometimes come up with great new features when exposed to actual users working with the software.

The Fog Creek Team completed the Endless Setlist on hard in Rock Band 2. That's 84 songs in a row, mightily impressive, at least to me.

I have mixed feelings about easter eggs; if you're going to put something cool and hidden in your product, why not make it a standard feature so most people will find it and benefit from it? There are two discussions of easter eggs on Stack Overflow: What Easter Eggs have you placed in code, and Is it a good idea to put Easter Eggs in applications?

You could argue that a lot of modern large application features are effectively easter eggs because people can't find them! This is what motivated the move to the Ribbon UI in Office 2007. Nine out of ten feature requests for Office were already in the product. That's the ultimate easter egg, and not in a good way.

The proposed Stack Overflow question bounty feature -- to help get those persistently unanswered questions some new attention -- has two gating clauses: first, you can only attach a small reputation bounty after 24 hours; second, the majority of the bounty will come from the asker's own reputation. You have to be willing to slice off a part of your own rep as a reward.

We noticed that Jason Calacanis of Mahalo will be doing a Q&A site. The difference is that this site will pay answerers in real money, part of what Joel calls Jason's Econ 101 management style. The danger is that financial incentives can destroy intrinsic motivation. What's your management style? Command and Control, Econ 101, or Identity?

There is a whole new generation of programmers growing up with code like we did. Here's hoping they're learning from our mistakes, so they can make all new mistakes and not repeat all the same dumb mistakes we made. It's almost like a system of software apprenticeship.

Is code elegance in the eye of the beholder? Consider the two answers to Parameterizing a SQL IN Clause -- which one is more elegant, and why?

Our favorite Stack Overflow questions this week are:

Jeff: How old are you, and how old were you when you started coding? This is a great example of using of Stack Overflow to do cool stuff we didn't anticipate. It also broke our hot question algorithm pretty badly, because it had such a huge number of responses.

Joel: What was your biggest CS eye opener? Joel points to K&R's observation that a[5] and 5[a] are the same thing.

Bonus: Parameterizing a SQL IN Clause. Great example of my accepted answer not being accepted by the community. I just wanted to highlight the cleverness of Joel's solution, which I literally would never have thought of. I ended up using the community's solution, though.

We answered the following listener questions on this podcast:

Chris: "It's often said that the job of the software development manager's job is to insulate developers from customers. But I've found it's helpful for developers to have interacti...

This is the thirty-third episode of the StackOverflow podcast, where Joel and

Jeff sit down with special guest Babak Ghahremanpour, the lead developer for FogBugz.

I gifted the Fog Creek office with a set of cymbals for the Rock Band 2 drums, to complement the sweet Rock Band setup I bought for them earlier this year. And yes, I already got them a tambourine and cowbell.

We're starting to seriously consider buying our own servers and renting rackspace for the Stack Overflow servers. It makes sense to us from both from a financial standpoint and from a performance standpoint. We're also considering some of the cloud services like Amazon EC2 and Windows Azure.

We wonder why so much of the software that's bundled with hardware is so terrible. There's nothing scarier to me as a software developer than the DVD labelled "Install me!" provided with some bit of hardware that I just bought. Why is that?

I tend to agree that one danger sign for a new programming job is the requirement to be on call. This is a bit more normal for sysadmin positions, but it's unusual (and arguably unhealthy) for programmers.

Joel and I note that developing software predisposes you to "debug" real world processes that largely aren't worth the effort. Beware!

We've probably mentioned this before, but whatever else you decide to do with your database, it is incredibly important that you get your database under version control.

Does it make sense for every software developer to start their own company, which is what Paul Graham seems to advocate? It's certainly one of the few paths to becoming very wealthy, if that's your primary goal.

If you just can't get enough Spolsky, Joel was featured on the Startup Success podcast with Bob Walsh and Patrick Foley.

Our favorite Stack Overflow questions this week:

Jeff: Why doesn't IE7 copy PRE CODE blocks to the clipboard correctly? This is sort of cheating because it's my own question, but it's a perfect example of using Stack Overflow to build Stack Overflow! We are the target audience, too.

Joel: Dealbreakers for new programming jobs. Some great responses to this question; worth a read if you're looking for a new job.

Babak: What real life bad habits has programming given you? We alluded to this question in the previous podcast; it's a classic.

We answered the following listener questions on this podcast:

Peter Bailey: "When you're designing a new application, how much code (triggers and stored procedures) do you put in the database?"

Vincent Tan: "What are your top 3 costs in running a software business, and how do you reduce them?"

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.