Attending tech conferences is a great way to meet new people and to engage with new ideas. It also provides a handy excuse to get away from your desk and socialize. :)
This year, I went to J on the Beach at the Costa del Sol, in Spain, along with two of my colleagues: Markus, and Ruslan. J on the Beach brings developers and DevOps together to discuss topics relating to Big Data, including distributed systems, architecture design, machine learning, and so on.
While there's no official word on what the "J" stands for, this year it stood for "Joe"—in memory of Joe Armstrong (a pioneering distributed systems engineer and inventor of Erlang), who sadly passed away earlier this year.
In this post, I want to present the synthesis of our conference notes and, also, share a few of my personal thoughts.
(Emily, Ruslan, and Markus)
Talks
Collective Problem Solving in Music, Science, Software by Jessica Kerr
Kerr started this talk with a story about the Florentine Camerata.
The Florentine Camerata was a group of musicians, intellectuals, and poets in the late 16th century Florence who would gather to discuss (and subsequently influence) the history of music. Through their experiments, the stile recitativo was invented, which eventually led to the development of opera.
Kerr used this story as a jumping-off point to talk about other examples from history when people with diverse interests and skills came together and were able to achieve something remarkable. These examples spanned music, art, science, and software.
She used these examples to demonstrate one of her core points: great teams make great people (not the other way around).
Specifically, she argues that you can't throw a bunch of great people together and expect to create a great team. Because what makes a team great is its ability to function as a symmathesy (sim-MATH-uh-see); that is, a learning system composed of learning parts.
And in that sense, the team is more than just the people and more than just the relationships between the people. It's the whole environment.
For example, when it comes to tech: the tools you use, the infrastructure you build, the software you develop, the tests you write—these are all a part of the symmathesy! We learn from that stuff (through our interactions), and that stuff learns from us too (in the sense that we modify and improve it).
So, for Kerr, good software development is the practice of symmathesy. A team that does this well (through sharing, cooperation, and prioritizing the interests of the group) increases the capacity for learning across every part of the system. And that is how a great team will, inevitably, make great people (and, hopefully, great output).
I liked this talk a lot. Kerr is a highly engaging speaker, and I feel that her message is likely to resonate with any team that is trying to achieve something great (not exclusively software).
I’ve been fortunate (as well as strategic) to have worked in environments where the desire to learn, share, and achieve incredible things has felt omnipresent and infectious. And this has further inspired my own personal development. So, the idea that "great teams make great people" rings true for me.
Bonus: Kerr has a written essay covering the same topics.
Acoustic Time Series in Industry 4.0: Improved Reliability and Cyber-Security Vulnerabilities by Philip Brisk
Brisk's talk is based on some seriously impressive academic research, but you don't have to be an academic to understand the significance of what was done.
The research starts with a question:
Can you use acoustic information to reverse engineer (or determine valuable information about) a product or manufacturing process?
The answer it seems is: yes, you can—with some creativity and insider knowledge. Which I find pretty amazing!
In a study carried out at the University of California, acoustic data from a commercial DNA synthesizer was used to determine which DNA sequences were being synthesized with up to 90% accuracy.
This is an example of what is known as a side-channel attack, i.e., a computer security attack that exploits unintended sources of information.
There are some caveats.
For someone to be able to carry out this attack, they must possess knowledge of the DNA synthesis process, have access to the machine (to place a microphone nearby), have access to a similar device, and have access to the machine manual.
Nevertheless, this underscores the importance of comprehensive operational security when dealing with sensitive manufacturing processes.
Check out the research paper if you want to learn more!
Leadership at Every Level by Liz Keogh
Keogh begins her talk with a question: "What makes a great leader?"
If you research what other people have to say about this, you will find an abundance of essays that list fairly obvious-sounding (but nebulous) qualities such as confidence, honesty, integrity, and so on.
But Keogh dismisses this approach. She points out that great leaders come in all sorts of shapes and sizes. You can't generalize like that. It's not accurate, and it's not useful.
So again, what makes a great leader?
Keogh argues that great leaders demonstrate an ability to handle problems effectively and make good decisions consistently. Great leaders do this in a way that has a positive (and empowering) impact on the people around them, inspiring other people to become great leaders in turn.
When it comes to problem-solving, there isn't a “one-size-fits-all” approach. Great leaders are relied upon to select an appropriate strategy for each situation. So what can we do about that if we want to get better?
Keogh introduces Cynefin (the Welsh word for “habitat”), a leadership framework for supporting that process. It separates problems into five domains: obvious, complicated, complex, chaotic, and disorder. And, accordingly, each of these five domains demands a different approach.
Keogh asserts that, when tackling problems, we typically start with the low-hanging fruit: the things we know. Because we like things to feel safe and predictable. (It makes us feel like we're making a lot of initial progress.)
But the Cynefin framework invites you to work the other way around.
Start with the disorder, then make your way through to the chaotic problems, complex problems, and so on. This forces you to deal with (and eliminate) uncertainty as soon as possible.
Why is that important? Well, Keogh refers to a study done at UCL, which found that uncertainty can cause more stress than knowing for sure that something bad is going to happen. So, eliminating as much uncertainty as possible as soon as possible yields the biggest impact on overall stress over the lifetime of the project.
As a bonus, tackling problems this way around reduces the chances of getting a nasty surprise towards the tail-end of a project (which is only going to add stress).
I could have listened to Keogh talk for much more than an hour. The analogies and examples she uses are concrete and relatable. And she even provides some recommended reading, which I am keen to look at:
- Turn the Ship Around by L. David Marquet
- Drive Dan Pink
- Commitment by Olav Maassen, Chris Matts, Chris Geary
You can also find Keogh's speaker deck online.
Servers are Doomed to Fail by Jaana B. Dogan
Dogan, an engineer at Google, spoke about the inevitability of failure. And while not every company needs site reliability engineering, this talk gives a useful insight into Google’s approach to handling failure.
Her core argument is that failure should not be treated as an exception. Systems fail all the time. Failure should be expected.
Indeed, she argues, when failure is embraced in this way, it changes the whole engineering culture for the better. Why? Because instead of a culture where you worry about making any sort of change ("in case it breaks something"), you end up developing systems and processes (such as testing and continuous integration) that function as quality control, which, in turn, build confidence in your ability to deliver improvements.
Dogan stresses that Google also discourages blame. When something fails, no single person is responsible for debugging it. Debugging is a collaborative exercise. She points out that if only one person knows the system well enough to debug it, you are inviting problems.
It's interesting to think about how Keogh’s talk (which highlighted the relationship between uncertainty and stress) relates to Dogan's talk about being prepared for failure.
Embracing failure, and building systems to control it decreases the uncertainty you experience when making changes or troubleshooting a problem. And, in my experience, this has really helped me build up my confidence with the systems I work with. Which has, in turn, helped to reduce stress.
Check out Dogan's speaker deck for more.
Dataviz for Devs by Shirley Wu
Wu gave a talk on data visualization aimed at developers. This was a nice addition to the roster of technical talks because it helped to broaden our experience with the design aspect of working with Big Data. (Thanks to Markus for pointing that out, and for providing most of the notes for this section.)
Wu presents five valuable lessons that she's learned:
- Be curious and get creative with the data gathering. There's so much data out there just waiting to be visualized.For inspiration, check out this line-by-line visualization of Hamilton.
- Explore the data and its attributes before starting to design. Sketching out what's available can provide additional ideas for the visualization.For example, check out the results of her Four Years of Travel in 20,000 Pictures project.
- Visual metaphors can make or break a visualization.The Guardian has a piece that shows how America provides travel support for homeless people. Their use of simple lines and arcs (scroll down) makes the distance far easier to grasp than, say, plotting routes on a map.
- Use SVG paths and trigonometry. This provides all the flexibility you might imagine. And they scale to any screen size.D3.js and Vue.js are great tools for creating visualizations and provide you with a lot of scope for interactivity.Specifically, she recommends Vue.js over React because it has better and more performant support for SVG transformations.
Wu gave a live coding session demonstrating the power of D3.js and Vue.js that lasts for most of the second half of her talk. Live coding can be hit or miss during a talk, but this was great. You can check it out in the video above at around the 22-minute mark.
Wrap up
J on the Beach was great! And when I wanted a break from the hustle and bustle, it was nice to be able to go to an actual beach. :)
The talks were informative and engaging, and, covered an unexpectedly diverse number of topics. But in particular, it was refreshing to get the perspective of such a varied group of problem solvers (academics, researchers, engineers, and so on.).
Check out the J on the Beach YouTube channel for the full collection of talk videos.