The following is a Q&A with Matt Jones, a software engineer who's been recognized multiples times as an Elixir Forum Member of the Year.
What was the first project you started using Elixir on, and what did you think of it at first?
The first thing I really started using it for—to do any serious work with—was an Advent of Code a couple of years ago. I saw a presentation by Jose Valim here in town. They brought him to speak at CoverMyMeds for Columbus Ruby Brigade. He gave a talk about scaling Elixir. I had been kind of just poking around at Elixir, and then when Advent of Code came around, I thought, “I'm interested in this language, and there's some problems that are useful.”
It was a pretty quick on ramp, because so much of the syntax, a lot of the kind of nitty-gritty, like which-punctuation-mark-you-put-where kind of things are similar to Ruby. People will say that there's a very high-level similarity, and I would disagree with that on a lot of the implementation details. But on things like the question of which symbol do you use to delimit strings, we're just going to do the thing that Ruby did. So it's not so much that they're the same language, but that a lot of the little annoying decisions like, “Oh we use semicolons to mean the same kind of things,” were there. There's a great tutorial that's literally Phoenix for Rails Developers, which was hugely useful for me. I thought, “I've been doing Rails for approximately forever. I just need to know what this word means over here.” So it was nice to have a quick reference that said, “You know how all of this stuff works already, it's just called different things. The pieces are in slightly different spots.”
I built some toy projects with Elixir, but the first really big work project was here at Test Double with Enbala. That was a really complicated project, but it was a good way to get your feet wet. They were specifically doing a lot of very Elixir-specific stuff with processes and things like that.
It seems like it helped that the syntax was familiar as you started using Elixir?
The syntax was familiar. There’s a lot of overlap in the spirit of the community. They're both heavily involved in giving back. Rails was historically one of the first ones where they were like, “We’re going to make documentation one hundred percent super important.” And, you know, people got really excited when the first pass of Rails guides came out. That was more than 10 years ago now. It set that bar where the tooling is going to have to be good, the documentation is going to have to be good. All of these things are table stakes for projects. And a lot of that carried over into the Phoenix and Elixir realms. So, the documentation is amazing, the communities of support around them are solid. So it was an easy language to step into, because of that.
Even at the time, it was not easy in the sense that there was a lot of change going on. I got heavily involved in Elixir and Phoenix in July 2017. That was when they made the jump to Phoenix having contexts, and the big reorganization of some of their internals came with that. In that sense it also reminded me a lot of Rails in the old days, because it was like, “Alright, so there are tutorials, but they're all wrong. Now you can read them and they’ll sort of help, but you have to kind of just wave your hands during some parts of them, because we do it differently.” It's a weird state. That drives some folks really wild—they want everything to be nailed down. But I really enjoyed the old days of Rails, where the answer was, “Well, go read the source and tell us what you find.”
What is something you really enjoy about working with Elixir?
The syntax. It is wonderful to work with, once you get going with it, it just works. The language designers have the same vibe that we need to make good code easy to type. If omitting parentheses is helpful, let’s make it possible for them to be omitted. The pipe operator I don't love quite as much as some people do. Some folks try to use it for everything. But it does make for some pretty slick expressions and drive some of your API design. The first position is magic and you need to make it work with the other ones.
The thing that struck me the most working with Elixir is that it lets you do things that would be so difficult as to be almost impossible in other languages. You just wouldn’t decompose problems the same way. You'll slice things into processes that you absolutely would not have done in languages where processes are more expensive or supervision is more complicated. Which is a blessing and a curse, because on the one hand you can write really powerful solutions that do really neat things. On the other hand stuff can break in ways that are incomprehensible to developers of other platforms.
I remember there was a case where the team I was working with made simulators that were processes behind the scenes on the server. That worked great until there was a bug, and then the simulator would crash and it wouldn’t work anymore until the server was redeployed or rebooted. In other languages, if you need that it's going to hurt because your tooling does not want to make that kind of long-lived process. You get a lot of new power, but you also get a whole new class of bugs with things racing, and what happens if it restarts too many times in a given time, and so on. So, it's fun.
You mentioned the community support with Elixir. How did you find out about the Elixir Forum?
I must have seen someone tweet about it. I assume I ended up there like most people do—they type something into Google like an error message and some other person who posted the same error on Elixir Forum turns up, and maybe fingers crossed there's an answer there.
You’ve been recognized as an Elixir Forum Member of the Year multiple times. What made you decide to get more involved as a contributor?
I don't know if I ever really sat down and actively decided to do it. So much of the time there are questions on there that are as simple as somebody needs to know the right place to look in the docs. Or someone needs to know a piece of vocabulary. There was one the other day where somebody asked, “What does this error mean?” It was in a live view template, and it was something about a remote function. So they said, “What do you mean remote, this is all on one server.” And the problem is that this error message is using very specific Erlang terminologies, but they're thinking remote in like a totally different lexicon. This means a very particular thing in here, but it doesn't mean that in any of the five overlapping contexts that we could be referring to, but we aren't. A lot of times, it's just stuff like that. If I see a message like that I will try to give them a pointer, like, “Here's the documentation for this function,” or “Here's what this word means.”
Personally, I find it really valuable to help folks along with it, because I remember starting out you grapple your way through it all. And other times there will be things like, “That's a really good question. I don't know what that does.” That’s the way I use those forum posts to drive my own learning. If somebody else needed to know about it, I may not have had a need for that particular piece of information but it’s bound to come up. You might answer somebody's question about something obscure about cookies one day, and then a month later it comes up in a SOC 2 audit.
Sometimes you just help somebody report a bug. Maybe you actually manage to get it all the way down to where you can help fix the bug. Helping people see that they can do it, too, is huge. If I say, “Here's the answer,” there will also always be a link to the documentation where the answer is, or “Here's the comment in the source code for the interpreter that explains why this is.” I think so much of the time the Internet is huge and unless you've trained Google to search appropriately it just gives you weird stuff back. I remember my Boot Camp students would say that. “Google doesn't work the way that it does when you type into it when we do it.” I've been typing nerdy crap into Google for 10 years, so it may learn something.
Are there any tips you would give to someone who is looking to learn Elixir or any new programming language?
Read lots of codes. I bet it sounds like the most ridiculously canned advice in the world, but the one thing that I've found a lot with students is that they don't spend very much time reading code. They're so concerned with the code that they're grappling with personally, that they tend not to get in there and read other stuff. The answers are sometimes in the docs, but sometimes they aren't. I think getting people to where they can feel comfortable answering questions where they don't know how it works by saying, “Let's go look for it,” can be really beneficial.
I will always remember being in a live coding session with students where they asked some obscure question and I said, “Hmm, that’s a good question.”
I had bundle open configured on the system I was working on. So I typed bundle open activerecord and just started wandering to wherever the heck it was. The whole class was like, “Wait, you can do that?”
“Yeah, you can in fact do that. You can do whatever you want. Check this out.”
And I think that's very much the case in Elixir. Everything is open. If you're wondering why the interpreter does this, you can go and find the place where it does that. Plus, you can figure out why it does that because there’s a comment from eight years ago where Jose is telling you why it does that.
Tell us about how you’ve engaged with Open Source.
I have not done a ton of open source recently because I've been kind of heads down with the client work. Most of the time I'm more involved in the support side, fixing minor issues. I don't do a lot of from zero. The biggest thing I was involved in recently was for an Elixir client I had last year. I was involved in some discussions with the Livebook team. I was mostly helping them write better test cases for embedding LaTeX markup into Livebook documents. There was a moment of “This should do the right thing.” That works until you have two underscores in one line, because with LaTeX, as soon as you have two subscripts, your party's over. That example was mostly build a bunch of test cases, and then figure out what's broken.
There was one other example—it's gonna be released in I think OTP 25, the next version of Erlang—they found this really weird corner case, something to do with the optimizer. I was staring at Beam disassembly to figure out what was going on. Somewhere way down in the guts of the machinery, there was an optimization that wasn’t being done right. But with the disassembly that I produced, someone who did know was able to say, “Oh, yeah, you need to do this” and added a tiny bit of punctuation to four lines and the bug was fixed.
Does finding questions you don’t know or things breaking contribute to better documentation in the end because you discover things?
Oh, yeah, that’s the way most of my open source contributions have arisen, like contributing to fixing something in Rails. One of my first patches to ActiveRecord many years ago was because they just rolled out has_one :through support, and I apparently found a way to use has_one :through that they hadn’t anticipated and it didn't work. Back in those days, there was even a warning on the bug tracker for Rails: It’s very possible that no one else has the issue that you're reporting, so don't expect anyone to fix it. So, basically, we welcome your report, but be aware you may not get any help. It’s just going to be logged here, so that somebody might help you fix it.
What do you enjoy most about contributing to the broader development community?
It's always nice to solve problems. So much of the time I get sucked into the larger, higher level discussions like how do we make a specific codebase not suck. That’s a really unsolvable problem. It's kind of nice to be like, “Okay, this person had a straightforward question,” and you write them up a nice, clear answer, and you actually solve the problem. There’s the feeling of bringing new folks into the community, because you will see folks that you helped, and months later they'll pop up in other conversations and help other people. That’s a really nice vibe. I will always remember I was at a boot camp, and one of the students came up to me and said, “Hey, do you remember me? You helped me set up my machine three years ago at a Rails Girls workshop.”
What advice would you give to someone who’s interested in contributing more to a support community for a language or to Open Source?
Make sure that you're helping and not just trying to provide answers. One kind of failure mode that people can get into is reading somebody's question, not really understand it, and then just be like, “Well, obviously you need to do X.” And the poster didn’t explain enough to actually say that. That is the biggest challenge I think people face if they don't know the answer for sure. Well, you don't have to. You need to be able to help the person get to the next question. Even if it's something like. “Can you paste the whole error message?” so you're not jumping to conclusions. Approaching with that spirit of, “We're going to find the answer together,” not “I'm going to try to make an answer happen.” Especially because folks will ask questions and half the time you might be wondering, “Why on earth are you doing this thing?” You don't want to push someone and say, “You should not do that thing,” because it's entirely possible you just don't understand. Instead you can just ask, “Tell me more about what you're doing.”
You don’t wander into conversations and be “I must know all the answers,” because that does two things:
Either people decide that and they're not helpful. Or they start to think they should be able to say that and they just don’t say the thing at all. You don’t have to know all the answers. You may be able to say, “I also have that when I do this other thing.” And that may not mean anything to you. But somebody else comes along and is able to say, “Wait, you did that and that, and they’re both broken in the same way? I know what that is!” Even little pieces of data like that can be super valuable. Because we’ve all ended up in the “What did you SEE???” situation instead.
So, don’t assume that you know everything!
