053 JSJ Software Team Dynamics

Download MP3

Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013!



02:48 - External Conflicts

  • Dealing with people outside your own team 07:04 - Areas of Expertise 08:45 - Expectations and Deadlines
  • Multiple Layers of Hierarchy
  • Differences in Goals 13:47 - Flatter Structure Approach 15:21 - The Search for Developers
  • Finding the ideal people
  • What makes an ‘A Player’?
  • Intellectual Capability 19:47 - Team Scaling/ Scaling Agile
  • Scaling Agile @ Spotify
  • How Stripe Builds Software, with Greg Brockman 25:10 - Team Diversity 29:57 - Team Dynamics
  • Attitude
  • Different: Escaping the Competitive Herd by Youngme Moon (Joe) 35:00 - Specialization 40:08 - Dealing with someone you don’t like
  • Circumventing
  • Confrontation 50:52 - Dealing with a non-engaged person


Next Week

JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat


CHUCK:   So, team dynamics this week? JOE:  Sorry, is that our discussion or is that what we decided to call ourselves? [Laughter] CHUCK:  It’s our discussion topic this week. AJ:  We are Team Dynamics. JOE:   Because if we’re going with names, I would like to submit the Wolverines. CHUCK:  The Wolverines? I think it’s taken by a University around here. AJ:  Yeah, and my high school back in Virginia, and that dude from New Zealand who plays in X-Men. CHUCK:  That dude? AJ:  Yeah, that dude, Hugh Jackman. CHUCK:   [Chuckles] [Hosting and bandwidth provided by the Blue Box Group. Check them out at **Bluebox.net**.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to **Wijmo.com ** and check them out.] ** CHUCK **:   Hey everybody, and welcome to Episode 53 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:   Hi there. CHUCK:   Jamison Dance. JAMISON:   Hello, my mission is to bring calm to the boiling cauldron of hate that is the Internet. CHUCK:   AJ O’Neal. AJ:   Yo! Yo! Yo! Coming at you live from the pulling my hair out over Iowa. CHUCK:   Merrick Christensen. MERRICK:   What up? CHUCK:  I’m Charles Max Wood from DevChat.tv and don’t forget to use that code to get into Fluent Conf. MERRICK:   It’s a big conference. You can go to FluentConf.com for the schedule, happens May 28th to the 30th, it’s at the Hilton Union Square in San Francisco. And for our listeners, you can actually get 20% off on your ticket using JAVAJAB. And that will give you 20% off on the registration. CHUCK:   This week, we’re going to be talking about team dynamics and all the fun stuff that goes with it. To start us off, I kind of want to ask because I always get good stories from people when I ask questions like this. What is your worst team experience? JOE:   That’s quite a way to start it off. It sounds like a good way to get me to burn some bridges. AJ:   No, no, I know this one… JAMISON:   I played little league and I was scared of the ball. And I had the bat and I was really short and they wanted me to bat first because I’d be walked all the time to get on base but I just wanted to quit. I wanted to quit so bad because I didn’t want to get hit by the ball. That was my worst team experience. My parents wouldn’t let me quit because they wanted me to develop, stick with it to a [inaudible]. MERRICK:  My worst experience was this podcast I did for quite a while. [Laughter] AJ:   Youch! MERRICK:   Where they asked me very, very tough questions, personal disturbing questions. CHUCK:   I have to say that I’ve worked on a lot of teams. They all had their own dysfunctions. It seems like though the most, the worst part of any of them was always dealing with people outside of the team. So, you deal with the developers and sometimes there’s that guy you don’t like. But most of the time, your issue is communicating with the outside group. So, your product owners, your Product Manager, your Project Manager, depending on how good they are, usually you have a problem with at least one of them and the way that you can or can’t communicate well with them. Is that something that you guys have seen? Or have you seen more problems within the team between like with the developers? AJ:   It’s when you’re in school, and the teacher is the team lead, and the team strategy is no teams. [Laughter] MERRICK:   I think that is one of the biggest problems is conflicts externally. I think in development, it’s really tough to manage expectations from people who aren’t developers. JOE:  There’s just a natural dynamic as well that you’re always going to clash more with people that are not part of your team. Whenever you’re dealing with any, whatever group you’re dealing with, if you’re dealing with another group, then you always feel more loyalty towards your own group than the other group. And so like, if it’s development and project management, there’s some disconnect. But then when you go to like to my company versus your company, and there’s disconnect. It’s whatever. There’s a natural human dynamic to be more loyal to the place or the group that you’re closest to. That’s just natural. But Merrick’s point is definitely true that there’s so little recognition about what software engineering is like, even among Engineers. So, when you take it outside of people that aren’t Engineers or that used to be Engineers and everybody else wants to control an uncontrollable process. MERRICK:  Yup. CHUCK:   Yeah. In the project I’m working on right now, and I’ll just be working with them for another week and a half and then the project ends. Incidentally, if you have Ruby, JavaScript, or IOS work you need done, let me know. Anyway, it’s been really interesting because we’ve been dealing with these product owners who started out basically designing our software for us and there have been some conflicts over how detailed or not detailed they we should get and thing like that as we figure out our process within our Agile, if you want to call it that process. And so, we’ve been fighting this battle over understanding how far they should go and how far we should be deciding. And it’s been really, really interesting; some of the conclusions that we’ve come to and some of the things that we’re still struggling with. But I’m really curious to hear what you guys have to say about some of it. So, I’m just going to throw this out there and then we’ll get your opinions on it. But basically, the way we broke it down was that the product owner should be giving us what they care about. For example, the thing that I’ve been dealing with today with them is they want to add settings to the application and then, they want to be able to have the users go in and basically override the defaults when they care about those settings. So, I’ve been pushing them toward what do you care about? Do you care about that they can change it? Do you care about that it has this certain level of functionality but you don’t care about things like the database design or how it’s implemented on the backend as long as it does what you say you want it to do. Is that generally how you guys approach this kind of thing? JAMISON:   I think any product person that’s not a technical person that’s trying to design your database is wilfully misguided. And you have terrible, terrible problems if that’s happening. I wouldn’t say that that’s how I try to approach it. I’d say that’s what happens. And if not, then bad things are happening. CHUCK:   Yeah. JAMISON:   It’s like saying I tried to approach my day by not dying and if I do that, then it’s all good. CHUCK:   [Laughs] JAMISON:   Yeah. Hopefully, the product person isn’t telling me like what framework to use or something because it’s no good. CHUCK:  Yeah. JAMISON:   We’ve talked about this a little bit because at i.TV, we’re trying to move to more of a flat style and we’re trying to figure out what exactly that means for us. It doesn’t mean -- well, it is a little bit chaotic because we’re getting lots of input from everybody instead of things coming down from the top, you know? But there are still areas of expertise. And I think that’s true for any team. There are designers who are very good at thinking up ways that people will like to use products and flows and things like that. And developers can have ideas about design but the weight of the idea is proportional to the expertise of the person giving that idea in the subject. So, I think that same thing should apply for product people, right? They can have ideas about technical things. But if they don’t know anything about technical stuff, then their ideas aren’t -- they shouldn’t be given that much weight if they disagree with people that know a lot more about technical stuff. JOE:  It’s tough though because they always do. And I found that nothing sucks the joy out of development than unrealistic expectations. CHUCK:   [Laughs] JOE:   And it’s just tough to manage that. I honestly don’t know how to. CHUCK:   Yeah, I think it takes a lot of communication and obviously, we haven’t completely figured this out. It’s also interesting to me that for example, when I worked for public engines, CrimeReports.com, their Product Manager or the Project Manager was excellent. And he was really good about managing all of these different groups of people. And so, when we dealt with things over there, most of the time, we’re just dealing with him. And then, with these other companies, it’s different dynamics. And so, I think it really depends on who you’re dealing with as well. JAMISON:   So, when you’re talking about expectations there, are you just talking about deadlines? So, we think this stuff is going to be done super fast and the developers think it’s going to take longer? AJ:   So, tell me if you guys experience this because this is something I struggle with. You’re in a meeting and you’re sitting there talking about all the features. And there’s like multiple product people, one developer, maybe a designer, but really from a guy that’s doing the work, you’re outnumbered four to one. So, you have a bunch of people throwing ideas out and while you want to be able to get enthusiastic about these ideas, et cetera, they all come at a cost to you, right? They all come at more workload without usually deadlines fluctuating. So, you have to kind of play the devil’s advocate and kind of ruin the party a little bit and keep things realistic. So really, not only is expectations that I’m talking about like deadlines, sure, but also keeping future scope within deadlines, right? JAMISON:   So, you’re talking about the problem where it sounds a lot like scope creep. So, stuff has already been assigned to you, you already have deadlines. And then people get great new ideas and don’t realize that changing what you’re doing will change how long it takes to do it. AJ:   Exactly. And they’ll use the whole Agile argument to be like, “Throw out all that old stuff because it’s Agile, so it’s easy.” I don’t know. I struggle with it and it really sucks the motivation out of me. JAMISON:   Yeah. CHUCK:   Yeah. We have something similar that we fought in the past where basically we’d get a story and it was this wide open story. And the expectation was, “You’ll get it done in a sprint.” And so, we’re sitting there going, “Look, you just wrote a blank check and you’re asking us to cash it.” So, you start doing the same thing. You start defining what the requirements really are so that you can give them an accurate representation of how much work it’s going to be and when it’s going to be done which they don’t always like. JAMISON:   This feels really antagonistic. It feels like you guys are battling a lot and like you’re the enemy or your product people are the enemy. CHUCK:   Sometimes, it feels that way and sometimes, it doesn’t. It really just depends on who you’re dealing with and how attached they are to whatever it is they’re trying to accomplish. JOE:   Also, I’ve noticed that these kinds of problems are almost directly proportionate to the size of the organization you’re in. CHUCK:   This is true. It also has a lot to do with how much power any one person has. So if they feel powerless, they usually feel like they don’t have that much choice. So, they have to push and that causes issues too. So, somebody above them is saying, “You have to have these features done this way by this time.” So, they're coming in and you’re telling them, “No.” And so, they’re stuck between what the person above them said and the person who can actually implement it said and they're at odds. So, these poor folks are stuck in a situation that’s uncomfortable. JAMISON:   Actually that’s a good point. So, if you have a lot of layers of hierarchy and you have the CEO talking to the VP who’s talking to the Manager who is talking to the Project Manager. And at each layer, someone has to come up with a totally, pulling out-of-their-butt estimate for how long something’s going to take, that would suck to be that person. They don’t know how long it’s going to take. They don’t have any idea of what it involves even. So, how are they supposed to come up with a realistic estimate? MERRICK:   Exactly but the real problem is that people have different goals. Like the PM may be struggling to get one feature in while the CTO has promised some different features, and there may or may not be collaboration based on these things. And so, everyone’s trying to get in what makes them valuable down with the developer because if they can deliver X feature, then they kind of are able to justify their stay. JOE:   Or deliver it in a certain way or under a certain deadline or a certain cost. They each have different goals. MERRICK:  Yeah. So, what all of them end up doing is compromising on quality which is not a place you want to be, right? JOE:   Maybe. There are places where their goal is quality. There are people whose goal is quality and they’re pushing for quality. MERRICK:   Yeah and I think that has to be an organizational ideal. JOE:   But sometimes, there are people who, their metric or their personal -- what makes them valuable is to push the quality up. So, somebody else is pushing it down because they’re goal is cost. Somebody else is pushing in more features because their goal is getting a certain thing done. Somebody else is pushing that sort of stuff out because they want quality. Developers are kind of caught in the middle. CHUCK:   And I’ve seen different layers or different levels of these different conflicts at different companies. I don’t want to put this on any one company just because some companies do real well at one area and struggle with another. JAMISON:   So, this again seems like an argument for a flatter structure, right? The more layers of people that you have things filtering down through, the more opportunities there are for things to get messed up. JOE :  It’s just layers, it’s just the quality of people. But I actually tend to agree with the flatter structure approach. However, it doesn’t scale like I don’t know how to scale it. The biggest company I know that does it is Val’s. And they do it to a great success right? JAMISON:  But they are also small. JOE:   Yeah, they’re also a really small company compared to a lot of software development shops. They’re big in their presence but their employee count-wise, I don’t think… JAMISON:   I think there’s like 300 or 400 or something. But yeah, it’s not like a giant company by any means. They also have the luxury of hiring the smartest people that exist on the planet because of their reputation. JOE:   Sure. CHUCK:   Yeah. If you can count on everybody to do the right thing, then a flat structure is fine. And if you’re willing to weed out the people who aren’t going to do the right thing, then again, your flat structure is probably okay. But the reality is that the world, as a whole, is becoming more dependent upon technology and that means we need more programmers. And so, somebody’s going to have to hire the folks that you have to babysit. JAMISON:   I don’t know. CHUCK:   And the other thing is that some people really do well under more of a hierarchical structure. They’re terrific programmers, they do great work. They don’t necessarily need to be babysat but they thrive when they have a boss to report to as opposed to being in a flattened structure. JOE:   I like Jamison’s approach that really it’s like an open source project, right? If you can count on people to do the right thing and move the company forward because they share a common vision and they’re smart people, great. But in the search for developers that I’m sure all of you guys in you’re tech companies have gone through, and I’m sure you’ve interviewed people, those people are not as common as you’d hope. I think when business expectations come, you’re not always allowed to pick the ideal which is to get a bunch of people who want to do the right thing. Which those people can kind of be a pain sometimes right because all those people have opinions… JAMISON:   Yeah, it’s chaos. JOE:   …that you have to…right, it’s total chaos. JAMISON:  There’s lots of arguments, lots of disagreements and sometimes, people get grumpy. JOE:   What do you do though when business needs demand more people and those people take a lot of recruitment and there’s not as many of them as you need? You have to settle, right? If you have a bunch of A people, that may not still totally work. Sure, we hear about the success stories of 37 Signal, right? Eight A players building something that change the face of software development, right? But that doesn’t mean that there aren’t plenty of other examples out there of companies with eight A players that just crashed and burned horribly. We just don’t hear about it because they didn’t have a great success story. CHUCK:   I understand. I actually wanted to say something along those same lines. I mean, what makes an A player. If I get ten of the top developers in the world together and they can’t communicate, then I’m not going to get my crap done. And it doesn’t matter that they are the best programmers in the world. So there are other things, there are other intangible things that just somebody’s level of skill with a text editor or IDE, that mean success for a software team. MERRICK:   Sometimes being an A player is really just about where you’re at, at the moment. CHUCK:   Yes. MERRICK:   I got a friend who’s a developer, and if you give him a skills assessment test, he would come out not very amazing, very average. But as far as working with him and getting stuff done, I’d prefer him to just about anybody else. He’s just amazing at getting things done, and getting things done right and well and taking care of all kinds of crap. But he doesn’t remember every syntax off the top of his head. JOE:   So here’s my question though, development is a real art right? For example, Jamison could probably do things in significantly less lines of code, significantly more elegance, more maintainable than I could with Node, right? JAMISON:   Probably not. But we’ll go with it for the sake of your example. JOE:   My point is though of tiring the work horse is they could cause a lot of damage if they don’t have the same intellectual capability. Because just because it works, doesn’t mean it’s going to work for a long period of time. And just because it works doesn’t mean it’s going to be sustainable for future development. So, that’s what’s really hard about this is it’s not just like we’re just hiring people to lay bricks, right? They could potentially really hurt the future of the products. JOE:   Yeah this whole problem is really all about sides. I mean, if you think about the most effective experience you ever had with developing a project, my guess is you always say it was one of the smallest projects you’ve done. Would that be true? JAMISON:   I don’t thing I've ever worked on gigantic teams. So, I actually can’t really tell you. JOE:   Well for me, it was a team or two, me and one Project Manager. That was by far my most effective and best development experience. MERRICK:   Yeah from my experience, the smaller the team, the more productive we were and the more maintainable the code base was. But that doesn’t scale because you’re throttled. There comes a point where you have to trade technical debt, also bigger teams which can create technical debt even if everyone’s an A player. Because ideas are different, they can do things different ways and then you have technical debt because there’s two different cognitive patterns for the application. So, it just doesn’t scale. So, then you’re forced to essentially accept, some level of technical debt that you’re fighting to get the business needs out. And in this technical area, in this technical space where people are shipping products like all these different times, what are you supposed to do? You can’t compete unless you scale up this big old team. JAMISON:   What about dividing into smaller teams, though? So, you could work at a gigantic company but have small teams within that company. CHUCK:   The thing is you have to define the barriers, not the barriers but the boundaries between the two well enough so that -- I like the way that you said the cognitive patterns that don’t match up, Merrick, so that they do match up. JAMISON:   He’s talking about semi-colons versus no semi-colons, by the way. MERRICK:   Yeah, yeah. So, you have smaller teams. I’m sorry, Chuck, go ahead. CHUCK:   Yeah. But the places where you stitch it together, the places where your API’s line up, those you have to be very, very explicit about that so that even though the code doesn’t look the same on either side where they mesh goes together seamlessly, so that it does feel mostly like one fabric. MERRICK:  But then you have problems as an organization trying to move developers from team to team, right? That’s why you need some sort of standardization process where things are the same, relatively. You can’t have one team building with Angular and another team building with Backbone, and another team building with Ember because then your product is downloading three major libraries when it should only download one. So, you’re going to have performance problems. You’re also going to have team problems because moving guys from teams suddenly makes you less flexible. CHUCK:  Yeah, that’s true. You do have to settle on some standards. MERRICK:   So, the smaller teams come at a cost of fragmenting your code base into different schools of thought. CHUCK:  Yeah. And the thing that I want to point out here is that they’re trade-offs, right? So, you’re not saying that it’s not worth it to fragment the code base to get more work done. You just have to decide if the tradeoff makes sense. MERRICK:  So really, you have one standardization team per level of the stack, like a server standardization team and a client standardization team. And they essentially work with all the sub-feature teams. JAMISON:   Are they kind of the architects on each layer? MERRICK:   Yeah. You could consider them the architects for the stack but… JAMAISON:  Do they decide the application architecture or do they just decide technology stuff so like, really use this framework stack and this… MERRICK:   I would consider them -- I think the team, as a whole, decides the technology stack, right? Everybody, at first. CHUCK:   Gee, that’d be nice. MERRICK:  But it’s their job to make sure that the different teams are doing things consistent and not do book any work. And enabling those teams, right? For example, in a services team, if everyone is doing X, then that team should be responsible for making sure X isn’t distributed and that it’s in one place. So, you call them a framework team, if you will. JAMISON:  Okay. JOE:   There’s a lot of documentation and thought and blogs and books about scaling Agile and really just talking about software development which in our day and age is Agile and scaling Agile. There’s a lot of people out there talking about it, about their experiences in doing it, the sad truth is it’s really hard. Agile doesn’t scale well but that’s just because software engineering doesn’t scale well. And so batting that is very difficult. And by far, the best thing we’ve found so far is teams of five to nine and then how to get those teams to work well with the other teams is just really hard. So, you got to have just kind of scrums and do all these other practices of the architects that own pieces of the application just to manage the communication so you’re just not bogged down to try and get people to come to consensus and spend all your time doing that and no time building software. The more you can reduce the coupling and the dependencies, the more effective you’re teams can be. Whether that’s, they just build smaller applications, somehow divide up your application into smaller pieces and let teams -- most of the time, when Agile says that it works it’s dividing up by feature. So, you have one team that builds these features in this piece of the application and then you have another team that build these features in this piece of the application and they go through the entire stack. That’s generally accepted the best way to scale Agile. CHUCK:   Well, and it’s interesting that you bring that up and you kind of eluded or talked directly about some of those issues. But again, I think most of it boils down to communication again. So, if you have a smaller team or a smaller subset of your team that’s working on a single feature, then you can have high bandwidth conversations about that between three to four people and the rest of the team doesn’t have to be involved. And so, you’re reducing the amount of overhead that you have related to your communication. And then, the rest of the team gets communicated, “Here’s the API that you’re connected to.” And so, you build that up or break it down the way that you need to. And then, scrum or retrospectives and everything else are about communicating about the project, or about the process, or about some of these other things. And every time you add another person to the team, you’re increasing the complexity of the conversation, the complexity of the communication that you have to have. And that’s why the smaller teams seemed to work. One counter point I want to bring to that though is that I worked for a company where I was leading a team of four people. And the problem was that on that team, two of the people were just there to collect a paycheck. They weren’t engaged, they weren’t really involved. It wasn’t my decision to hire them. But anyway, all they really cared about was being there, writing whatever code they had to write for the day and then going home. And the problem it was, was again, it was more of a one way communication. There wasn’t a feedback, it wasn’t a terrific situation to be in. And sometimes, they or we would wind up building the wrong thing because again, we didn’t have that level of engagement. So that’s another thing that comes in with these things is that a smaller team, it has to be a smaller team with the right people. JOE:  Right. JAMISON:  So, one thing we’ve touched on a little bit is managing teams as they exist. And one thing I’m wondering about is the idea of creating a monoculture because if you’re interested in creating a specific style of culture, if you want good developers that can also communicate well, is there a certain kind of person that you’re going to hire then, that you’ll miss out on other kinds of people? We’ve talked about the superstar developers that maybe just don’t like to communicate or work with other people as much, they just kind of want to kind of sit down and bang out amazing stuff. If you value communication so highly, you’re going to miss that kind of person. Is that useful? Is that important? Can you afford to just hire a certain kind of person? AJ:   So, with my experience at SpotRF, we had a very diverse team, like in terms of skill set and personality. We had some people that really were just work horses in a sense that you gave them instruction and you said, “This is what I need done.” And if it involved learning, then it would take them like four times longer than anyone else. But then, once they got into the groove of it, then they would get it done four times better than anyone else. So, we had that type of person. We also had the more creative type people where you give them a problem to solve and they’ll solve it in seconds. But then, you want them to carry it through to like all the meticulous little details of it and then that part’s going to take them a long time because the creative problem solving really engages them and they can just burn through it. But then when it becomes more meticulous, then they’re just not as fast anymore. And then, people that are more into research like Jamison, when he was with us and when I was with us. [Laughter] AJ:   But I loved having Jamison because he researches stuff. He’s always got some blog article that is ready, always has a great idea about how something could be implemented because he’s just so into research. And so, if we were in a culture where we didn’t allow all this diversity where we said everybody needs to be the creative rock star, or everybody needs to be the work horse, or everybody needs to be the researcher, or that we didn’t value a researcher, any of those things, then the work would not have gone as well. We needed that diverse team of people that had different strengths and weaknesses to pull it together. And I feel like it was a really great experience with those people. CHUCK:  One thing that I want to jump in here with is that every team is different. So, in that situation, those folks fit in real well. In other situations, the people who take a long time to research something and ten go implement it, they wouldn’t fit on the team that I was on. So, it really, really depends. And it’s really hard to know whether or not somebody brings something to the table that you need without actually kind of trying them out. And so, I see a lot of companies doing like contract to hire or they’ll bring somebody in and just pay them as a contractor for like a couple of days to come in and work with the team just to see where they fit. But most of the teams that I’ve worked on, the guy that would go off and work in isolation and not communicate well, even if he was like a rock star coder, wouldn’t have fit well with the team just because we’re bringing somebody like that in, so that the team can benefit from their expertise and not just in, “Okay, go do the hard stuff for us.” JOE:   Right, absolutely. CHUCK:   So, with some of these problems or some of the dynamics with the team, have you had people on your team that really helped the dynamic? And what were they like? JOE:  Well, always the less volatile personalities make a big difference. CHUCK:  The less vocal personalities? What do you mean? JOE:   Volatile. Meaning like someone’s not abrasive, they’re better. No one wants to work with a dick is the truth of it, right? [Laughter] CHUCK:  Yeah. So, where’s the line then between somebody being a dick, so to speak, versus somebody who voices concerns and is willing to disagree with other people on the team in order to explore a problem? JOE:  Much like pornography, I can’t define it. But I know it when I see it. [Laughter] JOE:  Sorry for the vulgar language that was not intended. But I think it’s a lot of just the approach. You can attack somebody or you can focus on the problem and there’s a huge difference. CHUCK:  That’s fair. JAMISON:  I think some of it has to do with the attitude of the rest of the team as well. Like if your team is getting along and is generally happy, then it’s a lot easier to disagree productively without being perceived as being a jerk. But if people are kind of grumpy at each other already, then innocent technical disagreements can be perceived as, “That guy’s just a total jerk.” They’re just a contrarian. So, I think a lot of it has to do with the health of your team. And a sign of a healthy team is being able to entertain spirited debate. MERRICK:  I think that’s so true. I think it’s hard though because for some reason, in the technical world, or at least in the professional world, you forget that what composes a business is people. And people’s emotions have a really strong effect on their productivity. So, it’s important to stay positive right where it’s really easy for nerds to get really negative and cynical. And also to treat people like the best employee you could have is a robot and I think that’s one of the most dangerous things an organization can do. But it’s very much so the way that the corporate world works. JOE:  There’s this fantastic book called Different. And I’m totally going to put that into my picks. It talks about the fact that we tend to homogenize ourselves. They are specifically talking about products but they kind of take it and apply it to people as well. That we have all these strengths as people and we have all these weaknesses. And when we go and we have our review with our Manager, what’s the only thing we hear him say? “Well you got a work on these things. You got to get better at this.” He never says, “You’re amazing at this. We’d love you to get better at that.” And so, we homogenize ourselves. For me, I worked with this guy who was just by far the most amazing person technically that I’ve ever worked with outside of possibly Merrick. But he was a little rough to work with sometimes. MERRICK:  Me? [Laughter] JOE:  No, I said besides Merrick. So, he was a little rough to work with sometimes. I was a couple times blatantly mad. But the guy was amazing to work with. I loved working with him because he was really smart. And he got things done really well. And most of the time, he was just really, really, really good to work with. But the bosses were always like, “Well, you’re not working well with other people.” It’s like, dude, this guy’s value is in the fact that he is getting things, doing some amazing technical stuff that really benefits everybody. His value isn’t that he’s easy to work with. Yeah, it’d be nice if he was easy to work with but if he works on that and forgets all about the stuff that he’s really good at, then that’s not going to be the kind of employee that you want. CHUCK:   Yeah. JOE:   You don’t want robots. You want people who have strengths which kind of constricts what I was saying, nobody wants to work with a dick, right? So, we still have to keep that in mind. But we all have our strengths and weaknesses. Some people are just good at staying focused and pounding stuff out. And some people are good at solving problems, some people are good at designing solutions, some people are good at communicating. And some people are good at managing the team and keeping the team even keel to be positive. MERRICK:  Something that I think is amazing for me, and granted, I’m a pretty sensitive guy. So, when I have a Manager that pays attention to something that I’m struggling with, like after a meeting where I feel the wrong decision was made. Instead of wanting to talk more about that, they’re more like, “Dude, how do you feel? How can I help you?” They’re more like addressing the human side of me, so to speak. The emotional side or being just aware of people’s lives, et cetera, has made all the difference in my attitude for where I work. I think when a team member asks you what’s wrong if you look upset, it goes a long way for building a team. CHUCK:  Yeah. So, we’ve talked a little bit about specialization and I’ve seen specialization both help and hurt teams. So, you’ve got the guy and he has that skill that really pays off for the team one way or the other. How do you disseminate that? Do you do pairing? Because I’ve seen that work before, are there other ways of doing that? Then at the same time, how do you avoid the problems with creating silos, expertise silos within your team? JAMISON:  I think there are two kinds of specialized skill that you’re talking about. One kind is the technical knowledge, like someone is a wizard at postgress or something like that. There’s also the application-specific skill where this person built from scratch this one application and they’ve worked on it forever. Those are very different because one is really good and one is really bad. And I think having specific expertise in technologies is amazing. But having all of your knowledge about one system in your app concentrated on one person is really bad. I think you can distribute the technical skill by pairing and stuff, but it’s also just as important to distribute the knowledge about parts of your application, probably more anyways. MERRICK:  I think it’s a matter of attitude too, in terms of learning. Like, I heard once that if you’re too old to learn, then you’re probably always too old to learn. And I’ve noticed, as I get older, and I’m still a pretty young guy, that I’m getting lazier in terms of… JAMISON:  What is this new fangled stuff? MERRICK:  Yeah, like let me sit this one back. I’m going to let this guy handle. And I have to consciously, purposefully say, “No, I’m going to do this piece as well.” Or, “I’m going to build this  feature from the start to the back,” because rather than continually potting off to that guy that knows a lot about that area, I think it’s worth the company’s time to pay me maybe to take 20% longer than him, to have that knowledge. Because pairing with somebody, and having them do it next to you, doing it with them, for me, it doesn’t teach me like it doesn’t stay in my head the same way that grinding against it until I figure it out does. JOE:  That’s a really interesting attitude. MERRICK:  I don’t know. I think having an attitude of like I need to figure this out before I go get help is exactly how people learn. I feel like anytime you’re stressed or frustrated, it’s usually the time your brain is about to learn something. JOE:  So, just out of curiosity, compare that to how you learned how to test drive. Relate that… [Expression] MERRICK:  I’m being totally honest here. So, if you guys don’t know, Joe, when Joe got hired he sat down and he showed me a test driven development and we paired. And I’ve been doing test driven development ever since. I really like it. And actually, that was a really great experience in terms of learning. JOE:  But we only paired -- I’m curious how you analyze that. Because we only paired for a while and you kind of went off on your own. Do you feel like all that banging your head against how I really do test driven development came after we stopped pairing? MERRICK:  I feel like you showed me the value. JOE:  Then you started learning the lessons? MERRICK:  Once you justified that it was something worth learning, because really the only way to get good at writing tests and et cetera is to do it, right? Like, you don’t know what to test at first. You’re like, I’m just going to treat this as a function, but that may not be like important at all. I think that experience was definitely a hyper drive learning experience which is one that does go against my existing theory of learning. So no, that’s fair criticism. JOE:  No, it’s not supposed to be a criticism. I just asked for an analysis. MERRICK:  Really? Because you made me look like a fun tool. [Laughter] JOE:  Here’s my theory on learning. And that is, it’s quantity of time. And so, if you’re sitting with somebody pairing and doing -- for example, me, I always feel that I’m weak in CSS. If I'm pairing with somebody who’s strong in CSS, if I’m actively doing the CSS, then I feel like I’m learning just effectively as if I was just on my own banging my head against the wall because I’ve got this really experienced guy showing me things than if I’m actually involved with. But if I sit back during a pairing, just let him kind of do it and tune out, then it’s like I went to lunch. It’s quantity of time. Like the other night, I spent an hour banging my head against the wall about CSS problem. And then came in and asked you. And in like 15 minutes, you showed me the solution. MERRICK:  Yeah. But now, I bet you the solution will not be as forgotten as it would have been if I just showed you. JOE:  Yeah, you're definitely right. So, I figured it out like an hour and 15 minutes worth of time. If I had have spent an hour and 15 minutes with you doing CSS, I think I would have got the same quantity of learning out of it. MERRICK:   Yeah, exactly. JOE:   So, I think it’s quantity of time. Not necessarily just -- we all know that there’s times when an expert shows you how to do something. There’s just no replacement for that. Self-directed learning just doesn’t… MERRICK:  That’s true. Like when somebody who’s way smarter than you makes you feel like an idiot on your open source project? JOE:   [Laughs] MERRICK:   There’s a certain level of gratitude that goes along with it because it’s like hyper learning, I guess. CHUCK:  So, I have two more questions. Well actually, two more scenarios that I’d like to just pose to you guys. And I know that there aren’t easy answers to these but I’m really curious to see what you offer for these. The first one is, let’s say that you’re in a situation. You’ve got this super smart guy in your company and what your deal is basically, he’s super smart but you can’t deal with this guy. He’s negative, he’s hard to deal with. You know the company is never going to let him go. So, you’re basically stuck with him on your team. How do you deal with that? How do you deal with that on your team? JAMISON:  Have you seen the Parent Trap? [Laughter] JAMISON:   I think this calls for some hijinx. MERRICK:   Hijinx. JAMISON:   Yeah. You need to put bees in their seat or…I don’t know. I’m just kidding. CHUCK:  Yeah, because that will make it better. I know it will. JAMISON:  Your point is to convince them that the office is haunted and then, they just leave on their own. [Laughter] CHUCK:  So, there is some nutrition that you could definitely have. JAMISON:  No, that’s a terrible idea. You shouldn’t try and get a person fired. CHUCK:  Yeah, or get them to leave on their own. It’s not going to pay off for you. MERRICK:  But it’s a really great joke. CHUCK:  So, what do you do? I mean, you’ve got this guy on your team and he’s a jerk. MERRICK:  Well, here’s the problem dude. The truth is you can’t reason with people that are unreasonable. So either you have to circumvent them or leave yourself. If it really is that odd, and you’ve tried having several conversations and the person is really just irrational, what else can you do? It’s not magic. You have to break up. You have to go through a long and painful break up. JOE:  Well, there are some things you can do sort of that. I guess maybe that depends on what you mean by circumventing because circumventing really can be a very vague term. It could mean a lot of things. For example in the past, I had one guy that I had a really hard time working with, we butted heads for a while. Then I actually spent some specific time like personal time with him that had nothing to do with work. And so, we kind of became buddies. That didn’t make the work issues go away like he didn’t all of a sudden become the easiest person in the world to work with. But what it meant was I was able to deal with him easier. Was it great? Was it perfect? No, would I have rather not had to deal with him? Absolutely. But still, you can at least manage. MERRICK:   Yeah. CHUCK:  Right. So, when you’re at odds, you’re at odds with somebody that you understand a little bit better and are friendly with as opposed to at odds with that guy at the office that just seems to get under your skin. JOE:  And sometimes circumvention really just means you just deal with it. He steps on you and it sucks and you learn that, “Hey, my life doesn’t have to be ruined because there’s one guy here that’s difficult. MERRICK:  Yeah and if it is ruined because maybe this person has complete control over your job, technical stack or what have you, then find somewhere else to work. Life is too short to constantly be battling. JOE:  That’s good advice that most people can do, but there are going to be people that are listening to this podcast that are in a job, whatever it is, they want to learn something. But maybe the skill set that they’ve got right now just doesn’t allow them to leave their job. MERRICK:  Yeah you have to have the career equity before you can invest it. JOE:  So, for those people that don’t have the career equity, it’s better to learn that you don’t get your validation from other people. So, you can be happy in yourself and in what you’re doing, regardless of the environment you’re in. MERRICK:  Or your skill set, because I’m not happy with myself. I’m not saying I’m good by any means, but I think I could find another job. And I don’t think it would make me any happier, right? JOE:  Yeah. Happiness does not come from what you go and find in your job. Happiness comes from you determining that you’re going to be happy. MERRICK:  Yeah, agreed. CHUCK:  The other thing that I do want to point out is that there’s a lot of value in having a team that works well together for the company. And so, under certain circumstances, and this all depends on your work situation, how the company is structured, who is involved and all of these, so this may not work everywhere. But in a lot of cases, you can make a value proposition that is basically, “Hey look, this person is causing these problems on the team and we could be more effective if the situation changed.” Essentially, you escalate to somebody who has some skin in the game but who is also empowered to come back to this person and say, “Hey look, when you do this kind of thing, it doesn’t help.” It doesn’t always work out. There are always political situations and things that may or may not make that possible. But if you’re in a situation where you can, where you have a manager or somebody  above you that you can go talk to and at least express your concerns over it, a lot of times they can go talk to that person and make it a little bit better without dragging you in directly with the issue. JOE:  That’s really good advice, Chuck. MERRICK:   It is good advice. JOE:   I mean, I’m sure we’ve all been in situations. I’ve been in situations where I’ve done that and it doesn’t do any good. We all have to remember that life is 10% how you make it and 90% how you take it. CHUCK:  Yeah. And sometimes, your upper ups, if you go to them and you talk to them, they’re just going to say, “Look, he’s the man. He’s the dude. There’s nothing that can be done.” JOE:  We’ve heard three guys’ input on this. I’d like to hear what Jamison and AJ have done in situations where they’ve had this exact thing, what they’ve done. JAMISON:  Well, my person is AJ. So, I don’t know. No, I’m just kidding. [Laughter] JAMISON:  I haven’t had this situation in a technical place but I had to deal with it in another completely unrelated situation. I was living in a foreign country with one person that I knew and I really didn’t like this person. It was really helpful. So, there was a lot of pain, a lot of suffering. And we had kind of a breakthrough moment, I guess. And that came from talking about it with each other. I think there’s some dangers in trying to skip the step of talking to the actual person you might have a problem with. JOE:  Never skip it. I agree, don’t ever skip it. JAMISON:  Because if you don’t talk to them, maybe they have no idea that it’s a problem. And then suddenly, their Manager is like, “Hey, Chuck said that you’re kind of a jerk.” And he’s like, “What? Chuck never said anything to me. I thought I was just trying to help the team.” I know if I was in that situation, where my boss came to me and told me that I needed to like tone down my attitude, I would feel kind of hurt that the person didn’t want to come up and talk to me about it first. And I feel like, it’s fair to give that person a chance. Maybe they just don’t know, maybe they have some stuff going on. If by talking with them directly, you can get a lot of empathy for that person. Maybe their behavior doesn’t change but you might understand them a little bit more. There are situations where you’ll try and talk to them. And they’ll just like spit in your face and slash your tires. And then maybe, have to do something else. JOE:  I admire your approach, dude. I think large parts, the way that you can kind of resolve conflict with people in these circumstances is to serve them but it’s really hard to do. Because I think a lot of times, working with people that are difficult is a lot more of an action than ideal. So, you’ve constantly got to strive to do things for them to keep them and also to help your own perception of the person. CHUCK:  I just want to add to what AJ said too. First off, you don’t want to start it out as a confrontation if you go talk to them. The other thing I wanted to point out is that sometimes other members of the team are aware of things that are going on, other extenuating circumstances. I’ve run into this before. And so, I went and escalated to my boss and just basically said, “Look, I don’t know that there’s necessarily anything I want you to do about this but I’ve noticed this and I’m wondering.” And sometimes, they can just indicate that there are extenuating circumstances that explain some of the behavior. And so, then you know, okay I guess I can cut him a little bit of slack because life is just hard right now for them. AJ:   So, there was one experience, this one isn’t directly with me. But there was an experience where I kind of mediated a perceived problem where actually, it was one person who had maybe been having like a bad week and was coming off a little bit rough to another person. But that individual didn’t see it at all. It was like a situation that was just explained with, “What? Oh, somebody thinks that this is happening? I didn’t know.” I think sometimes, it’s good to confront the person. Sometimes, it’s good to go through another source as long as you’re not accusatory. Because you can ask that person’s friend or their Manager, something like that and say, “Hey, do you know if anything’s going on, or if there’s any conflict?” Without really accusing, like, “This person’s being a real jerk to me, yada…yada…yada…” and kind of get a feel for the situation first before coming to the wrong conclusion or approaching that person in an abrasive way or a way they might perceive to be abrasive. JAMISON:  I think confronting the person, you don’t want to ambush them with a microphone and a camera and like, “Sources say, you’re a total jerk. What do you have to say?” [Laughter] CHUCK:  I love that image. [Laughter] JAMISON:  Like you’re doing investigative reporting. But I like what Merrick said in chat, he said my first measure of action is to insult them publicly on Twitter. Don’t do that. You don’t want to confront them. You want to express how they’re feeling and figure out if there’s something that they need or they want that you could do to make their situation better. JOE:   Yeah, there’s the concept of non-violent language for stuff like that, affecting it without attacking. JAMISON:   Yeah. He actually picked the book that I’m reading about it right now and it’s totally related to this. But this is also terrifying. I said that I think this is a good idea. But it is so hard to do. I’ve avoided it so many times. Sometimes, it works and sometimes, it hasn’t but it’s terrifying. CHUCK:  Okay. I want to get into another situation because we’ve talked about this and there’s another situation that I ran into that I want to get your feedback on as well. And this is the guy that’s on your team that doesn’t seem as involved as everybody else. So, everybody else is kind of pulling long hours or really getting involved in trying to make everything work. And so, the rest of the team is pulling together and then you have that guy that just doesn’t seem to want to be involved, he doesn’t seem to care. Maybe there’s something else going on and he’s not as engaged. He’s a little bit behind on the technology. What do you do with that person? Nobody wants to pair with him because it’s sort of not helpful. What do you do? JOE:  You're describing me, Chuck. [Laughter] AJ:   I would suggest just asking the person, “Hey, are you feeling engaged in this? Do you feel like this is something that you’re interested in doing?” Just like, straight up ask because maybe, the right solution is to say, “No, maybe take a different avenue.” If the person’s not wanting to be on the team, if they’ve lost the enthusiasm for it, do you need them on the team? CHUCK:   That’s a really hard question because in a lot of cases, when the answer is no, you’re letting them go. AJ:  And? CHUCK:  I’m just saying, firing somebody. I’ve done it before, it’s hard. But does anyone else have any alternatives? Are there any other things that you can do? Are there ways to encourage him? Are there ways to help him get more engaged? JOE:  Obviously letting them understand, just giving them clarity on the situation with their part in it and what that means makes a huge difference. If anybody ever gets fired as a surprise, then the Manager is at the fault and not the employee. Any employee who’s fired is not a surprise, that’s a Manager’s fault. MERRICK:  Unless they like piss on their desk or something? [Laughter] JOE:  Well then, they shouldn’t be surprised. CHUCK:  Yeah. Well, there are certain lines that if you cross them, you’re going to lose your job. And if you’re shocked, sorry. MERRICK:  I slept with the cleaning lady. And now, I’m getting fired, I don’t understand. Sorry, I repeatedly punched that guy in the throat. [Crosstalk] CHUCK:  Yeah. So, the situation that I’ve seen with this turned out that the guy had extenuating circumstances at home and he was around when he could be. He started to demonstrate, because a few people talked to him and just said, “Look, this is the perception on the team that you’re not engaged, that you’re not involved, that you don’t care.” So, he started making real efforts making sure that everybody knew that he cared and things like that. But yeah, I’m kind of in the same boat as Joe and AJ in the sense that if he hadn’t tried to engage on the team, if he hadn’t made an effort to make everybody understand, “Look, I really do want to be here and be involved,” then absolutely, we probably would have started talking to him and say, “Look, do you need to be on another project where you can engage? Or do you just need to go find another job where you can engage? Because you’re not adding value here and we need people on this team who can get us to launch.” AJ:  I don’t think there’s anything that needs to be embarrassing or uncomfortable about that. I mean, I think that’s a matter of being honest with yourself, honest with the other person, on both sides. That person should recognize, “Yeah, what I’m doing isn’t making me happy right now. I want to find something that makes me happy.” Who wants to be in that position where they’re not engaged? CHUCK:   Yeah. JOE:  So this is really funny as just a total coincidence. It wasn’t what you were talking to but a friend of mine that’s skyping me some messages because he’s a Manager at a development shop. And he had some employee blow up at another one. Rather than react normally and say, “Bring them in, you blew up,” and yell at somebody, he just had it out and said, “Hey, what’s going on? I saw something building up and then it turned into this incident. What’s going on?” It turns out the guys got an epileptic daughter at home, things are getting worse for her and it’s like eating him up. He would never have known and just would have assumed that the guy’s just a jerk if he hadn’t tossed up and just said, “I probably don’t know everything about what’s going on.” There’s a rule in life that I’ve always heard and tried to live by and probably done a terrible job at. But that is, there are two kinds of people, there are those that you love, and those that you don’t understand. CHUCK:  Yeah. There’s a lot of truth there. MERRICK:  I think that goes back to my earlier point which is that companies are made up of people and you can’t forget that. AJ:   People are powered by love. JAMISON:  That’s so true. Empathy is probably the most important thing for building a team. CHUCK:  Yeah. In fact, if I remember correctly a friend of mine who used to work for Pivotal Labs, he pointed out that that was the one trait that they aimed to hire for, was empathy. So anyway, I think we’ve been talking for about an hour. So, let’s go ahead and get the picks. This is going to be a little bit longer episode. AJ, do you want to kick us off with picks? AJ:  No way, man! No way! [Laughter] CHUCK:   Alright. Merrick, do you want to kick us off with picks? MERRICK:   AJ, you jerk! [Laughter] JAMISON:   AJ’s a rebel. MERRICK:   You coward! AJ:   Merrick, you need to go first. JAMISON:   That’s true. Merrick, you go first. MERRICK:   So based on this discussion, I’m going to pick honest and open conversations as my number one pick. And that’s kind of the essence of life. Two, I’m going to pick Noah Gundersen again. His music is just amazing. Anyways, thanks. JAMISON:   If you pick him three times, he appears on the show as a guest, write that down. MERRICK:   That’s awesome. Maybe like a guest musical episode. CHUCK:   There you go. JAMISON:   He just dials in on Skype calling, “I was just asleep. I don’t know what happened? I’m here now.” CHUCK:   We should do a fun episode on just like the music we listen to while we’re coding or something, I don’t know. JAMISON:   Mine is just Yakety Sax on repeat. [Laughter] AJ:   Mine is OverClocked Remix. JOE:   Mine’s all angry music. CHUCK:   Alright. Did we get all your picks, Merrick? MERRICK:   Yeah. CHUCK:   Okay. Joe, what are your picks? JOE:   Alright. So, I’ve got more picks than usual this week. The first is the movie Oz, the Great and Powerful. I went and saw that with my family, the whole family. Awesome movie. Little kids, big kids, whatever. And I normally would never say this because I hate 3D movies in general. But this is definitely a movie to see in 3D. I didn’t see it in 3D and I really wish that I had. In fact, I’m planning to go back and watch it in 3D. I’m also going to pick the book I mentioned in the podcast, ‘Different: How to Break Out of the Competitive Herd’. It’s a really good book, mostly about business but there’s some life lessons in it. I’m also going to pick another book that’s very relating to what we talked about today, it’s called the ‘Gifts of Imperfection’ by Brene Brown. And it’s all about the fact that we, as people, are imperfect and there’s a lot of power and gifts that we get in the fact that we are imperfect. If we understand that and embrace that and embrace our vulnerability as a power, then it just makes life a lot better for us and for those around us. So, I totally recommend that, just got finished listening to it on audio. CHUCK:   Awesome. JOE:   And then, I’m going to pick the board game King of Tokyo because it’s really awesome. Plays to 20 minutes, up to six people, you get to play a Godzilla like monster, pick that one. Then the last thing I’m going to pick is Angular because Angular rocks. I had a UtahJS meeting about it the other night and it’s just un-directive. It’s so fantastic. So, I’m picking Angular. That’s five picks. That’s a new record for me. CHUCK:   Wow! Okay, we’ll get links to those in the show notes. Did we have Jamison go yet? JAMISON:   No. I haven’t gone yet. CHUCK:   Alright. JAMISON:   So, I only have two picks. My first one is this movie called Kiki’s Delivery Service. So, it’s by the same people that did ‘My Neighbor Totoro’, ‘Spirited Away’. It’s by Studio Ghibli. So, it’s another one of these Japanese cartoons that’s not anime. But it’s still very different from an American cartoon. CHUCK:   Didn’t they do Ponyo as well? JAMISON:   Yeah, they did. They’ve done a bunch of them. AJ:   Howl’s Moving Castle? JAMISON:   And they’re all so good. AJ:   Miyazaki, is that his name? JAMISON:   Yeah. CHUCK:   Miyazaki. JAMISON:   So, this is their first one ever, I think. And it’s just adorable. It’s again like all their other movies that I’ve seen, it doesn’t have the classic western plot arc of like intro, like building up the conflict, coming of age story, resolution. Stuff happens that you don’t expect to happen because it falls a different story arc. It’s really cool. Then my next pick is this thing called Local and it looks mind boggling and amazing. It’s a way to divide your browser application to a bunch of little HTTP server-ish things that run in web workers. So, you essentially build your client side app as like this distributed set of services that are all running in the browser but they’re running in different threads because they are running in web workers. It’s kind of mind boggling but it looks really cool. CHUCK:   Nice. JAMISON:   Those are my picks. CHUCK:   AJ, do you have picks? AJ:   First, I’m going to pick Ciaran Jessup. He’s the author of the ‘Connect Off’ and the ‘O Off’ plug-in that goes with that. As I’ve been having some trouble figuring out this O Off problem I’m trying to solve, he’s been like super responsive and super helpful. Just like as soon as I posted an issue, he got back to me and he’s helped me find a couple little bugs here and there. I’m like super, super appreciative of this guy. He’s just…. I like him. I’m also going to pick ‘Psych Season 7’. I think with Season 7, they really brought back some of the fun of the earlier seasons. Like Seasons 4 and 5 were pretty weak and 6 was kind of mediocre. JOE:   There’s no season of Psych that wasn’t completely awesome. [Laughter] AJ:   Yeah. But you know in the first couple seasons, like he’s always having the psychic visions and he’s having like the seizures and all that? Well, as the seasons go on, he kind of loses that and then it’s just kind of like boom! Solved, without all that build up. And I feel like in Season 7, they’ve kind of added a little more build up back. So, it’s a little more interesting, a little bit more true to the original character. JOE:   All I can say is that show has always been awesome, always. AJ:   It is. Every season is awesome but some seasons are more awesome than others. And I think Season 7 is picking up the pace. I’m also going to pick Google+ Hangouts. I’m actually not a Google fan boy. I have been in the past but I do think that Google makes some really great products. And I’m hoping that Google+ Hangouts is one of the ones that doesn’t get thrown away after a year or two. It doesn’t look like it will. The Hangouts is on air, really cool. We’ve been using them at UtahJS to record our meetings. And although the resolution is a little bit low, so you’ve got to decrease your screen resolution and hit ‘Ctrl +’ a few times on your terminal during the presentation to get everything to show up. It’s a really simple, easy tool to use to get those presentations recorded that otherwise would have not been recorded. So, I really like it for that. And then, also ScreenFlow. I’ve had ScreenFlow for a while and I’ve done some video tutorials. Hopefully, some of you have seen that on my  HYPERLINK "https://www.github.com/coolaj86/blog.CoolAJ86.com" blog.CoolAJ86.com or on my YouTube channel. But I really like the simplicity of it and there’s lots of interesting use cases for doing screen recordings. Like when you’re trying to show somebody a bug but it’s difficult to explain it, you can make a 120 second video that’s like, “Here’s how I installed this. Here’s how I did the configuration. Here’s where the bug is.” Bam! So, I’m really happy with that purchase and I’m glad I have it to use. CHUCK:   Nice. I like ScreenFlow, as well. I use it for my screen casts. And I’ve also been using it for Rails Ramp Up to record the lessons. Anyway, one alternative to it that I guess I’ll pick because I’ve used in the past is  HYPERLINK "https://www.Jing.com" Jing.com. And it’s a little less involved than ScreenFlow. So, if you just need a quickie screen video capture, a couple of minutes, a couple of seconds to kind of demo something, you can do that. And it puts it up on the web and then you can share the link. It’s kind of like Skitch except it’s video. AJ:   Jing is limited to 15 minutes, correct? CHUCK:   Yeah, something like that. So, if you need some more involved or you need to do any kind of editing or something, then you’re going to need something like ScreenFlow. AJ:   Yeah. The one thing I like about ScreenFlow is the callouts where you can select an area on the screen like, “Here’s the important area,” to give the user focus. I really like that. CHUCK:   Yeah. It has a bunch of options like that. And there’s a plug-in app that goes with it that allows you to do the bar at the bottom you see like on the news where they put the name of the reporter and where they’re at, or breaking news, or whatever. I forget what that’s called. But anyway, there’s a plug-in for ScreenFlow that allows you to do that. AJ:   Wow! CHUCK:   It’s made by the same company. I’ll put a link to that in the show notes as well. AJ:   Cool! CHUCK:   My other pick is Transmit which is a Mac app. It allows you to connect to FTP or other networked drives to push stuff up or pull stuff down. I just found that it has an option for Amazon S3 which is something I’ve been using recently. And so, that’s nice because then I can just drag it over. I have a client that’s managing the upload so that I don’t have to worry about whether or not I browse away from the web page or if there’s something funny going on with the Flash or JavaScript or whatever it’s using to manage the upload on the web page. So, I really like that. It also has an option, I clicked the connect button. But right next to it, there was a button that said ‘mount as a hard drive’. So, it would have mounted it into a finder so that I could just use it and just drag stuff to it. Anyway, it’s awesome and that’s my only pick for today. Next week we’re going to have Ariya Hidayat and David Herman back on the show. They’ve both been on the show. One was here for PhantomJS and the other one was for a Book Club on Effective JavaScript. But they’re going to be talking to us about ASTs and parsing in JavaScript. So, it should be really interesting next week. Keep an eye out for that and we’ll catch you all then.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.