Every now and again, I think it would be great to\u00a0do some coding, to give up this infrastructure stuff (or at least to give up the management stuff) and solve problems\u00a0programmatically for\u00a0a living. \u00a0Unfortunately, I also have a mortgage to pay, and certain expectations on\u00a0living standards, so rewinding my career 20 years and starting again is probably not an option right now…<\/p>\n
Even so, I took a C# course on PluralSight<\/a> and, last\u00a0month, I attended the Code Dojo that my colleague Steve Morgan (@smorgo<\/a>) was running for some of the developers in\u00a0Fujitsu’s UK Microsoft\u00a0Practice.<\/p>\n Dojo<\/a>\u00a0is a Japanese word that means “a place of the way” with various explanations including a place where a group of people stay to discipline themselves. \u00a0So, it follows that a Code Dojo is a place where a group of software developers come together to be enlightened.<\/p>\n Our\u00a0Code Dojo focused on a Kata<\/a>, which is another Japanese term that literally means “form” – i.e. describing patterns of movements practiced solo or in pairs. \u00a0In this case, the pattern\u00a0that we followed was one of Test Driven Development (TDD)<\/a>. \u00a0We used TDD to implement a software solution to a given set of requirements but, like all projects, the requirements start off incomplete and there are new requirements received at each stage of the project.<\/p>\n We each took it in turns to write code (even me), with the rest of the group observing and offering help where necessary. \u00a0The principle of TDD was used to write unit tests that are machine-executable expressions of requirements.<\/p>\n First, we wrote a test for a single requirement and then attempt to run it. \u00a0It should fail\u00a0because the requirement isn’t implemented so we wrote just enough<\/em> code to satisfy the requirement (and no more). \u00a0The next step is to run all\u00a0tests and, if any fail, fix the failing tests or the implementation until everything works. \u00a0Finally, we refactored the code to make it more maintainable and supportable.<\/p>\n Very quickly, we had grasped the TDD mantra of “red, green, refactor” – i.e. at least one test fails, fix the code to pass the tests, then improve the code but tests must still pass.<\/p>\n The event was over all too quickly, and we ran out of time, but it was certainly worthwhile – and a great education for me. \u00a0we used C# and Visual Studio but really you could use any language to apply the principles and I really should give it another go at home.<\/p>\n Well done, @markwilsonit<\/a>. You didn\u2019t disgrace yourself writing C# code, today :-)<\/p>\n \u2014 Steve Morgan (@smorgo) May 1, 2014<\/a><\/p><\/blockquote>\n