 Video equipment rental costs paid for by peep code screencasts. So I'm going to give a soft talk today. I'm not going to give a hard talk. I'm going to give a talk on care and feeding of Ruby developers. So one of the things I'd like to do as we go is feel free to jump up with questions. This isn't the kind of talk where we need to wrap up all the questions at the end. It's going to be pretty informal. And I've threw together some notes and ideas from my experience. And one of the great things about giving a soft talk like this as opposed to a hard talk. First off, you can't prove me wrong. And the second thing is, it's, I don't know what the second thing was. Anyway, so, because my notes aren't, oh, there are my notes. Look at that. That's awesome. Okay, so the premise of the talk is that it's useful to know more about ourselves and our community as developers. I'll say why it's useful at the end. It'll be the cliffhanger. But I suspect that, you know, it's pretty easy to argue that it's useful right off the bat. So let me tell you sort of what's going to happen in the talk. I'm going to talk about a few sort of key areas, some important qualities. And I'm going to talk about aesthetics first, even though it's listed last. We're going to talk about collaboration, planning, stars, and care and feeding, which is sort of the homage to the title. The idea here is to come up with a set of qualities that characterize the community and the developers really from my experience. So, again, like I said, it's going to be hard to prove me wrong because I'll just say that's my experience and acknowledge your experience and then we'll move on. But it'll be useful for some good discussions. Please jump in if you disagree with me. Okay, so we know this is not, hopefully, the status quo for working in our community. It might be in some places that more than just a representation of a particular place, it's a particular style of working, a particular style of what it is we produce. I don't think this represents us well at all. So what does, what are some of the qualities that are really important to the developers? What are some of the qualities important to the community and the people that belong to them? Probably one of the first and most prominent when I started thinking about this subject was the notion of aesthetics. I've had the opportunity to be in a number of different communities over my career. I started off working being a UNIX kernel hacker back when it was just UNIX and version six, version seven. And the kind of people in that community, certainly there were a sense of aesthetics, but it was a narrow sense of aesthetics. And we'll have some photos to illustrate that later if you can make it that long. And then I had the chance to be involved in desktop Windows software, which was a period that I'm glad I forgot about. Web 1.0 and then now whatever we call this next waves. So the thing that really attracted me to this community, honestly, right off the bat, was the fact that aesthetics to me, what I saw was pervasive across the community. It wasn't just aesthetics, the visual aesthetics of some aspect of the community, but it went all over the place. There was aesthetics of software design. People had a strong opinions and strong feelings about software design. Certainly you can find that other communities, but that was a key part of the conversations I had with folks as I got to know different developers in the community. Visual design aesthetics was surprisingly high, having spent a lot of time with folks who were really excited when they showered once a week. And when they got a little percent in the flashy arrow, the notion of visual design aesthetics being sort of essential to the work that they did was very... I was very pleased to run across that because it was one of the things that I always felt uncomfortable about in other communities. A little plug for our work, that's some of our design, some of our visualization work that we've done on one of our products called TuneUp. I used it there because I think it's a great example of visual aesthetics. It's really cute looking, it's pretty, and it's also functional, so it's not just eye candy. There are lots of other examples. It's interesting to note that the work 37 Signals has done, some of their notions of visual elements has persisted out into all different parts of the web, independent of Ruby or Rails. I see design elements from their work all over the place. So these guys are known obviously from their technical abilities, but also from their aesthetics, their design abilities, which would make sense given their backgrounds. Aesthetics of work environment. In some ways this one is a little one hard to judge. Everybody likes a nice place, nobody likes to say they work in a broom closet, which coincidentally actually happened to work in a broom closet right now. But we have got a community of people in my experience who care a lot more about the environments in which they work in because aesthetics are high on their list of important things. The visual, the auditory, all of the different aspects of their work environment are important. And one of the things I've discovered is they will find a good place to work if you don't provide it. And coffee shops around the country are benefiting as a result. Certainly in Austin we've seen that. This is one of my favorite slides. It's so sexy. That's right. So we've got really three important people or three important creatures on this. That dog is hot. So it's kind of silly, but this is another thing that I noticed was that in this community people really cared about how they looked. Now, in other communities people cared about the look, but the degree to which they cared. The importance that that ranked wasn't as high as what I find in this community. Now, I do work with a bunch of guys that look like they belong to a boy band. Mostly Adam here on your left along with his partner, the dog. But seriously, these folks, in my experience, the notion of aesthetics pervades all over the place. It doesn't just stop at a good design, a good architecture, a good office space. To contrast that with previous generations, Richard Stallman I think represents maybe a different aesthetic. Or maybe that aesthetic is not as important as some of the other things that he focused on. I worked with a lot of people that looked like that. So I was sensitive to the notion that it could be different. Okay. Collaboration. Collaboration is baked into the community from the beginning. And that's one of the things I really noticed. That'd be my phone. Wow. I'll just put this on the stage. That's so cool. I don't want to break anything. Just bring it up here. All right. So collaboration is baked in from the beginning in the community. It's my experience. As you may or may not know, the folks that I work with include Adam Keyes, Bruce Williams, who do have somewhat of a familiarity in the community. One of the things I noticed about their working style right off the bat was they naturally collaborated not just with folks in the building, but with folks elsewhere independent of a particular project. So collaboration really showed up in a lot of different ways. And one of the values of collaboration, I mean this is a little bit like mom and apple pie, but one of the values of collaboration that I think we as a community have sort of inherited from the larger open source culture is this notion that we get course correcting feedback. The feedback loop is closed. It's pretty tight as a result of that collaboration. If you're building something that's relevant and it's built well, it'll get an option. If you're building something that's relevant and it stinks, you'll hear about it. Or you'll become irrelevant. If you're building something that's not even interesting, you'll become irrelevant. And it's pretty easy and pretty quick to find that out because of all of the tight and loose collaborations that we have in the community. And I think that's a tremendously valuable characteristic of the community. I couldn't pretend to know why that's occurred, but I think it's one of those huge assets that's true in our community. I don't have any good pictures for the next few slides. I wish I did, but I wasn't that creative. Independent of physical location, the collaboration occurs. Collaboration just isn't a matter of the fact that happened to be in the same room. The teams that I've worked with, the folks that I'm working with, they don't think anything about getting on iChat and collaborating with someone. We've got folks who are in Dallas. We've got folks who are in Scotland. So distance, while it does have an impact, is really less of an issue than ever that I've seen before. And of course, a lot of us get away with it from the technology that we've got and what have you. But the notion of being able to work in a distributed manner is something that we inherited very well from the open source community. Independent of organizational boundaries. This is one that I appreciated but thought it would be kind of challenging for some folks. In my experience, people don't have a problem in this community collaborating across organizational boundaries. They don't look up first and say, is this my team? Is this my company? Is this other person potentially in a competitive relationship with somebody that I am collaborating with? That parsing doesn't seem to go on. It's really more a fundamental question of, I've got a technical problem, I want to solve it. And who's the right person I can reach out to to solve it? And I think the parsing of the organizational boundaries really don't occur or don't occur until well downstream from there. The nice thing is that problems get solved with the right people getting together on them. And they don't have to worry about getting those connections vetted by somebody. One of the side effects of this is that, and this is Horton, by the way, who's looking to see if there's anybody in there. If you guys know the story of Dr. Seuss, Horton and the Who. Do you guys have anybody over a child here? Thank you. So Horton's the only one that could tell those guys were alive. They weren't doing enough things that made it obvious to the rest of the world that they were alive. Horton happened to be a particularly sensitive character. One of the things I've discovered as part of the sort of rich fabric of collaboration that occurs in this community. If you're not doing something, it makes it obvious you're alive. You're not posting blogs. You're not contributing code. If you're not insulting somebody. If you're not up on stage doing talks. Whatever, people begin to mentally, I think, start to say, well, you know, their aliveness is dropping. And therefore their relevance and therefore their degree of collaboration. And so one of the side effects of this collaboration is people get a sense of sort of what's stale and what's not stale. Simply because there's lots of ambient noise, ambient background information about what's going on with people and projects. And I think that shows up later in one of my recommendations. So make sure people know you're alive. Okay. Off-off collaboration onto another topic. And this one was planning. I sort of had a hard time trying to figure out what category to call this. I didn't want to call it managing because it really isn't about managing. And my point is sort of the opposite of managing. But I guess the point that I want to sort of drill in first to is the doing of the work on the projects that I've had the opportunity to either see or be involved with, the doing is really close to the planning. And that's in contrast to a lot of projects that I've seen elsewhere where the people making decisions about what is to be done. What's to be sold, what's to be built, what's to be serviced are at some amount of distance from the people actually doing the work. And to a great degree some of the technology, some of the frameworks, Rails obviously being the big one here. Some of the technologies that we have make it possible for the people who are the implementers to also be the planners because they've got more mental capacity to handle that because of all the benefits we get from some of the smarts delivered by the framework. I don't think that's unique to our community. We inherited some of that from the open source culture. But I think we have that a little more pumped up because we've packaged up a lot of our smarts and delivered it and collaborate well on it. One of the side effects is, I think this potentially results in more stars. You guys like the little asterisks I put there, I thought that was really catchy visual design. And by stars I mean things like this. Where you get beautiful people on the cover of Wired Magazine talking about their frameworks and their products. And it's those people who are actually doing the creation of the work or actually the people who are coming up with the ideas for the work. I don't know about y'all but I've certainly been on a lot of projects where the opposite is true. So, carrying on this similar theme is the notion of living on the edge with the latest stuff. Here we have, I don't actually even know if we know his name. Do we know his name? This is another Dr. Seuss character. We know Sam I am is trying to get him to eat this green eggs and ham. That he's the guy that won't eat it because it's a little too edgy. Yeah, he's the guy. Yeah. Anyway, so he's sort of not certain about living on the edge here about eating this green eggs and ham. And, you know, eventually he does, he's good with it. And one of the benefits that we get by living on the edge is that we get to have that tight feedback loop that gets us improvements quickly. Once we have this great collaborative fabric setup, all the different informal ways that we collaborate, what smarter people than me would talk about social graphs and what have you, we have lots of different ways to push improvements to each other rapidly and to take advantage of them. And that works because the feedback loop is closed because we have the collaborative mechanisms that if you do good work, people know about it. If you do, if your work stinks, people know about it. If you're relevant, people know about it. And so it makes it possible to live on the edge with the latest changes of code. And, you know, from personal experience, we're picking up edge stuff about, you know, edge rails or, you know, gems that are being tweaked, what have you, and some of the work that we do on a regular basis. And a lot of what comes with it is the knowledge that the people that are behind it we trust because of the collaborative fabric that we're in together. If the opposite were true and we were at the end of one long pipeline where it took months and months for things to go through long processes to finally get to us, then the rate of change, obviously, would be so much lower for us, for our community. And I think it would severely hamper a lot of the great results that we've seen. So there's a neat set of trade-offs that have occurred there. Enlightened capitalists. Now, this is one of the difference I've actually seen in this community versus some other communities that I've been involved in. From the open source world, I think the notion of passion plus some amount of useful action is rewarded. And for a lot of open source communities, that reward is personal reputation or the convenience of having some new functionality available for yourself and maybe for a small group of people. I think, maybe not uniquely, but I think in a great way, this community is finding how to turn that into capital, turn that into money, not by selling the source code because sort of carrying on our lineage from the open source world, source code is of less importance, but what seems to be of great importance is the delivery of services. I mean, we see, obviously, of 37-signal stuff and lots of other people are delivering softwares of services. We're also seeing people deliver services, services, humans going out and talking to other humans. So the actual code itself as something to... that it's, you know, has cash value associated with it, really seems to have gone by the wayside courtesy of the open source community. Ultimately, what I'm seeing, though, that is nice is people love this stuff and they also want to make a living doing it. They don't see those two in opposition to each other. So that's a bunch of qualities that I went over and now I thought I'd drill into some few suggestions about sort of care and feeding, but before I did that, you guys feel free to jump in. Any questions? No questions? Okay, good. So care and feeding. So at times I'm idealistic about this. I think having some awareness of these qualities of our community is just a good thing in and of itself. That awareness will in one way or another affect the decisions that we make, more of the human decisions. As I mentioned to somebody while I was furiously finishing the last few minutes of this talk in the green room, he was working on his talk at 2.30 and he was working on code samples. That's very concrete. You know what to do with stuff like that. You know, you might type rake at some point and do something and get some result. Mine, the kind of stuff I'm delivering, it's more like clip art. And there's not as concrete results that you can expect out of it. So the sort of general category of awareness of these qualities I think is useful and becomes useful in a pervasive way. However, I do have some specifics. A lot of it depends on the purpose that you've got in mind. And I think one of the most fundamental questions of wrapping all this information up and asking what you can do with it is, how well do these qualities match the other communities that you might be involved with? And when I talk about communities, I'm not just talking about technical communities. I'm talking about the companies you might be embedded in, the customers you might be collaborating with. Having some amount of meta perspective of realizing what the qualities of our community and the qualities of the people that work in our community, and then comparing those against other places where you might be, gives you a little bit of a chance to know whether there's going to be some amount of mismatch or not. So let me drill into some specifics. So in your environment that you do your work in, where you're doing your passion in, collaboration, obviously I spent some time talking about how important I believe that is. How well are you supporting or blocking the different forms of collaboration? Collaboration occurs in all sorts of different mediums, with all sorts of different tools. We spend a lot of time, we continue to tweak how we collaborate, both inside of our immediate teams and with folks that we have more looser collaborations with. Allowing for serendipity, where you have the chance to chat with this fellow, because it's not because it serves some immediate tactical purpose, but it in some ways benefits everybody. Obviously conferences like this are great, but there's a huge sort of cost to making this happen. So how to create those serendipitous collaborations, as well as the ones you know you have to have. Crossing organizational boundaries, I think in bigger companies, bigger corporations, ones that maybe have established earlier generation development approaches, the notion of freely crossing organizational boundaries, without having to get that vetted by somebody would freak people out. So as a heads up, that mismatch is an interesting mismatch, and I suspect that we've seen that before when the open source culture bumps into proprietary culture, and I think we'll continue to see sort of that having to be rounded, the corners rounded on that one. And lastly when we talk about collaboration, collaboration extends beyond just the technical community. In where we're working now, where I'm working now, it's a small team, about 18 people, a few of which do marketing, a few of which do sales, the majority of which do development, but it's safe to say that some of the conversations that we have in the scopes outside of development, the collaboration between development and those groups, those tribes are really critical, but they don't speak the same language. And recognition that in fact those languages are different, is sort of one of those mom and apple pies that everybody understands is important, but it's too easily sort of lost as we do our daily stuff. More specifics, I mentioned this earlier, sort of in the notion of Horton, do you look alive to others in your community? More than any other community I've ever had the chance to be involved with, what I'm seeing is folks are doing lots of, you know, they have a lot of presence online in lots of different forms. And, you know, whether it's Twitter, you know, friend feed, whether you're, whatever it is you're doing, blogs, what have you, that to a great degree is how people know you're present. And that, I hope that stays important to the community. Locus of control, that's a fancy phrase that I knew before, but I had to look it up at Wikipedia to make sure I really knew what it meant. But essentially it means where you're perceived control is over the decisions and direction what you're doing, where the perceived control of that is. And I think in a lot of the projects, as I mentioned, that I've had the experience on, the locus of control is very close. The people doing the work are actually the people making decisions about what should be done. So watch out for those projects in which that's not true, because they may look similar, but they're not. And there's lots of side effects that come from that being different. And there's a lot of side effects that come from getting people who don't understand that quality. If you're getting people into your group who don't know that the locus of control is where it is for y'all. If it's close and it's, you know, close to you. And they're not used to that. My experience is those people spend a lot of time on idle waiting for someone to tell them what to do. And that doesn't work really well. So when you're vetting people, clients or customers or staff or, you know, drinking buddies, what have you, check that out. That might be one of those things you want to see how well it matches or mismatches. Plan for people that blend technical and aesthetics. I think I overused the term aesthetics there. But my point being that in this community there are a lot of people who have a history of being designers or working in the visual arts or working in theater or what have you. And they bring that to the technical. That, I think, really impacts how we do our work, how we live our work, how we sort of, what the aesthetics are, obviously. So plan that that's true. And the corollary to that is, what are the people coming into your world and being more involved? And see if they match that for y'all. See if they match that level of aesthetic interest. And if they're not, you know, figure out if that's the right fit. It doesn't have to be a problem. Just have some awareness of it. And then the last bullet I've got here is people will find nice places to work to make that happen. When we moved to our offices recently, we were at a very classic sort of grade A office space in way the hell out of town from my point of view. You know, beautiful office, you know, exterior. Everybody that was there wanted to move to a place that was downtown where we could walk to lots of coffee shops where we had funky industrial feel versus marble in the lobby. And until we moved there, a great number of us spent a lot of time driving our cars to lots of places that felt like the where we wanted to be. We spent time in coffee shops. We spent time in each other's houses doing work. Even though we had a full office space, people wanted to find a place that worked and felt like how they work and feel. You want to avoid this problem? That is the clip art that depends on the time of day and the purpose of the, yeah. Yeah, right. This is the clip art that I found at the 11th hour and Rain and Bruce Williams both said I will have failed them if I didn't put this in there and find some measly connection. I suppose the connection is make sure you get an office space that people feel good about and they don't have to fight when they come in there cubicle. Okay, that's right. Other than that, Bruce, do you want to come in on that for us, Bruce? Thank you. So that's been my tour of this sort of soft subject. It's a shot in the dark. I really wanted to see if it was worth getting out there. I hope it's been useful and I'd be happy to entertain some questions if you've got any. Premature clapping, there was one or two questions. Go ahead. Yeah. Thanks, yeah. How much do I think what I talked about, the qualities that I talked about are unique to the Ruby and Rails community versus just companies doing, small startup companies doing development. I think there's a lot of overlap, but I didn't build a taxonomy well enough to say this one maps uniquely to Ruby. There are a number of qualities. More than anything, I think it's sort of the aggregation of these qualities. To me, our indicative of the Ruby community, I think you'll see a lot of these other qualities in small startups, but this is sort of the intersection of the two, I think is more the case, I think this is more of a prototype for really these qualities are in the Ruby and Rails startups, Ruby and Rails community, though you'll find some of these in other startups. Does that make sense? Was that well-formed because it sounded like crap to me. So, the short answer is I believe that these qualities, you'll see most of these in the Ruby and Rails community, and I believe you'll see some of them in general software startups, but the highest count will be in the Ruby and Rails. Okay, that was better. Oh, he's brilliant. You know, that's an interesting question. I wish I had a great answer, and I've made the mistake of working for small startups who wanted to have some of this, but the impact of sort of key folks in a small startup, if they weren't willing to go there, it wasn't going to happen, and when in particular it didn't happen because the CEO or the founder just, you know, there were some of the qualities that I talked about that he just couldn't get to, and it wasn't going to happen full stop. And as to how you pull that off into a larger sort of corporate context, I mean, that's an interesting conversation, and I had a variation on that conversation last night with some folks, and honestly the best answer I have is probably one that's not always legitimate, which is try and spin up separate groups where they can have their own culture. I mean, it's so onerous to change cultures, and the culture is the way it is for a reason, and it's almost like you want to get out of the way and let it keep going, but to stand in front of that truck, you know, I've got a few scars from that. That's a good question. He asked how to do that into a larger... I've actually changed existing cultures. I'm sorry, I didn't repeat the question. Yes? Right. So there's a lot of... you've got a bunch of people, you've got to keep spreading the block, the community, the conferences, and get people excited about... I don't want to use it. You can get the engineers excited to all kinds of management, and that's the first and foremost way they come. A lot of times it's either started or the other optionally... Yeah. There's a variation of that. I mean, sort of along those lines, one of the experiences at Five Runs was at one point we reduced the development staff down to... this prior to my tenure there. We reduced it basically down to one person, but that was Bruce. Bruce Williams, and we built up around him, and so if we're good, it's his fault, and if we're bad, it's also his fault. But the net effect was that finding a person or a group of people who can strongly hold on to the qualities you think are important and keep them alive, keep them sort of bound together to be the catalyst that you attract more people onto I think is critical. If you have one or two... If the bad stuff outweighs the good stuff, it's a... You know, have my hats off to people to try and do it. It's hard. Brian, do you have a question? I don't know what you're talking for, but I've seen a movement towards this more, for lack of a better word, agile type of team inside a larger and fresher project by taking three members from a larger team that were kind of in this dead-end project. It was like a year-over budget and show. It was a sort of separate side-related project. And when those three operated kind of semi-automatically, kind of as their own group. Independent. They ended up sort of moving to the larger group that operating with that level of autonomy could really produce a lot of results. So spinning off a small group to act as an example really started to make ways with this. Yeah, that makes sense. That's a good point. Any other questions? One back there? Right. Let me try and repeat your points. I think the point you're making is while the locus of control as a quality for developers is really important, there's also another aspect which is what amount of control do the customers have to see how the company goes, how the product direction goes, or service direction might go. And I agree with you, I think that's important. To me, that sort of goes to that feedback loop in that keep alive, that heartbeat. If you're producing something that's... If you're frequently producing something that announces your existence and the results are relevant, then that guides the ship in the right direction. If it doesn't, if the customers treat you as irrelevant or worse, then hopefully the collaboration is still rich enough that people get that information back and course correct. Because ultimately the people I've seen that don't course correct is because they aren't getting information about the things are going bad. Nobody I've met really says I'm going to keep doing this bad thing because it's wrong even though everybody tells me just because I love doing it unless they've got some sort of drinking problem. That's a good point. That's probably a whole other discussion about the trade off between what feels right at the moment versus what might be right for some set of audience, some set of customers. Any other? A lot of times with that locust control issue you're going to have to have external forces dictating a lot of what gets done but the developers can get a lot of the satisfaction of locust control by not dictating in any way how they do what they do. Sure. Yeah, that's a good point. You can separate a lot of what and the how and still accomplish that kind of psychological desire. Yeah, I think that's a good point. So for those of you who didn't hear it, with respect to locust control, looking at what versus how, I think if what comes in as messages from outside of a group of developers, then the how as decided upon by the developers, the locust control to a great degree is their own. I also think that when you start to collaborate with other tribes, like the marketing tribe and the sales tribe, they have their own language. They see things and they interpret stuff that's valid in their world and they translate it to us and part of that translation ultimately comes down to do you trust the data you're getting from them. And so if you do trust it, then it's sort of up to you to react to it in a way that's you know, that's honorable. Otherwise, if not, you're sort of in the situation going, well, I'm going to do it anyway. So, yeah, good point. Any other questions? No? All right, well thank you all. Video equipment rental costs paid for by peep code screencasts.