Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. I'm your host and today I am finishing my interview with Ernie Miller. Ernie is a programmer. He is also a speaker. He is a director of engineering at Invisium and Ernie spoke at Ancient City Ruby. I was lucky enough to be there at that conference and so I sat down and spoke with Ernie for a little while. Make sure you check out the first part of the interview. The second part we kind of jump in right in the middle of a conversation about Ruby and about how Ruby was engineered specifically to increase the happiness of the developers who are using the language. Really interesting conversation. Make sure you check out the first part if you missed it. Also make sure you follow Ernie at Ernie Miller. If you have not subscribed to Developer Teawhile you are listening to this episode just open up whatever app it is that you listen to podcasts and press subscribe and that will immediately send you notifications whenever new episodes of the show come out and you will have to remember to go to developertea.com. Speaking of developertea.com all the show notes for this episode and every other episode can be found on developertea.com and there is a contact form on there as well. Okay let's get started with the second part of the interview with Ernie Miller. Even sometimes at the detriment of performance. The Ruby community is very transparent about that. Ruby is not the fastest language necessarily and it depends on what you consider fast. But it is not the fastest language. It may be one of the faster to develop with but it is not the fastest in terms of execution time like objectively. But we have made that trade. It is a value trade for people who develop in Ruby. We enjoy the language enough to write in Ruby. It is making great struts and it will need to continue that direction. But more is a law on our side. Yeah eventually it is not going to matter really similar to memory as much anymore as it used to. You will see a lot of professors even saying the heap is big enough. You can just push stuff into the heap. That is big enough is not a scientific way of describing it but at some point it does not matter anymore. All of software engineering and really all of life but let's just try to write it in here. It is about trade-offs. It is looking at opportunity cost. If I do this what am I giving up and am I willing to give that up. For Ruby we are willing to give up a whole lot in order to have a language that we find works the way we think and does not artificially get in the way of us and does not make us jump through a lot of hoops to make something useful and fun. That is a trade-off that we have considered and we have elected to make. I personally can be happier with it but it may not be the right call in all situations. There are concessions you need to make to reality sometimes. If there is a performance hungry piece that is why we have C extensions. In the canonical Ruby interpreter for those who aren't Ruby S M R I or Mats's Ruby interpreter is the thing. It was written in C and you can write C extensions to it so you can drop to a little bit of a lower level when you need to in order to get that performance. It is interesting because I do not think that you can't be a happy developer and you do not have to code in Ruby to be happy developer. I am just saying no. There are plenty of people that I know actually I was talking lunch today with a couple of guys here and they were saying that they really enjoy objective C. It made sense. Actually I enjoyed objective C as well. I think I am weird. People squint at me when I say it. It is very similar to Ruby in a lot of ways. Message sending and that. All about. They both have small talk heritage. Object oriented development is core to both of them. Just because the syntax is a little wonky or different doesn't necessarily mean that they aren't very similar. Sure. Yeah. Which I think a lot of people look at Ruby and it is the syntax that a lot of people attach to it first but there is more to it than that. I will be right back with Ernie Miller right after this quick sponsor break. You have probably heard of QuickBooks and you might even use QuickBooks every day in your small business but did you know that QuickBooks has an API? Intuit has built the API with developers in mind using standards like Open ID, OAuth and REST API calls. With millions of businesses already using QuickBooks you have a customer base that is ready to use your app. You can even publish your app on apps.com. Intuit's application marketplace built specifically for QuickBooks users. Here is the best part of the QuickBooks API and apps.com. It is all free. Intuit doesn't take a royalty share from the applications that you publish. You can get up and running in just a few minutes using the developer sandbox and the API Explorer. Just go to developer.intuit.com today to get started. There will also be a link in the show notes to let Intuit know that you are a developer to you listener which is a huge help to the show. Check it out in the show notes on developertea.com. Thanks so much to QuickBooks for being a sponsor this week and now let's get back to the episode with Ernie Miller. Let's talk a little bit about Humane development. Great. So tell me, just give me the Twitter spiel about what Humane development is about. Alright, so I already made my blatant plug for the core premise. And without giving away stuff that is in my Humane development talk which you can actually go see. I gave it it Ruby on Ails earlier this month and that video is now on YouTube. The short of it is this. I believe that we as our organizations evolve we have somewhat corrupted the initial intent of the Agile manifesto for instance. That is we've diluted Agile to be almost meaningless at this point. And in fact if you look at some of the initial statements of the Agile manifesto about for instance valuing individuals and interactions over processes and tools. In fact now we look at most people that do Agile are using some specific tooling to accomplish it. There's well-defined kind of set in stone sort of processes like scrum that are under advocated and followed to a T or to some variation of it. Actually it's not always the case that we follow it the way that we that it was originally defined but that's really not the point. The point is the core ideas are no brainers when you look at when you look at the Agile manifesto you're like oh yeah absolutely it's about individuals and it's about communication and it's about all these things that obviously are involved in software development. And of paramount importance but we have for better or worse twisted and I often times kind of think like the business for you imagine air quotes right now for you listening at home. The business has embraced and extinguished the idea of Agile in a sense. In the sense that back in the days when everybody was demonizing Microsoft we used to always joke about how Microsoft would embrace and extinguish competitors. They would say we like this technology and then they would just subtly corrupt it in such a way that it was no longer compatible. We used to say that stuff about how they did web development for a long time. I don't think people are talking that way anymore but it was an old school way of thinking and I am an old man after all. And so I think the business has to some degree embraced and extinguished they like to say their Agile because Agile has connotations with fast. People like the idea of sounding like they're able to move quickly. It sounds great in theory but what they're really doing and I'm not going to be able to attribute it to the right person right now. So just some gentleman I talked to earlier at lunch in fact said that we do scrum fall. So it's sort of this weird combination of waterfall planning and then supposedly scrum execution but it's not really anything that's like what Agile used to be. So I think really when it comes down to and I struggle with the idea of presenting humane development as an alternative. Basically what I say is this. There are four virtues. Hussle is not among them. I do not think hustle is a virtue. The idea of moving quickly is in and of itself not the goal. The goal should be moving in the right direction. The goal should be moving in a sustainable pace that you're not consistently burning yourself out or your people out. And so I look at it as kind of four interconnected things. First things first and the foundation would be that empathy is necessary. And that follows off the idea that it's all about the humans. That's the core of the axiom right. It's obvious and what the whole point of an axiom is that it's so obvious you couldn't possibly refute it. We're humans working with humans to both suffer for the benefit of humans. So you look at it as a human endeavor. You need empathy. You need to be able to empathize with the business with your users with whatever and vice versa. The humans involved need to empathize with one another so that they're more willing to communicate with one another in an open and honest way, honesty being the second thing. That it's another pillar that you kind of have to build on. You need to be honest not front. That means acknowledging that in many cases deadlines are lies. Estimates are oftentimes lies. Currently I think that we get away with all those lies because they sort of cancel each other out. If the deadline is not a real deadline and the estimate was wrong, what doesn't matter? We just moved the deadline because it wasn't really a deadline at all. So we look for honesty. Once we've sort of displayed honesty to one another, well trust develops. When you can trust the other people to be consistently up front with you, if you can trust that they are going to be empathizing with you and your needs and they're going to do the best they can to deliver what they can, well then you unlock the goal. The goal is autonomy. You want individuals to be empowered to act in the best interests of the company and of themselves and hopefully those aren't in conflict. The goal is to approach it as a more human endeavor and be a lot less focused on the processes and the tooling. In fact, nowhere, anywhere do we make a reference to tooling except to say that you should be skeptical of tooling. Tooling is sort of setting in stone something that maybe is much more flexible as just kind of a here's the way we normally handle this and processes are really just shorthand communication. That is they're not, you don't need to have a process for everything. In fact, I call it process meta programming where you sort of really are better off giving underlying rationale for a process and letting people be able to derive that process on their own. You give them the wise. Why is the absolute and we talked about that today actually as well about the five wise. But asking why is such an important question to ask and to really listen to the answer can tell you so much is what moves you from having a requirement to a rationale or a reason, a reason for this thing. And once you know the reason, well then you might be able to find a better way to build and certainly a more sustainable way. If you know the end goal or you have an idea of what the goal is in mind instead of just we need to sprint to this next checkpoint because this is what they've moved off the backlog into the current sprint. Well, that gives you context and you can plan a sustainable pace that you're going to be able to keep up and you're going to actually make it to the finish. If you can't sustain your pace then it's less than worthless. You'll burn out. You won't finish. Yeah. So it's like re-injecting kind of the spirit of the original Agile manifesto. But in a more interesting things that have come out of Agile. Who was it Dave Thomas? I think wrote a post about how Agile's dead long live Agile or something like that. I think it came up around the same time as David's didn't. Yeah, David. It's a long live testing. Yeah. And so basically what he was saying was Agile comes with baggage now just like TDD comes with baggage now. And that we now have a reason to say let's pull back a little bit and like get away from this hype. Well, there's this culture around it now that that doesn't really isn't proper. Yeah. And doesn't do the original idea of justice. It was sold into organizations in such a way and that's where we were talking about the embracing and extinguishing sort of sort of mentality. By saying for instance, we are now certifying Scrum Masters. Right. If you look at something like that, you're now you're now saying well, that is part of your identity Mr. Project Manager you are now a Scrum Master. Well, in traditional, yeah, and in traditional Scrum, the idea was that Scrum Master went away eventually. Yeah. And that the Scrum Master was a rotating role between Developer Tea members. Right. The idea of a certified Scrum Master was ludicrous. And so in Uncle Bob, so Bob Martin had a Robert, Robert C. Martin, Robert did a talk. I believe there's a blog post as well. But the talk was really compelling and I found it when I was researching for the humane development talk where he talked about the land that Scrum forgot. And it basically goes into some of the origins of Agile, how it came about. And specifically this, in whenever he talked about the certified Scrum Master idea, Bob thought it was stupid. And all the developers he talked to he thought it was stupid too. Because like obviously this is not a thing we should be certain because it's not supposed to be a long term role. It's supposed to be the teams are supposed to be self organizing. And so it's really funny to look at how that is morphed in it's essentially just been another way for the same people that were in a position of power to kind of say, my team did this. Are now still in that same role. They have a different title. It didn't it went full circle. And so yeah, it's about I think with humane development it's about coming back to some of those same realizations. I mean, I don't claim to be saying anything that's rocket science here. It really is not. And by giving it a name hopefully we can talk about it in a way that makes sense. But I don't think that this is anything new. And I just think that if you look at the creators of the Agile Manifesto, most certainly many of them were in consulting. And since most of them were in consulting, well, they certainly couldn't exactly write a manifesto that said, you all are doing things horribly. Let us come fix you. You know, they would have a really hard time selling that. Sure. And so it's sort of by continuing to say there's value in these other things, but we value these things more. They allowed those other things to stick around and eventually reassert their dominance in a kind of a subtle way. At least, you know, this is in the way that I look at it with my limited viewpoint. I really welcome discussion on this stuff. And so I think that that's really the frustrating thing is, you know, how do you say something that still has meaning? And this is what I'm trying to do with humane development. To have something that's meaningful, maybe it's obvious as well, but it's meaningful enough to say without defining it so much that it allows the same kind of subversion again to go back in and kind of twist it to your own means, right? Like, sure. And I think that by being openly, essentially openly hostile to things like heavyweight processes and unnecessary tooling, I don't leave a window open for some organization to come in and like co-opt this term and twist it into something that's frankly evil. Right. Yeah. Because you're almost saying, you're almost targeting them before they come trying to build antibodies into the into the into the system to be resistant to commercialization. Yeah. It's an open source idea. I don't have to sell it to any. I don't care. I mean, you know, this is something I'm trying to work through for me and my company. And I don't necessarily have to sell it to anyone else, but the fact that it seems to be resonating with people is really encouraging. It makes me happy. Yeah. And in any commercialization of it would be just to propagate the same message, right? It's the only way that it's possible to commercialize it. Yeah. Create training resources of how not to do these things. Right. Yeah. I think it's great. So humanedevelopment.org. Yes. You may develop.org. And if you haven't been to show me any any any conferences, please approach me. I have stickers now. I will be taking one of those stickers with me home to Chad and Nuga. This has been great. So people can follow you on Twitter at at Ernie Miller. That's right. And I'm going to ask them all to tweet at you when the show goes live in and day Ernie with with tweets. That's this is a common common thing I ask you guys to do. Okay. So another common thing that I ask my guests is if you had 30 seconds to spend with either a experienced developer or a beginner developer, both sides, and give them 30 seconds of advice based on your experience and all the things that you are learning now. And what would you say to them? I don't even need 30 seconds. Give me five seconds. And I would say ask for help. You don't have to be perfect. I think that's really the core of any advice that I've given to anybody I've ever mentored. It's like, you know, look, if you feel like you're buried, if you feel like maybe you're going down a rabbit hole, speak up. Ask there are people who will help you. The internet is full of them. Our company is full of them. I am one of them, you know, reach out and let's work together to solve a problem. You don't have to know everything. Those rabbit holes are well traveled. There are people who have been there before. Well, this has been great. Thank you so much Ernie for being on the show. Thank you for having to talk to me. Appreciate it. Thanks so much for listening to this episode of Developer Tea, the interview with Ernie Miller. I hope you enjoyed it as much as I did. Make sure you follow Ernie on Twitter at at Ernie Miller. You can also follow me on Twitter at at Developer Tea, or you can email me at Developer Tea at gmail.com. If you'd like to support Developer Tea with a monthly or a one-time donation, make sure you go to developertea.com, front slash donate. I recently had a little bit of a set back with some audio gear and your donation is a huge help to replace that gear and just to generally help me out in making this show happen four times a week. Thank you so much for listening to Developer Tea and until next time, enjoy your tea.