 My name is Matt Farmer, and I'm here today to talk about the case for the cutting edge. So I thought it was really interesting when they placed me kind of in this track because you guys are dealing with a lot of, hey, here's this awesome library and here's this awesome technique and I'm going to come in here and talk about all this human stuff. So I guess they figured that if you were following this track you would need a break from having your brain melted the entire time with things like Scala's Ed and stuff like that. So I'm here to basically talk about kind of our experience at my company with choosing Scala enclosure and my hope is that at the end of this talk if you're in an organization that is not currently using some newer technology that you've had difficulty selling to people that work at your organization that you'll have an example of somebody to point to say hey these guys are doing this really well here are some things they said about what they learned in this process and this that and the other. So without like any further delay I don't think that I'll need to work very hard to find very many people in this room that think functional programming languages are awesome. If I do need to work hard to convince you of that this was an interesting choice of a conference for you to attend but I'm glad you're here anyway and like I said I suspect there are a lot of us that have had this experience of trying to sell functional programming or maybe maybe for you it's you've tried to sell using DevOps instead of a conventional like you know server management strategy over you know over your organization or whatever and it's interesting that we so often get pushback on these new things like new things are a little bit scary to people sometimes which is interesting because the mantle of the technology industry is to innovate and the mantle of the technologist in that industry is to innovate innovation. So this is this is an important thing for us to figure out how to how to do is to communicate that hey we can do this successfully. So to do that I'm basically going to be like I said using the company that I work for as an example. The rough agenda is I'm just gonna go over who we are real quick just so that you have some context for just what we're doing and where we're coming from in this. I'm gonna go through three particular lessons that we've learned in the process of making this choice and I'm gonna end with kind of why this is something that I think is worthwhile for any organization to explore be it like I said for Scala for DevOps for whatever and so that's kind of our game plan. So I work for a company called Alemica and there's a question that I get quite frequently and I think that the best rendering of it is in in the bobs. What would you say that you do here? This is this is something that that I get a lot because not very many people outside the supply chain space have heard of us but the kind of term for what we are is a supply chain operating network. Now if you're inside the supply chain space once again that probably means something to you. If you're not then your response will probably be very similar to that of a college buddy of mine when when I sent him that response which was this which is fair that there is a little bit of buzzwordy feeling to that if you're outside the supply chain industry but without going too far into detail with it I'll give you some rough numbers that give you an idea of the landscape that we're working in which is you know we we move about a third of a trillion dollars worth of industrial transactions over our network. To do that we support 200 different message format type and version combinations in order to make that communication happen and we have industrial great uptime and performance requirements because if our system goes down or malfunctions the possible failure conditions include factories having to halt production they include deliveries not being loaded or you know being delivered to the wrong place when deliveries can include things like chemicals which is really bad if those go to the wrong location. So that's kind of the context we're working in we're not playing in a perfect world sandbox like we've got a lot of things going on that are very important and we've chosen these these technologies scale and closure in order to actually make that happen. So that's kind of where we're coming from and now I'm gonna kind of go into some of the things that we've learned in the process of pursuing these technologies and we'll go from there. So lesson one is engineering isn't lost in translation so to most of us this this may not be a novel concept you know it's but it's the thing that when I'm trying to pitch scale and closure to somebody that's in a decision-making position the first thing that they look at right off the bat is the talent pool size. So they do something like you know go on like glass door or something like that and take a look at okay well how many how many scale engineers are out there how many closure engineers are out there and they're not entirely wrong to do that it being able to hire people for your organization is a valid concern and you know being able to use a technology that's popular enough to be able to hire people is is is reasonable conclusion to come to and so if you're following that conclusion they're not entirely wrong Red Monk periodically publishes language rankings based on GitHub and Stack Overflow activity. In the rankings that were published in January scale ranked 14th and closure tied groovy for the 19th spot. So if you're looking at that as a business person without an engineering background that's not entirely confidence inspiring right but let's let's put that aside for a minute let's take a look at an actual example of us attempting to hire people at Alemiko. So this was from about six six to eight months ago I think when we sent out basically a job ad to several different websites and we got about 60 high quality responses out of that and it's throwing away all of the recruiters that send you email say hey please use my services and things like that and of those 60 responses about five of them had prior scale experience that's about 8.3% which is not exactly confidence inspiring from just looking at a number standpoint. So if we were to consider this what we're hiring for then almost 92% of the applicants didn't meet this description but we kind of realized something and I'm sure that that you have as well at this point already that many of us at Alemica didn't start out knowing Scala there was a time before we knew Scala and it turns out that we're pretty good Scala engineers in spite of that in spite of not coming out of the womb already knowing about Scala so that was kind of that's kind of an important realization for us to communicate to the people that need to actually have the final say in what the company is going to do and acknowledging that allows us to be a bit more honest about what we actually need which is a software engineer and it's true there are plenty of other limiting factors that go into hiring somebody the most important of which is knowing how to pronounce the word Jeff obviously and you know that's that's an important distinction to make is that engineering isn't lost in translation that you know we have the the ability to translate engineering skill between a language or a particular technology stack and be successful wherever we're landing as a result of that and by doing that we open ourselves up to a lot of new blood and we get to be a part of expanding the Scala talent market as well so that's one two is embrace the elbow grease so I talked to a lot of different people about languages and things like that in Atlanta and one of the knocks that I hear about Scala enclosure is usually from people coming from outside of the Java ecosystem and they tend to quantify this in terms of library counts for whatever reason they say well you know I you know Ruby has so many gems that I have a high level of confidence that I can go and get something and I don't know why that seems to be the case maybe that's just been my unique experience I'm not sure but it's a bit weird because I don't particularly find myself hunting for libraries or being at a loss for a library that often the Java ecosystem itself is pretty rich and there's there's a lot that's already out there that that other people have done and you know you occasionally end up with situations where you need to basically reinvent the wheel on something because for one reason or another but by and large the Java ecosystem has a lot to offer us and the thing is is that this is a thing about this in terms of library counts is a bit weird because honestly library accounts are seem to be most helpful at the beginning of a project when you're first getting started so if you're thinking in terms of a longer timeframe it makes more sense to ensure that you're choosing a tool that lets you optimize for the hard things and that's the attitude that we've taken with it at Alimica because it's essentially by choosing scale I yeah we had we had a bit more work than somebody that can just use a rails generator to get our application up and running but now that we're at a point where we're past that where we're into the meat of solving the hard problems we found that for us scale of presented scale enclosure presented an opportunity for us to be more productive when we're in the middle of those hard problems and that's for various reasons one of them is the type system that actually helps us out a lot another one is that the concise syntax allows us to fit more context in one window we're not hunting around in a file looking for something and those are those are things that can change based on your team based on your problem space whatever so the the idea is to basically embrace that the hard things are going to happen regardless of what language it is that you've chosen and when you're thinking about what tools you want to select you need to select the ones that are going to do the best for you when you hit those hard problems so the kind of final thing that we've we've learned that we've we've got to do is engage the learning curve and that actually has kind of two parts to it the first one is for ourselves and part of choosing to approach newer technologies implies you've got to be willing to spend some time learning and you've got to communicate that that time is going to be needed to the people that need to know and ultimately I think that's that's a good thing for us as engineers is to communicate the value of that learning time that that we spend exploring because ultimately that makes us more valuable to the people that that are part of our organizations and you know ultimately promotes a culture of people that are learning consistently and the second one is in new team members so something that I think that a lot of organizations deal with this probably isn't unique to us but onboarding new people is hard sometimes and especially if you're onboarding somebody that doesn't have prior experience in the technology stack that you're using that's something that you have to pay extra close attention to and we've had our own struggles with that at Olympica with getting our onboarding process to a place where when we bring somebody in they're not going to spend a month and a half just being frustrated because they can't get anything done that's not what you want to happen and so we've tried very hard to kind of engage that learning curve and be very intentional both at a personal level and at an onboarding level about how we learn being conscious of making that time available to people on the team and other things like that so those are kind of the the the three things that you know we've kind of taken away in summary three big lessons that we kind of experienced in the process of making this choice and you know as a result of that we have kind of been doing very well with with this in spite of the challenges that it presents in terms of communicating the value in terms of training new people we've we've had a really great experience but even looking at that great experience back the other direction it's it's a hard choice for an organization level to make you know it's it's one of those things that it involves a good bit of risk from the point of view of the organization and it involves a lot of conversations involves a lot of communication in order to make that happen and you know ultimately one of the things that we've that I've found through that is that I miss lights gonna go there we go is that it's a decision that's worth it and I'm I'm basically looking at this from my perspective as an engineer but what I see when I look at the effects that this has had on our organization is that by choosing to abandon this notion of an engineering skill being limited to one language it's given us the opportunity to hire the best people regardless of what their background is regardless of you know whether or not they've written the line of scale of before like we have people that have backgrounds in the restaurant industry that have always just really enjoyed computer science and we have people whose backgrounds are in classical music that you know then learned Ruby and then came to work for us and those are some of the most valuable members that we have on our team and if we had considered having written scale of before as a qualifier for being interviewed we would have missed out on those people the same one is is that by acknowledging that the hard problems are going to be hard regardless of what language we're using we've kind of gotten over this mental block towards choosing something new when market realities tell us that's the right decision to make we're not so locked into the way we've been doing things that we we are unable to change when that needs to happen and you know finally being aware when things were not going well with onboarding has meant that we've been able to iterate on that process and ultimately make it better and by being open to learning new things individually and you know making that a core part of our team culture we've created something that I think is really unique in my employment experience of just this boldness to go and learn something new if that's what's called for now that could be a new technology but that's also proven to be a new part of our system if it comes down to me having to bother somebody that's on PTO or me figuring out a new part of the system in order to try to fix a bug that we need fixed our culture dictates that I choose this one over here that I attack I try to attack that problem first before just saying well no I don't know that and I think that was that's that's an important culture point that you know for me at least makes a limit a very interesting place to stay as an engineer and so for those reasons I would argue that ultimately pursuing new technologies pursuing learning as a core culture value pursuing you know this this kind of acknowledgement that hard problems are hard regardless of what tools you're using to solve them that these are things that are worthwhile to pursue for any organization regardless of the context that that you're operating in and I'm saying that coming from a context of you know we're not playing in a sandbox like I mentioned earlier like we're solving real problems by pursuing these values and so that is a very brief version of my talk because we're already getting close to time and I needed to kind of improvise a little bit so I hope that everyone is still awake and I thank you for listening and if you're interested I would love to hear feedback if you're interested you can email me and you can check out my blog and my Twitter account and let me know what you think so that's pretty much it and if you have any questions I'll thank them