NDC Oslo Day 1

This is going to be a blog post of three, one for each day. And it's more or less just gonna be a brain dump from my notes during the day. So there gonna be a lot of typos, bad spelling, strange grammar and stuff, so keep that in mind :-). Anyway, here it goes...

Keynote: "The Science of Communities Behind Software", Joel Spolsky

Joel (co-founder of stackoverflow) talked about the importance of understanding the anthropology of a "society" on the webb. Especially when creating a Q&A like stackoverflow.
He thought that you can control what kind of users you want to visit and ask questions (and answer them) - and ask the right questions - by designing the system with that in mind.
He spoked mainly on how stackoverflow worked, and what was the idea behind all the things created and why they where created that way. Like voting, reputation, laws etc. You want to encourage a certain behaviour. And almost shut people off that don't belong on the site.

"Creating Web Experiences with Users in Mind", Divya Manian.

Divya is a product manager at Adobe. Not that great talk and not what I excpected, so I'm not gonna write much about it. But mainly she talked about performance considerations when building web apps. And how browsers work and some tips and tricks to make sure the browser uses the GPU instead of the CPU. Not very pragmatic though. Like "avoid 'display:none'" (??) Well... no! I thought this talk was going to be more of "user experience" in like "user interactions" and UI. And I would have liked to se more pragmatic examples and solutions, not only "problems".

"The abstractions of AngularJS", Scott Allen

This was a live coding session, so it's hard to retell it. But he showed some AngularJS techinques mainly. How to use Controllers, Views, Modules, directives etc. Not that pragmatic I think. I would have liked to see more on when to use which technique. And maybe he should have built a "complete" app (and the different kinds of approaches), and not just some little things here and there.

He also made me beleive that Angular (and knockout) are good at the small "simple" things, but when things gets complicated, Angular (and other MVVM JavaScript frameworks, like knockout) becomes very complicated as well, and probably hard to maintain and understand. But I would love to try Angular more deeply.

"Do it right, then do the right thing", Allan Kelly

This was a brilliant talk by an experienced speaker! And it was kind of mind blowing. So I'm gonna write some more about it. 

He said, himself, that the title should have had a question mark after it - he was not sure this was entirely right, but he had (what he thought) some "evidence".

We have always been taught that it is most important to build the right thing (over building it right). But maybe we should just start building things and then see if it was right or not. Build, learn, evaluate and change (adapt).

The key point here is that it's better to fail fast, cheap and often then to (probably) fail anyway in the end (but do it costly). He compared it to a machine gun and a 19th century rifle. It's better to just fire a lot of bullets at a rapid speed then to take time to aim and probably miss anyway.

So fail often and most important fail cheaply. We now have the tools to do it. Because when you succeed, you gonna be ahead of your competitors. So make it easy to fail.
If failure becomes expensive, you become afraid of failure!
It all actually made me thought of  this story http://www.azarask.in/blog/post/the-wrong-problem/.

He also asked: "Why do cars have breaks?" Answer: "So they can go faster!". You don't want to drive a car with no breaks - or you want to go really really slow. So, make it easy to brake, as well. Stop what you are doing and turn and drive another way.

"Pattern of effective teams", Dan North

I always love Dan North's talks. He is a great speaker and have lots of ideas that are well worth listening to. And he tells them well!

He spoke about some patterns he had seen that makes team work more effective. And he made it very clear that effective is not the same as productive. Productive means "write a lot of code", but that's not important if you can write less code and solve the same thing.

He talked about these patterns:

• Dreyfus squared
  When you learn thing you move through these stages: Novice, Advanced beginner, Competent (aka Practitioner), Proficient and Expert.
  He then talked about how to combine team members based on which stage they are in.
• Shallow silos
  It's all about interactions betweeb team members (pairs). Talk to each other. Everyone should know what the other teams are doing. Everyone should easily step outside their "silos" for a moment. And then they have to be shallow.
• Near and far
  How to mix the "specialists" in a team with the rest of the team, and still make everyone happy.
• Warm Welcome
  Make newcomers feel welcome. Prepare even before they start, and make them feel like a part of the group immediately.
• Seize the day
  The most striking thing here was when he talked about daily standup. And that we probably are doing it wrong, it's to boring: "Yesterday I did nanana, today I'm ninini. No obstacles" everybody *yawns*. We don't really care what others are doing. Instead, how can we make this day as good a possible?
• Code critique
  Do code reviews! Read other's code - and learn from it!
  Pairing and code reviews are different things. Pairing = code quality. Code critique = consistency and learning to the entire team.
• Hack day
  I liked this. Go play! Eventually some great things will happen! It's how SQL was created, and Java.
  Or maybe have a "todo cleanup day" or something, it doesn't have to be all "play", but jut something you normally don't take time to do otherwise.

"You are not (only) a software developer", Russ Miles

Russ ended up talking much about Impact Mapping mainly. And when I started realising this he said it himself, as well :-)

He focused a lot on not "over production" things and instead focus on the goal, and how we get there as simply as possible.

So, to connect with the title of the talk, he finished with:

Move from being a software developer to a change developer (through software).

Move from delivering software to delivering change.

Well, think Impact Mapping :-)

"Chef for developers", Erling Wegger Linde

I don't know what Chef is. Google it, if you're curious. It's something with amazon cloud service and Ruby. I don't know. I thought this talk was going to be about something else (I didn't read the synopsis). It was a last minute descision (since the talk I was planning on going to was a series of talks and not intended to visit the last part of, as I was going to do). Anyway, I was totally lost here. Should have left the talk, but didn't want to make him (Erling) feel bad. But after a while Scott Guthrie left the talk, and I don't even think that the Ruby guy (speaker, Erling) knew who that guy (who left) was :-)

Well... that was that. A really great day after all. Many thoughts in my head right know.
And well organized conference.
Next blog tomorrow!