Visual whiz Ole Qvist-Sørensen at Øredev
We are happy to announce that Ole Qvist-Sørensen will hold a session at Øredev. Ole is a promoter of visual thinking, graphic facilitator and holds a black belt in explaining complex things.
Here is a recent presentation by Ole at TEDx Copenhagen, challenging us to draw more, together.
Together with his colleauges Ole did graphic facilitation at TEDx Copenhagen, and here is the result in the form of a speeddrawing presenting the whole line of speakers
At Øredev Ole will explain why getting getting everyone on the same page matters. In a hands on double session he will show us how to communicate, visually. Think you can not draw? Ole will prove you wrong!
Interview with Corey Haines by Jakob Klamra
Interview with Corey Haines
After 12 years of coding for money, Corey Haines decided to leave everything behind. He went on a long pair-programming tour. Corey travelled around the world, pairing for room and board. The mission was to cross pollinate between developers, learn their ideas, and pass them on to the next team. This has lead Corey to help developers improve their fundamental software design skills. He also co-created and led the popularization of the Coderetreat format - a way for developers to get together and learn from each other. One of Corey's latest projects has been to help organize programs and events to teach kids programming and get them excited about tinkering with their computer.
A few years back you lost your job and you went on a long trip, coding for room and board. What made you leave everything and just go?
One of my close friends and mentors, Joe Rainsberger and I, had talked about how great it would be if we could just travel and code with people. I had two things keeping me from doings this: a girlfriend and a job. In 2008 I lost both so it was the perfect time. To begin with I wanted to travel for about three weeks and it turned into nine, ten months. I would be switching from learning from somebody to teaching what I had just learned to the next people like a cross pollinating bee. There was an amazing amount of interaction. People started realizing the effects of changing environments and not just staying with the same people.
Were people acceptable of your idea and the things you were teaching?
Absolutely! It was a self-selecting group of people. If you are bringing some guy in to let him sleep on your couch and teach you coding, you are probably more open to new ideas. I was not there to convince or evangelize. I was there to work with them, share what I knew and try to pick up what they knew.
You have been a forerunner for the craftsmanship movement. What is it that makes programming a craft and what makes a developer a craftsman?
I am not a big fan of the term "craftsman". I like to say that there are two ways to be a craftsman: call yourself one or work for a company that calls you a craftsman. What I like is the craftsmanship, the care and respect that you give for what is admittedly a very difficult creative activity. It is to show respect for the reason you are coding, which is to provide value to the people who are paying you. If your customer needs something that is very quick and a throwaway prototype, provide it like that. If they need something that is long-lived, then you need to build something that can change with your customer's requirements. It is about understanding what value you are providing using the tools and the techniques suitable for that.
How would you recommend people to get into the craftsmanship mindset?
It is about taking a step back from the act of doing it for the sake of doing it and looking critically at everything that you do. Ask yourself: can I link my work to the result? Take automated testing as an example. Why do you write automated tests? I write tests because I have worked in places where we had to go through a slow manual process every time we wanted to release a new feature. This took a lot of time. Automated tests allowed us to release quickly and with that the ability to move quickly. When we were able to move quickly we could change the business quickly. We did not do automated tests because they are glorious in themselves. If you do not understand why you are doing this, you should find people who do and learn from them. I think that is a great first step.
Can you see a difference in the code written by somebody with a craftsmanship mindset?
Absolutely. One of the key things is understanding that change happens at specific points in your system. We want to isolate those points from the rest of the system so that we quickly can introduce a change to that key logic. On the other hand, for code not built with this mindset you can see key logic thrown out throughout the system, which makes change a hard task. I find code that is built to support change focuses a lot on abstraction.
Lately you have done a lot of work teaching coding to kids. How do you teach kids something that is so complicated that very few grown-ups will learn?
I have done a little bit. There are a couple of people out there who have been doing a tremendous amount of work, Steve Klabnik and Ron Evans amongst others. What I have been doing is bringing many of the people from industry and academia together. They have slightly different techniques but share the same goal. We have disjointed programs to teach kids, we should support each other instead. Academia is detached from the industry and do not understand the way we do things. At the same time, we do not understand academia. If we can bring them together that is a great step forward. I use Scratch when I teach and I really love it. It is a programming language created at the MIT. When you program it is like building Lego. You use different building blocks that you can configure and put together graphically.
What was the kids reaction to your programming class?
They really got into it. They loved it and by using Scratch we were able to build Pong in an hour. Scratch takes away much of the frustration that comes with learning programming, like syntax. Scratch is written in Squeak so, you can make adjustments while the program is running, which is much more like the way the world works. Rather than writing a bunch of cryptic commands and then see if they work, it is all about tinkering. There is no way you can explain to kids that their program will not work because they forgot a semi-colon. After the first class several students went home and downloaded Scratch to their machines. The Scratch website is basically like GitHub before GitHub was there. It is very social and collaborative. You can download somebody else's Scratch program, change it and upload it to your account. A wonderful collaborative thing.
Do you think kids starting to learn programming now will be better coders once they grow up?
I think there will be two kinds of people in the world: those who can work with computers and those who can use computers. There is a difference between people who can use only Word, and those who are not afraid to write a macro. I believe that basic computer programming is going to be a core component of literacy in the future.
So it is not about making kids better coders but making them effective people.