Devops

I heard of the Lead Dev conference series some time at the end of the last year. There are not many conferences that focus on engineering leaders, most of the technology conferences are focused on specific technologies, methodologies or the business side. It was too late for the Berlin 2019 conference, so I set my eyes on either the London or Berlin 2020 conference. In the end I decided against London, because I wanted to avoid short plane trips as much as possible and staying longer in London also wasn’t an option. Then the COVID-19 thing happened and Lead Dev organisers decided to cancel or postpone some of the 2020 conferences and also offer an online conference: Lead Dev Live 2020. It was a two day conference on April 7 and 8, 2020. Not only was it streamed live, but also completely free. Each day had a single track happening in the afternoon and evening CEST. Streaming was via one long YouTube stream for each day, which was well produced except for some technical issues that were quickly resolved. In parallel to this everybody had access to a Slack community for general chat, topic specific channels and networking. In the end I didn’t watch all of the talks, but most of them. I am just going to list the ones I recommend to watch if you get the chance. Overall I enjoyed the experience, they had some great speakers and some topics I can directly relate to. I noticed that I found the panels more difficult to follow, you get a lot of whitespace between the speakers and there is no consistent story. This makes it easy to lose concentration, check your messages or fetch a new cup of tea. A normal talk with a story and possibly slides can really grab your attention and take you on a journey. One thing that didn’t work at all for me were the Slack channels running in parallel to the talks. The main #leaddev-live channel was very noisy and just flooded with people just saying hello. Any announcements flew past so fast that it was pretty much unusable. Something like a channel only for announcements would have been more useful. You also run very quickly into the usual Slack problem of having too many channels and then too many notifications. I definitely would join another conference by Lead Dev. I might even pay for it. Would I go to a real Lead Dev conference? Yes, but only if it is close to me. I wouldn’t spend the time and money required to travel further than maybe a two hour flight. Day 1 The first day was focused on the effects of COVID-19 on management and remote work. YouTube stream day 1 Leading teams through times of uncertainty and upheaval [Panel] Camille Fournier, Lara Hogan, Rachana Kumar and Christian McCarrick https://youtu.be/yxiDblyYkrI Good insight into how different companies and engineering approach the crisis with some well known guests. Minimum Viable Business Continuity Management Meri Williams https://youtu.be/TCu0gJ_hLq8 Talking about all kinds of aspects of continuity management. From risk assessment, testing, planning and communication. Avoiding the pitfalls of rebuilding software [Panel] Dan Berry, Jai Chakrabarti, Bryan Liles and Erica Stanley https://youtu.be/lsgbGRkysJE Rebuild or refactor in many words. Day 2 The second day was more of a mix of different topics. YouTube stream day 2 Tradeoffs on the road to Observability Liz Fong-Jones https://youtu.be/wkXKbC1GWIM Keep SRE and observability boring. Use the tools that you can easily obtain instead of reinventing the wheel. Designing effective OKRs [Panel] Aniela Crisan, Whitney O'Banner, Antonio Verardi and Heidi Waterhouse https://youtu.be/tBchi7FzRFU Panel about OKRs in general and in tech teams. I really enjoyed Whitney’s take on this. Her talk from 2019 “Setting Objectives and Key Results in your team” is also worth a watch. Another related talk watching from 2018, which was also played during one of the technical glitches in this conference is “Goal-Setting Workshops for Managers” by Melinda Seckington. Apps, stacks, and frameworks: avoiding “Shiny Object” syndrome Angel Rivera https://youtu.be/Zk9Rg0Hswu0 This talk was quite random, but still interesting. He talked about his experience of using a new shiny technology (MongoDB) without having any expertise in this himself or in the team. Risky business: taking risks in production Matthew Hawthorne and Leemay Nassery https://youtu.be/Np8NFmjLn4Q How to manage risk by using a/b tests, metrics, testing, … Building and conveying vision [Panel] Neha Batra, Lawrence Bruhmuller, Kevin Goldsmith and Maria Gutierrez https://youtu.be/I9-_4WYUEhE How to create and convey a message to your team.

"One click" deploy (*) Recently our CEO Raj Kumar spent a week in our Barcelona office where the majority of our engineering department is located. I was working on some ideas for him to meet the team and get some insights into our daily work. While most of the company is aware of UI/UX and front-end changes we are doing to our site, some of the back-end and infrastructure work can seem like black magic. I think it is important to take every opportunity to bring this output closer to the rest of the company and especially the leadership. By chance I watched the very good presentation “Getting Real about Managing up” by Kellan Elliott-McCrea, which contains as one example the idea of letting your CEO deploy to production. One of the goals of our engineering team is continuous deployment. I set this out when I joined Devex to give us a far goal to aim for. I was inspired by Etsy’s Code as Craft blog and the book “Web Operations”. For me the important part was not continuous deployment itself, but all the changes in engineering culture required to achieve it. You need a good technical base from unit to integration tests, infrastructure as a code, continuous integration and a infrastructure team that is working side by side with the developers. At the beginning this seemed to be an impossible task, QA and deployment were completely manual, there was no unit testing, no code reviews, a clear separation between developers and operations. The code itself was a mess too, with lots of moving parts, outdated libraries and no easy way to introduce testing. But we slowly made progress, simplified the system and slowly worked our way up from deploying once in a blue moon, to once, then twice a week. Currently we are at one deploy a day, with some manual involvement of QA. The deployment gets kicked off by a chatbot and is well documented in our engineering handbook. The short version looks like this: Check QA status Tell the chatbot to deploy Check the metrics Everybody in the engineering team is already in the rotation of deploys and it is easy enough for everyone in the company to do it. Our CEO Raj Kumar was happy to do it and sat together with our two infrastructure engineers to help him along. Because there are some permission requirements it was also easier to do it from the workstation of our lead engineer. After some hiccups in QA the progress went smoothly and we had a new release in production. I guess in the end he was surprised how boring it turned out to be. Which a deploy should be. btw: we are hiring: Check out our current open positions *) the hat is part of the deploy protocol and not a fashion statement

When I wrote the review of The Manager’s Path I started to think about other books I wish I had read earlier. Usually these triggered some kind of change in how I approach my work or life. This list is definitely incomplete and I will add more to the goodreads list at the bottom of this post. Extreme Programming Explained: Embrace Change by Kent Beck I still remember when and where I read this for the first time. It was on a plane from the US OSCON back to London where I had my start-up. Up to that point all of our projects where waterfall and we basically had no unit tests in our code. On the plane I decided we had to do major changes and we did these over the next years. I was still pretty inexperienced in leading a team, but this was one step into the right direction. By now most of the things mentioned in the book, like pair programming, small cycles, unit testing, agility are well used and documented. This small book is probably still worth a read. Getting Things Done: The Art of Stress-Free Productivity This book is one of the ones where the solution is so obvious that a one page summary would probably enough. Nonetheless this is a good book and gave me a better idea about organizing myself. I am using a mix of the paper approach for all the paper one still receives and Todoist for everything else. In the end it is just a form of Kanban or Inbox Zero. It doesn't matter how you manage your tasks, just keep your work in progress small and your tasks prioritized. Web Operations: Keeping the Data On Time A collection of essays and interviews that gave me lots of ideas about DevOps and that side of a company in general. I still use it as a reference for things like post mortems. Because these are mostly stories it is an easy read and you don't have to read the book in sequence, just pick the ones that you find most interesting. Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity Mostly interesting and inspiring because I am so hopeless bad at this. As an introvert the idea of being candid and even worse radical candid seems absurd. But I know it is one of the areas I have to work on and the book gave me new ideas in a nice form. It is a bit long though and does repeat the main points over and over again. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses I am not working at a start-up any more, neither am I on the business side. I just wish we had this in my time in London. We would have avoided a lot of pain and would probably be still around now. Implementing this in an existing setting is a lot harder unless you have buy in from the top. The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change A great book for engineers transitioning to management. Another book I would have loved to have had at my start-up, thankfully it didn't exist back then. My review of The Manager's Path. Definitely worth reading for all developers even if you don't plan to go into management. I wish I read this earlier Web Operations: Keeping the Data On Time by John Allspaw Extreme Programming Explained: Embrace Change by Kent Beck Getting Things Done: The Art of Stress-Free Productivity by David Allen Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Malone Scott The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier Share book reviews and ratings with Christof, and even join a book club on Goodreads.

facebook: Looking back on “Look Back” videos https://code.facebook.com/posts/236248456565933/looking-back-on-look-back-videos/ Github: No Conversation Left Behind https://github.com/blog/1811-no-conversation-left-behind A Robot for Timo http://blog.printf.net/articles/2014/03/18/a-robot-for-timo/ Testing on the Toilet: What Makes a Good Test? http://googletesting.blogspot.de/2014/03/testing-on-toilet-what-makes-good-test.html Only 90s Web Developers Remember This http://zachholman.com/posts/only-90s-developers/ Tuenti Blog Tag: Continuous Integration: http://corporate.tuenti.com/en/dev/blog/tags/continuous%20integration Why your previous developer was terrible https://medium.com/p/506a06ae35ea Github: Switch your picture with ease https://github.com/blog/1803-switch-your-picture-with-ease Big, Small, Hot or Cold - Examples of Robust Data Pipelines from Stripe, Tapad, Etsy and Square http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html You Don’t Have Big Data… http://blog.mongohq.com/you-dont-have-big-data/

Hierarchy of DevOps needs https://www.kickstarter.com/backing-and-hacking/hierarchy-of-devops-needs 10 Things We Forgot to Monitor http://word.bitly.com/post/74839060954/ten-things-to-monitor