Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're talking about prototyping your processes. In one of the very early episodes of Developer Teawe talked about prototyping and we discussed some of the reasons that prototyping is so important. We talked about high resolution prototypes as well as low resolution prototypes and a lot of that stuff is specifically applicable to the work that you're doing but I want to take a step back and assume that everyone who's listening to this episode has at least encountered what a prototype feels like. They've encountered the need for a prototype at some point and for a simple explanation or a definition of prototype I'm going to kind of dumb it down a little bit. We aren't going to talk about higher low resolution prototypes. Basically what a prototype is at its simplest form is a very limited version that acts like the real thing or in some way it acts like the real thing. It doesn't have to be exactly the way the real thing works. It doesn't even have to work for real. It can fake some of what it's doing but it has some piece of it that proves the point. It's some piece of the prototype that is a reflection of what the real thing would be. There's a lot of reasons to create a prototype. We talked about them in that episode. One of the reasons is to prove that the idea makes sense. It's to prove the basic concept of the idea. Some other reasons may include finding faults that you didn't see before. You're creating a prototype so that you can uncover things that are not necessarily easily predicted. I want to focus on one very important aspect of prototyping, not just the reason that it's created but the way that a prototype is created. Specifically, we want to focus on the limited amount of energy that we put into prototypes. Why do we put limited energy into prototypes? Quite simply, what we're trying to do is get the most information out of the least effort. We're trying to get the most... We also are trying to validate an idea with the least effort. We're trying to validate an idea with the least input because the antithesis of a prototype, the opposite of a prototype, and a bad way of going about proving an idea is to actually go through with the whole idea to build a full resolution production version of that product. It would be a bad idea to try to build an entire product in order to validate an idea quite simply because it's so prohibitively expensive and it takes a lot of energy. I want to apply this same knowledge to another area of what we do as developers. We're going to do that right after I take a quick sponsor break to talk about today's sponsor, Linode. Whether you are building a prototype or if you're building a production application that needs to rely on multiple network servers or maybe you just want to have a personal website, a side project, Linode has you covered. You have eight data centers with Linode, then plan start at just $10 a month. That's like getting a couple of coffees and you get a fantastic server running Linux in the cloud with two gigabytes of RAM for that $10 a month. It's an incredible deal. All of their services are build on hourly billing and there's a cap on all of the plans. So you're not going to go over that cap. You can have a VM for full control. You can run a Docker container. You can run encrypted disks. You can have a VPN and you can run your own private get server. Of course, you can run things like Docker directly on these Linux boxes. That's what this stuff is great at. Of course, Linode would work well then as a part of your continuous integration processes. There's a ton of things that Linode servers can do because they're running on that incredibly powerful underlying software Linux. Go and check out what Linode has to offer. Here's a couple more important details. They have a seven day money back guarantee. You can try this for seven days. If you have a project that you want to get up and running or perhaps a Docker container, you can get it running on Linode very quickly already. You get seven days to check that out without any risk at all. On top of that, Linode is offering you a $20 credit for using the promo code Developer Tea2017 that's Developer Tea 2017. Go and check it out, spec.fm slash Linode. Thank you again to Linode for sponsoring today's episode of Developer Tea. We're talking about prototyping and specifically we've outlined kind of this basic idea that a prototype is a shadow or maybe a foreshadow of what is to come. It kind of works like the thing that will eventually be in its place. It's a proof of concept and it's the least amount of energy to prove an idea or to figure out if something is valuable. If a direction is the right direction to uncover problems that we didn't know existed before with the smallest amount of energy, the smallest cost. I want you to take this idea and start applying it to other parts of your job. We're going to talk about one of those specifically today. If you are a manager of developers, this is going to be particularly relevant to you. Even if you aren't, if you are a junior developer, you can still bring this up at your next meeting with your manager of developers or you can talk about it with your coworkers and discuss how this may apply to your organization or to your product. I want you to take this idea of a prototype and apply it to your processes as a Developer Tea. There's a lot of times that I as a director of technology at Whiteboard, I've come up with an idea and I want to implement it in a unilateral way across the company. I want all Developer To start using, let's say ES6. It's JavaScript January. We can talk about JavaScript as the proof of this idea. I want all Developer To start using ES6 or I want all Developer To start doing pull requests and reviewing code on GitHub. There's a couple of problems with this. Number one, not all developers are working exactly the same way. Not all developers are working on the same types of projects and it depends on where you are, what your organization does, but not all developers necessarily have the same level of skill with those types of requirements, those kinds of initiatives. Everyone hears something different when you try to require something across the board. Everyone hears a different level of investment and a different level of value. On top of this, if you're trying to implement a brand new process across the board, if you're trying to have everyone on a given team or everyone in the company do something that large, that much of a change to their workflow, even if it's a small change, that is a significant investment. For a period of time, you're going to see a lot of energy going towards those changes. Of course, everything is relative. The changes that you implement could be so small that they're negligible for this discussion. If we're talking about something as large as the types of things that I mentioned, for example, using ES6, certain parts of the syntax for ES6 or adopting a new workflow, adopting a test first procedure if your team is not already on a test first procedure, those kinds of things, those are going to be costly. On top of that, if you haven't tried it and validated that it's going to be valuable for your company, pay very close attention to this. If you haven't tried it and you haven't validated that it's absolutely going to provide value to your company, then you may be wasting that energy when you could be using it on something more valuable. This is the important part of prototyping. What we want to do is bring the wisdom that we have on the product side when we create prototypes. We want to bring that over into the people processes as well. Typically, the way that companies do this successfully is they create what are called pilot programs. They create pilot programs. What these programs do is they take people who are particularly interested or particularly invested and who are equipped to make these changes or to go into a particular field of research. They take those people and they try it out for a period of time. The period of time totally depends on what the thing is. We're not going to try to outline a perfect schedule for a pilot program. If you're doing something like adopting ES6, it may be over the course of a month. Right now at Whiteboard, we are doing a pilot program for a peer review and pull request workflow on GitHub. We're making it a suggestion, kind of a deprecation notice for one month and then a requirement for a section of the team in the next month. Over the course of three months, we're going to adopt it as a requirement across all developers at Whiteboard, but it's not going to happen overnight and it's not going to happen all at once. We're creating this pilot program. I want to give you a visual, kind of something that you can hold on to as a visual representation of what a pilot program does. Imagine if you're trying to drill a relatively large hole in a stud in the wall and you pull out your drill and you try to drill with a large drill bit. Well, the problem with this large drill bit is that you may end up creating cracks and you might even crack the wood. The actual stud may crack if you use a large drill bit. If you create a smaller hole, appropriately named a pilot hole, if you create a small hole and then you create your next larger hole in that stud, you're far less likely to screw up your wall or to crack the stud as you drill the hole. This visual is what should come to mind anytime you try to get a bunch of people to all buy into a single idea. If you can get a few people to buy in heavily to that single idea, then as those people buy in, allow them to help create the idea's momentum in your organization. This isn't just for developers. This is for any idea, any kind of regulation or process adoption or even value adoption. If you have a few people who create that pilot momentum, that pilot direction in your organization, then it's going to be much easier to get the rest of the people to adopt it. It's also going to be much easier for you as a person who is architecting this process change or the value adoption. It's going to be much easier for you to validate whether or not it's even worth it to try to spread it throughout the rest of the company. You see, before we decided to make the pull request and peer review process an enforced part of the way we do things, we went through a few months of a few people trying it out to determine what effect it had on their sanity, for example. Qualitative research in that particular area, what effect did it have on their code, on the reliability of their code, and the deliverability of their code? These are the kind of things that you want to test for. When you have a pilot program, you can pay more attention to the details. You can do both the quantitative analysis and the qualitative analysis and determine, is this going to be valuable? Is it going to be valuable for the rest of the company, for the rest of the team? Thank you so much for listening to today's episode of Developer Tea. I hope you like this concept of applying the prototyping logic to other parts of what we do as developers. Thank you to everyone who has already submitted pins in the JavaScript January Developer Teacode pin contest. It's kind of a mouthful, but basically we're giving away six licenses to code pin pro. That's a whole year of code pin pro. It's worth about 75 bucks. Code pin has been so kind to offer three of those and then Developer Tea is going to pay for the other three. So for whoever has the most hearted JavaScript based pin, if you don't know what a pin is, you can go to code pin.io and find out more. But whoever has the most hearted code pin pins that rely primarily on JavaScript and have the tag JavaScript January or JS January as well as the tag Developer Tea, whoever has those six most hearted pins are going to win a year of code pin pro. We will announce the winners in the spec Slack community on February 5th. That's spec.fm slash Slack if you aren't already in that community. Go and check it out. There's over 7,000 people, 7,000 designers and developers looking to level up in their careers. Don't miss out on Monday and Wednesday's episodes. I'll be interviewing West Boss, West is the creator of React for beginners as well as JavaScript 30. So it's right in line with our JavaScript January theme for this month. Thank you so much for listening to Developer Tea. Thank you again to Linode for sponsoring today's episode of Developer Tea. Remember you can get $20 of credit in seven days money back guarantee over at spec.fm slash Linode. Thank you again to Linode. Thank you so much for listening to today's episode of Developer Tea. If you don't want to mess out on those episodes on Monday and Wednesday with West Boss, make sure you subscribe. Until next time, enjoy your tea.