pro git

Is an excellent book by Scott Chacon (isbn 978-1-4302-1833-3). As usual I'm going to quote from a few pages:
Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.
In a DVCS, clients don't just check out the latest snapshot of the files: they fully mirror the repository... Every checkout is really a full backup of all the data.
Conceptually, most other systems store information as a list of file-based changes. These systems think of the information they keep as a set of files and the changes made to each file over time... Git doesn't think of or store its data in this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem... This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
It is important to note that the fetch command pulls the data to your local repository - it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready.
Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike make other VCSs, Git encourages a workflow that branches and merges often, even multiple times a day.
A branch in Git is simply a lightweight moveable pointer to one of these commits.
To switch to an existing branch, you run the git checkout command.
Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves.
In Git it's common to create, work on, merge, and delete branches several times a day.
In Git there are two main ways to integrate changes from one branch into another; the merge and the rebase.
At the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time.
If someone at any point in the history of your project added a single huge file, every clone for all time will be forced to download that large file, even if it was removed from the project in the very next commit. Because it's reachable from the history it will always be there.


management 3.0

is an excellent book by Jurgen Appelo, subtitled Leading agile developers, Developing agile leaders (isbn 978-0-321-71247-9). As usual I'm going to quote from a few pages:
The hierarchy is needed for authorization; the network is needed for communication.
Big species consume more and breed slower.
The Red Queen's Race is an evolutionary hypothesis describing that a complex system needs continuous improvement to simply maintain its current fitness, relative to the systems it is co-evolving with. Some scientists claim that the Red Queen's Race, or the principle of co-evolving species, is an even more important driver of evolution that any other kind of environmental change.
We can consider the internal structure of each system to be a code for the environment and the other species that it is evolving with.
There is no accurate (or rather, perfect) representation of a system which is simpler than the system itself.
We can figure out why the human heart fails (reductionism) but we can never create a heart that won't fail (constructionism).
Managers must learn that they are "in charge" but not "in control".
Recent research has shown that the copying of ideas is the most successful of all strategies.
Uncertainty results in a bias towards self-interest.
Feedback is only feedback when there is a purpose behind it.
Research shows that self-discipline is twice as important as IQ for final grades of students. Effort matters more than talent.
Focus on delivering value.
We need continuous business improvement.


scrum

is an excellent book by Jeff Sutherland, subtitled A revolutionary approach to building teams, beating deadlines, and boosting productivity (isbn 978-847-94108-4). As usual I'm going to quote from a few pages:
The most powerful part of Scrum from his [Jeff Johnson] point of view? Demos.
Scrum is not about the developers. It's about the customers and stakeholders.
I learned a lot about systems theory and how a system only has certain stable states. As a cell evolves, it moves from one stable state to another. Figuring out the rules to move a complex adaptive system from one state to another, and how to make the next state a positive one rather than a negative one, was something I spent nearly a decade on. To change a cell, you first inject energy into the system. At first there's chaos, there seem to be no rules, everything is in flux...
"How many gantt charts have you seen in your career?" I asked.
"Hundreds," he replied.
"How many of them were right?"
He paused. "None."
In business we all too often focus solely on individuals, even if production is a team effort.
It's the system that surrounds us, rather than any intrinsic quality, that accounts for the vast majority of our behaviour.
Every three weeks each team had to demonstrate to their colleagues what it was working on. This was an open demonstration; anyone could come. And if that demo wasn't both working and cool, [MediaLab] directors killed the project.
"Sprints." We called them that because the name evokes a quality of intensity.
Nothing gets moved to Done unless it can be used by the customer.
After engaging for a while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future but, rather, as something that is fundamentally cyclical.
People think in narratives, in stories.
The Product Owner has to be available to the team, to explain what needs to be done and why. While the Product Owner is ultimately accountable for the Backlog, there needs to be a constant dialogue with the team.
Orientation isn't just a state you're in; it's a process. You're always orienting... [OODA]


the genius in all of us

is an excellent book by David Shenk, subtitled why everything you've been told about genetics, talent and intelligence is wrong (isbn 978-184831218-0). As usual I'm going to quote from a few pages:
We're better at stuff because we've figured out how to become better. Talent is not a thing; it's a process.
We do not inherit traits directly from our genes. Instead we develop traits through the dynamic process of gene-environment interaction.
In truth, the [word] 'intelligence' has become a mere vocal sound, a word with so many meanings that finally it has none. [Charles Spearman]
Stability does not imply unchangeability. [Michael Howe]
In 1932, psychologists Mandel Sherman and Cora B. Key discovered that IQ scores correlated inversely with a community's degree of isolation.
Talent is not the cause but the result of something.
People make a great mistake who think that my art has come easily to me. Nobody has devoted so much time and thought to composition as I. [Mozart]
Heritability is a population average, meaningless for any individual person. When someone says that heritability of height is 90 per cent, he does not and cannot mean that 90 percent of my inches come from genes and 10 percent from my food. He means that variation in a particular sample is attributable to 90 percent genes and 10 per cent environment.
Genes don't directly cause traits; they only influence the system.
Genes are probabilistic rather than deterministic. [Michael Rutter]
We have far more control over our genes - and far less control over our environment - than we think.
What would be really interesting for people to see is how beautiful things grow out of shit. [Brian Eno]
The brain circuits than moderate a person's level of persistence are plastic - they can be altered. They key is intermittent reinforcement.


the reason I jump

is an excellent book by Naoki Higashida, subtitled One boy's voice from the silence of autism (isbn 978-1-4447-7677-5). As usual I'm going to quote from a few pages:
The Reason I Jump unwittingly discredits the doomiest idea of received wisdom about autism - that people with autism are anti-social loners who lack empathy with others. (Foreword)
I very quickly forget what it is I've just heard. Inside my head there really isn't such a big difference between what I was told just now, and what I heard a long, long time ago.
What makes us smile from the inside is seeing something beautiful, or a memory that makes us laugh. This generally happens when there's nobody watching us. And at night, on our own, we might burst out laughing underneath the duvet.
When I see I've made a mistake, my mind shuts down. However tiny the mistake, for me, it's a massive deal. Once I've made a mistake, the fact of it starts rushing towards me like a tsunami. And then, like trees or houses being destroyed by the tsunami, I get destroyed by the shock.
There are times when I can't act, even though I really, badly want to. This is when my body is beyond my control.
When I'm jumping, I can feel my body parts really well... and that makes me feel so, so good. By jumping up and down, it's as if I'm shaking loose the ropes that are tying up my body. When I jump I feel lighter.
It's not quite that the noises grate on our nerves. It's more to do with a fear that if we keep listening, we'll lose all sense of where we are.
My guess is that the despair we're feeling has nowhere to go and fills up our entire bodies, makes our senses more and more confused.
When you see and object, it seems that you see it as an entire thing first, and only afterwards do its details follow on. But for people with autism, the details jump straight out at us first of all, and then only gradually, detail by detail, does the whole image sort of float up into focus.
Numbers are fixed, unchanging things. That simplicity, that clearness, it's so comforting to us. Invisible things like human relationships and ambiguous expressions, however, these are difficult for us people with autism to get our heads around.
I understand that any plan is only a plan, and is never definite, but I just cannot take it when a fixed arrangement doesn't proceed as per the visual schedule. Visual schedules create such a strong impression on us that if a change occurs, we get flustered and panicky.
We can put up with our own hardships okay, but the thought that our lives are the source of other people's unhappiness, that's plain unbearable.

some cyber-dojo measurements

cyber-dojo has hosted about 13,000 practice sessions so far. I've written a short ruby script to extract some measurements from a sample of 500 sessions. I was looking at transitions between red, amber, and green traffic-lights:
  • red means one or more tests failed
  • amber means the tests did not run (eg syntax error)
  • green means the tests ran and all passed
The first column is average number of lines added/deleted.
The second column is colour → colour transition.
The third column is sample size.

3.94 ambergreen 447
4.65 amberred 379
4.67 amberamber 1462
5.39 redgreen 607
6.01 redred 604
7.52 greenred 420
13.65 greenamber 436
17.67 redamber 432
22.18 greengreen 598

Here's how I interpret the results:
  • If you're at red or green and you make a small change (5.39,6.01,7.52) you're likely to stay at red or green.
  • If you're at red or green and you make a large change (13.65,17.67) you're likely to transition to amber.
  • There is a big spike in the number of amberamber transitions (1462). I speculate that long sequences of these transitions are occuring after a large 13.65 greenamber or 17.67 redamber transition.
  • I think the greengreen value of 22.18 is larger than it should be because it's including plain file renames.


deliberate duplication TDD at XP Days Kiev

Back in October I did a 90 minute TDD master-class at XP-Days Kiev using cyber-dojo. You can watch the video of the talk which is now online. In it I code a simple exercise (Print Diamond) using sliming and deliberate duplication with refactoring.
  • I discuss ‘sliming’ – the technique of hard-coding magic-numbers to make tests pass.
  • How can sliming help guide your choice of what test to write next?
  • How can sliming be combined with deliberate duplication?
  • With micro-refactoring?
  • How do you know you’ve slimed too much?
  • How and when should you unslime?
  • I look at the the word “unit” in Unit Testing to understand why the definition is useful.
  • I consider some very important differences between “real” code and “test” code – they are not the same.