Soft skills, communication, and programming as a thinking activity with Trisha Gee of JetBrains

Transcript

Ledge: Trisha, good to have you. Thanks for joining us today.

Trisha: Thanks for having me. Always a pleasure.

Ledge: Could you give a little background story of yourself and your work, for anybody who doesn’t know you in the audience?

Trisha: Absolutely. I’m Trisha. I’m a Java developer, or I have been a Java developer for about 20 years, or something terrifying like that. For the last five years or so I’ve been a developer advocate, which means mostly staying on top of Java stuff. Doing a bit of Java development stuff, but also doing blogging, going to conferences, speaking to other Java developers, keeping up with trends. That kind of thing.

Ledge: You do that for JetBrains. Tell us about JetBrains, because I think you guys do some really important work for the developer class.

Trisha: That’s nice of you to say that. Yes, I work for JetBrains. I’m the IntelliJ IDEA advocate mostly. Most developers either know IntelliJ IDEA or Rider or ReSharper. We do bunch of IDEs.

We have team tools as well. We’ve got an issue tracker and we’ve got TeamCity for continuous integration, but most developers know the IDEs.

Ledge: I saw, and the reason we got in touch was, I saw you do a bunch of talks about both soft skills for developers and for career path development for developers and programmers. So, thinking about how to move through. You tell some good stories about some mistakes that you made and places that people can pave their own way and set their goals.

I loved all that. I think there’s a lot of intersection of those two topics. I’d love if you’d dive into some tips there and then I just ask some question.

Trisha: Sure. The whole topic of career advice for programmers is something I’m passionate about because I’ve been a programmer…

I did computer science and I followed the traditional programming career path, if you like. Despite that, I didn’t really have a lot of guidance on what it meant to be a programmer, or how to progress my career.

Particularly because I started at an enterprise – I worked for Ford Motor Company – obviously the career path for that was to go into management after two to three years of development.

After five then maybe 10 years of being a developer, I started to understand a bit more about how to get ahead, but that’s mostly in terms of how to present myself, how to interview, how to do my resume or my CV, how to network. Then over the last five years of doing a more senior role and speaking to more senior people, I’m starting to see that side of stuff, getting in the entry level stuff, requires you to take a bunch of boxes and to do things that might not be comfortable for you in terms of gathering skills, in terms of doing jobs that you don’t really like, probably.

Then, as you get more experienced, it dawns on me that there’s a whole bunch of other things that we don’t know that we need for our roles. Even if we continue to stay hands-on technical coders – and this is the topic of my most recent presentation – communication skills. How we talk to people. How we phrase questions. How we listen to those questions. How we interact with other people. All these things.

I went to university in 1997, and it’s now 20 years later and it’s only just occurred to me, we need to be able to talk to people. No one really said that. They said, you just have to talk to the computer.

That’s the easy bit. Talking to the computer is the easy bit. Talking to users, talking to customers or even ‘just’ a developer, talking to other developers. These things are skills, and skills that we are not encouraged to focus on.

Ledge: You’re right. I was a computer science guy too and it’s about the engineering. It’s about the science and algorithms and code, and how to get things to compile.

You’re right. No one talks at all about this other stuff.

When I started in the industry, also about 20 years ago, it was still – at least where I was – kind of okay for the developers to be down in the basement, sitting behind the screen. The lights are off and we’re these creepy basement dwellers that wrote code. I mean, we weren’t even allowed to talk to the customer.

Trisha: Right.

Ledge: It’s marveling to me to see how that has inverted. There was no phrase about your customer empathy or anything like that. UX wasn’t even a thing.

Trisha: The funny thing is that, having those skills did make us better at the jobs if we were able to talk to other developers even. As a developer advocate, that’s my job. I speak to other developers, and of course we have our own language.

Even the ability to write a well-named variable or a well-named method, this is a communication skill. Even if we were basement dwellers, which we were at some time, we weren’t even encouraged to communicate with the other basement dwellers.

One of the things is, it’s not just that the industry has changed a lot and, obviously, communication is important. Working in an agile way is important. Things like DevOps which allows us to cross boundaries. All those things are important and has meant that communication skills are even more important than ever. But I think our industry always required a certain level of communication skills and we never were aware of that, or pushed that.

Just to get under one of my other, this is another reason why we have a diversity problem, because there is this perception that we are non-communicative basement dwellers, and it’s not true. It’s not the truth.

It’s really important for us to be able to talk to people. These skills are not only like, oh, yeah, that would be nice to have on top of technical skills, they’re one of the ways that we can learn technical skills. By listening to other developers. By learning stuff from them. By asking them questions. Then, as we become more senior, by sharing that knowledge through these so called soft skills.

That makes us a really good senior developer, or lead, or CTO, or mentor. Those are the skills we need to become very senior.

Yet, all that we see in media and all of our perceptions of this technical career path is, it’s all about talking to the computers and it’s about white men sat in basements not speaking to each other. It’s not true.

Ledge: I actually sat in the basement with some women at that point. So, very diverse. Not really, but…

I agree it all goes together and I think we have this inclination sometimes to allow that narrative to be told as if it doesn’t. That, diversity is over here and somebody in HR should think about that. Management is over there. Sometimes you cross the boundary between tech and management but that’s different too. Then you still have these coders.

I think that belies the opportunity to think in a more complex and systemic way, which agile and many of these types of disciplines kind of forces to happen.

I think across the organization – tell me if this is true – it really takes the same skills across all the functions. Everybody ought to be doing that. Soloing is a standard problem in organizations. We get stuck in our craft, and we like our craft. Sometimes we don’t even want to be those other people but you’re just going to have to do it.

Some developers don’t want to be management, don’t want to lead anyone. You still need to be able to communicate, right?

Trisha: Of course. I was thinking to myself the other day, one of the things that I would have liked to have got better at as a more junior person was communicating with the rest of my team to sell them on my ideas. That’s almost a leadership skill, but it’s even more difficult if you’re not in a leadership position. When you’re saying, “Look. I know we have this design approach, but how about we think about it from this point of view?” Those sort of persuasion skills, which make us good team members and potentially improve our code, are just not valued enough.

Ledge: What are some of the key skills, lessons that you have learned? Distil down some of that into some actionable, hey, you better go do this while you have time.

Trisha: I went to LMAX, which is a training platform in London. I was looking to work in a so-called agile shop for a long, long time. I went to places that had two-week sprints, or little cards Blu-Tacked on the wall, but they weren’t really agile. They were just using these techniques to paper over the classic problems of slipping deadlines and, like you say, silos and things like getting the requirements too late, and stuff like that.

Oh, if we work on one-week sprints that will solve the fact that our requirements are late. No, it won’t. They’ll just be late every week.

When I worked at LMAX, they were doing agile the way that I’d read about it in books. Which included self extreme programming in terms of pairing. Not just pairing with developers, pairing with business analysts, pairing with technical testers. By technical testers I don’t mean necessarily coders, but people who can write code and run automated tests.

We were also doing some DevOps stuff in terms of, we didn’t pair with the Ops guys, but we – I use the word guys because they were boys – but the Ops people. We did a lot of work with the Ops people saying, look, what are the problems you face when we fling this object over to you and get you to deploy it? What are your pain points? What can we do to help?

There’s quite a few things there which made me realize that the way we develop software can be done differently. One was constant communication. Pair programming is all about constant communication. Pair programming with a business analyst and a tester is totally different to, “Here’s the requirements document. Read it. Potentially ask me questions over email which I’ll reply to you in like two week’s time.”

This is, sit down. Explain to me, okay, this is how I, me as a developer, this is how I understand the business problem. Does that sound right to you? What about this edge case I’ve thought about. Then having the testers there saying, have you thought about what happens when the user does this ridiculous thing that of course the user will never do except they’ll do it all the time?

So this is sat at the computer and helping to flesh out the automated test. This communication was super-useful.

From a technical point of view, I enormously upskilled because I was pair programming and I was learning how to use Intellij IDEA every day. The shortcuts, you don’t even know how to look for them because you don’t know they exist. The functionality that’s in your tools that you don’t know about, and you don’t know you don’t know about, you learn so much about it.

One of the things I thought was really useful there was understanding some of the compromises that we had taken. Whenever you’re working on a code base, there’s always like three or four different styles because, you know, that’s last year’s fashion. We did it that way last year. Then, we were doing it this way but we really want to go that way.

When you’re pairing with people they can be, especially when you’re getting up to speed, look, I know it’s done this way but the code over here is the way we want it to be. That’s much better than having documentation on confluence or something like that. When the whole team is having those conversations, that knowledge is always fresh.

So, pairing, for me, was a very specific, actionable way to get up to speed both the business domain, the technical domain, the tools we use, and crossing those barriers of communication in terms of the business and the testing.

Ledge: It strikes me that the organization needs to understand and be willing to invest in what would appear to be inefficiency in the short run. Three people sitting around one computer, if I’m a bean counter I go, “Geez. That’s expensive. Separate those people. Get them to work.”

You need to be willing to invest in that.

Trisha: It’s really tricky, because we tend to assume that programming is a typing activity, which it is not. It is a thinking activity. So you tend to assume you’ve got two people next to one computer, then the bottleneck is the keyboard. But of course it’s not because when it’s two of you, you’re having these discussions. You’re not waiting for someone else to answer your questions. You’re talking about the tradeoffs and potentially coming to a better design.

There’s a lot of studies about whether pair programming is actually faster or not. Of course, the answer is, it depends. There are also studies that imply that pair programming, you do introduce fewer bugs into the process because you’re having the conversations, you’re double-checking each other’s work, you’re keeping each other honest.

So, pair programming is not necessarily faster – it might be faster – but you can lead to better quality code.

That can be a bit worrying for organizations because they’re like, okay, fine, so I get code which is 50% better quality but I’m still using two resources. But you’re also doing things like you’re reducing your bus factor. When one person leaves the team you don’t have a gaping hole of siloed knowledge which has disappeared, and you don’t have to invest so much in activities to ensure that the knowledge is shared. You don’t have to invest in necessarily documenting the system. You don’t have to invest in…

We used to do things like brown bag sessions as well. We would have Monday lunchtimes where we all got together and chatted about stuff, and we had this like retrospectives and things. But a retrospective is an expensive meeting when the whole team is sat there in a meeting. It’s significantly more expensive than, say, pairing.

For us, pairing every day was totally valuable because we were working on a difficult domain. We were trying to get the code out quickly but with quality because it’s a financial domain.

Given other organizations that I’ve seen, other projects, other ways of working, it’s not always going to be 100% pair programming for everybody. There is going to be some times when you’re literally bashing out a CRUD application and it is as simple as create, read, update. There’s a lot of generated code and it’s just like wiring. You don’t necessarily need to pair on that stuff.

Sometimes you don’t want to pair when you’re doing a bit of prototyping because you want to play with it and see how it works.

We sort of had a thing of, if you’re writing code that’s going into master, you pair on that. You can prototype stuff on your own as much as you want, but you throw it away because it hasn’t been code-reviewed, it hasn’t been.

Ledge: Well, I know there’s equal studies on the quality front. You talk about the investment, it’s pretty easy to point to that, every bug that gets to production costs you 10 times as much to fix. That investment is only 2X, not 10X if you’re pairing.

You’re right. I do hear that a lot, though, particularly for clients that are paying by the hour. If I put six developers into retro for an hour, that’s a very expensive thing and you need to be able to really demonstrate to the paying entity that, in fact, that was valuable because it saved downstream.

You do get in a little of that… It’s a lot about trust because, we know that that works but we can’t prove that, had we not done it it would have been much worse and more expensive for you. So you get that ‘prove a negative’ kind of situation.

Trisha: It does depend, though. It depends a lot on management. It also depends on the team itself. We used to recruit specifically, knowing that we pair programmed every day. So we would hire people that we wanted to sit next to pairing with. It did mean we rejected some good technical candidates who we didn’t want to sit with and pair every day.

You can’t necessarily impose pairing onto a team that’s not designed to pair because there might not be those communication skills or that inclination. You have to build it a little bit from the ground up and, as you say, have trust and have management saying, this is the thing we’re going to do.

If you’re going to impose it on a team, allow team members to say, “This is not my thing.” So either to rotate into a different team or to perhaps only pair afternoons, or be part of mob programming instead of pair programming where maybe they could just sit back and watch rather than feel like they are being watched all the time.

Ledge: I just had a conversation the other day with a dev who said, “I am working so hard on my stage fright, but I can’t type in front of somebody.” Very much it’s like… When you’re that kind of craftsman, it’s like getting up on stage and speaking. So, kudos to those…

Trisha: It’s like doing a live demo. It’s like doing a live demo all the time, and it it really hard. You know the demo gods hate you, and you know that your brain is going to freeze as soon as you try and type something. So, pair programming, again, is something that requires practice, like anything else.

It requires you to have those conversations out loud. When you sat at the keyboard going, “I don’t know what this method is called,” or whatever, you need to say those conversations. Is it because you don’t know what the method is called, or is it because you’re a bit stalled because you’re not really sure where the design is going from here? Or is it that literally you just forgot that you’re supposed to order something? Right?

Having those sorts of out-loud conversations, it doesn’t necessarily suit everyone. But, if you can get into the habit of that, it’s fantastic for having those conversations out loud that you’re always having internally anyway. It stops you spinning in circled of, oh, I should do it this way, oh, I should do it that way, oh, I should do it this way.

You have those conversations out loud. You could do it with the rubber ducking too, but it’s better if the rubber duck talks back and says, “No. That’s not the right thing to do.”

Ledge: I know we could go on forever with this but I totally appreciate these thoughts. I think that, if we’re ever going to all get better at this stuff it’s just got to be out there. You’ve got to be able to have a dialog.

I appreciate your investment in doing that with us and thanks for being here. We could talk a long time. I know we’d enjoy it, but I hope the audience got something out of it.