What is the best way to structure workshops for starting programmers?

Question

We are planning to organize programming workshops for Java web developers with basic coding but no design experience. The goal of the workshops is to introduce these programmers to clean code.

Focus Areas:

• TDD
• Four Rules of Simple Design
  • runs all the tests
  • contains no duplications
  • expresses the intent of the programmers
  • minimizes the number of classes and methods

Structure:

• 6 full day coached workshops spread over 3 months using pair programming and pair-switching
• Each workshop contains
  • four 15 minute presentations/demos
  • four 90 minute problem solving exercises
  • 4 minute pecha kucha's by every programmer

Planned Katas for first workshop:

• prime numbers
• bowling game
• tennis scoring
• Arabic to Roman numerals conversion
• prime factors

Do you think this is a good way to structure a programming workshop? Are there any elements that I could introduce to the workshops to make them more interactive and create more interest among developers?

Edit 1: Summary of the feedback

• Create an interest in reading books.
• Have real project examples.
• Have contact with the group during off days.

Answer 1

Sounds like you're on the right track, but for students to really get the material and use it day to day you need to have some time where they can bring in their real code from their day job or whatever, and practice on that.

Answer 2

The focus areas and structure sound good. Some thoughts:

• Since once key is to introduce people to clean code, ensure that every single piece of example code is actually clean unless you're using it as a negative example. Seems like a no-brainer, but often bad code sneaks in and ruins your ethos (reputation) as an instructor.
• Use negative examples in a constructive way. Showing negative examples, especially when they don't belong to anyone in the group, is often a way to get group buy-in to the process, allows for some good brainstorming ("why on earth did they do X?" and so on) without it looking like you're attacking any one learner in the group. You can start with finding just the worst possible example ever, but then make other negative examples less difficult to critique as the workshops move forward.
• Having participants be responsible for some of the content (via pecha kuchas) is a good idea. This will help them become good communicators about development in addition to the content they're learning.
• Tie exercises, presentations, examples, to the work they're doing "for real" wherever possible.
• Try to have some sort of check-in or contact with the group during the off weeks (the weeks between the workshop meetings) -- maybe something to hold them accountable to the continuation of the learning experience, if even just a blog post or an addition to a group wiki.

Answer 3

This workshop sounds solid. I would definitely make sure there are documents or 'take-home' suggested readings. Some may argue that attendees will not read the materials you give them, but I contest that if it is interesting, and there is value added, the developers will follow through. The Head First Design Patterns book is fantastic, and a super fun read. Maybe introduce excerpts from there, and allow the developers to see its value, and then suggest they read it in between sessions. It averages $25 (I think) and is worth every penny.

Answer 4

This workshop will perfectly match the goal. There are some good books avaiable in the market like TDD approach by Kent Beck, Refactoring - Improve the Design of Existing Code - Martin Fowler, Clean Code - A Hand book of Agile Craftman Ship by Robert C.Martin. You should recommend the attendess to go through book where in these concepts have described in detail bocz we cant cover everything in single workshop.

Answer 5

Sounds perfect to me, I've had experiences organizing one. I'd recommend having sessions on morning followed by a design example and then developing the test cases for the same design in the afternoon.(something like that to be cohesive with the pattern of teaching). I have had hands-on session on the morning and had received complaints from candidates in the past requesting the hands-on session to be handled on the afternoon rather than on morning.

The feedback also stressed on more time on hands-on because people get more doubts that way than understanding something on theory. Hope it helps :) Good luck!

Answer 6

You might also try dividing the group into sub-groups, say 4 groups of 4, give everyone the same basic programming task, then shuffle the code to another group and have every group add some additional functionality. It will show them the importance of writing maintainable code better than any long-winded lecture.