I used to frequently attend, talk at, and help organize software development conferences. As a former magazine editor, I couldn't help but compare the "information bandwidth" (if not the ultimate efficacy) of lectures with magazine articles and books. I concluded that successful one-hour lectures provided about the information of an 1,800-word technical article (which is about 1.5x the length I believe is most effective for a technical article). Attempts to provide more information in an hour-long lecture forced skipping important details, attempts to provide much less information made the lecture too fluffy (this observation was validated by attendee ratings. Not that attendee ratings are primarily correlated to information delivered, but that's the topic of another post.)
This enforces the not-as-common-as-it-should-be wisdom that lectures are the least valuable aspect of professional conferences. Not that lectures are unimportant; you should attend conferences with great lectures, and even go out of your way to be in the hall as the lecture begins and ends, but you ought not to be terribly concerned about actually attending hour-long lectures.
Many conferences today are moving towards much shorter lectures: 15, 20, and 30 minutes. I think this dramatically increases value to the attendee (while making things significantly harder for the presenters and vastly harder for the organizers).
Phillip Greenspun, in a post on \<a href="http://blogs.law.harvard.edu/philg/2007/08/23/improving-undergraduate-computer-science-education/"" target="_blank" rel="noopener noreferrer">improving undergraduate CS quality that holds for professional training as well, concludes:
- Lecturing has been found to be extremely ineffective by all researchers. The FAA limits lectures to 20 minutes or so in U.S. flight schools.
- Lab and project work are where students learn the most. The school that adopted lab/projects as the core of their approach quickly zoomed to the first position among American undergrad schools of engineering (www.olin.edu).
- Engineers learn by doing progressively larger projects, not by doing what they're told in one-week homework assignments or doing small pieces of a big project
- Everything that is part of a bachelor's in CS can be taught as part of a project that has all phases of the engineering cycle, e.g., teach physics and calculus by assigning students to build a flight simulator
- It makes a lot of sense to separate teaching/coaching from grading and, in the Internet age, it is trivial to do so. Define the standard, but let others decide whether or not your students have met the standard.
- A student who graduates with a portfolio of 10 systems, each of which he or she understands completely and can show off the documentation as well as the function (on the Web or on the student's laptop), is a student who will get a software development job.