Archive for the ‘Learning’ tag
I recently came across an interesting post written by Randy Luecke titled ‘I’m done with the web‘ in which he expresses his surprise that people often aren’t willing to take the time out to learn something new.
Having worked for a few years now I’ve played around with a reasonable number of programming languages/text editors/databases/etc to the point that I have favourites when it comes to solving certain problems.
If I come across a new problem and I want to solve it quickly my first instinct is to use one of the things that I know and am comfortable with as this will allow me to solve the problem most quickly.
The problem with this way of thinking is that it’s restrictive – what if there’s some other way of solving the problem which is actually better than what I’m doing but would take some practice for me to recognise that?
For example at the moment if I wanted to hack together a script which used a Java API I’d probably just crack open IntelliJ and write the code in Java even if clojure might be a better choice if I knew it better.
You have identified gaps in your skillset, gaps that are relevant to your daily work.
In this case the gap I’m talking about is relevant in as far as you can arguably do a better job if you have more tools to choose from.
A common pattern that I’ve noticed myself/others doing is to stick with the toolset we’re comfortable with until it breaks down at which point we start looking around for something else.
While this approach does work it feels like we should be more proactive in learning new things so that we can question whether are current tools are actually the best ones for the job rather than just assuming they are.
I don’t really have a conclusion other than that Randy’s post struck a chord and I want to try and always challenge myself to keep learning things.
It’d be interesting to know if others have a similar experience or if I’m way off track?
I tend to end up reading about data mining/science, functional programming and startups and while the articles are mostly interesting it does eventually start to feel like you’re in an echo chamber.
I have a subscription to the ACM mainly because I enjoy reading the ‘Communications of the ACM’ magazine which gets sent out every month and until recently I only read articles which I thought would be interesting.
This unfortunately meant that I was adding to the problem I mentioned earlier whereby everything I read is about similar topics.
I decided to try and change that by reading the magazine from cover to cover and although I haven’t finished yet it’s been an interesting experience and I’ve read about things that I wouldn’t have thought to read about including:
- Do more computer science papers get rejected than those in other subjects?
- How do we allow people to vote in areas where there’s been a natural disaster?
- Why are there currently so many post-docs in computer science?
- How should we go about analysing performance problems?
This seems to be a reasonably good way of diversifying what I read/learn because an editor has decided what I should read rather than me choosing or an algorithm choosing based on what I’ve previously read.
Having said that, I’d be intrigued to know what approaches/strategies others have for getting knowledge of a broader range of topics.
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 watching Airbrake 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 😀
In one of my first ever blog posts I wrote about the differences I’d experienced in learning the theory about a topic and then seeing it in practice.
The way I remember learning at school and university was that you learn all the theory first and then put it into practice but I typically don’t find myself doing this whenever I learn something new.
I spent a bit of time over the weekend learning more about neural networks as my colleague Jen Smith suggested this might be a more effective technique for getting a higher accuracy score on the Kaggle Digit Recogniser problem.
I first came across neural networks during Machine Learning Class about a year ago but I didn’t put any of that knowledge into practice and as a result it’s mostly been forgotten so my first step was to go back and watch the videos again.
Having got a high level understanding of how they work I thought I’d try and find a Neural Networks implementation in Mahout since Jen and I have been hacking with that so I have a reasonable level of familiarity with it.
I could only find people talking about writing an implementation rather than any suggestion that there was one so I turned to google and came across netz – a Clojure implementation of neural networks.
I spent a few hours playing around with some of the encog examples and trying to see whether or not we’d be able to plug the Digit Recogniser problem into it.
To refresh, the digit recogniser problem is a multi class classification problem where we train a classifier with series of 784 pixel brightness values where we know which digit they refer to.
We should then be able to feed it any new set of 784 pixel brightness values and it will tell us which digit that is most likely to be.
I realised that the OCR encog example wouldn’t quite work because it assumed that you’d only have one training example for each class!
* For now, this trainer will only work if you have equal or fewer training elements
* to the number of output neurons.
I was pretty sure that I didn’t want to have 40,000 output neurons but I thought I better switch back to theory and make sure I understood how neural networks were supposed to work by reading the slides from an introductory talk.
Now that I’ve read those I’m ready to go back into the practical side again and try and build up a network a bit more manually than I imagined the previous time by using the BasicNetwork class.
I’m sure as I do that I’ll have to switch back to theory again and read a bit more, then code a bit more and so the cycle goes on!
For as long as I can remember I’ve had the belief that, at least as far as software is concerned, everything I know how to do everyone else also knows how to do.
I carried that assumption for quite a while and only realised relatively recently how harmful it can be.
The most observable outcome I noticed is that I either didn’t give my opinion in group situations or just didn’t take part in them because I assumed that what I wanted to say would eventually be contributed by someone else anyway.
The danger of doing that is that sometimes people didn’t come up with a solution I’d seen work before and I’d be extremely frustrated because it seemed like the others were making what I considered bad decisions deliberately.
I think this belief evolved from the fact that for several years I was nearly always the least experienced person on the teams that I worked on and it was often true that my colleagues knew way more about almost everything than I did.
As time has gone on I’ve seen more situations and gained some ideas on approaches which work and I haven’t been the least experienced in the teams I’ve been working on so the belief doesn’t necessarily hold anymore.
I’m not sure if this is a common stage to go through on the software journey so it’d be interesting to hear about your experience.
I’m now moving more towards an approach where I give my opinions in situations where I have some knowledge while also accepting the fact that there will be other situations where others know much more than me.
In those situations I can legitimately keep quiet and learn from my colleagues experiences.
Something which I frequently forget while reading books is that it’s actually quite useful to know exactly why you’re reading it i.e. what knowledge are you trying to gain by doing so.
Implicitly I knew that I just wanted to get a rough idea of what sort of things it’s telling people but I somewhat foolishly just started reading it cover to cover.
I only realised that I’d been doing this when I’d got a third of the way through and realised that I hadn’t really learnt that much since the book effectively describes the way that ThoughtWorks delivers projects.
- Survey – scan the table of contents and chapter summaries
- Question – note any questions you have
- Read – read in entirety
- Recite – Summarise and take notes in your own words
- Review – Re-read, expand notes, discuss with colleagues
I don’t think it always needs to be quite as organised as this but I’ve certainly found it useful to scan the chapter headings and see which ones interest me and then skip the ones which don’t seem worth reading.
When reading The Art of Unix Programming I felt that I was learning a lot of different things for the first ten chapters or so but then it started to get quite boring for me so I skimmed the rest of the book and ended up reading just half of the chapters completely.
The amusing thing for me is that I knew about this technique a couple of years ago but I still don’t use it which I think that comes down to having a bit of a psychological thing about needing to finish books.
At the moment I have around 15 books which I’ve partially read and at the back of my mind I know that I want to go and read the rest of them even though there will undoubtably be varying returns from doing that!
I need to just let them go…
One of the problems I’ve noticed in several of the ‘agile’ communication mechanisms (such as the standup or dev huddle) that we typically use on teams is that they focus almost entirely on verbal communication which only covers one of our learning styles – the auditory learning style.
The Learning Models
The VAK learning style model describes a simple model covering the different learning styles that people have:
- Visual – seeing and reading.
- Involves the use of seen or observed things, including pictures, diagrams, demonstrations.
- Auditory – listening and speaking.
- Involves the transfer of information through listening: to the spoken word, of self or others.
- Kinesthetic – touching and doing.
- Involves physical experience – touching, feeling, holding, doing, practical hands-on experiences.
My own learning style is predominantly visual so I tend to find that a well drawn diagram will help me understand something far more quickly than a colleague spending 10 minutes explaining something using only words.
If the latter happens then I either find myself totally zoning out or mentally trying to sketch out what the speaker is saying.
In a team environment this would translate into ensuring that we use the whiteboard when trying to explain problems.
Sometimes just going to the whiteboard isn’t enough and we need to cater to the kinesthetic learning model which in software development terms would involve walking through the code.
I’ve never been involved in a team session where we went through a part of the code base together but I’ve heard from colleagues that it can be very helpful in some situations.
I think it’s important that we know what our favoured learning style is so that we can guide any discussion in such a way that it plays to our strengths.
In terms of software development
Although people tend to have different learning models my general observation is that we can move through the models from auditory to visual and finally kinesthetic depending on the complexity of what’s being explained.
I think it also partly depends on the experience of team members. For example, I’m now able to understand many more discussions which are purely verbal where previously I’d have needed a diagram or someone to show me what they meant in the code.
I think it’s important to look at the implicit feedback we’re getting from colleagues when explaining something to see whether or not the model we’ve used has been effective.
If it hasn’t then at least we know we have some other approaches to try which might be more successful.
My colleague Aman King is back in Pune for the time being and during one of our conversations he was asking me why I didn’t wait a bit longer and learn more about Ruby before writing about it.
In a way he is right and I didn’t write anything at all about C# or Java when I was first learning how to write code in those languages because I didn’t have the confidence to write about something that I knew nothing about.
However, what I found when I was initially learning F# was that even writing about very basic things was quite useful to me and once I’d written about something my understanding of it tended to increase.
For example about a year and a half ago I wrote a post about some common things that I’d been getting confused with and I was quite surprised to notice that I never confused them again once I’d written that post.
I’m not sure of the science which explains why that happens but I’ve noticed a similar thing happening with Ruby.
I wrote about the advantages of learning through teaching last year which is along similar lines and I think the points I made there are applicable even if the subject matter would be trivial for others.
The other useful side effect which sometimes happens is that someone much better than me will point out a better way of doing something than what I described and I can then use their approach in code I write in the future.
In a somewhat related article titled ‘Blogging, empowerment, and the “adjacent possible”‘ Scott Rosenberg recently described in more depth how writing about things can actually change the way we think about them.
I was looking back over a post I wrote a couple of years ago where I described some learning cycles that I’d noticed myself going through with respect to code and although at the time I was thinking of those cycles in terms of code I think they are applicable at a project level as well.
The cycles I described were as follows:
- Don’t know what is good and what’s bad
- Learn what’s good and what’s bad but don’t know how to fix something that’s bad
- Learn how to make something that’s bad good
I think I’ve followed similar cycles with respect to how an overall project is run.
To start with I didn’t really know what it was that made a project run with an agile mindset different to anything I’d seen previously so I spent a lot of time observing the approaches my colleagues used, the processes they tried to drive and generally trying to understand what made a project tick.
Having worked on quite a few projects and seen similar underlying concepts working despite differing contexts I started to notice that the situations coming up were often the same or very similar to ones that I’d seen before.
At this stage I was more convinced that some of the approaches I’d already learnt could be useful but often deferred to more experienced colleagues or suggested improvements and relied on them to help drive them.
When I worked with Dermot he pointed out that the next step was to now be the one who can drive the changes that I want to see rather than relying on someone else to do it.
I’ve been trying to do that more recently and it’s not all that different to the way that I already try and influence the way that code is designed except it covers a wider spectrum of situations.
Books like ‘Fearless Change’ and ‘Agile Coaching‘ certainly have good tips for how to influence change but I find that more often than not I only really understand how to do something after I’ve made a complete mess of it the first time around.
I guess the downside of trying to influence situations more is that you put yourself in a position to be shot down so perseverance and knowing when to push and when to back off seem to be skills that will be particularly useful.
I came across an interesting article from the New York Times that Michael Feathers originally linked to on twitter which discusses some of the common ideas that we have about good study habits, pointing out the flaws in them and suggesting alternative approaches.
The author starts out by making some interesting observations about spacing out our learning:
An hour of study tonight, an hour on the weekend, another session a week from now: such so-called spacing improves later recall, without requiring students to put in more overall study effort or pay more attention, dozens of studies have found.
No one knows for sure why. It may be that the brain, when it revisits material at a later time, has to relearn some of what it has absorbed before adding new stuff — and that that process is itself self-reinforcing.
I’ve written previously about re-reading books and how we seem to notice different things when we process information the second time around.
I’ve also found that when I don’t understand something immediately that if I leave it for a while and come back to it later on it often makes more sense even though I haven’t deliberately tried to make sense of it.
For example I was playing with Clojure in November and December last year but then didn’t look at it again until quite recently.
Looking at it the second time the syntax and style of programming felt more natural to me which I think is because I’d played around with J a bit which is slightly similar.
I found the following section related to the type of material studied quite interesting:
Varying the type of material studied in a single sitting — alternating, for example, among vocabulary, reading and speaking in a new language — seems to leave a deeper impression on the brain than does concentrating on just one skill at a time.
I don’t do this intentionally but I find that my interest in something rarely lasts more than a couple of hours so I tend to switch between coding, blogging and reading when I’m doing anything software related in my own time.
The article also goes on to talk about the value of testing ourself on material, suggesting that the harder it is to remember something the harder it is to later forget.
The only correlation I can think of with respect to my own learning style is that I find it easier to remember information if I write about it or explain it to someone else.
It’s a very interesting article and well worth reading.