This year I decided to try to attend my first software development conference, and it ended up being Visual Studio Live in Washington DC. The conference just concluded yesterday, and now that I’m back after a full day of travel and haven’t entirely passed out yet, I wanted to put some impressions down for anyone else considering going to one of their future events.

I wasn’t sure what to expect going to a .NET-centric conference. The crowd probably had a higher average age than you’d find at, say, a Ruby on Rails conference, but there was still a wide variety of ages and skill-levels present. It was predominantly male, and at a guess I’d say there the attendees were about 10% female. It was nice to see some female presenters.

The presenters almost always seemed to have a firm grasp on their topic. Many of them have classes on PluralSight, and in some cases their material was a condensed version of a longer PluralSight course. I didn’t mind this even though I have a PS account, since many of those courses are a major time commitment and this gave me an opportunity to get an overview and see if the topic was even worth my time. There were the occasional tech problems that are bound to pop up at a conference, though hopefully the microphone problems can get ironed out for future events.

Some of the sessions I attended and got the most out of:

• SignalR from Rachel Appel: A library created by Microsoft that allows for a persistant connection over HTTP, using Websockets if the client supports it but falling back to server side events or long-polling if necessary. It certainly looks impressive and I want to play around with it on my own. My concerns are how it resource intensive it becomes with a lot of users. Support for load-balancing via backplaning was mentioned, though I’ve only seen mention of support for a few storage mechanisms such as Redis. The demo was really well done and would have even allowed for audience participation if it weren’t for the hotel WiFi being so intermittent.
• TDD (Test-Driven Development) vs TED (Test-Eventually Development) from Ben Hoelting: Both are definitely preferable to TND (Test-Never Development). Most of this I had already heard about, but I did learn about Code Katas, a daily exercise to teach TDD principles and keep up unit testing skills. I may try to introduce this at work as a group exercise, to foster discussion and increase our knowledge. I doubt we’ll be switching to a TDD approach anytime soon, but getting better code coverage with tests would get us some nice gains in code stability.
• JavaScript for C# programmers by Phil Japikse: This really opened my eyes to the… interesting… language that is JavaScript. I’ve mostly played in the shallow end of client-side that is jQuery, so seeing some of the quirks of JavaScript was highly educational. Phil had a very engaging style, even though he said he had received feedback from prior sessions about being “too negative”.
• Scrum and TFS from Richard Hundhausen: My team may be moving to a more Scrummish software development process soon, and even though that may not be using TFS, it was still worthwhile to get an overview of Scrum and the heart of what advantages it brought. The key benefit is getting your software in front of the customer sooner, and since whatever you show them is almost guaranteed to be not what they want (despite what they told you), you might as well do it sooner than later and make things better. Also good to hear about the pitfalls that many companies encounter when trying to implement Scrum, which in the majority of cases seems to be that they put all the right-sounding Scrum nouns in place (sprints, Scrummaster, daily Scrum, etc.) but aren’t actually doing the verbs (maintaining a backlog, grooming the backlog, etc.). Richard also mentioned the Scrum Guides website that I will certainly be checking out.
• New features in C# 6.0 from Mark Michaelis: A lot of cool stuff, and a little bit of heartbreak in the form of features that were once planned but cut due to a lack of time to fully implement. C# 6.0 is nothing groundbreaking, just a lot of syntactical sugar that should make for cleaner code in a lot of cases. The null conditional will reduce null checks that often take up many lines, though I hope we can refrain from reducing methods to a single unintelligible line. Mark really seemed to know his stuff and pointed out how the open sourcing of the .NET compiler really means that it’s much more possible now to influence the design of future C# features.

The monuments tour Wednesday night was also fun, led by a funny and informative guide. We weren’t able to stop in any one spot for long, so I definitely want to go back to DC and do the touristy thing. The conference venue was fine, and the area of DC worked out well with some good restaurants nearby.

Should you go to Visual Studio Live? I’d say the topics skewed towards beginner level to mid-level developer. Many were overviews of the technology, though there were some intermediate “best practices” type presentations. I’d say look at the sessions list, see if there are topics you’ve wanting to dig into or more specific talks on the areas that you work with. If you’re already a senior software engineer and want to explore and evaluate an individual technology or technique, devoting some time to diving into a related book or a PluralSight course may be more useful. I can’t speak to the all-day workshops conducted on the first day since I skipped those.

I am glad that there were dedicated networking sessions, both the lunches and after the talks concluded on the first day. I was able to meet other .NET developers from around the country doing a lot of different types of work.

Some of the impressions I heard from my fellow attendees were that they should try to have fewer but more defined “tracks” where the first day has an intro talk, then the second and third day has more advanced-level presentations. This may be difficult with the varied interests of the attendees, but that might present an opportunity to focus each VS Live event on different topics such as “Web”, “Sharepoint”, “Databases”, and so on.

Overall I was happy with the conference. Nothing totally shook up the way I’ll be writing software, but I was able to learn a lot of new things that I’ll be able to take back to my team and make our product better.