I want to start a new series here on my blog: Developer interviews. In the last few years I had the pleasure of working with several good developers. People who created cool stuff. People who have achieved remarkable things. Programmers I look up to. Today I contacted some of them, asking if they’d like to give an interview.

Sometimes, in a conversation or discussion, you are attacked head on. The other person challenges everything you say, does not let you finish your sentences and always has one more objection. My default reaction in a situation like this is to be defensive. Which is probably wrong in any case, but here I want to write about a special situation: The other person is is playing chicken.

The last 2 days I was in Leogang, Austria at the Con-fess conference, where I had a great time. There were good sessions and speakers, and I met many nice people. Leogang is in the middle of nowhere, but that didn’t matter, because Hotel Krallerhof, the conference venue, had everything you could wish for. The Salzburg mountains are beautiful, and the weather was good all three days:

Next week I will be giving a one hour talk about Apache Wicket and AJAX at Con-Fess Conference 2012 in Salzburg. Yesterday I finished preparing the first draft of the talk, which I will refine over the weekend.

Writing about blogging? I’m not sure if I like that. It’s so meta. But Hugh says I should do it, so I guess I have to ;)

I started blogging quite some time ago, but I never really followed through. It was something I did just for me, and I did not care what other people think - or if they even follow me. That has changed a bit recently - but not that much. I still won’t be depressed if people disliked my blog, but now I want to be read. But to be read is not the only reason I write. Not even the top reason. If it were, I would have already stopped it.

This blog post is the last part of the mini series about Framework Design Principles.

Fewer lines of code is better. Given that it sill solves the problem. Less code means less debugging, less testing and fewer bugs. A framework has to make sure that the programmers using it can express concepts succinctly and still clearly. Also, the framework or library should not encourage the developer to hide essential parts of the code just for the sake of succinctness.

I am just at the beginning of my journey - My journey towards becoming a better software developer, towards understanding how teams work and towards helping others. I will always be at the beginning. I hope I’ll never forget that.

Up until a few months ago, I used to work on side projects mostly after work, for just about an hour or two. Often I did not really get much done. Now I have set aside one day per week where I work on my side projects, and this greatly improved my productivity. Then, a couple of weeks ago, I won a book about the pomodoro technique in a contest organized by the Trello team, and so far I am quite impressed: It’s amazing how much you get done when using this technique!

This blog post is part of the mini series about Framework Design Principles.

How can we make sure that our code is extensible? How can we enable or even encourage the users of our library to use the library in new, interesting and unexpected ways? First of all, Simplicity is really important here. Also, we should support inversion of control (IOC) - and if possible we should not constrain our users to a specific IOC container. You can deliberately create “leaks” in your abstractions. And, last but not least, lambda expressions and closures can be an awesome tool for providing extensibility.

This blog post is part of the mini series about Framework Design Principles.

When writing a framework or library, we have to simplify things and create abstractions. But: With every new concept or abstraction, our users have to learn more. They can not simply forget about the underlying stuff. And they can not simply ignore other concepts. This does not have to be a problem, we just have to think about it.