Developer strengths and weaknesses 🏋️‍♂️

We are back, everyone, for another JS Party, and guess who is back…?! It’s Suz! Suz, welcome back to the party.

Thank you for having me back! I missed everyone so much. It was so weird to be away for so long. We have two new panelists that have joined the circuit, and everything. I’ve been under a rock, thanks for having me back.

You bet. Speaking of new panelists, Divya is back as well. Welcome, Divya.

Good to have you. And it wouldn’t be a party without Kball over there, dancing to the music. What’s up, Kball?

Yeah, I probably have the most ridiculous rock-out every day, and now you see it, now that we do video while we’re talking. I’m just rocking out over here.

I’m a fan. I’m a huge fan.

Absolutely. You have three huge fans over here. [laughter] Today’s show is gonna be lots of fun, let’s hop right into it! We’re gonna focus on something that hopefully is helpful for everyone, and if not, at least maybe therapeutic for us, as we go inside our ids and egos and discuss – some introspection about strengths and weaknesses. We all have them both, and some things lend themselves well to software development, some things harm us. We’ll tease it apart and talk about strengths and weaknesses.

The idea for this actually came during an episode of Backstage I did with Nick Janetakis, who’s a Changelog community member, where we were just talking about development and I happened to just by happenstance state one of what I think is a strength that I have, and then I followed it up with a weakness kind of off the cuff, and I thought, wow, let’s expand this idea and let’s talk about ourselves with the panelists here, as well as people out there in the community that we admire, or that we think are great developers, and talk about their strengths and weaknesses and maybe give some props as well.

As we like to stay positive, let’s start on the plus side, which is the strengths side of the conversation, and let’s talk about what we think are characteristics or traits or skillsets - whatever it happens to be that makes people great at software development… And specifically, let’s not get too selfish - let’s start with others, before we talk about ourselves. Talk about the most amazing or admirable developers out there, and what you think makes them great. That’s the conversation… We’ll open it up, to call dibs, or grab – who wants to go first here and kick off the convo? Fair enough, I guess just like a school teacher, I’ll have to call names. Either raise your hand, or I’m gonna call your name… Suz, you didn’t raise your hand, so I’m gonna call your name. Why don’t you kick us off and talk about developer strengths?

[03:44] Sure. One thing that I really admired in other developers and tried to emulate this is somebody who’s really good at compromise and pragmatism. I think that they are really important things to have. I think that once you build up a certain amount of technical skill and you sort of have this broad – at least a broad understanding of lots of different topics, and maybe you specialize in a few, you should be able to take that knowledge, ask the right questions of people who have better knowledge than you, and then be able to arrive at a solution knowing that there’s really hardly ever a perfect solution to something; there’s always trade-offs, and things like that. It’s someone who can very swiftly make the right trade-offs, make the whole team comfortable with that decision if they’re working on a team as well, but also have enough technical chops to be able to explain the reasoning behind things, so that everyone’s on the same page.

I think that that just has a huge productivity multiplier and a psychological safety multiplier on everybody, and it’s really using your skills I guess as an experienced developer in order to just get rid of roadblocks and start making something that’s very good quality.

Is there anybody in particular that you think embodies that, or that you think about as you’re talking about this generic skill of compromise, that you would point to and say “Here’s somebody that’s really good at it”?

I do, but they’re not well-known in the industry. Does that make sense?

Sure.

You can still shout them out… If you don’t think they’d be really embarrassed by it.

Yeah, I don’t wanna put him on blast. I will say first name basis. The first job that I had in the U.S, I worked with a really extraordinary team, and one person in particular whose name was Nick was just an exceptionally talented engineer… But he would be brought into so many different conversations outside of his team every day, because he was so smart, but also just incredibly good at listening, and incredibly good at being able to provide any gotchas to think about… And also, he was happy to explain certain concepts by drawing diagrams, and things like that. You could tell that that was something that he was just really admired for at work, because there was a system that we had where you could basically give someone a bonus every single month.

You could choose one person to give that to, and they got a certificate, and you wrote the reasoning down for why they should get this bonus… And the ceremony was you would print it out and bring it to their desk and give it to them, and then they would enter the code and that would go into their paycheck.

This person, by the time I gave them one, because they’d been at the company a while – by the time I came over and gave him one, Nick would basically take the corkboard, or… What do you call it in America? I wanna call it a thumbtack or a push-pin, but I don’t know what you call them…

Yeah, both of those.

So he took that out and he had so many of them that he couldn’t get the push-pin all the way through all of them without it falling off the wall, so he had to start another pile… And I think that that shows how much everybody really valued those skills that he had, and it made me want to become that sort of person.

Love it, love it. Let’s kick it over to Kball… What have you got?

Yeah, I’ve been thinking about this… So I wanna highlight a couple skills, and I’m gonna highlight particular people. These are strengths that I don’t have, really; or I might be okay on them, but not really stands out to me.

The first one that I wanna highlight is there’s a set of people out there that really master their tools. They have their editor tuned to the finest thing, and they know how to do everything. A couple people that strike me at this - one is our own Nick Nisi. If you’ve ever seen his Vim config, it is cray-cray.

I got a new laptop and I was like “Okay, I’m gonna just steal his config”, which I did, and I have no idea what 90% of it does. There’s so much in there, and he knows every piece of it. He’s just a master.

The other is someone I worked with years ago, a gentleman by the name of Brad Fults, who also just knew his tools inside and out; it was just this incredible feel of like “This is a craftsperson.” They know what they’re working with and they have it tuned to the N-th degree. That’s something I admire and it’s something I’m not good at… But really, when you watch a master at work, it’s incredible.

[07:58] The other thing I wanna highlight is the capability of really diving deep on a problem and researching all of the ways that people have done it in the past, and kind of drawing out and synthesizing the best pieces of each of those things. There’s a person I’m thinking of in particular that I worked with on an open source project on Zurb Foundation… An engineer, front-end guy by the name Brett Mason, who I think listens to this podcast, so Brett, props to you… He is incredible at researching a topic area, looking at 10 or 30 different ways that people have solved a problem, and drawing out the best pieces of each one. I really admire that when that happens. So those are a couple of both shout-outs and strengths that I kind of wish I had, but I definitely don’t.

Those are some really good one. Thanks for sharing those.

Absolutely. Divya, how about you? Have you put some thought into this?

That’s awesome, right?

[laughs] I forgive you, I forgive you. We’ve gotta share her around, you know…

That’s awesome. I’d just like to point that the things that we’re discussing here – as I kicked it off, I talked about inherent strengths, or maybe God-given talent, or whatever that’s called, versus learned skills or things that you can acquire based on effort… And so far we’ve talked about compromise, communication, tool mastery, deep dives into history, more communication, and it’s worth pointing out, especially in our industry, we have different forms of communication that all can be mastered, right? You have audible, text-based conversation communication, you have written communication, which is a completely other, related, but different medium skill. Sponsorship… These are all things that with effort and application everybody can be great at these things, and these are things that make great developers.

So I think it’s just really cool how many aspects of what we do are things that are available to anybody with effort, in terms of “What does it take to–” You know, Kball really admires when people do dives into history; well, anybody can do that. You’ve just gotta actually do the deep dive into the history, and you have to advance your skills at reading, and those kinds of things… But I just love how approachable all these strengths are, so if they are weaknesses of yours, you can turn them into strengths by way of effort.

One thing that I would like to point out, which teeter-totters a little bit into the realm of – I don’t know if it’s personality traits, but there are aspects of what we do where some people are naturally given to them over others, and yet you can still level up your game… And one thing that I think really makes for me an admirable developer - these are people that we talk to a lot; I mean, I’m talking to a few of them right here, but on our shows - is an ability to think systematically, and to hold a system in your head. The larger the system that you can hold in your head at once and comprehend and retain the context of the system, the larger that system is to me, the more admirable and the more skilled or strong that strength is.

A couple of people that come to mind - these are just people I’ve met over the years - a lot of them are language designers. I can’t pronounce his last name - Anders Hejlsberg, who’s the inventor of TypeScript of Microsoft, as well as I think the Delphi programming language… He understands TypeScript all at once, which is incredibly difficult to do. These are complex things. Matz, with the Ruby programming language… People who can take the entire domain of an area and they can filter all of the questions, and all the ideas and the features and the bugs through… And understanding, especially when you get to application systems, is an incredibly important skill, and one where people who have that strength will do very well.

[16:12] Speaking of this panel, let’s now turn a little bit inward and let’s share some of our personal strengths. Now, I know none of us wanna be up here boasting and bragging, but I’ve asked you - don’t be too shy, because we all have our own strengths, and we’re gonna get to our weaknesses, which I think will be a fun segment for sure… But if you had to be honest and talk about yourself just a little bit, what would be your personal greatest strength(s) or things that you really see as assets in your developer career that you can share with us? Selflessness I guess is the first one that we all have, because nobody wants to take the spotlight… [laughter] Okay, I’m gonna be that school teacher, I’m gonna start calling on people. Let’s start with Kball this time.

Okay. Let’s see, greatest strengths as a developer… There are two things that come to mind. One of those is kind of in this communication domain; one of the best definitions I heard for the responsibilities of a tech lead or somebody who’s really more advanced as a developer, and something that resonates strongly, because it’s an area that I’ve invested a lot in and I feel like I have a strength in, is being able to translate business and product requirements and desires into technical requirements in architecture. Performing the translation step between “We have this problem” or “We have this thing we’re trying to accomplish”, or even just “Here’s the product or business outcome we want”, and say “Okay, here’s an architecture that we could build that would accomplish that, here’s how we can break that down into steps and actually task that out into software things that we can do.” That’s something that I’ve come to realize is actually quite hard, but is something that for whatever reason I’ve always been pretty good at.

The other one that I think comes up is just I’m stubborn.

Hm, you stole mine!

I know, right? Well, it’s a thing, because I used to always be the one who – like, if there was a bug you couldn’t solve, eventually it would come to me, and if took me two weeks of banging my head against it, and I would try this, and try that, and try that, but eventually I would get that damn bug. That has served me very well, because that process also teaches you a lot. So having this strength of stubbornness, or like “I’m just gonna keep going until I figure this darn thing out”, then helps with many other areas of learning.

100%. Alright, Divya, let’s kick it back to you.

Very good. Suz?

I think what’s already been said I’ve resonated a lot with. I think that I have this stubbornness that Kball talked about. I usually just call it grit. Grit has had a lot of studies on it, and it’s been shown to predict someone’s success at general things in life, which is kind of cool. And then everything that Divya said just resonated with me. The disadvantage to going third is that sometimes people will say the things that you were gonna say, but in a nice way, it reminds you that you do have different skills that you might – you know, when somebody says a skill and it resonates with you, you probably realize you have that skill, so that’s very humbling and nice to think about.

We all have lots of different skills, but if I was gonna pick one that hasn’t been mentioned yet, over the last two years I’ve gotten really good at ramping up on new technical topics very quickly… And part of that for me has been a necessity of the job. When I took on a role in developer relations for Azure, when you think about Azure, it’s a whole collection of cloud services, and it is a lot of them. I’ve been thrown into situations where I’ve had to ramp up on a specific Azure technology, or a technical concept that I wasn’t well-versed in very quickly…

So over the last two years, because of that and because of how I sometimes stumble into things when I’m live-streaming my code, where I don’t know what I’m doing and I have to take a breath and read some documents and do that under pressure, while 200 people are watching me - I’ve definitely seen those two things, like being thrown into the deep end at my job, and also having to make mistakes and stumble in front of people on my live-stream… Those have made me very good at just being able to stay focused and learn something new, learn the most important parts, but then also try to get as deeply into that topic as possible for actually being able to understand it… And then that dovetails nicely into me being able to teach that to somebody else as well. So I think that’s a really nice skill to have.

You just feel so much less anxious in this industry when you’re trying to keep up on top of everything, if you’ve sort of gotten to a point where you can ramp up very quickly.

Well, if you think going third is hard, try going fourth sometime… Nah, just kidding. Because basically Kball stole mine, as I said, and I think we’re seeing a theme here with regard to one particular strength, which is - maybe you can call it grit, maybe you can call it stubbornness… The word that I tend to think of, which I think “grit” is actually a better one, so I’m gonna switch to that… But I’ve used the word “intrepid”, which is fearlessness or adventurousness. It’s kind of the idea that you don’t actually know what you’re getting yourself into, and that is kind of the “Ignorance is bliss” certain situation… But this is actually the skill I was referring to on that episode of Backstage, which is if there’s a challenge that’s been placed on my desk, I’m just going to figure it out somehow. I know that, the confidence to do that – maybe it’s gonna take ten minutes, and I’ll feel good, maybe it’s gonna take three days and I’ll hate myself… But eventually I’m going to get there, and I have confidence that that’s the case, so that allows me to take on tasks that might otherwise scare me off. It has been a huge strength for me. So that one I’ll just iterate it for the third time, I suppose.

[24:14] The other thing that I used to say, which is kind of a joke but it’s true - I tell people that my greatest strength as a developer is fear of irrelevance. The reason I say that is because industry moves so fast, and I’ve always had this feeling of “In six months I’m gonna be useless.” And maybe that wasn’t always true; so far it has proven not to be true. Maybe it’s a self-fulfilling prophecy… Because that fear of becoming irrelevant very quickly has led me to always stay up to date, and even ahead of a lot of people in terms of techniques and trends, and I think it’s probably at a meta-level led me to be where I am with Changelog, because of that fear… So it’s kind of turning a weakness into a strength in that regard.

I’ll say one more real quick before I wrap up, which is gonna sound super-simple, it just really is; it’s just easy to say and hard to do… And it’s not just for developers, but it’s for career and industry in general. Here’s what it is - when I say I’m going to do something, I do it.

In the chat they’re talking about soft skills as table stakes… I think table stakes is when you say you’re gonna do something, you should do it. So I hold myself to that standard. Now, do I always achieve that standard? No, of course not. I fail all the time. But my goal is when my word goes out, then I follow up with my word, and that has been a huge asset to me over time… Because unfortunately there’s a lot of people that say they’re gonna do things and then they don’t do them. And if you can be the person who says you’re gonna do something and then you follow up and you do it, on a reliable, consistent basis, well that’s a very, very valuable thing in industry, and it’s proven to be one of the reasons I think I’ve had the success that I have, in both as a developer and just as a businessperson in general - it’s because if I say I’m gonna do something, then I do it. It’s a simple equation, but it pays dividends.

I like that. It’s really simple, but very powerful.

And again, it’s something that we all can do. There are times where, of course, there’s extenuating circumstances - you totally forgot, you feel terrible… But nine times out of ten if you can just stick to that word and do that over a course of years, I believe that you will be successful in business, because it’s an incredibly, incredibly valuable thing… And like you said, Suz, it’s pretty simple; you’ve just gotta actually go do it.

Well, enough boasting about ourselves… Let’s get real, and let’s talk about things that are holding us back. Our greatest weaknesses - we all have them, we all know them very well, I’m sure, and we’re now going to focus on the for a while and share that. I’ll go first, and I’ll say that one great weakness that I have, and that is a thing I admire in other people - and I haven’t been able to change it, unfortunately, over the years - is that I do not think in libraries very well. I don’t think in general use software. I think in very specific software, and I do think in abstractions, but they’re always tiny, little abstractions that I can reuse, and they’re never general purpose abstractions that everybody can use… Which is more useful software. If I write a thing for my thing, and I can pull it out and it can be used by 100,000 other people, that was very valuable software. I’m sure there’s times that I can do that, but either it just never crosses my mind, or I think “Oh, it’s just too much work, I’m not gonna do it…”, or I feel like I’m not very good at API design for anybody but myself, which is probably true as well… I’m very good at designing things for me, but not for other people.

Whatever it is, I stop short… And I see so many people and companies have a product, and then they pull portions out of the product and they give them to the world, and the world benefits… And I love that. It’s the beauty of open source… And yet I’m not good at doing it, and I haven’t been able to get good at doing it so far. But sometimes with a weakness just recognizing it is the first step, so maybe I can start to get better at that, but it’s definitely a weakness of mine. I don’t think in generic library abstractions, so I think my software suffers as a result.

Alright, let’s go over to Kball. Weaknesses…

Alright, so one weakness that stands out to me is I’m actually pretty darn bad at getting way down in the nitty-gritty on stuff. I’m really good at getting software from 0 to 80%, and there are some developers who are really good at polishing everything and getting everything fully tested, and they know all the latest language techniques, and whatever… I’ bad at that.

It’s extremely common that I’ll work with somebody and they’ll be way more junior, and they’re like “You know there’s a better way to do this…”, or they’ll be picking up the pieces down there.

It goes to something we’ll talk about later in terms of partnering with people, because I think there are people who are really good at that, and I like to work with them… Because I don’t have the level of deep dive detail-orientation that some amazing developers do.

That’s a good segue for mine, actually. I’m a very detail-oriented person…

[whispers] We should work together…!

We should, we should! But I have these two weaknesses that really let me down in order to take advantage of that… The first one is that I type slower than I think, so I’ve been really trying to improve my typing speed over the last – I would say I started seriously about six weeks ago, and I’ve been practicing every day, and I’m trying to change my typing style, and things like that… And it’s because I actually have a very bad short-term memory. So I’m super-excited about details, my brain is already sort of collecting all of them, but it cannot retain them; and if I can’t type fast enough to get them out into Vim, or onto the documentation that I’m writing, I lose it…

If you watch my stream – I mean, part of this is because I’m on the spot, in front of a bunch of people, and I’m talking aloud, so my concentration is a little off… But even off-stream I do this - you’ll see that if I have several Vim buffers open and I have several files open in my IDE (that’s the equivalent), I’ll basically be in one file and I’ll write a new variable or a new function name, and then I’ll jump over to the other file to use that function, and I will totally forget what I just called that variable name. So that’s how bad my short-term memory is.

I have a very good long-term memory… Again, I tweeted this week that I remembered something from the Dewey Decimal System 14 years later… [laughter] I have a really great detail-oriented long-term memory, but when I know that I only need something for 30 seconds to a minute, I really struggle in that short-term space… So I’ve been working on my typing to get faster, and then I’ve also been looking into how I can actually improve my memory, because it’s just something you can work on, even if you’re predispositioned to be bad at it.

[32:11] That’s a very interesting one. Divya, how about yourself?

“What am I working on again…?”

It’s gone. The day is gone…

I love this. I’m thinking of all these other weaknesses I have as everyone’s talking; I feel like I could go on forever. I’ll add one more and then we’ll move on, because we have some good stuff coming up on ways of working around teaming up, improving yourself etc.

I don’t ever take notes. It’s just the dumbest thing ever. Even when I find answers to solutions, I’ll just remember what I googled to find it, and I’ll just google it again the next time. And I’m 36 years old at this point; you’d think by now I would have learned that you should write down things once in a while… And it’s a weakness of mine; I just don’t take notes. And it bites me on a daily basis. That’s just me.

Blog posts.

Writing a blog. I still find myself – I’ll google stuff that I’m like “I know I solved this at some point”, and I’ll google for it and it’s on my blog from a year ago, or two years ago, or whatever.

But talk about a yak shaving - you set out to solve a problem and now you’re writing a blog post, you know? That’s where I’m like “Ain’t nobody have time for that…”

[35:50] Yeah, yeah. But when you do that thing - I do my notes in my Drafts folder, because my blog is a Jekyll site, so I’ve got a Drafts folder… And I’m already in my terminal, I’ve figured this thing out; copy/paste, dump it in my Drafts folder. Many of them I probably won’t get to. I have a very large Drafts folder.

It sounds like a strength of yours, and definitely a weakness of mine, because I’m with Divya; I would take 20 minutes to figure out the answer and four hours blogging about it… So that’s a good idea, just to take notes as blog post drafts. Hm… There’s a life hack for you.

So we’ve talked about some strengths and weaknesses… Strengths are strengths; you’ve got them, you hold on to them, don’t lose them, but weaknesses is where we can really improve, right? So if we focus in on weaknesses and ask about how we can actually get better, I liked Kball had some good advice for one particular weakness that I guess Divya and I have, in the last segment… But what are some strategies and techniques that we and the listeners and the community can use to improve the weaknesses that we have? What are some ways that you can suggest, or maybe you improved yourself in the past somehow? Opening that up for conversation…

Before I do, I actually wanna challenge the premise for a second, and say that contains the assumption that really we should work on our weaknesses. I’m not 100% sure that’s true. It may actually be more valuable to double down on improving our strengths, and then find ways to compensate for our weaknesses. For example, it’s really easy to find developers to work with who are detail-oriented. One of my big weaknesses is that lower level of detail orientation, but it comes with – some of my strengths are things that other developers may have challenges with… So I’ve actually found it more productive for me to find folks to partner with than to work on that weakness. Plus, working on your weaknesses sucks.

That is a good way to – I guess you would call it a strategy, in terms of finding people who are good at the things you’re bad at. Absolutely. And it goes back to what I didn’t say out loud, but I did write down - how do you route around your weaknesses, or improve them over time? So I guess it opens up both questions, and routing around is a great strategy. There are things that I think if you are bad at them, whether it feels shitty or not, you should get better at them and you’ll be overall better at what you do. So assuming that we do wanna improve our weaknesses, or maybe just find that detail-oriented person and hope they wanna work with you… I don’t know. Suz, you were gonna go first here, but Kball rudely cut you off after 30 seconds of silence, so… Hop in there, Suz, before Kball takes the stage again.

No, I’m so glad that Kball said all that, because that actually is very relevant to what I was gonna say. I think that using your strengths to help attack your weaknesses is a really good thing. For example, I’m really good at learning new things and ramping up on them, and that usually makes me excited. I’m very excited and don’t feel threatened about learning new things, which is not something that I’ve always had in my career, but I do now… So if it’s something such as the drudgery of learning how to type faster, I’m going to essentially create a framework for myself to succeed first. I’m gonna set goals and say “I’m gonna practice for half an hour a day, and then I’m gonna observe how I improved.” Then if I hit this certain goal, then I’m also gonna do this nice thing to reward myself.

[40:03] So I usually set myself up with a framework. That’s what makes you excited. If something’s drudgery, then you have to introduce other things to make it exciting. And then knowing that I’m pretty good at picking new stuff up, I’m pretty good at being disciplined to do it as well - I try to take advantage of those strengths in order to work on my weaknesses, if that makes sense.

So for me, I have been dedicating X amount of time a day to practicing my typing, and then I’ve been dedicating half an hour a day to reading about a new topic that I think would be good for me to know, and then that way I’m also improving things like “Oh, I have this weakness about this one topic, so I’m gonna learn about it.” If you could just find something that is exciting about the weakness that you’re trying to work on, even if you’re just giving yourself a cheap reward, like “I’m gonna go buy a donut if I achieve this”, then that’s usually a recipe for success, at least as far as I’m concerned.

So yeah, that’s what I’m working on right now - creating a disciplined environment where I’m excited about the idea of actually improving as a person, and improving as a developer, and that’s enough for me.

I love that, I love that. Use your strengths to improve your weaknesses. That’s a great tip. Some of these are subjective – or not subjective, but case-by-case. So depending on the weakness, the strategy in order to improve it would be different. One of the things that we talked about that we all admire in a great developer is communication skills, and we talked about those different kinds of communication skills. Well, there’s a lot of people - and I mean, hey, there are people who are naturally gifted communicators; most of us aren’t, right? So a lot of this is learned, very much so. What are some tips that you all have - you guys are great communicators, I’ll just go ahead and say it - that got you where you are today? What are some ways that people who aren’t great communicators can go about improving that skill, because it crosses the chasm industry/personal life/software development especially - you have to be able to communicate well to be effective. So if you aren’t a great communicator, what are some things you can do?

I’m a huge advocate of Toastmasters. For those who are not familiar, Toastmasters is a chapter-based non-profit organization that is focused on helping people develop communication and leadership skills. Basically, it’s a set of small clubs - and if you google for a Toastmasters in your neighborhood, or your location if you’re in a city, you’ll probably see dozens nearby… And it’s literally practice; it’s just a controlled, safe environment for practicing speaking. And they have both a set of curriculum to practice prepared talks and prepared speeches, but they’ve also got stuff for working on your impromptu speaking skills, they have stuff for working on your feedback skills… There’s a whole slew of things around it. I was a member of a Toastmasters club for about six years; I saw people coming in where the first time they decided to stand up in front of people and try to speak, they couldn’t. They turned red and they just could not get a single word out. Going through to the point where they could get up in front of people and give a prepared speech for 5-7 minutes, and just do it.

It’s got a bunch of different stuff in it. There’s lots of different ways. Because it’s chapter-based, your experience is gonna vary a lot by clubs, so if you’re interested in doing it, check out several clubs in your neighborhood to see which one feels good to you, and feels supportive, and feels like a good environment that you wanna be in. But if you wanna work on your spoken communication skills, it is an incredible resource… And you can go as a guest as many times as you want, and a membership is like $40/year or something; it’s super-affordable. And if that’s a hardship, a lot of times they’ll have sponsorships available.

[43:47] We had a guy come in who was literally homeless, and he was attending our club, and he was amazing. He was homeless, a product of the foster system, he had all sorts of challenges, and over the course of working with this Toastmasters club for about a year and a half, his communication skills improved dramatically. He got a job, he got all sorts of other stuff out of being able to be in an environment where he could just practice “How do I interact with other people?” on a regular basis. Yeah, I highly, highly recommend it.

That’s great advice. I had never even considered that, and I’ve heard of other people who’ve had success in Toastmasters. So I didn’t even think of it, but that’s a great way especially for getting ramped up, without all the pressure live on stage with hundreds of people staring at you.

Divya, do you have any advice on communication skills?

Yeah. That takes practice, for sure.

Yeah. That’s very insightful.

[47:43] I’ll say one more tip while we’re talking about communication - this is specifically around written communication… There’s nothing wrong with emulation until you can find your own voice. So if you feel like you are bad - or maybe you ARE bad, and so you appropriate feel like you are bad at writing down your thoughts and having somebody else read them and interpret them the way that you wanted them to, have the desired output… If you are bad at that or you wish you could be better, there’s nothing wrong with just finding people who are good at that. And it’s very easy - if you read, you will find people who you read and you’re like “I like their writing. I like to read this writing.” And you just emulate them.

Don’t plagiarize, obviously, but think about what it is about the way that this person writes that is compelling or effective in your eyes, and then you just start to adopt those patterns and principles in your own writing, and eventually you will find your own voice through that. You can work your way until you get the skills up, and you will then shed those and find your own voice… But in the meantime, there’s nothing wrong with finding good examples and emulating them. That’s one tactic for improving your communication pretty quickly through simple emulation.

I totally agree with that.

And the fact is that we can disagree and be okay with each other. If you disagree, you’re on the other side of whatever the topic is, and we’re very divided because of that; and it’s like, “We can disagree and still get along.” That’s part of life, and a valuable part of life is engaged disagreement.

I do have one more topic I wanna get into in terms of the advice, specifically around the empathy side. Speaking of empathy, Suz, Divya talked about a great skill is empathy, aka caring about others, and the user experience, and the person who’s using your software… So what if you’re really bad at that? Do you have any advice on ways that you can get – because that’s hard to improve, I think… But do you have any advice on that?

Yeah. For me, the most powerful thing that helps people who are really struggling with it is you’re just never gonna be able to get outside of your own experience or your head, unless you actually go out and either observe people having the problems that you’re having trouble empathizing with, or just asking people questions about it. And I’ve seen this a lot.

I led an accessibility effort at a job once, and I just couldn’t get people to consider experiences outside of their own. Obviously, there’s a lot of work that is required in order to learn accessibility topics if you don’t know them, and so obviously there’s pushback because of that reason, to… And what we ended up doing was we brought someone in to the company and they used that website, and they used the tools that they needed to use the website, and that was the fundamental turning point for people. They just needed to see it, they needed to feel someone using something that they made personally; so if your code is the piece of code that’s responsible for a bad experience and you visually, viscerally, cringe-worthy feel it, having people cringe like that, that’s when you realize.

[52:14] Unfortunately, sometimes people only empathize once they’ve been through it or once they’ve had a relative or someone they care about that goes through it. That’s just not good enough. It’s not something you can rely on, and it’s kind of not really that nice to wait until it actually affects you. You really have to make that effort to go out there and watch people struggle to use the things… Or be thrown in the deep end and have someone explain something really badly to you and you feel that frustration, which makes you wanna be better at explaining things to junior developers or people who are new to a topic that you’re really good at.

You really should try and at least try to be a little bit uncomfortable at times in order to really be able to bridge that gap that you’re struggling with.

I love that.

Yeah. Within the context of developers, I cannot recommend highly enough watching somebody who has never used your code use your code. On the web, it’s really easy; go to a freakin’ store or cafe, have your laptop, have your website open, go to a random person and say “Can I ask you to play around with this a little bit?” It is striking how many people will say yes, and you watch them and your mind will be blown… Because people do not use your tools the way that you use your tools. And it may be more difficult if you’re using something that’s less consumer-focused, or whatever, but sit in on a design user study, or whatever; people do not see your software the way you do… And it’s incredibly humbling, because no matter how good of a job you’ve done, they will get confused about something, especially if you haven’t been already doing this a lot, and a lot of times they’ll get confused about everything, and they will have no idea what’s going on with your software. It’s a mind-opening and stretching experience, and very painful, but worth doing.

I love that advice. Well, let’s turn that advice inward a little bit as we wrap up. We have no idea what you all think of our podcasts unless we “listen to you listen to them?” - no we can’t do that. But what we can do is solicit your feedback. Let us know what you think of our shows, and specifically this show. Every show now on Changelog.com does have its own discussion page, where you can talk to the panelists, you can share your strengths and weaknesses, you can share the show’s strengths and weaknesses, tell us what we’re doing well, tell us what we really could improve at… We’d love to hear from you; we want this to be a show for and by the community of JavaScript and web people, and so that’s what we’re striving for, and you can help us by letting us know what you think.

So that’s our show today. Divya, Kball, any final words before we call it a show?

Know yourself. We’ve just done a bunch of introspection here, but I think it is really important to pay attention to this in yourself. And I think one thing we didn’t really talk about here, but it kind of came up tangentially, is know what gets you excited. Because whether or not something is your strength or your weakness, you’re gonna be able to learn and power through and do whatever by getting excited about it.

Suz talked about being really excited about learning - I have the same thing. I could do something that is the most boring, detail-oriented, right-in-my-weaknesses, all these other things… If it’s new to me and I’m learning something through it, it’ll be fun. Because that’s what gets me excited. That’s not what gets everybody excited. Know yourself, know how you react to these things, and use that to help guide your investment in your strengths and weaknesses.

Love it, love it. Know yourself. Very good. Well, thanks, you two; thanks to Suz, who is now on her way to the airport. Thanks for listening, that’s our show this week. We’ll see you all next time.