Comments on: Looking for tips on how to learn as quickly as possible http://www.fuzzylizard.com/archives/2007/05/02/881/ My thoughts on Agile, Java and Ruby on Rails (mostly) Thu, 04 Dec 2008 01:33:51 +0000 http://wordpress.org/?v=2.6.5 By: Shane http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12616 Shane Thu, 03 May 2007 19:36:42 +0000 http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12616 Hi, as a person who kept found himself in that situation in last job because of nature of the consulting business, I really appreciated a developer on the team take time to triage the bugs to decide which ones are good for new member to work on. The new member should be the driver during the pair but the bug should be isolated. For example, if it is just a bug about not validating the input fields on the UI, then maybe it is a good one to learn about the web framework the project is using. Needlessly to say, it is easy to say than get done, which is why I always appreciated it when someone puts in the effort. Hi, as a person who kept found himself in that situation in last job because of nature of the consulting business, I really appreciated a developer on the team take time to triage the bugs to decide which ones are good for new member to work on. The new member should be the driver during the pair but the bug should be isolated. For example, if it is just a bug about not validating the input fields on the UI, then maybe it is a good one to learn about the web framework the project is using.

Needlessly to say, it is easy to say than get done, which is why I always appreciated it when someone puts in the effort.

]]> By: Andy P http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12613 Andy P Thu, 03 May 2007 14:59:16 +0000 http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12613 Ideally, the person who is reporting the bug knows the domain. In this case, the bug report should give you: - Some context on what they were doing - The steps taken to reach the point at which the bug occurs - The step that causes the bug to occur - The nature of the bug (eg. unexpected output) and what should have happened (eg. the expected output) With this information it should be possible to recreate the situation for yourself. With your test copy you can trace through the program path and see if there is anything untoward, and if there is, you can fix it. This way, you learn the code, the domain and where the bugs are likely to lie in small iterations :-) Also, you get to know which people write the best bug reports. Ideally, the person who is reporting the bug knows the domain. In this case, the bug report should give you:
- Some context on what they were doing
- The steps taken to reach the point at which the bug occurs
- The step that causes the bug to occur
- The nature of the bug (eg. unexpected output) and what should have happened (eg. the expected output)

With this information it should be possible to recreate the situation for yourself. With your test copy you can trace through the program path and see if there is anything untoward, and if there is, you can fix it.

This way, you learn the code, the domain and where the bugs are likely to lie in small iterations :-)
Also, you get to know which people write the best bug reports.

]]> By: Carlos Villela http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12612 Carlos Villela Thu, 03 May 2007 13:08:38 +0000 http://www.fuzzylizard.com/archives/2007/05/02/881/#comment-12612 One thing that's helped me immensely was to recursively do a Find Usages on whatever I was looking at, until I reached the bottom of the stack. Then I'd make my way back again by (in IntellIJ or Eclipse) ctrl-clicking on whatever seemed important to the task at hand. Do that a few times and you can already start sprinkling any code with a few notes and TODOs, or even spot opportunities for testing that were previously missed. One thing that’s helped me immensely was to recursively do a Find Usages on whatever I was looking at, until I reached the bottom of the stack. Then I’d make my way back again by (in IntellIJ or Eclipse) ctrl-clicking on whatever seemed important to the task at hand.

Do that a few times and you can already start sprinkling any code with a few notes and TODOs, or even spot opportunities for testing that were previously missed.

]]>