At a client, last week I’ve organized an internal training, in the form of a discussion about this article: Testing is hard - just do it Our thoughts When a bug is found, prove it exists with a test This immediately reduces defect rate: the same regression cannot be introduced again fix a bug a second time If fixing a bug (having defects in your code) was ‘waste’, as defined by lean methodologies, it also is wast fixing it for the following times

I have seen this video: [Nothing is something][video] by [Sandi Metz][sandimetz], as I saw it recommended [here][recommendation] In the video, she talks programming in this fashion: (it is a stack, not an unordered list) Abstraction seeking Message centric Condition Averse Smalltalk Infected Not here to change the language but change you This is a pattern I’ve also heard from [Alvaro Videla][old_sound], where he said that other, more powerful languages can change your mind and help you bring some of those concepts to your own language.

At a client, today I’ve done an internal training on angular js: we’ve prepared some slides and a live demo. The repository with all the information can be found here. Apparently, the training has been a success, given that most of the talent in the team is backend focused (as opposed to full-stack) and changing from java to javascript is not straight-forward. Note: this post has been created a posteriori, dated with the correct training timestamp.

In the prologue of the book, while thanking everyone that has made the book possible: […], none of the people mentioned here would be responsible for any inaccuracy that might exist in the book, as this responsibility is exclusively mine Mihaly Csikszentmihalyi (translated)1, prologue of “Flow” (More posts on this same book, here) This connects with what Dan North said in the Craft Conf about this idea of the “I’m the only one in the company producing good quality work, the rest are not doing the same”.

At the Craft Conf 2015 I saw someone with the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye and asked them about the book. After praising the contents, they asked me how to approach the book. I recalled reading it non-sequentially, and explained it to them: Read the introduction, preface, etc first When you get to the patterns, pick one at random 10: Read it and navigate through the see also.

When I went to the Jason Gorman’s TDD workshop (experience report here), he said something interesting regarding refactor and TDD: In job offers / advertisements, TDD is much more in demand than refactor. But the latter is included in the former as an integral part. Jason Gorman I agree with the second thought: you cannot properly do TDD without refactoring, as it is an integral part; also the third phase.