Nils Löwe
Lightning Talks (Part 2)
Summarized using AI
Lightning Talks (Part 2)
by Christopher Turtle, Philip Szalwinski, Andrew Faraday, Nils Löwe, and Matthew BlochIn this second part of the Lightning Talks series from BathRuby 2016, five speakers explore diverse topics at the intersection of technology and creativity. The main themes revolve around innovative programming practices, responsible software development, and personal anecdotes that highlight the human experience in tech.
Key points discussed throughout the video include:
- Theoretical Exploration of Ancestry: Andrew Faraday introduces a unique perspective on tracing family lineage through the Semantic Web. He uses SPARQL queries on the DBpedia to explore historic ancestry connections, humorously concluding that the earliest traceable ancestor of Queen Elizabeth II is a bishop associated with beer.
- Paragliding and Programming: Philip Szalwinski shares his passion for paragliding, drawing parallels between flight experiences and programming journeys. He emphasizes the meditative state of flying and how unpredictability can lead to exhilarating experiences in both fields.
- The Wonky Limerick: Andrew Faraday uses a limerick to illustrate software development pitfalls. He discusses the importance of meeting customer requirements and the intricacies involved when projects deviate from expectations, culminating in a revised, satisfactory limerick that aligns with user needs.
- Responsible Software Development: Nils Löwe introduces the 'Manifesto for Responsible Software Development', questioning the ethical implications of software design in contemporary society. He asserts that developers must take accountability for how their code impacts the real world, particularly in sensitive areas like data security and military applications.
- Anonymous Hiring Process: Matthew Bloch presents improvements made to the hiring process at BiteMark, inspired by research on gender bias in orchestras. He describes the implementation of an anonymous audition system that focuses on candidates' skills and qualifications, aiming to reduce bias and create a fair evaluation process.
The session wraps up with reflections on the importance of ethical practices in software development and hiring, encouraging tech professionals to consider the broader implications of their work while fostering a more inclusive environment in recruitment. The overarching takeaway is that technology not only shapes our future but also requires responsible action from those who wield it.
00:00:19.310
In the next five minutes, I would like to take you on a journey through time. This journey begins with a theory: the theory that the world is controlled by a shadowy cabal of devil-worshipping, baby-eating reptilian shapeshifters, all of whom can trace their descent from Alexander the Great. It's the last part of this theory that I find compelling and perhaps plausible: the idea that there are still people walking around today who have a family tree that can be traced step by step back through the generations to a man who lived over 2,300 years ago.
Can we construct such a chain of people? And can we do it using Wikipedia? There are literally pages of biographies on Wikipedia, and you'll notice that many of these biographies contain links to other related figures. This brings to mind the idea of writing some kind of web crawler that starts from a well-connected individual, like the Queen, and then follows all the related hyperlinks to construct a gigantic family tree, hopefully uncovering a direct line back to Alexander the Great.
However, it turns out that there is a better way to do this, which involves something called the Semantic Web. We can think of the Semantic Web as the machine-readable part of the internet. The Semantic Web has an equivalent to Wikipedia known as DBpedia, which is a giant graph database that contains all the same information as Wikipedia, but in a machine-readable format.
The data is stored in a format called RDF, and we can query that data using a language called SPARQL. This means our path is reasonably clear. We'll construct a SPARQL query, much like the 'friend of a friend' query that Coraline discussed earlier in relation to Twitter. Instead of connecting Twitter followers, we will connect family members, starting from the Queen and expanding the connections to include those related by marriage as well, casting a wide net. After wrapping it up in some Ruby code and running it, the result is a huge network of thousands of individuals, which is quite fun to scan through, as it presents a who's who of notorious figures.
01:01:16.300
Among these individuals are Lady Macbeth, the Borgias, and even Jenga from some obscure references. But then, lurking at the very end of the list is Arnold Schwarzenegger. What’s he doing here? How is he related to the Queen? Interestingly, he is actually related to her as a distant cousin—specifically, a fifth cousin once removed. This can be demonstrated by tracing two nodes and seeing how they connect, as I have done here.
Now, what about our original question? Were we able to trace the connection back to Alexander the Great? We managed to get quite far, making it back as far as the Dark Ages, but at that point, we began to run into challenges with figures like the Vikings, Visigoths, and Vandals—people renowned for their pillaging and destruction, but not for establishing the kind of marriage alliances that would allow us to link the descendants of Alexander the Great with the royal houses of Europe. This proves quite frustrating.
So, how far back did we manage to reach? We made it to a sixth-century bishop—not a baby-eating bishop, but a beer-swilling bishop named Arleth of Metz, who is considered by the Catholic Church to be the patron saint of beer. With little more than a mere database query, I have been able to establish that the earliest traceable ancestor of the Queen is none other than the patron saint of beer, which I think is quite interesting and amusing.
00:02:21.400
Moreover, I believe there is a larger picture to consider. Up to this point, I have been merely connecting people to other people. Yet in this enormous Semantic Web world, I could also connect individuals with various other elements: historical events, places, ideas, and if I can accomplish this, it seems plausible that I could start to uncover new historical truths—essentially engaging in the practice of history through the data mining of the Semantic Web. Thank you very much.
00:03:10.800
Alright, in the interest of full disclosure, I work for Sky, and they have sponsored this conference, so yes, some palms have been greased to get me on stage, although they didn’t grease mine, so I can speak about whatever I want. Thus, my topic today is programming and paragliding. I want to start with a story. When I was younger, I watched the movie 'Fly Away Home', which narrates the tale of a girl who finds some geese and steals her father's airplane so she can fly them south for the winter, ensuring they do not starve or freeze. I was around ten years old, just like the protagonist, and I thought to myself, 'I want to do that.'
Thus, alongside Nerf guns and super soakers, I would request a glider on my Christmas list every year. Lo and behold, Santa would always deliver the Nerf guns and super soakers, but he never brought me the paraglider. As a result, I had to make it happen for myself. After a couple of years working as a software engineer in Chicago, I finally saved enough money to pursue that dream!
00:04:06.200
Initially, I thought I would have to run off a cliff or a big mountain to achieve flight. However, I discovered there's actually an alternative. Let me show you this short clip. In the video, you can see I am being pulled up into the air; the glider is trailing behind me. As I ascend, I find myself at an altitude of about 2000 feet, which provides a completely different perspective. Once I've been towed up, I am able to release from the line and simply fly. This is due to the sun heating the ground, which creates pockets of warm air.
This warm air functions similarly to the condensation on the side of a glass—if you run your finger along the glass, drops of water will fall. Tilting that glass 90 degrees illustrates the concept of thermals: something will cause the warm air to rise through the atmosphere, and that is what provides the lift, enabling a prolonged period of flight.
00:05:04.200
My first cross-country flight was with Yaro, a self-proclaimed Czechoslovakian. As he pulled me into the air, he gave me a variometer, which beeps to signal the rate of ascent. The faster I rise, the higher the pitch and frequency of the beeping. Armed with only this variometer and the knowledge that the sun rises in the east and sets in the west, I decided to take off. I reached the top of the thermal, where the beeping slowed, indicating I reached my maximum height. I radioed Yaro to inform him of my altitude—approximately 7,000 feet in the air! He encouraged me to choose a direction and go.
In flight, one finds a meditative state filled with calmness and introspection. I had the opportunity to fly alongside some hawks and noticed various things moving beneath me, including a garbage bag that surprisingly floated to 3,000 feet. After flying for around three and a half hours and covering about 35 miles, I landed next to a highway, right behind a Taco Burrito King restaurant. I called Yaro to let him know where I had landed, and to my surprise, he came to pick me up, and we celebrated with tacos for dinner.
00:05:46.200
Programming and paragliding often seem like solitary pursuits. When setting out on a programming project, you cannot always predict where the journey will lead. This experience of paragliding is akin to those programming excursions—it elevates us, energizes us. I'm genuinely excited about returning to programming now, driven by the new insights I've gathered today. So, what I want to convey is that we are all flying. While we may not know precisely where our flights will take us, the thermals are out there, encouraging us to keep soaring onward.
00:07:05.300
There once was a man from Dunoon who used to eat soup with a fork. As you can see, it gets a bit odd after this—the swordfish fly across the sky, and there are thousands of melting clocks. Now, most people would glance at this poem and think it has gone a bit off the rails; something about it doesn’t align with our expectations. When things go wrong, it is important to reflect and have a conversation about what has happened, how we intend to prevent similar issues in the future, and crucially, how to rectify any existing work that may be compromised.
The poem starts conventionally; we know exactly what to anticipate in the first line. It’s a signifier telling readers about the form we are employing, establishing expectations for subsequent lines. Looking at the specifications, it passes all requirements since it is eight syllables long and easily recognizable. The first line is perfectly acceptable.
00:08:04.600
However, by the second line, we deviate slightly from convention, failing one insignificant specification, namely, whether or not it rhymes with 'lime.' We have stepped away from the norm and needed to take yet another step away, which caused the entire piece to falter. By now, there is considerable validation in the database, yet we notice various specifications failing. Nevertheless, the paper still shows many green specifications passing without issue. Therefore, we overlook both the convention and its deficiencies. Under a tight timeline, we need to release this Limerick but feel cornered without line five. At this moment, we recognize we need to incorporate a new word: 'clocks.'
This is not a term I've used then or since, making it somewhat of an unknown quantity. Not a lot of foundations have been laid for it—it only has about four commits and lacks the community development typical of words. People aren’t even looking to see if there are any existing issues.
00:09:10.400
Regardless, we proceed with deploying it. It still passes most of the specifications, and that suffices. We release it, and the outcomes are mixed. The customer is not satisfied, though not necessarily unhappy about the specifications that are failing, primarily because they never requested a Limerick. Instead, they asked for a joke delivery system, and we failed to deliver on that request completely. We neglected to address that aspect, which the customer primarily cared about.
This highlights the critical importance of not completely disregarding customer requirements. We need to backtrack and evaluate our previous work. Soon, we realize we’ve created a tangled mess—spaghetti code of sorts. We cannot simply alter the last line and expect everything to fall into place; we need a complete correction. Our existing framework has faults, and if we choose to consume work in the same manner as the end user, we expose the very problem at hand. Soup with a fork captures it perfectly.
00:10:04.600
I appreciate the cleverness of 'eating soup with a fork' as a phrase; it stands out. I recognize the value in lines two, three, and four, hence I desire to avoid rewriting eighty percent of the project. This would be akin to starting over from scratch. Let’s examine line one—there is absolutely nothing wrong with it. It's conventional and time-tested, featuring a catchy Irish place name, serving as a strong opening. Nevertheless, it may not suit the Limerick we are attempting to create. If we consent that this just isn’t a good fit, we can rectify the entire poem with one simple change.
The new version reads: 'There once was a panther from Cork who used to eat soup with a fork. The swordfish fly across the sky, and the chicken was outlined in chalk.' This may not be exemplary, but at least it provides a punchline. The customer is now satisfied, as it meets all the parameters and fits their requirements, making the company content as well. I successfully maintained my surrealist lines in the middle, so I can say that I'm content as well. The end users are indifferent; nevertheless, we have achieved a completed project and can declare it satisfactory.
00:10:58.700
So, what do all of these tales have to do with software development? It appears I am running out of time; thank you.
00:11:41.800
Now, I would like to speak about the manifesto for responsible software development. The primary question I have been contemplating for years is: are we steering the world in the right direction? Software is ubiquitous in today's world; you cannot purchase a car without software, no plane flies without software—look around; software is everywhere. As software developers, we are the ones shaping the present and future. Are we truly doing the right things?
People have pondered these questions before—physicists centuries ago, and engineers in the 1920s raised similar concerns. I wrote the manifesto for responsible software development last year with several other people. Writing such a document was new to me, so I looked at the Agile Manifesto and reached out to its original authors for guidance. They shared insights on their methods.
00:12:45.800
The crux of the manifesto revolves around my accountability for my code—particularly when individuals use the software I write to aid missiles in targeting systems to take down civilian planes. Perhaps I should have considered the ethical implications of creating software that is too efficient for weaponry. There is a significant ethical usage of software; it can facilitate horrible actions today.
I must stress that the one who writes a system also bears the burden of ensuring its integrity. For instance, if my work could be distributed widely, I am responsible for determining its effectiveness. Data security is another critical issue; given recent breaches such as the ones faced by eBay and Sony, I question whether I can protect my systems better than they could. Thus, if not necessary to store sensitive data, I should refrain from doing so unless I can guarantee its encryption. Agile considerations prompt me to ask myself these vital questions to enhance our outcomes.
00:13:53.300
Take Google, for instance, consuming almost three gigawatts per year—it’s comparable to the output of a small nuclear plant, all to facilitate Google services. So when I develop algorithms that interact within a sizable system like Google, even minor increases in performance can yield massive impacts on energy consumption. Ultimately, it is my prerogative to choose if I want to craft weapons. However, I must acknowledge my responsibilities; it is not permissible to shift the blame to others, so I will not say that I merely supplied algorithms while claiming ignorance of their use. When it comes to creating things, I must take responsibility for their consequences.
I have written numerous articles on this matter, and if you are interested, there is a website to support this notion. The most vital takeaway is to think critically, engage in discussions, and question what kind of world you want to inhabit.
00:14:41.500
Now, I would like to share a brief story regarding improvements we’ve implemented in our hiring process at BiteMark, my hosting company that has been providing reliable hosting solutions for the past 14 years. This story revolves around an unusual improvement we've made in our recruitment system. A notable paper published in 1997 highlighted gender bias in hiring and provided significant findings. It indicated that in 1970, fewer than 5% of musicians in the top five US orchestras were women. By 1991, that percentage increased to 25%, attributed largely to the implementation of an anonymous audition process where candidates performed behind a screen.
00:15:35.800
The authors of this paper gained access to the candidate data from those anonymous auditions and found that women were 50% more likely to progress to the second stage of the audition compared to when the panel could see them. This sparked an idea within me as we began efforts to refine hiring practices at BiteMark, prompting me to consider how we can enhance our approach. Traditionally, we relied on a conventional interview process—dressing in our finest attire and gathering around a table to decide on the best candidates based on minimal data. After engaging with this research, I realized we could establish a reasonable audition process for each candidate, encouraging us to evaluate their skills and qualifications without ever needing to meet face-to-face or know their gender or age.
00:16:27.100
Our objective was to be more precise in identifying the attributes we desired in candidates while disregarding any extraneous factors. By April 2015, I developed a simple Rails application within six weeks, which allowed candidates to register on our careers website by providing only their mobile number and a pseudonym, sharing a bit about their motivations for wanting to work at BiteMark. We arranged interview times through text communication; the interview panel would convene online for discussions with candidates, meaning we were essentially interviewing cartoon characters, Pokémon, or other creative aliases. Our focus was on assessing their enthusiasm and skills rather than personalities or aesthetics that could lead to bias.
00:17:22.800
We maintained a strict commitment to culture fit being outside the criteria for these interactions, as focusing on this aspect could inject bias into the interview process. There was a secondary interview process involving a skills test demanding a couple of hours dedicated to developing a small project relevant to the role being applied for or working on a chosen scenario relevant for system administrators or researchers. This process utilized screen-sharing to facilitate performance assessment.
When the time came to evaluate the candidates' suitability, we effectively drafted our assessments to paper after each stage of the interview process to ensure a clear record of evaluations and decisions. When we arrived at the conclusion of this funnel, we could identify individuals we truly wanted to meet in person. Ultimately, it allowed us to approach these final interviews with the confidence born from having already engaged in valuable discussions about the role.
00:18:15.000
The feedback from this method suggested that candidates felt more secure entering our discussions since they were engaged in an innovative process rather than stepping cold into an unfamiliar company. This progressive cultivation of engagement improved candidates' comfort levels. Although at BiteMark, we are still a bootstrap company that has only hired five key people over the past year, the evidence is insufficient for a substantial study, and, crucially, we don’t have enough data regarding candidate demographics from those selected. However, this approach allowed us to achieve our targeted results by democratizing the hiring process and ensuring we secure the best talent while simultaneously building candidates' confidence in our team.
00:19:03.300
Overall, we managed to lower bias while engaging more candidates. We will continue refining this process as we look to fill our position for a front-end developer. If you are interested in seeing how our process works, I encourage you to check out the available positions on our careers page at careers.bitemark.co.uk or feel free to approach me afterward. Thank you!
Explore all talks recorded at BathRuby 2016
+12