Hosting Public Coderetreats

I described the needs and benefits of inhouse Coderetreats in the previous article. (In case you did not read it - a Coderetreat is a full day hands-on coding workshop focused on the fundamentals of software development and software design. It is a day full of fun and excitement.) In this second part about Coderetreats I will say more about the opposite of (buying) an inhouse event, which is (hosting) a public one.

Hosting a public Coderetreat is obviously more work for the organiser, adding promotion of the event and handling registration. There are several reasons why companies host a Coderetreat. I ran a public Coderetreat in Venice sponsored by Interlogica. The people of Interlogica were passionate about our craft and wanted to connect with like minded individuals. Three out of four attendees were not connected with Interlogica at all and the exchange of ideas and networking was great.

Sponsoring a Coderetreat is Awesome!
The hosting company is usually also the Coderetreat's main sponsor. Sponsoring a public Coderetreat is a marketing activity. Interlogica wanted to increase its visibility. While we cannot expect a huge impact from a single event, it definitely was a good start. I supported them because a Coderetreat is real value provided to participants and the Craftsmanship community. As the event was free for the participants, someone had to pay for the room, lunch, time spent on organisation, my (facilitator) travel expenses and so on.

The sponsor deserves our gratitude and at least some "link love". The host and facilitator may create more buzz on Twitter and other channels, depending on the free time the host has during the sessions. I post at least some images of the sessions and retrospectives, drawing some attention to the sponsor as well. As sponsored event, this is part of the deal.

Finding Local Talent
Many companies have trouble finding developers to hire. Hosting a public Coderetreat is a great way to present the company. Sometimes a representative of the sponsor will open the Coderetreat and make participants aware of open positions. I recommend distributing handouts of vacancies in the room and on the tables.

Public Coderetreats are run on Saturdays to allow people to participate. Starting Saturday morning attracts only the most passionate developers, who want to learn and engage in deliberate practice. These are exactly the kind of developers companies want to hire. A lady from Interlogica's marketing department told me that "people who understand (the idea of Coderetreat) and come are the people we want to hire."

Community and Networking
The Software Craftsmanship community is growing and a Coderetreat is also a networking event. After a few Coderetreats the participants get to know one another. For me a Coderetreat is like a class reunion, I usually know at least half of the participants and some of them are dear friends whom I would like to meet more often. For beginners or people new in the city it is a great way to get in touch with local craftsmen.

A Coderetreat ends with drinking beer in a local pub in the evening. This is another opportunity to talk to fellow software professionals. At the Coderetreat in Venice, the sponsor set up a small reception including cheese, wine and finger food for all participants. (Did I mention that they rock ;-) Interlogica's CEO was amazed by the number of different people he met and talked to during that time.

Free for Participants
According to Corey Haines, one early proponent of the Coderetreat format, the event must be free of charge for participants. Many organisers ask people only for a safety deposit of ten to 15 Euro. The deposit is refunded as soon as the person shows up and is used to pay beer in the evening if the person does not. I strongly recommend using such a safety deposit to make sure that people show up. Most organisers use Eventbrite for handling the registration, because it does not take any fee when a ticket is refunded. An Eventbrite registration page might look like the one I used for GDCR14.

Promoting the Event
After setting up Eventbrite, every public Coderetreat should be registered at coderetreat.org and promoted through Twitter, Facebook and other channels. Coderetreats in large cities, e.g. Berlin or London are sold out in under a week. In smaller communities we need to allow enough time for people to get spread the word that a Coderetreat is coming up. I recommend having the registration ready at least one month in advance to have enough time for sharing and advertising the event.

Whenever I run a Coderetreat, I talk directly to local programming language user group leaders and ask for their support to promote it. Even if I do not know these group leaders, their members might be interested in coding activities. As a Coderetreat is open to any programming language, it is much more fun to have participants from various programming backgrounds. Collaborating with user groups ensures that there are participants offering more interesting languages like Go, Elexir, Haskell, Dart and so on.

The same is true for women in technology. For a Coderetreat in Berlin last year, one facilitators got in touch with several local women-only programming groups, like Rails Girls or PyLadies, told them about the event and opened private registration for them. He waited for a week before making the registration public. After public registration started, the event was sold out in a week.

Being Awesome!
So if your company wants to be seen to care for craftsmanship, dedication and quality, you are looking for great developers to hire or you just want to work in an awesome company, hosting a Coderetreat is the right things to do. Even when you are not able to host a full Coderetreat, buying food for participants or covering expenses is appreciated.

Another Journeyman Week

Recently I had the chance to accompany one of my fellow Craftsman to his work and immediately agreed to do so. While my own Code Cop Pair Programming Tour finished in 2013 I am still enthusiastic about being on tour. In the spirit of documenting my previous 13 weeks, I consider these past days to be week number 14 of my (probably never ending) Code Cop Tour ;-)

Global Day of Coderetreat 2015
To improve my facilitation skills, I ask facilitators to run trainings together with me. My friend Carlos Blé agreed to host me for a Code Retreat and I ended in Las Palmas, Gran Canaria for the Global Day of Coderetreat 2015. I recommend Gran Canaria for GDCR because the weather was much nicer than in Austria during mid-November.

For the Code Retreat itself I proposed to have a specific focus, a theme that we would use to shape the day. Carlos selected Object Orientated Design and we built the whole day around it. We started the day with a (very) short introduction - probably more a summary - of basic object oriented design principles. During the day we only used design centric constraints like No Naked Primitives or Tell Don't Ask. I was concerned that some people would like to try functional programming and indeed there was one participant working in Clojure in all sessions. But he did not complain and tried to fulfil the constraints, which was certainly a great exercise, even when using functional paradigms. We also asked participants to use Test Driven Development and pair programming, but we did not stress these topics. By making the Code Retreat more focused, we were able to exercise a single topic more in depth.

Besides from copying Carlos' every move, I learned a lot from the changed setting. I was a guest and knew nothing about how the Craftsmanship group of Gran Canaria and their Code Retreats. Further I had trouble communicating clearly and talked too fast for the Spanish participants. In return I did not get much feedback because I had not communicated well - which left me confused and made me sweat. I cannot remember feeling that exposed. The whole setting proved to be very challenging, exactly what I had been looking for.

Ruben wrote a summary of the day, which saved me from writing it myself. The slides Carlos and I used are available here.

AIDA Canaries
Because I "happened" to be around, Carlos invited me to spend a few days with his current client, AIDA, probably the largest IT company native to the island of Gran Canaria. I spend three days mob programming with Carlos, Emilio Medina and Ronny Ancorini. I used the opportunity to improve my C#, which I had not used since my session with Paul two years ago. I learned some more things about C# and ReSharper. We worked long hours and I did not see much of Gran Canaria during these days. As I had not come as a tourist, I did not mind.

Carlos published his summary of my visit already, which saved me a lot of typing again. (It seems that it pays off that my post is a month late ;-) I really loved staying some days in AIDA, everybody was nice and very inclusive. While a few employees had problems talking English, everybody seemed to appreciate my visit and the discussions I started. I enjoyed my time there. Thank you!

Spontaneous Unconference on Functional Programming
The following Friday I was lucky to meet Nicole Rauch. She had come to Vienna for her talk at the Agile Tour Vienna. She was one day early and we took the opportunity to spend the day together. While I had planned to host her, my friend Görge Albrecht, the "Code Mentor", stepped up and did the extra work of really organising the day, getting the necessary infrastructure and even paid for drinks and lunch. (Thank you Görge, I owe you.) The Software Craftsmen GmbH helped us out with their meeting room and shared their office with us for a day. The Software Craftsmen are a young company of experienced but still enthusiastic software professionals.

So a few members of the Vienna Craftsmanship group came together to discuss, share and exchange knowledge with Nicole. In the morning we collected possible topics. As Nicole is into functional programming, it was no surprise that Haskell, Monads and all kind of functional topics came up. We started discussing and reviewing one of her older presentation on Monads, which gave us plenty food for thought. In the afternoon we decided to do some coding and mob programmed an asynchronous error handling Monad in NodeJS. It was a great day and I learned a lot. Thank you Nicole for finding time for us and squeezing in a day of learning between your customer meetings, travel time and conference presentations.

Conclusion
The bottom line of this week is that our community is very inclusive. It is easy to find people who will accept you as a guest or be your guest if you just pay a little attention to their schedule. I had found Nicole's name in the list of speakers of Agile Tour Vienna, so I knew she would come. All I had to do was reach out to her early enough and we made it happen. The same was true for my visit to Carlos. I knew he would run a Code Retreat for GDCR15, so all I had to do was propose doing it together. I encourage you to look out for such kind of learning opportunities. Follow the people you meet at conferences, pay some attention to their (promotional) tweets and conference schedules and do not be afraid to reach out and ask them to spend some time together to discuss, learn, practise or just write some code together.

Advanced Personal Branding

This February I wrote three articles on personal branding for software developers. I discussed creating and strengthening your brand step by step: branding all your accounts and defining your motto, sharing and promoting yourself and maintaining a technical blog. I sorted these activities by difficulty into a kind of personal branding ladder, which will vary for different people depending on their personality. This is the final article covering advanced, that are more difficult and more time consuming branding activities.

Go Out!
Personal branding is - well - personal. So you need to meet people in person, interact with them. Find your local user groups or technology related meetups and attend regularly. Join the discussion and talk about the topics you are interested in. You do not need to present anything formally. Regular listeners who ask questions now and then are vital for the existence of any community. There is no way you can fail here. As long as you are authentic, people who share your enthusiasm will want to meet you and discuss your topics. You are interesting to like-minded developers, you just need to allow them to find you.

Present at a User Group
After attending the user group meetings regularly, it is time to take the next step and present something yourself. It it true that some people would rather face death than talk in front of a crowd, but the usual audience at community meetings is forgiving. Remember, most people in the audience are like you and already know you in person. They gave similar beginner talks or know that they should. First time speakers cannot be expected to give flawless talks, and that is the beauty of user groups, full of natural human beings, delivering refreshing and idiosyncratic presentations. Some communities are so successful in encouraging their members to talk, that they continuously breed world class speakers.

Nevertheless I am not saying that your talk does not need rigorous preparation and practice up front. There are several basic things that you can screw up in presentations in general, like giving a wall of text or death by power point. Do your research and read some articles on preparing content, creating slides, presentation techniques and such. There is also much content available on technical presentations in particular. In fact there is only one rule you need to keep in mind: Your presentation is not about you. It is not about you becoming a rock star speaker, it is about serving the audience. For example if you want the audience to read your code samples, make them easy to understand and write them in a large enough font. If the font is too small you are actually conveying the message that you do not care if people read it.

I gave my first presentation at the local Java user group five years ago. It worked out well and today, many presentations later, I still like to talk to smaller groups because these presentations often become conversations and large crowds make me nervous. If you have an extrovert character and like talking to people, giving regular presentations could be less cumbersome than maintaining a technical blog. Here you might change the order of steps. Anyway you need to do both!

Organise a User Group
Organising a local community is hard work. Meetings have to be scheduled, speakers contacted and so on. Usually the group leaders' work is not seen but vital for a thriving community. Step up and help the organisers, your help will be appreciated. Or maybe there is no local community for your favourite topic, then it is high time to create one. Creating new communities is easy using tools like Meetup or social media platforms. For example Aaron Cruz is a "community factory". Be created a new meetup for a topic that clearly has been missing, Clojure Vienna and organised a few meetups, which were a great success. Then he transferred the ownership of the group to the most enthusiastic member and went on to create another meetup.

Your group does not have to be local, there are good examples of virtual communities as well. For example Jonny Andersson runs a remote reading group, a small group of people sharing the interest to learn from books. Another, quite different example is the vJUG, the on-line Java User Group, which brings well known speakers on-line every month.

As I said above, being a community leader can be a lot of work. For example Peter Brachwitz of Clojure Vienna told me that he prepares a presentation if nobody else volunteers to do so. Now that is great leader spirit! Despite the effort, running an user group is a highly rewarding activity. You will be able to watch great presentations (if you organise them ;-) and have "exclusive" access to speakers and other community leaders. For example in the Java world there is an International JUG Leader's conference once a year.

Present at a Conference
Presenting at user groups is often informal, sometimes becoming a discussion rather than a polished presentation. The larger the audience gets, the more formal and professional your presentation needs to be. When submitting a talk to a large and well known conferences like Devoxx, you are competing with many other speakers to get accepted. Also your future talk needs much more practice. When facing 80 or 100 people for the first time, who are all looking at you in eager anticipation, your brain is likely to shut down, unless you are naturally gifted. At least mine did, and I did not even talk to really large crowds till now.

So your presentation needs more preparations, several dry runs, maybe even showing it to a colleague for feedback. This is much work, which keeps me from doing it too often, if at all. And I do not believe in talks with little or no preparation. Even if you do not mind making a fool of yourself, you are doing your audience a disservice. You are wasting their precious (and limited) learning time, when instead they could listen to great talks in parallel tracks.

At international events you might meet new people and grow your network beyond your local area. While this is already true for all attendees, the "magic" speaker badge lets you stand out. Other speakers will talk to you and regular attendees will stalk you to ask questions ;-) And speaking at international conferences can make you famous, really world-famous if you work hard. Working hard means attending at least one conference each month, all around the globe, besides your regular work. This is really tough, as veteran speakers like Dan North or Thomas Sundberg have assured me.

Organise a Conference
Did you spot the pattern? Find some event, attend, contribute and finally organise one yourself. What is true for local events is even more true for conferences. Again you can start small with local one-day conferences embedded in larger communities like Eclipse DemoCamp, Google DevFest or Code Retreat. Your event is likely relying on the infrastructure and help of a well running user group, because you cannot do everything by yourself. For example when we started Eclipse DemoCamp in Vienna five years ago, we did so with the help of the Java User Group Austria.

A much better example is GeeCON, my favourite Java conference which I attend every year. I believe its story is the following: Some guys of the Polish JUG met and complained about the lack of a great conference in Poland. They decided to create one. Already the first version of GeeCON was a huge success and over the years the conference became one of most awesome events I have ever attended. But GeeCON is also a perfect example of the hard work needed to run such an event. If the organisers are not in a hurry, e.g. to buy more wireless routers or fix some other problem, they are walking around the venue slowly, with tired, dark circled eyes. Lukasz Stachowiak, member of the GeeCON organisers, once told me that preparations for the next version of GeeCON start on the very next day after the previous one has ended. I am sure this is also true for Devoxx and all community-driven conferences.

Write a Technical Book
Finally we reach the top of the food chain. Writing a book is probably the most time consuming activity. Tomek Kaczanowski told me that it took him two years to get his Practical Unit Testing book delivered. But the time was well spent. His book is getting more and more popular, which is nice in case of the little revenue each book gives, but much more important is the widespread reception of his book.

As I did not write any books myself, I can only refer to articles about doing so. For example Jack Shirazi's discussion if writing a technical book is worthwhile covers income vs. non-direct income vs. time spent of writing a book. It says "People are impressed by authors. If you have had a book published in a certain area, even if that book did not do particularly well, people are impressed." Since 2007 when he wrote the article, things have changed in publishing if you decide to self publish, as Tomek did. Jurgen Appelo recommends to read at least three books about self publishing before starting with it. And if you think about writing a book you should read Rand's excellent explanation how to write a book first.

It seems that writing a book is sort of making addicted. Many authors I know did write more than one book or at least think about writing another one, even if it would make their wives unhappy (again). Tomek decided to give his third book away for free. Bad Tests, Good Tests is a short book, nevertheless it took him some time to write it. Sure, giving the book away for free removes its direct income aspect, but increases its non-direct income, as more people will get it. Anyway, free or not, it is a great book and you should read it!

Thanks to all the people I used in this blog post as examples for successful branding activities, especially as I did not ask for their permission to do so.

CodeCopTour Week 3

I was waiting for the legal advisor of TechTalk to review the five lines I wrote about my visit at their office the week before, which caused some delay in my blogging queue, but now I am back on track and will continue with week number three of my tour. I started the week with going to the country-side of Lower Austria. While driving I reflected about my tour (and I already published my thoughts here). Markus Schinerl had invited me to stay at his house for three days. Markus runs a small company called sdguide.org which is specialized in calculating metrics like the carbon footprint for factories in the pulp and paper industry. Pulp and paper is a very competitive industry and customers like governments demand the highest environment-conserving certificates from their paper providers. Sdguide's office was located in an old house and due to old age and structural damage it was under construction and looked terrible, see the image on the right side. Some windows were broken and we worked on a raw, wooden construction resembling a table. However we had a powerful computer, two keyboards and two huge screens - no problem there ;-)

Spreadsheet Monstrosities
Markus used a gigantic spreadsheet to enter all parameters needed for such a calculation. It contained roughly 200 input parameters and 500 metrics for up to 50 product parts resulting in huge files with thousand of lines. Obviously Excel was reaching its limits and he needed something more powerful. We spent the first day discussing the domain of carbon footprint and created a small diagram defining the core elements of his calculations. Although we did not write any code it was a productive day because I helped Markus to reflect on his needs and he explained the requirement to me at the same time. We came to the shared conclusion that he needed a real database, but one that he might be able to develop himself, so we ended with Visual Basic (for Applications aka VBA) and MS Access. Although I did not fancy VBA it was the best choice for his needs and he liked the idea that he would be able to use parts of our VBA code in his spreadsheets as well.

Markus had used VBA some years ago and I had never worked with it before. It took us half of a day googling and reading StackOverflow until we got fluent and then we flew. VBA does not offer much and I missed a lot like unit testing, collection classes, closures and much more, still we made good progress. At the end of the second day, actually the very end of the day - it was 10pm, we had built full end-to-end functionality. Of course it was not finished and only calculated one simple formula of one metric for one product part without considering scenarios, different years or different customers. Still it showed the way. I had aimed for that because we needed to know if the chosen design would work. It looked good. During the third day we added more features Markus wanted to investigate, we even created an infix math parser to evaluate arbitrary formulas. It was great and I learned a lot.

Being Brutal
Back in Vienna I helped a small team of developers to improve their refactoring skills. The developers liked practice and I chose Adrian Bolboaca's Brutal Refactoring Game. I had participated in Adrian's session during XP2013 earlier this year and had liked it a lot. It is a programming challenge focusing on refactoring. The brutal part is that each code smell needs to be refactored right now, regardless how small it is. This makes an excellent exercise to train developers in spotting code smells and refactoring them. Adrian lists 17 code smells as the base of the game and I asked the team to prepare short presentations about each of them. At the beginning of the session the developers presented the material to the audience. I just love when trainees teach themselves ;-) During the sessions I collected all the smells I had flagged. Half of them was about naming, i.e. "name not from domain" and "name not revealing intent" which did not surprise me because naming is a difficult problem. Further 30% were "Primitive Obsession" and "lack of tests", common problems in most code bases. One participant was disappointed that he did not hit each of the 17 smells at some point during the game - maybe I will add some game like achievements for completionists like him.

Even for a small group it was demanding to watch out for the smallest code smell in several evolving code bases at the same time. I noticed that pairs kept hitting the same smells again and again. Besides naming, which all participants had to deal with, one pair was "obsessed with primitives" several times, whereas another team had trouble writing tests to cover their design ideas. A fast typing pair, two developers who knew their IDEs well, created a lot of code, but as soon as I found a smell they were unable to remove it by refactoring and had to delete the new code and start over. Although I was as brutal as possible and challenged the participants a lot, I got positive feedback after the exercise and all participants learned something.

The Java User Groups of Austria
For the rest of the week I went "on tour" with the Java Klassentreffen 2013. The Klassentreffen is a series of events organized by the Austrian Java training company Ciit and sponsored by Oracle. It is a mixture of sales pitches and technical presentations, covering various aspects of Java. Technically the Klassentreffen did not meet my requirements for the pair programming tour, but the organizers had invited me to speak and food was provided. Together with Martin Ahrer, the founder of the eJUG Austria, I introduced the audience to Java and Java related user groups in Austria. I started my talk with the reasons to attend user groups, then covered the core groups of Java, Eclipse, Android and Scala and finished the presentation with Open Source, Software Craftsmanship and upcoming Code Retreats. (For details and links please open the slides.) Later the leaders of several groups told me about new registrations, so I guess my presentation was a full success.

DemoCamp Help Wanted

Last Friday an Eclipse DemoCamp took place in Vienna. If you do not know, a DemoCamp is an "informal event for Eclipse enthusiasts to meet up and demo all the cool technology being built by the Eclipse community." (Eclipse Wiki) The Vienna DemoCamp is usually a mixture of product presentations, local companies sharing their experience of how they use Eclipse and pure demos of the newest and hottest stuff, usually delivered by our DemoCamp veteran speaker Tom. Roughly four hours of presentations are made perfect by additional two hours of space in between, filled with discussions, networking, food and free beer. And we make sure that there is enough beer. Once we ran out of beer and since then we are haunted by the fear that we might not have enough which usually ends that everybody has to take some bottles home in the end ;-)

This was the 13th DemoCamp invitation by the Eclipse Foundation and the 8th DemoCamp held in Vienna. It went very well. In the last four years we have built a community of Eclipse enthusiasts and there are a few companies who actively support their employees in participating in the DemoCamp. The "word is spreading", and after two years I finally managed to bring a colleague to the DemoCamp, which is a huge success as people from my employer are usually not participating in any community activities.

We are organizing the DemoCamp in our free time and it is worth it but there are times when the tide is high and there is little time left for extra work involved in running an event for 60 to 80 people. Our Platinum sponsor agent°ex supports us a big deal, still there are many things which need to be done. And we would like to do more like invite more speakers from abroad, have some games, give away free T-shirts and so on. To do that we need help. If you are enthusiastic and want to be part of this, contact us. Your local Eclipse Community needs you!

Getting Started with Hackergarten

Hackergarten is a computer programming contributor group. Read more about Hackergarten here. To join the group either find an existing Hackergarten near you, or start your own. This is a step by step list of what I did when I started Hackergarten Vienna.

The Simple Way to Start a Hackergarten

1. Contact a few people that might be interested.
2. Find some Open Source committers and the smallest tickets/ideas to implement from their projects. Usually committers are short on personal time anyway and will love to find someone who is willing to help.
3. Ask them to create a list of possible things to do in advance and publish it. Maybe have a theme for a night.
4. Determine the preconditions (what is needed to code...) and publish them, so people are able to instal before.
5. Find a place with wireless network. Most likely this is the office of a small company, e.g. Canoo or Sphinx. You might also find some pub with a separate room/wireless for no charge.
6. Negotiate a proper date and time. At least for the first time. Then having a fixed time, e.g. first Tuesday each month is probably the best.
7. Meet.
8. Discuss the agenda for max. 15 minutes, do not discuss too long.
9. Have food and drink ready so people do not have to leave for it.

Read the Hackergarten FAQ for further details and what to avoid.

What to Do
There have been all kinds of contributions made during a Hackergarten. Here are some general ideas what to do during a Hackergarten:

• Fixing an outstanding ticket (bug) in project X, submitting a patch.
• Writing Javadocs/doc pages for project Y.
• Building a plugin for project Z.
• Making screen casts showing how you can integrate W with Q.
• Writing a new feature for project P.
• Create a kata cast.

Also everything applies from Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star.

Concepts of Functional Programming

Last week I had the pleasure to give a presentation at Javaabend in Vienna. Javaabend (German for Java evening) is a local Java user group event organised by openForce Information Technology at irregular intervals.

A Little Rant
This presentation has a long history, so I will start with a little rant. Last year when I started playing around with Scala, we (read some enthusiastic employees) formed an informal study group to have a look at functional languages and Scala in particular. In the beginning we made good progress and had quite some fun and met biweekly. Unfortunately the organisation had a strange attitude to training (as well as to public relations) and we were disbanded. Being stubborn as I am, I managed to establish a budget from "another source" after some time and started preparing this presentation for the monthly "Developer Round Table". The presentation was postponed several times and in the end I left the company for good.

Scope of Presentation
Now let's come back to the presentation. Talking about the principles of functional programming is a bit off-topic for the Code Cop and it's just scratching the surface of the core principles: purity, higher order functions, closures, currying, continuations and (well not really) monads. I'm no expert on functional programming, so feel free to comment corrections or clarifications. Especially the concept of monads is a bit mysterious.

Slides
Download the Concepts of Functional Programming slides. As usual the slides are not very useful without my explanations because they entirely consist of single words and/or images. This is my take on the current presentation style. I received some good feedback on the style and especially the images. One attendee even told me that the images were "too" good for him, he was distracted by them. (Thank you Flickr community for all these wonderful CC licensed images.)

Discussion
After the presentation there was an interesting discussion on the advantages of functional programming over the imperative style, e.g. Java.

• Is it easier to get things done with many lines of simple, imperative code, compared to one line of functional code (that most definitely does not look simple when you are new to the area)?
• Are the functional paradigms more difficult to comprehend? Is this the reason that functional programming isn't used as widespread as the imperative one? Would the average developer produce bad quality code when using functional languages?

These are difficult questions, only time will tell.

Resources

• Slava Akhmechet explains functional programming for the rest of us. This is a nice overview and definitely worth reading.
• Tony Morris posted slides of his talk what functional programming means.
• Some code examples were taken from Ruby Blocks, Closures, and Continuations.
• A good resource for all concepts is Wikipedia.

Acknowledgement
Researching the core principles of functional programming was part of a System One Research Day.

Upcoming Eclipse DemoCamp

After all the work I put into last year's DemoCamp, I promised myself I wouldn't organise another one in the near future. Well, it didn't work out like that. Michael persuaded me to organise another one. So, the second Vienna Eclipse DemoCamp will be at the end of June.

Show Me Code - No Slides - No Suits ;-)
We plan to have a different style this year and want to create a more in depth and personal experience. Instead of fancy slides we want to do some live coding, guided by the presenter's vast knowledge of the topic. Hopefully things will run as smoothly as they did last year.