Memo to authors ADD 2010

After the publication of the announcement of the admission of reports to the Application Developer Days 2010 conference, we were asked what the reports should be in order to be interesting for the audience. And in fact, there is one trick here - the conference is not tied to any particular platform, and most of the people in the room do not necessarily understand your subject from a half-word. Therefore, I decided to write a small memo to the author.

Of course, the report can not be made on any template. Everyone has their own understanding of how to make a good report. I will outline only the principles that need to be kept in mind during preparation.

1. The report should be interesting to listeners . Item from the repertoire of Captain Obvious, but this does not negate its significance.
2. Our conference is for programmers . A short list of what interests me personally as a programmer: programming languages, architectural techniques, libraries, development environments and other tools. Finally, an interesting report on the implemented project.
3. Not so interesting methods of organization of work, Scrum and other Agile, time tracking and everything else that, according to managers, developers should do at work, in addition to programming. Startup problems are also of interest only to programmers-entrepreneurs. Those exist, but they are few.
4. The word "testing" is interesting to the programmer only when used in the phrase "development through testing." All that cannot be verified programmatically is the manual work and personal problems of the tester. And the problems of others do not particularly occupy anyone. So if you are a tester, and you want to give a report on testing, remember that programmers will be sitting in the hall. Somehow they have to please.
5. Any report is interesting if the viewer understands the ultimate goal . Even if the language is not familiar, and the platform is alien. If you understand the meaning of the action, then you will try to understand the process, for there is always a chance that you will get a similar task in life.
6. Do not expect the meaning to be obvious to viewers. Most of them do not know the essence of your tasks and problems of your platform. It is better to clearly explain at the very beginning.
7. The report should not go deep into the particular issues of a particular technology. Often, such a depth is associated with a lack of obvious practical meaning for listeners. Even for your technology colleagues. (The goal is not clear.)
8. Remember Death from PowerPoint .

So, planning a report, go on a specific practical problem. If the viewer can project this task onto his realities, he will be interested.

Detailed information for authors is available on the conference website . There is a template for abstracts, and a link to the report review system , where you should upload these abstracts.