AVDI: Hi friends!...that's what Scott Hanselman says whenever he starts a talk or a podcast. He's done over 650 episodes of his Hanselminutes podcast that he calls "Fresh Air for Developers." It's a tight 30 minute technology chat show that shares the same values that we do here at Greater Than Code. There's a huge library of guests for you to catch up on and a new high quality show every Thursday afternoon with a fresh face you may not have seen on other shows.

JESSICA: So go listen to it.

AVDI: Yeah.

JESSICA: After you're done listening to this one, because this one's going to be great.

SAM: Go listen in three, two, one, now!

JOHN: Welcome to Greater Than Code Episode 144. This is John Sawers and I'm here with Coraline Ada Ehmke.

CORALINE: Hey everybody, I'm glad to be back after a brief or extended hiatus, whichever way you want to think about it. I am super happy to introduce our guest today, Jamison Dance. Jamison is an Engineering Manager at Walmart Labs and the co-host of Soft Skills Engineering, a weekly advice show for developers. Jamison organizes React Rally, the first community React conference, which is going on its fifth year. He's a frequent conference attendee and occasional speaker. You can find him on Twitter: @jamison_dance or on the web at jamison.dance. Welcome Jamison.

JAMISON: Thank you. I'm so glad to be here. I've listened to a lot of these episodes and it's kind of fun to be on the show that I listen to so regularly.

CORALINE: Awesome.

JAMISON: I think you all are great and you do great stuff.

CORALINE: Thank you so much. So since you have listened to the show before, you know what our opening question's going to be. Jamison, what is your superpower and how did you develop it?

JAMISON: This question paralyzes me.

[Laughter]

JAMISON: One of my superpowers is not talking about how great am. I think after a lot of thought, I ended up on moving swiftly between layers. So, some amount of like context switching is part of that and some of kind of jack-of-all-trades is part of that. My day job is a lot of moving between layers, between code and people problems, and planning. And then the stuff I do outside of my job is podcasting and running events and writing code for fun. I like to do a lot of different things and I feel like I'm pretty okay at changing between them. Or maybe not an expert at all then. How did I develop? It would be like a lack of discipline. [Chuckles] I can't focus on anything for too long and become an expert. I don't know. I feel like it's just born out of interest in a lot of different things. I don't know that I deliberately tried to develop it, but I'm stuck with it.

CORALINE: How did that manifest before you got into tech?

JAMISON: I think [inaudible] a very intense obsession with hobbies that were then discarded. That's kind of how it was manifested.

CORALINE: I also had it the same way. I feel that.

JAMISON: Like what? What kind of hobbies did you do?

CORALINE: I read Cryptonomicon by Neal Stephenson and got into crypto for like a year. And I got into Egyptology really deeply for a period of some years and taught myself hierarchical effects. And then got to a point where I'm like, "Okay, I'm done." And moved on to the next thing.

JAMISON: I've conquered hieroglyphics.

CORALINE: [Chuckles] Yeah. So I also had that switching between topics, do a deep dive then move on kind of thing going on.

JAMISON: It also sort of manifests in, I would say I'm equally uncomfortable in lots of different social situations, like never super comfortable, but I can switch between groups pretty well. And that makes some things easy and some things hard. There's some tradeoffs there, but it's kind of how I am.

CORALINE: I imagine that's really valuable in your role as a manager to be able to switch and also to have broad knowledge as opposed to deep knowledge.

JAMISON: It's super valuable. Part of being an Engineering Manager is context switching, but that's the job. Have both of you been engineering managers? I feel like both of you have talked about it on the show.

CORALINE: Yeah, in my previous life.

JOHN: Yeah.

JAMISON: Okay. So you all know, like your job is to be interruptible and deal with things as they come up to some extent so that people can focus, ICs on your team can focus. And there's that kind of program or meme about 'don't interrupt me because I lose my train of thought and it takes me forever to get it back'. And that's just the job as an engineering manager. So being able to switch contexts rapidly means that you can keep up with all the stuff that's piling up on you.

CORALINE: Well Jamison, my experience has also a characteristic or a requirement for a very senior engineer as well, because maybe 50% of my job is writing code and the other 50% is helping my team level up. So I have to be interruptible and I have to be organized enough to always know where I left off and what I need to do next. But I would argue that's not just a skill for managers. That's a valuable skill for anyone as they gain seniority.

JAMISON: Yeah, that's a great point. I really like what you said about being organized enough to know where you left off too because you're pointing out that that's a skill that you can improve on. It's not just like someone tapped me on the shoulder so my day is ruined. If you're deliberate about kind of organizing your thoughts and moving onto another thing, then hopefully it's easier to pick up the context when you come back. Do you have any tools or techniques you use to do that, to keep context around so it's easier to come back to things?

CORALINE: I actually open sourced my organization system, my to-do tracking and note taking and organization system. It's called LFTM, low friction task management. It's on GitHub at CoralineAda/lftm. Lots of people are using it and they find it really valuable and I'm super happy about that. I tried everything over the course of my career from like Bullet Journal and Getting Things Done and Omnifocus and various view applications and nothing worked for me because they all required an app. So LFTM works in a tree structure that you keep open in your text editor. And as developers, we always have our text editor open so we're used to that. And you just sort of like use it throughout the day. It's not like a ceremony of like, "Oh, it's the end of the day, I better update this," or whatever. You just track in real time whatever it is you're doing, whatever you have to do next. So, you might want to check it out. It's the only thing that's ever worked for me. So, I'm happy if other people can find it useful too.

JAMISON: This is cool. I'm looking at it right now. Awesome. I'm going to view the little star button and just boost your ego in real time.

[Laughter]

JOHN: I'm sort of the opposite of that. For those situations, I just use Post-Its or whiteboards. So if I'm like leaving for the day and I want to remember where I pick up, if it's simple enough, I just write it on a Post-It and put it on the monitor so I can't lose it because I have to get through that in order to get anything else done. Or if it's more detailed like last night when I was trying to save a state before I left for the day, I had to write a whole bunch of things out on the whiteboard in order to remember all the different things in which state they were in at the end so I can jump back into it.

JAMISON: This is really interesting because I was talking about this as a thing important for management, Coraline pointed out it's important as developers get more senior, I feel like there's a rhetoric sometimes around things that are important for managers to do. And it seems like if you squint, they're all kind of the same as things that are important for very senior engineers to do. Like some amount of kind of longer term strategic vision or talking to business teams. I feel like for almost everything that's part of a manager's job, you could say, "Yeah, a really senior engineer would be able to do that well too. Does that resonate with you folks?

JOHN: Yeah, I would think so. Everything outside of like specifics of compensation and possibly performance management, but everything else it's like mentorship and organization and communication and convincing and persuasion and being persuadable and all that stuff.

CORALINE: That's why I really get disappointed sometimes when really good developers decide to move into management because I feel like they have a set of skills or the set of things that they're interested in and they don't maybe realize that those things are valuable to senior engineers as well. And I think maybe the only way they can express that interest or develop the skills is by switching over to management. But we need more developers with good communication skills, with strategic vision and with mentoring abilities. And we need that as an industry, not just on the management side.

JAMISON: Yeah. It certainly amplifies the impact of your technical contributions if you have all those skills where if you don't have them, you're a little more limited to your scope.

JOHN: Yeah, and I think that goes back to the discussion of having good ladders that split so that you can ascend in management after a certain level or you can ascend technically in a certain level. Because if there's nothing past senior that isn't management, then that's where you'll go, right? [Chuckles]

JAMISON: Yeah. The ladder is a funnel, it turns out.

[Chuckle]

JAMISON: I was reading this post. It was talking about how we have this idea of parallel tracks at a lot of companies, but one of those tracks has the ability to fire the other tracks. We talk about how they're not promotions. It's not like one is more prestigious or powerful than the other. Do you feel like that is true in practice? How do you balance the different responsibilities with this idea that they are both parallel and equal steps up a ladder?

JOHN: Yeah, I mean I think if the team is organized in such a way that the manager isn't the type of person that's wielding power because they think that's what managers do and controlling things and being in charge, then yes, then the technical discussions can be led by the technical experts and the people discussions can be for the people experts. You're not going to be doing your one-on-one with the staff engineer. But I think it's dependent on a healthy environment.

CORALINE: And really it goes beyond the team structure I think to what the company culture is. If the culture is about empowering engineers, then I think you're more likely to have a successful parallel track. And you do have to think beyond the senior. People achieve senior level a lot more quickly these days than they did when I was coming out. I feel bad for 32-year olds who are seniors and don't have a way forward.

JAMISON: Yeah. I'm 32.

[Laughter]

JAMISON: I'm stuck. Oh, no! That's an interesting point about the cost of maybe some amount of title inflation that's gone on as the industry has just expanded so much. What do you think the answer to that is? So, say you are 32, you've been bumped up to senior engineer because everyone else is 25. What do you do now?

CORALINE: To some degree, it's the companies who just want to make sure that there is a way forward. And that the responsibilities you take on as you become more senior are reflected in your title or reflected in your compensation because they're important things. But you did mention title inflation and I think that's a reality. And I think it's a dangerous reality for the reason that we're not giving people a path forward. We're not giving them a way to continue to develop as engineers and they're going to cycle out. We're going to lose their skills.

JAMISON: So you're saying without kind of a clear path of what to do next, people might get frustrated that they don't know where to go from here and it feels like their career's kind of stagnating?

CORALINE: Yeah, that's what I meant.

JAMISON: That makes sense.

JOHN: Yeah. I felt that in the past because I started calling myself a senior engineer in 2003, 2004, and then my last title bump was when I became a manager earlier this year. So it's like, that's a long time to spend at one level. Even though my skills were leveling up and I was building up all sorts of different abilities, but when you just look at that title and you see it not changed for a long time, it can be demoralizing.

JAMISON: Yeah. Titles are weird. They're real weird. So I worked at a startup early in my career and I think I was, how old was I? I was 25. I didn't know what I was doing. And they wanted me to manage a team and they said, "Hey, the title that goes with this team is Director of Engineering." I was like, "Okay, cool. I've got like five reports and I don't really know what to do with them and I'll just kind of code all day like I did before. But I guess I'm a director now." And I look back at that, I cringe so hard because that's not what a director does. It was just startup Wild West of like everyone is making things up as they go along and titles don't matter, but it still has an effect. And there's probably someone out there who looked at my LinkedIn and was like, "Oh, director. This guy really knows what he's doing." And maybe you have to go put an asterisk that says like 'fake startup director', 'not real experienced director'. But yeah, titles are odd.

CORALINE: Yeah. I was a C level at a five-person startup, which basically meant nothing. I can say, "Yeah, I got as far as C level," but I was a developer. I wasn't managing anybody.

JAMISON: Yeah. All of the titles simultaneously. [Chuckles]

CORALINE: Yeah.

JOHN: I've had that same experience with a startup. They're like, "You can pick whatever title you want." I'm like, "All right, Director of Web Applications." "Sure." And I knew I had just made it up so I'm performing as a senior developer. No one reported to me, so at least I wasn't like failing as a manager at that point.

[Laughter]

JOHN: But I knew like that wasn't a real title and it's not like the next job I get is going to be Senior Director at wherever.

JAMISON: Yeah, like, "Well, I've been a Director. Time to be a VP."

[Laughter]

CORALINE: I wonder if some of that is like a retention strategy or a hiring strategy for startups where title inflation is a way of attracting candidates. I know that a lot of companies are really bad about promoting people. And so there's this trope like if you want a promotion, you have to jump companies and they think if a company is willing to offer you a director position or or something like that, or a senior position when you're still early career, that's attractive because it feels like progress even though you're not necessarily qualified or you're not necessarily ready at that point in time for that kind of responsibility.

JAMISON: You mentioned you're not necessarily qualified. Do you feel like there's some kind of objective standard that would apply across companies that you could say this person is qualified in general to operate at this level? [Crosstalk] it's pretty vague.

CORALINE: It is very vague. I do wish that we had some kind of agreed upon standards, not necessarily formal. The way I see career advancement as an engineer is ever expanding circle of influence. So when you're early career, you're not really influencing anybody. You're developing your own skills, you're focused on personal development. By the time you get to lead, you're guiding projects, one project, maybe a couple of projects, and you're impacting the people who work on that sub-team or that project or what have you. When you get to principal, you're operating across team boundaries and maybe as you become more senior as a principal, you're influencing the broader engineering organization. And you get to architect and you're expected to spend most of your time on X-engineering and leveling people up. And those are skills that take time to develop. You can't just throw someone into that role and expect them to be successful.

JAMISON: I mean, you can though because it happens a lot.

[Laughter]

CORALINE: Yeah, you shouldn't.

JAMISON: That's an interesting point where if I am motivated purely by career growth, it's possible I could end up in a position where I'm not set up to succeed and that would be detrimental to my career. So even if I'm purely thinking of self-interest, like I just want the most titles next to my name possible, as fast as possible. If you do that and end up at a place where you're not capable of fulfilling that responsibility, it's probably going to cause some damage to you and people that you work with.

CORALINE: I wish I could just send a broad message out and say, "Pace yourselves, friends. Pace yourselves."

JAMISON: Yeah.

JOHN: Yeah. It's like you've accelerated your ability to ascend to the level of your own incompetence.

CORALINE: Yeah.

JOHN: [Crosstalk] you haven't had the time to build that competence. Like you haven't hadn't been in those situations where you get that skill.

CORALINE: And that's a terrible position to be in, right? It's not that, "Oh, you're not as good as this other person over here," or, "You don't have the same skills as this person who's been doing it for 10 years or 15 years," or what have you. It's that you're put in a position where you're not equipped to grow.

JAMISON: There's probably something tied in with Impostor Syndrome there where there's probably people who feel like that even when they are equipped to handle it. But it feels very different to be in a situation that stretches you and challenges you but that you can figure it out versus something that you're just like going to get squished by.

CORALINE: There's this notion called the zone of proximal learning. The series states a couple of things. One is that you learn best when you're given a task that you can almost complete by yourself. And parallel with that is you have to have peers who are also at your level of experience who also can necessarily complete that task on their own. And that when you work together as two people who are challenged by a task, you're more likely to be successful than you are solo. So having that peer group of people who are developing the same skills that you are and growing the same way that you are is really important too. I think that's something you don't get a lot of in startup culture too.

JOHN: Yeah, I like that emphasis on peer support. The idea about pushing yourself just slightly beyond your boundaries also appears in research into flow states where one of the reliable triggers of a flow state is you're operating like 5% to 10% beyond your current skill level. So it requires your full brain attention in order to stay on that task and not mess it up. And so, an interesting way to think about it as a sort of way of motivating those deeper states of focus is you're right at that limit of what you can do.

CORALINE: I was going to ask you, Jamison, what do you do as a manager to make sure that you are providing members of your team with those growth opportunities and with those challenges that will stretch them and help them learn and grow?

JAMISON: That's a good question. The main thing I do is try to make it safe to communicate. If you are feeling overburdened and squished or if you're feeling kind of bored, we have some team values and safety is the first one. I don't know. There's all that Google research on psychological safeties on teams. I believe you've talked about this stuff before on the podcast too. But I feel like that's the underpinning of a safe environment is an environment where you can make mistakes and learn and grow and admit things you don't know. And if it's not safe then you're going to just pull in and protect yourself, which isn't conducive to growing. So that's the first thing I do and probably the biggest one. Just make it so people understand that they can talk openly about how they're doing and try things that might or might not work. The other one is probably just kind of some amount of modeling their skill set in my head and where they are and trying to deliberately pick things that I feel like are a stretch for them. This can go well or poorly based on how good my model is, I guess, where you can sometimes pick things or guide them towards things that don't match on where they are. But if you get it right then it's really satisfying to see someone take on a task that you think they can do with some extra growth. And they maybe aren't sure they can at first, but ended up pulling off.

Another thing we do is -- so, our team is fully remote. Everybody works all over the world now actually, not just all over US. So we don't sit in an office together, but we try to create a sense of camaraderie through having this shared video conference that's open at all times. People just hop in and talk. And most of what happens there is actually ad hoc pairing. We're not an XP shop or anything where we don't have strict requirements around pairing, but we do a lot of just ad hoc pairing where everyone on the team, usually several times a week, will help someone else with the thing. And it all kind of works out where you spend some of your time pairing with someone on their thing and it evens out because someone else will pair on your thing. And I found that's very helpful for growth because it both lets more experienced people mentor very naturally where they just kind of lend their experience working on practical problems and it lets less experienced people learn more clearly from working directly with someone instead of just feedback on code reviews or things like that. An interesting thing with that is experience or inexperience isn't like a binary. It's not like one person is experienced and the other person is not. Everyone has different overlapping subsets of skills. So by everyone pairing together, everyone kind of gets the chance to mentor on some things and everyone gets the chance to learn from each other on some things.

CORALINE: I love that that creates lots of opportunities for latent learning too. I absolutely love this idea of keeping a video chat open for your team. I've done some of that. My team used to be all principals and we had someone who's like mid-career to our team. My team has a lot of autonomy and we work independently, and I was afraid that she would feel very isolated. So we actually just leave a video chat open just the two of us while we're doing our work. So even if we're not directly interacting, at least as remote people, there's another human there who can make side comments to each other. Or if she says, "Damn, what's going on here?" I can say, "Oh, can I help?" There's a lot of [this friction] when you get used to that than DM-ing someone on Slack or something along those lines.

JAMISON: Yeah, that's a great point about lowering the friction. Remote is awesome and I prefer remote to in-person work, but I have moved away from thinking remote is better in every way than being in an office. And there certainly is you lose some signal by not being around in person where, like you mentioned, those little comments people make or you can see their body language or just walk by him in the hallway. The constantly open video chat is an attempt to get a little bit of that back where it's like you want to pretend like you're in an open office for a little bit and just kind of hang out while you work can be a little bit more distracting but also a little more responsive to what's going on. And I've found that's a good trade off versus everyone just only communicating in explicit meetings or through chat. I didn't invent that idea. That was from a person I worked with named Josh Crowder. So shout out to him for starting that. It helps our team be a lot better.

JOHN: What led you to start Soft Skills Engineering podcast? How did you decide that you were the person who would give advice to develop?

JAMISON: Hubris. [Laughs] When you put it that way, it's like, I don't know. I'm a doofus. I don't know the answer to things. I had been on a podcast for quite a -- I'd helped start a podcast called JavaScript Jabber and been on there for quite awhile and that one was very technical. It was very focused on kind of we'll talk to the person who made this thing about their thing. I found that interesting, but I also felt like the specifics of technology kind of fade away to become more tools and less the point of the thing. I really, really like some tools, but I feel like the time in my life where I will get obsessed with a programming language or a framework is probably past. And I will learn new ones and use them and like them, but I'll never be like a diehard fan of some new web framework or whatever. I'll just use it because I want to get stuff done. So that interest of like I really want to know everything about everything technical coming out kind of faded. And the thing that was there, I'm thinking of like the waters receding and the land that's there underneath this. I want to talk more about how people interact and what kind of communication patterns they have, what kind of problems do they encounter, how they solve those problems. I guess I've always been fascinated by how people work together. And because I knew podcasting, podcasting felt like a venue to explore that. I was on the show with another co-host, Dave Smith, and we both kind of had similar ideas. We were thinking we wanted to try something different and just branched out and started it. We had no goals about what we wanted to do besides talk to each other about it, which made it comfortable to start because we weren't trying to like make a job or get famous. It was just, we thought it'd be interesting to talk about the subject.

CORALINE: Yeah, and that's actually not very different from the origin of this show. A bunch of us were Ruby Rogues which did tend to focus on a specific technology, and the author of a new gem or whatever like that would come on the show.

JAMISON: It's no coincidence that the same person ran Ruby Rogues and JavaScript Jabber.

CORALINE: Yeah, exactly.

JAMISON: Yeah. There's a model there.

CORALINE: Yeah. I'm much happier now and I hope that the podcasts that we do and the podcast that you do are helping people more because if I don't learn how to use a new Ruby gem, I'll read the read me, I'll read the blog post, I'll watch a conference talk on YouTube or whatever. I don't need a radio station to tell me about a gem. That's not a way that I'm going to learn anything practical. And even if I do learn something practical, that's not the optimal way to learn it. I think the lasting lessons that we get are by talking to people about, like you are saying, what are they struggling with, whether they're learning more the tools that they're using? And it comes down to those human interactions. I think human interactions are fascinating and we can learn more from those and become better developers by learning more from those than we can by learning about a new JavaScript framework.

JAMISON: I mean, I do think those shows are valuable and I think they serve an important purpose. It's just that I'm personally less interested in them than in talking to people about people things. So, that was kind of the motivation for doing something different. The idea for the format. So, the format is an advice show where people write in with questions and we answer to them every show. And that came, I think, because I'm a fan of the My Brother, My Brother and Me Podcast. It's a comedy advice podcast. They answer questions from listeners and the format felt interesting and also maybe a little bit less. It felt a little too arrogant to just sit down and say, "Now, Dave and Jamison will explain how things work." I don't know everything. I don't have in my brain this grand unified theory of soft skills. But being able to help people and talk through their problems feels like a thing that is more focused. And also I don't have to have as big of an ego to do it. I can listen to people and talk to them about what I think they should do instead of just spout forth the right way to do everything from first principles. And I don't think I would still be doing it if it wasn't for the format. It feels comfortable to do this now.

JOHN: So you've been doing this podcast for at least a couple of years now, right? And you've got two questions that are coming in every week that are coming from all over the world. At this point, you have a pretty big reach. And it seems like you have a really interesting breadth of people coming from different contexts, with probably questions that you would never think to ask. So, tell me about how that has informed what you understand working in technology to be like.

JAMISON: The biggest thing is that my experience is such a narrow keyhole view into what it's actually like for all developers to work. I've worked in the same state my whole life. I've worked mostly at small startups to not exclusively never worked in government. I'm a white male, so that has a lot of effect on my experiences and viewpoints and things. And our question askers come from everywhere, from all levels of experience, all over the US, all kinds of backgrounds. And I think one of the things I have learned from doing this show is that the developer experience is much broader than what I experienced. And before that, I think I just kind of implicitly assumed most people's careers and lives and experiences were kind of similar to mine because that's what I knew. But I think we get more questions from outside the US than inside at this point, which is great and we love it. And just in a question, I learned a lot about work culture outside of the US. We have this meme on the show that the answer to every solution is quit your job and that started kind of tongue in cheek. And we've sort of deemphasize that lately because it's born from like a very US tech industry position of privilege where if you work in Silicon Valley or some very frothy tech field, you probably can quit your job and get a new one relatively easily. But most people don't. So that's not actually good advice. If you work in like Indonesia and you're underpaid, but there's lots of things making it hard to smoothly transition to another job. I would say I have learned how small my viewpoint is and expanded it a little bit because of that.

CORALINE: I'm interested in one thing that sort of comes out of that, Jamison. I've traveled all over the world and gone to conferences all over the world. I haven't been to Asia, disclaimer. Even like RubyKaigi in Japan and other places I've been, I don't see the same emphasis on interpersonal skills at conferences outside of the US than we have here. At RailsConf this year, there were two tracks devoted to interpersonal skills and personal development.

JAMISON: Those are great. I've watched a bunch of those.

CORALINE: Yeah. I don't see the same emphasis on that outside of the US. So, I think it's really interesting that so much of a demand for discussion and insight about interpersonal skills is coming to your show from outside of the US.

JAMISON: Maybe I should do some actual counting because I'm just going by my intuition. And we don't collect info, so some of it would be inferred from if they explicitly state where they're asking from their question. But I guess my gut feel is just most of them are outside the US. Is your question how to reconcile those things where you don't see the emphasis in the conference scene, but it sounds like there's still interest in that content?

CORALINE: Yeah. And what do you do to move that forward? I think you're providing a valuable service to them, but do you think it's just a trailing demand that conference organizers haven't caught up with yet? Or is there some sort of like cultural pressure and not talk about things like that?

JAMISON: I think my first answer is I have no idea. I'm American, grew up in the United States. I've lived outside the US but not for most of my life. And this is all through the lens of like pure speculation. I wonder if some of it is, do you feel like that emphasis on soft skills and interpersonal skills was there from the beginning of the Ruby community or is it a thing that kind of grew more over time?

CORALINE: I think it grew over time. Personally for my speaking career and starting out, I felt a lot of pressure to give technical talks. I still feel some prefer to give technical talks just to maintain [straight] crowd. But most of my talks are about human factors as what I find fascinating. And I've found an increasing number of venues who are willing to make space for that here. I've seen that sometimes at conferences and other places in the world, but never with the same emphasis. So, I think that is something we've developed over time as a Ruby community here, but that is not universal Ruby. RubyKaigi in Japan doesn't do soft talks. They're all technical talks.

JAMISON: How long has RubyKaigi been around?

CORALINE: Forever. It's been here forever.

JAMISON: That kind of blows up my hypothesis I was going to propose. I guess my impression is that many tech conferences in the US or kind of the tech conference scene in the US has been around longer in general than lots of places in the world. And maybe there's this natural evolution as people participate in the community and seen for longer that they kind of got the technical stuff. And there's always more to learn, but the interest naturally shifts to be more soft skills and more interpersonal things. I feel like I've seen that a little bit, or not a little bit, quite a bit in the JavaScript community, which is the one on the tech community I'm the most active in. There's just as much excitement about a cool story as about a cool framework. But I don't think it was like that 10 years ago. And I don't know, maybe it's like as tech communities age outside of the US, that'll increase. But I guess I'm making an assumption that they're kind of generally have been around longer in the US than in other countries, and that might not be true. I don't know.

CORALINE: I'm kind of reminded of that, you probably remember about a month back, there was an individual who's based, I think, in India who posted a long thread about 10X developers. And people responded to it in a very non-empathetic way, in a very US-centric way because we had had all those conversations seven or eight years ago.

JAMISON: You say people. You can say Jamison too, because I think I dogpiled on that person. Sorry.

CORALINE: But I think what it highlights is that tech culture is not universal and that Silicon Valley is not the world. And I hope that what you said about it being an evolution is true because it's a hard one lesson that skills like these are just as important, if not more important than technical skills alone. And not to say that we figured everything out. We have a long way to go. But I think in the places where I've worked for the most part, that emphasis has been there about a balance of the skills. And brilliant assholes are less likely to be tolerated today than they were eight years ago or whatever.

JAMISON: Thank goodness. I don't know. I think the world is better for that. I guess that's the implicit belief behind the podcast is that it's worth thinking about these things and talking about them.

JOHN: Definitely. For me, it's harder to tell that there has been that progression because I came into the Ruby community six or seven years ago, right when these sort of things started ramping up. And it sort of mimicked the development of my own understanding of these issues. And so I feel like they sort of grew with each other. And so for me, I don't have that sense of from before when it wasn't like that when the conferences were purely technical. But yeah, like Coraline was saying, I certainly hope that there's an evolution there, that sort of standard in a technical culture where once it reaches a certain level, the conversation switches over to the things that we talk about every day.

JAMISON: Yeah. If you look at like a bootcamp, maybe the theme for the show should be 'Jamison talking about things he doesn't know about' because I've never been to a bootcamp. But my impression is they focus quite heavily on just the pure technical parts of it because they're coming from zero there, or not zero all the time, but usually starting at the beginning of a technical career. And I think they do have some amount of training on interviewing and some stuff like that, but it seems like there's maybe a certain technical baseline that needs to be established where you need to have that base so that your interpersonal skills have more leverage. Where if you don't have the right baseline of technical skills, being able to communicate very effectively won't matter because you won't have the technical solution to communicate effectively, if that makes sense. Does that seem reasonable?

CORALINE: Yeah, and obviously both things are important. I think there's a big difference between someone who got a degree in history, can't find a job and decides to go to a bootcamp versus someone who had a previous career and is a career switcher because the career switcher has had exposure to the importance of communication, knows how companies operate. They have these interpersonal skills that they've developed that are 100% portable and all they have to do is level up technically, as opposed to having to learn everything all at once in order to be successful at the job you just got out of bootcamp.

JAMISON: I would love to know if there are any studies about, it seems like this day would probably be pretty heavily guarded, but I would love to know some kind of studies about things that correlate with success of bootcamp grads. And if it does seem likely, I feel like I agree with you Coraline that career switchers feel like they would be more successful than fresh grads in some other field or something. But someone has to be counting all this stuff, right? Shouldn't the bootcamps be doing that?

JOHN: I would think, yeah.

JAMISON: They probably don't want to share it. [Chuckles]

JOHN: I worked at the online bootcamp Bloc for about four years as a mentor. That wasn't a full time gig but I always struggled with wanting to talk about soft skills throughout the curriculum. It was a three month program. But in three months, there's so much technical stuff to learn that there's almost never enough time to detour into things that aren't like 'is this going to get me a job next month' questions. And it makes me sad because I really think there's so many other things that could be talked about that will prepare people for getting into the new job. I'm mentoring a person right now who is out of bootcamp and just started a new job a couple of weeks ago. And so, we've been talking like intensively. We've stopped at the technical stuff for a couple of weeks because it's all about like, here's how to have a one on one with your manager and this is figure out how your deployments work and this is how you relate to other teams. And just like all this day to day developer stuff that like no one ever tells you until you're right there in it trying to absorb a million things in your first few weeks, trying to set up your development environment and learn who is in charge of restocking the coffee in the kitchen or whatever. And so, I was trying to prepare her with a lot of that information so that at least it would be less of a shock.

JAMISON: There's a lot more than code, turns out, like the theme of the show. [Chuckles]

CORALINE: So Jamison, we talked a little bit about conferences and the emphasis on interpersonal skills, the growing emphasis in interpersonal skills. And I know you're a conference organizer. As we said in your intro, you founded React Rally and you continue to organize that. Do you intentionally set out to balance technical talks with interpersonal talks or is that something you intentionally do or is that something that happens? You said the JavaScript community's coming around to that. What role do you think you, as a conference organizer, have to play in that?

JAMISON: Oh boy, I got to do some introspection now. I don't think I do that as a conference organizer in talk selection. React Rally is mostly technical talks. I would say it's technical with a side of LIMSey or [experiment]. But we haven't had very many purely communication or soft skills talks. If I think through some of the talks that stick out in my mind, one of the ones, was it last year? One of the speakers brought up a tenor, I think they played the saxophone or flute of some kind and then a bass player and went through the documentation of React and had them improvise music live on stage that reflected his impressions of what the different lifecycle hooks of React components were. And that was my gem. It's kind of weird. It's kind of different. It's not like a thing you could easily learn by reading a blog post. It's showing personality and showing the more human side of a person while still kind of delivering useful technical content. I think that's kind of the niche that React Rally is in. We're a single track conference. So some of it is the size of the amount of slots we have. But some of it I think is just -- yeah, I'm struggling to reconcile these two things now. Why don't I have more technical or more soft skills talks? I don't know. Maybe we will next year now. [Chuckles] I think the part of the goal with react Rally is focused on the experience attendees will have. And in my mind, the talks are only a part of that experience. And the feeling of the conference is from a lot more than the talks, it's from the communication that comes out from the conference about buying tickets and attending and what kind of things you're agreeing to do and not to when you come to the conference. It's around the activities that you have there. And I think you can nudge groups of people to behave differently by setting them up in the right environment. We value people making connections and friendships. And one of the ways we do that is by having really, really long breaks in the conference. For example, lunch, you don't sit in an auditorium and eat kind of box lunches or whatever. We send people out into the city and tell them kind of a list of restaurants to go to and then they just go in and make friends and chat for a couple of hours there. Or when they're in the venue during breaks, we have little icebreaker things. It's stuff to do, so you don't hopefully have to experience the awkwardness of walking up to a group of people that you don't know and saying, "Hey, how about that JavaScript program?" So, I think we're trying to create a feeling of community and openness in the experience of attending. And talks are part of that, but part of it is all of this stuff around the talks too. Does that make sense?

JOHN: Oh, certainly. It's definitely more than just -- a conferences is more than just the talks. And certainly as I've gotten more experienced with conferences, I ended up going to fewer and fewer talks, just exploiting the hallway track and really doing, like you said, using it to form connections and meet new people and build up my community rather than just cramming technical stuff into my head, which I can do by watching the videos after.

JAMISON: We're trying to formalize the hallway track, is maybe a way to put it where we're trying to make it acceptable and clear and comfortable to people that might not naturally just walk out into a group and make friends without nudges. But maybe one thing I've taken away from this is that there could be more opportunity. I think in JavaScript at least, the more general JavaScript conferences feel like they have a bit more focus on purely nontechnical talks. Where if I think of JSConf, in its various iterations, there's always several talks there that are not even related to JavaScript, it's just kind of at the JavaScript conference. But the more framework focused conferences seem to be a little bit more technical in nature. So maybe some of that is we're kind of, we have the DNA of a framework in our conference talk or in our conference. So, something I'll think about after this stuff.

JOHN: Yeah, I've certainly noticed that when looking at this conferences that I want to submit my talks to that it seems like those more framework-y conferences tend to be more technical and it kind of makes sense in that the topic is much, much smaller. And then you were talking about the difficulty of just walking up to people and starting that conversation. It definitely took me years and years and years to have the ability to do that. And I have like a couple of slots in my brain every day per conference that I can do that. And then like once [crosstalk], I do not have the energy for it.

JAMISON: You have some tokens to spend.

JOHN: Yeah.

JAMISON: I feel that very deeply. It doesn't come naturally. I'm not naturally outgoing with strangers. That's actually probably one of the biggest benefits of organizing the conferences. People come up to talk to me so I don't have to use up the introvert slots to go meet people at a conference. And it's great because I still get to make connections but I don't have to spend as much time, like overcoming that fear of what if I open my mouth and just like you shriek obscenities on accident instead of introduce myself. I don't know. Whatever weird stuff I'm afraid of.

JOHN: Speaking is great for that too is you just become someone that people have seen before and so there's that, it's just easier to approach.

JAMISON: Yeah, we talk about that at the conference too where we try to encourage speaker choice I guess is a big theme where we don't have Q & A but we let the speakers know, "Hey, if you want to talk to people and kind of talk about your talk, announce that and then go mingle in the hallway and the hallway track. If you don't, that's fine. You can just go hang out in the speaker lounge. You can go to your room or whatever." But hopefully that means that speakers that want to engage that way feel very comfortable to do so. And they can do it in a way they control instead of, I don't know. I've feelings about speaker QA on stage.

CORALINE: I refuse to do them anymore because I got the -- this is more of a statement than a question. I had one experience that was so bizarre where I was doing Q & A and this happened like with three people in a row sitting up to ask a question and somebody in the audience answered the question instead of me. That was just so bizarre.

JAMISON: I think there's more ways for it to go wrong than right. And the skillset of handling live Q & A is not necessarily the skillset we want to select for when picking speakers. There are people that could just crush it and smoothly deal with anything that comes up, but you shouldn't need to. Just speak at a conference.

JOHN: I've had luck as a speaker. If the conference has like BOF sessions, birds of a feather, or open spaces or something in like setting up my talk as a topic for one of those areas so that I can just be like, "Office hours, come talk to me more. I'm around." And just make it super approachable for people to have more of a discussion about whatever I was talking about.

JAMISON: There was one conference, I'm sure they didn't invent this idea, but one recently. I think it was React Day where they had, it was kind of birds of a feather, but they had like moderators for them. Is that common in birds of a feather sessions? Are they more ad hoc?

JOHN: I think some of the open spaces are set up that way, but I would imagine there's variation in how people think those need to run.

JAMISON: Sure. But basically they had moderators for several topics picked out and then tables and then you could say like, "I want to go talk about ReasonML. And there's a couple people that are friendly and knowledgeable about Reason that are hopefully guiding an interesting discussion instead of just like, "Hey, everybody who cares about Reason, walk over to that corner," and then see what happens. I thought that was pretty interesting. I guess a theme with conferences is that there are lots of great ideas out there and it's fun to look around and think of things that might or might not work at your events. That's one of the benefits of the proliferation of developer events is there's a lot of people thinking really hard about this and you have a lot of examples to look from and freedom to design, like pick the parts that you think are interesting and would work and not the parts that you don't.

I've really enjoyed this conversation and thinking back, a few things that stuck out to me were -- so I Googled Zone of Proximal Development. I think that's the thing Coraline was talking about, about kind of the comfortable path of learning things close but not too hard, close to your current skillset. That was very interesting to me. The discussion about career growth as a developer and the tradeoffs between title inflation and skill growth and how you manage those is also something I've been thinking about a lot. Thanks for bringing those things to my attention.

CORALINE: We've had a great time talking to you, Jamison. I think we all learned something. I really appreciated your insight as an engineering manager, as well as, as a conference organizer and as a human being. It's been really great to have you on the show. I appreciate it so much.

JAMISON: Thanks for having me.

JOHN: Yeah, it's been really great. And if you want to hear Jamison talk more, you can check out the Soft Skills Engineering Podcast.

CORALINE: Thanks everybody. We'll talk to you soon.