JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

231

231 JSJ Codewars with Nathan Doctor, Jake Hoffner, and Dan Nolan


3:23 Discussing the purpose and aim of Codewars

7:30 The process for building a program with Codewars

11:07 The UI and editor experience

12:55 The challenges faced when first building Codewars

14:23 Explaining PJAX

16:54 Building code on Codewars

21:24 The expanded use of KATA on Codewars

23:11 Practicing “solving problems” and how it translates to real world situations

34:00 How Codewars proves out the persistence of coders

36:41 How Codewars appeals to collaborative workers

44:40 Teachable moments on Codewars

49:40 Always check to see if Codewars is hiring. Codewars uses Qualified.io, which helps automate the hiring process.

PICKS:

Marrow Sci-fi book

Uprooted Fantasy book

“Write Less Code” blog post

“The Rands Test” blog post

Five Stack software development studio

“Stranger Things” on Netflix

Angular 2 Class in Ft. Lauderdale, Discount Code: JSJ

Lean Analytics book

Code book

Datasmart book

Letting Go book

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Joe:               Hello everybody and welcome to the episode 231 of the JavaScript Jabber podcast, today on our panel we have Jamison Dance.

Jamison:       Hello.

Joe:               I’m your host, Joe Eames, and we have as our special guests Nathan Doctor, I can’t remember who else, they’re on the other side.

Nathan:        Jake Hoffner, and then Dan Nolan. We’ve got three of from in the Codewars team.

Joe:               We’re here to talk about Codewars, but before we do I think it’d be good to have everybody get a nice introduction with you three and your backgrounds. Maybe you can tell the story about what Codewars is and how it came about.

Nathan:        Interestingly enough, Codewars got kicked off at Hackathon. It’s startup weekend, that’s where Jake and myself had met. I’d been studying architecture, I got into a lot interior design, prod design and technology because of that and Jake have been.

Jake:             Yeah. I’ve been [0:01:12.2] for about twelve years at that point, I was self-talk, I’ve been doing it since I was, I started myself when I was nineteen, I’ve been working professionally since I was 20. This was my second Hackathon Weekend that I went to.

Nathan:        Yeah and interestingly enough, he had won his first one too. We went up there, presented this idea of creating a space that allowed the Hackathon environment into the online space in a small right size chunks.

                    Instead of taking a whole weekend to partake in a project, you could partake in a co-challenge in a course fight and there’s a competitive aspect too and educational aspect to it. We built out a prototype over that weekend, created feedback from all the developers there, lots of excitement.

                    Actually had a working prototype where there was these challenges and people had to compete on them and that’s where everything kicked off from. Won from there and then Dan joined us about…

Dan:             About a year ago, about sixteen, some few months.

Nathan:        Yeah.

Dan: I was a huge fan of Codewars. There were definitely times where I wasn’t super confident in my coding ability but through Codewars I started to, I wasn’t sure exactly what I was going to do, I initially came in as a C Sharp developer and I was learning, I was getting there but I never felt super confident in my coding ability until I started taking a lot of challenges on Codewars and I felt really confident. I started to do all these challenges and picked up on these different ways in doing things.

Nathan:        He really showed himself off in the community there and that’s actually how we got in touch with him. Planning up for our whole team is, other than me and Jake, not in the beginning has come through Codewars, it’s kind of awesome.

Joe: Yeah that’s super cool. You mentioned the educational aspect of it, what do you see the purpose of Codewars? It seems like it can do a bunch of different things, it could be for interview prep, it could be educational, it could be for recruiting, on the other side it’s just a fun hobby type thing. Is there one main role that you see it fulfilling?

Jake: It’s kind of a coding gym.

Nathan:        Yeah. Great question.

Joe:               Like a coding gym. Did you just make that up? Because if you did that’s amazing. Nathan, you are amazing at elevator pitches.

Nathan:        The challenge format, Dave Thomas coined that the concept took at it and that was something that grabbed us where we started to do this. We actually didn’t know what a code kata was so we started to build it but after doing a research, we realized that what we’re doing was basically code kata and then we already had the name Codewars, all these themes came together. Code kata, dojo, we had this cue system where you rank up but felt same as you won martial arts dojo. I think with code gym, you go dojo, it sounds like code academy awards only for beginners or something else, it’s only for more advanced developers.

                    It’s like whether you’re a white belt or a black belt, you come with this thing and everyone learns from each other, everyone can show up to the same class and be able to branch off into the more mastered martial artists can go and work together on some stuff and then the more beginners can work on other things but then, there’s learning or they can work with each other and they can learn from each other.

                    That’s what Codewars is where we don’t really guide you through educational content in a specific course or route but it’s more about challenging yourself and then interacting with the community and learning from each other.

Dan: Code concepts, there are code challenges that started out from the beginning at that Hackathon where it began and expanded out now. All that content, all this code challenges in the community are created by the community, vetted by the community and then ranked in terms of difficulty, what actually they help you with improving on all by the community itself.

                    It’s really cool in that sense that that educational component, we think is created at different type of format. One where there are no teachers, everyone in the community is equally able to contribute and those contributions are held up and proven by the community itself. It also completely immerses so everyone’s learning, improving on their coding skill actually by doing that and completely self-directed too.

                    They take these challenges, you can have one that’s five minutes all the way up to five hours, different difficulties depending on whether you’re on your coffee break or you’re really looking to improve your skills in the specific area or prep for an interview. Those kind of be the event like you said, there’s so many use cases within this coding gym.

Joe:               Right. That totally make sense.

Jamison:       There are a lot of these kinds of things out there, there’s HackerRank, there’s Exercism, there’s that graphic one where it’s like an RPG type of thing.

Nathan:        It’s called CodinGame.

Jamison:       Yeah, probably. I can’t remember the name but you should get their name wrong so you don’t send traffic to competitors. It’s like coding potato or something. What’s different about Codewars compared to the other ones that are out there?

Nathan:        One of the big things is we’ve gotten really strong buy in from our community. The people that create the content in the community have extremely been devoted to the system and the platform but also to just creating this content in the way that gives back.

                    All of that content, whereas like so many other sites, there is content created by the community it’s at a different looking Codewars as far as the [0:07:19.9]. But beyond that, one of the biggest differences is our testing frameworks.

Dan:       Yeah. When we started this, you mentioned HackerRank and there’s a bunch of other ones and they all work in the same basic concept which is they’re standard in and standard out of the program.

                    If you want to  test something you passing this little format where you have to read in standard in and it’s something like the first line is like a number that you have the parson to it and that is the number of test cases. Then the second line is maybe number arguments that are within a function or something. Then the third line is at the beginning of the test next cases.

                    You have to almost write a program just to write the program. You have to part standard in and you need to write everything to standard out and then because you’re writing everything in standard out, you wanna write console messages or trying to bug, that affects your results a little bit.

                    It was a very unnatural experience which I felt was against the point. The whole point is you’re trying to do this challenge. It’s like a snippet of what you normally do in your daily work if you’re working on something really interesting but maybe you’re not working on something interesting, maybe you’re working on the same thing over and over again which you love to and you wanna take a fun challenge but you’re doing it in a format that feels very awkward to work with.

                    We were like why don’t you just use test cases, that’s what we use to test our code anyway, why would you come up with a totally different format for testing code when you can just use test cases? It’s like with before. Of course the problem with that is that it’s actually the path of most resistance in a lot of ways because it required us to build out a large number of additional things.

                    Suddenly you can’t just write test cases for one language and it works across all languages. You need to have test cases for each individual language and you need to, probably every language that you support, you have to come up with a test framework to use for that code language and then you need to make sure the output works with your outputs.

                    It became a lot of work but the result is that you have something that’s much more natural to what you would do normally. If you wanna use PHP, you can use PHP and you can test using that.

                    It feels much more natural and it was a lot of effort that went into that but we think that that’s a huge difference between us because not only does it feel more natural but we could also test a lot more because we’re actually running the code, we’re actually testing the code inside of the app that the code is running in so you can do things like transport things that can go well beyond just spitting out a specific output.

Joe:               That makes sense.

Dan:             We hope to expand them on that too. You can do things like render charts or render images, or render HTML. You can have interactive things. There’s actually a creator perspective and it goes a lot of potential for what this product can eventually end up doing.

Joe:               Sure.

Nathan:        A lot of that really came down to creating the most intuitive, familiar developer experience. Putting in a format that you’re used to in your daily life and not forcing into this awkward round place that you have to go through to just take this challenge which can get really frustrating.

Jamison:       Yeah. I have eight kata units, whatever KYU stands for. I’ve done one challenge three months ago and I didn’t even remember that. I’m totally a user. I want to ask a little bit about just the UI and the editor experience and how that’s built.

                    It seems to me like maybe five years ago the standard for what an online code editor looked like and functioned like was pretty low and now there’s a ton of them across all different products and websites. Was it relatively easy to build, is there a lot of custom trickery you have to do to make something look and feel like a natural editor in the browser?

Dan: Luckily there’s two major open source editors out there, there’s the ace editor which is Cloud Nine I think is their name, they just got bought by Amazon and then there’s Code Mirror which is the one that we use.

                    These days, you can probably use Atom too, I don’t know if it’s embeddable on a web page or not, I haven’t researched that. It’s HTML driven so imagine it probably it could be. Fortunately, there’s a lot of work that go in these projects and that takes care of a lot of the work. We’ve had to expand on those a little bit to increase the file mapping and some of them support things to make it feel more natural to certain people. Also there’s a little bit of an IDE there, there’s an output panel.

                    We put a lot of work into making the results look like actual test cases and creating shortcuts and subs so that you can switch between different editors and things like that. Certainly a lot of work went into it but I think that the community is really fortunate to have thing likes Ace and Code Mirror which are out there and we’re all able to use.

Joe:               Technically, when you we’re building those, is there any specific challenges that are quite interesting to solve?

Dan:             Yeah. I think the first challenge that came up with it was that when we’re first building this, what Codewars is today, it’s not like we had a vision that’s where it was. Originally, we were picking out different bunch of ideas and originally we’re thinking this is going to be more of a side project based thing. The whole Hackathon idea was originally part of the goal.

                    We ended up choosing architecture that wasn’t really the right architecture for what Codewars has become. It was a Rails app and we’re doing everything. It’s on a single page app, everything is being rendered service side. As things have had changed and the requirements changed, we went with what we had because we don’t have the option to go back and change things.

                    This remedy is like four years ago. I think Angular was just coming out and there wasn’t necessarily a lot of, I’m trying to think of the what was even the hotness back there.

                    We have this and that, there’s a whole PJax concept which we use a lot, we expanded upon that so that everything’s PJax based even if it’s a submission, there’s a lot of iteration on what you can do.

Jamison:       Can you just talk about what PJax is?

Dan:             PJax stands for push plus ajax. The basic idea is, GitHub uses this by the way, the biggest calls that you have in a service side rendered app is the actual loading of all the assets. Every time you change the page, it has to reload all the scripts, it has reprocessed all the scripts, it has to reprocess all the CSS, it has to recheck if anything has changed. That can be a pretty expensive operation.

What Pjax does is basically uses HTML5 push state so that when you change the page, it doesn’t actually re-render the whole page, it uses an ajax request, it grabs the whole page. It rips out all the header stuff and all the things you don’t need and then just replaces the body with the body of the server or a new body from the server.

                    Basically, it hot swaps everything and you don’t have to incur that the cost of removing all your scripts all over again.

Joe:               It sounds like turbolinks, does turbolinks like Pjax implementation?

Nathan:        Turbolinks is the simplified version of PJax, that is where it came from. PJax was just like a open source project and they incorporated that. They simplified it though, actual PJax, you can do things that you can say only reload this section, basically re-render the whole page but only swap out this section and then it also supports codes as well.

                    With turbolinks, you can only reload the entire page and it only works with Git requests. We’re using it back then, I know that it’s been with Rails Five, Turbolinks has been improved somehow. I’m not really sure how it’s improved though.

Jamison:       My impression of PJax is it’s like a stop gap for apps that are server rendered but want to move to a more dynamic model but you don’t want to rewrite your whole app necessarily. You can use PJax to get some of the benefits.

Dan:             Exactly, and it works for activity. GitHub is the biggest site that I know of that uses it. I don’t think anyone really complains too much about their UI being slow. I imagine that there’s probably a ton of work that goes into optimizing everything so that it work that fast while still using PJax. It does work pretty well and it has the advantage of having better SEO compatibility.

Jamison:       Sure. I want to ask about the infrastructure for running code because that seems like an interesting problem that you could solve in a bunch of different ways. How does it work for you all?

Dan:             It was. When we first started working on it, the initial languages that we supported was JavaScript and Ruby. Node already has Sandbox built into it and then I found a J Ruby gem that had a Sandbox capability. They’re very limiting and it worked well enough, what we’re trying to do in the beginning.

                    They both function wholly separately and we basically had little Node apps running on Heroku for each separate language and then we would stitch it all together between our route’s app.

                    They started come out on the same time but it was very young and took us a lot of switch over to it. But now we fully use Doctor for all of our languages. The project is actually open source for the core aspect of it. We had a lot of contributions from the community for adding different languages. We use that in an interesting way than I think, as far as I know, anyone uses it.

                    Every single time you run code, you use a container and then we kill that container and then create a new one in its place. You’re always running on a fresh container that’s never been used before. We do that because we allow you to break the fall system and do different things and just want to make sure that people aren’t leaving behind a bad state for the next person.

Jamison:       Sure. It also seems that it helps with security. Running arbitrary code is the giant nightmare of every security conscious person and that’s where your product is. You let people run arbitrary code. Do the containers and making them delete themselves or whatever, does that address the problem?

Dan:            Yeah it does. We also have within the container, we have special users so they don’t run a screw within the container itself just to be extra careful. We wanted them to be able to run amok. If they wanna kill a container or do something stupid with it, it’s fine, it’s gonna get killed anyway.

                    The beginning though was hard because we have the Sandbox things and it was like cat and mouse game because we have a bunch of our user were just kata that were just meant for trying to hack the system and break it and then try to beat it.

                    I would be like I will fix it. We had this guy who’s just doing the crazy, I still up to this day do not understand this JavaScript code. It was alien code but the things he would do to get past our sandboxing, it blows everyone’s minds, people were learning so much from it.

Nathan:        It was really exciting at some point. They understood how we were stitching codes together or at the time I wasn’t on the Codewars team, and Jake was defending against a lot of this himself with help from the community and people were doing some really smart things. They will figure out how to take the code and because we’re stitching it together, they could turn it into a string, not JavaScript necessarily but you could turn the entire app within two strings so they could to things like turn what should have been JavaScript into a sequel string and so you’re actually executing it in a sequel or executing in batch, do all these crazy creative things that you can do otherwise if you didn’t leave this open space for you to actually execute.

Jamison:       It seems like it would really draw a certain kind of person. I have one friend that would just dedicate their life to figuring out, not maliciously at all, but how can I break this in a wonky way?

Nathan:        Yeah. We had a number of users, that was the only reason for using the site, was just trying to break it, they were getting HTML.

Jamison:       Yeah.

Nathan:        I feel like, “Alright guys, fixed it.” And then fifteen minutes later we’re like, “Oh, broke it again,”

Jamison:       Yeah, that’s true. I haven’t thought about that. Lots of product companies complain about their users. This is like a special kind of complaining about your user though. It’s not like they can’t find the big red button that’s super obvious, it’s like they took down our server and cackled with glee.

Jake:             We love it though. We all are. We all learn together.

Jamison:       Sure. The hardest kata is defending against your curious users.

Nathan:        There were some of the most interesting kata too for a little while. It’s very outside of the realm of what Codewars supported but still an interesting use case.

Dan:             Yeah. One of the most interesting kata I remember I tried to take was somebody actually created, there’s this idea of a detonating bomb and you didn’t know where it was but you have your kata and you have to figure out how do you disarm it. You didn’t know exactly what you’re supposed to do but if you start to look on the global scope which I didn’t know how to do at the time, you can start to figure out, “Oh what kind of variables do I have available to me.” I started to look inside there, started to look at the keys, started to do different things to figure out that the main object is frozen which I didn’t even know that you can freeze objects in JavaScripts.

                    All the while, I took one of my coworkers and we were just working through this after work and we’re just, “Wow, you could freeze stuff in JavaScript, this is so cool.” It’s just going right the ruin, figuring it all out, super cool.

Jake: Yeah. They make a scavenger hunt by trying to figure out where this hidden variable is that has the answer. I think a perfect example of what you can do with our format of where you’re running tests inside of the process instead of just outputting, you can’t ever do any of that stuff if you’re just using standard in and standard out.

Jamison:       Like I said, I haven’t done a ton of questions on here but I glanced through them and it’s also from my experience with this other kinds of sites. There’s a certain style of problem that fits well for this. Whether generally self-contained but small enough to be solvable in a couple of hours but still interesting.

                    I feel like in my experience in just data based software development, those kinds of problems are pretty rare. They feel artificial especially relating to interviews. Do you think experience and practice at solving these kinds of problems translates directly to just general software development?

Nathan:        We tried to. We definitely know what you’re saying because a lot of these problems, especially ones that are better raised during interview questions, they tend to be very computer science driven and then things that are theoretical but you never do in your daily work.

                    That’s part of the reason why we try to expand our format with different things is that there’s certainly computer science questions on the site that fall from that category. We definitely try to expand the code base or the kata base to try to do things that are more real world, that was part of the reason why we went the route we did so that would happen.

Certainly, Dan could speak to how much that has helped him and I think it does apply. There’s the other side of this too which is I think a lot of us, our day to day stuff is, how many time you’re building, maybe you work for a company and you build CRM apps or something, you tend to do a lot of the same stuff over and over again and you don’t feel a lot of opportunity to expand your knowledge in ways that you’re not going to do with your day to day stuff.

                    That was part of the point where as if it allows you to challenge yourself on hard problems that aren’t part of your daily work. You might work on a company for two years but because you’re caught up doing the same basic stuff over and over again, you’re getting really good at basic stuff but you’re getting bored and you’re not being challenged in certain ways.

                    The idea with Codewars was that it allows you to instead of maybe in one week, ended up having one opportunity to work on something really cool and maybe you didn’t even have to work on it because it’s sprint planning and it was like, “Oh, I want to work on that because I haven’t done that before,” and then like, “No, we’re going to get that build.”

                    You end not doing much that week that’s really that challenging to you and helps you grow professionally. It was the idea, with these challenges, you can expand yourself in a lot of different directions. A lot of these things apply to video games or various different types of apps that maybe you’re not working on. They don’t necessarily apply to your day to day activity but they’re willing to help you grow.

Joe:               I don’t really know that I agree with what you’re saying because whenever I implement a code app, I’m always using a B3 and a link list.

Jake:             If you can you can’t do a red black three on the board.

Jamison:       Don’t waste my time. Do you know how complicated our CSS is here?

Jake:               I really like that though because I cannot think back to the number of times—I programmed professionally for 20 years, and in that time, I’ve used to some computer science like data structure, algorithm types stuff to solve a hard problem, certainly less than five times.

                    I interviewed for one big Silicon Valley company, Google, and I didn’t have to do a ton of study and I learned a ton. I interviewed twice, I didn’t get the job, and since then I haven’t used it again. The opportunity to go on do something that’s fun. I could go get online and do some coding challenges that you read about like interview challenges on Career Cub or something without it being gamified. We live in a world where nothing is gamified and I don’t want to do it.

I think your point is awesome. You are expanding yourself and it was a huge detriment to me trying to interview Google because I haven’t done that sort of stuff that they interview on.

Joe:             Absolutely.

Jake:               Being able to do this would be a huge advantage if I done this regularly over my career.

Nathan:        Right. In Google’s defense, if you’re working on their search engine, you probably need to know this stuff. If you’re being interviewed as a front end developer for one of their products that’s probably going to get killed next year, you probably don’t even know that stuff but they apply the same formula to every single person they hire. In today’s hiring climate, that point alone, you should know this stuff just for that and someone unfortunate that, “What are you?” That’s very unfortunate that you have to know this stuff when you’re interviewing for a job that actually doesn’t use that information but there’s a lot of opportunity.

                    Even if you’re not using it, maybe you’re not going to be using functional programming in your job, maybe you’re working with C sharp or something. If you go and learn a functional language, having that knowledge of how functional, a pure functional language works, is going to make you a better programmer whether you use it or not.

Joe:               Oh yeah, absolutely. It’s not just that. Learning the computer science, search and algorithms, you will find more opportunities to use it on your job once it becomes  second nature. They say when you have a hammer, everything’s a nail. But if you don’t have the hammer, then there’s no nails.

Jamison:        Bang your head on the stuff to pound the nails.

Joe:               Just basic things about the performance characteristics of arrays versus hashes and linked lists, those sorts of things. If you have that in your mind and it becomes somewhat second nature, and somewhat at least accessible to you when you need it, then there are a lot of more problems.

                    There’s definitely times in my career, even though I may have done it only five times, there is plenty of other times where I could’ve implemented a more optimal solution or done something but I just didn’t have the tools readily available to me because I wasn’t using them.

                    It will open up your brain more but also it will definitely give you an advantage in your regular day to day job because there are going to be times when this stuff can come in handy.

Nathan:        Absolutely. A double example of that that I can think of, I’m terrible at map but I’m not like I took this time so, the computer science foundation is not really there with me.

In this site, one of the other big features of it is when you complete the challenge, you can then see everyone else’s solutions. That’s a big learning point is that you solve it, you feel like you solved it really, really well and you’re super proud of yourself and then suddenly you see everyone else’s solution and you’re like, “Oh my God, that was so much simpler.”

                    Part of that is the fact that if a thousand people solved it and 500 of them solve it the same way, we don’t want to  have a thousand result you have to go through. We have to have some sort of grouping algorithm that would group these code result together that you have to try consolidated them.

                    I originally wrote it and it was this long, very logic statements. We had someone come in as a contractor to work on few things and I was like, “Yeah, it’s not very efficient, can you work on that part?” He used some sort of computer science, I don’t know what it is to this day, I should probably go learn what it is. It’s been three years since I’ve seen that code but it blew me away. That was something that I never would’ve done, it was very map based but it worked, it was probably a thousand times more efficient than what I was doing and it resulted in better results as well.

Joe:               I really want to know what it is. Is that part open source?

Nathan:        That’s actually component that I think we meant to open source and I might have and just never wrote it really well but either way, I’ll go dig it up and I believe there’s some place for us to post materials from this talk.

Jamison:       Yeah. You got to share the answer now because you left me in suspense.

Nathan:        To build on the idea that you now, using a linked list or something, we’re not going to go and implement the search algorithm ourselves anymore. Knowing these internals is so huge to us, for example, for something more modern and something applicable to JavaScript, you have promises now, and most of the time you used Cue or Bluebird or you got your own promise that they implemented by.

                    Most of the time you’re not going to go implementing your own promise but one of the things that we do have, someone actually created the community is a promise kata where you actually go and you do build your own kata. You find out that really what is it really about like collection of promises or collection of call backs that get called when you go to hit the dot then when the next things happens.

                    Going through and building this and building the internal structure makes it so much easier to understand, oh okay I can chain this, I can do this with this. What is this object exactly? This is a very abstract concept to somebody who’s new and I’ve seen a lot of people at code camps trying to figure out what a promise is and I was just telling them, “Hey man, just build it and you’ll understand what it is.” You’ll really understand, it’s not that complicated.

Nathan:        I’m really about taking things apart that helps you get an understanding for what’s going on there. To that original point, you’re not on Codewars going to be setting up a whole application or dealing with all these other contingencies that are really important part of being a software developer but you do really got those basic language fundamentals.

You’re picking up the internals there especially as you go up to more difficult challenges. You start to pull it apart in ways that may not be something that you use everyday but really contributes to your mastery of it as a whole. Something beyond that too, which we found is that even beyond just the content, and we’ve had kids that have come in there from college where they’re just doing Java or just doing C Sharp and completely picked up JavaScript form the beginning just using Codewars.

                    One of which ended up at Riot Games, got a great position on after that and was super effective in credibility, real world setting with the language. But beyond that too, what we found is that one of the big things behind Codewars as well is it just prunes out the persistence if someone comes to the table.

                    Can you be presented with this problem and then instead on giving up on the first, second, third try, really keep going through it till you find that solution that’s going to make it work even if you take the wrong route the first three times? We found out that that’s one of the biggest indicators of whether or not someone does become successful.

Jake:             It’s the perfect environment for flow. If you’re familiar with the psychology term flow, it gives you the exact, you know what you need to do to be able to complete the problem, you’re given all the input, all the output, and then you just go at it and there’s a direct, correct answer that you come out with at the end and it just feels beautiful because you know you accomplish it.

                    Sometimes, you don’t always get that feeling of accomplishment in programming, necessarily you have time constraints, you have all kinds of other things that come in, you know what your bosses want, what your customers want, and all those things come into play. A lot of the time, you’ll come up with a solution where you’re not entirely happy. In this case, you know that when you complete that solution, you did it, you passed all the test cases, you figured it out and it’s a great feeling, it’s phenomenal.

Jamison:       I’ve heard the similar argument for open source. Your business is where you go to write code that makes money and there are all these external constraints from deadlines and technology choice and open sources where you just craft this pure gem of code.

                    It sounds that is similar in some ways where you just focus on the code. If you’re sick of JavaScript fatigue and the world web pack makes you scared, you don’t have to set up a new project and take two days doing that. You just focus on the inputs and outputs so it’s cool.

Nathan:        A very similar format between the two, all we found too that a lot of people that contribute to open source also get attracted to Codewars. The other way, it is, all the content in there if you’re contributing with this community. I was in on the same format but that’s the same approach cross.

Jamison:       The name Codewars carries a competitive or adverse areal connotation and I know that’s not all that it is. There is certain personalities that just thrive off that, I wanna defeat people, I will win the Codewar. There are some people that aren’t as attracted to that kind of thing. What does Codewars offer to them if they’re more interested in collaboration and learning, and the idea of stepping into the code arena doesn’t appeal to them as much?

Jake:             The war never happens. It was a part of the original idea. We definitely have some things that we’re working towards that can incorporate that.

Dan:             Funny enough, the first prototype we ever built was actually head to head. The whole point was you went and defeat your friends. We don’t actually have that. Right now, it’s all still very self-driven, there’s no actual competition other than getting more points and higher cues and level.

                    It’s like we ended up building the dojo part of the Codewars, just ended up focusing all of our energy on the educational side where people can be collaborative and there is really no competition within the community. I haven’t quite gotten to the wars part yet.

Nathan:        It’s actually a very welcoming, warm community. Everyone is really helpful and strives to help each other. It’s a misnomer, that aspect.

Jake:             One of the best thing is when you first get in there, you start to build your own content and that’s a huge feature too that we haven’t really touched on. If you really want to start to learn something, build your own content, your content becomes open source and all the people can start to help you create your problem and translate it to other languages.

                    As soon as you create a problem, plenty of people sign up to start taking at that day, it’s amazing, you just published something and all of a sudden 20 people try to take it and they’re like, “Hey, I had a little trouble, getting through here, what’s going on the test cases?” They’ll help you solve it now which is truly nice. It’s a lot more of a community than you realize, not so much.

Dan:             It’s like a little mini GitHub, little mini open source project. It help me do this kata a little mini programs, they go through a beta process, they go to QA, people can make contributions, we have this idea of you can translate a kata.

                    If you write a kata in JavaScript and somebody wants to add Ruby as a language for that, they can actually translate it and they submit it and the original author can then review and approve it just like you would approve a poor class. There’s kind of a little mini GitHub thing going on.

                    The thing about GitHub that I always wish that it was and it wasn’t is they call it social coding but there’s really not much of a social network. You’re not going to talk to people or you’re not going to create an open source project and have people starts showing up to your open source project. You have to go get them to show up on your own somewhere else like blogging about it or something like that.

Codewars, everyone comes to you, it’s more like a medium in terms of a blog, it brings you an audience. Everything is just like open source project but super minified.

Nathan: I think it’s also an interesting point to write projects of all. Going back to the beginning of Codewars, we started with this idea that is more in line with the Codewars name itself and we even think about it as far as the head to head. As it evolved, we ended up realizing that people got really got in the community, contributed the most, wanted to foster this collaborative environment.

                    Even now as we think about Codewars going forward, head to head, things like that, the contentious battle types parts, we think we’ve added dynamic to it which would be nice but really a part we’re more interested in are the educational parts like adding in ways for people to collaborate even better to actually make it so that they can code live together and someone could actually jump in on a kata with another user and help them out through it. Through that dynamic too, we didn’t get to touch on it yet.

                    We’ve also been working on this new project, Qualified.io. Essentially, that kind of grew out of the community as well in a way that we saw these challenges were being effective at helping people train, being effective at calling them out has really scaled them. It worked well for our own internal hiring, all of our team has come for the Codewars community.

                    When we started to see that with hiring processes, one of the big downsides to that to the engineering team is that you have this engineering team that’s pulled away from their daily job in what they really want to be working on to have to try and hire people. It’s not really something that you want to be doing, going through interviews, going people to onsite, doing all this bedding. That’s where we built qualified ad, that pain point as well, to help speed up the hiring process for teams and apply this format that we came up with for Codewars. The code runner aspect behind it from remote execution code and put it into this format to make this easy way to vet out talent, show our skills.

Jamison:       That sounds like an awesome master plan. The path to revenue from Codewars itself isn’t super clear to me but pivoting to use that engine for hiring seems awesome. Is that the thing you planned on from the beginning?

Jake:             Not at all. When we started out, we figured that some of the value were just being creating this community, and then when we create that community, we’d be able to top it somehow.

                    But it evolved over the last two years where we really started to get that feedback from our community where people, companies, hacker group camps, any develop organization, schools too, universities are using Codewars like an ad hoc format to test their students, test their potential hires and using that as part of their process.

                    We started to see this use case and then started to build out qualified as the separate application to support that specific scales. The monetization doesn’t really come from code, it comes from qualified but qualified builds upon all of this infrastructure we built for workers.

Jamison:       That seems cooler than the normal path to like, “We’ll build a thing and then figure out how we make money later,” and then you just stick ads in it. I think you ended up in a cool spot.

Do you ever get people that just submit problems that are just things that they want done? Like here’s a problem that not I, some other person has to do, and I don’t know the answer but I’m sure you could figure it out and then they just take it and use it in work.

Nathan:        Part of that thing is when you create a kata is you have to make a working reference solution. You have to have something that is already working and passing all of your test cases before you can push it out there. Technically, you can make a really contrive one and then be like, “How do you really do this?”

                    And then see what the community comes up with. We haven’t really seen that yet but there have been cases where I’ve created a kata and then, cause I wanted to learn for B3, I wanted to learn how those functions work and so I created a kata that was one of B3s functions and I wrote it and then I saw everyone else’s solutions and I was like, “Wow, these are way better.”

                    There were a lot of things that I took from other people’s solutions and started using them in my own code. I definitely think it could help you because we haven’t seen anybody pushing that out there, it’s like, “Please help me with this and that.”

Jamison:       Maybe that’s how you get an even better solution to that sorting and clustering to problems or the solutions to the code katas.

Dan:        We didn’t want to make it kata. There’s a lot of good ideas that just never made it.

Jake:             That’s a really good point you touched on. One of the most interesting educational components of Codewars is that you have this content and you’re taking it to yourself so there’s no one teaching you it, you have to go through Google the same way when you’re actually in work and figuring something out.

                    At the end of it, once you finished this problem, you get to see all of the solutions that the community put through. That’s usually one of the biggest teaching moments for people, you just struggle with this, you really know what’s going on here and you see ten other solutions that are just mind blowing. They really put a different perspective on that and end up teaching in a way where you’re learning from the best.

Dan:             I should think that probably for a lot of people, on my personal experience, you learn more looking at other people’s solutions than doing the challenge yourself but only because you did challenge yourself.

                    If you look at the solutions without doing the challenge, you’ll just be, “Oh look, cool,” because so much thought process went into it and then right after you complete it, you see all these other solutions and makes such a meaningful impact to you.

                    There was when I first started, I started following users that I thought were really brilliant and I would watch them code. I would follow them and the nice thing is you can follow them and you can see their solutions and the ones that you completed as well and I started following this guy. Sure enough, six months later, you guys hired him.

                    I saw the newsletter and then they had another open position and I ended up applying for that. Part of the reason was I was really excited to work with Jake and I didn’t know much about Nathan but I watched him code so much that I really understood how he thought, learned so much from him so I figured working with the guy would be a great experience and it has been.

Nathan:        It’s funny enough with the guy we hired is he has a couple open source plugins and I was working with him one day and I needed to do something, and I found his plugin and I saw the name and I was like, “Wait a minute, I know that name from somewhere,” and then I was like, I looked it up and I was like, he’s one of our top Codewars users.

                    And then I was just like, “I wonder what about him,” and I looked it up and there was some article about him, it was like Rolling Stone, it feels like he’s a rock star or something. It was a weird format. It was recent and it was mentioned that he hadn’t worked for a couple years but he’s looking to work now and I was like, “We’re looking to hires, this is amazing.”

                    We really caught him a few days before some other companies tried to get him. We’re not getting better.

Jamison:       It’s good timing. I have one more question. Part of the difficulty with software engineering research is it’s really hard to get good data sets because having people sit down and code up the solution to problems is expensive. They either do a lot of observational studies or interviews of people that work on existing projects or it’s like ten undergraduates doing this one thing.

                    It seems like one super valuable part of Codewars is the data set. Do you have all the analytics data about how long it takes people to solve a problem and how many times they come back to it? It seems like you could do some really interesting studies based on that data set.

Nathan:        Yeah, absolutely. It’s just something that we’ve been looking at doing. One thing we don’t have is the time of completion on Codewars just because we don’t foresee to start it and then have to finish it at that moment. You can just start doing it and finish it later. We don’t have that, we have everything else and that’s definitely some.

Jake:             We’ve got some ton of data that. They’re actually interesting see different groups of users, based on the type of usage, the way they come in, you can actually tell the developer’s personality based on how often they start challenges and give up really quickly versus the ones that even as they get into really tough challenges like sticking with it and hammer through it even if it takes five, six, eight hours.

                    To the point in data, that’s something that we built in a lot more into qualified and unqualified, we really do a good job of gathering everything. You actually even gather key stroke data. An interviewer can replay back a candidate’s solution and get a full feel for how that actually top. The thought process they went through, the solutions that they tried first, and even the output that they ran in between.

Nathan:        One thing we’ve seen a lot of is people actually take their Codewars solutions and they’ll put them up on GitHub as away of showcasing some of their skills. They’ll take that data and show it off, that can be super useful if you used there.

Joe:               Cool. It’s about time we wrap this whole thing up. I think let’s move into picks. Unless you guys have anything else you’d like to try in before we move to picks. Nothing we didn’t cover.

Nathan:        Yeah anyone would want to check Codewars, you go over to codewars.com. The hiring site, if there’s any interviewing, hiring managers there, engineering directors, Qualified.io helps automate the hiring process and assess coding skills in a really effective and efficient format. Beyond that, I really want to thank you guys for having us on the show.

Dan:             Yeah, thanks guys.

Joe:       Thanks for coming.

Jamison: The listeners don’t know but there was a great struggle before we started recording this episode to get all the tech to work. These guys are super patient to stick with it.

Joe:               Alright so Jamison, how about your picks?

Jamison:       I have a few picks. My first pick is a book called Marrow, it’s like a sci-fi, epic sci-fi book. The cool thing that I liked about this book is it’s got extremely long timelines, like thousands and thousands of years following the same characters which is just kind of a cool twist.

                    The next pick is another book called Uprooted and that one is a fantasy book. I just really like the voice that the writer has, it’s not your traditional, I don’t know. I read a lot of fantasy and it all starts to blur together after a while and this one didn’t at all. It’s got a very unique feel to it.

                    I’ll do two more picks. One is a blog post called Write Less Code that just had a perspective I enjoyed about the best code is no code because it can’t have any bugs and it’s easier to maintain and just kind of an argument for doing fewer things instead of just throwing more code at a problem. Tell them the fastest way to make a website load fast is to not have a bunch of stuff on it. That’s the thesis of the post.

                    My last pick is another blog post called The Rands Test. Rands is a famous blogger from the old school blogging days, the early 2000s. He writes mostly about the people side of software. If you heard of the Joel test, it’s like a checklist of things that a company should have to hint to you that it’s a good technical organization. This is the management side of it, things that a company should do with their employees to hint that they know what they’re doing in regards to managing people. Those are my picks.

I have started a company called Five Stack, it’s a software development studio. We build software for humans. We are looking for people to help build software. If you’re interested, you could go to fivestack.com and check it out, and just get in touch with me, I’d love to talk to you.

Joe:               Awesome, I’ll go next. I absolutely have to pick yet again Stranger Things. Television show on Netflix, unbelievable. So amazing, you’ve watched it?

Nathan:        Oh yeah. It’s amazing. Everything from the intro, music and the soundtracks. Everything about it is amazing.

Joe:               Yup, unbelievable. It’s amazing that shows can be so good when you watch so much, so many TV shows that are just not that way. Absolutely, take the time. Binge watch it, it’s like eight episodes or something. It’s a quick watch but man, it’s such a great show. I can’t wait for season two, whenever that comes out.

                    I do also want to again mention the Angular 2.0 workshop, John Papa and Dan Wahlin are putting on Ft. Lauderdale Florida, October 6th and 7th. We’ll be down there helping them out. I’m super excited for that. Two days of intensive Angular 2.0 training. I don’t think I’ve mentioned this before but if you use the code JSJ for JavaScript Jabber, that will get you a couple hundred bucks off. Head over to ng-learn.com if you wanna pick up a ticket. Let’s go turn over to you guys and your picks.

Nathan:        Sure. My pick is a book called Lean Analytics, it’s a analytics book, it’s part of the Lean Startup Series. I think it’s really important. Obviously, I’m a cofounder and analytics is important as an entrepreneur but I think all developers should pay more attention to analytics.

                    I think analytics tend to be the thing that’s thrown upon us and this stupid thing that’s slowing our website down, we have to add that script tag to our page. There’s actually a ton of value and I think it leads to us being more efficient about what it is that we build. Ultimately for developers, it leads to us more efficient about the things that we don’t have to throw away. I think analytics is an important thing that we should all at least have a good understanding of and I think the book Lean Analytics does a really good job of that.

Jake:             I got a pick, it’s a book called Code and it was amazing so far. I’m about halfway through and it’s starts with a brief overview of binary morse code and logic gates, and how they’re created from real life. Now, they use translators but if you wanna understand how computer works on a low level, I really suggest this book. I took a course in college on it and while I learned a lot then, this book has really been fun. I really enjoyed it from the beginning. Now, I can understand how you can toss a couple man gates together and start to hold memory, things like that which is quite exciting to learn not on a low level.

Joe: That book is rad, it’s sitting on my shelf right behind me right now.

Nathan:        Dan is going to use it to rebuild the first and second computer that we lost.

Dan:             I got two picks. One is a book called Data Smart, data scientist John Foreman, he’s the VB of product management of MailChimp. One of the best primers to get in on an entry level, even if you’re not going to become a full data scientist, it’s really interesting and that is a great way to wrap your mind around all the approaches that go in there and get a good inside view of it. Even more so than just an inside view is like learning how to use it in a way that’s applicable to whatever you’re working. Thinking about the best way is to gather data, capture data because half of the problems you realize, they come from doing a good job with data collection in the beginning and then actual crunching the numbers etc., like the other 50%.

                    Another book which has been pretty profound for me over the last few months is a book called Letting Go, it’s by this guy, Dr. David Hawkins. Essentially, he started out as a clinical psychologist, had this huge health breakdown and came up with a system that weds metaphysics and science together in a really good way. The whole concept of this book, Letting Go, is that a lot of the biggest things in our lives that we struggle with often are put there by ourselves. We as developers, they think a lot of people are more experienced. Sometimes the biggest block to solving a problem is your own inability to look at the easiest solution or look at it from a certain angle.

        That comes across in all sorts of ways across our lives. This book Letting Go expounds on this idea that letting go of things in general, whether it’s emotionally or issues or challenge etc., can have this really profound impact. So I suggest people go and check it out. It’s worked really well for me.

Off in Codewars, we’ve all started to build our new service, Qualified.io which is focused on companies that are hiring engineers. Effectively, what it does is it helps automate the hiring process, saving engineering team’s time, saving hiring manager’s time too so they can unearth the best talent and then also filter out people that don’t make it through that process for them. Anyone that wants to check that out can go to Qualified.io.

Jamison:       I just added a bunch of stuff to my Amazon wish list.

Joe:               Alright, well, is that it for you guys? That’s all your picks?

Jake:             Yeah, I think so.

Joe:               Awesome. Thank you so much for coming on the show. It’s been a great episode. We’ve really enjoyed having you on. Thanks everybody for coming, Jamison of course on our panel and thanks everybody for listening and we’ll see you all next week.

Jamison:       See yah.

Nathan:        Thanks a lot guys. We really appreciate you having us on.

x