Learnings @ #RubyConf2018 DAY ONE

[1] Matz’s keynote was amazing. His points about how friendly and welcoming the community is was spot on. It’s why I joined in the first place. I will not spoil what is coming, but there will be a new version before years end, and 3.0 is underway. 

[2] “The Games Developers Play” by Andy Croll. Oscar versus Nadia was spot on about previous interactions with past teammates, and relationships. I learned about transactional psychology: parent, adult, or child, and the DRAMA triangle: perpetrator, rescuer, and victim. He also mentioned the stoics, Seneca and Marcus Aurelius. I have seen this so many times in my life. If you are building a high quality focused friendly family like engineering team, you need to watch this talk. Trust me. 

[3] “Designing an engineering team: Making room for everyone” by Jack Danger. I have been through a number of interviews and have given many more for people working for me and my teams. How to determine where the bar is set is a true challenge. Just like Aaron’s talk earlier, if you’re hiring you need to watch this talk. His points on evaluating skills and culture fit are spot on. In his opinion amazing teams focus on: people leadership, technical leadership, customer focus and metrics, and students. Finally there is no such thing as a real engineer. 

[4] “Yes, You Should Provide a Client Library For Your API” by Daniel Azuma. Summed up in three words, APIS ARE HARD! The goal of your client library is to know the protocol. Research and track how the users are interacting with your services. You have to care bout the developer experience. If this doesn’t matter to you, you will fail. Make the usage of your library familiar to the developers who write code in the language the library is written in. Ideally your library handles retires, error, etc. all can be tailored for settings. Do not make developers write this. Finally always use IDLs.

[5] “Uncoupling Systems” by Jeremy Hanna. More than one person should be making decisions. Silos are bad, isolated decisions will result in costly rework. Consider the network, how the systems interact, not just the services itself. Be careful of how interconnected your models are, the data set mashups can be challenging, and it may take time to cache them in order to be performant. In a nutshell, his best quote was: “Creating something to keep consistency between services is complex and it becomes very easy to over optimize.” 

[6] “Building for Gracious Failure” by James Thompson. Quote of the night: “I do not work overtime..” We can’t fix what we can’t see. If a team is working 24hours a day something is wrong. Visibility is the first thing you need to do before you manage failure. Going through the logs is not the answer. Trust carefully. Be careful of how errors bubble up to the end users. Each service should account for errors in the services they interact with. Intercept and handle. Expect failure. The infrastructure we build on is far less likely to fail compared to the shitty code that we write. 

[7] “Closing Keynote” by Bianca Escalante - I will let this attached graphic outline her points. It does it better than I could begin too.