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


  • 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.
  • 1
    hi ranga, you might want to restrict the class room strength to under 25. Jan 18, 2012 at 10:01
  • I would add stress on using comments & javadoc in code (could be part of clean code section). Jan 18, 2012 at 10:55

6 Answers 6


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.


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.

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.

  • +1 for suggestion on Books. I'm planning to make books available to Programmers to take home and bring them back for the next session. Jan 17, 2012 at 8:44

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.

  • Thanks for reply Sathish. +1 for Refactoring & Clean Code. Jan 17, 2012 at 16:54

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!

  • Thanks for the input Morpheus. I've not tried this before but I have a feeling that I'm more effective coding and practicing coding in the morning. I'm more tired in the afternoon and would really like to do stuff which is lightweight. I will try both and assess. Jan 17, 2012 at 8:43

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.