NOEL:  Hello and welcome to the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and would like to encourage us to continue, please follow us on Twitter at @Tech_Done_Right and leave a review on iTunes. iTunes reviews really do help new listeners find our show so we appreciate your time. We also have a new newsletter where you can find interesting stories, podcast news and some mini-essays and rants from me. You can subscribe at TechDoneRight.io/Newsletter. Thank you in advance.

One of the perks of doing this podcast has been the chance to have extended conversations with smart people who I, either never get a chance to talk to or are only get to interact for a few minutes in a conference or on Twitter. Sarah Mei is the Chief Consultant at DevMynd and she's also a member of Ruby Central. Her Twitter feed, @SarahMei is loaded with interesting tweetstorms on all kinds of code-related topics, ranging from code quality to testing to culture to mentoring. You should definitely follow her there.

I'm really excited that I got a chance to talk to Sarah and I'm excited to share with you the conversation that we had and it starts with a discussion about Livable Code. Sarah, would you like to introduce yourself?

SARAH:  Sure. I'm Sarah Mei. I'm the Chief Consultant at DevMynd and I have been doing a bunch of thinking recently about teams and software design and code quality and how all that stuff intersects. I've been talking about a concept called Livable Code. I'd love to talk about that today.

NOEL:  Why don't you tell us what you mean by Livable Code?

SARAH:  I see codebases in two states. Neither of which is super useful to the team that owns it. The first state is probably the most common and it's the one where it's so messy that you can't really understand what's going on. That there are large swaths of the codebase that nobody touches. There are small little goat-trails of understanding through large files or complicated methods.

NOEL:  Now, the one time where that one person who knew what was going on, cleaned up the one file that one time.

SARAH:  Right and there was a bug that needed to be fixed so they had to trace through some thing. There's this one little piece of it that you understand but then there's this whole unknown, like Oort Cloud of stuff out there. There's a lot of teams that have those or are approaching that situation. Then the other type of codebase I see that is not workable is the type where everything is super-abstract, where it's very difficult to figure out what happens when a user does something with the software. It's very difficult to figure out like, "Trace through here, it goes through there, it goes through there," and eight classes later, there might be something that actually does the thing you're trying to figure out, if you're lucky.

NOEL:  Low cohesion, textbook low cohesion object oriented design.

SARAH:  Yeah, exactly.

NOEL:  Cohesion is a software design term that is an abstract measurement of how clumpy the code is.

SARAH:  Yeah, that's an interesting way of thinking about it.

NOEL:  A codebase that has high cohesion tends to have a lot of stuff in the same place and a codebase with low cohesion has stuff that's spread out.

SARAH:  Right. You know, most software is super basic. There's some kind of input, there's a list of things that has to happen and then there's some kind of output. No matter whether you're building a piece of middleware or a backend service or a web application or a mobile application or firmware for a robot. This is the basic structure. It could be easier or harder to find that list of things that happens and that's how I think about it, it's like how easy is it to find the list.

NOEL:  So, you will make all of these abstractions sort of ostensibly in the name of future maintainability or maybe they just do it because... Certainly, I went through a phase where I just did hyperabstract code because I like hyperabstract code and had not yet gotten burned by it.

SARAH:  Absolutely. That's sort of the way we teach design as well. I did a computer science degree a long time ago and the way that they taught software design was you figure out all of your boxes and lines up front and you figure out what the names of your methods are going to be and what they're going to take in and what they're going to return and then you fill it in. They taught us that the way to do that was to figure out like, "What might you want to change and let's make that easy."

NOEL:  It's a good goal.

SARAH:  Which is a good goal, absolutely.

NOEL:  My actual undergrad CS degree kind of predates object oriented programming but as a grad student, I taught object oriented programming in Smalltalk and certainly, I was responsible for inflicting that philosophy on people. I still I think, have some abstraction in my codebase so where does that go wrong?

SARAH:  Well, where it goes wrong is if you've got folks on your team who can't keep so much stuff in their head. Where I see it go wrong often is when you have a team that is more on the junior side of things than on the senior side or if you have a team that is all senior right now and you want to start bringing in junior developers because a lot of times, folks who are newer to development, one of the characteristics is that sometimes they can keep fewer abstractions in their head. As people gain more experience, that's one of the things that people seem to get better at is keeping a set of abstractions, maybe because they've seen so many so they can pattern match against them and can take shortcuts in their brain. But for whatever reason, folks who are lower on the experience spectrum, sometimes have difficulty with these very abstract codebases.

NOEL:  One definition of expertise is that you get better at pattern recognition and dealing with larger abstractions, like across domains.

SARAH:  Yeah, absolutely.

NOEL:  What makes a codebase livable, then?

SARAH:  I think about Livable Code as being somewhere between the super-abstract, low cohesion codebase and the extremely messy don't understand it, difficult to figure out messy codebase. I think about that as two different extremes. One of them, I think of as a hoarded house, like a house you would see on the TV show, Hoarders. I don't know if you ever saw that.

NOEL:  Yeah, I can picture.

SARAH:  Yeah, the other side is like a house that's been staged. You're trying to sell it so you take out all the clutter.

NOEL:  Very minimalist?

SARAH:  Very minimalist, you can't live there. There's no trash cans, there's no pot rack in the kitchen, etcetera.

NOEL:  This is like the Goldilocks of software design?

SARAH:  Yeah and the 'just right' is different for each team. I think the important thing to think about here is that there's no 'just right' that is just right for everybody.

NOEL:  I definitely can think of one case which I know anecdotally, where a company had a large messy codebase and they called in a consulting company, which is neither my consulting company nor your consulting company and that consulting company built them a super-abstract codebase. Unfortunately, when they left, nobody left behind knew how to maintain it and again, anecdotally sort of devolved back into a hoarder's mess and they stopped using it. I think of that story a lot, actually in terms of what the right thing to do is or what correct software design actually is in context.

SARAH:  Exactly. There's no such thing as absolutely correct software design because the correctness of a software design is a function, not only of the code itself but of the team that's working on it. That's why a lot of the static analysis tools, I feel like they give you one piece of data but they are absolutely not enough to evaluate whether the code you have is the code that you need. I think that a lot of times, the static analysis tools are set up to reward a cleaner codebase, a staged house, like no trash cans out.

NOEL:  I find that kind of static, like the static analysis of long methods, long lines. I find that stuff to be generally of relatively minimal value. There are some things that some of those code climate kind of things do that I do find interesting but the simple... like this file is going too complicated, this method is getting too complicated... I don't find that more helpful than my own intuition about how my team is reacting to the codebase.

SARAH:  That's true and I think that Code Climate and things like that, there's a couple of really interesting things that they can do for you. One is for example, Code Climate has this thing that's a plot of churn against complexity so if you have a file that is both high complexity from as far as static analysis can figure out, meaning it's hoarded, and it changes a lot, meaning the churn is high, then that is a good way to identify, oh, maybe if we're thinking about in trying to make this better, that might be a good target to look at because if you manage to make that easier to work with, because it changes so often, it'll be higher reward.

NOEL:  Right and conversely, even if you have stuff that's high complexity if nobody ever touches it, then it's not necessarily a good use of your time to polish that room. You don't necessarily need to clean the attic.

SARAH:  Exactly and if you've got the one cabinet that housed all the Tupperware in it but you never use the Tupperware, it doesn't really matter if when you open the cabinet it all falls out because you're not going to open the cabinet. Like you've got a closet in the spare room that has all of the random stuff you don't know what to do with, well as long as you don't need to do anything with that stuff, you can just leave it there.

NOEL:  There are a couple of questions that come to mind. One of which is how do you start to calibrate what the right level is for your team. I know that I feel a tension between my, for lack of a better word, CS hat wanting to make everything clean and my consultant -- I'm going to have to actually do work in this hat -- how do you calibrate that for your team?

SARAH:  There's a couple of different ways to do it. One thing that I found useful is to run a retrospective meeting, specifically about the code. Now the way that I usually do retrospective meetings as they're usually about the process. Now, if you look at them from a traditional Agile point of view, a retrospective is your chance to reflect on the process itself. It's sort of a meta thing but I have found that if you give the developers a chance to list all the stuff that they don't like about the code and all the stuff that they do like about the code, that can give you a lot of insights into what would be good to have more of. It's important to make sure that they can have stuff in the good column as well. Sometimes, it helps to have them think about this ahead of time.

Also, like what stuff is in the bad column? What are they finding difficult? If you've got something that's really abstract and people are finding it difficult to trace through, then that's a piece of information. If you have something that's very abstract but it doesn't show up on the list in either place, it's another piece of information. It can be good to do these regularly just because if you have them regularly, people think of things and write them down and can bring them to the meeting and because you touch different pieces of the codebase over time. I think that over time that can give you a good sense of like, "This part seems to be a bit problematic. This part, no one has ever brought up and this part everyone always puts in the "like" column so we should do more like that."

NOEL:  We just had Michael Feathers on this and it's actually released today as we tape this and we were talking about the thing that I was bringing up which is the sort of the Boy Scout campsite role which is to leave the code a little bit better that you find it every time you make a change. That has the advantage of you're only changing the things that you're touching, anyway.

SARAH:  Absolutely. I think that the difficulty with that rule and I do talk about that a lot, although I call it the Girl Scout role because that's where I come from. We have that rule too, by the way in Girl Scouts.

NOEL:  I was neither one because I was not a camping kind of scout, kind of kid.

SARAH:  Yeah, anyway. But I think the difficulty actually, though is that people disagree about what better means. Especially, if you have folks that are more on the less experienced end of things, they may not know what that means, like what does better mean. I would love to assume that everyone is pair programming with all of their junior developers all of the time but I know that's not realistic.

It's often helpful then to have a set of guiding principles for the codebase is I think about it, which gives people at all experience levels a very concrete advice about what better means in the context of this team.

NOEL:  What are some of the kinds of things that you would consider principles of the codebase.

SARAH:  I've struggle with sort of the title for this type of thing. Sometimes I think about them as goals, sometimes I think about them as principles. But for example, I had a client who one of their guiding principles was we want to make this codebase more accessible. We want to reduce our on-boarding time. We want to make it more understandable to people who aren't -- in this case -- Ruby developers. Because they were having a hard time hiring Ruby developers so they would bring in folks from other technologies and they had a really hard time picking it up. 

Some of that had to do with their use of metaprogramming and other stuff that a lot of other languages don't have. What that meant though, was that it gave them a very concrete way to decide how to structure a small piece of code. For example, if you're looking at something where you need to add a conditional, there's a lot of different ways you could do it in Ruby. You could either do an if statement. You could do a ternary operator. You could do a string interpolated method call. You could do a lookup table. There's a lot of different ways that you could do a conditional.

This is where the rubber meets the road, like what is better mean in this situation. There are people that would argue that a ternary is better because it's shorter and less code is always better. There are people that would argue that an if statement is better because it's just more straightforward. There are people that would argue that once you have more than three things, you would want to do it as a hash lookup, interpolated method call or something.

You know, there are all these opinions almost like personal preferences how we tend to argue about these things. Or idioms. We say idiomatic a lot, which really It just means that we like it that way but if you look at it in the context of we want to make this codebase more accessible to developers from other languages, probably the if statement, right?

NOEL:  If statements are pretty universal.

SARAH:  They're pretty universal. People don't have to figure out what interpolated method call is. They don't have to figure out... it's able to be searched, it's able to be understood by people from a wide range of disciplines.

NOEL:  I used to co-teach a Ruby course with another person and we would continually got to the point where we were comparing a ternary operator to an in-line if statement, returning a value and the students would inevitably ask which one we would like and simultaneously, I would say the if statement and the other person would say, "The ternary," because he liked the conciseness and I liked the readability.

SARAH:  I think that those are both valid reasons and those are both useful in different situations. Say for example, instead of you wanted to make your codebase accessible to people from other languages. Say for example, instead you wanted to make it faster for a senior Ruby developer to on board. In that case, you might go the other direction.

NOEL:  And one thing about that is that you can mix team and more objective goals because you can easily mix in just pure performance as a goal along with on-boarding or along with testability or extendibility or whatever else you want.

SARAH:  Yeah, I think so. I think that a lot of the times when people argue about the different structures like that, they do have reasons for it but sometimes it's very difficult to articulate it so it falls down to words like testability or extensibility or conciseness. Those are all good things but basically you need to be able to rank those in order of importance for your team and to be very specific.

That's pretty hard to do that because they're going to be different situations in which, a blah-blah is better than that, more important than this over here but not important over there. I feel like the guiding principles which are one level away from the code versus that. Because they're more concrete, they're often easier to apply or they are applied more consistently. When you do a code review, you can talk about it in terms of that, rather than in terms of personal preference or idioms or anything else. You can just be like, "This is our goal and I feel like this structure advances that goal." Then the other person can be like, "I feel like my structure advances the goal better because X," but then you can have that conversation in the context of a goal, instead of in the contents of the personal preference.

NOEL:  I remember the word 'maintainability' being a big bugbear for DHH a couple of years ago. And that's the same kind of thing. It's an abstract goal that is often used without a concrete context around it so it can mean whatever you want it to mean. Often, when you start dealing with abstract goals like that, it's often useful to have the next part of the conversation be "how" like, "How does this make our codebase more maintainable or accessible or on-boardable?"

SARAH:  Right, exactly. Especially in those conversations, one thing that I've noticed at clients that have teams of mixed experience levels is that in these code review conversations or when they're pairing, sometimes developers that have more experience will fall back on either like, "In my experience, this is better." Or in sort of the pathological case, it gets as far as like, "I've been in software for 20 years and I've never seen anything that would want you to do this or the other way," and it leaves the less experienced developers at a huge disadvantage in these conversations because they can't really argue against that.

NOEL:  Right. You can't say, "My six months of experience leads me..." I guess the only case where you can do that is if you actually have a counterexample but then you have to get the person to listen to it which can be hard.

SARAH:  Right and that said, the folks that have less experience have extremely valuable information and the information that they have does someone with six months experience understand this. That is extremely valuable information.

NOEL:  This is asking questions as junior developer superpower, which is something I think Katherine Wu said in a talk.

SARAH:  Yeah, definitely and that information is really, really valuable because you need to write code that your entire team can work with.

NOEL:  This tension between the experienced developers on a team and the junior developers on a team is something that you have been tweeting a lot about and this is something you talk a lot about. When it comes to this guiding principle or structuring your code, how should senior developers work with more junior developers to put that together? How should they use those in their interactions?

SARAH:  I'll start with the second half of that first -- using them in the interactions. I think it gives senior developers a way to articulate the reason why they want to do something. Rather than just being maintainable or best practice, I read it in a blog post or whatever, they can be very concrete about it. It gives them an opportunity to look at that and be like, "How does this advance that goal. Let's talk about that."

Then it's an opportunity for them to explain things in a more concrete way. A lot of these conversations tend to be, "Maintainable is better. It needs to be changeable," and these are sort of received wisdoms in the software community but there's a huge value in taking that down a level to be more concrete. So talking about it in those terms, also allows the less experienced developer to contribute on those terms. It's easier to say, "But would it also advance the goal if we did it this way," than it is to say, "What if we try this thing that goes against your 20 years of experience. Wouldn't that also be fine?" It's easier to get them into a place where they feel safe surfacing that information when you're talking about it in terms of codebase goals than it is when you're just talking in a more general way.

NOEL:  We were talking here not just about a goal, like Livable Code, as you're describing it seems to be not just a function of the codebase but a function of the entire team, 

SARAH: Absolutely.

NOEL: that you're structuring and guiding your code to be developed in a way that you get the maximum amount of input from both more experienced and the less experienced members of your team.

SARAH:  Right. Less experienced members can't contribute or it's more difficult for them to contribute to higher level architecture discussions. But they can give you a lot of interesting feedback. Because of this issue with abstractions and being able to hold abstractions in their head, however they can give you a lot of information about the very concrete things you're doing and that can help inform how you do some of those larger abstractions.

NOEL:  I can imagine somebody listening to this so far and having their takeaway be, "Sarah is telling us to write worse code to string the juniors along."

SARAH:  Yeah, I get that a lot.

NOEL:  I don't think that's true but I'd like to hear you explain why.

SARAH:  I come back to this house analogy a lot. When everything is put away all the time, it's very difficult to live in that house because if you need to go into the kitchen and make some food, then you immediately need to clean all that up and put it away. You may not be able to find things. You may be like, "Oh, shoot. Where did I put the wok? Well, it's not over here. Maybe, I put it over there," and if you do that every day, you're wasting a bunch of time looking for the wok all the time.

It's hard to imagine this, I think in a code point of view but if you think about it as a houseful of people, the clutter that you need for a particular group of people in a house will be different, depending on who those people are. What you need out when you have an infant: baby bottles, a pack-n-play, board books, guardrails or whatever it is.

NOEL:  I think, specifically for the analogy, guardrails.

SARAH:  Right. It's different than what you need out and around the house when you have older kids. It's different from what you need out and around the house if you're a bunch of college age roommates. In that case, maybe you've got a bunch of videogames stuff out and you've got this table that you always use for parties or whatever it is like there's a different set of clutter that works for each group of people that's in a house.

NOEL:  Yes, I guess what I can takeaway from that is that we have a knee-jerk reaction to the idea that a minimalist codebase or a very spread out small factor codebase is good in and of itself. What we're saying is that impulse is not necessarily as correct as you think it is.

SARAH:  Right and that can be good. There are certain teams of people for whom that will be great. If you've got an all senior team and you're working on this thing, that can be great because once they load it into their head, they're going to be very fast to add things. But the minute you want to add someone with less experience, then it's not so good.

NOEL:  What do you think of the role of career development here? I can also imagine somebody saying that the goal then should be like, "We keep our cool minimalist design. We just train the new people to pick up after themselves." Is that also a goal? How do those two interact?

SARAH:  Well, you can think about it like if one of these people has a super minimalist house, then there's going to be a much smaller set of roommates that you are going to be happy living with. Then there is, if you are not one of these minimalist people, then there's a broader spectrum of people with whom you would be happily cohabiting. It's the same with a codebase.

Every time someone comes into the team or leaves the team, it's like getting a new roommate in the house. They've got their own ways of doing things and you can either take this hard line of like, "This is the way we do it," and they can conform. Or you can take the line of, "Now, we all live in this house together, let's reassess what we do, like what our rules are and where we leave stuff out and when do we do dishes." All that stuff is -- and should be -- open to re-evaluation every time that group of people changes and it's the same thing in a codebase. You can either have a codebase that can be worked on by a very narrow group of people.

NOEL:  But I guess my question then is, you're right, there's only a small group of people that can work on this codebase but to then what extent do you say like, "We'll find a person and we'll train them."

SARAH:  That's always an option but a lot of times, people can't wait that long. I do see this happen, especially in very large organizations where because they have so many people working on the codebase, it's important for it to be consistent. It's important for you not to leave a mess out because some other team on the other side of the world might accidentally step in it.

When you've got a team that's big enough that they can't all talk to each other, then these types of abstractions become more important. But I think that when you have a team that small enough that you're all in contact with each other or if you have a team that is in the same location or if you're not Salesforce.com, if you're not IBM, if you're not HP, if you have smaller teams or even if you are one of these, you can have a codebase that you can work faster on and get more people into and make better progress.

Some of the consulting I've done has been for large companies and a big part of the problem for them is that they have these practices that they have adopted for codebases that are worked on by thousands of people. Then they take those practices and they are surprised when it slows down a group of five people. A lot of figuring out how to get a large organization to 'innovate again' is showing them that, "You don't have to do all of that stuff for a codebase that these five people are going to work on."

NOEL:  Right, because a lot of that stuff is communication and process and you need to communicate and process in a different way when you have a thousand people where you can have everybody can sit around a table in front of a white board.

SARAH:  Exactly. When you have a case where people are sitting around a white board, a lot of these people probably are coming from a situation where they're used to this set of larger processes so we don't necessarily teach very well the skills for figuring out when a process fits your team's size and when it doesn't. I don't blame them for necessarily trying to apply what they know into a smaller group but I think that a lot of the very abstract stuff comes from a place where it was a government system with several thousand people working on it, in different places all around the world.

NOEL:  What can I do on my particular team? Now, I have my five to seven person team and it has got a mix of seniors and juniors and maybe it's a slightly well-established codebase. How can I use that to guide the choices that I make as I'm architecting in my code?

SARAH:  There's a couple of things that can be useful here. One is to think about the codebase as explicitly as a place that we're all living in and that we need to be aware that there's going to be people coming in, looking at this piece of code -- even if I own it right now -- but there's probably going to be people coming in and looking at it that are less experienced.

NOEL:  I want to try to pull this into an actual code example and not another architecture analogy, which is fine. I'm building a new feature for this and we're trying to build in discount codes for this point of purchase thing. That has a tremendous amount of potential complexity and normally, a tremendous amount of future proofing, like this is something that might change a lot. I, now have the option of I can make a very abstract workflow that talks to a bunch of different abstract classes but maybe, I probably shouldn't do that on my own. Maybe I should start by talking to the other members of my team. How would this process play out in practice?

SARAH:  Something like that is an incredible opportunity for your team because they have an opportunity now to see how it moves through these levels of abstraction. What you could do is start out by doing something very concrete that solves the problem at hand. Then something else comes in and you're like, "This is looking a little awkward now. This method is really long. This thing is now hard to change. I'm going to take this up one more level of abstraction and look, it cleaned up this part of the code," so you can take them along on that journey as it goes from very concrete to a more abstracted design. I think the process there is important. You can't just be like, "Here's my abstract design. We're done." It's more like, "Let's go through the steps. Let's see how this actually happens."

NOEL:  This sounds like very Agile, sounds like YAGNI -- you ain't gonna need it -- kind of design. You start with a concrete thing that solves the immediate problem and you explicitly don't try to outguess the future.

SARAH:  I think that it's okay if you want to guess but just don't code it up yet. A lot of times, as you get more experience, you will be able to see where it's going, probably or you may not. There's a lot of situations in which things end up differently, do you start out with something small and evolve it versus if you conceive the whole thing and build it. Both of those approaches will work, usually. It will end up with code that actually does the thing you want but they're not going to end up at the same place, even if it's the same person doing it.

NOEL:  The thing that the XP people always used to say was that you're just as likely to be wrong when you guess about the future as right so the goal is to make it flexible, to make changes in the future, rather than make it super abstract to start.

SARAH:  The difficulty with statements like that though is that some people would equate flexible to change with very abstract trait.

NOEL:  As that was coming out of my mouth, I was realizing that was not maybe the best way to phrase it.

SARAH:  What that means to me is that flexible to change is not an absolute concept, in the same way that good design is not an absolute concept. It's a concept relative to the people on your team. Flexible to change probably includes could somebody else change it? Could the least experienced person on the team figure it out and change it? That's part of changeability.

NOEL:  Flexibility to change to me also means, "Do we have tests to determine that we haven't broken anything?"

SARAH:  Yeah, absolutely and that's part of if they've got a process where you would make a change and then run the suite of tests, they need to have confidence because they haven't loaded the whole system into their head yet. They need to have confidence that those tests will tell them if something else has gone wrong.

NOEL:  Do you see as testing as having a particular role in this? Is testing something that you would bring up as a guiding principles of the codebase, we want this codebase to always be testable or we want to test in a particular way, like this testing help?

SARAH:  I don't think of it as a goal in and of itself but I think that it is part of what changes as your principles change. For example, if you wanted to make your codebase more accessible to new developers, that would suggest -- in some ways -- that you might want to do more top-level integration tests, which would then explain to them how it's working at a high level. As opposed to a codebase where you don't do very many of those and you just lower down unit tests where you would still have to trace through the code to figure out what's going on. Right, so your testing strategy is also informed by these goals.

NOEL:  The integration test strategy is sort of the Rails core DHH approach to testing in the Rails community as opposed to the more unit test structure. I think that's an interesting compare and contrast to the way that you're talking about: livability and principals, because certainly, Rails core operates along a particular set of principals in creating their codebase.

SARAH:  Yeah, they absolutely do and the interesting thing I thought at RailsConf this year was that you could see it shifting real time. They've hired.. Basecamp, in particular which is the company that does Rails, has hired a bunch of newer developers and you can see it shifting in the way that they talk about their code. I would look for some really interesting changes to come out in the next couple of years.

NOEL:  Changes to Rails because you think that's interesting. What direction would you guess?

SARAH:  That I'm not sure of but I think it's a big change. They've always had a team -- well, maybe not always but for a long time, I had a team that was mostly on the mid to senior end of things. That's a definite point of view and you can see that in Rails itself. You can see it in some of the additions that have happened over the course of the last five or six years too. You can see, for example that over time, they've gotten more sophisticated about JavaScript and frontend development. You can see that.

NOEL:  That's a fascinating novel in its own right.

SARAH:  Oh, yes it is and so I think it's easy to see in retrospect, it's hard to predict given current changes but it seems like a significant enough change that we will see something come out of it. It's hard to say what.

NOEL:  I do think they've gotten a lot more explicit about, "These are what our principles are and we're going to try and do things... like we have principles." Maybe like, "This is not the only way to make a codebase but this is the way we believe in."

SARAH:  This is the way we do, yeah.

NOEL:  I think that's the change, whereas a few years ago, a lot of the rhetoric was, "This is the only way that works," and I think now it's a little bit more, "This is the way that works for us and we're going to try and keep doing it that way."

SARAH:  Right and doing something like a framework is a very delicate balancing act between "works for us right now" and "will appeal to a large number of people." I think that is true that there are certain patterns of code that a lot of applications can fit into and that people can understand even at a very beginner level.

NOEL:  Yeah, I think that Rails is a really interesting example here in terms of, although I don't think he would use that word, I think that DHH is really tried towards livable, like he certainly never been interested in object purity for object purity sake.

SARAH:  Yeah, that's for sure. Or testing for testing sake.

NOEL:  Or testing for testing sake, sure. Yes, I have my own scars about that one. But he's always been concerned with the programmer experience, I guess originally, as he saw it and now I think more as he sees other people experience it.

SARAH:  Yeah and I think that is a really interesting evolution from Ruby itself, where one of the original principles for the language was programmer happiness and DHH really strongly attached to that and was one of the reasons -- at least from what I remember -- as to why he chose Ruby to build this framework. He's taken that principle and that's a hard one to keep a hold of, I'll be honest because a programmer happiness is what type of programmer, how much experience do they have, what kind of things do they like to do, right?

NOEL:  Right and there's all kinds of things in Ruby that make you happy the first time you do them and then make you a lot less happy the 10th time you have to clean up somebody else's mess because they did that.

SARAH:  Right, that is very true and I think that making things easy is definitely like there's a spectrum there. This is a large part of why you don't see huge codebases with thousands of people working on them that are dynamically-typed, for example. Types are one of those things that work as a formal communication mechanism for very large teams at the expense of individual programmer happiness.

NOEL:  Right, there are kind of process in that sense.

SARAH:  They are. They absolutely are and we don't talk about them that way but that is basically how they are perceived. People say, "You need to have types," and what they really mean is when you're in a team like I am in, types serve a useful purpose in our technical communication.

NOEL:  It's going to be really interesting to me to see the Rails community collide with webpack and the JavaScript community. The JavaScript community as expressed through build tools like webpack, which I don't have a complete first-hand experience with but they have certainly a much different definition of those livability tradeoffs than the Ruby community and the Rails community. It's going to be very interesting for me to see what happens with webpack being essentially a first-class member of the Rails framework.

SARAH:  That's an interesting distinction to make. The JavaScript community has a lot of very experienced developers so my take on that is that people develop these philosophies because they are guided by the contours of the language itself. There is something about the language itself that has guided these two communities, in two different directions. That's interesting, right?

NOEL:  That gets complicated. People choose the language because it matches what they like and then the language affects how they express what they like and it is sort of a chaotic attractor there, I think.

SARAH:  Yeah, that's true.

NOEL:  But I think what struck me at RailsConf, particularly, was Rails built up this entire system testing framework. One of the goals of which was to avoid having the developer type in like six lines of Capybara configuration, which is great. I don't like typing those six lines any more than anybody else does. But then webpack is like a gajillion lines of configuration and it's hard for me to see that the community is not going to try to sand some of the edges off of that.

SARAH:  The ttitude towards JavaScript has evolved over time. When JavaScript first started getting really popular, there were a lot of people who were like, "These people are doing it like that because they are inexperienced or because they're not real developers or because they don't understand." I think we've arrived at, perhaps a more sophisticated understanding of this phenomenon which is that the things that we choose are largely guided by things that we're not necessarily fully aware of, things like capabilities and restrictions of the language. There's even aspects of like how does the community want to communicate with each other. That can literally affect how code is written.

NOEL:  I think really early on the fact that the developer tools and JavaScript are further behind the other languages are kind of a circular... The tools aren't great so it's hard to build large programs so JavaScript wasn't perceived as a language you could build. The perception of JavaScript programmers was colored by the tools in kind of a weird circular way. Then the tools got a lot better very, very fast.

SARAH:  Because as it turns out that if you put a bunch of programmers who are experienced at JavaScript and ask them to think about tools, things happen.

NOEL:  Is there something else you want to talk about before we finish up?

SARAH:  The main thing that I want to get across, I guess is that the right design for your codebase and your team is different from everyone else's codebase and everyone else's team. It is a thing that needs to adjust every time someone joins the team, every time someone leaves, probably. The static analysis tools and so on can give you a certain amount of data about what your code is like but it's really less about what it's like and more about your experience of it.

NOEL:  So read POODR but don't assume that you have to implement it perfectly in your codebase. That it is exactly the right thing for your codebase.

SARAH:  Yes. Sandy says that a lot but I think that people miss that.

NOEL:  Right. Sandy will say that no methods should be more than five lines but people miss that that was in a particular context that you're trying to solve a particular problem for a particular team.

SARAH:  Right and there's a lot of situations under which that would be a good idea but it's not on every situation. She's the first to acknowledge that but I think that some of that nuance gets lost.

NOEL:  Some of that nuance gets lost, the internet story.

SARAH:  Right. A story of the internet.

NOEL:  Okay. Well, thank you so much for being here, Sarah. I'm really glad to get a chance to talk to you more likely than I normally get a chance to talk to you.

SARAH:  Yes. It was nice. Thanks for having me.

NOEL:  Where can people reach you, if people want to reach you?

SARAH:  To be honest, Twitter is probably the easiest way to reach me. I have difficulty with email but Twitter DM's are always a good thing.

NOEL:  So that's @SarahMei?

SARAH:  That's right.

NOEL:  Sarah is telling you to DM her on Twitter.

SARAH:  Maybe not all at once.

NOEL:  Okay, thank you. Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. You can find Table XI on Twitter at @TableXI and me at @NoelRap. The podcast is edited by Mandy Moore and you can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded via iTunes or wherever you get your podcasts. You can send us feedback or ideas on Twitter at @Tech_Done_Right or subscribe to our newsletter at TechDoneRight.io/Newsletter.

Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. If you're interested in working for us, we just opened up a couple of job listings that you could find at TableXI.com. We'll be back in a couple of weeks with the next episode of Tech Done Right. Thanks.