Learning by doing
This one came to me through a Scala course.
My uncle* suggested me to learn Scala because functional programming is the future of software development. Two years ago read a book about it and also learned FP in uni – I replied. I was humble enough to tell him: very likely I already forgot most of it.
So I started to take this course. It turned out, I did forgot a lot. There are some things that became clear to me during the exercises. E.g. now I really know how to write tail recursion.
Learning by doing is fucking effective, I concluded.
There are many ways of learning:
- You can learn by reading books
- You can learn by listening to / copying others
- You can learn by doing, e.g.: experimenting on things and reflecting on your results.
In the beginning of ones carrier it’s useful to copy others, like going through tutorials. It’s also useful to read books so you can learn what others discovered by doing things. This sort of things can prevent you from reinventing the wheel.
What do you mean by “learning” ?
OK, but what is learning? Memorizing a new API, e.g. finding out how to use FEST is learning of lexical knowledge. Practicing TDD is learning of tacit knowledge. On the other hand, figuring out how to track session in whatever web framework is not learning: it’s just hacking.
From these options, gathering tacit knowledge is the most important thing a developer could do. Good guess: you can gain tacit knowledge by doing things and reflecting on how those things worked out.
When do we learn
Cool! I want to learn things! When do I do that?
Uncle Bob suggests in his Clean Coder book that a professional developer spends 40 hours a week with working for the employer and another spends another 20 hours with making ourselves better developers. He suggests to read tweets during lunch, go to coderetreats, work with side projects, etc. In other words, he suggests to spend our spare time on learning. I think we have other options too:
- We can learn when otherwise we would sleep
- We can learn when otherwise we would spend time with our special one / kids / pets
- We can learn when we would do other things like go to the theater, do sports, etc.
- We can learn when we do our day job
I know officially (in a taylorist point of view) we should learn when we do not do our day jobs. It also means that when we learn then we deprive our family from ourselves. From this point of view when we learn things during our day job we rob our employers: we spend the precious man-hours on ourselves.
I disagree with this approach. Although we should learn in our spare time too, the most precious learning happens when we reflect on our day-to-day practices and change them when needed. This is what could make us more efficient. This is exactly why we practice TDD, read stuff and go to conferences. This is also the thing that makes us love our jobs and makes possible to spend time with our families.
Before we would go on I’d like to introduce a concept. Psychologists say that a person can subjectively live his/her life in 3 tenses:
- In the past, grieving for things that are gone
- In the future, worrying to get there on time / in the right shape
- In the present – which is the key to happiness. Some call this state of mind flow.
We can apply this approach to software development too: When we deal with buggy, dirty, untested legacy code we deal with the past. When we add new features we are in the present. When we estimate or when we redesign old stuff we are in the future.
The fine line
I believe most of you had a conversation about a trade-off between speed of development and code quality. As most of the developers learn there is no such trade-off. We should write the best quality code we can. On the other hand there is a trade-off on how much time we spend on finding better solutions on reoccurring problems.
In this metaphor living in the present is the crunch mode. Flow comes to you when you find the fine line between getting things done and uncovering better ways of doing things.
* This is the website of my uncle. He isn’t as influential on software development as Uncle Bob is. However, he is a successful researcher, a great mind and I’m very fond of him. He also agrees with Uncle Bob on the importance of functional programming.