The Frontside Podcast

Jonathan Jackson: @rondale_sc | Ember Weekend | 201 Created

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 60. My name is Charles Lowell. I'm a developer here at The Frontside. With me is Robert De Luca, also a developer. Hello, Robert.

ROBERT: Hello, hello.

CHARLES: Today, we actually have a meeting of the podcast minds. We have with us a very special guest, Jonathan Jackson. You probably know him from the Ember Weekend Podcast. If that's your thing, it's a great podcast. I listen to it, you should definitely check it out. Hello, Jonathan.

JONATHAN: Hey, how are you doing? I'm really excited to be on the podcast. I am an occasional listener. It's similar to my own podcast where if I don't edit it, I tend not to listen to it. It's when I have long trips you guys are number one, number two right behind The Adventure Zone which is a D&D podcast.

CHARLES: You worked at 201 Created. Why don't you tell us a little bit about that? It’s an interesting company.

JONATHAN: Actually, when we book to this podcast, I was not at 201 Created. This is a very new thing for me. I think I started right around the time of Ember Conference out in San Diego and I'm just realizing that this is not exclusively an Ember podcast. This is the first podcast I've been on where I can't just assume blanket knowledge of Ember stuff. But it's an Ember conference out in San Diego.

I actually gave a talk there about FastBoot which is a server side rendering technology. Right after that, the entire 201 company which I think is four. It's very small. The entire thing, the whole crew went to do a company event and basically camped out in the mountains for a few days, which was really, really fun. But I started working there and 201 is a consultancy based out of New York but I think it's more than half is remote. I think Matt's on the West Coast, two of them are in New York and I'm in Jacksonville right now.

We do a lot of really cool stuff. We worked in a lot of different companies. You can actually see the website at 201-Created.com and you can see the different clientele we worked with. But we specialized in consulting, training as well. As well as a couple of other services that we offer. It's been a real great experience. It's been very fun and also I'm learning a ton which is really cool to be in a different environment. I have done consulting for a little over four years, previously at Hashrocket. I got to tell you, consulting will get your wheels turning. It's been nice to see how different consultancy takes a stab at things. It's been super fun.

CHARLES: Yeah, it's a fantastic company. I've definitely known them for a while, certainly through my involvement in the Ember community and one of the things that always struck me is just how seriously they take the community aspect of it. We were talking about just a little bit ago, it was 201 that sponsors -- well, sponsor isn't really the right word for it. It does the Ember Community Survey which I think is a practice that we're now used to in the Ember community but I think it's something that I would love to see wider communities do. Maybe you could talk a little bit about that and explain what this community survey is, why it exists and what's the knowledge that's derived from it and how do we take action on that?

JONATHAN: 201 also does contribute workshops and things like that. The idea is to make Ember a more inclusive space, a place where people feel comfortable being a part of our community and a big part of that is self-reflection and realizing where you have weak points and how you can actually mend areas that are being neglected or whatever. Basically, shining a light to figure out where we need to improve and a big part of that is the community survey so figuring out what technologies are being used, figuring out what demographics are represented or under-represented and trying to figure that out.

It’s actually been really cool. I think this is the third community survey and it's live right now. I feel like we could probably shed a little bit about some of the questions. This year, they did a really cool thing where they actually put all of the questions before they put the survey up live. They actually asked for a comment period which is very, very Ember thing to do.

CHARLES: Because I was actually going to ask about that. Who is the final arbiter of the questions that get in because part of the survey is determining you're trying to get hard metrics on a set of questions but it's the questions that you don't know that you should be asking which are really the tricky ones.

JONATHAN: It was really interesting to watch the document change over time. There was a committee discussion between some of the people in core team and Matt Beale and Tom Zalman who's been doing the organizational stuff as an intern at 201 and he's been doing a fantastic job of really staying on top of it. It's a surprising amount of work to get a survey together, especially when you have a comment period so there's tons of little adjustments here and there need to be made, to wording and phrasing and also like responses. Surprisingly enough, you can actually have biases in your questions based off of the responses that are allowed because multiple choice.

It’s been a really interesting effort and I think trying to weigh and balance that side of things, where you want things to be worded in a way to where people can answer more honestly and without a bias coming into the question. Because the questions change year over year, trying to get data that is historically relevant so we can see what versions were being used last year and versus this year, what was your experience level with Ember last year and this year. But still make those changes that are recommended.

It's an interesting balancing act. I was very interested in the process. I was trying to stay as involved as possible but I think also, Isaac was working on that as well. It's been a team effort. The survey is a very interesting aspect of the Ember community and it's only been three years but it feels like longer.

CHARLES: What I love is the work. Once you actually get the survey up, the work has just begun, which clearly a lot of thought went into it, not just the questions that is very beautifully presented --

ROBERT: But the survey, what's the software that you're using to do that?

JONATHAN: I think Typeform is the thing that they're using. I feel like it actually works on mobile and I have a great analytics tools. If you're doing a survey, you should come talk to me.

ROBERT: Does that like track people that half-fill out a survey and exit?

JONATHAN: Yeah, it does. It actually does track like -- what's the word for that -- there's a word for that. Basically, the main metric that we're looking for is people who open the form then complete it and the percentage there, that's the respondent percentage. I've actually haven't seen the metrics yet. I think I might just wait until the conference. You're exactly right, this is only the first step so once everyone fills it out, then there's a bunch of data extraction because some of these questions are open-ended and allow users to directly input their own feedback and trying to sort that and make that useful information as a lot of work and a lot of effort.

It’s interesting to see, of course there's some obvious graphs that are going to happen like we see transitions. It's easy to graph out the number of people using things on a time axes or the X-axis or whatever. There's some kind that are obvious but I'm actually looking forward to seeing the results. I was only really involved in the actual administration of the survey in as far as I provided some feedback before the main feedback period. But it's been really a community effort which is great because it's a community survey. That's pretty neat.

CHARLES: One of the questions that I have is how do you ensure, because the only people who hear about the survey are the people who are already involved. In order to get -- I don't want to say statistically valid -- a broad and more informative data set, how do you try and balance the concern of we want to make, maybe half people exposed to this who aren't inside my community or maybe sitting on the boundary somewhere or slightly over somewhere versus at some point, if someone's an attorney for example, then we don't really care if they hear about or participate in the survey. Certainly within the developer community, which is ill defined to begin with, how do you try and draw those lines to make sure that you get the best knowledgeable dataset possible?

JONATHAN: You know, I don't really know. I guess, it's the meta point that I should probably make but it will prevent me from giving my opinion. Basically, I think that since this is a community survey, it makes quite a bit of sense for the community avenues for learning about Ember to be used to actually distribute the survey itself. For instance, these podcasts, like my podcast as mentioned in the survey and now, this podcast is going to mention in the survey.

I want to say, "It's going to be in Ember Weekly." That's just a guess, I don't know. But there's really avenues: Reddit, Twitter, etcetera and then the Ember blog itself. Those are the means for dispersal within the Ember community. The one metric that we get from that is what can we reach or who can we reach? How many people can be reached through the normal means? That in itself a metrics. But I think it's kind of valuable to test that every once in a while.

I believe over the first two, we saw 100% increase in respondents from Year 1 to Year 2 so it'll be interesting to see from two to three to see if that number continues to increase at a really rapid clip or if we're seeing some other trend there. It is an Ember survey so we are going to assume a lot of Ember-related things. We're trying to gain insight into the Ember community so it's probably not great to put it on JavaScript Weekly, for instance and get a bunch of React developers in that. They're going to be like, "I don't use this." Why are you using Redux, they don't understand. Oh, wait, Ember Redux, what's that? That sounds up my alley.

ROBERT: I did feel that form out at the survey with my experience that I've had with React recently, things that I would like to see come over to Ember. I don't know... That'd be interesting to see or I wouldn't want them to fill it out because they would, obviously ruin the data set but I think another survey with more information from other communities to see like, "What's preventing you from utilizing Ember or what are the barriers to learning it?" Maybe from other communities might be interesting. That would be cool to do cross-pollinated surveys where you can be like, "We'll do it, if you do it and then React can provide us something and vice versa. I feel like the word homogenization is bad, usually but sharing ideas is good, I think.

CHARLES: If you've never experienced this in your development community, the amount of work that goes into actually analyzing the survey and trying to draw and make inferences from it is just astounding. Who does that? Is that like Matt sitting up in an ivory tower? That's was just the wrong term. Basically, he can sequester himself for a month and put on his thinking cap and just come out with these mind-blowing deductions?

JONATHAN: To be honest, I wasn't here last year at 201. My suspicion is that Tom will do quite a bit of the data munging, I think is the word. Then we'll go through phases where I think Isaac and Matt are working pretty closely with the survey stuff so they'll probably do feedback loops, then eventually before anything happens, I think with EmberConf, there's usually a survey blog that comes right alongside the EmberConf thing, where you share some of the results.

I think that those things will go out to core and then core will start to pick it apart, toss that around exactly and then come back and basically, you're going to try to get as many people who are pretty smart, looking at it and trying to make sure the data makes sense and honest and doing the right things the survey needs to do, in relevant, I guess is the other metric.

CHARLES: Now, as part of the survey, one of the things that you mentioned was the purpose is to surface weaknesses and gaps that need to be filled. When you think about your experience and the way that you filled out the survey, obviously it's anonymous, share what you're comfortable sharing but what were some of the things that you perceived as maybe holes that need to be filled and you're hoping that the survey will bring to light.

JONATHAN: That's a very interesting question. I think, the thing that I'm interested in seeing is maybe different than what I've seen. One of the things I'd really like to see the survey that bring to light -- it's probably the most important metric in my mind -- is where people are at in the upgrade process because the cadence of releases an Ember is such a big facet of what makes Ember really powerful, especially for large companies and stuff like that. But I've personally seen people get stranded in certain spaces. Usually by the time they call a consultant to help them get un-stranded, they're at a point where they're going to try to work towards pushing past it.

I think this is felt primarily around the 1.13 switch. People did get stranded there and some people are still working on very large apps to push past that and I would really like to see just where the community is at right now, in general. Especially as a consultant because you come into a project and I don't necessarily know what to expect. I think on certain teams, I am always shocked I see like, "Oh, you're using beta and everything. You guys are on top of this. That's really cool. Let's do some feature [inaudible]," and you're really excited. But then other times, you get called in and they're like, "We're still using 1.13 and we have bind others in our source and could you please help us?"

CHARLES: Right and it's just that mountain is just too big to cross. That's something that you see in software development as the tools that you use tend to change and for lack of a better word, rot over time. In comparison to what's more newly available, it's the phenomenon of JavaScript churn, which is known in the community at large, scope down to just one framework where you've got different versions of the framework and you've got this churn. It's been somatic for Ember to try and it has been very aggressive attacking this problem and yet still, it manages to happen. How does that work, just given the amount of attention?

JONATHAN: Ember, hands down handles this better than most other JavaScript projects that I've seen. I've gone to old backbone apps throughout my career and knock out in Angular one, etcetera. I've seen the rot that we're talking about here and usually, once it gets too bad, the authors of the JavaScript libraries are unable to push it forward at all. Either band in it or end of life it and you're going to have to invest your own time to get pushed past this point.

In Ember, it really strenuously disagrees with that philosophy. They try super hard. All the people in core and really the community at large, the philosophy is like, "No, we're not going to break Ember. Ember is very serious here. We're not going to leave people stranded," yet it still happens. The reason I'm curious about seeing it is really about how do we make that story like a solved problem. Is it possible to do? Is it possible for us to basically make it to where the Ember community can very honestly say, "If you choose us if you choose this framework, it will be around. There will be a path forward for you for five to ten years and that's not something you can get a promise from anywhere else."

I just want to see what are the ways that we can make that promise more strong. I think, the LTS was a big step in that direction. I think that was actually last EmberConf which the LTS was announced?

ROBERT: Yeah, absolutely. Definitely all of our clients have moved to LTS as rather than trying to do every six weeks because they find that much easier to upgrade in between and they're more stable.

JONATHAN: They're more stable and I think it's such an easier sell like if you actually start talking about going up the pipeline and you're like, "I have to talk to my boss and my boss just to clear money. We have to clear time, etcetera." We're going to put a [inaudible] aside every six weeks to upgrade seems a little untenable for a lot of companies. I think for larger companies, it's sometimes okay because they're actually utilizing some of the edge features which is cool and I think that's a big thing. I feel like I have no real insight here but I feel like that's what LinkedIn kind of does, where they're usually pushing the boundaries because they're utilizing features like engines were first brought into LinkedIn. I think it kind of pushing it at the edge.

ROBERT: If you have the new LinkedIn Ember app, if you will crack open the inspector, when I last looked, I think the beginning of this week, they had two beta versions deployed. The Ember data version, that was beta and actual Ember, it was beta.

CHARLES: Usually large companies are associated with big lumbering end piece that are in terrible condition. That's actually a breath of fresh air. Shout out to LinkedIn.

ROBERT: Ember Data is 2.12 canary and Ember is 2.10 Beta 2 patch so it looks like they have a patch version.

JONATHAN: It doesn't surprise me that Data is being pushed. I think last I spoke to [inaudible] right around December, he was doing a lot of perf work on there so I think he's really pushing that pretty hard. There's a lot of really cool stuff like that and I feel like it kind of runs the game. You see the smaller teams who choose Ember for stability, they sometimes get stranded so I want to see if some survey data can probably correlate. You could correlate the size of your company to the version of Ember you're on. Maybe, we'll see some trends around if it does it mean that smaller companies have more difficult time pushing forward.

That would actually be a little counterintuitive. I would expect that smaller companies would be able to push forward at a faster clip because they usually have to support fewer browsers, etcetera. It'd be interesting to see information like that because I think that promise for ease of upgrade and there will be a path forward, that's a big part of what makes Ember really appealing to me. Especially as a consultant for four years, you see so many projects. I don't ever really want to advocate a rewrite but we're going to have to spend a significant amount of time fixing this and it's because you went with Mootools or something. Everybody guess Mootools wasn't so bad.

CHARLES: But the point is that you didn't go with a holistic solution so you basically had to write your own framework.

JONATHAN: Yeah.

ROBERT: Yeah, in Ember, it is a feature that you will not be left behind and you can upgrade. That is something that is really nice. I have upgraded a lot of Ember apps.

JONATHAN: I think Mike North calls that the patchwork app application. It's not just like React apps where you have React-Redux and Preact and all of this other stuff that you kind of piece together and make your own little quilt and that's your application. But this also happened in Backbone. It happened in jQuery before that and it was just like take this thing, take that thing, then I have this custom quilt, which is not bad. There are some advantages -- pros and cons.

CHARLES: Ember is giving you a blanket.

JONATHAN: And it's going to be a comforter. It's going to probably all look the same and be right.

ROBERT: My experience is I love Ember and I love the convention over configuration but whenever you hit that wall of the convention is actually getting in the way now, that is a very tall wall to scale in Ember.

CHARLES: Yeah, I think the flip side of it is like you say, Rob because everything does have to mesh, because that blanket has to be one solid weave, it means that you've got a hole in the blanket, the surgery required to excise that hole and then patch it --

ROBERT: I love his metaphor. His metaphor is --

[Laughter]

ROBERT: It's so good.

CHARLES: It takes a lot of effort.

ROBERT: Today, I'm quilting daily.

CHARLES: That's right. Next topic, crochet.

[Laughter]

CHARLES: But, yeah in order to make that surgery on the blanket to mix metaphors, which I love to do so freely, you have to make that cut and then make sure that the weave is again, seamless. I think that takes a lot of thought, it takes a lot of effort and it takes a lot of time. It means that there are shiny things out there that you might not be able to have.

I think, one of the ways that the community and the technology is mitigated is with the add-on ecosystem, which is very, very strong and allows you to riff and experiment and push those boundaries. But there are core pieces, things like the rendering engine, which can't really be modified or hooked with an add-on. They can but not in deeply fundamental ways or the templating. We saw that happened. There was a big kind of shift from first, the old handlebars to --

ROBERT: HTMLbars?

CHARLES: HTMLbars and then Glimmer 2, which there's been a flurry of activity around there but that was definitely one area where there was a hard wall right now. I feel like for me it’s around the handlebars itself. I would like to see that environment become more powerful because certainly, with the React Native work that we've been doing around here, you get to see just how simple like the JSX model is, React aside because like Vue, you can do with JSX.

I think JSX is a separate technology. It's certainly integral to React but there are a lot of other frameworks now that are using just the JSX part for the templating. Seeing that there is real power in being able to have the functional programming aspects of JavaScript right there inside your templates. From my perspective, I think that in Ember, there's a wall there that needs to be scaled.

ROBERT: To be clear to the Ember developers that are listening like us kind of advocating JSX, if you are having like, "No, that's a terrible idea. I hate JSX," I had that very exact reaction about a year and a half ago. If you go look at my Twitter feed, you would see me ranting about how much JSX is a bad idea. After I actually played with it, I'm on the opposite side. I think JSX is really awesome and I think there are things to learn from it.

CHARLES: I definitely love having templates. I love having the separation. I like having it in a different file but at the same time, I don't want to lose sacrifice the power that comes. I think that for people who are kind of sitting on the fence or have played with it, if you actually are strict about not having side effects and things in your templates, it really is a great experience.

I think there's a lot of people who have scars from doing ERB or liquid templates, where you can have all kinds of crazy side effects --

ROBERT: That's where my scars came from -- ERB.

CHARLES: Yeah, I can show. I can roll up my sleeves. I will be like, "You see this? I got that back in aught-seven with an ERB app, where they were calling out to a service from inside the template."

ROBERT: Setting the variable and modifying everything.

CHARLES: Yeah. There's definitely that tradeoff. One of the things that is great about the Ember community in particular is when there is, it takes a while to generate the will to recognize that this is a major problem but then the solution that you do get does, eventually match the weave of the entire blanket, which is really, really nice. But it can be frustrating when you have those core pieces of infrastructure that are presenting those walls to you.

ROBERT: I'm excited for Angle Bracket components because that's actually a lot of the gripes that I had with handlebars. Whenever I got a bunch of the curlies next to each other, like a bunch of components around each other, they all kind of just mold together and seeing the brackets and just looking like HTML, it makes it so much easier to grip.

CHARLES: Yeah, it's weird because you think that small things won't have big impact and you think that big changes ought to have a big impact. An example of this, I was kind of derisive of the whole Angle Brackets syntax. I was like, "Urgh! Angle Brackets, dah-dah-dah..." Then we started doing more JSX and you start seeing like, "I want to have my templating construct separate from my JavaScript and scripting constructs," and it actually makes a huge difference in clarity there. Obviously, the change to make all that happen is big but it's a small difference in the syntax. Tiny but I think it has a huge impact in the readability and the clarity of the templates and by the same token, all the performance increases.

At this point, I couldn't even give a flip. It's nice. It's great but there's a barrier, there's a threshold that has been crossed, actually some time ago. Performance of rendering is -- I can't even remember the last time it was a problem. What about you? Have you run up against performance issues in your Ember apps?

JONATHAN: Some performance issues but usually, they're a result of some rather inefficient rendering. Basically, a combination between user and keyboard or whatever. I wrote something really bad. It's not Ember getting in my way. I don't particularly mind the curly braces within my template but I think a big part of that is just editor choice. If your editor syntax highlights then it also knows how to indent handlebars correctly, that makes a huge difference.

ROBERT: Are we about to start an Emacs versus Vim war here?

[Laughter]

JONATHAN: No, as a matter of fact, I suspect you would win that when the Vim -- there's no good solution for indentation in handlebar templates that I found in Vim. If anyone knows that [inaudible], "Oh, there's one plugin," please ping me on Twitter because that would be nice.

CHARLES: Well, yeah. It's true. I can deal with it. I don't think it bothers me quite as much as it does Rob but I think what has been interesting is in our hypothetical code, you always like pay snippets in Slack. We started using Angle Bracket syntax just because it's so much clearer. Even though, none of us actually use it in any of our apps, when we're actually exchanging ideas, that's what we use.

JONATHAN: Yeah, there's some cool things that come with Angle Brackets that aren't just aesthetic. The container element is like you don't have to deal with the tag lists stuff anymore. I feel like there's a few tradeoffs that are going to be really interesting to see when those start becoming the norm.

CHARLES: Yeah, I like also the separation of what they did from JavaScript attributes to HTML attributes. It's really clear.

JONATHAN: Totally. I think it's [inaudible] cool stuff.

CHARLES: It's exciting. I remember being derisive of it -- not divisive, that's not the right word -- but I'm thinking like, "Why are they spending so much time on this," but I actually think it is going to have a big impact, small change.

JONATHAN: Totally.

CHARLES: No dis to the people who are working on it. I know it doesn't feel like a small change at all.

ROBERT: Yeah, it only took a year and a lot of really hard work.

[Laughter]

ROBERT: Like I peek in there and I'm like, "Hmmm... Nope, not smart enough yet."

CHARLES: One of the things that I want to ask you, you mentioned that at SO Ember, you gave a talk on FastBoot. You've actually got a lot of experience around the subject so I'm just curious. First of all, what were you talking about?

JONATHAN: I think my talk was actually called Boots and Shoeboxes, which there's a little library function into the FastBoot suite called the Shoebox where you can communicate between node and the browser. It's not like well-known enough to where that title resonated with people. I got up on stage and I was like, "You know, we don't have any descriptions on the speaker note like website. He just talks about FastBoot. I hope that I don't disappoint you," because they had no idea what I was talking about. Actually, I feel like the problem that's the FastBoot solves is a persistent thorn in people sides.

CHARLES: So what is the problem just to give full context? I think is it called like Isomorphic JavaScript for something --

JONATHAN: Yeah, I don't like using that word.

CHARLES: Yeah, there's like server side, SSR --

JONATHAN: Yeah, SSR, you'll see that a lot.

CHARLES: I guess the question is why would you even?

JONATHAN: That's a multi-faceted question. I think the first section of it would be what's the problem? I think for a lot of people, the biggest problem is SEO. A lot of JavaScript frameworks are not search engine friendly, then that affects a lot of different things. It means that they're not archivable either so it's not like you can have this on archive. They're not very crawable. This is becoming less of an issue because Google Crawler, for instance will actually parse JavaScript now. But I feel like that's still limited. Also you have to then think about how the Crawler is going to like actually execute your JavaScript. You're like, "Wait a second, so now I have to have a compatibility table for Google Crawler? That sounds madness." I think that's a big component.

There’s also the idea of speed downloading as low as poor connectivity devices or locations, I guess. Having to download all the JavaScript before you see the first meaningful thing is not a very good experience. Especially for a huge swaths of different types of sites like Discourse, I think is a big Ember forum software. Forums are mostly just static text, like you just want to read the text so time in First Meaningful Paint could be like as soon as you get text onto the page, that's could be really fast.

Some sites that doesn't make sense for it like if you're posting a video game or something like that, like you need interaction for that site to be meaningful. There's still tradeoffs there but there's a whole host so I guess that's the need. Then the solution for a lot of people is to start rendering JavaScript on their backend software and presenting full HTML along with a JavaScript source tag so that you get a Meaningful Paint first and then you get the JavaScript a little afterwards. The whole point of my talk, which I was basically like --

CHARLES: That's a hard problem.

JONATHAN: Oh, it's a very difficult problem.

CHARLES: Unlike anyone who says they have a solution, you should look at them with extreme mistrust.

JONATHAN: Yeah and there's a whole bunch of different solutions that people have tried. You could actually have prerender.io, I think is the service that will actually render it for you and you put it in front of your CDN and they'll actually do that and create static files for you, which is a solution or no script tags. You basically render all of your stuff as much as you can on the server side and you put everything into no script tags and that will presents its own problems.

There’s a bunch of different solutions that people have tried. In FastBoot, the solution that Ember went with and I think that it's really cool because server side rendering and this is the big reveal of my talk. I think it's recorded so you can check it out. But the bigger reveal is that the server side rendering is not just about rendering. It's also about routing and data fetching and authentication and etcetera. There's a whole bevy of things that you also have to handle very well. It's not just taking a component, the view layer to component and rendering it to HTML and then serving that. It's much more than that. You want your app to basically run in node. FastBoot does that remarkably well. There are some spots where it's a little fuzzy but does it remarkably well.

CHARLES: What's an example of how you would might need to handle authentication? That sounds terrible.

ROBERT: One of the problems for a lot --

JONATHAN: That's exactly the problem. You actually have access to headers and stuff and FastBoot land so you can do authentication by using traditional token off, which is pretty cool. There's a lot of really cool things and routing is obviously handled quite well so the request comes in and it does the normal Ember router. The Ember app instance itself is running in node so all of the things you expect to work in the browser, work in Ember and node, with the exception of any time you need to access the DOM because the DOM is expensive like very, very, very oddly expensive. Like JSDOM is just expensive and unreliable, then you have to deal with compatibility tables for that.

Anyone who has written tests for Phantom and tried to bind a function or something, they know the pain. I think it's fix now but I was always bitten by that so many times. It doesn't even give you the right error. Forget about it.

CHARLES: You have all these things. It's basically authentication. It's data. It's making sure that you have in your, so to speak, headless environment as an authentic replica of your application running in the user's browser, as you can possibly retain.

JONATHAN: Yeah.

CHARLES: How feasible is that? Like what you're saying is that Ember takes that whole approach and says, "Okay, we're going to make sure we handle all of these cases?"

JONATHAN: Yeah, I think Ember has done a phenomenal job of this. It's still alpha software, although I believe that the path to 1.0 is basically paved. It just needs some documentation. I think FastBoot hits the nail right on the head and gets a lot of the stuff really in a good place. It's also a big part of FastBoot's call to action where this stuff is possible elsewhere. You can do all of these things. You can make all of the stuff work in the React ecosystem or Vue ecosystem, etcetera.

But in Ember, it's Ember install, Ember FastBoot, I think or Ember CLI FastBoot which is a really compelling sell because I've looked at some of the alternative approaches and in other ecosystems, they're very complicated. It's not possible. It's just their ad hoc --

ROBERT: And it's usually a 10,000 line medium posts that you have to follow line by line --

[Laughter]

CHARLES: Right so instead of giving you actually a working code, what you get is a treasure map.

JONATHAN: Yeah, exactly. It's like you just shop at Ikea. Here you go, build it. There's some really cool stuff that it unlocks and the fact that it's so low-hanging fruit, for instance Ember Weekend, which by all accounts does not need to be on FastBoot, isn't on FastBoot because it's ostensibly free and it's a good testing ground for me to learn about FastBoot. But the future --

ROBERT: It's interesting in handling audio on a FastBoot, how was that?

JONATHAN: Since the user doesn't actually can't listen in node land, the user can only listen in a browser, we don't do anything with the player in FastBoot land, which is fine. There are some weird things like you have to basically have guards around like key events, for instance. Because Mousetrap relies on, I believe in jQuery to bind its events, you have to basically say, "In node land, we're not going to bind any of these Mousetrap events because they will not work," but there are some things you have to learn about the ecosystem but by and large, it's a solution that you just drop in and you just get for free.

I think that's a huge sell. That's another thing with the convention over configuration argument, the model is that eventually, once the solution arrives, most of the people who are using Ember can just use it right away. It really does help with [inaudible] activity devices. There are some really interesting things about how time to first paint, I think Martin [inaudible] just released an add-on that basically says, "I'm going to take all of your JavaScript files and mark them as async and then when you download, the time to first paint becomes almost immediate," because it's just going to say, "I have HTML. Here's the HTML and serve it."

Then in the background, because of script tags or whatever, it just goes and fetches the stuff in the background and you end up like time to First Meaningful Paint is really cool so it'll perform software that is super neat. If Discourse wanted to say, "Here's the stuff and we're going to make it work later," like as soon as the JavaScript has download, that's a really cool sell too.

There’s a lot of weird edge cases and describing the interactions is I think the hardest part about FastBoot. It's just like describing why this might be really good for you is the hardest part because a lot of people don't have these problems. If you're doing a marketing site, you're probably going to use Squarespace or something.

ROBERT: Yeah, like a static site generator or something?

JONATHAN: Yeah, exactly.

ROBERT: Something that will give you great SEO results.

JONATHAN: Exactly.

ROBERT: You want to play around with that.

JONATHAN: This dovetails into something Edward Faulkner was talking about eight or nine months ago when he was working on the inline content editor for Ember. It's really, really neat. I actually like to see where that's at now. I think it was Cardstack that funded a lot of the stuff for it. But if you combine things like that, then also FastBoot, you're starting to talk about something that could do what WordPress does, which is a really interesting thing like the really, really low hanging fruit. Type these few commands and you're point clicking your way to a website which is really, really cool.

CHARLES: All right everybody, thank you so much for listening. Thank you, Jonathan for coming on by and talking with us today.

JONATHAN: Yeah, thank you so much for having me on. This podcast is super awesome. I'm really excited to actually be able to be a part of it. I feel like you are at Ember Weekend that one time and you were in Norway?

CHARLES: Finland.

JONATHAN: Yeah, Finland and we weren't able to actually have a video open at the same time because of the data problem. It's been actually kind of cool to actually have a real conversation. That's been really great.

CHARLES: Yeah, that has been awesome. That was a good conversation and that, your podcast obviously is EmberWeekend.com. Everybody go and check it out. Thanks for listening.

Show Notes:

Resources:

React Native and Chill: A tale of stupid made fast by Charles Lowell

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 59. We're getting up there, 59. That's like, I don't know, it's not a milestone but it's something.

ROBERT: It's like one away from 60.

CHARLES: Yeah, it is. It’s past middle age. It’s like elderly.

ROBERT: Start thinking about retirement.

CHARLES: Yeah, exactly.

JEFFREY: These are our golden years.

[Laughter]

CHARLES: Welcome to the golden years.

ROBERT: All right. Possibly, we need to go and watch the Golden Girls.

[Laughter]

CHARLES: Actually, I think it was only five or six episodes, maybe 10 episodes, we were singing The Golden Girls theme so it all comes back around. We’re here with a very special guest and that guest is nobody. It's just folks from The Frontside --

JEFFREY: I was hoping you would say it was Betty White.

[Laughter]

CHARLES: We're going to fly it solo or like tri-lo or like trio.

ROBERT: Trello?

CHARLES: Trello. I, of course, am Charles Lowell. With me is Jeffrey Cherewaty and Robert DeLuca. Hey, guys.

JEFFREY & ROBERT: Hey, what's up?

CHARLES: We were kicking ideas around and something that's been kind of percolating around the offices is a theme for 2017 is doing dumb stuff, just stuff that has no apparent value but that you can learn from. I think, we each have a bunch of these experiences where we've done something a very little import that ends up being really, really helpful, either both in the short-term and the near-term.

JEFFREY: And who knows, maybe this episode will turn out the same way.

ROBERT: Oh, how meta. This could become a black mirror episode. I'm start to questioning my values.

CHARLES: I know for me, I recently did some explorations into React Native, which I found to be very edifying. I could obviously talk about that experience quite a bit I did on a blog post but I'm curious, if you guys recently had something that was a throw away, something that you did that wouldn't really matter if it had come into existence or it didn't but it's just so happens that in this thread of reality, it did.

ROBERT: You know, I have. It's always been centered around the impagination library that we wrote here. I was always kind of intimidated by impagination for some reason because it was this big library that I didn't necessarily understand. I was like, "You know what? I'm just going to go for it. I'm going to go do something dumb with it," and then I just decided to implement the most useless infinite scroll. It solved absolutely nothing and as you're paginating through 500 records of robots from Faker, I sat down and spent six days and wrote some code and implemented it React Native and it was actually the most informative and fun thing I've ever did. I don't feel tied to it.

CHARLES: Yeah, so what kind of inspired to do that? Because usually, it feels like there's this pressure to ship something. Ship something is like just go build something but the idea is that you're going to build something that people actually might use.

ROBERT: Yeah, I always had that idea. Maybe you can think about it as like feeling getting cornered, like the pressure of shipping sort of pushing me into a corner. Then eventually, I just kind of lash it out like, "No, screw this. I'm out." I'm going to go do something that's not even useful. I don't care. I'm not going to try and support people or make it to something that other people can use. If that is what falls out of this, that's cool but I'm going to totally sidestep and this needs to be something that other people can use.

Sometimes, when I go to build a project, I start thinking, "This is going to be in my GitHub public profile. What if somebody comes and finds it? What are they going to think about my code?" And I just shed all of that fear away, then what happened is I learned a ton. After that experience, I was like, "Whoa. This is massively valuable."

CHARLES: Yeah, like hearing you talk about it makes me think about one time I went to a Picasso art exhibit and they had all these sketches that he'd made just in pencil from when he was younger and they were in studies. I guess, apparently artists do this a lot where it was like just a goat's leg. Or some old man's nose. You know, just in pencil or charcoal and these are little tropes that he later integrated into all of his painting --

ROBERT: That is an amazing way to put.

JEFFREY: It's funny. When you see engineering tutorials are like, "This is how you learn to make software." A lot of times that is the way they're structured it is around studies. Like, "Make this little tiny thing that by itself is worthless but can be part of a greater whole."

ROBERT: Yeah, take that impagination infinite scroll thing, I think three months later, it turned into a full on talk about co-chairing between React and React Native but it started with this dumb little project that I decided, "If I don't finish it, nothing bad happens. It just kind of sits there and rots." I feel no guilt. No pressure.

JEFFREY: Would you say that was part of your blue period?

[Laughter]

CHARLES: Yeah, I like you [inaudible] point to like ship it. It's like we have a culture of ship it or don't. In any way, it's entirely up to you.

ROBERT: I kind of thought to think about it as the extreme of ship it. Literally, just ship it even if it doesn't work.

CHARLES: Right, ship it even if it's wrong.

ROBERT: The other thing that I figured out was who is to determine what's wrong or right. I figured out that no one like I figured that out and I choose if it's wrong or right.

CHARLES: Right, and it's like whether I learned something or whether I didn't or whether I get to be the arbiter of what I get out of this experience.

ROBERT: And you almost always learn something. Always.

CHARLES: Yeah, you definitely do. I think it can pay off, both in the short term and in the long term too. I know with my recent experience, I was feeling extreme burnout. I don't know... You feel like the code that you're working on or the things that you're doing have become a burden. I guess that's kind of to your point, Rob like when you are building something that it creates users. It creates code. It creates maintenance cost. It creates contributors. There’s all this mass and inertia and momentum that are for it and that can be great if you own something massive, you can have a lot of momentum and it can be extremely energizing. But it can also be a burden, if it's something that you have to carry and you feel obligated to carry.

ROBERT: Yeah and when you have those huge successful projects, things that come to mind like Ember or React or Babel or things like that, those are awesome. But I was always experiencing that responsibility with things where I had big plans for them but nobody knew that just by looking at the projects like it was still very much a work in progress. But I felt that feeling in my gut.

CHARLES: Right and that mass and that inertia can come completely and totally from an internal source. It’s both important for the project to be like these throwaway projects to be completely and totally free from all attachment, especially from your own dreams and your own ego and things like that.

ROBERT: And when I learn to let go, that's when I learn that I'll learn.

[Laughter]

ROBERT: I'm going to learn-learn.

CHARLES: I guess, the kind of greater point that I was making is that when you are able to approach a project like that, then it can be a really intense cure for burnout because you are just allowing yourself to create, you're allowing yourself to feel creative and actually deliver something whose success parameters you define entirely. I think, Brandon actually talked about this almost like two years ago with that robot. That project that he did where he was kind of in a similar situation and he really, really needed to do something that was not a web app. I think there was a series of talks that came out of it but that was primarily for the burnout case.

ROBERT: I think I can agree with that. I might have been in the similar situation where I was starting to think about the feeling cornered. It was maybe because of burnout.

CHARLES: Maybe those are one of the same.

ROBERT: Because I felt like I wasn't producing anything and I was like, "I should be doing this stuff but I feel like I should be but I'm not," and the things that I'm doing aren't great enough because the things that I have done in the past and that's a bad way to think about it.

JEFFREY: There's something so refreshing about being able to switch contexts of I've been working on this same app for a few months and doing kind of similar tasks over and over and that's such a nice way to create at really recharge like, "I'm just going to do something completely different and see how that feels."

ROBERT: Yeah, I've gotten really good at writing computer properties but I want to write something else.

JEFFREY: Just like anyone who does a lot of Ember, they're great at computer properties.

CHARLES: It really is the equivalent of throwing a dart into a map. If you're feeling burnt out and you're looking for what to do, There are so many things like you actually aren't cornered. You have the universe of possibilities and the dumber the better. Choose something random that you can do in five minutes, do something random that you can do in an hour or a week or something like that so it has that payoff for being an answer to burnout. I've experienced where these types of activities come back and pay you back down the road.

ROBERT: It doesn't have to solve a problem. I was always looking for the next project that I could build that would solve a problem. I always felt like I needed to solve a problem and I was just looking at it backwards. You should also be looking at things like it solve a problem. That’s cool. But why not take a piece of technology and like, "How can I bend this? What can I do?" And exercise the different corners of this framework or do just something that's totally useless.

CHARLES: I remember actually, that was something that Ryan, when he first started coming to the Ember meetups, he was asking questions about it and I think he was coming from Backbone and was --

ROBERT: Just Ryan from [inaudible]?

CHARLES: Yeah, [Ryan Ralph?] from [inaudible] and he was asking questions and like, "Yeah, it's pretty good. The only disadvantage right now is you can't have multiple apps inside of a single tab," so literally he comes back the next month with a talk of how I embedded more than one app in a tab and here's what I had to do it. First thing was like, "Let's see how does it break." Let me prod at it and poke it in and just see what happens.

I know I had an experience recently where I had done something really, really stupid with Amazon Lambda and I just very recently came back like the fact that I had actually gone through the process of just deploying a very dumb --

ROBERT: How dumb, Charles? Tell me how dumb?

CHARLES: Remember when I was going on and on about badges and how we needed to have our own custom badges. I kept on trying to get everybody excited --

JEFFREY: I don't know that we need that.

CHARLES: That was pretty much the response that I got from, I think in a poll of nine out of ten. It was 9.11 or something like that.

ROBERT: -- That was cool but --

CHARLES: It was cool but no one wanted to put it anywhere. The badge was just a static SPG that was served on top of the Amazon Lambda but as part of that, I had to go through all of the steps through actually getting it to deploy. While that thing was completely useless and it was thrown away, that knowledge ended up becoming useful almost a year later or maybe six months later, something like that. I feel like it was sunny so it had to have been at least six months ago and so --

ROBERT: You know, that it's always sunny here.

CHARLES: Uhh... Ish. I mean --

JEFFREY: It's not Philadelphia.

ROBERT: I was trying to work somewhere.

CHARLES: It was warm but it's a practice that often has long term payoffs. I guess that's just the learning aspect of it, the fact that you're going to learn something.

ROBERT: The thing I want to stress here is you don't have to go into it expecting that.

CHARLES: Yes, that actually is critical.

ROBERT: Yeah, that absolutely is critical because then if you expect that, then the problem with all the things for me started with setting expectations. It was always I had expectations. You take them and throw them out. Toss those things out the window.

CHARLES: Zero expectations.

JEFFREY: Really, it's an adjustment of your expectations to where at any point, you can say, "No, I'm kind of done with this. I learned something but it's not going to turn into anything," versus the expectation of, "I'm going to make something amazing that thousands of people are going to use."

ROBERT: Yeah, that's the way I always start out as like, "Here we go."

CHARLES: "I'm going to take over the world."

[Laughter]

ROBERT: "I'm writing another JavaScript frameworks. Next step, world domination."

CHARLES: Yeah, I know it's absolutely important to make sure that if this thing that you're doing just cease to exist, you wouldn't feel good or bad. It wouldn't make any difference. Very Zen, I think. Some people try to approach every aspect of their life that way. I'm not sure if that's healthy.

ROBERT: That's another podcast.

[Laughter]

CHARLES: But I certainly think it is, if you at least allocate a portion of your projects to be that way. I think that applies to any creative endeavor that you try to undertake. Jeffrey, you had some actually some non-programming examples that you were talking about earlier.

ROBERT: It ties in nicely to the Picasso thing.

JEFFREY: Yeah, actually I was I'm moving right now to a new apartment and I have no architectural background at all but I am comfortable with vector graphics in Illustrator and doing things mathematically precisely in there. I do have a little bit of problem solving that comes out of this. It’s not purely exploration but I've been like, "I'm moving to this new place. These are the pieces of furniture I have. How can I rearrange them and play and --"

ROBERT: Did you actually set the scale correctly to your --

JEFFREY: Oh, absolutely.

ROBERT: Oh, that's amazing.

[Laughter]

JEFFREY: --Otherwise it's worthless.

ROBERT: This is a whole new world. This is awesome.

CHARLES: -- Like there's an atomic gauge on the couch.

[Laughter]

JEFFREY: My couch is six feet, three inches and 24 angstroms. I have not reached that level --

[Laughter]

ROBERT: Does Illustrator have that level precision?

JEFFREY: It can go pretty far. But yeah, it's just an opportunity to play around and like in a situation where actually moving those pieces of furniture in 30 different ways would be a pain and just unrealistic but thinking about it more in the abstract and just being able to play with it at a scale that's playable with, turns it into something fun and creative.

CHARLES: Yeah, I guess that's a luxury that we have, I guess in the modern era of being able to simulate so much and be able to apply this practice of total creativity in a consequence free zone where people might not have been able to do so before. Before the advent of computer-aided design, I don't think that would've been a possibility.

ROBERT: There will be a lot of manual hand-drawing and sketches and stuff.

JEFFREY: And now software it's at point where --

CHARLES: Or you just get your children to do it.

[Laughter]

CHARLES: "Move it over there." You guys are sweating but man, I'm feeling really creative.

JEFFREY: Yeah, really making stuff happen here. But software has kind of reach the point where we have similar abstractions there to be able to do it, move pieces around like that. Maybe not as fluidly as I'm going to move all these squares around in Illustrator but we're at the point where we can kind of plug in pieces and see how it performs and plug in another piece and see how that performs in a way that feels maybe more creative and less scientific than getting lower down in the code.

ROBERT: Honestly, I wonder if this is where React began because the idea of rerendering the entire dom every time was more performant like you just throw something at the wall. See if it sticks. I don't know but --

CHARLES: Yeah, you have to wonder. I'm actually become surprised at the origin story is not more widely known.

ROBERT: Yeah, I also don't really know it. I kind of heard of it like --

CHARLES: I remember hearing about it the first time I was like, "That's crazy."

ROBERT: Yeah, that sounds like it'd be massive performance hit. That sounds really slow. Why would you rerender everything?

CHARLES: Right but then again, it's always getting into pre-[inaudible] optimization. We always fall down these paths of optimizing in our heads. Of course, we want to do incremental rendering. Why? Because it's faster but nobody's actually measured then realized that it's actually the dom that's slow.

ROBERT: It's like opening up your world to this. It's just like you explore everything.

JEFFREY: That's another thing we can take from design thinking and the philosophies around the design field that maybe aren't as recognized in engineering is the idea of simply brainstorming of being open to dozens of ideas, trying out dozens of ideas and seeing what feels right and being able to have so many ideas that you can throw most of them away. In software, so many times we get to the point where maybe we'll have two or three ideas but none of them are worth throwing away. We feel uncomfortable throwing out any work.

CHARLES: Part of it is you were so busy. You have so much invested in your current track that it's very easy because your current track is on Rails. It goes forward, there's clearly a path forward and to hop off of those Rails, it require some sort of energy and are you going to be leaping into like a chasm? I don't know.

ROBERT: Or in Jeffrey's case, if your computer dies and you're forced to think without a computer --

JEFFREY: That actually happened the other day.

CHARLES: That was amazing. That was worth a story.

JEFFREY: I forgot to bring my charger to the office so I have one of those new [inaudible] MacBook with the USB-C charger and we didn't have any backups in the office. I was hacking along on some configuration devops kind of stuff and just kept running experiments and eventually my battery died. Then I was forced to whiteboard out by what I was doing and I came way over to conclusion that I would have ever come to, if I had just been sitting on my computer the whole time. It was another case of where I needed that abstraction away from looking at the code to be able to rearrange the blocks in a way that made sense.

ROBERT: Pull yourself out of the [inaudible].

JEFFREY: Yeah, definitely.

CHARLES: I really like that idea. Again, I'm not being too familiar with the way that the design world works. Is that kind of like a modus operandis to have too many ideas that you can throw a bunch of them away at any given point?

ROBERT: Where you start stealing pieces from all of them and you make one master design. In my digital design class -- shout out to Miss McDaniel -- she would always make us start off --

JEFFREY: Check for that in the show notes.

[Laughter]

CHARLES: -- She would always make us start off in a sketch book and I remember because I'm not an artist at all. If you know me, I draw even the worst stick figures: my arms and stick figures don't line up. That's how bad it is. She would always make us start off in a sketch book and it drove me nuts. But after doing it for two months, I finally realized the value because she would make us come up with five or six different design concepts. Then after I did the process a couple more times, I realized, "This actually has a ton of value."

I sort of picking things from one of the other. It makes you think outside the box. The first couple of ones that I would turn into her she would be like, "You actually have three of almost the same design here. You need to think more outside the box. Think of something that's completely different." Seriously, it's just like you're throwing things at the wall. Whatever freestyle off top of the brain and just let it go.

JEFFREY: I'm thinking of a concept side of exercise where maybe you're playing around with layouts for selling a magazine or something and you'll sketch them out and you'll sketch out maybe a few dozen of them but you don't get into the nitty-gritty details. You do it at a very-low fidelity where it's just pencil and some boxes and rearranging those boxes and maybe mark what that box is but you don't worry about the details of that box until you mix and match like, "That layout is not going to be great. This layout seems like it might be along the right track. I like this piece of this one. Let's combine them and make something completely different." Then once you have that high-level view, that make sense to you and you've gone through lots and lots of iterations, then you can start honing in on the high-fidelity details.

CHARLES: This conversation makes me feel like there's definite poverty in our processes as software developers in the sense that what I'm hearing is that these things are just taken for granted, that these are the activities that you're going to be doing as part of design and what are we doing if not design. Each of us has these experiences that are kind of these one off things where we actually experience this creative space. It seemed very special and it seemed revelatory but really, it almost sounds like you need to make sure that it's something that you're revisiting again and again and you're doing it as integrated with your work. But I feel like it would be hard to pitch that --

JEFFREY: That's not understood to be part of the software design process.

CHARLES: Maybe that's a little bit of what happens when we've put together our design documents --

ROBERT: Yeah, it just occurred to me like looking back through my history of how I landed to be a software developer, I actually wanted to be a designer first. That's why I was in digital design and stuff. I rejected design so much because I thought it was super... What's the word I'm looking for? Flighty?

CHARLES: Wishy-washy? Non-committal?

[Laughter]

ROBERT: Anybody could walk in and say, "I don't like that design. It looks ugly. It doesn't look good," and I thought I was going to programming because it was more black and white like, "This is the right solution. That's not the right solution." As I've worked my way into my career, I actually realized they're actually really similar because you're designing software and software is abstract. As much as you want to try to think about as it's not, you start to develop this mental picture of the programs that you're developing. You're designing these things. It's just a different form of design and design is problem solving.

CHARLES: In digital design, it's not artwork. It is measured by some quality. It's just hard to put your finger on but there is some kind of external measure of, "Does this fit the purpose for me, which it was made?"

JEFFREY: "Does this solve the problem?" Usually, there are some expectations just like there are software of, "There's been best practices established. Did you stick to those best practices? And if you didn't, Why not?" Because sometimes there is a good reason to break those best practices.

CHARLES: Right. I wonder if it would be interesting at integrating into our process like what we think of as the ideal pull request or issue reporting or design document have. It kind of similar to some of the RFC processes out there. It's like, "What are some crazy alternatives?" Not just any alternative --

JEFFREY: I don't just need viable alternative.

CHARLES: Yeah, I don't need viable. Give me the in-viable. Give me the ones that are like, "What crack are you smoking? Oh, wait a second... Hmmm..."

[Laughter]

ROBERT: "All right. Here we go. I got it. It's got to be powered by nuclear --" No.

[Laughter]

CHARLES: Curious. I'm very, very, very curious.

ROBERT: Let the curiosity fly.

JEFFREY: Charles, do you had a blog post recently about a dumb project you built. Would you tell us about that?

CHARLES: Sometimes, it gets stressful around here. Sometimes it gets stressful in life. Sometimes you just feel stress and there are a lot of things you can do to deal with it. Everybody has their coping mechanisms. For me, one of my secret weapon coping mechanisms --

ROBERT: Not a secret anymore.

CHARLES: It's not secret anymore.

[Laughter]

CHARLES: This also will be in the show notes but I'll go ahead and say it right now is ChillestMonkey.com. If you need to enhance your chill, you can just go to ChillestMonkey.com and I guarantee you will not be disappointed. You will feel instantaneously better. I was in the point where I was feeling a lot of stress. I don't know exactly how it came up but I was actually with Stephanie and she was like, "Charles, you just got to do something stupid. You just got to do exactly what it is that we've been talking about on this podcast. You've got to just do it and you've got to do it fast and you've got to not look back and look forward."

I was like, "Oh, my God. You're right." That planted the seed in my brain but then, I think it was the next day, I was talking about ChillestMonkey.com -- go check it out. You can pause the podcast right now and go have a look at it. It’s really awesome -- And I was showing it to everybody and then I think Rob were like, "Oh, my goodness. We've got to have this on the Apple TV."

ROBERT: It just lands itself perfectly.

CHARLES: Yeah, I was like, "Yes. Absolutely we need it on the Apple TV. We need it on the Apple Watch. I need this on my iPhone," so right that minute, I hearken back to the conversation I had with Stephanie and I was like. "This is it. This is perfect scope." I have been looking to build something in React Native. Something that I can just completely and totally throw away, something that fits in a small time box and I also have this opportunity to build this thing that I really need but if it doesn't work out, it's fantastic.

I went home. I think that was that very night and started hacking on React Native and took the Chillest Monkey, then put it first into an npm package. You can include it in any React Native application. Then once that was accomplished, I went out and checked the support for Apple TV had dropped literally ten days before, maybe even less. I was like, "It's a sign and this has got to happen."

It was a little bit of a slog but we were able to get it up on our Apple TV and with a remote and feel that glassy touchpad, move it over to the Chillest Monkey and open it up and just see those wisps of hair and those tranquil eyes up there and six feet across. It was just such a great feeling. But it was something that was accomplishable within a day or two. I don't think it was more than that but it serve the purpose that I was able to learn a lot about React Native. I was able to learn about packaging, shared components.

ROBERT: Actually, I remember we fought about flex box and what not for a little while.

CHARLES: Yeah, that's right. I learned about laying out images and kind of the best practice around there. Also, I think this is important as I got to experience a win and it felt good to be able to experience that win. It felt like if I hadn't experienced it, it probably wouldn't have been that big of a deal. But the fact that I was able, it was a low-hanging target but it felt like a big-hanging target. It's hard because there's no such thing as a free lunch but kind of there is, when it comes to little projects like this because when you see something totally stupid come together and it works exactly you wanted it to work, then it feels like you've accomplished something major. I don't know if that's some sort of brain hackery or some sort of life hack or what but that was extremely good for my internal morale.

JEFFREY: This is an example of a project where, maybe you didn't get as much creative juices flowing out of it.

CHARLES: No.

JEFFREY: But you've got a high accomplishment and learning value, which I guess are all, I call that the iron triangle of building dumb stuff.

[Laughter]

JEFFREY: You can have two of the three.

CHARLES: On one side is creativity, on the other side is what?

JEFFREY: Accomplishment.

CHARLES: -- Is accomplishment, just shipping it and then on the third is time? It's the iron sticks --

[Laughter]

JEFFREY: The third side was learning. That's creativity, accomplishment and learning. You can't have all three, sorry. It doesn't work that way.

CHARLES: It doesn't work that way. Okay.

[Laughter]

ROBERT: Then you'll take on a big project, that's how you'll get all three.

CHARLES: I like that.

JEFFREY: In a particular project where you're having to throw tons of ideas at the wall, You're probably going to be learning, you're probably have to be very creative but your chance of shipping here is much lower.

CHARLES: It's almost a detriment.

ROBERT: Yeah.

CHARLES: Whereas in this case it was take something that is easily accomplishable and accomplished it.

JEFFREY: And you learned something from it.

CHARLES: You learn and you accomplish but you're not particularly creative. But it's still a feather in your cap. I like that. It's a good way to categorize it.

ROBERT: And the accomplishment is how you define it. In this case, you actually finished this project.

CHARLES: Yeah. I finished it. We have it on Apple TV.

ROBERT: Yeah, and like you said, you have to do that. For me, after I did a couple of these things, actually what I just do, a newsletter has come in and somebody was like, "Look at this new thing," and I'm just going to put it off to the side and then eventually, I'll stack two or three of those things together and decide, "We're going to take all three of these things, we're going to put them all together and see what happens," and that's how GraphQL and dove in to create React app.

CHARLES: That's actually a good idea. I like the random newsletter driven development --

[Laughter]

CHARLES: -- You're like, "I'm going to subscribe to this newsletter. I'm going to pick one thing from each week and after I have five things, I'm going to build something with those things.

ROBERT: Wait. I have a dumb app idea. We could make this just a random app idea generator. It takes ten packages and you see like --

JEFFREY: A bunch are required to build the Hackernews clone. Isn't that a classic newsletter driven development?

ROBERT: Or the Reddit clone? This feel like that's the React thing -- the Reddit clone.

CHARLES: Yeah. I think it's more like Frankenstein driven development like you've got GraphQL, Vue.js and I don't know... Datomic.

JEFFREY: Like a GRD stack --

CHARLES: No, like a rando stack.

[Laughter]

CHARLES: Rando.js, that would actually be a good --

ROBERT: You hear it first. It's our new JavaScript framework.

CHARLES: A stack generator.

JEFFREY: It's going to be a high on learning and not so much on accomplishment.

ROBERT: You won't ship anything but damn will you learn? Every week!

CHARLES: What is an example then? We've talked about the one where the accomplishment. I'm wondering if there's an affinity between those sides of the triangle. What would be an example of a project that was high on creativity, low on shipping? How do you approach projects like that and then make it okay to fail? Because I think, one of the things that was great about the Chillest Monkey Native was I did get to ship it. It wasn't much but it felt great. How do you prepare yourself for those projects which are high on creativity that you're not going to ship? What is one of those look like?

JEFFREY: I think those kinds of projects are usually tend to be ones where you're more comfortable with the tools already so that you do have the space to be creative and you're not having to fight against, "I don't know how to do this." The learning is already been done, at least to a point to where you're comfortable enough to go, to feel loose and creative and be able to brainstorm without having to bump up against walls over and over.

CHARLES: I guess, tender love is a master of that, where it's really has a deep knowledge of Ruby and systems programming and does some fun and creative. Do I say zany?

ROBERT: The Ember example of this, I think it's Alex Matchneer. Matchneer?

CHARLES: Matchneer, yeah.

ROBERT: Sorry, I cannot pronounce names. The Photoshops, I mean those aren't exactly --

[Laughter]

ROBERT: -- Those aren't exactly programming related but --

JEFFREY: High on creativity and accomplishment, low on learning.

[Laughter]

ROBERT: And then the Ember Twiddle is the one that I laughed out and I was like, "Can React router do this?"

CHARLES: I don't actually see that one.

ROBERT: Actually, it was broken when I went to look at it but the responses were hilarious. They're like, "Actually, no. I'm happy. I can't."

[Laughter]

ROBERT: But he always has the Twiddle and he's like, "What about this? It’s like the programming equivalent of his Photoshops.

[Laughter]

JEFFREY: I'm wondering if there are particular, out of those kind of three different types of dumb projects that we've identified. If there are particular types that people gravitate toward like I know that I am higher on the, "Just go, do something creative with tools you already know side," versus, "I enjoy learning," but I'm more likely to want to accomplishment up things and be loosen in my creativity. I'm wondering what the breakdown is among different engineers of those different profiles.

ROBERT: It's quite interesting and I wouldn't think of myself as an explorer but I feel like I'm driven by FOMO -- fear of missing out. That's where this comes from for me. All this technology that I hear so many good things about that I haven't even done anything with. I don't even have Hello, World or anything. That's usually where I start picking things up the shelf and I'm like, "What if I did redux, Vue.js and whatever else. Let’s see if we can make all these things work together."

CHARLES: Do you feel like you can, at least always be kind of touching?

ROBERT: Yeah.

CHARLES: Pinging different areas of the ecosystem?

ROBERT: Yeah, I really like to see what they're doing because they all have different takes on things. I really like what Chris Freeman said, he's like, "I feel like programming is just gaining experience points." Like it's video games where you're just going through and you're getting experience points with different things. That's kind of the approach that I've been taken for the past five months. Since I discovered this, this is just like, "Oh, that look shiny." Maybe that's also driven because of our JavaScript-type cycle or whatever you want to call it, where something new is always coming out. Somebody is always reinventing the wheel.

CHARLES: Whenever I see a cool demo or whenever I read a really provocative blog post that guides my exploration a lot, which I guess those things usually are extensions of some activity like what we're talking about that someone did. A lot of really good blog posts are just like, "I've been doing this stuff for five years and I have gained an absurd level of expertise on it. Let me take you to school."

I definitely love those but a lot of it is like, "Look at this cool thing that I've done." Without talking about murdering names, what is it? Hakim...? Gosh, I can't remember his last name. The guy who does Slides. Some of his demos for CSS and JavaScript animations back in the day we're just like, "Woah, someone has just revealed a huge power source," and so I want to go do it. But most of that came from him just having to play.

ROBERT: Jeffrey, you've actually got my brain ticking here. I'm thinking about where people fall in applying this like just go do something dumb and it doesn't have to mean anything. This makes me starting to think, "Maybe I need to go do something really creative in Ember."

JEFFREY: It's making me think that I need to go do some learning --

[Laughter]

JEFFREY: -- Just try some new stuff so I have new tools to play with.

ROBERT: Because that's the whole purpose of this, right? I just recognized that I am not doing very creative things and the tool sets that I am comfortable with.

CHARLES: Yeah, it is harmonious. The more learning projects you do, you acquire tools and then with familiarity with those tools, engenders creativity so you can see how the process feeds in to itself.

ROBERT: Now, I'm going to build something creative.

CHARLES: All right everybody. There you have it. Go out, build something useless, build something creative, build something that will help you learn and acquire new tools, new techniques and take you [inaudible] and do it quickly.

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32

Show Notes:

Resources:

Transcript:

STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols.

CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol?

CAROL: I'm great. Thank you for having me on the show.

CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust?

CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out.

We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We’ve got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services.

One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We’ve done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We’ve also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like.

One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We’ve had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community.

CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help?

CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library.

CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping?

CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We’re not going to come in and rewrite the whole project. We’re going to come in and work with their style and make any modifications they want to be able to incorporate into their library. But as I said, a lot of libraries are gotten to a certain point and I think the maintainers would like their libraries to become more feature complete but everyone only has so much time and you don't necessarily know what's useful to people but this is a very, very strong signal that this library would be useful to someone if only it had this little extra thing. I think most maintainers are open to making their libraries more feature complete to be more useful to more people.

CHRIS: Yeah, that is a pretty sweet deal from the standpoint of an open source maintainer. It’s nice enough when people show up to help at all. It is especially nice to show up to help and aren't motivated by money.

CAROL: Yeah.

CHRIS: That's very cool. When it comes to prototyping things with Integer 32, what kind of projects are people coming to you and asking you to prototype in Rust?

CAROL: A lot of them are existing projects that they have and written in something else that they want to either perform better and be safer as opposed to rewriting it in C or C++ to get performance out of it. Sometimes, they want something to interface with other Rust things. We’re starting to see projects like that but mostly, they have a hunch that Rust will be good for their projects and solve some problem they're having with their current implementation. We scope their projects way down to whatever will let them evaluate, whether Rust is a good fit or not and we go with that.

CHRIS: Cool.

STEPHANIE: Going from there, the question that I have is why Rust? I don't know a lot about Rust so I'd like to know what would be some of the benefits of using Rust, if you're familiar with programming. If you are in web development like I'm familiar with Ember, why would I like to use Rust or learn Rust?

CAROL: I could talk all day about this. I really love working with Rust. I feel like it is adding more tools to help me to write better code and taking care of little details that usually I would have to spend a lot of brainpower thinking about to get right all the time. But now I can actually concentrate on whatever it is I'm trying to get done and let the compiler take care of those details for me. The way it's implemented, it happens really fast.

The way I got into Rust was I'm a Rails developer previously to this job and I spend a lot of time optimizing Rails, looking for places where essentially too many Ruby objects and memory leaks and [inaudible] a lot of trying to make Rails go faster. At some point, you can't. There’s only so far you can take Ruby and Rails so I look at where I want my career to go next and I love making things go faster but I'm terrified of C. I should be nowhere near production C.

You have to spend years learning all the quirks and all the ways that C can go wrong and crash and be insecure. Around this time, I know you had Steve Klabnik on the show, in the previous episode. Steve is from Pittsburgh, where I am and he came home for Christmas one year and came to a Ruby meet up and was talking about this new language called Rust and how awesome it was. Steve gets distracted by new awesome things all the time so I was like, "Yeah, yeah, okay, whatever."

The next year, he came home for Christmas again and was still talking about how awesome Rust was. At that point, I was like, "There's got to be something to this." At that point, he was writing his book, 'Rust for Rubyist' which has lead into his work on the Rust programming language book. I was like, "Rust for Rubyist? I can handle this. This is something I can do and capable of," so I started reading his book and submitting corrections and things which is again, how I got involved with the Rust programming language book.

If you've ever gotten the error 'undefined method on nil' or 'undefined is not a function' in JavaScripts, like in production at runtime that happens all the time. That's just normal in Ruby and JavaScript land. Rust prevents those problems at compile time so there's no null, there's no nil. It's strongly typed so it checks that you have the thing you think you have before your code even can run. There's no garbage collector so you don't have memory leaks. The system of ownership and borrowing and the borrow checker and lifetimes which is weird. It’s tricky to get your head around at first because it's different than any other language.

But once you get that that's the part that enables your code to go faster without needing the garbage collector. You actually don't have to think about your memory management as much as you would in C, where you have to say, "Please give me some memory." Okay, I'm done with it now. You are manually managing your memory but you don't have to think about it as much because the compiler is thinking about it for you, if that makes sense.

CHRIS: I have a follow up question, kind of related to the fact that Rust is kind of performing at the level of C or C++ but a lot more friendly in the fact that both you and Steve and I think a lot of other people, have come to Rust from scripting languages, from higher level languages. I remember at first that I started paying attention on Rust like right before the 1.0 happened, I thought it sounded interesting and wrote it off because it was just insane and I had only ever done Python and JavaScript and higher level things.

In a relatively short time, it has developed a level of ergonomics that I'm envious of, even in the 'more comfortable' languages, things like Cargo, things like the compiler is really great but now the compiler has really friendly and informative error messages so that 'undefined is not a function' never happens but when you try to make it happen, it now shows you like, "No, no, no. On this exact line, in this place, this is where you're doing it wrong."

But I recently heard it and I'm curious if you know anything about it that there's also development on a Rust language service, kind of like I guess TypeScript test, where it's a whole set of tools that you can run under the hood that any editor can plug into so that you just get this tool box of things to help you develop in Rust that are all packaged up and handed over and all you have to do is hook into it. Have you try that at all? Are you familiar with that?

CAROL: I am not. I've been watching but I haven't worked on it and I haven't tried it out yet. I am excited for the language server because it's going to enable IDEs to do more interesting things. Coming from Ruby where it's so dynamic that you can't do things like ensure that you renamed all of the places and method it's called because you can't know that. I've read books like Michel Feathers' Working Effectively with Legacy Code and a lot of the chapters in that talked about leaning on your IDE, on your refactoring tools to do automated refactoring.

RubyMine has a few of those things but not all of them because it's just impossible so I'm really looking forward to having real refactoring tools that can let you do automated refactorings and things like that that are possible in other statically-typed languages but with Rust in an IDE. I haven't used an IDE in years because I haven't found them to be useful but once the language server is up and running, I'm thinking about going back to an IDE so it's definitely exciting.

CHRIS: That's some pretty cool right now. There's one called Clippy which I love because of the name like it takes you back to my Microsoft Word days. There’s a lot of very good stuff that they have added that I didn't expect from a 'systems language' but it has definitely benefited from a lot of things that people in the scripting world have learned.

CAROL: One of the goals of 2017 for the core team is increasing people's productivity in Rust so getting people over the learning curve, providing them with tools like the language server and making it easier for people to build things in Rust without having to manage things around Rust. Just Cargo in itself has made systems programming so much better. I see people who develop in C and C++ who really try to minimize the amount of libraries they bring in because that makes your build system so much more complicated and you have to have libraries in the right place and so much more can go wrong. But with Cargo, it's just Cargo install and you have a Cargo.lock and cargo.toml that manages versions. It just work so it's been interesting watching people figure that out and change their opinions on bringing in dependencies with npm and JavaScript and Bower and Ruby Gems that we're all used to like, "Oh, there's a gem for that. Let’s just pull that in and go." Systems people have been really reluctant to do that but Cargo is enabling that to be better and easier which is really exciting to watch.

I want anyone listening to this who thinks, "I can't do system programming. It was too hard." No, you totally can. You can do Rust. Rust is going to let you do this and that's why Rust is really exciting because it's enabling a whole new group of people to get into the systems programming space where things need to be optimized and faster and letting people build these sorts of things without having the programs be vulnerable to crashes and security bugs and things like that. It’s really, really exciting.

CHRIS: Very cool.

STEPHANIE: I'm curious in Rust, if there's an error, how would you know that there's an error? Is the whole thing going to stop? Is it going to break? Do you get a useful stack trace? What would I expect to see?

CAROL: A lot of the errors in Rust are at compile time. It won't even let you try to run your code if you have certain kinds of problems and they tried to move as much as possible into that compile time space. There are always going to be things that you can't catch a compile time like the user enters a number that's too big for whatever you're trying to do. That’s still going to be a runtime error because we can't possibly know what a user is going to put in when you're compiling. They've done a lot of work on the compiler errors as Chris was talking about, to make them friendlier and point here's where your error is, here's why it's happening, here's a hint as to how you might want to fix it. This has been really great.

I was volunteering in a local code school with students just starting Ruby and I'm used to Ruby's error messages by now but they were just getting started and getting all sorts of errors and I was like, "Wow, these error messages are not helpful at all," and I forgot how bad that is and how confusing it can be for a beginner to just think you understand, think you have got it working and then you go and run the code and it's just like 'string is not a symbol' or whatever. The worst is when you forget to close the block and just expected to see [inaudible] end of file instead and it's not helpful at all. I was just like apologizing the whole time like, "I'm sorry. This is telling you that you need to write 'end' at the end of the file," but it's not telling you that in any way you could possibly know that. That made me appreciate much more all of the work that's going into Rust error messages that are really trying to help.

Some people talk about, especially the borrow checker, fighting the borrow checker like they're not used to having a compiler tell them their code is wrong so often so people talk about fighting the borrow checker a lot but it's not trying to fight with you. It's not trying to make you feel bad about your code. It’s trying to help you make your code better and prevent errors that might happen at runtime by catching them earlier. I actually have a little project called Rustlings that is full of little snippets of Rust that intentionally don't compile. You run them and you get an error message right away and your job is to read the error message and learn how to fix it.

When I was starting out, I was really frustrated because I was trying to do something and I would get an error message and I would have to stop whatever is doing to deal with the error message. I was like, "If I could just get some practice just dealing with the error messages and learning how to fix them so that when I'm trying to do something else, I already have experience fixing that kind of error," so that's how that project came to be and people found that useful. I haven't had much time to work on it lately but it could definitely use more examples because I think people are used to error messages that are not helping. People used to back traces that are really long and don't say anything useful.

Sometimes, you don't stop and read and think but the Rust error messages are really trying to help you and often times, they are telling you exactly what you need to do to change the code to work. I think getting practice seeing the compiler as more of a pair who is trying to help you and not someone who's trying to reject all your code is a different mindset that I don't think people are used to but I think it's really useful.

STEPHANIE: That's excellent. I was going to ask you if there are any resources or any repos to check out for someone who is interested in getting into Rust. It's funny, last night I was poking around with Python and there's something similar to Rustlings. It's called Python Koans and it's basically like what you're already familiar if you do web development. You want to get your test to pass so it'll tell you, you need to think about this one or you need to meditate on this and then you try to get it to pass and then it says you have reached enlightenment or you have not yet reached enlightenment and you have to sit there and think about it and then run it again. It’s very useful in trying to get started with language in a way that you are already sort of familiar with.

CAROL: Yeah, I've definitely gotten inspiration from the Koans project that have existed in other languages. There's also an exercism track for Rust that people found really useful and of course, I'm working with Steve Klabnik on the Rust programming language book. We're rewriting the whole thing so there's an existing version that if you go to the Rust documentation and click on book, you'll get the existing version which is complete but the new version is going to be way better. Especially with the explanations of ownership and borrowing, people have said that the new version is way, way better than the old version.

Someone even made the analogy of doing medical research and you see that trial case is doing so much better than the placebo case that is not ethical to continue the trial. It's more ethical to stop the trial and use the new thing because it's helping so many people. Someone was like, "You need to replace the old book with the new book right now because it's so much better," but the new book isn't complete yet.

The new book is in a different repo which we can put in the show notes so I'd recommend starting with the new book and then working back and forth with the old book once you run out of content. But we're getting closer all the time so hopefully, that should be done and printed by No Starch sometime in 2017 --

CHRIS: Woah! It's being printed by No Starch?

CAROL: Yeah.

CHRIS: That's cool. I didn't know that. Congratulations.

CAROL: I thought Steve mentioned that in the last one.

CHRIS: He may have but he talked about it a long time ago and I thought he always meant the old one. How long have you been rewriting the Rust book for?

CAROL: It's been a while.

CHRIS: Longer than I knew about then, probably.

CAROL: It's kind of like software. It’s more work than you think it's going to be and estimating, it's going to be done when it's done. If you kept telling people, "It's going to be out on this time," and like Steve, "There's no way it's not getting done by then," so now he's not allowed to say it when it's going to be out.

CHRIS: Nice.

CAROL: I'm really grateful to see this opportunity because I don't think I would have written a book on my own and I'm learning a whole lot about the process of writing a book. It turns out there's a lot of editing, a lot of back and forth, a lot of trying to build a narrative through this long stretch of text so that you're building on top of what you've already covered and not introducing things that aren't mentioned. It's a lot of work and I'm learning a lot and I have no idea when it's going to be [inaudible] because I think there's more work that I still don't know about coming, as we get closer to going to print. It’s definitely one of those things that you can't make agile because you've got to put it on paper that costs money and it's going to be around a long time at some point. It’s definitely a different kind of working that I'm used to with software.

CHRIS: Although, I have to say, I clicked around and I think this is the new version: Rustlings.Github.io/Book. Is that the new one?

CAROL: Yes, that's the new version.

CHRIS: There is a lot here and it's not quite what I would have expected to see here like it's not done yet. I've been clicking links and I have yet to find one that says 'to-do'.

CAROL: I think 15 through 20 are like outlines right now. We’re maybe three-quarters through with the content but then we have to go through revisions and editing and copyediting.

CHRIS: I'm looking at the headings and I was a big fan of the first Rust book but I can already see it calling out things I wish had been hit on more specifically in the original book. There’s a lot of good looking stuff here so I'm excited about this. I'm going to go and read this thing.

CAROL: I'm excited for people to read it.

CHRIS: Earlier, you were talking about one of the things that is really nice about the Rust tooling is that Cargo makes it really easy to bring in dependencies. I happen to know that you are recently, I believe the maintainer of Crates.io which is where all of Cargoes crates, which are the libraries are hosted. Is that correct?

CAROL: That is correct. I have commitment Crates.io now which is very exciting. Crates.io is like Ruby Gems or npm. It’s the site where people publish their libraries and you can go and search for a library for what you need. As part of the Rust 2017 goals, we want to make it easier for people to find high-quality libraries that do the things they needed to do. I've been doing some work on adding badges and categories. Rust makes major decisions on the language and on things through an RFC process, which I think Ember is doing now too. I forget which way we stole that. Do we steal it from Ember or did you steal from us? I can't remember.

CHRIS: If I remember right, I think -- I could be wrong, Twitter -- Ember did it first. Rust borrowed it and then added the 'how do we teach this?' section. I think Ember took that back and added it to their RFCs.

CAROL: Okay, I'm super excited about that section. Now, when you propose a change of language, you have to go through this RFC process where you write up what you want to change, why you want to change it, any downsides, any alternative designs. Then the community talks about it and makes comments when you revise it and things like that. Now, there's a new section that just got added. That's 'how do we teach this?' Before something can be stabilized in the language, you have to document it. This is still kind of starting to take effect but I'm super excited about it because people can't use something unless they know how to use it.

Right now, Steve's the only person getting paid full time to work on the documentation and I need him to write the book so I'm excited that more people will be thinking about documentation and thinking about how to help people use their new features. Anyway, I have an RFC about how to rank Crates within a category that we're trying to work through. In some automated ways, we can recommend different Crates for different purposes. I'm working through that with the community to try and figure out how to best recommend Crates in different circumstances.

Crates.io is written in Rust and it performs really well. It just got added to the Heroku things so you can deploy it too. Looking at the analytics and their response times for is just like the Ruby apps I work on would be thrilled to have these stats. The backend of it is Rust, the frontend is Ember and [inaudible] who was an Ember person is also interested in Rust and he thinks Rust on the backend and Ember on the frontend worked really well together. He’s always trying to figure out ways that we can work together.

Crates.io is an existing project that I'm still learning Ember. There’s lots of words I don't really understand about like components and Bowers. I would love Ember help on Crates.io. I'm starting to pull out issues that would be good at first time issues or more Ember-focus or I have some idea of how to fix that I could help someone fix. I'm starting to tag those things with 'has mentor' in our labels so I love for people to come check out issues on Crates.io who know JavaScript and know Ember and might want to get into Rust because there are definitely some issues that need a little bit of frontend, a little bit of backend so it might be a good way for people to get into Rust.

CHRIS: Very cool. I'm personally very interested in that and will likely hit you up. But I'm sure many of our listeners will as well because I think we have a lot of Ember-friendly listeners so look Carol up because it sounds like she could use some help. Actually, I'm curious, the backend, I know that pretty recently, Rust has kind of gone through this period of kind of explosion in terms of Rust as a web language. There have been a number of different things that have come out pretty recently for a web framework in Rust or there's that Tokio thing. I know Diesel is like the ORM for Rust in talking to databases. It looks like it's about to hit 1.0. There's a lot of stuff happening so I'm curious, what are you using to write the backend. I know you're using Rust but are you using one of these frameworks or have you rolled your own? How's that work right now?

CAROL: Crates.io is one of the first web apps that has been written in Rust. Actually, if you look at the backend code, you'll see SQL being built by hand. It’s going to the Rust postgres library so it has SQL injection protection. All the things are [inaudible] so don't worry about that but they're still like SQL with the Rust code so it's not using an ORM yet. I'm going to have to look up. There is a library that is using that I'm blanking on the name of it for but it's very low level. It just let you send HTTP requests and let you respond to HTTP.

We’re in kind of a Cambrian explosion period with Rust web frameworks. There’s a lot of different ones. One that I'm excited about that I haven't gotten to tryout yet is Rocket. That was just released. The thing I love about Rocket is that everyone's really excited about it because it was announced and they have an awesome website with lots of awesome docs so that should be a lesson to any open source project that's launching is if you want to get excited about it, you've got to launch some docs. That will help so much.

There's a lot of different frameworks happening. They’re still little trilobites and little animals that can't walk on land on their own quite yet so there's still no Rails. There's the pieces of Rails. There’s Diesel which would act like a record. There's Nickel and Pencil and Iron and Rocket. Tokio is the async framework that is getting more and more stable by the day. We got to try it out on a project recently and it's pretty fun. I still am working on wrapping my head around promises and futures and working in that way but I think as that stabilizes and people use that, that is going to cause like another explosion of libraries that enable really fast but safe web backend stuff, which I think is really exciting.

If you're looking for the Rails experience of being able to plug things together and nicely, just declare a few things, it works but not quite there yet. But if it excites you to try out new things and figure out the best ways to do the things you want to do in Rust, this is a great time to jump in and help.

CHRIS: I will say the Rocket website is beautiful and it even has this templating section, a testing library section. This is very exciting. It really looks like as the closest thing to a Rail-style web framework that I've seen in Rust so far. People should definitely check this stuff out. I'm curious, I know a lot is really interested in Rust and Ember, which doesn't surprise me because lots is really interested in Ember in general, which I think is awesome. But is there anything specific about working with the Rust and Ember together that seems, especially well suited or even like some gotchas that you guys have run into?

One of the things I'm thinking of is like Ember is really big into JSON API spec and I don't know if Rust has a JSON API library for serializing things in that format. Is that something you guys have to tackle at all?

CAROL: There might be. I'm not sure. Crates.io is using the Rust API adapter for Ember so we might not be keeping up with the latest of Ember. But I know there are people who want them to interface them better with each other. Actually, that's an interesting thing. Both Ember and Rust are on a six-week release trains sort of things so the way Rust people will say -- I don't know if Ember people do -- is stability without stagnation so they're both changing.

Rust has backwards-compatibility guarantees so the code you wrote with Rust 1.0 is still going to compile today. You might have some warnings and there's probably new cooler stuff that you could switch to but it's still going to compile. I'm not sure about Ember's upgrade path things. Someone just sent in a pull request that we merged like three days ago to upgrade us from two Ember point versions. There were a couple of things that like [inaudible] and we weren't doing quite right and we had to fix. It’s been interesting to kind of fit together, keep both of the sides, update it and upgrade it and continuing on using the best things. But I think they have similar philosophies around making things better all the time.

CHRIS: Yeah, the whole stable upgrade path and backwards-compatibility guarantees is definitely mirrored on the Ember side of things. I can see that being a little kind of comforting place to be knowing that both your frontend and your backend are not going to suddenly just break on you one day because some new feature came out that breaks your router or something. That’s very cool.

One of the thing that I know you're involved in -- you're involved in a lot of things -- when it comes to Rust, it's very cool. But you also run or a co-run a conference, right? Rust Belt Rust?

CAROL: Yeah, we had our first year in 2016 in Pittsburgh. I ran Steel City Ruby before then so I love running conferences and I love having them near me one, because it's convenient and I get to trick all of my friends into coming to visit me. But two, because there's a lot of tech stuff happening in the Rust Belt and places that aren't San Francisco or New York. People don't necessarily know about that and people who live here don't necessarily have the opportunities to travel as easy to conferences. I sort of start Rust Belt Rust, one because of the pun opportunity and one of our speakers drew a little bar graph. There were three conferences last year. There was Rust Fest in Europe which has [inaudible] amount of Rust. There’s RustConf, the official Rust Conference in Portland that has a lot amount of Rust and then Rust Belt Rust has double the amount of Rust in its name so we're the Rust-serious Rust conference.

We're going to do it again, in 2017 we're going to move it to a different Rust Belt city. I'm not going to say which one yet but we're closing in on a date and a venue in the Rust Belt city so watch out for an announcement on that. It was a lot of fun. We had a day of workshops and then a day of single-track talks and a lot of time for conversation. A bunch of the core team members came out and it was fun talking with a friend of mine who was trying out something with Tokio. This was in October so Tokio was still working towards their first big release and he was trying to do something with Tokio. I looked over and I saw Carl Lerche, Alex Crichton and Aaron Turon standing together and talking like 30 feet from us and I was like, "If only the three people working on Tokio were nearby to answer your question --" so he just walked over and talked about Tokio with them.

I love getting people together to talk to other people working with things, talk to the people who are working on the things they're using and meeting the people behind the names on the internet so I love running conferences and having events like that.

STEPHANIE: Carol, you have a Rust consultancy called Integer 32. How is that going?

CAROL: It's going pretty well. We’re learning a lot. One of the reasons I wanted to start it is because I felt like I wasn't learning more in my job. In my Rails job, I felt like I had kind of tapped out with that knowledge. In starting a business, I get to learn a lot of stuff like sales and marketing and taxes and invoices. Sometimes, I even get to program a little. We're still learning how to effectively find our target customers. We do have availability, if anyone listening is interested in hiring some Rust experts.

Right now, I'm trying to figure out when can we bring more people on the team. I'm trying to decide if we can have an intern for the summer. It should be fun so yeah, it's going pretty well. It's been a slow build but we're lucky enough to have savings and be able to spend some time building our business but it's been really gratifying to feel like I'm in charge of my destiny somewhat, as opposed to the whims of a company.

STEPHANIE: And if I were interested in some Rust consulting, what would be the best way to reach you?

CAROL: We have a website at Integer32.com and a contact form on there.

STEPHANIE: Thank you so much for speaking with us, Carol. It was a pleasure. I feel like I learned a lot about Rust.

CAROL: Thank you for having me.

STEPHANIE: All right, y'all. That’s it from us. Thank you so much for tuning in. Until next time. Bye-bye.

Liz Baillie @_lbaillie | GitHub | Blog | Tilde Inc.

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 57. My name is Charles Lowell. I am a developer here at The Frontside and with me is Stephanie Riera, also a developer at The Frontside. Today, we have with us Liz Baillie, who is a developer at Tilde.

I am actually really excited to have Liz on the show. I saw her at Wicked Good Ember back in June of 2016 and her talk was definitely one of the more memorable ones. You come away from a conference kind of only remembering a certain number of talks that stick in your mind and as time passes, the messages may fade but some of the message just stick with you and the one I got from her talk was a feeling of empowerment that, even though I have a lot of experience, I could approach any code base and try and grapple with it and understand it. I came away thinking, "There are a lot of code bases out there that I don't understand but if I apply a certain set of techniques and a certain level of fearlessness, I will actually get there."

You know, if I want to go attack something like I don't know like Kafka or something like that, I would feel better about that. That was actually a great feeling coming away from that, a feeling of great power so thank you very much for that, Liz.

LIZ: Yeah, no problem.

CHARLES: Why don't we start with a conversation of how you came to be a developer? Everybody’s got kind of a unique path. What's yours?

LIZ: Well, I went to art school and I studied comic books. I actually have a bachelor's degree in comic books. I was a cartoonist for a number of years and at some point, maybe like 10 years ago, I had a friend who was a programmer. He’s a web developer. But I didn't even what's a web developer was. But I knew he worked at home and he made his own hours and he made a lot of money. It seemed like an awesome job so I was like, "How did you get into that?" And he's like, "I don't know. I just kind of mess around and figured it out." And I was like, "Uh... I don't know what that means." Like how do you start? I have no idea. I went to the bookstore and I look at the For Dummies books and I got Programming for Dummies or something and it was like Visual Basic, I think.

CHARLES: All right. What year was this?

LIZ: That's 2004. I guess, it was a little more than 10 years ago. But it didn't say that on the cover. It was like 'Programming' and I was like, "Oh, cool. I'll learn programming." I don't even know what the difference of languages was or anything like that. I did a couple of exercises in that book and I had no concept of how this would become a website ever. I was making 'Hello, World' and little things that spit out Fibonacci numbers or whatever.

I kind of gave up on that and I was like, "I don't care. I don't mind being poor." I'm used to it so I kept being a cartoonist, putting out books and stuff. I did a little PHP and HTML type of stuff in making websites for myself in between but I don't really consider that programming. It didn't feel like programming.

CHARLES: Did you ever put any of your cartoons on the web?

LIZ: Oh, yeah. Google me. They're there.

[Laughter]

LIZ: I might have some stuff like my web comic, I'm not sure if it's still up. But I had a web comic called Freewheel, which was about this girl who runs away from home and joins a band of magical hobos.

CHARLES: That sounds like a career change to programming. It was oddly prophetic.

LIZ: Yeah. It’s out there. Anyway, I got to a point where, long story short, I was tired of being broken for all the time and I have to figure out some way to make money that I like doing so I thought, "I would go back to school," so I went back to school. I didn't start out with computer science but I took some math and science classes and I got really into math a lot. I really enjoyed math so I started looking into what careers can I do that are math-y.

Somebody said, "If you enjoy the problem solving aspects of math, you'll love computer science," so I took a Computer Science 101 class or something like that and I got really, really into it like I just killed it. I just loved it. It was awesome. But I still didn't understand how you made that a website. In the back of my mind, I was like, "We did this thing --" We learned Python in my class so there's some program we had that like move a little turtle around and do pictures or something. I was like, "I don't understand how this makes a website."

CHARLES: You got to move that turtle around a lot, especially like account for the kerning in the fonts and stuff.

LIZ: Yeah. I have no idea how you make that a job, like the stuff that we were doing like spitting out Fibonacci numbers and making a little adventure game or something but how does that translate into anything else. That was in 2014 and that was around the time that web development bootcamps were starting to be more of a thing. I heard about a school called the Flatiron School in New York which is right at the time and I thought, "This sounds great. In three months, they'll actually teach me how this makes a website and finally know how does this make a website?"

I applied in kind of like on a lark. I don't think I'll get in, I didn't know how can I afford it or anything and I applied and I got in. I was really lucky that my stepdad help me pay for it so I don't have to worry about it. I did that in three months and then I got a job. In November 2014, my first web job and now I know how those codes make a website so here I am today.

CHARLES: What a journey.

LIZ: Now, I live in Portland, Oregon and I make websites. Not really, I work on web apps, I guess is more accurate.

CHARLES: So you actually went straight from the Flatiron School to working at Tilde?

LIZ: No. I was in New York at the time and my first job was at an ad tech company called SimpleReach and I worked there for a little over a year before I got the job at Tilde, then I move to Portland. A year ago yesterday was my first day at Tilde.

CHARLES: Fantastic. Knowing that company and knowing what they do, they must have you doing some really, really fascinating stuff.

LIZ: Yeah, I do a lot of typical web stuff. I work on the Ember side of our app, Skylight. I also, more recently have been working on Rails engine that's also a gem that spits out documentation automatically, which is pretty cool.

CHARLES: Now, is this documentation for the product or is it just documentation for any real site?

LIZ: No, it's for our products specifically but I don't think it would be very difficult to alter for someone's personal needs, other than ours. But it's basically like if someone can write a markdown document, then we'll parse it and spit it out into HTML and all these different places so that it just updates the whole documentation site around our products.

CHARLES: Basically, there's an infinite amount of stuff that has to happen to make a website because there are literally so many moving parts. What's been your favorite kind of area, I'll just say the whole website building because that really is like the tip of the iceberg. The actual iceberg goes way, way, way beneath the surface. But what's your favorite location on the iceberg so far?

LIZ: I kind of like the middle, I guess. I always feel bad saying it because everybody talks badly about CSS but I just don't like it. I tried it really hard. One of my resolution this year was I'm going to try really hard and I'm going to like it more. But what I like the most is whenever I get to do pure Ruby. I learned Rust in the last year or two and anytime I get to make the stuff behind the visual aspect work or kind of like meta stuff. I'm saying this and it's totally wrong but I did my first meta programming the other day or last month. The metaprogramming that I did ended up getting cut out of [inaudible] but I got to do it before it got deleted. It was pretty cool.

CHARLES: That's generally how it works. Metaprogramming is the program we do that we end up hating ourselves later for but it's really fun.

LIZ: Yeah, they're like, "This is cool but this is not the most efficient to do this." It's like, "I guess, we don't have to dynamically create methods based on all our filenames.

CHARLES: As far as the CSS goes, I actually see CSS like raw kale. It's actually really good for you, if you like to it eat in large quantities and it's like fantastic but it's not always the most pleasant going down.

LIZ: It tastes bad. It has a terrible feel. It's like eating rubber. I am really lucky, though that I worked with a couple of people who are incredible at CSS and when I get to pair with them, it's like watching magic happen.

CHARLES: Yeah, you realized, for all its quirks and strange ways that you approach it, is an outlier but it is kind of a fully-formed programming model that has a lot of depth and a lot of people have really, really generated some pretty neat abstractions and ways of dealing with CSS. But it is like, "I just want to fix this one thing," and it's basically a sea of things that I have no idea how to navigate.

LIZ: It's one of those things. I always think it's funny, anyway that I come from a visual art background but the thing I like about programming is anything visual.

CHARLES: That is actually really is fascinating.

LIZ: Yeah, when they hired me here they're like, "You're going to be really good at design," and I'm like, "I just want to do programming."

CHARLES: Like never the temptation, like this is just because you've actually kind of drank your fill of that in a past life?

LIZ: I think I've talked to my coworker, Kristen about this because she actually has a design background and we paired together all the time. She’s one of the people that I was talking about who are geniuses at CSS. She’s a genius at it. She has a design background. We’ve talked about this how art and design are kind of different, like the brain stuff that I use to make a comic is really different from designing a book cover or designing an experience. It's all part of the art side of the brain but it's different compartments of the art side of the brain. I don't really have a design background as much as I have like a narrative and a drawing background.

STEPHANIE: That and your interest for math that probably has a factor.

LIZ: Yeah.

STEPHANIE: Going back to your journey, I wanted to ask about it seems like it took you awhile to knock on different doors and finally feel like, "Now, I understand. How do I work with what I have to create a website?" We have similar backgrounds in that. We didn't start off in programming and I also went through a code boot camp. But mine was a little different where when I finish, I didn't really feel I understood what programming really was. I still felt like I understood a primitive level like just building something, just a 'Hello, World' using HTML CSS. When I finished, it took me a year and a half to actually get a full time programming job, like a legit job.

Before that, I was scrambling doing three part time jobs and lots of WordPress grunt work. Even though I thought it was actual experience, it was enough experience but I feel like a lot of the programming concepts that I've had to learn and just basic functional programming, I've learned it on the job. I don't yet feel like I am a legit 'real programmer'. We were talking about the Pinocchio thing like, "I'm a real boy." But I want to be a real programmer.

[Laughter]

STEPHANIE: What I'm curious about is at what point did that happen? When did that click and when did you stop having -- I'm sure at some point you had -- impostor syndrome? When did that just evaporate and you're okay?

LIZ: I still have impostor syndrome all the time. It’s weird that it's like I have a sense of, "Oh, I can figure anything out." At this point, I know who to ask or where to look and I could figure anything out if I really wanted to. But I also feel like everyone else is better than me. I get impostor syndrome in that sense, not that I'm not a programmer but that everyone else is better than me.

When did I start feeling like I was a real programmer? Definitely not at my first job. When I started my first job at SimpleReach in November 2014, I had two months in between bootcamp and the job. In that time, I made some weird little apps but nothing super serious. I made an app that I use the Twilio API to anonymously text Seal lyrics to people. It sends either lyrics from Kiss From A Rose or a fact about Kiss From A Rose. You can choose which one. I made stuff like that.

CHARLES: [Singing in the tune of Kiss From A Rose] There's was so much in app can tell you so much it can touch. Okay, I'll stop. I'll stop right there. I promise.

LIZ: Yeah, so I did stuff like that and I sort of wrote my own crowdfunding to go to RubyConf because I gotten an opportunity scholarship ticket that year. But I couldn't afford to go otherwise. I did a little crowdfunding thing but I did little things like that. I didn't really feel like I understood everything so I was looking on other people's code and forking stuff to make all that happen.

Then I got my job and it was small-ish start up at the time and they didn't have a whole lot of on-boarding at all. It's kind of like I showed up, they gave me a computer and it took me three or four days to get their app running locally. It was just a lot of leaving me to my own devices a lot of the time in the beginning and I was kind of like, "I don't know what I'm doing. What do I do?" It took a while.

As the company matured and as I matured as a programmer, they kind of develop a little more infrastructure, I guess for supporting junior engineers. As time went on, I became better and they became better at mentoring me. I don't know when I felt like a real programmer, probably sometime in the middle of that job. I gave my first technical talk, I guess or conference talk at EmberConf in 2015. I gave a lightning talk at the behest of the Leah who is now my boss. It was a five-minute talk on why testing an Ember sucked at that time. It sucked for me to learn and it was really hard. I wanted to learn it but it was really hard.

Then after that, people started talking to me. They came up to me after and they are like, "Oh, my God. Blah-blah-blah." I was like, "I don't know half the stuff these people are saying. I don't understand what you're talking about." I'm going to smile and nod. But maybe a little bit after that, I kind of started feeling more that I could solve problems. I think public speaking actually helped me a lot with that like when I realized that I had something to say and that people want to hear it, then I could help other people feel empowered to learn stuff, I think that was part of it as well.

CHARLES: Yeah, I really like that. Obviously, I'm going to push back a little bit on Stephanie, just in terms of the day-to-day. You definitely deliver daily as a programmer so you can look at that. You've mentioned this at the very beginning of your answer and it almost really sounds like what you came to be was more of a kind of a peace with the things that you didn't know, rather than feeling confident about the things that you did. You said something and I'm going to paraphrase it but it's like, "I got to the point where I became sure that I would be able to figure it out." Or, "I had strategies for being able to figure it out."

Maybe we can unpack that a little bit because I feel that's actually very, very important and that's a skill that's important to have at any level of experience in your career, whether it's one year or whether it's 20. Certainly, that message when I saw you speak that's something that I took away as a very experienced developer. I felt actually empowered by it. What are some of those mechanisms to feel at peace with your own ignorance?

LIZ: I think part of the problem for me, I started learning how to program before I went to dev bootcamp or whatever, that I was really good at stuff. I actually think that was a problem because I was used to succeeding immediately or like always doing everything right so it's hard when you start learning something and you don't realize when you first start learning programming and it's not supposed to work immediately, like you're starting with something that's broken and you're making it work.

CHARLES: Right. In fact, 99% of the experience is like every time I look at a piece of software, I'm like, "Someone sat with the broken version of this for a year and then it work and that's what I got." They got to live with the working version for two seconds before it came to me and they spent the rest of the time, totally broken.

LIZ: Yeah, totally. It’s hard when you're used to creating something from scratch like doing comic books and like writing stories and stuff. It’s never broken it's just blank and then you add to it so I'm used to that sort of workflow. Then I started in this new field where Rails is new or whatever then it's just errors as far as the eye can see until you fix it, until you configure it, you made it work. It's hard to change your mindset into that. It's easy to feel like a failure when all you see is errors and you don't know that that's normal. I helped a couple of my friends to learn to program and I think the biggest hurdle is just mentally overcoming that it's not you, you’re not a failure. It's just that everything's broken until it's done.

STEPHANIE: I can definitely relate to that. I was always one of those overachievers, straight A, AP class. I'm not even kidding. In my high school, they called me Hermione, which for those that don't know, that's the girl from Harry Potter. It’s like you take it really personally when you feel like you're a failure. You feel like you can't deliver, you don't pull your own weight. For me, it's actually so overbearing that it can even inhibit you from doing things like public speaking or other activities. But one of the reasons why I do like to teach whenever I can is because that's when you realize, "I do know a lot of things," like how to do stuff on Git and just basic things that you don't even think twice about.

I volunteered for this these high school girls and no one really gave me any instructions and I just rolled out of bed for this thing and just have them build a basic cute little web page with their picture and this and that. I had to really think hard to how do I put just a regular image tag and I had to peel back all the old layers of stuff that I don't do anymore. You don't think about those kind of things in Ember or JavaScript frameworks. I caught myself in keep on saying dom and this and that and they were like, "What is a dom?" And I'm like, "Urghh." But then I realized, I do have all this context, I guess I don't appreciate it or something.

LIZ: I think talking to beginners when you're slightly above beginner-level in helping other fresh beginners is one of the best things for you as a new developer because you realized, you're like, "I actually know stuff."

STEPHANIE: Yeah, that's usually the type of advice I like to give to other aspiring junior programmers. I also wanted to ask about it seems like now you're going through something similar because you tweeted or you're asking about systems programming. What's that like?

LIZ: I'll start at the beginning. When I started at Tilde about a year ago, I knew that we use Rust, which is a systems programming language, a lower level language than Ruby or JavaScript. We use it for some aspects of our stacks. I thought, "That's really cool. I want to get into that nitty-gritty type of stuff so how do I learned that?” I started learning Rust but I didn't really know how to apply that knowledge.

I wrote like a little adventure game in Rust and it was almost exactly the same as when I first started learning about web development, it's similar to how does this become a website, instead of like, "How does this become a computer thing?" I don't even know what systems programming is but I hear Rust is a systems programming language so I want to learn that stuff, like what is that stuff?

A couple months ago, I think it was, I tweeted like, "Anybody have any probably three systems programming resources so I could learn more about systems programming?" And I got huge amount of responses. Everybody was super kind and helpful but a third of the responses were like, "Well, what kind of systems programming?" And I was like, "I..."

[Laughter]

CHARLES: "The kind that happens on a system?"

[Laughter]

LIZ: I don't know. It was kind of the same thing. I think I used this metaphor earlier but it's similar to when I first started learning programming it was like I was standing at the front of a forest and I knew that the stuff I want is in the forest but I don't even know what a tree is, you know what I mean? Eventually, I learned what a tree was then I learned what a map was and I learned how to get through that forest. But then in the middle of that forest, I was like, "Oh, there's a tunnel," like there's another stuff. "I want to get on to this tunnel," but I don't know anything about living underground, you know what I mean? Like, "What do I need? What even is there?" I have no idea so that's kind of how I feel about systems programming. At the moment, I'm trying to go into this tunnel but can I breathe down there? I don't know. Where does it lead?

CHARLES: I feel like at that point when you're about to enter into the tunnel, can you intentionally apply filters for information that at that point is not useful like the difference between a stalactite and stalagmite is not useful when you haven't even gone into the cave yet and you're just like, "How do I actually just get down there with a flashlight?"

How do you go about deciding which information is useful and which is not at your particular stage? Because obviously, it's all going to be useful at some point but at what point it becomes useful and what point do you just catalog it and put it for later? I feel like that's very, very hard thing to do. Do you feel like you're able to do that?

LIZ: I'm not sure. I think I said this earlier but I feel like I can figure most things out at this point like if I really want to. One of the things I learned just from talking to people on Twitter about systems programming is like, "Oh, some examples of systems programming are operating system," or like a browser engine because I'm still learning Rust and I gotten to write as much lately but I know that there is servo which I believe is a browser rendering engine written in Rust, it's something like that.

CHARLES: Supposedly it's going to powering Firefox at some point.

LIZ: Yeah, stuff like that, I think is really interesting but now I know a little more about what to look at in terms of as far as I understand, there is probably an infinite amount of different kinds of systems: operating systems is one, maybe a browser engine is another. I can't remember the others but I'm sure people tweeted it out to me.

STEPHANIE: I feel like we touched on something which is it can get overwhelming when you're starting off in something new. Trying to understand what you don't know that you don't know.

LIZ: Yeah, that's the hardest thing.

STEPHANIE: How can you make tangible goal marks for yourself if you don't even know what you don't know? When I first started off, when I would pair with someone that was more advanced, I remember having a realization that every time I would look for an add-on or I'm looking at someone's repo, I would take my time to read everything about it, all of the Ember documentation and I need to know everything.

Then later I realized that is totally not the case. Like Charles said, people develop this filter for noise and only focusing on not the entire tool box but that one tool that they need for that one specific thing that they're doing and I realized it only when I was pairing with people and seeing that. They go to this repo, skim it, "No, this is not what we need. Let's go to the next one. Let's try to find a method that what we need," and then they would just search on the page. "Oh, this looks kind of similar. Let's plug this in," and I'm just like, "What? You can do this? You can just copy/paste someone else's stuff?" and it was amazing. But when you're starting out, you don't know all of these things and unfortunately, kind of waste a lot of time thinking that you need to know everything and you don't.

CHARLES: Yeah, Cheating is totally a virtue in so many cases.

[Laughter]

LIZ: Totally, for sure.

CHARLES: Just being like, "I don't need to understand this," but I just know that it works. You pushed at what point that happens like further and further back but that boundary of understanding is just simply always going to be there. No matter where you are, that kind of veil of ignorance, you can push it out but it's just can be further away. I am actually curious, you mentioned you got really into math, this is when you went back to school. What drew you to that and how have you applied, if you've applied? Have you found it to be an asset in your development career?

LIZ: For sure. When I first went back to school, it was with the idea that this is totally different now, obviously. I thought I might become a veterinarian --

CHARLES: You need a lot of math for that, right?

LIZ: Well, it's like a lot in biology and there's a lot of math and science and stuff. I had to take a bunch of science classes and take biology and chemistry so that involved taking some pre-calculus and calculus and more calculus. What I realized, though was that I hated biology and chemistry but I love the math that I was learning. I loved the process of problem solving and just figuring out puzzles.

When you get into calculus, how you solve problems, they're similar to how you solve problems in programming where you have sort of a framework like I have this certain language which would be the different theorems or whatever in math and you can just pick and choose which ones will fit your problem and if you're taking a calculus test, you could be sitting next to the same person and you might come to the same answer in different ways so it's similar in programming where you have all of this documentation, you have these languages, you have use other frameworks and you can solve the same problem in a million different ways.

But in terms of how people talk about needing math for programming, I don't necessarily think you need math for programming but if you already like math, it's definitely sort of a happy path, I guess because you get the same joy out of programming that you get out at solving calculus problem. But if you don't like calculus, it's okay. I don't think it's necessary.

CHARLES: One of my favorite blog posts of all time is this letter to young Haskeller, I don't know if any of you guys have ever read that. It’s fantastic and it's an experienced person in the Haskell community talking to someone who's just coming in and it's incredibly empathetic and wonderful. I think it's a message that needs to be heard more generally. I think it's ironic coming out of the Haskell community as it does because they definitely have a reputation for being a little bit salty and a little bit exclusive. But it's actually a very inclusive message.

One of the great points they make is they say we've got the whole equation reversed. It shouldn't be, "Math is hard, therefore programming is hard." It should be, "Programming can be really fun, therefore math on which programming is based, can also be really fun." You can go both ways. If you find math fun, you can find programming fun and if you find programming fun first, you can later go and have fun with math. You can pick and choose which parts you want. I think it's a great message that needs to get out there.

LIZ: I think it's also really, really important to note for anyone who might be listening that is getting in to programming, that is scared of math or has had a bad experience with math that it is not necessarily to love math. I think that scares a lot of people away and a lot of the stuff that people learn when they're first learning programming are math based. When I was in the Flatiron School, Some of the exercise we did in the beginning with just pure Ruby were Fibonacci sequence. They were sort of math-y and that turns a lot of people off and makes people scared. If someone is hearing this and has experienced that, don't be scared. You don't need to worry about it. But if you love math, then it's great but you don't have to.

STEPHANIE: I'm one of those people that always had this mental block of like, "I'm not good at math." I was good at everything in school. I excelled at everything except math. I think a lot of it came from my struggle when I was a kid so you have this self-perpetuating thought that you aren't good at something. Every time you take a final or something, you blank out because you have this mental wall in your mind.

What I found weird was I was doing the exact same thing. I was taking calculus for bio-sciences and physics too at the same time. In physics, I loved that class. It was so awesome and I realized that half the stuff I was doing was going backwards in all of my problems and it was fun for me. Eventually, I was taking a final for my calculus class and I didn't remember the equation that we needed for that class so I took out all the variables and I solved it as if it's a physics problem and I got the same answer and I was correct.

I realized at that moment, if you just remove the negativity from your mind and you try to apply yourself in the same fashion as you would in something that you enjoy, you'll just forget for the moment that it's math, that it's something that you 'suck at'. You actually could do good in it and not get stuck. I realized I actually do like math when it's veiled as chemistry or physics.

LIZ: I think a lot of people have that experience with math. They have a really bad experience when they're young and then they get stuck and they feel like they're just not good at it like somehow, on this subatomic level, you just can't change it or you're not good at it. It’s not really true.

STEPHANIE: Yeah.

CHARLES: I actually love that example because it is, it's all integrated. We are constantly doing things like math without even realizing it. Actually, one of the things I love about the Montessori education is that's the way they actually teach it. They have all of the different great lessons, they want to convey to the children which is things like courtesy and grace, things like taking care of your things, things like music. But for all, I think they've got a bunch of different categories but they make sure that they always intersect with each other and you get that in surprising ways to make sure that if a child likes music, use the music as a way to introduce them to arithmetic.

If they like arithmetic, use that as a way to introduce them to music. If they have things doing design, I don't want to say, interior designer or clothing design but practical life stuff and if that's something that a child really is drawn to, then they'll use that as an introduction to music or geography. There’s all these parallels that are constantly there and you can ride whichever rail works for you to whatever area that you want to go. There is no set way to approach math. You literally can find a way that works for you.

STEPHANIE: The subjects aren't mutually exclusive, "Because you're not good at this, probably you shouldn't become a programmer."

CHARLES: It's not expected that every child will grow in one subject at the same rate that they'll grow in every other subject. They just let the children explore the area that they're interested in and let them go crazy. If they're really into art, they just let them explore and learn as much as they can and then slowly entice them and just show them the connections that art has to courtesy and grace to math to music to other things and let them see those connections and then follow them on their own.

That’s why they call it -- the kind of grown up in there -- the guide. It's really there. The way that they push is by showing them the connections but then using the kind of internal motivations of the children to move. I actually have some pretty strong feels on this. I feel like our education does leave a lot of people behind because there's this expectation that in every single subject, everybody will goose step forward at exactly the same rate and that's just a fable. It's not real. It’s not how the human mind works.

LIZ: Yeah.

CHARLES: But yeah, I actually think, certainly for me and my connection to math has been helped by the fact of programming and now, later on after having done a lot of programming, so much more is interesting to me about math and I can see beauty in it, I think where I didn't see beauty in it before.

STEPHANIE: For one of the projects that we've been working on, we have been doing an Ember upgrade. I basically needed to get some changes for one of the dependencies and I have no experience in open source, whatsoever. That happened for the past two weeks. I was making a lot of PRs to two different dependencies and that was my first experience with open source. It was less scary than I had imagined and I actually got a lot of great feedback from it. Now, I realized that it wasn't as hard as I thought it would be and most people are very receptive to your PRs or if you have questions about their open source because they need help, they need people to help them tackle all the issues that they have so I'm curious, do you have any advice for people that are interested in contributing to open source but they may find it daunting and they don't want to look dumb or do things the wrong way?

LIZ: One of the things I've been interested in since I started learning programming is open source because I enjoy collaborative atmospheres and just the idea of a big group of people coming together to solve problems. It was something that I wanted to do since the beginning but it's super intimidating because when you think of people who are open source maintainers, at least to me in the beginning, they seemed way above me like Gods so I'm like, "How can I possibly be useful to these Gods?"

At my last job, my manager was like, "I got a couple of goals for you and for your career." One of my goals was I want to contribute To Ember CLI Mirage. That was a goal. I just thought, "This is a great add-on. This is a great project and everyone uses it and I love it and I would love to contribute to that." I made it a goal but then in that in the middle of that time period, I got a job here at Tilde and I went to Portland. Shortly after that, I went to the repo and I was like, "I'm going to do this thing," because one of the reasons why I chose it as a project to contribute to is because I heard Sam is a really nice guy. One of the things was that I was really intimidated by the people maintaining projects is like, "Well, he's not intimidating." I feel okay about this so that's a good first step.

The second step is let's find a thing to do so I look at all the issues on the repo and I find something super simple which is just adding in-line documentation. That’s what I did and I was like, "Can I pick this up?" I was feeling super shy so I didn't even want to put it on the issues so I think I just pinged him on the Ember Slack and just like, "Can I help with this?" He's like, "Yeah, yeah. That's great," so I made a bunch of in-line documentation additions to the project and I made my first PR and it felt like such a way that it's not as scary at all as I thought it would be so I started contributing to other projects, things that just came up. Not so much like in your situation where it was a dependency I was using but more like I saw somebody tweet about it and like, "I just made this project and I think there's a bunch of typos. Can somebody just spell-check this for me?" I'll go in and do a couple of typo fixes.

Another situation when I was reading through a repo because I want to learn and there's a project called intermezzOS which is Rust operating system, like a tiny operating system. I was just reading the code and I was like, "There's a couple of typos. I can fix this," and stuff like that and I found, through that experience, that open source maintainers are super happy to have you help in any way that you can, even if it's a little things.

In the last couple of months, I started my own project which is like an app -- it's not an add-on or anything. I actually got my first couple of PRs from other people and other people are helping me build it. I don't think I've ever met but every time I get a PR, I feel like I won a prize. Every time someone contributes and I'm like, "Thank you." I cannot give you another --

[Laughter]

LIZ: I love that you're helping me. You know, like I only have one hour a day to work on this thing so anything, anyone people can do to help me is so great. Now I have the experience of being on the other side and I can attest to the fact that most open source maintainers are incredibly stoked for any help they can get. Even if you're new, just find someone who's nice and ask them how you can help.

STEPHANIE: Yeah, that was a realization that I had because I was communicating directly with this person in the Ember Slack as well. I had submitted a PR and later he was like, "Hey, while you're at it, do you mind adding in this one property that's missing?" And I'm just like, "All right. Sure." Later he offered if I wanted to become a collaborator because I was putting in so many PRs and like you said, he hasn't had the time to cut out a new version or to fix the things that you keep in your head, "Okay, I'm going to go back and fix this," and then someone else is like, "I want to fix this thing," go for it. That's the best.

LIZ: Yeah, totally. It's a great way to learn more stuff too.

CHARLES: I like the point about choosing a project that you know is not intimidating because unfortunately, there is a lot of negativity that happens out there.

LIZ: Totally, I knew that and that was a big blocker for me, for a long time.

CHARLES: Yeah but knowing that there are actual, I would like to say, a majority I don't know if that's true but it can feel like it's enclaves, just because negativity has a way of clouding everything and propagating but there are certainly areas where we put that way and it's very healthy, it's very collaborative and welcoming and making a definitive effort to first know that they're out there because if you have a negative experience, you make sure that you don't bounce off of that and then define them. I really like that, how you were deliberate about that.

LIZ: Yeah, it seems like the most important thing, if you're a new programmer and they're like, "How do I get involve in open source," and your first advice is like, "Find someone who's really nice." It doesn't sound like the right advice but I think it is the right advice.

CHARLES: That's because that's where you'll stick.

LIZ: Yeah and you'll want to collaborate with that person and that project because you're not scared of being insulted or something.

CHARLES: Well, that was fantastic. We can wrap it up.

LIZ: I have two talks this year so far coming up. One is going to be in Toronto at the end of this month at a new conference called 'Hello, Con!' I built a type space adventure game in Rust and I built it side by side with the same game in Ruby so I can learn Rust by doing the same thing on both sides. I'm going to be talking about the similarities and differences and things I came across learning Rust as a Rubyist.

I also have a similar talk in May at OSCON in Austin about learning Rust as a Rubyist but at a slightly different, longer talk. I did a version of it at RustConf last year. It's kind of in comic book form so it's all of drawings and it's sort of a story about going to a place called Rustlandia as a Ruby person and how you literally navigate that world, not just everything is sort of a metaphor. I'm getting that talk again in a longer form at OSCON in Austin in May.

CHARLES: Well, fantastic. You have to stop by the office and come see us.

LIZ: Yeah.

CHARLES: But thank you so much --

LIZ: Thank you.

CHARLES: -- Liz for taking the time to talk with us. This is a great conversation again. You know, I feel like I'm going to come away feeling that I've got more tools to deal, certainly with my daily struggles --

LIZ: Yeah, get pumped!

CHARLES: -- In programming. Yeah.

LIZ: Programming! Yeah!

[Laughter]

LIZ: -- One of the Mortal Kombat music comes in -- Tun-tun-tun-tun-tun-tun-tun-tun-tun...

[Laughter]

CHARLES: I remember actually seeing Mortal Kombat in a theater and I actually getting up and dancing in the theater and then the rest of the movie just sucked. It was like they spent the whole budget on the first 20 seconds of that movie. Anyhow, all right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that's engineered to make your UX dreams come true.

Philip Poots @pootsbook | GitHub

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 56. I am Charles Lowell, a developer here at The Frontside. With me is Jeffrey Cherewaty, also a developer here at The Frontside.

JEFFREY: Hey-o!

CHARLES: We're going to be talking today with Philip Poots, who is a fantastic individual, who I have known over the Twitters, over the e-mails, interacted with at conferences, seen him speak on at least one occasion and today we're actually going to be talking about the thing that I saw him speak at Wicked Good Ember last June. It was actually one of my favorite talks from that conference. It was on Elm for Ember developers. Thank you very much for being on the show, Philip. Why don't you tell us a little bit about what Elm is and how you came to find out about it and really kind of dive deeply into it?

PHILIP: Yeah, sure. First of all, pleasure to be on the show. The Frontside is one of my favorite podcast, if not my favorite, given a cross-section of the Dadcast, the love of programming and balancing that with the business of programming. That’s right, I'm an independent developer. I started off with Rails then got into the Ember quite early on. Last year, I think around January, that's when I started really investigating Elm in detail.

It's actually a funny story how I came about because I was at Ember Amsterdam and it was a night where we had three members of the core team: we had Erik Bryn, he gave a talk, Alex Matchneer, gave a talk and Igor also came over because he's based in Europe. Alex always loves to investigate new things and one of the things he was getting into was Observables. I'd never heard about Observables at all so after the talk, I kind of pulled him aside and I asked him some very stupid questions. He was gracious enough to bear with me and to dive a little deeper into this stuff.

Alex is kind of a quiet member of the core team, unless he's got his drum sticks but he's the guy that rewrote the [inaudible]. That was no mean feat because I got into Ember just before that moment and the way he managed to make that incredibly easy was fantastic so I kind of had an extra ear open to what he had to say. I went on this Observables talk. You know, you start off with React that was the framework that was using Observables the most. That brought me to Cycle.js --

CHARLES: Cycle.js? I haven't heard of that. Is Cycle.js a framework built on top of Observables?

PHILIP: It is. There’s a guy called André Staltz or André Medeiros but he uses Staltz as his name. It’s largely based off the same principles as React. Cycle, basically one of his inspirations or at least one of the things which cycle is most like was the Elm architecture. He calls it Model-View-Intent. We have Model-View-Controller and Elm was model update view but essentially, the same principles.

You know, I'm the kind of guy that likes to get stuck in, to go deep and where I started with Observables then I ended up at Elm. I started playing around with that, I started looking into it and I loved what I saw. The thing above all that really attracted me to it was the pure simplicity of what was going on. It was almost like they boiled down the UI paradigm to its essence and removed all the extra cruft and you just saw what you meant what you wanted and it gave you these, what I thought at the time, composable way to put things together.

CHARLES: Can we unpack that just a little bit? I really love that idea of it boiled down to the essence of UI. I assume there are certain coordinating mechanisms that Elm employs. It’s interesting to hear you say that Cycle.js has used Elm as an inspiration. I also understand that Redux is inspired also by the Elm architecture. I'm very curious, what are those kind of essential mechanics that drew your attention?

PHILIP: I think you can look at it from two points of view. The first is, which I didn't actually learn until later but the first is essentially boiling down functional programming. You’re decoupled, you're using functions and not only functional programming and there's a lot of arguments over this term but functional reactive programming. The idea of functional programming is stateless. Therefore, time is kind of the beast that you have to deal with.

But FRP, then essentially boils time into the concept of values that can change over time so you have a reference to one value but in JavaScript that's an Observable. In Elm, in the beginning, when I was getting into it, that was signals. That's not all kind of hidden underneath so you don't really need to get over that conceptual hurdle anymore. Then the boiling down to the essence, I guess that's more from a code point of view with Ember. Especially at the beginning, there were a ton of different concepts that were thrown at you to begin with. It was billed as an MVC framework. It was sold as an MVC framework but you had helpers in there, you had components, you had views model controller. You had this cluster of things. You could see MVC in there but there were enough things surrounding it to kind of think, "Where does this piece of code go? Where does that piece of code go? Where should I do this?"

CHARLES: There are a lot of blog posts trying to explain what exactly is the view, is the template the view? Is the controller the view? What's the difference between a view and a controller?

PHILIP: The way I think about frameworks is they give you buckets to put your code. The buckets are kind of all connected together. I'm thinking at a really simplistic level. I need to write this feature, I need this bit of code, I need this bit of logic, where do I stick it?

A framework says you should stick it here or you should stick it there. It's solves the need of having to think about the broader architecture and how things interact because those things have been solved for you. Now with Elm, it was just so straightforward to say, "This goes here: all the data, the model. It lives in this record, which is equivalent to a JavaScript object, we can say on a simple level. Anything you need to do with state, happens there. Then you've got the view and the view is simply a function, which takes that data structure and then you tell it how to render it to HTML and then all of the action, everything that happens in your application is also defined in one place in your update function. That’s it, like no more than you need and no less than you need.

CHARLES: Yeah, I love that. I feel like it is very much as 'data down, actions up' kind of boiled down to the essence. It’s almost better at that paradigm than Ember is in itself, with having your view as just a function. Your state transition or your update is just a function. Then your model is just unadorned data. That’s all it is.

PHILIP: The type system as well in Elm, also made it really straightforward. My model is a record. That’s it. My view is HTML in the beginning but then it moves to HTML, which contains messages. Essentially, I've got HTML and in the HTML, there are events or actions and those actions will send messages and really straight forward. Then the update function, I take in the current model, I take in the message and I decide via pattern matching what I want to do. There are a few extra bits and pieces around there but that's the essence of it.

CHARLES: Now, when you say messages, I'm thinking this is a way of declaring what actions you will take when certain HTML elements, like events happen, like you declaratively mapping an event to the dispatch of an action.

PHILIP: That's correct, with any extra data so a message is itself. Like the actions hash in Ember essentially and along with the parameters for that action, which would passing through the HTML.

CHARLES: Some might argue that if something is simple to get something working, I can have a pure function that's a view, I can have a simple data structure which is my model. I can have a pure function which is my update or my state transition, how I change my data or affect changes to the model. Some might say, "That's very simple," but simple is great for simple cases. But then there's the question of scalability. As my application becomes more complex and has the interactions become more complex, does that simple paradigm actually scale? What has been your experience there?

PHILIP: Straightforward answer -- it's a learning curve to scale. Why? Because it's so new and also because the things that you would have reached for in the past aren't available to you. When I think of Ember scaling, the scale is built into the framework. You need another component, you just add another component. You need another model, you add another model. There’s a clear story or there's a clear way that you deliver a new feature.

I think that's a fantastic aspect of Ember that you also say no. I can remember being at Wicked Good Ember and just realizing how many of the people that were speaking and how many of the people that I was talking to work for bigger companies -- Heroku Dashboard, you had LinkedIn and the fact that Ember scales across a large team size, it's a real testament to Ember, which is slightly different for the reason why I got into Ember. Also you know I had a few issues just on a side project with a friend, the pace of Elm's change meant that when you only have a limited time to devote to the project, then you don't want to be spending that time for going out where you should be in terms of the upgrade process, etcetera.

That’s a known path and I think that's a really clear advantage of Ember over Elm. The path in Elm is not as well-fleshed out and there's a bit of tension between Elm as a single page application and then Elm as an application that you stick on every page of your server generated app, for example. The main people who use Elm NoRedInk could employ Evan Czaplicki, the creator of Elm, there up at the minute is a Rails up. I think in Elm up for every page, I believe that certainly was the case, whether that's [inaudible], I don't know.

It’s not an area where it's like here's the path, go for it because the scalability of Elm, everyone came into Elm thinking, "I know react. I know Ember, the components system, 'data down, actions up'," and in React, you're really encouraged to make a component for the smallest thing on the page as a component. Then you have container components, you make your way out of the onion skin and hope you don't cry on the way.

[Laughter]

PHILIP: But the thing about Elm was everyone jumped in and tried to do it this way. I certainly got the impression when I was beginning that the Elm architecture was infinitely Nestable Russian dolls. It is in a way but the difficulty is then passing into component communication between parent and child and people had been figuring it on a weird ways with signals to do it but then became obsolete.

The main encouragement is basically go so far with a single component that you can and then once you had problems, try not to create new components or new bits of UI but to extract the bits you need into modules. This is actually one of the things that really attracted me to Elm is that you're encouraged to lean on your programming skill set, rather than learning a whole new frameworks way of doing things so that the things that work in functional programming will work in Elm. But that's also a down side because all of a sudden, you have to exercise your programming chops. Let’s be honest, a lot of the stuff we're building we're like gluing things together. We’re not thinking up new architectures or ways of doing things. That’s definitely a learning curve and that's definitely a struggle or something that I find difficult.

CHARLES: Yeah, I feel like that touches a lot on the messages you get from the FP community. I know certainly in the interactions I've had with the Clojure community, they're very big on that and it's like, "Let's have very powerful primitives." They have that term 'decomplecting', like let's get at the core. It’s like understand that essence so if we can compose and we can enable composition of these low level functions and allow you to compose the data, then you don't have to worry so much about everything else. There will be a way. I think the counterpoint to that is that you end up with a lot of different ways because there are a lot of different ways that you can compose a very small set of primitives.

PHILIP: Yes, that's right. But I think one of the advantages of Elm over maybe other FP languages and this is where the similarity with Ember comes in as well. It tries very much to cement simple convention but not only by convention but actually baked into the language so people that are coming from more powerful functional programming languages often come to Elm and think, "Why can't I do that? Why do I have to write all this boilerplate code," and the reason is because then it's not going to be simple enough anymore for people to use it. Also the goal of Elm, which is this long term maintainability of large code bases, you kind of shoot yourself in the foot a bit just like you said, Charles.

CHARLES: Yeah, I think that's actually a great point. It’s actually one of the things that was most memorable, I think about your talk at Wicked Good was -- just a quick anecdote. I remember in 2007, when iPhone came out, I had an iPhone and my father in law came over from Finland and this is a guy who was a Nokia partisan. I mean, part of Finnish pride was everybody own --

JEFFREY: National phone of Finland.

CHARLES: Yeah, exactly. Everybody owned the Nokia mobile phone. He came over, He visited me and I had an iPhone and he was like, "Can I see it?" He took it, he had the swipe to unlock and he swiped it and it unlocked and all the app icons just kind of came right into the screen and he was like, "I want one."

[Laughter]

CHARLES: That was all it took. I've never seen a sales process so utterly complete and so rapid in its realization. For me, I think that moment when I saw you talk was when you made a mistake like where you were trying to match against an improper attribute on the model inside the update function. The first thing that happened was that Elm caught it before you could even compile your program and the error was just beautiful. It put its finger right on and it's like you need to fix this right here so there's much tied up into that because I feel like it addresses a lot of the learning curve problems that we have in Ember.

PHILIP: I don't think that's Ember specific --

CHARLES: No, it's not, it's --

PHILIP: That's the JavaScript thing, isn't it?

CHARLES: Yeah.

PHILIP: In many ways, I think of JavaScript as a very low level substrate. It's like sand, it's very granular and it's very hard to put together well without falling apart, whereas in Elm gives you bigger blocks, so to speak but it also defines a way through the type system where if you don't put those blocks together in the right way, it's going to tell you. That’s why despite some of the ignorance of how best to do Elm apps, that's why people continue to use it because it gives them this delightful experience.

CHARLES: Yeah, it was fantastic where when you fail, it picks you up, dust you off and sets you right back on the right track. I think one, that's just a freaking awesome feature and I think also two, the thing that struck me when I saw that was like, "Wow, this community has a different focus than other FP communities that I've come into contact with because I have encountered that exact same error message in Haskell and it left me puzzling and wondering what to do. It's like, "No instance for type class blah-blah-blah for class blah." Then if you're an experienced Haskeller, it does point right to the problem in the same way that like you've learn the parse Perl stack traces. You know, you see a Perl stack trace and you understand it. But they could have gone that way with Elm but the other thing that it demonstrated, it has kind of a different focus there.

PHILIP: Absolutely and that really comes down to Evan Czaplicki, the creator of Elm. I was able to get over to London in October a couple of years ago or a year and a half ago now to do a workshop with him at the Code Mesh Conference. You know, just seeing him teach this stuff and saying go into this and talk about the things in a bit more detail, it was very clear. First of all that he'd had a negative experience picking up Haskell, I think it was and he just thought, it doesn't have to be this hard. The things aren't actually that hard. It's the way that we're explaining them that makes it hard. The things that are actually under the surface is really simple. He has a blanket ban on this kind of technical jargon.

In the Elm community, he prefers to get things really straightforward names. I think he said to me that one of his thesis advisors or his university professor said, "Evan, that's what you get when you put a usability specialist into a programming language creator's shoes," that he does have this focus where he understands the benefits of static-type systems but he also deeply cares about the experience of not only picking up the language and learning it but also the day you solve it and that's something that just shines through.

I think even if Elm never makes it into the pantheon of great programming languages like that in itself and the influence of that had already on other communities, this is fantastic. It’s the tide that lifts all boats in many ways and we all benefit from that.

JEFFREY: We kind of touch on this a little bit earlier. We’ve been talking about the ergonomics of being an engineer working with Elm or Ember. What about the business case? We’ve mentioned how Ember has prevent a scale fairly well in large organizations. What's Elm's path to being able to do that and where is the niche to that it fits in right now?

PHILIP: I definitely think Ember comes out of Apple, I believe with sprite core. That’s where it started and it's interesting to see that that's also where it's gone in terms of the focuses and making it easy to build these rich applications. I think also that Elm has a similar genesis in the sense that Evan, I believe he did an internship at Microsoft and one at Google and I think there's a conference talk as well from large JS or elm lock or something, millions of lines of code.

It’s definitely gunning for the CM area which is applications which are large and hairy and trying to make the maintainability a lot better by bringing the strengths of the static type system to bear and bring the simplicity that that enables. That means that the learning curve maybe is a little sharper at the beginning, in a similar way, also that Ember was and is. But then you should reach this point where the maintainability of the app outweighs the time spent in learning.

I think about it a bit like test driven development. I remember back when I was doing Rails and DHH had baked TDD into the Rails itself and there was the years of the testing discussions whether to test all the time, test everything, 100% coverage or even full circle tests are a waste of time. but it's a similar philosophy in that if the tests are doing what they should be doing, which is giving you great feedback, the time it takes to get up to speed in testing, the time it takes to set up testing, the time it takes to write the tests, they pay off further down the line and that's not music to the ears of the people who want to get something into production immediately. But it's definitely music to the ears of people who will be spending a long time on maintenance in an application.

That NoRedInk application is huge. They have millions of users. They’ve build software for teaching grammar and skills in the US and they talk all the time about the benefits of Elm. Mainly, in the sense of confidence, I have the confidence to go in and change this code. All of bits or majorities of our code bits, which are things that we've rather not like to touch. We kind of section them off.

If a feature request comes in and instead of saying, "Yeah, we can do that," you try and slowly push it out the door. Elm is supposed to give you then the confidence to be able to go to any part of your code base and to change it without the fear that you're going to break something or break everything because the type system, the compiler will tell you, "You change this type, you change the signature of this function, here's where it's broken and as soon as you fix the compiler errors, functionally it works, you'd probably have a few tests to test the actual business logic of it." Probably not so with technical stuff but it's a huge time saver.

That’s where we want to be as developers and our relationship with our tools. We don't want to be fearing our tools. We don't want to be anxious every time we open our editor. We don't want to fear the feature requests coming in. We want to be in control of our environment and we want to be able to deliver the business value. I think that's certainly the promise of Elm. That’s certainly where it wants to be.

CHARLES: I love that. It sounds like that is where they want to shoot for is these big applications and they do want to scale massively. Let me ask the question then. Where is Elm do you think right now today on that curve of scalability?

PHILIP: To put it in Ember terms, that's maybe the best way I can describe it. If anyone remembers the early days of Ember, I definitely feel that they're in 0.9 approaching one rather than later than that. One of the things as well, I think it's important to note is that Evan is not rushed. It just blew my mind when I heard him speak about it and it wasn't anything big or anything but just the whole kind of tenor of the conversation of the way he was teaching of how he was talking about Elm was so in contrast to the JavaScript type machine.

In contrast to a new framework every month, he was like, "If Elm is going to be around in 10 years, then this is the decision that I'm going to make." In that sense, where is Elm in that journey. I'd say it's still pretty early on. I'd say also, Evan is really focused on use cases so if there's not a use case for something, there's no reason to add it.

This is actually quite frustrating maybe for people who are coming out of JavaScript ecosystem and they think of a feature that they want and they submit a pull request and it just gets closed or it get set, is there use case for this? Why do you need it? Is this generalizable to everyone? Will it make sense to add this to the language? Can you do it in a library? Then figured out later, can you do it in JavaScript with port, instead of having to bring it into Elm?

He’s definitely building it very slowly but that may sound like a down side right now but the upside is we're going to come up with something at the end, hopefully that is battle-tested, that fits the use case and a good example of that was the URL handling at the navigation. It didn't live in Elm. Do we actually need it because he's building single page applications? Can you give me your experiences? There are a couple of libraries also built. Then the things from those libraries were then taken a little bit like Ember as well, where you use the add-on ecosystem to try new things and then things may get brought into core or make it kind of the official stamp of approval. But it's a lot slower and not as committee-based. Evan is the benevolent dictator for life.

CHARLES: I really like that approach. I don't withhold my opinion from the benevolent dictator versus kind of the oligarchy that you see elsewhere. But I was thinking as you were describing it that maybe the framework really, and this is me, I'm kind of a little bit of a tree nerd, mostly in and around the trees that grow in central Texas but I love trees. Unfortunately, it sounds like oak or maybe redwood would have been like a more appropriate name because those are very slow growing, have a very hard wood, whereas in Elm, it's actually fairly short lived and has a softer wood.

JEFFREY: And you also don't want cedar because that will come back and bite you -- highly allergic and toxic to humans.

[Laughter]

CHARLES: Right. Named Elm but slow growing hardwood that you can build a house out of. But I like that. It’s so important to get things right the first time because that's where you realize exponential gains. Unfortunately, there is no substitute for exponential gains, rather than deep thought. At least that's been my experience. You can realize gigantic short term gains with taking cut corners but in terms of long term exponential, ultimately those will taper off.

PHILIP: I think as well, what we've seen in Ember's experience is the decisions that you take to open up a private API or not to make something private. They limit you because all of a sudden, everyone starts using those APIs. A year down the line, you realize, "Oh, hang on. We don't want to design it in this way. We want to do it in that way," but given the commitment that Ember has to stability, you have to deal with that.

Sometimes, the dealing with that actually takes more energy, more time, more effort in education, in actual code, in maintaining two branches, all of that kind of stuff then actually takes away from the time that you could have had to think up better solutions and it's a danger, you know? It’s almost like as soon as you throw this into the water that it becomes firm. As soon as you throw it into the crowd, the crowd will take it and they will use it and your chance to change it or mold it will have gone.

Evan talks a lot with language designers and at least I got that impression that he opens up channels of communication with people who've done this before and he thinks very deeply. He’s not closed off to the idea of adding more powerful features to Elm but he would only do it when it's right to do it. It’s not just is this feature right but is this the right time for this feature? That as well is just the kind of mind blowing like who thinks about this stuff, who cares about this stuff?

CHARLES: Yeah, because certain features become accessible once other features are in place. I feel like it would have been as feasible to have an entire compiled language as an acceptable option before people started transpiling CoffeeScript and then with Babel, transpiling future versions of JavaScript back into JavaScript.

If those intermediate steps happened, if CoffeeScript and Babel would have happened, would people be as receptive to things like Elm or things like PureScript? it's definitely there is kind of the zeitgeist of the development community really informs what features are even possible or appropriate tomorrow, even though they might have some ejectively sound qualities out to them.

JEFFREY: They want to make sure they're not too far ahead of their time.

CHARLES: Right, exactly. Folks got to be ready for it. Then the other thing that I wanted to ask was given the trajectory of where Elm is, some people are using it in production. You said it was around like a 0.9, 1.0. if we are actually quite happy with our current code bases, whether we're using Ember, whether using React, whether using some other framework, what are things that you can learn from Elm that you can bring home with you to your own town, wherever that is to use and make your own life better, as you develop code, to kind of increase that confidence, as you say?

PHILIP: This is very relevant to my suggestion because in the past couple of months, I haven't had a chance to do any Elm but what I find is after kind of my deep dive, I've come out the other end and I feel like I've come out a better programmer. I feel like Elm is simple enough conceptually to learn quicker, faster, at least the basics more than maybe even to JavaScript framework.

I think that the things that you will learn in that process are tremendously beneficial, even if you don't ever end up using Elm in a professional capacity. The thing I think that grabbed me most is because of the way the type system is, you have to deal with every error and this is something when writing Ruby or when writing Ember, you always focus on the happy path. Then once you've got the happy path in place, often the business will say, "That's done. Let's move on."

Your better instincts say, "No, we haven't actually made this robust enough." But sometimes the value is also not the great in kind of shoring up all those cases. But what Elm does because of the way it's build is it forces you to deal with failure. The classic no runtime errors in production, the reason that is it may have taken you a bit longer to write your code in Elm. But you come out of it with a confidence that if something explodes, it's either something incredibly rare or it was JavaScript and not Elm. Just the forcing like, "How can I think better about how this code can fail," means a bit of extra mental effort when you do it in a language that's not Elm but it's definitely something that's worth doing, if you want to build good software.

Another thing related to the failure stuff is maybe the idea of what's called an abstract data type or a union type or an enum, like the fact that you can encode different states in one object, that you deal with all of those states in a cohesive way. One of the things actually, I think it was Jack Franklin of JavaScript Playground who brought this back from Elm into Java Script was when you have a screen, you want to load some data via Ajax or Fetch, instead of just loading the page, sending off the request, getting the request back, deciding what to do with it, it's like, "Why don't we encode those states in our code." We have the waiting state, we have the find state but we have find but it was an error, we have find and it worked, we have find and it actually has no values.

Instead of just dealing with those on the fly, if statements like why don't you create an object that encodes the states that your UI can be in and then you react and the UI will know what to do and you write the code to do that. But in some ways, at least to me that's a lot better than kind of hit and hope when we got an error. That's, "If do this, if do that, let's nest some callbacks or let's chance some promises." The sheer act of taking a step back and this is something Elm forces you to do because the way it is, like thinking about the domain and thinking about how best to model the domain. To be honest, it's probably just good programming practice but how often do we not do it?

CHARLES: Absolutely. It seems so obvious, except it's only obvious when you're put into a system that you can't slide on it. What you're describing reminds me of this concept that I came across in the Haskell community. They talk about wholemeal solutions versus piecemeal solutions. Most of the time, they talk about wholemeal solutions as kind of finding the most general set of abstractions that solve a problem for all cases. But I hadn't applied it to this concept of that all the potential states kind of envisioning your application.

As you execute your code, you'll only come across one state of the time but kind of thinking of your code as all of these sort of quantum states of your application existing at once and you need to account for them all and draw that whole picture.

PHILIP: This is a really stupid analogy but I don't know if anyone's played Age of Empires or any other kind of war-based game where you have a map, you've got the fog of war and you can only see a few meters around you and you have to send out your scouts and you need to find them --

CHARLES: Yeah, yeah.

PHILIP: -- Different tactics. You shore up your base and you concentrate on where you are, you send your scouts into the far ends of the map. In terms of seeking out of the unknown, I feel like Elm forces you to know the map where is when I'm programming in JavaScript or in Ruby, it's more like, "I'm here. I need to do this. I do it," and you don't necessarily force yourself to think of all the potential states or all the potential things that can happen, the events that can happen, whereas with Elm, if you don't have those, then it will tell you that those things in place.

[Laughter]

CHARLES: Yeah, I love that analogy. Like actually sent out your scouts to know the map.

PHILIP: Yep and I think as a person, and this is maybe why it appeals to me it's like I like the feeling that I haven't left a stone unturned. I like shipping something that I'm confident in and I know it won't bite me or if it does bite me, it's purely because it was an unknown-unknown. It’s like doing your due diligence.

As I'm saying this, Elm is not the silver bullet. Elm is not the panacea. Elm will not solve all of your problems. But speaking in terms of contrast with JavaScript or Ruby and more dynamic languages than Elm, these are the things that happen. I think that kind of leads me on to another point which is Evan in the mailing list conversations and the decisions that he takes with Elm, I don't know if this are stages of maturity as a developer but you find your tool, you love it, it's the only thing that can do the job and then you realize other people are doing jobs pretty well, doing their other stuff, I guess each to their own.

But I feel like there's another stage where it's like what are the tradeoffs involved in taking this decision or using this tool and what are the tradeoffs involved in taking this decision or using that tool. Just the way of thinking in terms of tradeoffs, instead of absolutes I find really, really valuable and that's definitely something that I've been able to apply and what are the benefits of this decision. Not only from a code point of view but from an organizational point of view, from a team point of view, from a long term point of view, from a short term point of view, having a wider arena to make those decisions, it has been really helpful for me, valuable on both side of them.

CHARLES: I can see it. I believe you and I think we're coming to the end of our time here, I think I'm going to make the same recommendation that I made to everybody last week when we were talking with Toran about Redux and that is you should go out and you should try Elm. It’s really easy to get started and it will guide you. The guides are excellent. The air handling is excellent and yes it is quirky and weird but it supports you. There’s going to be some big functional programming boulders thrown at you but it gives you a [inaudible] to deal with them.

JEFFREY: I think you need a suit of armor so we can stick with the Age of Empires metaphors.

[Laughter]

CHARLES: Yeah. Go out there, try it and experience the things that Philip is talking about because I feel like they are very real and they will have a good effect on you, whatever it is that you do the next day or the next week or the next month.

PHILIP: They'll challenge the way you think, they'll give you new perspective and they'll give you a good counterpoint as well. You know, elm is not for everyone but only if you try it will you understand that. I think that's one of Evan and everyone in the Elm community is try it yourself. I'm not going to say Elm is right for you, Elm is right for your business. Rewrite everything in Elm, not at all, try it out, try it on a side project, try it to just having fun hacking around. If you do want to make the jump to using it in your company or whatever, don't take a decision to rewrite everything. Take one very small part of your app and do it in Elm and see how it goes.

If you don't like it, you can take it out. If it works, you can build another small thing. This kind of gradual approach were far too quick to jump on a bandwagon: trash the old thing, do the new thing. Especially now, when we are building applications that are going to be maintained, when we are building applications that are going to be around for a few years, it's also just not feasible and sometimes it's not right. You just got to make that decision maturely rather than I want to use this or I want to use that, which can be tough. But ultimately, you want to deliver the value. Try Elm at Elm-lang.org/Try. You can try on the browser and see how you go.

The official guide is really good. There's also Elm-Tutorial.org, which is kind of a complement to the official guide. Pragmatic Studio have released recently an updated course for learning Elm. James Moore at KnowThen.com. He has a couple of Elm courses, one is free introductory and then there's a paid course, which goes into deeper topics, whether text or whether video, whatever your thing is, there's resources available to get you to the point where you'll be able to make a decent decision.

CHARLES: Well, fantastic. I'm certainly excited. I haven't dip my toes in Elm for a while and I'm actually, after this conversation pretty stoked to get it on again. I hope everybody else does. Thank you so much, Philip for coming on to the podcast. This was just a fantastic and enlightening conversation.

PHILIP: Not at all. It's been an absolute pleasure. Thank you.

CHARLES: All right. That’s it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that is engineered to make your UX dreams come true.