Short version: what would you tell someone who was trying to improve at ______ ? (see last sentence of email)
This last fall at SCNA in Chicago, I presented findings from my class "The Craft of Software Development" where each master student studying software engineering created a learning plan designed to work on an area of known weakness to further themselves in our craft. I appreciated the community's feedback about my class. (If you don't remember me, we also did some dancing at the start of my session. You were magnificant.)
This year, I'm asking for your input on my students' learning plans. If you have personal experience in one of these learning areas (or have guided an apprentice), I'd love to get your input.
What is something that has worked for you to become more of an expert in the named area?
(I've debated how to present this request to this group. There are eight topics. Perhaps it is better to have one email with everyone replying to it. Perhaps it is better to have eight email threads where people who only care about TDD can just offer advice on how to get better at TDD. Because there hasn't been a lot of traffic on this mailing list recently, I've decided to post four emails today and four emails tomorrow. If this was a colossal lack of judgement on my part, please mute any thread that you aren't interested in. And I'm sorry.)
I really appreciate your time and input,
Todd Sedano Director of Software Engineering Carnegie Mellon University Silicon Valley Campus Developing Software Leaders (TM) T: 650-335-2812
*For me Software Craftsmanship includes the notion of 'Test-driven development'. I have always written unit tests after writing the code. So TDD literally turned my software development model upside down. **I am trying to use TDD but when I face a complex software problem, I find myself reverting back to code first and test later. This is mostly because my productivity is severely hampered due to my lack of experience in thinking the TDD way. What does the community think will help me improve in this area?* * * *
On Thu, Mar 22, 2012 at 4:15 PM, Todd Sedano <todd.sed...@sv.cmu.edu> wrote: > For me Software Craftsmanship includes the notion of 'Test-driven > development'. I have always written unit tests after writing the code. So > TDD literally turned my software development model upside down. I am trying > to use TDD but when I face a complex software problem, I find myself > reverting back to code first and test later. This is mostly because my > productivity is severely hampered due to my lack of experience in thinking > the TDD way. What does the community think will help me improve in this > area?
Practice practice practice.
Find a catalogue of katas and do one everyday for a week. Focus on picking the next smallest test. My guess is you'll do well with the first couple of trivial tests, then write a big test and hash around until it passes. When you find yourself hashing around, stop, delete the test, and look for a test that lets you take a smaller step.
On Sat, Mar 24, 2012 at 4:26 PM, Curtis Cooley <curtis.coo...@gmail.com> wrote: > On Thu, Mar 22, 2012 at 4:15 PM, Todd Sedano <todd.sed...@sv.cmu.edu> wrote: >> For me Software Craftsmanship includes the notion of 'Test-driven >> development'. I have always written unit tests after writing the code. So >> TDD literally turned my software development model upside down. I am trying >> to use TDD but when I face a complex software problem, I find myself >> reverting back to code first and test later. This is mostly because my >> productivity is severely hampered due to my lack of experience in thinking >> the TDD way. What does the community think will help me improve in this >> area?
> Practice practice practice.
> Find a catalogue of katas and do one everyday for a week. Focus on > picking the next smallest test. My guess is you'll do well with the > first couple of trivial tests, then write a big test and hash around > until it passes. When you find yourself hashing around, stop, delete > the test, and look for a test that lets you take a smaller step.
> -- > You received this message because you are subscribed to the Google Groups "software_craftsmanship" group. > To post to this group, send email to software_craftsmanship@googlegroups.com. > To unsubscribe from this group, send email to software_craftsmanship+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
The 'Why' tab in Jon's cyber-dojo is a great example of reflective practice, and such higher-order thinking skills would be beneficial to improve on pretty much any topic. It also highlights very important points such as deliberate practice needing to be free of that 'on the job' attitude towards finishing tasks ([...] my productivity is severely hampered [...]), and collaboration.
cheers, José
On 24 March 2012 17:21, Jon Jagger <j...@jaggersoft.com> wrote:
> And > http://www.cyber-dojo.com > should help you practice. > Cheers > Jon > P.S. Love the Schwarzkopf quote Curtis
> On Sat, Mar 24, 2012 at 4:26 PM, Curtis Cooley <curtis.coo...@gmail.com> wrote: >> On Thu, Mar 22, 2012 at 4:15 PM, Todd Sedano <todd.sed...@sv.cmu.edu> wrote: >>> For me Software Craftsmanship includes the notion of 'Test-driven >>> development'. I have always written unit tests after writing the code. So >>> TDD literally turned my software development model upside down. I am trying >>> to use TDD but when I face a complex software problem, I find myself >>> reverting back to code first and test later. This is mostly because my >>> productivity is severely hampered due to my lack of experience in thinking >>> the TDD way. What does the community think will help me improve in this >>> area?
>> Practice practice practice.
>> Find a catalogue of katas and do one everyday for a week. Focus on >> picking the next smallest test. My guess is you'll do well with the >> first couple of trivial tests, then write a big test and hash around >> until it passes. When you find yourself hashing around, stop, delete >> the test, and look for a test that lets you take a smaller step.
>> -- >> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group. >> To post to this group, send email to software_craftsmanship@googlegroups.com. >> To unsubscribe from this group, send email to software_craftsmanship+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "software_craftsmanship" group. > To post to this group, send email to software_craftsmanship@googlegroups.com. > To unsubscribe from this group, send email to software_craftsmanship+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
To improve at TDD, practice! Remove yourself from needed to accomplish something for a teacher (or professor) and tackle a problem with strict adherence to the three laws of TDD. ( http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)
Katas (practicing someone else's solution to a problem) is a fantastic way to practice, as are code retreats.
It's helpfully to remove yourself from the problem you are trying to solve itself to practice just the technique.
On Thu, Mar 22, 2012 at 6:15 PM, Todd Sedano <todd.sed...@sv.cmu.edu> wrote: > Short version: what would you tell someone who was trying to improve at > ______ ? (see last sentence of email)
> This last fall at SCNA in Chicago, I presented findings from my class "The > Craft of Software Development" where each master student studying software > engineering created a learning plan designed to work on an area of known > weakness to further themselves in our craft. I appreciated the community's > feedback about my class. (If you don't remember me, we also did some > dancing at the start of my session. You were magnificant.)
> This year, I'm asking for your input on my students' learning plans. If > you have personal experience in one of these learning areas (or have guided > an apprentice), I'd love to get your input.
> What is something that has worked for you to become more of an expert in > the named area?
> (I've debated how to present this request to this group. There are eight > topics. Perhaps it is better to have one email with everyone replying to > it. Perhaps it is better to have eight email threads where people who only > care about TDD can just offer advice on how to get better at TDD. Because > there hasn't been a lot of traffic on this mailing list recently, I've > decided to post four emails today and four emails tomorrow. If this was a > colossal lack of judgement on my part, please mute any thread that you > aren't interested in. And I'm sorry.)
> I really appreciate your time and input,
> Todd Sedano > Director of Software Engineering > Carnegie Mellon University > Silicon Valley Campus > Developing Software Leaders (TM) > T: 650-335-2812
> *For me Software Craftsmanship includes the notion of 'Test-driven > development'. I have always written unit tests after writing the code. So > TDD literally turned my software development model upside down. **I am > trying to use TDD but when I face a complex software problem, I find myself > reverting back to code first and test later. This is mostly because my > productivity is severely hampered due to my lack of experience in thinking > the TDD way. What does the community think will help me improve in this > area?* > * * > *
> *
> -- > You received this message because you are subscribed to the Google Groups > "software_craftsmanship" group. > To post to this group, send email to > software_craftsmanship@googlegroups.com. > To unsubscribe from this group, send email to > software_craftsmanship+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/software_craftsmanship?hl=en.
