A few weeks ago I attended the very first installment of Techorama, a new conference for developers hosted in Mechelen, Belgium. This post will walk you through my experiences of the conference and will highlight the most important takeaways from the various talks I attended.
The conference had tracks on ALM, Mobile, Web, Cloud, Language & Tools, Sharepoint & SQL and best-of Build 2014. I mostly attended the Web and ALM tracks since they are most relevant for my current work, but I dabbled in the other tracks here and there. I expected this conference to be heavily Microsoft-oriented but it turned out that there were a lot of non-Microsoft specific talks. As a matter of fact, it would have been entirely possible to schedule your conference without attending a single Microsoft-specific talk. Most of the talks I attended were high-quality presentations. The booth hall had some entertaining side tracks and there was a lot of swag up for grabs. The food was delicious (warm meals instead of the usual sandwiches!). Overall there was a very good vibe during these two days.
Bruno Segers kicked off the conference with his keynote "The Real Deal". He pointed out the ubiquity of software in our daily lives (instagramming the meal you're about to enjoy, anyone?) and the consequences this has on our privacy, or lack thereof. With some striking video clips found here and here, he delivered a shocking reminder to the audience of their responsibility in this regard. This was a very inspiring talk and a nice reminder of the power and corresponding responsibility developers have in the IT-driven future they are helping shape. I grouped the talks into several topics which I will discuss below.
One of my favorite talks was Mark Seemann's Zone out, check in, move on which you can watch here. The main premise is this: all developers have experienced being in the zone at one point or another. You've got your headphones on to avoid being distracted (if you're a programmer you've almost certainly heard of the headphones rule) and you are blasting out the most beautiful code ever written. Then comes the inevitable tap on the shoulders. It could be your manager nagging you about estimates, a coworker asking something about an obscure part of the codebase or your girlfriend begging you to please stop working and come to bed. You take care of the intervention and put your headphones back on. But no. It's gone. You're not in the zone anymore. As you become more experienced, distractions like these will only occur more often. Given this certainty of frequent interruptions, how can developers stay productive? Mark listed several nuggets of wisdom that make it easier to regain focus after being interrupted:
- Divide your code into smaller chunks. Less code on screen equals a smaller cognitive load to remember what you were working on after an interruption. This is a paraphrasing of uncle Bob's Single Responsibility Principle but some very good advice nonetheless.
- Write code in small steps. Use a distributed version control system like Git to check in whenever the system is in a consistent state. If you wonder just how small a step can be, I recommend trying the Taking Baby Steps exercise for yourself.
- Shorten your feedback loops: keep your build and test times short to avoid getting distracted. If you apply Test-Driven Development to design your code, the only thing you have to read after an interruption is the next failing test.
Another talk with lots of great advice on improving yourself as a developer was Mike Wood's Be a better developer. He has a series of blog posts discussing these topics which I urge you to check out here.
An entire track was devoted to Application Lifecycle Management practices. There were a lot of talks concerning the DevOps movement, infrastructure-as-code and provisioning. One of the conference's surprises for me was a nifty PowerShell extension called Desired State Configuration (DSC). DSC provides a way to declaratively configure machines (like installing a specific version of an IIS web server) and to keep the configuration of different systems like production and UAT in sync with each other. If you work in a Microsoft environment and still manually maintain or set up your machines, DSC is definitely worth a look. As an added bonus: It's just PowerShell, you don't even have to learn Ruby. Tiago Pascoal shared a metaphor that really drove this point home (although being a farm boy myself, the analogy is far from perfect):
You can treat your systems as pets, or you can treat them as cattle.
You name your pets. You groom them personally by installing the latest OS updates every once and a while. You lose all will to live when one of your machines suddenly dies out on you and you have no way of replacing it. Or you can think of your systems as cattle, treating all instances uniformly. You never manually tend to a system. Each change is recorded and can be replayed on any environment at any time. Each system is ready to be replaced by an identical copy when things go awry in seconds, not weeks. Now I love my pets, but when I think of my systems at work I'd much rather treat them like cattle!
- Know your framework/technology/language. For example, you don't need to know how ASP.NET's model binding works to create simple "Hello World"-style applications but if you are planning to develop world class web apps you better read up on this stuff.
- Stay up-to-date with security vulnerabilities and their mitigations. Before this talk I had never heard of Clickjacking or Mass Assignment vulnerabilities. Off the top of my head, I can list two projects I worked on that are vulnerable to these attacks.
- Implement the mitigations. It often takes something as simple as adding a single HTTP header to your server's responses, but it could make the difference between a robust web app and a million-dollar mistake.
I was very surprised to see a talk on functional programming pop up on the schedule. In his talk A functional architecture with F#, Mark Seemann presented a functional architecture for high-performance web applications. The title included "F#" but the ideas presented in this talk apply to all functional languages. In my opinion they even apply to many high-performance web architectures written in a typical object-oriented language. The main point of the talk revolved around Command Query Separation (CQS). He presented an architecture that applied the pipes-and-filters architecture for input and the map/reduce pattern for output. Seperating write operations from reads combined with functional programming's preference for working with immutable data and controlled side-effects (like writes) can result in highly performant and easier-to-understand applications written in any language, not only the functional ones.
During the first installment of Techorama I had a lot of fun and learned some great stuff. The talks covered a vast range of topics ranging from self-improvement over functional programming to web development and ALM. I can only recommend this conference, even for non-.NET developers.
Like this Blog?
Then you’re in for a treat! Visit Jo Van Eyck's personal blog, which offers many more hours of excellent reading material!