Last week I attended a software development conference, QCon in New York. Here are my impressions of it, as well as some thoughts on programming conferences in general.
For me, there are several reasons to attend developer conferences. You have a chance to hear what is going on in the field of software development – what are the new techniques and technologies other companies are using. What are their experiences. What works, what doesn’t work. Maybe you will pick up ideas for how you could improve the way you develop and deploy software. It is also a chance to meet other developers and discuss and hear their perspectives. And finally it is stimulating. Each time I have been to a conference, I have come back energized and inspired.
The conference was divided into two parts. The first three days consisted of five parallel tracks of talks. The last two days consisted of half-day tutorials/workshops. I attended the first three days only. Here are the presentations I liked the most from those three days:
Talks I Liked
Scaling Event Sourcing for Netflix Downloads. In this presentation, Phillipa Avery and Robert Reta from Netflix talked about their experience using event sourcing when implementing the download feature. Overall they were quite happy with the result, especially that it was easy to extend when new requirements emerged. They also mentioned how trouble shooting became easier when it was possible to view they entire event stream for a subscriber. I liked this talk because the presenters had been involved with the actual implementation, and because it is both interesting and useful to listen to experience reports (in case you want to implement something similar).
Beyond REST: Coursera’s Journey to GraphQL. In this talk, Bryan Kane from Coursera described how they started using GraphQL. Their site was getting slow because of the many separate API calls needed to display a page. To speed up the page loads, they decided to use GraphQL to be able to fetch related data in a single API call. This should be possible in principal, but they ran into problems because the service had not been designed for GraphQL from the beginning. This talk was well presented, but I particularly liked it because it highlighted the problems they encountered as well. Too often talks only focus on clean solutions, instead of also describing the cases that aren’t so easily solved.
The Effective Remote Developer. David Copeland is the “senior-most contributor” to Stitch Fix. The whole development team at Stitch Fix is remote, and David has many years’ experience being a remote developer. This talk contained a lot of concrete, practical advice on how to make it work. For example, publicize your working hours so people know when to expect answers. Learn how to screen cast and to use diagramming tools (works better than text for some people). Invest in a good microphone. In video conferences, use nouns instead of pronouns (avoids confusion), and ask to have the camera pointed to the speaker if it isn’t. This was a good “experience talk”, with lots of practical advice that comes from personal experience.
Production – Designing for Testability. A better title of this talk would be “Verification in Production”. Michael Bryzek talks about how Gilt only has their production environment. There are no local, QA, or staging environments. Testing is done via comprehensive automated tests, including tests running in sand-boxed accounts in production. The rationale for this approach stems from the question “How do you know if it is working in production?”. Even if you verify your services in a testing environment, you still need to ensure it is working in production. By focused all testing and monitoring efforts to production, you avoid any issues with maintaining separate testing environments. I liked this talk because it really challenged my assumptions. Can you really do this? But that would mean… . Definitely food for thought.
Homoiconicity: It Is What It Is. Stuart Sierra does a deep-dive into the origins of homoiconicity (code and data represented the same way). The talk started off showing the slides of the presentation as data that could render itself. Next were examples of languages that are homoiconic to some degree: Clojure, Lisp, Tcl, and TRAC (a programmable text editor from the 1960s). Stuart then traced the idea back through history thanks to some impressive detective work, and finished with some general reasons why homiconicity is useful. Both interesting, very entertaining, and extremely well done.
Odds And Ends
A few other things that caught my attention at the conference:
Themes. Popular subjects for tracks and presentations included: Micro Services, Chaos Testing, Stream Processing, Serverless, Java 9, Immutable Infrastructure, and APIs. One of the benefits of attending conferences is learning what technologies are up and coming.
Hallway conversations. The breaks between presentations were always 25 minutes. This means you have time to talk to people before heading back to the next talk. Like many developers, I could do better in terms of starting conversations with people I don’t know. Still, I did all right. The company names were clearly visible on the badges, so I made an effort to talk to people from companies I recognized or was interested in.
Human + ML. In the keynote on the third day, Cathy Polinsky of Stitch Fix gave some funny examples of where the combination of humans and machine learning is helpful. Stitch Fix uses both algorithms and stylist to give personalized clothes recommendations. In one instance, a customer had received many skinny jeans, and was getting tired of them, and told the company so. A human stylist had to override the algorithm recommending even more skinny jeans (since the first few times that had been a success). Conversely, many people in Boston got recommendations for shorts in December. That seemed like an algorithm error, but turned out to be correct, since they were all going to Florida on vacation.
Code review tip. Another good talk was The Marriage of Communication and Code, where Andrea Goulet and Scott Ford of Corgibytes (and married to each other) shared tips on how to communicate better. One tip I particularly liked was an example of a code review comment. Instead of writing “This should be a separate method”, you can write “Whenever I see a code comment like this, I wonder if it should be turned into a method instead”. The whole talk had a lot of good advice on how to communicate effectively.
Details, Details
Just as when coding, the details matter a lot to end result for a conference too. At QCon New York, they had paid attention to a lot of the small details. This added up to a really good experience overall:
- Excellent food, especially the lunches. Much better than what I have experienced before.
- Quick presentations of all the upcoming talks within the tracks before the morning keynotes.
- Badges with NFC for green/yellow/red feedback after each session (and staff that made sure everybody had a chance to give feedback)
- Badges with easy-to-read names of the participants and companies – helpful for starting conversations.
- Site where you select and build your own schedule (but you still see what the other talks are).
- Short interviews with the speakers published together with the talk outlines.
- A good mix of male and female track leaders and presenters.
- Very central location (by Times Square).
- 5 parallel tracks, so many interesting talks to choose from.
- Swag – no useless trinkets or weird-shaped bags, just a functional back pack.
- Videos available (for attendees) almost immediately (and will become available to the public in the next few months I believe).
- A gong sounded five minutes before the next session started – useful to be reminded.
Conclusion
Of course, not everything was great. I walked out of one presentation that was not up to scratch. Another talk was quite bland, but the Question & Answer session afterwards made up for it – excellent questions getting to the heart of the matter made the session worthwhile anyway.
But for the most part the presentations were very interesting and informative. I got a sense of what the latest techniques and tools are, and how other companies are designing and building their systems. And I got several good ideas to evaluate and try out myself. All of this made for an inspiring experience in New York.
Henrik Warne's blog 