Michael: 00:00:04 Thank you Debbie. Thank you Sandi and David for joining us tonight. So we're here to talk about continuous learning as a lead developer. If you go to Twitter, you can go to NYCTechDebates. You can tweet or retweet anything you're seeing. And we may even ask ... later we'll have some time for questions from the audience, so if you post anything there, we might ask questions from it. Then we'll also have some questions at the end for anybody.

‍

Michael: 00:00:34 So, for the first question, so you're both accomplished teachers, you've written multiple books, you've been developing for a long time. I'd like to know, could you talk about how learning continues, where do you draw inspiration even when you may be the most or more experienced than your manager or some people on your team.

David: 00:01:01 You're looking at me. I guess that means ...

Sandi: 00:01:03 You see how cleverly I did that.

David: 00:01:09 It's an interesting question. I'll answer with a little autobiographical twist. I work at 2U. I've been at 2U for three years and a little bit. When I first started at 2U, the first year I was there I didn't do any Ruby and I had been quite immersed in Ruby. I'm writing about Ruby. I'm running Ruby conferences. I'm teaching Ruby. Having programming gigs about Ruby and so on. And that first year, I didn't do any Ruby. That changed. Actually there was so shifting around of teams and some resources kind of moved towards another project, which was [inaudible 00:01:53] because the second and third years I haven't been exclusively doing Ruby but doing a lot.

David: 00:01:58 Anyway, the point is that there I was. I kind of thought well, they are not going to let ... well my worst thought, they are not going to let me do Ruby. It wasn't quite that. But, as it turned out, it was a really great idea to have a year where I didn't do Ruby. I went back and did Ruby and picked it up again and that was fine. But, I learned some Python. I don't describe myself as a real ... got to be a good intermediate Python programmer maybe. We did a lot of AWS Lambda and other stuff like [inaudible 00:02:34] AWS things. And, that was the year that really ... it did kind of inspire me. I learned a lot and I learned that I didn't have to stop learning and that was good.

David: 00:02:45 I'd been worried I had been kinda pigeon holed a little bit as you know can only do Ruby. Maybe I had a little bit to prove in that area too. Then when I came back and got on the rails project the next year, that was fine too. I was ready to do that. So that worked out.

Michael: 00:03:04 And Sandi?

Sandi: 00:03:06 We don't quite have this all worked out yet. It's funny. Like I don't feel like I am someone who has spent my career intentionally trying to learn new things. In some ways, I really am the [inaudible 00:03:23] for ambition. And yet, like I started out punching cards. Right? Back in the day. I've hung ... you know those movies where they try to show that a computer is active because there's like a tape reel on screen? I loaded those tapes. Like I run a similar program to break the labels on those tapes and we can reuse them. And somehow I'm here today, right? Which is sort of interesting.

Sandi: 00:03:48 I think it's just because ... I have a quality that I suspect many of you have. I'm just so easily bored. All right. Then when new things come we get tired and we want to do new stuff. I feel deeply grateful for programming because we get to do new stuff all the time. And maybe you just lose your job if you don't.

David: 00:04:11 It's interesting. When you put it that way, I see it as sort of operating on a ... that's kind of a horizontal access so to ... but there's also for me the vertical axis of just getting so deeply into a problem, a programming problem and kind of knowing, just based on the odds I'll probably solve it eventually, but that process is just ... I've been doing this, okay since 1972. I was 13 there. Intermittently though. I'm not ...

Sandi: 00:04:42 This discussion already.

David: 00:04:44 Not continuous. I had a sort of child computer whiz phase when there was no such thing. I got sort of into that frame of mind. There's something very meditative and whatever about it. But I agree about this sort of horizontal ... also there's always kind of new things.

Sandi: 00:05:07 I remember the first program I ever wrote. Don't you? Raise your hand if you remember the first program you ever wrote, right? It was like magic. Right? So I don't know. It feels like a very difficult question to answer as if we have some max secret sauce. But we don't. We fell into computers luckily and now we're still doing it.

Michael: 00:05:29 Awesome. This is kind of from the ... from learning, this might be going into more of the teaching side. So on a team, what percent of a lead developers time should be devoted to writing code, mentorship, teaching others, attending meetings, etc?

Sandi: 00:05:47 I'll go first this time. I have no idea. I mean here's what I know about. I've been on the management track. I've been on the track. It's like I want good bosses. I want the people who are on the management track to make it so that those of us that are doing mostly development, can do our jobs. I don't really care how much time it takes them. Like I want them to know enough technicals to not be conned by devs which happens. Right? Like I want them to know enough so that they don't ... they don't make decisions based on personality instead of technical worth. But other than that, I don't really care.

Sandi: 00:06:30 Like when I was on the ... when I was a manager right away, it seemed to me like that was a bad idea. I mean it means your job has to be making it so other people can do their jobs. Like that's what it felt like my job was. I found that I just kind of wanted to do my job. Like some people really get a lot of satisfaction out of that. And I want that person for my boss, and I don't care how much [inaudible 00:06:55].

David: 00:06:55 Yeah I actually ... I don't know. I kind of don't like being managed. My mind is naturally ... I was raised by academics. I was an academic for a long time. Let the faculty do what it knows how to ... that's sort of ingrained in me. And I will say, I learned that there can be good managers and I learned it doing basically back in the cyber stage, doing computer programming and being on teams and it was like my goodness. There really is such a thing as managing and it's a skill and it's a thing that some people are good at and some people aren't. And that was quite eye opening.

David: 00:07:39 The other eye that opened, was that I didn't want to do it or feel that I would be good at it. So I never see ... I've never seen myself as on a track that goes to that. Again, really that's in a way a homage to good managers. That there is such a thing as ... it's not just like oh you've been programming for long enough. You can be rewarded by being a manager. I've seen that happen and that's a mistake. In terms of, I think, the question you said how much time ... you're kind of I guess being slippery about certain lead developer management. But, if we're talking about somebody who is a programmer and is also in a management position, sort of lead, rather than just senior or whatever.

David: 00:08:34 I don't know. Again, I can't really speak from having had to face how to do that, but in terms of how to divide time and coding and so on. I think it's more a question of at least in my experience, of the kind of attitude you take toward the coding. Like if a manager slash lead developer, whatever, says okay I'm the manager so I can commit things that merge to master without asking, then you're in trouble, right?

David: 00:09:07 I had one manager who said, I said to him something like, just to clarify. What is your coding role?

Sandi: 00:09:16 What's your job?

David: 00:09:16 Yeah what are you doing? No. This was a really, really good manager. Just clarifying. He said, oh well I'm coding. I'm one of the engineering team. He said I don't have any special rank. I can't pull rank. That was I think very important. That's more important to me than how much time. I think how much time depends on other demands and has to be balanced. Yeah that's kind of their ...

Sandi: 00:09:40 I wanted to be a manager first. And not a programmer who neglects management duties. Right?

Michael: 00:09:50 Can you talk about any strategies that you've used for teaching or mentoring people on your teams?

David: 00:10:05 It's actually an interesting question because I have done ... I was a professor in a different field for many years. I have a real teaching background. When I left being a professor in 2005, and you don't have to ... but when I left the university in 2005, I thought okay. And there's a long story behind that. Like Ruby, suddenly you could make money from Ruby because of rails. I had been doing Ruby for [inaudible 00:10:34] ... that's the abridged version. I actually had a book contract with Manning and I basically resigned from the university in lieu of taking a sabbatical because I wanted to change to this new career.

David: 00:10:51 But anyway, I thought okay I'm going to go be a programmer, right? Hang out my little shingle and be a programmer. I was in 90 plus percent of my living for the next four and a half years from training people in Ruby and Rails. And it wasn't because I didn't want to ... somehow the word got out, I guess, and I got very interested in training and I worked for training companies and also ran some of my own courses and so on. Anyway. So one of the interesting challenges for me is how and even whether I can sort of bring that to bear on a job where I'm basically a programmer and it's tricky.

David: 00:11:34 I'd like think that we all kind of teach each other and maybe if someone has more experience with XYZ, we teach more about it. It's ... doing it as a sort of formalized way, I think is a very difficult challenge to an organization. I mean I've talked about it at places and everyone is attracted to the idea in a sense, but it's very hard to formulate ... because you say okay David is going to teach a Ruby class one afternoon. Then you're taking me off the work and that sort of throws everything off.

Sandi: 00:12:14 It's a super interesting thing, right? It feels like the whole, like mentoring wasn't a word. It wasn't anything we talked about 10 years ago maybe? 15 years ago? Certainly not. I mean it's much more a common idea now. And it feels to me that it's an outgrowth of sort of this huge demand for programmers and then we have code schools. So there's this real influx of folks who feel like they want to be programmers. Who could possibly be quite good programmers, but they arrive at your shop with 12 weeks of experience. Right?

Sandi: 00:12:50 I am completely okay with the world being the kind of place where, like I went to Voc Tech school and learned to write code, right? So if that's the bargain we make of that, that we're going to give people a sort of taste of it, and then employers are going to hire them and train them. Now you're in a situation where you have lots of people who really ... so sorry if you're from a code school. Newly from a code school, they know nothing. I mean they really don't right? What can you learn in 12 weeks? That maybe you would enjoy it? Perhaps you have the knack? I don't really see.

Sandi: 00:13:27 I learned a lot after my first 12 weeks. So, there is a way that it feels like in the modern world where businesses are signing up to hire people where a lot of that bargain involves training and we're calling that mentoring and I have not done it, so I can't really speak to how that goes. Like now I don't write code every day for a living anymore. I teach. I teach short courses [inaudible 00:13:56]. So I show up and inspire people and give them hope and then I leave town. Like it is very clear to me that I can give people a glimmer of a different way of writing software, but they aren't really anal to do it when I leave. Like i give them lots of homework.

Sandi: 00:14:15 So I don't know. I don't have any kind of answer. Like I do not have a good, a prescription for mentoring but I accept to acknowledge that the way we have managed to arrange the universe, a great deal of mentoring probably needs to be done and maybe you guys should be figuring that out. I mean otherwise everyone is going to be unhappy. So we should ... we would prefer they not be.

Michael: 00:14:48 And then kind of related, what's the hardest thing to learn on the road to becoming an expert software developer?

Sandi: 00:14:53 Okay, so we got these questions in advance. So I read it, then today I was like did I ... where were those questions? I should read them before I go. I read that and I thought, the answer came immediately to me. Humility. If you, like, and humility takes like some amount of self confidence and a little bit of bravery and those things can be hard to come by. Like if you want ... for me, maybe I'm saying more about me than I'm saying ... yeah. If I feel humbled and I'm not afraid of being wrong. If I'm not afraid of being wrong then I'm not defensive. If I'm not defensive, then I can work things. I can work stuff from people who violently disagree with me. And so it all starts, for me, with that. Like not being afraid. Being confident enough to be humble.

David: 00:15:45 Yeah what she said.

Sandi: 00:15:49 I was going to say top that.

David: 00:15:53 Well, I probably can't. But yeah no, it's very thought provoking actually because for me, there is often a struggle ... well you mentioned being defensive. And I often go through this cycle, probably in other walks of life too, but certainly with coding and ... I can get sort of territorial about code. I can get defensive. I can sort of make snap judgements or reactions. And almost every time that happens, in that particular way there's sort of a thing that happens.

Sandi: 00:16:36 I have that feeling when I'm having it. Right?

David: 00:16:38 Right. And almost always it turns out that when I let go of that feeling and I actually listen to the what the other person was saying, like no we're not going to use J query in this ...

Sandi: 00:16:50 Not to pick on [inaudible 00:16:53].

David: 00:16:54 Yeah. Right. No it was in this view app. No we're not just going to do everything with J query. It's that kind of thing. Once I let go of saying we have to use ... then it almost always turns out that they had some correct or lighting point of sometime. It's also been a process for me, of recognizing that earlier and earlier. And just saying it's not a reflection on me if I either choose something wrong or there is someone has a better idea. It doesn't mean I did something ... it's a sort of growth thing also for me.

Sandi: 00:17:32 It helps to be older. I've gotten better at this. It really helps right? Like I've been wrong in so many ways I'm just used to it.

Michael: 00:17:43 Would you say that's one of the better ways to acquire humility? Just to let it, experience failing, maybe being over confident and then ... is there anyway anyone can short circuit that?

David: 00:17:54 Be right about everything.

Sandi: 00:17:57 I mean it would be great if you were somewhere where ... like you can pick your work environment very carefully. Right? I mean if you were ... like okay can I tell a really brief story?

David: 00:18:10 I've done it several time already.

Sandi: 00:18:16 I distinctly remember that I was ... I had never given a talk but I had had a conference proposal accepted, so I was working on the talk. I was going to come here actually and speak at [inaudible 00:18:29] 2009. And I was just terrified. I was just like ... it was horrifying. So for those of you who've never given a talk. Like if you think about what is the most scary thing about giving a talk? Like I have like ... I might trip and fall down as I'm walking up on the stage. I might take a drink of water. They are all physical things mostly for me. I will take a drink of water and I'll choke myself. But the one thing that really struck terror in my heart, was someone was going to ask me a question that I couldn't answer after the talk. Right?

Sandi: 00:18:58 Sometimes you are in those talks when there is some know it all in the audience and they are rabbling at the speaker. And they are up there sort of flailing, flailing really helplessly. I was in a talk that Chad Bower was giving. And someone asked him a question and he said, he looked out there, he said. He looked at him and he said, I don't know anything about that. Like right from stage. You can do that. I just ... it was really great to see someone who I really respected and I thought knew everything. Modeled the ... he was very sweet about it but it was clear he didn't really think he was a bad person for not telling him. We can talk about that later. And he moved right on. He cut the guy off right away. He couldn't enlighten everybody.

Sandi: 00:19:40 So if you can be with people that you think are really smart, who exhibit that behavior. That helps teach you that you don't have to be a defensive jerk about your own stuff.

Michael: 00:19:56 So, perhaps related. What challenges have you seen in collaborative software development? And how has this changed your approach to the craft and working on a team?

David: 00:20:09 Changes in ... can you repeat the question?

Michael: 00:20:14 What challenges have you seen in collaborative software development? So this is more when you're working as a team, what are some of the challenges? And has that changed your approach to the craft? And how has that affected your work on a team?

David: 00:20:29 I think in some ways there is a lot of overlap between software teams and any other kind of team. I've played in string quartets. I've been on academic faculties. I've been on software teams. All these sort of small scale ish organizational units and there is more in common than not with some of them. Obviously string quartet, you don't have to choose which code repository to use. But yeah. I think there's a lot in common and I think the challenges are ... the challenges are many but I find them very interesting. Can I think of any? Let's see. Well yeah.

David: 00:21:21 The challenges include obviously sort of the human dynamics. I mean we've all been on teams.

Sandi: 00:21:29 It's just the people.

David: 00:21:33 Yeah it's the people.

Sandi: 00:21:37 Tech is easy. People are hard, right?

David: 00:21:38 What's that?

Sandi: 00:21:38 Tech is easy. People are hard.

David: 00:21:39 Right. Another thing actually that you don't hear enough about maybe or there are probably articles I haven't read, but ...

Sandi: 00:21:49 Humility.

David: 00:21:50 [inaudible 00:21:50]. But, it is change. You know I was talking to somebody recently about the Storming Norman Performing thing. Now I have to say. Disclaimer. I've never read it. So I'm not ... I've heard about it sort of ... the thing that's ... so I'm talking about versions of it that are kind of anecdotal and if I read the original article ... I haven't so I can't speak to that, but one thing is that it represents it as kind of a totally linear process. But I think one of the most important things about teams and one of the most challenging things is the fact that people rotate in and out and that you can get very attached to a particular formation and people talk about well we have to make sure we're all interchangeable in case we're hit by a bus. But in fact, nobody really wants to do that, and nor do I.

David: 00:22:53 So I think the risk ... it's kind of high risk, high reward. If you lean very heavily on who is actually in your team and then one of those people leaves, it is a trauma for the team or it can. It can also be good I guess depending who it is. But yeah thinking of ... just sort of the typical case. I think that's sometimes, I don't know, just not ... doesn't get enough attention. It's very important that the team can change. The dynamics in that sense can change and the composition.

Sandi: 00:23:34 Anyone familiar with that research that came out from Google about team work? What was the name of that project? Was it Aristotle?

Speaker 4: 00:23:40 Aristotle project?

Sandi: 00:23:41 Was it? There's this idea called psychological safety which is about how safe you feel like ... are you allowed to be yourself? Do people care about you? Are they willing to make space for you? Like there are a whole bunch of qualities that go into that. And Google, who has a lot of teams and they are good at data. They were really interested in figuring out what made the team, and they did a bunch of research and they drilled it right down to that. Which is really ... and so really what it was was the sole determining factor that could be used to predict how well teams collaborated was how the members treat one another.

Sandi: 00:24:20 So when I say tech is easy, people are hard. It's really short cut for that, right? Like I don't think it's a tech problem. Like every collaborative human endeavor involves more than one person and then you have to figure out how to deal with them. There's a way in which we self select. There's a lot of ... like some of us are in tech because we can sit in a room by ourselves and write code. So we're maybe not naturally suited to get along, but that ... like it's a problem like any other. You can't get better at being on a team, if you just decided it's important and practice it. It turns out it is important. So like, do it. Get better at it. Figure it out, right?

David: 00:25:03 Sandi, do you know anything about the modern agile movement?

Sandi: 00:25:09 No, I don't think so.

David: 00:25:13 Does anyone know anything about the modern agile movement? This is unfortunately a slightly distant memory from a talk from a discussion with someone at a conference. I don't want to misrepresent it, but I think it's called Modern ...

Sandi: 00:25:24 It kind of makes me want to Google it.

David: 00:25:24 Yeah. I maybe getting this wrong, but it's a movement, basically that is about that kind of [inaudible 00:25:31]. It just occurred to me that I met a couple of people a couple years ago who were very much talking about that.

Sandi: 00:25:39 Well do we want to get stuff done or do we want to have our way, right? And if psychological thinking is what helps us get stuff done, we should just get better at that. I don't know. Now we're getting like ... let's just rip this right off. Like how do you feel about style guides? Straight to the heart of this issue.

David: 00:26:08 The heart of the ... yeah.

Sandi: 00:26:09 Why are we fighting about style?

David: 00:26:13 Right. I think when we fight about style, for me, it's because of predictability and wanting to ... I mean yeah I can look at some code and if somebody puts a space before a bracket and someone else doesn't it's not really going to dog me. But on the other hand, there are certain things for me with style where, I don't think, it's kind of speaking the same language or the same dialect or something.

Sandi: 00:26:40 So if you were, in effect, to you. You too.

David: 00:26:43 To you?

Sandi: 00:26:47 To you. If the whole team had a style guide that everybody agreed on and you arrived as a new hire and they were all agreeing and they were all doing it, and you wanted a slightly different style. What would you do?

David: 00:26:59 What would I do as the new person?

Sandi: 00:27:00 As the new person. Yeah.

David: 00:27:03 Well, there's something called dot robocop dot yml and if you look at the commit history to around when I was hired ... you know. That's actually true though. We use a linter essentially and it's funny you should ask because one of the first things I designed in my second year when I was thrown onto the Ruby project, I made some changes. Those changes went through code review.

Sandi: 00:27:37 I feel the need to ask this question in a different way. Is it more important in a shop that all of the code follow the same style? Or that some individual gets their own way? Don't make me hurt you.

David: 00:28:12 Are those opposite outcomes I guess? If your own way is to have ... there is a legend in my family, that my father says his mother once said to him, Charles you always want your own. He said, well if I didn't want it, it wouldn't be my way. So there's something to that.

Sandi: 00:28:28 I mean I love my own ... in Ruby, in essence we don't have a thing where we all agree on. Like I think my way is the right way and everyone should write in my style. But if I went to a shop and they had a different department, and they were all doing it, I would cave because it's more important that all the code look the same then I get my way.

David: 00:28:37 Right.

Sandi: 00:28:37 That's really what I'm trying to say. [inaudible 00:28:51].

David: 00:28:54 Well in spite of having edited robocop.yml, I still agree. Yeah, no. I think the style ... I think certain stylistic things in languages ... I mean I do have opinions of it.

Sandi: 00:29:13 It's because I go and do brief little ... I arrive at a place and I'm there for three days and I do that a bunch of times a year. In some of those places, they are just killing each other over the style. Like people have cried in my class during the conversation about style guides and it feels to me that those fights are about power. They are not about tech. And that's a collaboration problem and it just feels like, I don't know, we should find a way not to do that.

David: 00:29:45 I will say also I think that when people do code reviews and we have a very strong code review culture on my team, one thing is there's ... basically I think kind of working or understanding agreement, at least maybe unwritten but still, that you can't just say you know I don't like that style. Even I ... I don't like it else. If we have a working agreement that says the team has agreed not use if else, or whatever, then yes you can say the team has agreed not to do this. But you can't just say I'm holding up this whole request because you did something ...

Sandi: 00:30:31 Because I can.

David: 00:30:31 Right. Because I can. Because you did something I wouldn't have done. It doesn't look like it was written by me, therefore ... yeah that's problematic.

Sandi: 00:30:37 And teams collaboration. Like I can remember what we were talking about.

Michael: 00:30:37 Actually that was essentially the next two questions.

Sandi: 00:30:50 See, we're good.

David: 00:30:50 We did have them in advance.

Michael: 00:30:58 I guess how do you handle a conflict when it's on your team but you don't necessarily hold a strong position? So two other people on your team are debating vigorously about the style guide, are there any strategies or can you speak to any experiences about how you facilitated that?

David: 00:31:18 No.

Sandi: 00:31:18 I mean I hate it when mom and dad fight. We've all been in this situation. It's like why are they not ... if they can't come to an agreement, it's not a technical problem right? There's something else going on. Because ... you know if you really want to get the job done, [inaudible 00:31:39]. I mean I want you all to use curly braces all the time. No more of that do and stuff. Right? It's not important enough to get ... like okay here is the thing I do advise people on sometimes. Like if you and I have a big difference or me and David or we all, maybe I have a difference with both of you. Like we just alternate who gets to win. Like I'm going to go ... I'm going to resolve, like you have to tell me everything, every place you have a difference, and we'll just go through the list and swap them. And then we'll agree, the thing I'll make people do, I'll say, you have to do it my way. I'll do it the easier way and you do it my way for a month and at the end of that month we'll switch. Right?

Sandi: 00:32:16 So we make that bargain. Then what happens at the end of the month is nobody ever wants to switch because by then it's become clear that it does not matter. Right? Well whatever we're doing right now, we'll do it forever. So like ... I want ... I sort of want to circle back to bosses here. I want the people who ought to have power in these situations to step in and talk to the folks who aren't getting along about power. Right? There shouldn't be winners or losers in that situation. And the reason those bosses get paid more money is to deal with the hard problems and those problems are the problems of the people.

Sandi: 00:32:57 And so I just want someone to make them behave. And I'm happy with that. When I was a boss I did that. Like I'm not, like I'm going to make the playground be fair for all the people who are mostly behaving well which means that I will have the hard talk with the people who are not behaving well and I want my bosses to do that too.

David: 00:33:18 And I think you're absolutely right that something else is going on. I mean it's probably, especially if it's a recurrent some kind of personality issue between the two people, not just the [inaudible 00:33:30].

Sandi: 00:33:29 The other thing I would say is those fights come down to fear. Those people are afraid. Right? Like why can't they let go? If they weren't afraid, they'd be like yeah whatever.

David: 00:33:38 Now I should add that do end and curly braces [crosstalk 00:33:42], do have different precedence. I know you know.

Sandi: 00:33:50 Yes. He's right. I'm not saying he's right. But I almost never use the do ends. I much prefer ... I know see? [inaudible 00:34:00] was up here groaning like ... if I was on your team and this [inaudible 00:34:02] I would just do it. I might complain about it every time I did it, but I would still do it. I would write code that looked like ... like if you can look at code and tell me where it's costing your business money. We don't get to decide that, you know?

David: 00:34:17 Have you used linters like robocop? I did. Actually, you know I've written a little elm word, like those languages that have the automatic reformat, or something. And I just hated the code as it first came out, and then I got used to it. 

David: 00:34:30 Because actually I have begrudgingly kind of embraced robocop and what it does, which for those of you who don't know, it's a linter for ... and I was kind of disgruntled when I first saw it because a couple of things. Like and and or and double ampersand and these are all non interchangeable. You can't choose between them because they do different things. So, that was one of the things that went out of our channel file. But I was ... I don't know. Kind of ...

Sandi: 00:35:04 It would be nice if we could just take it off the table. Like they have in go. And they have it at home and all those languages that automatic format. Like why are we wasting our time in a fight to change that?

David: 00:35:15 I think just in terms of the linter itself. At first, I really kind of didn't want to use it, but it's actually saved us so much time.

Sandi: 00:35:24 Yeah. I mean I know I want my way.

David: 00:35:25 My way?

Sandi: 00:35:25 I do want my way. We all do. And we can't all have it. Anyways, so it's a lot of verbal ground in the style guide. I saw a hand over there. Are we taking questions? We could?

Michael: 00:35:38 We will in a few minutes so get ready. They'll be a line forming there in about five-ish minutes for any audience questions. So just kind of shifting gears here a little bit. How do you know if code is maintainable?

Sandi: 00:35:59 You find out as time passes. Duh.

David: 00:36:10 Right. I think you find out that it's not maintainable.

Sandi: 00:36:11 Were you surprised?

David: 00:36:17 Well I don't mean you always find out, but I mean, yeah I guess you kind of take it for granted. Like if you're working on code and ... let's just say more often do you say, oh this code is not maintainable. Wow. That was really maintainable. Like you kind of don't know the best phrases that you don't even notice.

Sandi: 00:36:33 Or it never changes again and it doesn't matter.

David: 00:36:36 Well right. That's the other thing. If the sort of don't bother cleaning it up until you're touching it again anyway, which I actually do believe in. Even though if I see the file, I might be like that. But on the other hand it really ... I mean we all have that itch to make everything beautiful and perfect and so on. But that has to mesh with the business cycle and not, we can't go off on those tangents too much, but if you are touching the file, I do believe in ... if it is opaque or unmanageable and making some changes.

Sandi: 00:37:11 It feels like a question that's so open ended.It feels like a proxy for some other question, like how can I convince people to write code my way? Right? That's sort of what it feels like. I am all ... and I'm sure David is too right?

Sandi: 00:37:28 I get in a lot of situations where, like I teach these classes and I teach a vision of OO and people always ask me, like I'm going to go back to my office and no one is going to want to do this, right? And because we don't have any metrics, how do we know that the advice that we give to people is correct? It really is a matter of sort of paying attention to what hurts later? There is no real, I mean in some ways, we make it up and then we believe it. I mean it's true, right?

Sandi: 00:38:04 Like my belief is, that my experience writing code, that I believe that I am right and there's a certain way to organize code that will cause me less pain and cost me less money later. And that experience is from me just writing codes and looking at many applications. But I don't know. Maybe I'm not right. I feel like I know, but who knows. Yeah exactly. Time will tell, right?

Michael: 00:38:32 So I'll ask one more question for now, but if you would like to ask a question, if you could just line up right behind the camera here, and then I'll give you the mic after and you can ask your question. And this is just kind of broad, what excites you most about software right now?

David: 00:38:55 Right now?

Michael: 00:38:56 Yeah. What are you excited about in software? I didn't ask this one ahead of time. So I'm putting you on the spot.

David: 00:39:05 Oh curve ball. Do you mean sort of in my work? Or in like what's going on in the software world? Please say the former, because I don't know anything about ...

Michael: 00:39:20 In the software world. Any trends or like what makes you excited about software right now?

David: 00:39:25 I was afraid that's the one you meant.

David: 00:39:27 What's that?

Sandi: 00:39:27 I'm ducking this question.

David: 00:39:34 Okay. We might have a ducking conspiracy.

Sandi: 00:39:37 Right. It's all exciting. It just keeps changing every day. I told you I punched cards, right? Now we've got phones. Like phones still seem new to me. I'm excited about my phone.

David: 00:39:46 The way I would actually answer that is I kind of know it when I see it. I really don't ... I'm not encyclopedic about sort of what's going on. I don't know ... I probably know fewer languages that have cropped up recently than I should. But I know it when I see it. Like if you had said to me, one November morning in 2000, what excites you about software? I would have said, oh this and that. An hour later I would have said Ruby. Like I just [inaudible 00:40:17] the pick ax book in a bookstore and I can't take my eyes off of it. So you know it when you see it I think.

David: 00:40:24 Look, I don't personally look exhaustively. I have a lot of work I have to do. I know people are more diligent about that than I am, but I do think you know it when you see it.

Sandi: 00:40:37 Everything is cool. It is. I don't think we have to predict what the next perfect thing is right now. Just do all the stuff. Things will happen. Pay attention.

Michael: 00:40:50 Are there any questions from the audience? Ideally if you all could, if you have a question, if you could come up here in a line ... oh Zach's got it.

Speaker 5: 00:41:01 It's very intimidating to welcome you.

Sandi: 00:41:03 Congratulations.

Speaker 5: 00:41:10 I have a question for both of you. Speaking of continuous development as you go through your programming career, how has writing something as long and involved as a book, changed your own development and the way you look at day to day work?

Sandi: 00:41:28 David seemed to like writing better than me. You talked a little bit about ...

David: 00:41:32 I thought I write better than you.

Sandi: 00:41:32 It's tortuous for me to write. And so, I mean ... it was a very big deal to me to like get up every day and do it, till it's done instead of quitting. It took a long time to write the book. It was probably, I mean I worked on a lot of software projects that lasted for many years, but the really killer parts never really were ... more than ... the hard pushes were maybe six months or a year at a time and the book was way longer than that. So, like I feel, for what ... I mean I can't speak to the worth of it. I can't speak to anything about, like the only thing I feel really comfortable saying about books I've written is I'm enormously proud of having to finish them. Right? All the rest of it is something else. But that I feel enormously proud of and it's made me feel like okay I can just do the hard thing for a long time.

Sandi: 00:42:33 Like I can put my nose to grind ... like I feel like I could be good at things, but now I feel like I can really do anything. And it really is just a matter of doing the dirty work every day. I don't know.

David: 00:42:43 No, I love writing. And actually in my academic career I wrote one single authored book and lots of chapters and articles and encyclopedia entries and this and that. So, I've always liked it. It's an interesting question though. In terms of writing about something and also doing it ... one thing to keep in mind is that ... after you've written the book, it's not necessarily in your day to day life. You know, I sometimes think of it, like I don't know. Think of somebody who recorded a song in 1979 or something, and you kind of think if you met them now, their life would be about ... like that was two days of their life.

David: 00:43:31 Now it's more than two days, but there's a little bit of that. That it comes in and out of my radar. Obviously the third edition just came out recently, which was coauthored by Joe Leo, available at ... nevermind. Anyway. So there's been this sort of, so the book has ... my Ruby book is going to come back into view a lot lately for me. But I get through many days and weeks and whatever where it doesn't figure very largely necessarily because I'm not teaching from it. I'm not really using it in that sense.

Sandi: 00:44:08 It's also true though that, and I would say this to you and to everybody. It will change ... giving a talk at a conference changed my life and writing a book changed my life right? So, it turns out you don't really have to be anybody or know anything to write a book as ... you can speak to David about that. I mean I was completely unqualified to write a book. And so, you know, if you know anything now, you should write it down and someone will be grateful for it. So have at it.

David: 00:44:38 I'll just say this about book writing also for me and writing in general, it's performative. What I mean by that is I don't sort of have a book in my head and just busily dump it down onto the ... the ideas actually come to me as I'm writing. I mean I have maybe some kind of outline but even that is subject to change, page by page. It's like aha, this is how ... and that's one of the things I find exciting. That it's in the moment. You sometimes think of writing, especially a technical thing. You have an outline. A slightly more detailed outline, then write the actual paragraphs. It doesn't work that way for me. And that's what makes it more interesting.

Sandi: 00:45:19 I would agree. That was the most immersive thing I've ever done. The most immersive project I've ever worked on. I dreamed about it. I would wake up in the morning and walk with my eyes shut. Like if I opened my eyes, I would lose it. I would wake up dreaming in paragraphs of text and I would walk with my eyes shut into my keyboard in my office, and I would put my hand ... get my hands to line up and I would type paragraphs [inaudible 00:45:40] and I would look at them later and they would be [inaudible 00:45:42]. Otherwise I would forget. I would have the perfect thing to say to explain an idea and I would have to get it down before it drifted ... they would drift away like dreams every morning.

Sandi: 00:45:51 That makes it sound like I liked it but I hated it. Anyway thank you for the question.

Speaker 6: 00:46:02 Hi.

Sandi: 00:46:03 Hey.

Speaker 6: 00:46:04 You both shared some stories about moving onto new teams, moving onto new projects, talking with new people. That stuff. What techniques have you used or have other people used on you when you were moving into a new space or a new problem that helped you pick up context, figure out what was going on, start providing value, quicker than you would have been able to otherwise?

David: 00:46:35 For me, you know I think as they say, everyone learns differently and that pertains to something like getting up to speed on the project with the code and stuff. For me, what benefits me the most is sitting there when someone just slogging through tickets and asking questions and just breaking down my [inaudible 00:46:59]. I think of it as breaking down the ignorance as much as building it or something like that.

David: 00:47:05 I have to say, when I, again this is just how I operate. How my brain operates. I get kind of limited return on like looking at diagrams of how systems that I don't know anything about interconnect. So if I join a team and somebody on the team will sit me down and walk me through sort of the architecture. It interests me but it kind of disappears. I have to sort of walk through the looking glass, you know, and actually be in the project and in the code. And it is a gradual project depending on what the project is. It can also take a long time depending on how big and the problem.

Sandi: 00:47:51 So I found that super fascinating because I am just the opposite. Like I feel like the details all fill in easily for me if I understand the larger abstractions. So I want to look at your code climate output to know where all the dragons are and then I want class diagrams so I can see the big picture of how it all fits together. And everything else is like a detail to me. I can just open the file and figure it out.

Sandi: 00:48:15 So like I need to be completely oriented on the whole map and space first, then the parts. Like I'm making ... I'll fill in the parts from the whole and it sounded to me that you just said you build up the whole from the parts.

David: 00:48:27 Kind of. Yeah. I would say, like I said, it's informative to see let's say an architectural diagram or whatever and I might even go back and refer to it, but I don't feel like I'm sort of a master of the project until I've really rolled up my sleeves and had the opportunity to ask those questions. And then it's like oh I get it. That's why ... you know whatever. This foreign key has a weird name or whatever. So yeah it is kind of a bottom up process. And you're describing kind of a top down.

Sandi: 00:48:58 I need the whole ... like a very high level map of the whole space because otherwise I am disoriented every time I stand some place. [inaudible 00:49:06].

Speaker 7: 00:49:06 I am writing a book with another person and I know Sandi you've talked about this on a podcast with Katrina Owen. But when you talk about style guides and the code that our team will see, that's one thing, but when you talk about a book that hopefully millions of people will read, where does humility come into that and honestly what do you learn from co authoring with another person when you're writing something as substantial as a book?

Sandi: 00:49:46 It's hard. Right? Writing is really hard for me and then I have to sit and negotiate it with someone else. You just want to kill them. Here's what I would say. Have that ... like if you really, like with Katrina Owen, you guys can't really see the guy sitting up here in front. He was the coauthor of the second edition [inaudible 00:50:12]. You guys see, right?

Sandi: 00:50:15 Either you have to be enough alike so you don't have a lot of conflict or so different that you decide in advance that you value them so much that that conflict is useful. Like TJ and I are a lot alike and Katrina and I are really different.

Sandi: 00:50:27 So it takes a real commitment to that. The other thing I would say is get a good editor. You can pay someone to resolve conflicts about the voice, the tone of the voice when there's more than one author. I would get a professional to resolve that. Really it's about figuring out how to get along while you're writing and then any style differences can be solved with money.

David: 00:50:56 Yeah I'm in a slightly different situation ... basically I wrote the first new editions of the Well Rounded Rubyist without a co author. I actually contacted the publisher and said, we should really do a third edition and I don't want to do it basically. I didn't quite put it that way, but you know, I've been living with ... this text started as Ruby for Rails. I took the Rails parts out and then I expanded it and then I did the second edition. It was kind of like I've been working on this text in one form or another since 2005. I really ... I said I'm not withdrawing from the project but I'm not going to do, for a third edition, what I did for the second edition.

David: 00:51:38 So we brought in Joe Leo, which was my idea and I think it was an inspired idea. I mean ... Joe was certainly following the details of the changes in Ruby at that time more than I was. He wasn't burned out on writing the book. It was kind of different because I was in a slightly more passive role. I helped out and I did ... but Joe really was, and I've said this publicly before. Joe did the lion's share. Joe Leo. Lion's share. Joe did the ... [inaudible 00:52:13] ... I mean really. He sort of went through the whole book and added some Ruby stuff. He also freshened up examples. And we talked about some of this as it was going on.

David: 00:52:25 But, sort of got rid of some stale examples, added some exercises, wrote a chapter on functional programming and so on. So it was kind of a different thing. It wasn't really the two of us sitting at a desk, you know, having to negotiate the wording of stuff. We talked about certain things, but it was kind of a different situation. A different dynamic.

Sandi: 00:52:49 The one thing I would add before you sneak away from the microphone. Like, the first book I wrote, I wrote by myself and you know what happens is people say they want to read your stuff and then it turns out they have their own lives and they don't really want to. Like no one cares as much as you about that book you're writing by yourself. So, if you can find a way to collaborate, like if you want to write a book and you can find a way, at least someone else is like as motivated as you are to make it ... you've got someone to talk to because they care. And no one else really cares as much about it as you do at that point, so it can be super handy.

Sandi: 00:53:25 Even though it is harder. So again, you want it to be great.

Speaker 7: 00:53:31 Thank you.

Speaker 8: 00:53:33 Hey. I just want to say thanks for coming in and sharing your experiences. It was excellent questions. It was all really interesting to hear. My question was actually for you David. You mentioned that, I feel like it was fair to say that you weren't a huge fan of managers for a bit, a little while ago.

David: 00:53:48 Well I would say I was very skeptical about ... it's not that there were any specific managers I didn't like or whatever. I mean I probably have, but it was more just sort of I kind of bridled at the whole thought of anyone telling me what to do. So yeah. Something like that yeah.

Speaker 8: 00:54:06 My question is was there anything specific that changed your mind about that? Or you just realized one day?

David: 00:54:13 There was a couple of experiences. There are people in this room who would know exactly who I was talking about but I'm not going to name names. But we're going back almost, let's say, 10 years and just experiences of like oh yeah. This person is doing something incredibly well and it's something I couldn't have ... there was always that slight skepticism. Like oh I could just do my work myself. It's like no actually. This person is kind of abstracting things away that would stop me from doing my work, that I couldn't abstract away. This person is running interference with upper management.

David: 00:54:58 So it was just more experience on my part I think of people who knew what they were doing.

Speaker 8: 00:55:04 Cool. Thank you.

David: 00:55:04 Okay.

Speaker 9: 00:55:09 So I was wondering, since the industry changes very, very fast. Kind of ... and sometimes it can change kind of under you, while you're not really paying attention. What advice can you give to somebody who might be going to, let's say, a different stack or an entirely different programming language and how do you handle you know, making that change?

Sandi: 00:55:35 Again, it might just be that I've been around too long and seen too much. It feels to me like programming is programming. And there's a couple of different stops and if it feels like you can keep a job somewhere, you should have some passing familiarity with all those styles. Like you should know a little about functional, a little bit about [inaudible 00:55:55], maybe static and dynamic typing. Right? [inaudible 00:56:00] is easy because we all know that, right? Frameworks. I don't know. Frameworks kind of go like window shades going up and down, right? I mean it is ... you are sort of on the enviable other side where like I have so much, I've worked on so many different frameworks that new frameworks don't seem intimidating.

Sandi: 00:56:17 It's like well, just another one right? And I'll just learn it. It's probably not the kind of thing that if you were a 20 something that just got out of code school, probably a perspective employer would not have that same level of confidence that you just come and pick it up. I mean I would just say, do good work and learn. Try not to get stuck. Here's the thing. Things will change around you. Like I've wrote cobol for as many years as I've written any other programming language. And, there's just no more cobol jobs right? That was easy to stop writing cobol. It's not like there's this gravitational pull being exerted by cobol now right?

Sandi: 00:56:58 So, just do good work. I just feel like ... maybe I'm too optimistic.

David: 00:57:04 I think also, there's factors that are not necessarily in your control. Like the team you're joining. Let's say they hire you and new technologies. I'm thinking back again to when I started at 2U and I was doing Python primarily. And I was very fortunate, actually that first year I was on a very small team. And, it was ... everybody was just very mentoring, so very helpful and we really collaborated and everyone's cards were on the table. Everybody knew I just started learning Python, basically the day I accepted the job a few weeks earlier.

David: 00:57:45 So I wrote some game in Python and sent it to them before I started, just to be critiqued and so on. Kind of jump start myself. That was very fortunate. You know if I had been kind of thrown in at the deep end. It was a little bit of the deep end, but in a way I could handle. It was partly because it ... nobody was trying to set me up for not succeeding. It was very supportive.

Sandi: 00:58:15 Can I add one more thing to that? Because I had a minute to think. I definitely have been in situations over the arc of my career where I was in a bigger organization and they were on something, whether it was the standard technology at the time and new stuff was coming and we could see it coming. And we were all good at the old stuff. And I wanted to be on the new stuff. It was very difficult to get a larger organization maybe to let you go, if you're valuable doing what you're doing.

Michael: 00:58:48 We'll take these last two questions. And then I'll end with one final question.

Speaker 10: 00:58:52 Hi. Oh gosh. This question is going to seem a lot like the last question, but I was wondering, you two are obviously Rubyist, what do you think the value is in being a polyglot programmer? It seems like as engineers especially when you're looking for jobs, it seems like a negative connotation around being a Ruby developer or being a Java developer rather than being an all purpose engineer that doesn't care what stack or what language they work in. What are your thoughts about that and how important is it being able to adapt to any language the organization requires?

David: 00:59:37 I think you kind of meet it half way. It depends on the job market, on the situation you're in. In other words, the ideal I guess would be to find an organization whose mission you were interested in and who was using technology you were interested and everything kind of degrades from there, right? So yeah again, it depends on maybe your financial situation, the job market like I said.

David: 01:00:06 I think just taking a job without any thought of you know whether you are interested in the technology. It could be risky, in the sense that you probably would quit. I don't know. I mean I'm thinking if you just want to flow through it. But, yeah I guess ... you see also there's a difference between a polyglot programmer and someone who kind of does everything because no one does everything.

David: 01:00:41 So again, I think it depends on just finding a good fit. That maybe a kind of circular reasoning. It will be a real answer ... over to you.

Sandi: 01:00:48 I'm going to say exactly the same thing in a slightly different way I think. For me, I care about the mission. I want my work to feel like it has meaning. And I really like Ruby, right? It's really nice if those things align. If they don't align, I don't want to write Ruby for a business that I don't feel good about. And, I would do a lot of things. I would write in languages that I don't write so well if the mission were exciting enough, right? There are some place where there's lines, like there is a balance between those two things.

Sandi: 01:01:25 I don't think you have to be good at everything. I think people who tell you that they're good at everything are just lying. They are not humble enough. I mean it's good to have enough to understand when you ought to ... when the problem suits a language other than the one that you prefer, right? You want to know that. You don't want to push everything in a round peg of whatever your preferred tool is. But there's a lot of freedom in that. Right?

Sandi: 01:01:52 You feel free to love Ruby the best.

Speaker 11: 01:01:59 Hi. I was just wondering what was your motivation for writing your books? Like, did you always want to write a book or was there something about existing books that you just didn't like and thought you would do it better?

Sandi: 01:02:13 I would have ... where's Deb? Did he leave?

Deb: 01:02:13 No, I'm over here.

Sandi: 01:02:14 Deb made me.

Deb: 01:02:15 I did actually.

Sandi: 01:02:20 You should go.

David: 01:02:24 Okay. I've written several books with different motivations. I guess my first book grew out of my dissertation. It's ancient history and I wanted to get tenure which I did but I needed to write a book. But in terms of computer books, like I said, I really love writing. I kind of wish I had the writing project now, because it's been a bit of a dry spell. The third edition of Well Founded Rubyist has come out, but I'd like, it would be fun for me to have another writing project.

David: 01:02:50 But in terms of motivation, I can answer that very precisely in the case of my first single author computer book which was Ruby for Rails. My motivation was that I had been using Ruby since 2000 and in 2004, Rails came long and I got very interested in that. Over the next year I noticed that people were saying, I really love Rails but what's this Ruby thing? Do I need to know anything about that? And my response was Ruby for Rails. To write a book. So that was ... you know it kind of fell into place. The right thing at the right time. The publisher actually contacted me and said, we were kind of casting about of opinions. Should we have a Ruby book? And who should write it?

David: 01:03:39 And I said yes. Me. So it converged at the right time. But I did have ... I said I have an idea for a book. And that was the idea. Then, getting even more I guess on a personal level, in terms of my writing projects. I then wanted to write a pure Ruby book without the rails. So that was just kind of my itch to scratch and that's where the Well Founded Rubyist came from.

Sandi: 01:04:07 So for me, I got overheard doing a rant at a hallway conference about a technical explanation that I felt was intended to make the audience feel stupid. And that was by Deb. Then she grabbed me and said why don't you write a book? And I was like well people like me don't write books. What are you talking about? I email code. That's what [inaudible 01:04:26]. Then I would run into her at conferences. For like five years I ran into her at conferences. She'd even take me out and buy me a really expensive meal and make me feel guilty. She tried thing after thing after thing after thing after thing. Finally she told me a few things, which I don't know if I've ever said out loud.

Sandi: 01:04:42 Like I try really hard to be all tech all the time. I feel like there's a way in which I'm representing my gender in tech. And I never talk about diversity on stage. It's a policy of mine not to do it. But I will tell you guys here tonight what she said to me that day that made me write [inaudible 01:05:00]. She said, you're using open source software and you're not giving it back. She also said ... this was in like 2010. She said there's not a single Ruby book, not a single hard core technical Ruby book that has a woman's name on it. I was like okay.

Sandi: 01:05:22 I have another book, the 99 Bottles of [inaudible 01:05:24] book. I teach a course really curmudgeonly. I don't like leaving my house. I have a dog. I enjoy my dog. So it costs a lot of money to get me to come somewhere. It's a great pleasure to me that people want that course. So it's booked far out in advance and the price has been going up and up and up and up, right? And that means that people like me, born in Partridge, West Virginia, eight years of night school to get a bachelor's degree in psychology, learned to write four tran at a voc tech school in 1980. People like me are never going to get to take my course.

Sandi: 01:06:01 So we took the content and started writing it down in a book, so I could get it in the hands of people who might be more like me. So the motivation. There you go.

Speaker 11: 01:06:09 Thank you.

Sandi: 01:06:11 Yeah you bet.

Michael: 01:06:15 And finally, from the conversation tonight, are there any high level takeaways you'd like the audience to walk away with today?

Sandi: 01:06:24 I was struck by the general agreement about the style guide. It just feels like there's ... issues of power are things that we maybe don't talk about enough. And maybe we should do that more.

‍