I attended my first ever developer conference (Techorama) in Belgium this past week (May 23-May 24, 2018) and it has to be said, it was much more exciting than I thought it would be. Lots of great speakers and amazing talks for 2 days interspersed with some nice food and nibbles.
Attending talks pretty much back to back, switching rooms, walking up and down etc all can be quite tiring. Not to mention, during the talks your brain is still actively processing information so that also adds to the overall exhaustion (i.e. if you are really using your brain).
The talks themselves were quite good. Not every talk however does justice to it’s catchy and click-baity title but most talks are what they say on the tin. I prefer attending talks more geared towards design, architecture and techniques rather than the hottest new framework out there.
What follows is my experience of the talks from Techorama Belgium and my key takeaways from each one of the talks I attended:
1. What’s new in Web Development with ASP.NET Core 2.1 by Jon Galloway: ok, this was the only one about frameworks but since this is the primary framework I use, I am gonna let this one in. Overall it was quite interesting to see new features in ASP.NET Core 2.1: Razor class library to create UI as Nuget packages, Signal R Core for real time communication, performance improvements in asp.net core, authn and authz as Nuget packages for after the fact identity integration, sneak peek of Blazor.
The framework has come a long way since ASP.NET webforms and by developing it open source and making the framework cross platform, Microsoft has clearly stated their intention that ASP.NET Core is here to stay. Kudos!
2. Art of C# Code Review by Kasey Uhlenhuth. This was a really cool talk about something seemingly as benign as code reviews. She presented code reviews as a way to share knowledge and also to improve communication between team members. Kasey has a terrific stage presence and with her brilliant sense of humour and bubbly style she brought her talk to life. She demonstrated how to use editorconfig files in Visual Studio to establish coding styles at a team level and make it a part of CI process. On PR comments, she had an amazing demo lined up. She showed how using Azure Cognitive Service against the PR comments can reveal the sentiment type of the comments i.e. negative emotions or positive emotions. This can be used to improve PR reviews to make them more encouraging and positive instead of downright mean and condescending (my personal pet peeve). This was mind blowing and very practical use case for AI and ML.
This is something that can be experimented with right away in teams and see how we are doing.
3. Quantum Computing by Bart de Smet. Well…the guy operates on a different dimension to the rest of us. Needless to say this talk mostly bounced off my head. Bart demoed Q# from Microsoft’s Quantum Development Kit. The key takeaway for me was that to store 32 qbits(quantum bits) we would need peta bytes of classical computer storage. That’s all. 🙂
4. Functional Techniques in C# by Kathleen Dollard. Seeing as functional programming is becoming the “new” thing these days, this talk was aimed at adopting some of practices prevalent in functional programming world for e.g. pure and impure functions, higher order functions i.e. functions that take a delegate type as a parameter, not throwing exceptions across the layers but wrapping them in an enclosing type i.e. currying. With C# 8.0 on the horizon more wide spread use of extension methods should help C# be more functional. Certainly a useful talk.
5. A deep dive into Microservices on Azure by Gitte Vermeiren. I went into this talk thinking that it would be more about how do you build Microservices on Azure but it turned out to be more about how to manage existing Microservices infrastructure on Azure using services like Kubernetes, Azure Container Services etc and relied heavily on your pre-existing knowledge of Kubernetes ops which unfortunately I lacked.
6. Fixing Distributed Systems Fail by Jimmy Bogard. I always enjoy watching Jimmy’s talks because they are full of pragmatic advice and his “fail” presentations serve as great case studies of how not to do micro-services. This talk was about how he worked for a company where developers decided to place customer order, process payment using a 3rd party provider, send email using yet another 3rd party and submit the order to RabbitMQ queue of the shipment team, all within the context of a single HTTP request… oh dear!
He also showed the various ways this problem could be resolved.
He then went on to describe how they actually solved this problem by breaking up this whole workflow into online and offline processing modes. For e.g. save the order in the database and return the response immediately but then in the background do the payment processing, sending of emails and publishing to the message bus. This talk is also on YouTube if you just search for “six little lines of fail Jimmy Bogard”. This was the last talk of the first day and was a great way to end day one.
7. Getting from Monolith to Microservices by Jimmy Bogard. Another gem of a talk by Jimmy, pragmatic, technology agnostic and sensible. This talk was more from a process and team perspective than any specific technology. The key takeaway from this talk for me were:
Empathy: observe people who you are building the software for, doing their jobs. One day in their shoes will teach you more than months of dissecting user stories and guessing what might users mean. Don’t be an ivory tower architect/developer.
Boundaries: system boundaries should be based on real life process boundaries rather than organisational structure because changing org structure shouldn’t impact how you do business or how you provide value to your customers. Initial boundaries you create might be wrong but that’s ok because this will help you discover natural boundaries.
Continuous Improvement: work in small increments because it’s easier to deliver value that way than wait for several months before delivering anything. Creating pilots or MVPs is a great way to learn and discover your processes on a greenfield project. On a brownfield project start at the edges of the legacy system and refactor your way in. Don’t start inside out because it’s too disruptive a way to refactor.
Identify integration points and data migration strategies and avoid shared libraries like core, common, utils etc because they prevent true decoupling between services.
Overall very informative talk and very valuable advice.
8. Impostor syndrome by Heather Downing. One issue that’s more common in our industry than we know is what’s called Impostor Syndrome. A feeling that you are not adequate enough or smart enough and that some day people will find that you are a fraud or a fake. Apparently, this feeling is fairly common among people that are in fact good at what they do but because of that feeling of inadequacies brush any successes aside as a stroke of luck and not due to their own skills of any kind.
It’s a nasty place to be in, when you are under going it the world around you stops being important including your loved ones. You become so focused on your troubles that you feel totally alone which in turn reinforces that horrible feeling even more. Everyone else you work with seem to be so much better than you at everything. You truly feel like a fraudster, “what makes me an expert to blog about architecture and design?” Or “why should anyone listen to me or read what I have to write when there are so many really smart people already doing a much better job at it?” “What can I claim that will prove my worth to people?” Thoughts like these are common during an Impostor syndrome phase.
Heather in her brilliant talk not only shared her own experiences with Impostor syndrome but also showed examples of famous business leaders and celebrities that have also had similar experiences. It certainly feels good to not be the only one struggling with this and with people like Tom Hanks, Will Smith, Natalie Portman, Sheryl Sandberg I would say I am in a pretty good company.
The key takeaway for me was that a reason one might feel like an impostor is because we care about our craft, our discipline and the thought of lacking is debilitating. But you also have to realise that no one knows everything there is to know about everything. It’s OK to acknowledge that others might be more of an expert in, say , microservices than me but then I can always learn and improve and that’s what needs to be encouraged. There are things that I must acknowledge that I am good at, to stop negative emotions dead in their tracks so they don’t become real and impede my success, happiness and well being and that of my loved ones. Its also important to keep an eye out for signs of this feeling in your team members and give them positive feedback to encourage them to develop the confidence they need to succeed, what Heather calls “co-bragging” :).
Excellent, excellent talk!
9. Introduction to Chaos Engineering by Paul Stack. Over the years chaos engineering has been popularised by Netflix as a way to test your system for resilience by being disruptive and “kicking the plugs from the sockets” from time to time, so to speak.
It obviously goes without saying that doing chaos experiments must be done in a way so as not to have an impact on production system during the hours of operation. These experiments have to be scoped, planned and scaled appropriately.
Getting management buy in for chaos experiments is a tricky aspect of this kind of activity. Managers and product owners are never going to be able to say yes to pulling the network cards out of servers or blocking all ports on the server VM instances or detach hard drives but if they are asked, “we need to make sure that our systems are resilient to failures and/or heavy demand so we can continue to serve our customers and not lose our revenue but to do this we are going to have to conduct experiments to understand how our systems work currently and then bring them up to speed. Can we please allocate a few sprints for this?” Then they are more likely to agree to it albeit cautiously. Then you have to plan, scope and scale the experiment appropriately so that current production systems are not knocked off by accident resulting in all the bad things chaos engineering is supposed to prevent.
Choas toolkit is a good place to start playing with chaos tools for various platforms like AWS, Azure etc. Paul demoed a tool invented and used by Netflix called ChaosMonkey and showed how it can simulate various failures on EC2 instances like detaching hard drives, blocking all HTTP traffic, burn CPUs, overload the request queues etc and it’s quite fascinating to see EC2 perform appropriate failover to ensure business continuity in face of overwhelming failures. Inspiring talk indeed and I am certainly becoming more and more interested in Chaos Engineering!
That was the wrap of Techorama Belgium for me. It was a terrific experience and it has set the bar very high indeed for other conferences to rise up to or beat. I will be keeping an eye out for similar conferences in the future as they are a great platform for learning and networking.
Artineering 