Latest / The Not-Boring Tech Writer / Bridging the gap from “not technical enough” to “technical” with Janine Chan
Transcript
- Kate Mueller: [00:00:05] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills and foster our distinctly not-boring tech writing community. Hi, I'm Kate Mueller. In today's episode, I talk with Janine Chan, a senior technical writer and a Write the Docs community moderator. We talk about that feeling of not being technical enough and ways to level up your technical skills so you can flip the narrative to, 'I'm a technical writer who just hasn't learned how to do this yet'. Hello my not-boring tech writers. I am so excited this week to be joined by a writer that I met kind of by happenstance. I gave a talk at one of the virtual Write the Docs Portlands a few years ago on Beating the Virginia Blues, and this woman happened to be my moderator for that session and ended up being amazing. She handled the other person who was doing Q and As audio networking with total aplomb. I can say she is both great under pressure and also not boring and a delightful human to boot. So I would like to welcome to the pod Janine Chan. Janine, welcome. Janine Chan: [00:01:20] Hi, Kate. Thank you so much for such a kind intro. Oh man, all those AV issues. I guess I must have blocked them out. Kate Mueller: [00:01:27] You've repressed them. It's fine. Janine Chan: [00:01:29] Yeah, that's exactly what happens. And what a great talk it was. To be introduced to you by virtue of amazing athletic feats and also technical writing. Who could ask for more? Kate Mueller: [00:01:42] There are two areas that have way more overlap than the average person probably thinks, because the number of people who messaged me after who were like, I've been a thru-hiker, or I'm thinking about being a thru-hiker, or I just really loved your talk. Apparently the Venn diagram of not-boring tech writers, and also people who enjoy doing outside things is pretty strong. There's a huge overlap there. Janine Chan: [00:02:05] I love it. I love hiking, but I do love showering and getting in my own bed that night. So different sense of scale there. Kate Mueller: [00:02:16] I will say, I never got used to not showering. Ever. Janine Chan: [00:02:20] I always wonder, and it's a weird question, but I always wonder. Kate Mueller: [00:02:24] Yeah, I never got used to that, ever. It is, for me, one of my favorite things about not thru-hiking is getting to shower on a daily basis if I want. However often I want, there's hot water there. It's great. I can be clean. It's awesome. Janine Chan: [00:02:39] Indoor plumbing, what a gorgeous thing. Kate Mueller: [00:02:41] One of the best things in modern civilization. Janine Chan: [00:02:42] Welcome to the Indoor Plumbing Fan Podcast. Kate Mueller: [00:02:45] Forget tech writing, we're just going to talk about the wonders of indoor plumbing for the day because it's pretty darn great. Janine Chan: [00:02:51] It's pretty great. Kate Mueller: [00:02:52] Janine, you are a moderator of the Write the Docs slack community among other things. So you are deeply involved in a portion of the tech writing community. Can you tell us a bit about, I call it, your tech writer villain origin story? How did you get into the field of tech writing in the first place? Janine Chan: [00:03:12] I love it. It makes it sound so much more interesting than it could have otherwise. You know what? Tech writing is one of those careers that nobody knows about when they're young. I feel like nobody is really, oh, I wanted to be a tech writer ever since I was a kid. I would like to meet that kid. It would be fascinating to spend time with them. Everybody I know fell into it. For me, I was doing an English degree because that's what I enjoyed. I had no idea what I wanted to do with it. I had strangers telling me to marry rich. Kate Mueller: [00:03:47] Did you get the 'marry rich or go into teaching'? I feel like those are the two paths people tell English majors to pick. Janine Chan: [00:03:54] Yeah, or sometimes they'd be like, do you want to go into law? And I went, no thank you. No, I couldn't, I could never. I'd make a terrible lawyer. I was just doing it because I enjoyed it. Then one day I was at my boyfriend at the time's parents’ place, and I think his dad was trying to just make conversation over dinner. He said, what do you want to do? I said, I have no idea. He said, well I'm a technical writer. I went, boring! Because I didn't know what that was. So internally I went, yeah whatever. Whatever, Philip. Okay, good for you. Then it kind of planted a seed in my brain. The more he talked about it, the more I went, well I could do that. I'm a total nerd about formatting. I spent an embarrassing number of hours as a child in Microsoft Word trying to get the fonts right and stuff. Because when I'm not outside hiking, I'm doing that stuff. In many ways, I was that weird kid I was joking about meeting. Kate Mueller: [00:05:00] The weird kid without the job title to aspire to. You were just doing it without knowing it. Janine Chan: [00:05:05] Aren't we all just weird kids with job titles now? Kate Mueller: [00:05:10] Forget not-boring tech writer, this is the Weird Kids with Job Titles podcast. Janine Chan: [00:05:16] Every podcast is that, really. So yeah, I bounced around after I graduated for a little while. I landed a junior tech writing role, which really feels like finding a unicorn in a desert. It was really great to get a foot in the door like that and I've been tech writing ever since. That was about 7 or 8 years ago now. Kate Mueller: [00:05:38] So you were a junior tech writer? I'm assuming you worked with more senior technical writers in that first role? So lovely. Janine Chan: [00:05:48] I know, that's my favorite thing about getting to work on a team of tech writers. You just get so inspired. You get to pick people's brains all the time. It's the best. Write the Docs has been similar. I've been involved with them in some capacity since 2020, and they're just marvelous people, and you get to meet marvelous people like you. So it's just been a really great experience, too. Kate Mueller: [00:06:12] Oh, it's a fantastic community. I think just generally very welcoming, very inclusive, very supportive. A lot of really smart, really experienced folks who are actually very comfortable sharing that experience, but not in a condescending sort of 'how do you not know this' way, which I appreciate. So how long ago was that for you, that junior tech writer role? The very first one. Janine Chan: [00:06:39] That would have been 7 or 8 years. Post-pandemic time means absolutely nothing to me. Kate Mueller: [00:06:46] It's been three decades since 2020. I don't know what you're talking about. Janine Chan: [00:06:50] It's also been like 45 minutes. Kate Mueller: [00:06:52] So it was pre-pandemic anyway, in the 'before' times when time actually made sense and worked in a way that you expected. Janine Chan: [00:07:02] And I worked in an office. Kate Mueller: [00:07:03] Oh my goodness, what a novel idea. So what are you doing now? You started as a junior tech writer, it sounds like you've had a couple roles since then. Where are you at in your tech writing journey now? Janine Chan: [00:07:18] I just a couple of months ago left startup land and I'm at Datadog now, which is a big change in scale. It went from my last company being about 250 people, and I was 'the' tech writer, to a team of I think it's 18 now and a company of over 6000 people. So I'm still getting used to the sense of scale. Kate Mueller: [00:07:42] That is a tremendous change. I've only done tech writing in the startup space. So that, to me, is an unimaginably large, both organization, but also tech writing team. A team of 18, and they're all tech writers? Janine Chan: [00:07:57] Yeah, and they are all incredibly impressive people with incredibly impressive backgrounds. It's just like Write the Docs where it can be both intimidating and inspiring to be around so many brilliant people all at once who all, kind of vaguely, do what you do, but you all bring something different to the table. What I was thinking about in prepping for today, was how you can manage those feelings and focus on building up what you can bring to the table, even if it might not exactly be like all the super cool X developers on my team who can program their way into some really cool solutions. I can maybe program my way out of a wet paper bag. Kate Mueller: [00:08:43] I mean, that also describes my programming abilities. So I'm right there with you. It is encouraging to me to know that there are other people who are comfortable using the title of tech writer who are similarly 'programming challenged', shall we say. Janine Chan: [00:09:00] Yeah, because there's no such thing as, you get technical enough for the title. It's not like an amusement park where you must be this technical to have the job title. It's not like you're crossing a bridge and there's a troll being like, 'program your program solutions to my questions three'. It doesn't work like that. One day you get hired and you're a technical writer now, but it can be mentally, you can have weird blocks around what you do and don't know how to do. Kate Mueller: [00:09:37] Yes, that's totally true. I would say, for me, very true in my own experience. I've written technical documentation in some way, shape or form for probably 15 years, but very rarely has my job title actually reflected that reality. It's very often that I've been somewhere in the support realm, or a trainer or a product person, and I was just writing documentation on the side. So for me, I definitely have pretty strong feelings of feeling like I'm not technical enough to do my job, but I'm totally technical enough to do my job. Janine Chan: [00:10:15] I was listening to your first episode of the reboot of the podcast, and when you were talking about all the things you've done I went, Kate is so impressive! Kate Mueller: [00:10:27] No, I'm not really, but thank you. I sound great on paper, or I guess on the pod. I sound great on the pod, but in real life there's this aching, I don't know enough. There's no way I possibly know enough. I think for me some of that is-I also have two degrees in English. Then I went back to school for school for information management, but it was very much on the database side, which is not a lot of programming. I did a little bit of programming with that, but I would not ever call myself a programmer or a developer. There is, for me, just this constant, I feel like I don't know enough here. Even though, if I take a step back, I can see I've taught myself a whole bunch of stuff. I didn't take a class, I wasn't certified or anything like that, but there's a lot of stuff that I've learned over the course of doing my job or sponged up from the engineers or developers that I worked with or something like that. I guess maybe that's a great lead-in to a lot of what we were hoping to talk about today, which is coming from that non-technical background and trying to teach yourself technical skills. What does that look like, how do you do that? Because I feel like you are someone who's made that leap and is a lot more comfortable calling yourself a tech writer than I've ever been. So I would like to learn from your 'oh great and powerful' wisdom, Janine, so that I can get rid of some of my imposter syndrome. So how do I do it? Janine Chan: [00:12:03] You know what? The main difference between us might just be hubris on my part. Kate Mueller: [00:12:11] Or perpetually low self-esteem on my part. I mean, let's put that into context. Janine Chan: [00:12:16] I think it's so common, because I don't think that if we do have a platonic ideal of technical writer in our heads, I think it can be so easy to be like, this person just knows everything. It's immediately setting ourselves a mental trap, because I don't think any of us really feel like we're done learning. It's what draws us into the profession. We're not done learning, we're not done gaining those skills. Then we don't meet this ideal of a writer. So most of us, we don't meet our own ideas for what is technical enough to really earn the job title. But that criteria for what makes a technical writer is often really arbitrary. Kate Mueller: [00:13:02] Incredibly so. I don't know that I could sit here and tell you why I think I'm not technical enough. Because if there was a particular set of skills or a particular tool, that if I just went and learned it and I could check off a box and be like, now I'm a tech writer. Like, 'now I'm a real boy'. There is no clear milestone there to say, you've unlocked 'real' tech writer. I think that's where the trap that a lot of us fall into is, I have this amorphous idea of what being a tech writer is, and all I can feel is that I'm not that idea. There isn't a set list that if I check off all the all the items in this, I'm comfortable using that title. Other people have called me that for years, but I may not be as comfortable using it myself. So how do you start tackling that? Particularly back when you were first getting into tech writing, you took that junior tech writing role. How did you approach that? Because I'm sure that you had some feelings of, I'm not totally comfortable with this because I've never done it before. But that's totally normal when you take a job in a new field. Janine Chan: [00:14:17] Oh my gosh, yes. I still deal with it. I found that every time I get a new job, I go, did somebody make a mistake? Did the right person just forget to apply or something? It's so easy to second guess yourself. I think back then, I was so happy to just have the job title, period. To be in the field, to have a foot in the door. Ignorance really was bliss because at that point I had no idea that it was something that X engineers got into, or X developers. I almost went, I have an English degree and now I'm a writer. What a natural progression. At that point it was really easy for me to go, yeah that's me now. Technical. I'm writing an HTML. That's the technical part, that's the only technical part. I found over time that, as I learned more about the field, as I joined Write the Docs, which I described as finding the nerdy summer camp that I didn't have as a child, and finding that there were so many incredibly impressive people in there. Me going, I'm in there with them, and realizing that it was a way bigger field than I knew when I joined. I started to think about it in terms of always learning. It's exactly what you were talking about, where you've been able to teach yourself everything that you needed to know in order to keep progressing in your projects, in your career. I actually think that's way more important than the formal training that you can get in tech writing. Like we were saying, there's no real formal training. I think there are starting to be programs for tech writing in post-secondary institutions. The tech writing course that I took in order to just have it on my resume and be like, look not a total phony. Those courses don't always prepare you for what the job is going to be. I learned paper editing markings. I don't even remember what they're called, but you know how you do the little swish to say 'remove this' and it's a little loop you draw on the paper? That's what I learned in my tech writing course, and I didn't know anything about HTML and CSS. I learned that on the job in my first role. So even then, the courses that you can take might not prepare you for the actual jobs, and I find a lot of people find that intimidating. I get a lot of messages on LinkedIn saying, do you have course recommendations so that I'll be prepped for the positions I want to apply for? I think my answers can sometimes be frustrating or scary when I say, I don't think that there is that box you can check off by taking a course. I think it's more a matter of attitude. It's what I see when you were talking about your career in that other episode. It's just, you've taught yourself. Most importantly, you tell yourself that you're capable of learning these new skills, and you play around until you get it done. Then you do it and then you write about it. To me, that's emblematic of tech writing. Rather than, I know all the languages and I can code in all of them. Kate Mueller: [00:17:40] So would you say that it's a good skill to be able to, not just continuously learn, to recognize that you have more to learn. But also that there's a-it requires a certain level of humility, maybe, to be able to say-no, it's not humility. It's that comfortableness with not knowing. With walking into a job or a role and thinking, I don't necessarily have the full range of, perhaps, all of the tool knowledge or the process knowledge or whatever that I might have to have, and I'm comfortable enough to take the role anyway, and then just roll with it once I get into it. To recognize that I'm going to have to learn on the spot, on the job, probably under a little bit of duress, and that you're comfortable with being in that place. That was a very long question. Janine Chan: [00:18:40] It's because it was so good. Sometimes you need to give a question a lot of space on its own. Kate Mueller: [00:18:46] It has to breathe. It's like a finely aged wine, you must let it breathe long enough. Janine Chan: [00:18:50] Swirl the question around, give it a sniff. I think you really have to trust yourself that you can learn. I think that there is the humility to say, I don't know everything there is to know because we have established there is no such thing. I think it's really easy to have a bit of a fear response to that. I think the imposter syndrome is really common because you're always learning. You're always telling yourself, there's more that I could know about this. I think the people who I know who are the most successful or the happiest in tech writing are the ones who go, cool. Because it's an opportunity to continue learning and to challenge themselves and to trust that they'll be able to learn it. They won't stay in that 'I don't know what I'm doing' phase. They see it, I think, as a necessary step to getting the solution, getting the project done. They find it a fun challenge because they don't tell themselves 'I am not technical'. I think that's one of the biggest traps to really essentialize that feeling. They just go, I don't know how to do this yet, but I will. Or, there's no reason why I can't eventually know how to do this thing. If you're comfortable with that feeling, then I think it's a lot easier to move past it and figure out what you need to do, to do the thing. Kate Mueller: [00:20:15] So maybe a key component of that, also then, is the story that you're telling yourself about your experience and your ability to either learn more or step into something that's not a comfortable place for you, but to tell your story that it will become a comfortable place for you. That you have confidence in yourself to stick it out. Janine Chan: [00:20:39] I think it's a fantastic Jedi mind trick to play on yourself, because then you get to see it as an opportunity. You get to approach it with curiosity instead of anxiety. You get to take more control over the fact that you don't know, because you just don't know yet. But there's no reason why you can't. I think the more evidence you have that you're capable of teaching yourself, the easier it gets and the more fun it gets. So I think the real trick is learning how to make it feel fun. Kate Mueller: [00:21:11] So what have been some of the ways that you have tried to make it feel fun for yourself? Janine Chan: [00:21:18] I don't know that it's the way that I've consciously done it. I'm somebody who likes to get really deep into a challenge. Last year at my old job, I was doing a migration into Docusaurus which required, I don't even remember what language it was, but I hadn't dealt with it before. It was all a new and scary world, and I was trying to futz with the search results and stuff like that. It was just something that I really wanted to focus on. The more frustrated I got with it, the more I wanted to fix it, and the more satisfying it was when I figured it out. I don't even remember what it was. I think part of it is just what your brain enjoys fixating on, which is less of a Jedi mind trick, and I guess where it intersects with personality and the kinds of challenges you enjoy. Because I find that the angrier something makes me, the more I enjoy fighting with it. This is just work. This is not to say that I have incredibly toxic friendships or anything like that. Kate Mueller: [00:22:20] I would hope not. I was about to be very worried for you, Janine. Janine Chan: [00:22:24] As my friend, Kate, welcome to hell. Kate Mueller: [00:22:31] I'm now second guessing everything about my personality and why we stay in touch. Janine Chan: [00:22:34] Yeah, this is going to be a very contentious episode now. Kate Mueller: [00:22:44] I mean, leaving the possible toxicity of your personal relationships aside, I think there is, maybe this just puts the focus on how important self-awareness is in this field. That you need to be aware of your limitations, but you also need to be aware of the things that are the most motivating or fulfilling or inspiring for you, so that when you get into those totally new languages, tools, domains, whatever it might be, that you can put a spin on it to say, here's the stuff that I know is going to help keep me afloat during this time period where I feel like I could drown because I don't understand how to swim in jello. I have to figure out a way to acclimate to this environment to be comfortable with it. If you lack the self-awareness for that, I imagine that that would be incredibly stressful. But having that level of self-awareness of, in your case, if it makes me angry, I get that much more excited to figure out how to solve it. Then when something makes you angry, instead of being, I should just quit, you're like, this is where I want to dig in. This is where I want to spend my time for the next week. Janine Chan: [00:24:02] Yeah, exactly. I imagine that's true of any field that you work in. You have to know what makes you tick because you're going to spend 40 hours a week doing it. You might as well try to find ways to make it work for you. I think it really does help to know which of your limitations are permanent and which ones you can work around. Because it's easy to say, I am not technical. This is a permanent limitation of mine. But when you think about, what does 'technical' mean, what's the skill that you're lacking right now, you can break down how to get past that limitation. But then there are permanent ones. I cannot draw. Boy, have I tried. If I have to make graphics for my own docs, it'll be one box over here with an arrow pointing to this box. But anything beyond that, I can't. I know that about myself, and I've been able to work with some really great graphic design teams, and I've been aware of not stepping over that barrier to this sort-of-permanent skill I do not have and can't seem to build for myself. I know how to not set myself up for failure, and I know how to ask for help when I know that I'm edging towards it. It's just a matter of really knowing how you can make yourself happy and pursuing that, while also not making excuses for yourself to not learn. It's a fine balance. Kate Mueller: [00:25:27] I was going to say, no big deal. This isn't hard at all. Janine Chan: [00:25:32] It is so hard. That's why this is such a common topic with tech writers, I think, and it's such a common struggle. 'Am I technical'? Do you look in the mirror as you're getting ready for bed, 'am I technical now'? I don't know. Kate Mueller: [00:25:46] Am I technical enough? Yes. Well, in the land of things that make us happy, I think this is a great time for us to take a little break. So we will happily take a break, and we will be right back with more with Janine. Kate Mueller: [00:26:02] This episode is sponsored by KnowledgeOwl. If you're looking for an owl-in-one solution to keep your software team’s docs organized, KnowledgeOwl has you covered. KnowledgeOwl offers content access control for internal and public docs, flexible customization, robust security, and friendly support. Learn more and sign up for a free 30 day trial at knowledgeowl.com. Kate Mueller: [00:26:29] We're back with more from Janine Chan today. So, Janine, I want to pick up on a thread you tucked into the middle of that last reply, which was the ability to ask for help along the way. I specifically wanted to ask about this because I think sometimes there is this feeling in tech writing that you should just be able to figure it out by yourself, or that it's maybe even a sign of weakness to ask for help, or you don't want to let the developers that you're working with know that you don't understand something. I've had the opposite experience where the more I ask, actually both the faster I learn and the better the relationship I get is. So I'd like you to talk more about that, about asking for help, asking good questions, and how that has helped you deepen your technical prowess. Janine Chan: [00:27:21] It is so common, especially when you're feeling really deep imposter syndrome, it is so hard to ask for help. It's hard to admit to other people that you don't know something. It's really easy to worry about making a mistake and imagine that everybody is going to point and laugh. Which is even more impressive if it's in a virtual setting, that they'll just know the direction, but they will somehow. It's really easy to get in your head about these things. I think that I've been really lucky because I've worked with incredibly generous writers in the past, and PMs and engineers, and I also have learned how to ask good questions. When I'm doing research on my own, I will give it my best shot. Sometimes I will get an answer that I think is maybe 80% of the way there, and sometimes I'll still have no idea and that's totally fine. I find that when I'm asking a question, that it helps to show your work, and it helps to be able to point to something specific where you've gotten stuck. You can maybe make the interaction a little bit smoother by going, I've gotten this far on my own. I promise that I didn't decide to message you because I secretly love wasting people's time. The really nice thing that I've learned is that people are so generous with their time. Maybe not when they're swamped and they've got so much stuff that they can't possibly talk to you and also find time to eat and sleep. That's totally fine, people have their boundaries and they should. But people want to help you. People feel good when they're able to answer your questions and help you get unblocked. For me, I think part of it was alleviating my own guilt from asking for people's time by doing my own research and being able to ask really specific questions. Rather than making somebody think, 'does she just want me to do her job for her', they're answering something specific. Also reminding myself and giving myself evidence and collecting that evidence, that when I ask people for help, overwhelmingly, they respond positively and are so happy to do it. I think that over time, you start to get into that habit of being okay with asking for help and telling yourself that it isn't a sign of weakness. Because if it was, then I don't even know how people would function. We are social people, social animals, whatever the phrase is. We are programmed to cooperate with each other. A tech setting shouldn't make it any less so, that we need to band together sometimes to get the best results. Kate Mueller: [00:30:19] It's also worth noting that, at least for me, there have been times when I've gotten to that 80% of the research and I feel like I've hit a wall, so I go to start to ask the question. In the effort of trying to clearly articulate the question, I suddenly realize that there's some angle or element that I've overlooked that I could, and maybe should, go research before I actually ask the question. Sometimes it's not even getting the response from someone else that I've found useful, but it's the act of having to frame the question that helps some subconscious part of my brain be like, but this other thing, you forgot about this thing. You can't possibly ask this question until you look at that thing. Very often that thing was actually the answer to my question. But it's that, I needed to 'rubber duck' this a little bit. As soon as I said it out loud I realized, I think I know the next thing I should try on this. Have you found that to be the case as well? Janine Chan: [00:31:27] Yes, absolutely. I was just going to mention that we've got a rubber duck emoji that I use pretty heavily. Because sometimes you just need to bounce ideas off of somebody, anybody, that empty text field, to get yourself unblocked. I think it's another indication that sometimes you just need to get out of your thought loops in your head and get it out. It's surprising how it can get you unblocked. Kate Mueller: [00:31:53] KnowledgeOwl has trained me very much to think about a lot of the interactions I have as whether or not they're giving good service. I feel like it's an act of good service, that if you're going to ask someone for help, that you provide context and details around the help that you are requesting. That might be, I've researched up to this point and this is where I've gotten stuck. Or it might be, I've tried these four things, what am I doing wrong? Or is there another approach that I've missed here? It is as if you're being generous in the 'ask' as well, because you've already put time, energy, and effort in. So when you are making the request of someone else, you're giving them a much more tightly scoped question to answer, which is more respectful of their time and makes it easier for them to be generous in the response. Janine Chan: [00:32:43] Yeah, that's exactly it. That's really well put. The more I think about it, the more specific the question, the more insight you get on somebody's thought process, too. It's not just that you're asking for a technical answer. I think what I'm getting at by saying, you can teach yourself all of these tech skills, is that when you ask a question, you get to learn about how the people you admire think rather than how they do things. I think that's a really key part to building up that confidence and building up your ability to solve that next technical problem, is that you're not just asking people, what would you do? What would you type into the box to make the magic thing happen? You're getting to the point where you're getting stuck and saying, what do you think about when you encounter the same thing? What do you remember? What comes to mind? You can start to adopt that thought process. You just slowly steal these things as you go, and you can get stolen from, too. That's this cooperative way where, they say a rising tide lifts all boats. You can start to build expertise to help other people, too. I think that's my favorite thing about working on a team with writers, is that everybody's expertise helps everybody else. It's not just the solutions, it's teaching each other how to think through different kinds of problems that different backgrounds prepare you for. Kate Mueller: [00:34:14] That's a really good way of describing it. This is something that KnowledgeOwl has incorporated a bit into our onboarding process, because it's been a really small team for a long time. A lot of that knowledge about the history of the product, or how we've solved certain weird things has been very trapped in three people's heads. We realized really early on that that was a problem, and you can only document so much stuff. At some point, we started doing, what we called, 'support out loud onboarding' where when we hired a new support person, there'd be a period of time where they shadowed different people as they responded to tickets. The experienced person would talk through how they would approach a problem. Okay, so I know this and that, and here's where I think the problem is so I'm going to start there. Just walk somebody through, not the answer to the problem or the question, but the actual process of achieving and finding that answer. Because that is often that problem solving ability to break down the thing into pieces and figure out how to approach it. That is the thing that is fairly unique to individuals, but it is also the thing that actually enables other people to solve things instead of just being like, here's the answer, go away, quit bothering me, kid. Kate Mueller: [00:35:35] I think that that's a good way to think about many of those interactions. Is that, I want to teach you a little bit. I want to peel back the curtain so you can see how stuff works in my brain. Which is maybe not the same way it works in your brain, but you can see how I'm working through this problem. Therefore, the next time you encounter a problem that is similar in nature, even if the exact solution is completely different, you will have that problem solving ability in your toolkit. If I think about the developers that I've worked with the most closely, who've taught me the most over time, it's been because they took the time to do that. To sit and walk me through how they approached a particular thing. Or if they did come up with a solution on their own, but then to explain to me what the pieces of that were or where they got them from. It's a good way to do knowledge transfer, but that's knowledge transfer of a process rather than knowledge transfer of a body of knowledge. Janine Chan: [00:36:45] Getting used to thinking about how other people think is also a really great way to get used to writing documentation for an audience that has a really different experience level than you. I think it always helps to have been in the position of not knowing anything. I can't remember where I picked it up, but somewhere I read the phrase 'the joyful idiot', where you're just like, yeah, I don't know what's going on. I will eventually, but that's not what's happening right now. That helps you not only get over the hump of not knowing what's going on yet, but also you can go back and you can look at a user, maybe who is in the same spot. There's no judgment involved. You can also project your brain into what they're thinking, too. It kind of goes both ways, and I think that flexibility is really important for the tech writers who I know and admire, is that they're able to take in how other people are thinking and also empathize and put themselves in the shoes of somebody who thinks differently from themselves, too. The more flexible you are, the more able you are to jump between other people's brains. This got really weird on a biological level, but the more comfortable you are thinking like other people, I think the more you can build up your own brain. Kate Mueller: [00:38:06] We're veering far into weird little corners of each of our brains at this point. I think that that's probably really true. Both that those experiences help you center and bring empathy into whatever you're writing, which is always going to be helpful for the end user experience of that documentation. But it also helps expose you to the sheer diversity of the way different human's brains work. If I think about what I might consider more 'old school' technical communication training, back when folks did actual paper manuals of things, there was definitely underlying some of that curriculum, that the field that there was a right way to do that documentation. I think the place that you get to once you've been exposed to the way a lot of other people's brains work, is that there isn't a single right way ever. There's ways that work better for certain people, and then there are ways that actually don't work better for those people, but might work better for others. What you're really trying to do when you create technical documentation is to try to find something that's reasonable enough for the majority of the people who are going to be interacting with your content, or to recognize that there are very different paths for how people might absorb information. You're structuring, making media selections or formatting selections or choices differently to try to appeal to those different groups. But if you don't have the exposure that those things exist, you can't put yourself in that user's position, then there's no way you're going to create that documentation in a way that makes sense for them. Janine Chan: [00:39:49] Yeah, absolutely. I think a lot of people look at, once you've learned a certain amount about technical writing and you have that awareness of how many valid approaches there can be, I think a lot of people hit a mental block there, too. I think such an attention oriented field often attracts people who struggle with perfectionism. To go, there must be a best choice out of all of these options that I have, there must be a way that I can improve this, and what I write will never be quite good enough. It's exactly how it's easy to think, I'm not going to be a good technical writer. It's easy to think in a parallel way, this documentation is never going to be good enough. I think the people who I enjoy working with also have a good sense of perspective about their writing, about their perfectionism, and to recognize that any docs are better than no docs at all. Most of the time, hopefully they're right and everything. I have a coworker who I used to work with, he's awesome. His name is Lachlan, he said 'just enough just in time', and I think about it all the time. Because instead of going, I need to overthink this and I need to make it just so, and I need to make sure that every sentence is absolutely perfect. I think if you try to do that, you're probably going to limit yourself in your career. You can't go for those really big projects that you have to get out really fast and really challenge yourself, because you'll be so tied up in those little problems that arise and that you probably can't get to 100%. If you get something out, I also like the phrase 'don't let perfect become the enemy of good'. If you can make it good, that's awesome. You've done your job. The software, whatever you're documenting will probably change in the future anyway, so it's just as well. But the more you can forgive yourself for not being perfect all the time, the more easily you're going to deal with all of those potential approaches to a problem. Kate Mueller: [00:41:57] The question should no longer be, am I technical enough? The question should be, is this good enough for now to get out? Janine Chan: [00:42:05] Is it okay? Is this something that will help somebody? Then it doesn't have to be a question about you, it doesn't have to be a question of how good the docs are. Can this help someone? Maybe it's more easy to answer that question in a way that's kind and constructive to yourself. That's always the hardest part. Kate Mueller: [00:42:23] I find lately, because I am perpetually behind, that the question I ask myself is, is this better than what I had before? If it's better, if the answer there is yes, then I can publish it and feel fine because it is still an improvement. I think this is where working with a lot of developers has helped me reframe what probably was inherent perfectionism, because most of the developers I've worked with will be like, I just had to touch code I wrote two years ago and oh my God, it was awful. I know so much more now, I would write this in a totally different way now. For the folks who've been developers, I think you come to just expect that two years from now, your approach to solving that problem is going to be totally different. So you just do the best you can with what you have and recognize that in two years you'll be grumbling about the choices you made now, but you will know more and be able to solve the problem in a more elegant way. I've tried to embrace that for my documentation. To be like, in two years I'm going to hate this. I might not stress as much about it, because one way or the other, it'll be outdated. We will have changed our style guide, the app itself will have changed so significantly, whatever that might be. Our primary user base has changed so we'll have to retool how we focus all of this. If you just accept that in two years I will regret these choices, even if they're the best choices for right now, it takes some of the pressure off of making the choices right now. You just accept that it's going to be imperfect. Janine Chan: [00:44:07] I think you can also look at it in an aggressively non-judgmental way, too. I tend not to look at it as, I'm going to hate it, or I'm going to judge myself. It's just going to be, future me is going to pat present me on the head and go, you did your best and your best will be much better in the future. I go, won't it be nice to be her one day, but this is what I'm doing now. Kate Mueller: [00:44:33] Future me will thank current me for having done any of this work. Because imagine how much more horrible it would be if I was starting from ground zero in 2 years on this, instead of iterating on existing content, which is probably much easier. Janine Chan: [00:44:49] Exactly, you have to have something to iterate on. Kate Mueller: [00:44:50] In the land of 'seeking feedback from folks', what do you do with people who are prickly or difficult or aren't inherently generous with their time or their knowledge? Because we have so far been talking about how amazingly generous and awesome people are. That is generally true, but there are always going to be some folks who aren't or they're having a really bad day. So that day they are not at all generous with whatever. How do you navigate that? Do you have any amazing pearls of wisdom that I can steal from you? Janine Chan: [00:45:27] I wish I did. I wish I had Jedi mind tricks that you could apply to other people, instead of just thinking about your own work better. I try my best to meet people where they're at. If I know that somebody is super busy, I'll try to give them the bullet points or screenshots to save them a click and say, this is the part that I'm really wondering about. It goes back to asking good and specific questions. Sometimes if there's a subject matter expert who I would love a full review from, but I know that I am not getting it unless I tape their eyes open Clockwork Orange style. I haven't looked it up, I'm sure that's not legal. Kate Mueller: [00:46:09] I'm pretty sure that's an HR violation at bare minimum. Janine Chan: [00:46:12] I would be pulled in some very interesting meetings, I'm sure. If I know I can't get that, I will try to pinpoint my own gaps in my knowledge and I'll ask them to specifically fill those out. I'll try to make it as quick and painless for them as possible. I think that's all you can do. Sometimes you can try to see if there's somebody else who has a similar knowledge set who you can ask instead. Sometimes you can go to other writers. Oftentimes teammates will have a fantastic different way of looking at things or another resource that I haven't seen before. It's really nice to have that support. Maybe somebody else has encountered something similar. That's part of being a tech writer, is just dealing with all of those different personality types, and sometimes they clash. I think there's no real getting around it. Maybe sometimes it's just another one of those things where you don't essentialize the fact that it's happened to you. You don't think, I did something or I am something that made this happen. You go, that was weird. You just move on. Kate Mueller: [00:47:25] Well, and recognize that those interactions have-we're all three dimensional people. We all have a lot of baggage we bring with us into the workplace, into each day, into whatever. Whatever that interaction was might have had literally nothing to do with you. Could have had a ton to do with what was going on with that person for the day or their family, or maybe they just got done getting chewed out by their manager. You don't know the context in which you asked the question. That advice to, don't essentialize that, it's not about you. It is just the thing that happened and moving on. I think that's a good tactic to take. I think I could talk to you literally all day, Janine, but for the sake of our listeners, I'm going to try to get us into the tail end of this episode. Typically when I get here, there's some general questions I like to ask. I know we've been talking a lot about how there isn't a particular set of courses or certifications or other things that you can do to level up your tech writing skills, but are there any resources generally that you think would be beneficial to folks? Whether that's helping people get in the right mindset about a thing or some of those more esoteric elements. Anything that you can share with us there? I will not pressure you for certifications and classes, I promise. Janine Chan: [00:48:55] I think that more important than any one certification or class, like you were saying, it's so much more interesting and rewarding to talk to other writers and to other people you admire. I would recommend joining Write the Docs for sure. Not just to plug it because I'm involved with them, but because that's how I found that I got the inspiration for my own career. That's where I got to talk with other people, and just ask. I think that skill is really cool, what did you do to get it? How did you get into the position where you're able to use it every day? Practice that sense of curiosity, asking questions, receiving help. I think that a lot of people really struggle with that. I know I sometimes still do. Also, crowdsourcing your career advice. Because I think that hearing from diverse voices means that you get so much better help. I think my advice is always just to find people you admire, surround yourself with people who you think are really cool and see what you can steal. Oftentimes, they're more than happy to help you. Kate Mueller: [00:50:05] Write the Docs is a great community for that. Both because there's the online Slack community, and the conferences, and there's a lot of local meetups where you can connect with folks. You can pick your poison as to how you like to engage with others, as well. Maybe a closing thought, what is a great piece of advice that you've been given? It does not have to have anything to do with tech writing whatsoever. Janine Chan: [00:50:31] I did think of a tech writing related piece of advice that I got from my coworker I mentioned earlier. I messaged him once when I felt like I was absolutely drowning at the company that we worked at together. He said, it's okay to put your blinders on sometimes. I think that the job before, I'd been managing a team, I always knew what was happening. It was a small company and a small team, and I knew how everything worked, and I knew what was on every release. This company that he and I worked together at was a lot bigger. There were a lot more teams, there were a lot more engineers, and I was trying to keep an eye on way too much. I was setting myself up for failure, because there's no way that you can do justice to everything. He told me to focus on my little sphere of influence that I could have in the docs, to trust that I could manage that little bit, and that the other writers could manage their bits. We didn't have to try to help each other with everything. I know that for me, I struggle with wanting to be the one to answer every question because I know. But sometimes stepping back and saying, does it have to be me? Does it have to be something I deal with right now? Giving yourself room to have more focus really helped me survive that transition from quiet job to very busy job without going down that road of essentializing, I don't have superhuman skills. How dare I have capacity that can be exceeded. The gall of having a normal number of brain cells and fingers that I can do this work with. Kate Mueller: [00:52:16] How dare you be human, Janine, how dare you! Janine Chan: [00:52:20] We just don't forgive ourselves for our innate humanness. I found that was really helpful. Every time I started a new job after that I've gone, what do I need to be focusing on and what can I trust that either I can deal with later or that somebody else can pick up? Not so much that I don't think that somebody else is going to do a good job, but the sense of guilt that I have for not doing it myself. You can let that go. It's fine, it'll get done. It's also just work, which you can feel guilty for thinking of it as just work, but also you'll be fine if it doesn't get done. Kate Mueller: [00:52:57] Also, a lot of us work with some very smart, very talented people. At some point, you do have to recognize that you need to trust others to do their job. Just like they're trusting you to do your job and feeling like you don't have to be keeping an eye on all of that is also a sign of respect to them and their abilities to be like, you've got this. I will just wait for you to tell me you don't have it. If that day ever comes. Janine Chan: [00:53:25] My anxiety over this not getting done doesn't have to spread to you. I can keep this all to myself. Kate Mueller: [00:53:31] I can hoard my own anxiety, thank you. Maybe in the spirit of continual learning, is there anything that you are currently learning to do or that you are looking forward to learning about? Janine Chan: [00:53:43] That's a great question. I think that sometimes the most fun feeling is not knowing what I don't know. Right now, I am starting work on a security product at Datadog. I know nothing about security, but it fascinates me, and I find that both intimidating and really exciting to get stuck into a new domain that I've never written in. Tech writing is the perfect way to learn about something. I am really excited to apply the tech writing skills that I've been able to build elsewhere into a totally different context. It's a big challenge, there's a lot of velocity in the security world and in the products that arise to combat those things, but it keeps me excited. Kate Mueller: [00:54:30] That sounds fantastic. Staying true to your ideals that tech writers do have to be continuously learning, because we work in spaces that are often very fluid and very quickly changing. Thank you so much for this, thank you for your time, thank you for being generous with your knowledge and everything else. This has been a delight. Janine Chan: [00:54:51] Thank you so much for having me, Kate. What a pleasure to talk with you about what I think we both care about so much. With a tech writer, that is you, who I respect and admire so much for so many reasons. Kate Mueller: [00:55:06] Thank you, that is a mutual feeling. I would not have asked you on if I did not respect and admire you and want to hear everything you could possibly throw at me, so thank you so much. Kate Mueller: [00:55:22] The Not-Boring Tech Writer is produced by the lovely humans at Astronomic Audio. With editing by Dillon, transcription by Alan, and post-production by Been and Alex. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. If you have feedback or ideas for a topic or guest idea, shoot us an email at tnbtw@knowledgeowl.com or message KnowledgeOwl on LinkedIn.