Programming Languages for Newbs: Tom Alcorn

Tom Alcorn of Flux.io joins us for a conversation about:

• why Tom’s got a fascination with programming languages and LLVM
• what are the educational resources outside of studying math at MIT that Tom has used to educate himself on computer science
• how Tom’s got his first data science job and it led to a software engineering career

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Max: Welcome all. I’m Max of the Accidental Engineer. Today we’re joined by Tom Alcorn, Backend Software Engineer at Flux.io in San Francisco.

Tom, do you mind sharing for our audience what you do there and what Flux does as a business?

Tom: Yeah, totally. Like Max said I’m a Backend Engineer at Flux.io. Mostly I work on backend services, so writing services and APIs that enable our frontend teams to offer new platforms and apps to our customer. The company is focused on architecture and construction users and provides data services for that field.

Construction and architecture have really large data problems. Building models are just one segment of that problem. It can be these huge files that have to get shared between huge teams of people like construction firms. So that’s kind of the problem space that we’re trying to address and specifically, one of the things we can do is take your geometry from whatever CAD tool you’re using and provide it to any other CAD tool that you’re using.

Max: Got it. CAD being computer-assisted design?

Tom: Computer-aided design yeah.

Max: It would probably be helpful for our audience to know how we know each other. We met on the job working for the same employer in Boston, a start-up called EverQuote, or now called EverQuote?

Tom: Yeah, previously called AdHarmonics.

Max: So that was your first job out of college. You went to MIT and like most of the guests that we’ve had on you did not major in computer science.

For our audience that has a similar background to you–without a computer science degree–how did you get that first programming job?

Tom: Yeah, just pure luck actually.

Max: For real?

Tom: The first line of code I ever wrote was in freshman year at college. I’m not the kinda person who was coding since I was like a kid or anything like that.

I touched “software” obviously all the time–everyone uses software all the time.

But I didn’t write any software myself until senior year when I decided to take some computer science courses right at the end of my degree to try and have something to be able to go to an employer and say, “Hey I can actually do a job that involves some amount of coding.”

I was a math and physics major in undergrad so I studied a lot of solving equations by hand, that kind of thing, not that much software.

The closest thing to programming I’d say is writing lots of MATLAB scripts to analyze data, which is a very handy skill actually not totally unrelated to what I ended up doing at EverQuote. But not at all like a “production-level” software engineering skillset at that point.

Max: What was the crossover from your math and physics classes to that first job out of school?

Tom: What do you mean by crossover?

Max: Were there things like MATLAB that your undergrad education gave you that you actually managed to use on the job?

Tom: Yeah, I guess so. Maybe not directly, I guess the fundamentals in mathematics and physics are applicable in a lot of different fields. At EverQuote I was doing data analytics, data “pipeline” building.

Learning the basics–the fundamentals of mathematical inquiry into a problem–was helpful in that regard. But I think the small amount of Python that I picked up while in college was helpful as well. That was the main language that we used there.

Max: It sounds like there were some hard skills that you obtained as soon as you started that first job for doing stuff like backend engineering, data pipelines.

Tom: Yeah definitely.

Max: What were they?

Tom: I think first of all, taking programming and software engineering to the next level from writing scripts, to doing data analysis and intro class-level stuff to: “this thing actually has to run and not mess up constantly.”

I mean, we’re gonna be depending on this and not only that but it has to interact with multiple other systems all at once. I guess it’s a generalized idea of “dependency management” and knowing how this piece of software that you’re writing will be run.

I think one thing about scripting is that you know the environment it’s gonna be running in. You’re gonna run it on your own machine, probably hit a button, the files are all gonna be there and it’s gonna do something. That’s a typical data analysis kinda workflow.

But in a production environment your script is gonna be running on some machine that you’re not directly logged on to it, it’s somewhere in the cloud. And it’s gonna be talking to these other services all over the place and you don’t really know where they are or what they’re doing. It’s a little more…you have to do a little more thinking about the environment that code is gonna be executing in.

Max: What were the some of the steeper learning curves in that first job when it came to knowing the environment your code would run in?

Tom: One thing that I really feel like I suffered from was not having a clear mental model of how a modern computer works from the ground up.

I don’t think you need to have a perfect, complete understanding of a computer to be a good software engineer. But I think understanding a lot of the basic things like what an OS is, what a kernel is, what is the networking stack doing–just having some basic kind of mental models of what’s going on can help you a lot.

A lot of that stuff bit me multiple times before I had the realization that, “Oh I’m actually running to the same problem over and over here. I should actually do some research and I’ll read about this, go on Wikipedia, start somewhere.”

Max: It sounds like there are some specific anecdotes. Are there any specific ones that you can give us about how you had a problem that arose from not being familiar with how modern operating systems work?

Tom: I have the emotional memory or feeling of banging my head against a wall like, “Why won’t this work? Why is it not doing what I expect that it’s supposed to be doing?”

Max: I can relate to that experience for sure.

Tom: Yeah, it’s ubiquitous. Everyone’s had this moment. Amazing software engineers and total beginners, this is a universal thing.

Max: As you start programming for the first time in a job role you’re always working with abstractions where there’s details below the surface of what you’re doing. Or you’re describing what the operating system or kernel is doing and you might not know exactly you don’t even might not know the tools for observing what is happening but if you’re there, the abstraction.

Tom: That’s really great, yeah. Great point.

Max: It’s like you said looking or going to Wikipedia reading about this stuff is like populating your cache so you don’t have to look another time. So there is a constant trade-off in your first job about whether you should just keep chugging and trying to beat the abstraction into submission or should I go spend God knows how much time. Maybe a full day for listening.

Max: On that topic about learning the stuff on the job, what were some of the resources you used to self-teach?

How did you get up to speed so quickly? Was there a real safety net for you in that first job to educate you about the skills that the employer needed or?

Tom: The people around me in the work environment definitely had a lot of good pointers. One great thing about the job was that people were super open and receptive to questions and willing to explain things to relatively fresh and green kind of employees.

Absorbing almost by osmosis what people are saying about things also helps in ways you might not even realize. Slowly you pick up words and concepts just from the way people are using them, which can help to link together the things that you’ve seen while you are actually working.

YouTube videos–there’s tons of them, you know.

Wikipedia obviously is a great resource, StackOverflow is a great resource. Another good thing to do is–a website like Quora is reasonably good for this–just trying to look for a slightly more general question like, “How do modern compilers do optimization?” You’re not looking for one fact, you’re looking for a set of answers that are broader and more open-ended. But that can be an interesting way to find new niches of knowledge that can help you sometimes.

Max: This is a very common phrase so far in interviews we’ve done: guests mentioning how being “on the job” and having the job inherently exposes you to coworkers who are invested in you succeeding.

You were describing osmosis or coworkers actively educating you up on job skills that are really valuable. Just getting that first job is really key to being in a feedback loop where your coworkers will help you overcome educational hurdles you might encounter but also cue you towards what topics are really important to be working on and learning how to be good at.

Since you moved out to San Francisco from Boston, have you been at Flux this whole time?

Tom: Yeah, the whole time I’ve been in San Francisco basically.

Max: What are the skills differences that you see in working at Flux versus having worked at EverQuote, the startup in Boston?

Tom: When I first started at Flux I wasn’t a backend software engineer. I was an app engineer is what I would call it. Working on various projects closer to the frontend, including making up absolute web apps but also making tools to support people making web apps.

Slowly I’ve transitioned into now working full time on backend services. That’s been an interesting transition.

First of all, it was an interesting transition going into being app engineer, having been in a data analyst role at EverQuote. I’d only really recently learned web development skills so there was a lot of groundwork to cover there as well.

Max: What application development skills did you have to learn when you came to Flux?

Tom: I think there were two really big ones.

One was learning the quirks of browsers. They are just really odd pieces of software and you have to work around the quirks a lot. I don’t love doing that. I wouldn’t say it’s my true calling is to make web apps because a lot of the time I think, “Why did we make browsers this way?”

There was a lot to learn there. Anyone can throw up a website, it’s intentionally meant to be low barrier to entry to “productionize” things. I feel like there’s a lot of knowledge actually that you need to have to ensure that your browser is gonna be interacting with your server properly and securely and efficiently…

Max: Do you mind getting specific? Like what specifically were you really surprised by and working on the frontend side of things?

Tom: Probably the most surprising thing was how much of a hodge-podge security is in browsers. And it’s gotten a lot better in recent years. I mean I’m glad I wasn’t working on this kind of stuff in 2007 or something because it was even more of a chaotic mess then. But there are a lot of things that feel like duct taped on afterwards as an afterthought of like, “Oh this is actually a security hole and we’re gonna have this new feature of the browser to patch this security hole.”

Max: Damn—what were you guys building app wise that was security wrought?

Tom: That’s the thing. We’re not even trying to build something…I mean obviously the client is a construction architecture firm so the data is sensitive. They don’t want building blueprints just going out to anyone in the world, right?

Max: Yeah.

Tom: So, they need to have a secure platform but that’s true of most industries. People care about their data not being exposed to the entire internet–we weren’t trying to do anything particularly special but if you wanna prevent someone from doing a clickjacking attack where they can show a fraudulent page to a user and then the user clicks on something and suddenly it’s sent their credentials through to your servers.

If you wanna prevent that kind of thing you have to do one kind of mitigation. There’s another kind of mitigation for evil websites using resources from your page to make a legit-looking evil websites that trick users and stuff like that. Then there’s all kinds of ways of securing cookies. There’s a lot of ways to do it wrong as it turns out. There are a lot of ways to do authentication wrong, there are a lot of ways to do data security wrong.

Max: Were these realizations about security things that your coworkers were pointing out to you–about the software you were developing–or were they things that you were discovering yourself?

Tom: Mostly coworkers pointing it out, yeah. We had already committed to doing a certain set of security things. Then the actual process of implementing those things turned out in some cases to be tricky. There was some amount of learning to be done about why do browsers do it this way, what exactly is going on here and why was that the decision made?

Again I don’t feel like it’s fundamental knowledge about computer science which is the stuff that really gets me going. It’s more just dealing with a platform that has its own quirks and everything any platform does.

Max: For sure. It sounds like you went from being a backend engineer at EverQuote to being more “full stack” and touching frontend a fair amount, based on the security stuff you’re describing. All that sounds, well, A) it sounds really rough. B) it sounds like, dealing with browsers is a massive headache.

Tom: Oh totally, yeah.

Max: And would you recommend for people who are starting their careers having gotten their first job or at their first jobs to forgo trying to work on the frontend side of things?

Tom: Not at all, yeah. I would say go for it. Every platform is gonna have its quirks no matter what you are developing for.

At some point you probably want humans to interact with the software. Maybe not if you’re just writing stock trading software or something. But if you’re going to have your software used by people then you’re going to be developing for a platform that involves interacting with humans and that is gonna have quirks for sure. And it’s because humans are weird or maybe computers are weird depending on your perspective.

Max: What are you hoping to work on in the next 5, 10 years? Presumably as a software engineer or do you see yourself moving into a different type of role with relation to your career?

Tom: Yeah I see myself doing software for the foreseeable future. I recently took a course on compilers which really interested me. I’m trying to explore that further, get deeper into that—I would like to at some point soon design my own language.

Max: So for our audience that doesn’t know what a “compiler” is, do you mind breaking it down for our audience? What is a compiler and why is it important to software engineering?

Tom: Yes, you can think of compiler as a Google Translate for software languages. It takes language A and turns it into language B and hopefully preserves all the meaning correctly. We all know Google Translate isn’t perfect, so there’s always quirks there and that’s where it gets messy.

But the basic idea is that you have language A which is typically something that humans are gonna be writing so it’s Java or C++—something that’s hopefully got good enough abstractions and clean enough syntax that a human is gonna be happy writing it. And happy is again subjective, right, but…

Max: I know this is a fucking landmine of a topic, but what in your opinion are “good” language features? What makes a programming language to you more human-friendly?

Tom: That is a huge landmine of a topic and it’s…I’m gonna give you a straight up engineering answer and say you’re looking at a bunch of trade-offs there, right?

Max: For sure.

Tom: So there is a couple of big trade-offs, I could say first of all back to just quickly reiterate what a compiler is. Language A can be something human-writable and readable. More importantly, readable is the consensus these days–we do a lot more reading of software than writing. And so it should be something that you can read and understand what it’s gonna do. And then language B is ideally something that a machine can execute or, if not, then could easily be translated by another compiler into something a machine can execute. When I say a machine can execute, I mean this is bytecode that you give to your CPU and it runs it. Or a bytecode that you give to a virtual machine which is kind of like a fake CPU, a virtual CPU.

Max: All right. Okay. So what makes code more human-readable?

Tom: Yeah, so with any human computer interface, HCI as they call it, a programming language is a user interface for programmers. The key thing is information hiding, not showing too much at once. Because we mortal humans can only hold so much information in our heads at once. There’s kind of a hard limit to that. Like, unless you are a genius or something that, you know, you can hold a shopping list worth of things in your head at once.

Max: Arguably geniuses are inefficient in that they’re trying to hold more…or they are capable of holding more in their brain than they necessarily might need to?

Tom: Yeah maybe they are doing it wrong. I don’t know.

Max: Basically I’m saying geniuses suck :)

Tom: Yeah, geniuses suck, yeah we don’t need those.

Max: We need languages that are dummy-friendly!

Tom: Dummy-friendly, yeah. Well we got them. No I’m kidding.

Well actually they’re dummy-friendly. I’d say Python is just friendly.

Max: Agreed. So I’ll bite, I’ll weigh-in on something that specifically about Python I love is the whitespace.

By whitespace I mean tabs and spaces that help indent your code, so that you can see the flow of where your software is going line-by-line. By requiring indentation of code as a property in the language you basically get punished if you indent your code too much.

And as a human, reading heavily-indented code is very hard to interpret because you might have conditionals like if/else, you might have for-loops or while-loops. And the more indented your code is, the less readable it is.

So one aspect of Python’s whitespace as a property of the language is that it punishes bad programmers, and forces…it penalizes you for heavily indenting code. And while you can style-wise enforce indentation and whitespace in the same way for other languages like Java, C#, JavaScript, Erlang, Ada whatever, every language, Python, it’s a built in proper language and I think that makes it a very attractive first language for people to learn. Or for companies to adopt as their, you know, application layer programming language but, that’s my [inaudible 00:23:26] heavy duty opinion.

Tom: Yeah, you come to ride on the minefield there. I feel like it’s…

Max: I don’t think it’s even that controversial!

Tom: Controversial? I feel like there are a lot of people who really hate the whitespace.

I’m not saying I hate it, I don’t really mind it either way or whatever but I’ve definitely met people who just despise the whitespace thing. I think because the way they see it, these are usually people who are happier writing C++ or something. The way they see it they are like, “I don’t want the language to tell me how to style my code. I want to style it…”

Max: Like overall style?

Tom: “It should all be able to run on one line if I want it that way.” I think that it’s about taking cognitive load off the programmer.

The example you’re giving is having the code follow a kind of uniform format, be it whitespace or whatever, one of a kind syntax like the language chooses to help unify the representation of code.

That takes some load off the programmer because they know what to expect when they see something. When they see even a certain shape of code they start to imagine what it’s gonna be doing. Which is why you see style guides.

Max: So that’s actually a topic that’s come up previously. We had a guest on, Anand Kulkarni, who’s CEO of crowdsourcing business for software development, where I was asking him about what acceptance tests–what criteria do they have in place to as requirements for whether a code is good or not?

And the type of test that you’re describing of linting and checking whether the code that a human has written conforms to a style guide is of the type of test it’s called “static analysis.” Static analysis is evaluating code in its human-readable form to determine whether there are errors that might be present without even having to run the code in its machine-readable form.

So, are there properties of programming languages that make certain programming languages more or less amenable to this type of static analysis? Where you can get feedback about what a human has written in the programming language without having to run it?

Tom: Yeah I mean absolutely. This is one of the number one design choices to make if you’re gonna make a programming language: “how much stack analysis do you want to do?”

Generally speaking, the more amenable your language is to static analysis the more explicit the programming is gonna have to be when they’re actually writing things.

A language with strong and explicit types like Java, in any given expression or block of code you know the type of what everything is. And so when someone tries to add an integer to a string it can either…it can maybe cast it or something fancy but generally, you would just say “that’s an error.” We don’t even have to run that line. We know it’s an error. So, you know, fix it.

Yeah, that can really be a great property. People also see it as a limitation because you have to write more stuff down in the process of making code. Whereas if you were using Lisp or some incredibly flexible language you can write shorter programs, you can write really concise, cool one-liners.

You don’t have to write as much stuff down but it’s not gonna be able to tell you at least unless you develop some really, really hardcore static analysis tools. It’s not gonna be able to tell you about errors before it runs them generally speaking.

Max: How did you get familiar with this topic of programming language design if not in your undergraduate degree? This is a topic that comes up a lot on our show: how do you learn things beyond a formal education?

Tom: Yeah. It’s a hugely challenging thing. I would say that very early on there was YouTube, there was coworkers and colleagues. Actually, I should have mentioned I worked through a textbook when I first started at AdHarmonics as well. It’s a classic computer science textbook called “Structure Interpretation of Computer Programs” so, you know, plug that one.

Max: Sure. Yeah and it’s freely available, we’ll include the link in the shows notes.

Tom: Yeah, it is and it’s a really good one. There’s also “OpenCourseWare” which is an MIT offering…not even software engineering–computer science lectures that you want you can find there.

But recently I took a course from a small, I guess “school” you call it called Bradfield Computer Science or Bradfield CS. They basically offer classes for full-time software engineers. People who are not trying to get into software engineering the way a coding boot camp might work, but people who are currently working and wanna go deeper into various parts of the field. So they offer courses on things like compilers or distributed systems or that kind of thing. They’re not really beginner topics, you need some groundwork before you would be able to make sense of a course like

But yes, now I’m a couple of years into this world and so I felt ready to try and take a course like that. So I took compilers. We worked from this scary looking textbook called the “Dragon Book” which is a notorious textbook in some ways like notorious for being like comprehensive but also maybe a little hard to pass sometimes how to read.

Max: I like that one.

Tom: But actually, I think it’s a pretty good textbook and there’s enough supplemental beginner-level stuff you could read online. And it’s good to have a reference book around like that as well. So we worked through from the start of language design all the way down to running it on a machine, a VM. So that’s all the way from, like you said static analysis, lexing, parsing, semantic analysis which is the part of the compiler pipeline where you do type checking and that kind of thing. Then on to bytecode generation and so we implemented the VM to do that. And then once you have implemented the VM you’re kind of done but, you know…

Max: VM being a virtual machine?

Tom: Virtual machine, yeah sorry. So that’s one approach that you can take. Another one would be to directly compile to a real machine target like Intel’s assembly language or something. But it’s a little easier to implement a virtual machine in some high-level language that you’re comfortable with because that way you know what’s going on inside it. Whereas reading through all of Intel’s assembly documentation can mean…it’s just a whole other thing to learn. So we have to try to keep it a little simpler than that.

So yeah, that was roughly what the course covered but it was just very inspiring and it introduced me to a lot of terminology that I wasn’t totally sure what it meant. Now I feel like if someone asked me a question like, “How does this part of a compiler work?” or something. I would know what to Google now, which is a really key skill.

Max: That’s the first step to understanding.

Tom: Oh it really is, yeah.

Max: Before we started recording, you mentioned one of the skills that you discovered that is possible to learn that you hadn’t known or been familiar with before taking the compilers course is familiarity with LLVM. For our audience that has never heard of LLVM, do you mind giving like a very broad 10,000-foot overview of what LLVM is and why it’s worth learning and why you’re interested in it?

Tom: Yeah I’ll give you the 10,000-foot overview because I feel like the level of detail to which I understand LLVM is probably the 5,000-foot overview. So that’s great, you’ve asked me the perfect question. So LLVM is…it sounds like VM, virtual machine, right? And it kind of is that but it’s also a library for doing code generation for any machine target that you want.

So LLVM doesn’t stand for anything I don’t think, but it originally was meant to stand for “Low-Level Virtual Machine.” So it has two components, one is a virtual machine which I don’t think is used very often. The other is code generation from LLVM’s intermediary representation. I should explain what all that is, but I’ll get there. Two whatever assembly target for whatever machine that you actually wanna run stuff on.

Max: Before you get further into the details, I think it might be worthwhile to share for the audience why this is a tool worth even attempting to understand its value. LLVM is a framework for writing programming languages or writing compilers, I guess.

Tom: I wouldn’t even say it’s a framework for writing programming languages. You remember when I was talking about some compilers take language A and go to language B sort of thing?

Max: Mm-hmm.

Tom: LLVM implements language B that you can compile your language A to. So it can be something crazy, you know, functional, whatever the next hot skill or something that’s got some really complicated features that you want.

Max: Abstractions?

Tom: Yeah exactly. LLVM provides what they call an intermediate representation but it’s just another programming language somewhere between C and Assembly in terms of complexity. It’s got some features that assembly doesn’t have typically or are a little harder to implement. But it’s also low-level enough that it can easily be translated into really tightly optimized machine code.

If you write a compiler that goes from language A through your pet language to LLVM, then LLVM has all these really hardcore, best-in-industry optimizations that they can apply to that intermediary representation to generate machine code that’s gonna run really fast.

Max: So, one example use case in the real world: the familiarity I have with LLVM is Apple’s use of it as a component of their compiler of Objective-C to assembly language code that runs iOS apps.

Tom: Yeah.

Max: I’m sure there are many other examples but if people need a rationale for understanding its value, it’s a component that is essential to running all apps on your iPhone or iPad. It is a pretty reasonable argument for understanding it and seeing why it’s valuable I guess.

Tom: Yeah totally. And if you’re just writing Objective-C you probably will never actually have to interact with the LLVM specifically but it can be interesting if you wanna know why this piece of code is running fast or slow or something. It could be interesting to take a look at what LLVM codes are actually being generated from the code fragment that you’re wondering about.

Max: So Xcode, the IDE that Apple provides for writing iOS apps, hides LLVM under the covers when you’re writing your Objective-C in Xcode but the guy who created LLVM or headed up the LLVM opensource project was a University of Illinois professor. He got hired on fulltime at Apple and then I think he left to join Tesla, and now he’s been a huge advocate for LLVM’s use in the development of the iOS platform and for running native mobile apps. But my familiarity with it is very low. This is the most intense conversation on the show where we’ve gotten into a computer science theory topic, I feel out of my depth.

Tom: I feel like I could point out one more reason why you might wanna use LLVM and again, I wouldn’t say I am an expert in this or anything. This is just what I’ve learned from one class basically. But because it’s backed by big industry players like Apple and I think there’s a few others even, you get a lot of really hardcore industry optimizations and performance and robustness for free. Instead of trying to learn Intel or x86 assembly–which can be really hard because you’re going from some really high-level like almost mathematical notation down to instructions for a machine–if you use LLVM you can get a lot of the optimizations that the big players get for free.

If you’re planning to design a language (which I don’t know how many of your audience members are into that but maybe people don’t even realize it’s a thing they could do), anyone can get in and just make up a program language. That’s how we go about programming languages actually was…by and large people were just making them up because they thought they should exist.

Max: And even if you’re not setting out to create your own programming language there are tons of jobs at places like Apple or Google or what have you where these large corporations are backing programming language development or design.

Tom: Yeah, absolutely.

Max: In order to optimize those languages that they have available for developers to develop apps on their platform in order to make them super optimized and preserve things like battery lifetime for phones, all kinds of levels of abstraction.

Tom: That’s a huge one yeah. That’s actually one area that because Apple compiles all their apps down to an almost machine code level before they even send the app to your phone–which they can do because they know what hardware they’re gonna be running everything on because it’s Apple, right? There’s like one piece of hardware for all, you know, for everything.

That’s one reason why I like iOS apps, they’re often better at using energy and can be faster and do more crazy graphic stuff than Android apps. Because Android there’s actually a VM, a virtual machine running on your Android phone all the time interpreting the compiled version that you got off the app store to run on your phone’s hardware which is something that the app store has no idea about. It doesn’t know how your phone’s CPU works because it could be made by anyone, right?

Max: So there’s a layer between the app that you get from the Android app store and what actually runs on your phone?

Tom: Yeah, in a way that there isn’t really that layer on iOS. So definitely that’s a thing that a lot of…it’s a reason why Android will probably never be quite as efficient and fast as iOS and at least for really cool applications like graphic stuff.

Max: People might disagree.

Tom: Yeah they might disagree and they might come up with so many technology that mitigates this. You know, totally it’s not like a done deal I guess but…

Max: So to wrap is there anything that you’d like to plug in terms of tools or resources that you think our audience will find valuable for learning how to get to a point in their careers that’s similar to yours job-wise/career-wise/skills-wise?

Tom: Yeah totally. One thing that I would like to suggest everyone do is last week I just got back from a conference called Strange Loop in St Louis, Missouri. It’s actually the second time I’ve been to it–I went once last year and then again this year. And each time it’s been a really inspiring and awesome experience just in terms of opening my eyes up to what is out there.

I’ve learned things that I didn’t even know existed, didn’t even think to imagine would have existed sort of thing. So it’s just a really good opening up of horizons and perspectives and stuff.

Max: And even if you can’t attend the conference in person…

Tom: Yeah you can look it up on YouTube, all the videos are on YouTube. And they have records back for…to the beginning I think so…

Max: We actually have a video with another EverQuote person, Kyle Feeley, Director of User Experience who has a bunch of tips for employees to provide arguments to their managers on why they should be allowed to go to conferences and why their employer should fund these conferences.

Tom: Oh cool I should watch that because that’s clutch, yeah.

Max: Well dude, Tom it’s been enough pleasure. Thanks for coming on.

Tom: Yeah thanks, Max.