Learning new technology

Jan Vermeir

A while ago my colleague Olav Maassen asked a question on our company mailing list about the best book to read to learn OSx development. His question made me think not about the best book but about how I learned new programming languages in the past.
My first programming language was 6810 assembly code (OK, that was the second, the first was Commodore 64 Basic, but I’m denying I ever learned that). All I had was a reference manual, a dot matrix line printer (30 characters/second), a far better memory (this is important because IDEs have only recently won the battle against my deteriorating brain cells) and some binary feedback by a magazine on my proposal for an article (‘No thanks’). And lots of time to spare at the age of 13. So I had to learn without any real fine-grained feedback through trial-and-error.

On to the university and Pascal as my main programming language to solve small scale problems in a group of students. Feedback was minimal (‘yes, it compiles’) and in the form of an integer between 0 and 10 inclusive (‘Your grade is a 6’). In this case we learned from each other mostly since books were full of theory about programming for academic problems (what did you expect from a university…) but not (at least so I felt) about creating something that actually works.

My first real job was developing software in Oracle Forms and Reports in small teams. We had a combination of ad hoc peer reviews (‘Jan, this code really sucks, go fix’) and structured code walk troughs with an auditor working for the quality division. SQL was a major but easy to master paradigm shift from procedural Pascal. I remember weeks of training at Oracle headquarters in the Netherlands delivered by enthusiastic trainers. No theory here, just tricks.

The end of the nineties meant Java and web technologies for me. We started with tight deadlines and hardly any feedback (‘Yes, it compiles’ all over again), no tool support other than a clunky version of what later morphed into Eclipse. We learned the craft from a British company who were just a couple of weeks ahead of us on the learning curve.

Only recently I got used to pair programming, test first development and rigorous quality assurance in the form of peer reviews (‘Jan, this code really sucks, go fix’). The complexity of OO systems and the platform they were and are deployed on is far greater than the complexity of a terminal and database based system. This requires better quality measures and slows down the learning curve.

My last attempt to force secondary brain cells into active duty (to compensate for the ones that lost the battle against alcohol and age related wear and tear) is learning Scala and functional programming. Without the rigor of a project team you have to do something to make sure you learn to use the tools the way they are supposed to be used. Xebia provides an excellent environment to avoid laziness and dubious quality standards. I use peer reviews (to discuss design) and pair programming (to discuss code quality, ‘Oh, but there’s a much better way to solve this problem’) again to learn.

I do read books (Martin Odersky’s early book on Scala for example) but I easily get distracted or just too curious so I have to start experimenting. Learning by doing works better for me than reading a book, but if I want to break my old habits I need colleagues who know how to provide feedback. Code reviews and pair programming work best to help me learn quickly.

Comments (4)

  1. Simon - Reply

    May 30, 2012 at 8:00 pm

    I agree with the theme; we only really learn a technology by practicing with it. Yet I am shocked at how many folks dont follow up by reading a book (or the full docs) after getting all the basics to understand the full width and depth of a technology. To me the basics is doing the tutorials and getting some real things working. Intermediate level is practicing many times and reading the documentation. Expert level is having practiced the corners of a technology and knowing and understanding all the key blogs about a technology. Master level is teaching others. A lot of folks I interview for jobs just don't seem to get past the first level by claiming the know something but having not read up on it...

  2. Edoardo - Reply

    June 5, 2012 at 11:38 am

    I have to admit that often I don't get past the tutorial stage; partly for lack of time but most importantly for a lack of a didactic trajectory.

    Going through the blogapp exercise is easy enough, and gets rapidly boring - finding a good set of problems to learn from is hard and IMHO the real difficulty in anything. Mentoring and peering need to address this issue; sites like http://www.4clojure.com also help

  3. Jan Vermeir - Reply

    June 5, 2012 at 1:26 pm

    Hi Edoardo, I recognize that problem. I think I solved it by doing two things:
    - Stick to a problem you've solved before (generating a shopping list based on a weekly menu in my case) so you can concentrate on new technology without being distracted by what you are building.
    - Burn the following motto in your brain: 'This code is never good enough', so you remember there's always something to improve, so you will keep learning. When I get to the point that I consider something 'done' I go and show it to someone else so they can comment and point me in another direction.

  4. Gustavo Freitas - Reply

    June 29, 2012 at 5:52 pm

    Hi! Firstly I'd like to thank for finding Xebia website and blog. A great resource for learning.
    In my daily journey for learning something new, mainly technology, what I've found as one of the most annoying issues is: how to find real problems to solve and exercise it?
    There are a lot of tutorials everywhere, but their goal is merely to start. Having this scenario, what I use to do is:

    - Invent something interesting you'd like to solve or simply understand how it works;
    - Define it and start to look how it works;
    - Break it in minor tasks to make you feel you're finishing something most of time;
    - Create tests for your functionalities;
    - Refine and improve each one;
    - Re-do the cycle;

    I hope it helps someone who comes here with this kind of feeling.

Add a Comment