I was able to to attend That Conference 2018 last week thanks to Backstop’s developer training. Why That Conference? Many coworkers have attended over the past several years and raved about how much they learn and also how family friendly and fun the conference has been. Having the opportunity to learn while also brining along my family seemed like the perfect idea for a conference.
We had a great time and I was able to learn and reflect. Below is the list of my thoughts and notes on the sessions I attended.
I have seen Jessica speak at GOTO Chicago multiple times and I enjoy the energy and insights she brings to topics. This talk was an interesting discussion about how the field of programming relates to the formation of the Florentine Camerata and other similar types of groups in art and how that shapes the conversations, learnings, and research in their fields.
Jessica introduces the idea of symmathesy (sym – together, mathesi – learning) which is defined as “an entity composed by contextual mutual learning through interaction.” She poses the idea that software teams are a symmathesy which is constantly changing due to the people, customers, tools, and feedback loops involved in the process.
She also makes an interesting comment about “10x developers” where a proficient developer is working with developers newer to a system and the challenges that arise from that situation. She proposes that the proficient developer should not make any changes directly to a system where the intent is to transfer knowledge to others. Instead, the newer developers should be driving a pair session with the proficient developer to ensure knowledge transfer occurs.
Jessica brings up several ideas on how to be a better team member. She talks about “generativity” which she describes as “the difference between the team’s outcomes with me vs. without me.” She says that “to become great, put the team first” and that “great developers aren’t born or trained, they’re symmathesized.”
She pushes back on the idea that software is a craft. Instead, she describes it as a necessary skill that we need to achieve the true goal of having an impact on the world. Software is not a craft nor is it art – it is an entirely new thing. Software is more flexible than metal and plastic, has fast feedback loops, the ability to run experiments more quickly than we’ve ever known. She says software is the next thing after art that we don’t fully understand yet.
This talk was focused on Northern Mutual’s conversion of a web site to multiple SPAs (Single Page Application) driven by multiple microservices. Dana provided some general insights on the process, but it was less prescriptive than I was hoping for. This was a good introductory talk to microservices and described the great benefits they saw in that transition.
Her group in Northern Mutual went from quarterly and bi-quarterly deploys to multiple deploys per day with the new architecture. Wow! That sounds amazing. It sounds like they did a good job in making the transition seamless from an operations perspective. Also, she described how management do a great job in supporting them and how they had to leverage that support to change their processes around change management to support this new model.
I was interested in attending this session since I am very invested in improving operations at Backstop. I was curious how other teams defined the role of an SRE and if there were techniques we could adapt at Backstop.
This talk was less prescriptive in terms of what you should be doing and more of a conversation about what SRE means within an organization. Victoria works for NewRelic and was discussing some of the tools they provide to improve visibility into the state of the application and related metrics. She referenced the Google SRE book and also the SRE workbook which I hadn’t heard of as good reference points on how to implement SRE within an organization.
I am adding the workbook to my “to read” list!
The title of this talk grabbed me! I have not seen penetration testing practices so I was eager to see the tools of the hacking trade demonstrated by a professional.
The talked focused on a vulnerability analysis of the That Conference staging site. Art described how he would proceed as a hacker to gather data about the job and then what techniques he would use to probe the site for vulnerabilities. He discussed the social engineering side in detail as he described how he would gather data on the individuals running the site to try and determine their usernames, associated sites, and personal details that would paint a better picture of the site. He used networking tools to enumerate the subdomains and web host as potential attack vectors as well.
The meat of the presentation focused on watching the requests the website made and replaying those as different users or with different permission levels to ensure they were locked down sufficiently. Art showed off some tools such as Burp to replay requests with altered payloads and headers. This was an interesting tool I hadn’t heard of before.
In the end, he discovered multiple vulnerabilities that were reported to That Conference and addressed prior to the conference. This was a very interesting talk!
This was my favorite talk of the conference! I strongly recommend watching the video. My summary here will not be able to list all of the great lessons that Cory provides.
Cory talks about how we can change our trajectory in life by changing the systems we use everyday. We are creatures of habit and it takes effort to push it outside our seemingly automated systems. He cites a quote from Hunter S. Thompson:
Beware of looking for goals: look for a way of life. Decide how you want to live and then see what you can do to make a living within that way of life.
He talks about how this quote allowed him to realize that he needed to adjust the goal in his life to find something that made him happy and then engineer his life’s systems to help meet that goal.
He goes on to list the seven pillars he believes makes for an exceptional career:
- Happiness is an advantage. Being an optimist improves your outlook and the relationships you have with others. Others are drawn to optimists.
- Be aware of the brain chemicals that generate happiness and the actions that create them.
- Stop wasting time poorly. Waste time well!
- Get better at saying no at the things that don’t excite you.
- “If you want to be an anomaly, you have to act like one.”
- Specialize. Be remarkable.
- Stop asking “How can I do it all?” and start asking “What do I want to go big on?”
- Engineering degree half life – 2.5 years. 10 – 20 hours a week to keep up.
- Embrace daily learning. Use a growth mindset.
- Know what to ignore.
- Learn how you learn.
- Consider buying time by paying others to teach you.
- Teach yourself.
- Learn one thing at a time.
- Degrees don’t matter.
- Dress strategically.
- Increase your luck surface area. Attend conferences, speak, consult, blog/tweet/share, etc.
- Fool argue, wise people discuss.
- Keep your identity small.
- Sit with people you don’t know.
- Be real. Network with people you like.
- Buy time, not stuff.
- Money buys time.
- Multithread your life. Learn while commuting, exercise while playing with family, etc.
- Systems > Goals
- Define what success means to you. Determine the price it costs. Pay it.
- It’s illogical to envy others. We don’t know the price they paid.
- Success is personal.
- Change your systems to change your life.
This session was overflowing with good content and ideas. As I said, I can’t do it justice by attempting to summarize and I believe the takeaways are entirely personal. Please watch the talk, I guarantee you’ll walk away with at least one thing you’ve learned or will want to start working on.
Elm has an interesting way of modeling the application. It is a functional language and one of its strong points is the excellent compiler error messages it generates. I had heard this previously and it was great to see it in practice. The error messages really were helpful!
I left the session with a good basic introduction to Elm and how it can be used to model an application in such a way to prevent errors at runtime. However, I think I would need to do more research to determine how it compares with React and if its popularity has declined as React has taken hold in the community.
Open spaces are informal sessions led by attendees focused around a single topic. Attendees were encouraged to propose ideas for sessions and set up times to discuss what they felt would be useful to them. Sessions included anything from specific technologies to financial independence to food and drinks.
I attended sessions on Slowly Breaking a Monolith into Microservices which was not that useful and a session on going Independent as a software developer by Cory House since I was so impressed by his keynote. I was a bit nervous attending these types of sessions since the content depended on whoever showed up to the session, but I liked them so much I attended more!
I was less enthusiastic about this talk although it was a very well told personal tale on his journey from angry teenager to developer. He does a good job describing how skills from multiple disciplines transfer to software development and also how to stay resilient in the face of failure.
Jason discusses the idea of seeking vs wandering and how both are necessary to succeed but serve different purposes. Seeking is purposeful and goal oriented whereas wandering expands our horizons beyond our known world and knowledge.
This was a good talk, but I felt the subject matter was similar to Cory’s talk from the day prior and both more broad and narrow so it was less effective for me.
This was a fascinating discussion on how to model document databases. I have limited exposure to document databases but heavy relational database exposure so I was curious what new patterns are used in this new model.
Matthew did a good job of describing the best practices for relational database design and how those translated directly to document databases. The most interesting aspect to me was how to represent foreign keys and relationships. There are multiple ways to represent relationships – normalizing the data into the document or storing a key to be looked up in a future query. Clearly if there is a significant amount of data it does not make sense to normalize the full data into the document.
This was an interesting talk and I want to try and get more exposure to document databases to see how these tradeoffs work with real data.