This is the fifteenth episode of the StackOverflow podcast, wherein Joel and Jeff discuss the following:
- A brief discussion of our shoestring budget, and the project schedule. The beta for Stack Overflow is close; we will likely be trickling people in by the end of the month.
- Strategies for handling recurring or background tasks in ASP.NET. We have a simple method that works for now.
- Being a stellar software developer does not necessarily equate to being a stellar manager of software developers. Promoting your best coders is not always the best strategy. We highly recommend Peopleware and Managing Humans: Biting and Humorous Tales of a Software Engineering Manager. If you're a manager, staple these books to your face! Live it, learn it, love it! If you know someone who is a manager of software developers, staple these books to their face. They're that important.
- Joel's essential time management tip: get things done by not reading Getting Things Done. Personally, my time management is terrible, but I do have one guiding principle: produce some kind of small public artifact every day. We can recommend Merlin Mann's excellent site 43Folders, which is sort of a long running geek love letter to that book.
- I argure that regions are the GOTO of code formatting. I navigate in Visual Studio using search as my metaphor. Between CTRL+I incremental search and CTRL+SHIFT+F find in project, I'm never more than a few keystrokes away from whatever code I need to see. Your code is full of highly unique keywords, just like the web is full of unique search terms.
- Joel and I both agree: one of the most effective coding practices you can adopt on your team is interactive, sit-down-with-your-coworker code review. 90% of the things you will learn have nothing to do with the code. I believe programming is a far more social activity than most realize. If you write code, and nobody but you ever sees that code -- did you really extract all the benefit from writing that code?
- When it comes to interviewing software developers, it seems there are two classes of interviews: the kind where the interviewee gets to drive, and the kind where the interviewer does all the driving. Try to have a game plan for both types of interviews. Be yourself, build a portfolio, and actively study the company you're interviewing at. For some interviews, you really do need to prepare -- practice, practice, practice!
- We can't talk about programming interviews without mentioning classic interview puzzles and the book How Would You Move Mount Fuji?
- On the amazing power of lambda expressions, delegates, and anonymous methods. Fun stuff!
- If ACME is in the business of developing explosive widgets, is it unreasonable for them to inevitably outsource their software development to Coders R Us? If you're serious about software engineering as a career, you deserve to work at a company that is serious about software engineering, too. This usually means choosing to work for a company where software is at the core of their business model. See Joel's Talk at Yale.
We answered the following listener questions:
- Gordon Milne: "I have an opportunity to pursue a more manegerial role; how do you feel about making the transition from developer to being responsible for other developers?"
- Jason Zimpelmann: "What sorts of time management skills do you use?" and "What about that posting on region blocks?"
- Aviv Ben-Yosef: "Should code review be done alone via email or in person?"
- David McGraw: "What advice would you give college graduates who are interviewing for programming jobs?"
- Adam Haile: "How do you handle pointers to functions in the .NET world?"
- Matías A. Bellone: "Outsourcing has been putting food on my table for the past few years. What are your feelings on this?"
If you’d like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to firstname.lastname@example.org. You can record a question using nothing but a telephone and a web browser.
The transcript wiki for this episode is available for public editing.