DevOps Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 544 posts at DZone. You can read more from them at their website. View Full User Profile

Restricting Your Own Learning

12.31.2012
| 5050 views |
  • submit to reddit

For the first few years that I worked professionally* every project that I worked on was different enough to the previous ones that I was always learning something new without having to put much effort in.

After a while this became less the case because I’d seen more things and if I saw something even remotely similar I would abstract it away as something that I’d done before.

A couple of months ago Martin Fowler wrote a blog post about priming and how research has showed that exposure to a stimulus influences a response to a later stimulus.

In this case he was referring to the benefits of starting a retrospective with the prime directive because it will help put us in a more open and understanding frame of mind which will be beneficial in this context.

I feel there might be some link between this and my learning conundrum in as well as I’ve primed myself to believe that there’s nothing interesting to learn in a situation because it’s similar to something I’ve previously worked on.

Confirmation bias also comes into play because I’m now only looking for things that I already know to prove my point.

I started working on the uSwitch energy team a few weeks ago and initially I was only looking for the things that I already knew how to do.

After a week of doing this I decided to instead look for things to learn and realised there was more than I expected. These are just some of the things I’m currently learning more about:

  • Continuous Deployment – we deploy every commit if not immediately then usually within a couple of hours. In order for this to work you have to be alert to what things might break. This involves watchingAirbrake for any errors and being ready to fix things if necessary.
  • Maintaining an application in production – somehow I didn’t end up doing this at ThoughtWorks; almost every single project that I worked on was the first release of an application and then we rolled off after that was done. I haven’t done it for long but so far it’s been fascinating seeing the different paths users can take through the application that I’d never have thought of.
  • A/B Testing – we follow quite a data driven approach to improved the website. If someone has an idea for how to improve it, rather than spend hours discussing it we’ll implement the idea and then put it side by side the current version. Then using an A/B test we’ll send half the traffic to one version and the other half to the new version and see which one works better. I’ve been reading this paper to try and learn more about this.

I’m sure that there are more (or certainly will be) that I can’t think of at the moment but it’s much easier to find new and interesting things to learn now that I’m looking for them rather than expecting to magically appear.

——

* as in I got paid. I’d never claim to be professional in any other way :-D

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)