Enterprise Healthcare Platforms & Analytics

Frontend Development: Murphy Randle with Day One

Show Details

Today, we have Murphy Randle on the show. For those who don't know who Murphy is, he heads up the front web work at Day One. We'll cover topics like picking a framework and the business decision-making process.

Once again, thank you for tuning in, and let's welcome Murphy.

Show Transcript

Carlos: Hello everybody! Today, we have Murphy Randle on the show. For those who don't know who Murphy is, he heads up the front web work at Day One. How are you Murphy? It's a pleasure to have you. How are you doing today?

Murphy: Great, Carlos. Thanks for having me on.

Carlos: I was excited to chat with you because during our pre-interview I felt that there is lot of people that might have been in similar situations as you have been for the last couple of months, picking a framework. So I thought that bringing you on to talk about your decision making through this process would be very insightful.

Murphy: I'm glad to talk about it. Where do you like me to start?

Carlos: So before we jump on that, tell me a little bit about yourself and how did you get started in software?

Murphy: Alright. So I got started in software pretty young because my mother homeschooled myself and my siblings. And they were technologically advanced family from the start and when I say they, I mean my parents. They always cared a lot about providing us opportunities to educate ourselves in preparation for the future. And so they spent time and effort getting software at educational prices for us and tools for doing video capture and things like that. So my brother got way into video editing and dabbled a little bit in 3D animation. And then 3D animation ended up being something that really called to me. I think I was about 9 years old or so at this time. And I started doing that for many of my free hours in the day and continued to do that, and to love doing 3D animation work until college, all through high school then into college. And then, I happened to be growing up next to one of the top universities for animation in the United States called BYU, Brigham Young University. And so I got into the animation program there. Not so much because of my artistic skills but more because of the time that I've donated to working on their senior projects. They needed a lot of help and I had time to give so I just put in many hours per week in the lab. And while I was there I ended up doing, and started to get into programming for real. I had done a little bit in high school, I had dabbled in enough to think, ?Boy, I'll never be a programmer and this is hard stuff.? And then I started to do some more realistic stuff to help the films that I was working on at school get done. And I ended up really falling in love with programming there.

Carlos: Ow, how did you end up, you had some work with, was it Disney?

Murphy: Yeah, Pixar.

Carlos: With Pixar, right? That's impressive.

Murphy: They are close to be in the same thing now. They're separate companies but still they share a lot of assets. So, yes, Disney bought Pixar and I got to work with them. They were coming to mentor to BYU animation program. And so they would send a couple of people out regularly and they would work with us and also look for people to do internships. And I ended up actually leaving school for a couple of years to go and serve mission for my church. But when I came back, I got back in contact with them again. And they were still interested in me doing internship so I accept it and I went and I did an internship in Rendering Technical Director position for six months. And I worked on the film Cars 2, that was my film, which is unfortunately probably the least good Pixar film that there has ever been. But I had a good time with it anyway.

Carlos: It's seems interesting to have in your resume that you are part of the Cars 2. That's impressive!

Murphy: It is fun also to be able to tell people that, I'm like, ?Oh, I know Lightning McQueen. He is my friend.? And then the kids go, ?Oh, that's so cool.? You know, that's fun.

Carlos: I like that, and so from there I guess, I've heard the story a lot by the way in terms of people going into animation and somehow be able to use those same skills to engineering. What was your step after Pixar?

Murphy: Yeah, so that's the transition point right there because at Pixar I got the opportunity to get a lot deeper into programming and software design than I had ever been. And I started to discover that I was more interested in programming than I was in purely doing animation. I came back to school and started to delve deeper into the programming study and considered switching majors over to Computer Science. But that didn't end up working out with schedules and finishing school so I stayed in my Animation major. But I took a lot of Computer Science classes and I really started to fall in love with software design with just normal Software Engineering, not necessarily tied to Animation. And the real transition point came when I was looking for internships again while still in school. And in a company called Space Monkey, local to me here in Utah. And they didn't offer me an internship but they did offer me a full-time job as a web developer, as a Python web developer. And I was way into Python because that's the language for animation at the moment or at least it was when I was doing that. So I took that job and that's when I started to really get into the web stuff. I kind of fell far field from the animation world. So I'm not really a part of that world anymore so much but more of the web programming and software engineering world now.

Carlos: Well, so much so, that you spoke at ng-conf earlier this year.

Murphy: That's right, yeah.

Carlos: What was your talk about?

Murphy: I talked at ng-conf about Elm, about a language called Elm which your listeners may or may not have heard of. Do you want me to talk a little bit about what of it is?

Carlos: Yeah, we'll get into that in just a second. So I know that recently you have a little bit of a job change, so I think it's probably the core area of what we are going to be discussing as you now working at Day One which is an app that I've used for years. I loved it. How do you like it there? How it has been?

Murphy: It is a fantastic company. I really have enjoyed working at small companies a couple of times in the past years. It's just, it fits me well. And there are about around ten employees here, 10-15. I'm not just counting in my mind at the moment. I should know us all in number. But that small, single team feel something I really enjoy. And I just came from another company that I also love that was a very different environment called Koalian. That was corporate software for higher education purposes. And so this is a very different from that team. Could you hear the cheers in the background?

Carlos: I can.

Murphy: Yeah, that's the whole office cheering for something.

Carlos: They probably just play some code or something, something went live.

Murphy: I think Apple announced something exciting. That's what happened.

Carlos: Oh, I think Apple is announcing something today. Alright, I'll check that out later. Alright, so this kind of the area that now we start talking about, the meat of this episode or the core of this episode for the vegans out there. The choices that you're making in terms of framework choices because you are heading up the frontend web components or the frontend web side of Day One. I make sure that I don't call it components because people then get confused. So you've gone through a lot of decision making throughout this process. I know you were thinking about Elm. You are thinking about, you know, few other frameworks so what I like us to go through today is just tell me a little bit about each and you know, we'll talk about Elm, and we'll talk about some of the other options you're considering. And I know that you're close to making a choice, so maybe you can also kind of guide us through the ?Whys?. So, let's start with Elm for those who don't know what Elm is. What is Elm and why is it important to you?

Murphy: Elm is aesthetically type language. So let me throw in really quickly here that this decision interesting because it's not just about framework but it's about frameworks and languages. So this isn't just a JavaScript framework idea. It is ultimately at the core of that but it's also how we interact with the JavaScript framework so that's where Elm comes in because Elm is not React. You wouldn't be using React, or Angular or Vue or anything if you are using Elm. Elm has its own language which also comes with its own framework for frontend web development. And that framework is built upon the same kinds of technologies that React has built upon and Angular also. So they're kind of similar at the core. They have different APIs, they have different approaches. And Elm is not only a different framework but an entirely different language that compiles down to JavaScript get sends the browser. Does that make sense?

Carlos: Makes a ton of sense. And why do you personally like Elm? What about it is compatible with your taste if you would?

Murphy: I really love the functional approach that the language takes. I started studying Haskell about almost two years ago now at my previous company. We had, one of the team members, he was a big Haskell fan and started us all learning about it and it stuck with me. I really enjoyed it but it was also extremely difficult to try to get anything done, or try to start, or actually understand the concepts that Haskell gave to me. Haskell is kind of a server side language. It's been around for a long time that embodies many of the functional programming paradigm and design patterns that are being talked about right now in the React hype and a lot of the blog article you might be seeing around. There's a lot of talk about functional design and about being able to reason about code, etcetera. And so a lot of those things originate from ideas that were implemented in Haskell so I spent a long time reading books and trying to compile Haskell programs and not getting anything done because there are a lot of advanced concepts especially mathematical concepts that I just didn't have the context for. And so I wanted to do it but couldn't get anything done until I ran across Elm and my co-worker said, ?Hey, you should check this out it's pretty neat.? And I say, ?I don't know. Looks like kind of a weird thing.? And then I pull it up and started to use it and in just within a few hours I was actually doing things which I hadn't been able to do in months since studying Haskell. That was exciting to me because I could use those functional patterns that I was learning about and I was excited about, and didn't have to be terribly confused by a lot of the more advanced abstractions that you run into with languages like Haskell. So that's part of what Elm's approach is. It uses a lot of the same concepts that functional language like Haskell use. But it on purpose clears away jargon. It clears away a lot of the language that an object oriented programmer wouldn't be used to and designs the language around a set of simple core attributes. That's probably the wrong way to say that, around the simple core principles of functional programming. And it gives you a language that it's easy to apply those design patterns and it was easy to learn to.

Carlos: And do you think that because of your preference for functional programming. Does that also kind of lead you into React?

Murphy: Yeah, certainly so, we used Angular at my first job, the Space Monkey. I love it and I thought Angular was fantastic. Angular has got a lot of great design patterns around it, but it's also very object oriented, very kind of classical if you've come from a university study in the recent 10 years I think. But React being someone new takes a more functional approach to designing frontend user interfaces. Its ideology is kind of Model In View Out, and so you take in a model you render it purely. You put out an output and then you, it reacts to events that happen. You change the model and then you re-render the view again. So it's not doing the same kind of dirty checking like updating parts of the state and re-rendering parts of the view like Angular does. It's more of an entire approach where maybe you update, keep all your states in one place, you update a piece of it and then the whole UI re-renders and it tries to do it intelligently. No, that's not, you don't have to work with React that way but that's generally kind of accepted pattern right now.

Carlos: So was that a reason why you didn't value or you didn't add to your balance Angular JS into the mix.

Murphy: I think that the reason I didn't go back to Angular was, well, I moved to a new company. From Space Monkey I moved over to KoaliCo and I was on a very small team there. We were able to make tech choices there because we were just starting things out. And React was the new hotness and it was super fast and at that time the kind of JavaScript propaganda was saying, ?Angular is dead, React is the thing.? And we were all excited about that too so we dove on the React train or jump on the React train and started to use it. And while we were doing that, I told you about a co-worker who introduce us to Haskell. He was able to teach us a lot of these functional design patterns and those were exciting. They made a lot of sense to me and so I never really had the chance to think, ?Well, I wish I could go back to Angular now.? React really clicked with the stuff I was excited about that time and it really made sense to me, it's API. I think Angular is super neat. But at this point I probably wouldn't be able to go back to Angular easily and get a lot done because of the way my brain has changed in its understanding design patterns.

Carlos: Yeah, and it's exactly that. It's kind of how you function, how you work kind of dictates what to work with. Of course there are reasons, there are people that will say, ?Oh, this is better here or there.? But I think there's a lot of subjectivity around it. I'm always curious though about the framework choices and the way that people weigh in the different factors. So, last time that we talked you were kind in the middle of this and you hadn't made a final decision. We'll probably do the reveal at the end but I don't think anybody has surprises. Well maybe there's a surprise here and there. We haven't talked about one that might come out. Did you factor in any, something such as ramp up speed versus community support as a factor of choice? Not only for now but looking into the future, right as you think of adding employees and so forth.

Murphy: Yes, so those Carlos, those are the really stressful factors. Those are the ones that really matter are things like what you mentioned. Because there is language design which is fun and exciting. But languages can be designed and argued about until the cow has come home. But there are infinite combinations of possibilities and language design. And infinite opinions about which are better. I think those are very subjective so. It's not so much about language design this decision. As it is, it's kind of a person, a people problem because it's really be able to hire people if we need them when the time comes around will this technology die before we can get to market. Will it die before we're able, you know, while we're trying to support it and before we're able to move to something new. Will there be enough support from the community that we won't have to spend thousands of extra hours implementing tools to just support getting our tool out in the first place. So those are all I think the big considerations versus something like, ?Oh, does the language have for loops or something like that?? So those were the thing that we were kind of stressing about and talking about now. And I was stressing a lot about as I was trying to make this decision over the past couple of months.

Carlos: So let's just bring it out there. The one that also made the cut though and you're using it in your stack is Scala JS. So, you know, we all, no not all, but a lot of people have heard about Scala JS. But what is this Scala JS? And why did it become a contender?

Murphy: Yeah, that's, ok cool. Let me first mention the other considerations we were making too because the obvious possibilities were just normal JavaScripts with React and Redux. Those are very popular right now. And we were doing that at Koali but I found JavaScript pretty difficult to maintain after a year and a half of working on a project, and growing that project, and having to change that project. I found that often without something like a strongly typed compiler to help me re-factor the code in JavaScript I was breaking things a lot. And so, it takes a lot of discipline from the developers. Self discipline to make sure that the test is comprehensive and that things are inline before JavaScript can easily be re-factored. And so, that was a big consideration that I had. I knew I just said that we are worried about people problems. But I think this count as a person problem because if you have a compiler that actually capable of helping you understand your program and re-factor it. That's going to save many man hours of work. And not just work but also stress and pain for the developers who are writing. So that's a big part of it. I really want to go with something that had a static type checker. And there were options like TypeScript and Flow and I worked with both of them. But I don't think we have time to talk at the moment as to the finer details of why I didn't think those would solve my problem. The other options we're Elm which I've used and really like, PureScript which I also have used and I really liked, and Scala JS which I'm just now kind of starting to get sink my teeth into. And as you said that's the one we ended up going with. So the reason that Scala JS even came up and was an option was because all of our backend code is already in Scala which is the functional language that has advanced type system, aesthetically compiled, run on a JVM, it's a super neat language and it is supported by quite a few companies. There are a lot of people so it's got a nice big community around it. Not as big as Java but it is pretty big. Big enough to be comfortable with so that came out as an immediate option. And Scala JS is a project that takes Scala code and compiles it to just JavaScript. So it makes a little JavaScript library that it can use at runtime and it bundles your code into it and it ships it to the browser. And you're running JavaScript that's been written through Scala. And a lot Scala's libraries are even compatible with Scala JS so you can just pull in one popular library called Scala Z or Scala Zed if you're from Canada or other places. You can pull that right in and just use it even though it's not a JavaScript library. So that's a pretty cool option and there are some neat wrappers for React too. So that was one of the decisions there. That's the framework decision as you are saying, ?What framework are we going to go with?? I was pretty confident from the beginning that we wanted to stick with React because I've used it for a year and a half. I'm kind of, I'm used to it, like it. I think it has a good design and takes a good approach. I think Facebook is good at shipping updates and they're pretty solid about supporting and so I feel pretty confident with React. And I wanted to keep that as the thing that actually rendered my views to the page versus something like Elm. Even though I really liked the language Elm, I wanted to opt for a more widely community supported rendering framework than Elm has. And not because necessarily it's better but just because of that community support factor and the familiarity in when hiring people. Many people already know how React works versus having to learn the way Elm works from the ground up.

Carlos: Which is somewhat of an interesting subject that I have to touch on a few times recently, about the value of hiring engineers that are good engineers versus hiring developers that are just good in one framework. And I don't mean to offend anybody by calling them developers. It's just that there's a different mindset when you're an engineer who can grasp multiple frameworks, multiple technologies without, because you have that basis, right? What's your opinion on that?

Murphy: I think that's a good distinction and I'm working to try to make myself not just somebody who is stuck with a certain tool, or has a certain skill set in one specific implementation or tool but rather someone who has a good understanding of Computer Science as a field. And I think that we look to hire those kinds of people too, people who understand programming in the large as far as, ?Oh, how do we approach solving problems?? It doesn't really matter so much with what language of choice at that time but can quickly learn the syntax, semantics and adapt to it. And begin to implement the age old Computer Science approach to solving problems, right? So that's what I look for when hiring people. Unfortunately, I think those are the harder people to hire because they are the most sought after in, and the most difficult to identify. Because how do you know if someone is able to do that until you've worked with them for a good chunk of time. And can see the way they approach problems and handle new situation. And aren't just nervous in a whiteboard trying to reproduce some pre-conceived thing, you know.

Carlos: Right, no, no, no. It is hard, I would say that we have to figure out a way to bring that into your process because it is that important. So when do you think this project will be done. I know you can't give me actual dates but what's kind of the timeline for it?

Murphy: That is a great question and at this point it's completely undefined because we are about to take the first steps into making the web client happen. So, I'm sure that the plans are going to change a lot in the next few months as we kind of flash out what it is and what it will mean. So the goal is to make a web app. I'm not sure how that's going to end up. If it will be even be the same thing or if it will be an electron app or what not but at least we're getting started. And we've chosen at this point to move forward with Scala JS and React in the backend. And then if we need to drop down to JavaScript for speed sake or whatever it may be, we could do that. Now that's something that we have also reserved the right to change based on what we discover as we move forward but it seems like the correct decision to make right now because it's already part of our team, Scala is. And we already have the main knowledge and expertise there. That's probably the biggest reason.

Carlos: That's a pretty good answer because you're sudden on your ways but you're not, you know, hard coded into it. Like you're going to evolved in the process. So I know you've been big on conferences, any new conferences that you're going to be chatting or talking at soon?

Murphy: Yeah, next stop Elm Conf which is a mini conf connected to Strange Loop. That's next week so I'll be talking there on a fun topic where I'll put together a crowd sourced music player app that reads music from Twitter. And hopefully I'll be able to live demo it and not have things crash in front of everyone.

Carlos: That's sounds pretty fun. Alright, so well the last two questions. What's a book that you would recommend that you've read based on some of these subjects we discussed today?

Murphy: Can I recommend five books?

Carlos: Oh yeah, please.

Murphy: Ok, because I was thinking a lot about this. So, in order to learn the things that I'm playing now, it's unfortunate that there's not at this point any one book that I would recommend. But I would recommend the combination of the following books. Number one I think would be Haskell book, and just Google ?Haskell book?. I think it's like haskellbook.com. So that's an excellent introduction to functional programming. What Haskell is, kind of that whole world of things. And then there's a book called Functional Programming in Scala JS, distribuited by Manning. It's got a bright red cover. That's an excellent book because it talks not just about the language Scala but it also does a really good job of approaching functional concepts in an understandable way. And also teaching you to kind of understand how to make your own functional designs, your own patterns in a functional way and why that's useful, so that's a great book. The third one would be, and these aren't into any particular order. I've been jumping back and forth between these books over the past years so, Learn You a Haskell by, I can't even say his name. I'm not even going to try. But if you just Google, ?Learn You a Haskell? you'll find. And it's free to read online and it's an excellent book. It's a little more advanced than the other ones. I mean, it gets advanced quickly but the first few chapters are really great way to start understanding what functional programming is. So there's three, let's see if I'm going to add up to five. Maybe I have the wrong number in my head. Another one is Grokking Algorithms which is an excellent book distributed by Manning. And the author is very intelligent and he also is quite good at doing these very cute little illustrations to help his concepts. So that's a book that goes through a number of introductory algorithms and teaches them in a very understandable way. And also the writing is excellent and quite entertaining too, so that's a super super book. I would highly recommend that one. Okay and the last book is PureScript by Example by Phil Freeman. And that is a book available on Leanpub. You can donate to it or you can read it for free. And it's a full length book about using PureScript to develop web applications which is very much like Haskell. And the book contains a lot of gems as far as instructing on functional design patterns and buildings stuff with it and learning about monets and things like that. So that's my suggested reading list for right now.

Carlos: How long did it take you to read all those five books?

Murphy: The trick is I haven't read all of them yet. I've been taking them piece by piece and kind of mixing them together into a smorgasbord books board in my brain so I'll jump back and forth between them and read a piece of a chapter here and there as I'm trying to implement a concept in it. It's really helpful to get all of the different perspectives. I think much more helpful than just sticking with one of the book's perspectives.

Carlos: I couldn't agree more. I read often, actually a lot. But sometimes, you know, what happens when I change. Let's say I'm reading about topic A, and then topic A is covered differently in Book 1 versus Book 2. All of a sudden by the time you're reading Book 2, you forgot about Book 1. And I'm trying to like figure that out because I don't want to stop reading. I want to read more but I want to, it's like, it's not really reading, it's studying that we got to be doing these days. Murphy, and this has been an amazing interview. I want to thank you so much now but I do have one last question which is probably the most important question. How can people find you? How can they find your work? And are you guys hiring at Day One and how can they apply and all that?

Murphy: Great questions. I'm reachable on Twitter my handle in Twitter is splodingsocks, S-P-L-O-D-I-N-G Socks, and I'm more than happy to chat with anyone there. Or on GitHub, I have the same username. I'm also reachable on the Slack Channel, a number of slack, I'm on the Elm slack and have the same name there if you want to start to talk to me. And Utah JS, if you're local to Utah, there is Slack Channel just for Utah people. It's a functional programming slack, I'm there too. So I'm pretty findable. And also, I'm an instructor with egghead.io and I have some videos of Elm if you want to go watch them. I have plans to make more video soon about similar topics. So that's where you can find me. And Day One I believe will be hiring an iOS developer soon. And potentially web developers in the future. But at the moment I think I'm the lone ranger web developer dude. But that could be changing in the near future. But if you do iOS and you like Day One, we'd love to hear from you.

Carlos: Murphy, once again my friend I want to thank you for the wonderful time and an amazing interview.

Murphy: Great! Thank you so much, Carlos! I really appreciate it.

Carlos: Thank you! Bye bye.

Murphy: Bye.

Building Credibility and Influence as a Leader: John Sadler with Agilent Technologies
Listen to episode