Restricting Your Own Learning
Restricting Your Own Learning
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
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
Published at DZone with permission of Mark Needham , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.