00:00:21.560
I was at work the other day and I picked up a new story from the backlog. It said something like, 'As a business, I want A/B testing on the homepage.' This is clearly very important because businesses need to do a good job here. So, I thought, A/B testing on the homepage? Well, that's great because there's a gem for that! I opened a gem file, added the new gem, and then ran 'bundle install.' It fetched the gem for me and installed everything. The only thing left to do is run a quick script to initialize everything, check that it works, then push it to production, and we’re done! Everyone is happy: the business gets their A/B testing, and I'm happy because I'm getting things done and everything is easy.
00:01:01.320
But there's no time to stop and celebrate. I'm straight on to the next task. It says, 'As a user, I want some copy changes for reasons.' I can argue the reasons, but not since the Enlightenment anyway. Copy changes? Well, that's great! There's another gem for that! So I opened the gem file again, added a new line, ran 'bundle install,' and it goes and fetches the gem for me and installs it. This time, I need to write some kind of configuration file for it. I check that it works, push it to production, and we’re done! Everybody is happy: the customer is ecstatic with the copy change, and I'm happy because I'm getting things done and everything is easy.
00:01:41.520
This is pretty much what it's like to be a real developer today. In fact, I read some research recently that suggests real developers spend about half of their time just adding gems to projects. So, I thought, what's it like in practice? I took a project I'm currently working on and the first thing I thought was, how many gems do we have? We can just look in the gem file and tally them up. It turns out we have 40 gems in there. But that's not everything, because these gems depend on other gems. So I thought, what are all the gems I need for my project? We can ask Bundler this question and count them up. It turns out there are 120 gems! Now, this project is only about six weeks old, so that's like 20 gems a week, or four gems a day on average. It sounds excessive.
00:02:56.000
So, I can ask Bundler to unpack all the gems in the local directory for me so that I can poke around. I thought, let's find all the Ruby files in there and exclude the test ones, then count the number of files. It turns out there's 4,000 files in there! That's way more than I can go and look at. So, the next thing I thought was, we can take those files and stream them out, looking for method declarations to count those up. Now, it turns out there are 35,000 method declarations in there. It's actually a bit worse than that because about 90 of those are method missing; they respond to any message, and there are about 200 places that call 'def method' and add new methods at runtime. 35,000 methods! I mean, what does this all do? What does my project actually do? I have no idea what's going on.
00:04:11.120
To give you some kind of perspective here, I thought I would count up all the lines of code we actually wrote in the project. This is the code written by other developers, and there are about 1,000 lines of code. Then I thought, okay, I'll do the same thing and count up the lines of code that are in all the gems. It turns out to be 370,000 lines. Okay, so here's our code compared to the other people's code. Or maybe look at it another way: here’s all the code that's been through our rigorous PR process versus all the code that hasn't.
00:04:30.200
Now, look, it’s natural for a project to become complex over time. I mean, we add new features, and it takes complexity to implement those features. But there's something that just makes it worse and makes it happen much quicker. I'm not suggesting that gems are the problem here. If we had written all the code ourselves by hand, it wouldn’t have been any better. But I think the way we use gems is indicative of a problem. We tend to solve problems by adding gems, running scripts, or writing code. All these things add complexity. The problem is that if we leave this complexity unchecked, it kills projects.
00:05:26.080
Now, there are some things we can do to avoid complexity, but they all involve doing less stuff and thinking more. It requires caring more about the complexity we introduce, and this all takes time. It doesn’t make anybody happy, and it doesn’t make it's not always the right thing to do either. I mean, quite often, we just need to make progress. But this is all about balance. If we don’t think about complexity, it will eventually kill our project, and nobody likes a dead project.
00:05:51.840
So the next time you're thinking, great, there’s a gem for this or I can just bash out some code to fix it, maybe don't think that. Maybe try thinking about the problem instead. Try searching for a simple solution. It's a tough thing to do because in the short term, nobody cares. But in the long term, your project depends on it. Thank you for listening.
00:06:06.160
Thank you. This is a talk about Ruby papers we love. There's a website called rubybb.org. I'm a researcher; I look at how Ruby is used in practice and how Ruby is implemented. To do that, I read a lot of Ruby papers. I don't think people know that there are lots of Ruby academic papers out there. By papers, I mean documents written by scientists that are peer-reviewed and published in journals and conferences.
00:06:20.600
If you go to rubybb.org, you can see a curated list of these papers, and there's a surprising number of them about all sorts of interesting ideas. If you think some of the blog posts you see are interesting about what people can do with Ruby, you should take a look at some of the crazy ideas here and also the history of Ruby in these papers. I'll talk you through a few of the papers I'm interested in. This is a paper on YARV, the Ruby VM, which was implemented in Ruby 1.9. If you remember the days of Ruby 1.8 which changed to Ruby 1.9, this paper was written by Kichi, who worked on that. It describes how it works, what he was trying to do, and the whole idea behind YARV.
00:07:34.000
This is a paper which I wrote. It talks about how you can do metaprogramming in Ruby without any overhead. You've probably been told that Ruby is slow, and one of the reasons it's slow is due to metaprogramming. People use things like method missing, as John was describing, and this paper describes how we can make that have no overhead and make it really fast. One previous talk mentioned that threading is often hard. This is a paper that discusses how you can take a multi-threaded program and make it deterministic, so there’s no conflict between threads; you know exactly what each thread is doing at any point, and your program runs deterministically even with multiple threads.
00:09:12.000
You may have heard that Ruby has something called a Global Interpreter Lock, which means you don’t get true parallelism the way other languages do. This is a paper by people at IBM, and it discusses how threading works in Ruby. You may have heard people debating static typing in Ruby. This paper talks about how we can infer static types for you. You write dynamic code in Ruby, but Ruby is inferring all these static types, making sure you have a type-checked program.
00:09:48.000
We also talk about some papers on history. Ruby is quite related to Smalltalk, and some of the papers we've listed relate to Smalltalk but apply to Ruby as well. Now, reading papers sounds like something only a scientist might want to do, and sometimes they can get a bit complicated. This is genuinely some maths from one of these papers that discusses how Ruby works. But the great thing about these papers is they have authors, and they always put their email addresses on them.
00:10:07.000
What a researcher loves more than anything else is to receive an email from someone asking to explain how their work functions! So, if you want to read one of these papers, emailing the authors is a fantastic idea, and if you want to do a talk at a Ruby user group or your company, you might find it great to take one of these papers, understand it, and then present that as a talk. The authors will absolutely help you understand it.
00:11:40.000
We run two of the largest Rails Girls chapters, maintain a code of conduct, and run many events. When we look at our code of conduct, we have a statement that says, 'We are committed to providing a friendly, safe, and welcoming environment for all, regardless of gender, sexual orientation, or ability.' That's something I’d like to talk about today. At some point, we figured out that we were doing quite fine with one of our core conferences, EuroCamp, in terms of diversity, but we had an issue: we had an accessible conference, but no one showed up.
00:12:29.560
So, we decided to put that front and center for a year. Instead of just having a code of conduct on our page, we had an accessibility statement. This is the original version of what we did, which said, 'We are an inclusive conference, and if you think you have any issues attending, please come and talk to us.' That was positively received and used by Rubicon for Australia. They took the text and completely reworked it, doing a lot of advertising for it. If other conferences are interested in this, I thought I would ask if they want to do the same.
00:13:21.000
Now, this brings me to the question: why should we run accessible events? Most events, especially in the IT sector, don't put any focus on that. Conferences are a main source of contacts, jobs, and learning. We have a job board, and there are many people trying to advertise jobs. Lack of accessibility is plain discrimination. Every time I talk to organizers about this, they say, 'But it’s so much work!' But that isn’t true from my experience. Accessibility cannot be an afterthought.
00:13:59.000
Once you've booked a non-accessible venue, it’s hard to go back. You may have signed a contract for a room that costs you £20,000, and you can’t just leave that. So before you sign a venue, go and check if it meets all your requirements. I’ve heard that booking venues is less of a problem in the UK, but in Germany, where I come from, it’s a huge problem. Venues will actively lie about their accessibility.
00:14:42.000
It’s also a lot of simple things. For instance, if you're doing a flash sale for tickets, keep some tickets out of the sale. There are people who need two or three weeks to think about whether they can attend. They won’t be able to participate in your flash sale. Keep five or six tickets set aside for those who need more time. Accessibility is much more than wheelchair access. It's also about quiet areas for people with sensory issues, flexible food options, and translations.
00:15:22.000
In Germany, many people say they speak English, but actually, the reality is very different. In regions in southern Germany, many people don’t speak any English at all, so all conferences there have live translations. We also have to guide people if it’s a larger event. Budgeting for accessibility doesn’t necessarily have to be high, but you should still have a small budget for that.
00:16:15.000
For example, if you have a stage like this one, access could be provided through a ramp. Ramps may cost around £80, but you should have the budget for that. Not everyone with accessibility issues is disabled in a legal sense, so be mindful. Be open to requests and non-judgmental about them. People with disabilities are often the best experts on their needs.
00:16:48.000
One question arose from the community: are there any guides for this? I found two guides in German. One is a 100-page document from a nonprofit focused on barrier-free and inclusive events. The second one discusses how to throw accessible parties and events; it’s still an 80-page document. The issue is that there are no quick and actionable guides for small meetups without budgets, which is common in larger cities.
00:17:30.000
However, we are starting a project with RubyBin and another nonprofit that works with disabled people, Zal Helen. We're seeking funding to build a small website focused on copy editing and accessibility. If anyone's interested, please talk to me; also, follow me on Twitter or follow our RubyBin account. I’ll tweet the slides later.
00:19:00.000
This book is basically the kids’ advice version of Fight Club. As a developer, it's very easy to get caught up in the thrill of creating things and the dopamine hit. Yet, it’s important to think about what you’re actually doing and how it makes you feel. It doesn’t mean you should be socially valid in what you’re creating. You can want to build Facebook for dogs; that’s good, but be sure what you do makes you happy.
00:19:40.000
When you have the capability to create things seemingly out of thin air, it’s easy to place immense pressure on yourself to succeed, which is compounded by external pressures from the business. I’m going to repackage some advice you’ve all heard and probably ignored, wrapping it in a children’s book framework to see if it sticks. You can get so confused that you’ll start racing down twisted roads at breakneck speed, moving for miles through wild space, fearing you’ll end up at a useless place.
00:20:34.200
I’ve done the VC thing and built something that was promising. We charged money for something useful and raised a few hundred thousand. But here we are, four years later, and we are winding down the company. There were lots of reasons it failed; online travel is brutal and we could never make selling Google ads lead to booked holidays.
00:20:56.000
Spending other people's money makes you feel weird, and there were quite a number of fatal paper cuts. But there is something larger at play. For example, if you take VC for your company, you're aiming for money. Money’s nice; it’s useful for things like houses, children, and cars. However, even the best VCs only achieve a one in ten return on their investment, which actually looks more like a graveyard of failed projects.
00:21:44.000
Each skull represents years of people’s lives spent pouring their heart into projects that did not succeed. The VC doesn’t mind because they make all their money from that one gem that succeeds. Understanding the incentives of all the people involved in your business is essential: your customers, your investors, and your employees. Make sure you know why you're working for someone. Don’t be exploited for the dreams of riches.
00:22:30.000
All the places you will go! There is fun to be had, there are points to score, and games to be won. You will become the winningest winner of all due to the magical things you can do. Fame, you'll be as famous as can be, with the whole world watching you win on TV, except when they don’t, because sometimes they won’t.
00:22:41.000
Collecting money from normal people can be extremely difficult—nearly impossible. I love to pretend I tried this only once, but in reality, I’ve tried many times. What you want to build should have demonstrable value to someone with money who is willing to pay for it. Be a maker of useful things! Side projects can be fun to explore your skills; however, don’t try to make something into a business unless it’s meant to be one.
00:23:51.000
And if you take a job, don’t be too employable for too long. Having a little bit of unemployability is healthy. You will associate with many strange birds, so step with care and great tact. Remember, life's a balancing act.
00:23:59.000
So, I entered a business with this guy—more accurately, this guy. So, hands up if you’ve ever gone into business with a billionaire! Spoiler: it doesn’t always work out. A friend and I partnered with a billionaire friend to form an idea lab. That ended with me being shockingly fired in a Starbucks.
00:24:30.000
What this illustrates is that it’s crucial to make sure you’re collectively pulling in the same direction. There’s no wrong answer to the question of if you will succeed; you definitely will, with a 98 and 3/4% guarantee. Your mountaintop is waiting. Enjoy your work, do a good job, but set healthy limits for yourself.
00:24:54.000
The easiest way to do this is to have children; then you’ll be too tired to criticize yourself and will spend your time reading children's books. So get out there and explore, your mountain is waiting, so get on your way!
