Over the holiday break I decided to tackle some of the books that I have stacking up next to my bedside. One of them was How Would You Move Mount Fuji by William Poundstone. This was a book that I know some of my colleagues had read already, and they recommended it highly, so I decided it was my turn.
The book was a quick read. The author kept my interest with not only the topic, but also with his concise explanations and his witty comments.
Poundstone describes the history of the intelligence tests, and how it was developed. They were used by our military to determine qualification for different job roles. This led to the popular use of intelligence tests in the corporate world, particularly in the use of Silicon Valley. During the civil rights movement, intelligence tests were determined to have a racial bias in the questions, so were banned as a hiring practice by the federal government.
The ban of intelligence tests did not deter those types of questions from remaining in interviews, however. Looking for more people with minds like Bill Gates, puzzles made their way into the interviews at Microsoft. They have popularized the use of logic puzzles and impossible questions. Poundstone also describes the grueling day-long series of interviews at Microsoft and how you are rated throughout the process.
My most important takeaways from the book was these nuggets of golden advice –
- When the technology you use is changing rapidly, you must hire for problem-solving stills, not just for the technology.
- A bad hiring decision is likely to hurt the company more than a good hiring decision will help it.
- If you ask puzzle questions in your interview, make sure they are worth the effort by asking yourself these two questions:
- Are you willing to hire someone because of a good answer to this question?
- Are you willing to reject someone because of a bad answer?
I highly recommend this book to any hiring manager who plans on asking any puzzle type questions. I also think the book adds insight into the overall interview process, even if you don’t plan on asking them that type of question.
Have you read the book? Do you have an opinion on puzzle questions in interviews? Leave me your feedback and let me know what you think.
As I have said before, debugging is a complex and time consuming process. I have outlined 10 resources for debugging, and provided a primer for things not to do when debugging. Now, we get to the meat and potatoes of debugging. This is a guide of things to do when debugging. I have broken this guide into three sections – a description of the Scientific Method of Debugging, Tips for Hunting for Bugs, and Bug Prevention Methods.
Scientific Method of Debugging
This is a parallel to the Scientific Method that you learned in your grade school science class. The book Code Complete by Steve McDonnell outlines this methodology to debug your applications.
- Stabilize the bug by identifying the simplest test case that reproduces the error
- Locate the source of the bug
- Gather data about the bug and its behavior
- Analyze the data regarding the bug
- Form an hypothesis about the bug
- Write test cases that would prove or disprove your hypothesis
- Run the tests and prove your hypothesis, or begin again with a new hypothesis
- Fix the defect
- Test the fix with all of the new unit tests you have written
- Continue to look for similar, cascading, or peripheral errors
For a more detailed breakdown of the Scientific Method of Debugging, read Code Complete by Steve McDonnell.
Bug Hunting Tips
These tips for finding bugs, broken out into different areas, will help you narrow down where your bug is.
- Be sure to save the original source code
- Be sure the fix the problem, not the symptom
- Make one change at a time
- Check and Double Check your fix
- Consider the possibility that the bug is generated from multiple sources
- Divide and Conquer
- Check other places where bugs have existed
- Check other places where code has changed recently
- Compile the application again
- Insert Trace, Print, or Alert Statements to help track the bug
- Create a logging methodology to trace the application
- Check the Log Files of the servers, etc.
- Search the web for the stack trace
- Design By Contract
- Write unit tests that cause the error
- Try to reproduce the bug in different ways
- Try boundary cases and special cases
More Complex Methods
- Recompile with a different compiler
- Create a mini version of the application
- Sequentialize the Parallel to see if it is a timing or resource issue
- Try the code in different environments (local, dev, test, prod, other developers’ machines, etc.)
- Grab someone else to talk through the bug without looking at the code (explaining the problem may trigger some ideas)
- Do a full, in-depth code review on the broken code
- Rewrite the whole section of code that is causing the bug
- Take a break for a few minutes, or an hour, or until the next day, to give your mind time to process the data
Bug Prevention Methods
These are things that you should be doing during the planning and development of your applications that will help you identify, fix, and test your bugs after you are done with development.
- Identify and track consistent bug types within your own code
- Introduce debugging methodologies early
- Implement loose coupling techniques
- Implement Information Hiding Techniques
- Write a regression test that tests the bug you just fixed
So… these are some different ways to attack debugging. Are there methods that have proven themselves that you have used? Do you take a different, more unique approach to debugging? What have your experiences shown to be your best practices? Please leave your feedback and let me know what you think.
Debugging is a complex and time consuming process. In my last post I listed 10 Resources for Debugging, both web sites and books, that every software developer should read to keep their debugging skills sharp. Knowing what not to do is just as important as knowing what you should do. Here is a list of things not to do when you are debugging your application
- Don’t guess what the problem is
- Don’t dive into making changes without a plan
- Don’t code right away without a thorough analysis
- Don’t fix the shell of the problem, not the problem itself
- Don’t trust line numbers in compiler messages
- In fact, don’t trust the compiler messages at all
- Don’t ignore the value of automated unit testing
- Don’t delete the original code
- Don’t ignore recent changes to your application
- Don’t ignore resources available to you, like the Internet or the Library
This post is a teaser for the one that is to come – what thins should I do when debugging? Is there a more formal process for debugging? What steps should I follow? What things should I look for? What place should I look?