[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about how to communicate complex technical topics with Anna Skoulikari, Technical Writer at Mambu.

[00:00:19] AS: What I realized then was that the way that Git was taught online was not really user-friendly to people coming into tech from non-technical backgrounds, and that I myself could actually teach the topic in a much simpler and more human understandable way.

[00:00:35] SY: Anna talks about transitioning from UX designer to front-end development, how to explain complex topics like Git, and why technical writing isn’t as boring as some might think it sounds after this.

[MUSIC BREAK]

[AD]

[00:00:57] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:14] Ambassador Labs enables developers to ship software faster on Kubernetes. Sponsor of both the Ambassador API Gateway and Telepresence open source projects, Ambassador Labs is used by tens of thousands of developers worldwide. Learn more at getambassador.io.

[00:01:32] RudderStack is the Smart Customer Data Pipeline. Easily build pipelines connecting your whole customer data stack, then make them smarter by ingesting and activating enriched data from your warehouse, enabling identity stitching and advanced use cases like lead scoring and in-app personalization. Start building a smarter customer data pipeline today. Sign up for free at rudderstack.com.

[00:01:57] New Relic helps engineering teams all over the world visualize, analyze, and troubleshoot their software. Discover why some of the most influential companies trust the New Relic One observability platform for better uptime and performance, greater scale, faster time to market, and more perfect software at developer.newrelic.com.

[AD ENDS]

[00:02:23] SY: Thank you so much for being here.

[00:02:24] AS: Thank you so much for having me.

[00:02:25] SY: So you didn’t always have a technical background and now you literally have a job explaining very, very technical things. Tell us about your journey. Where did it start for you?

[00:02:35] AS: So I think my journey into the tech space starts off in London when I was living there. And I ended up doing a UX bootcamp, so a user experience design bootcamp. And that was where I learned how to design digital interfaces, so mobile apps, websites, and that was kind of my introduction into getting hard skills and getting into the space of tech. And I ended up working as a UX designer in London. And after a while working as a UX designer, I got really curious about coding because I really felt like as a UX designer, you’re kind of like an architect. You can create the blueprint of what a digital product is going to look like, so what an app or a website is going to look like, but you’re not the construction company. You’re not the one that gets that blueprint and actually builds the thing. So I got really curious about how are these things that we’re designing actually built. So basically after that curiosity peaked and I ended up moving to Barcelona, and when I moved here, I decided to study coding. So I went to a coding bootcamp and that’s where I really got technical skills and where I first learned to code.

[00:03:46] SY: So tell me a little bit more about the UX experience. What toolset do you work with with UX? If you’re not necessarily coding, but you’re still working on a product, what does that role look like? What tools are you using? Paint that picture for me.

[00:03:58] AS: So in UX design, you’re going to be using some sort of software in order to create your digital designs or often called “wireframes”. At the time I had learned Sketch. Honestly, it’s the world of tech. So I’m sure that there’s like a bajillion new tools that have been created. The main thing in user experience design is about thinking from the user’s point of view and having empathy for the user and thinking about how you can design a digital experience that’s going to be smooth and user-friendly.

[00:04:30] SY: And tell me more about bootcamp. What was that experience like for you?

[00:04:33] AS: That was a really crazy experience. Because honestly, if somebody had asked me five years ago whether I would learn to code, I would tell them like, “No way. Why would I learn to code?” I remember actually being younger. When I was 21, one summer I was working in a startup accelerator. And I remember at the time I would meet a lot of people that worked in startups that needed developers. And so whenever people would come up to me and say, “I don’t know what to study, I don’t know what to do,” I would say, “Study computer science. Study coding.” I just know that there’s so many jobs out there for developers. But whenever they would ask me, like, “Why aren’t you studying coding?” I would think, “Well, my mind doesn’t work like that. I wouldn’t be able to do that.” So when I did move to Barcelona and I decided to do this coding bootcamp, it was kind of a big personal development journey for me to face my fear of something unknown and uncertain and to just learn something new that I had previously never thought would be something I would ever attempt.

[00:05:35] SY: What made it so scary for you?

[00:05:37] AS: I think it was just that I had no idea what to expect and that I had never attempted to learn something that technical. So it was just the fear of the unknown, I think.

[00:05:50] SY: Yeah, I can totally appreciate that. So you have an interesting perspective because you’ve done both the design, the UX side of things, and you’ve actually built products and done the coding. Tell me about those two worlds and where they intersect. How do those two worlds kind of come together for you and how does having both sides of the story? How has that impacted your technical skills?

[00:06:14] AS: So those two worlds come together for me in my first job, working as a developer after the bootcamp. So after my coding bootcamp, I ended up getting a job working as a front-end developer in a company here in Barcelona. And while working in that job, I realized that I had to really understand how to use Git version control. Basically for anyone that doesn’t know, Git is the way that coders track the versions of their project and it’s the technology that they use in order to collaborate with other developers. And I was terrified of Git. I had learned the basics sort of at my coding bootcamp, but it’s when I arrived at my job and I realized that I didn’t really understand how it worked. And whenever I had to do something that I thought was complicated using Git, I was terrified and I thought that I was going to destroy the repository. So I always had to call on the senior developers to come help me. And at some point, I realized, “Okay, I want to face this fear, this fear I have of Git.” So I decided to really master it and to really learn it really well. What I realized then was that the way that Git was taught online was not really user-friendly to people coming into tech from non-technical backgrounds and that I myself could actually teach the topic in a much simpler and more human understandable way. So I ended up creating this online course, teaching Git. It was just this creative idea that came to me and I thought, “Okay, I should do this because I can help so many other junior developers or other people that need to use Git that aren’t extremely technical to learn it in a much easier way than my journey had been.” So I created this online course and that’s where I feel like my technical background and then my communication skills just came together. What happened was I put that course on Udemy, so Udemy is an online course platform, and it became a highest rated course on Udemy. And that’s where I realized that using that skill of thinking of things from the user’s perspective and having empathy for people and thinking about how you can explain things in the most simple and tangible way was really helpful in explaining technical concepts. So that’s kind of how those two worlds came together. That experience is sort of what led me into the next chapter of my journey, where I decided to enter the space of tech communication and tech education.

[00:08:49] SY: So tell me about what you’re doing now. You have this UX background. You have this developer background. You created this really incredible, really popular course. And today, you’re a technical writer. Tell me a little more about what a technical writer is and how all those experiences impacted what you do today.

[00:09:06] AS: So a technical writer, honestly, it’s a job title that can vary extremely from one company to another. It’s not something that is extremely well-defined. So in my case, a technical writer is writing developer documentation, API documentation, even support documentation like support articles, but you can talk to various other technical writers and they may do completely different things. But for me, technical writing is just a way for me to combine my tech background with my communication skills, and I’ve always been a writer. I really love writing. It’s the way that I can express myself the best. I’m actually also a lifelong journaler. I’ve been journaling for the last 10 years. So writing is a really big part of my life. So it’s really cool that now I’ve found a way to merge my love of writing with my ability to communicate technical concepts into my job.

[00:10:08] SY: So you wrote or created, I guess, this course Git Learning Journey - Guide to Learning Git (Version Control) on Udemy that you mentioned earlier. So let’s get into it. What is Git? And how did you make this course?

[00:10:21] AS: Yeah. So basically Git is a version control system, and it’s basically a program that you download onto your computer and you use it in order to keep track of all the versions of your project and also to collaborate with other developers. And it’s really important. And the really cool thing about Git is that actually almost anyone that writes code uses it. So it’s not just something that a back-end developer or a front-end developer uses. It’s for data scientists, data analysts, anybody that writes code, and that needs to keep track of all the versions of their code can use it and not even just developers, also technical writers use Git. So it’s something that kind of is a shared experience among a lot of people in the tech world. In terms of how I got started to actually build the course, in the beginning I thought that I would have to learn this really complicated animation software in order to make the videos. I’d never made a course before. I’d never even explored how people make online courses. So what I ended up doing was at the time I was working as a front-end developer and as part of a new product that I was working on, I had to learn and Vue. So Vue is a front-end framework or front-end library that developers use. React is another one. And I’d learned React in my bootcamp, but I had to learn Vue. And I really loved the online courses that Vue Mastery had. So what I did was I contacted the people that work at Vue Mastery. I contacted Adam Jahr and I asked him, “What do you guys use in order to make your online courses?” And he told me, “We use Keynote.” And that’s when I realized I don’t need to learn some really complicated animation software in order to make my online course. I don’t have any excuses for procrastinating to start this creative project. Actually, all I need to do is to start using Keynote and Keynote Animations. And with that, I can build an online course. So I started making one presentation per lesson and it was all just me hacking away working with these Keynote presentations and then preparing lessons and recording my voice, teaching these lessons. So it was really just me on my own doing the bare bones version of an online course and just figuring out how I could present things on the screen in a simple way. And honestly, my main principles that I tried to stick with wasn’t minimalism. So keep things as simple as possible, and consistency. And obviously, any designers out there will know that consistency is a really, really big thing in design so that people know what to expect and so that there’s a really nice flow and rhythm to an experience.

[00:13:12] SY: So I remember learning Git years ago and I remember being very, very, very confused by it. And you’re absolutely right. A lot of the resources, the ones that make it to the top page of Google, they are not newbie-friendly at all. They are just not made for people who are non-technical, who were trying to get into it for the first time. But there was a moment, I don’t remember exactly when it was where like clicked and it finally came together. And I’m curious, when was that moment for you? And how did you use that moment to make it click for other people?

[00:13:42] AS: I think that moment came for me when I started to play around with Git at home. I would just be on my bed with my laptop and I would try to do things in the wrong way on purpose. For example, I would open up the .git folder, which is a hidden folder. So in the beginning, I didn’t even know it existed. On a Mac, for example, you have to press the command shift dot in order to see hidden files, in order to even see this folder. And then I would look inside that folder and I would try to understand what are all the things inside this folder. And that’s when I really started to connect the dots. And I think, honestly, it’s like I started developing Git confidence. So at work, whenever I would have to do something with Git, every time that I was able to actually do it just on my own or figure out the solution on my own, it just increased my Git confidence just a little bit more. And then at some point, I realized that sometimes I could help other people with their problems with Git.

[00:14:44] SY: Oh, nice!

[00:14:44] AS: And that’s where you really felt like, “Okay, I get this. I understand this.” And you’re right. The thing is there are some amazing resources out there. I want to mention one in particular because honestly I owe my course to this resource. It’s a book called Pro Git and the book is I would say like the Bible for Git, and it’s very, very big. It’s very thick. That’s why I also called it like a Bible. It’s really, really big. But it’s also just available online for free as a PDF. And it’s extremely in depth. It has everything you need to know about Git. It just introduces the information in a different way than would it be useful for a certain kind of Git learner. So that resource was extremely helpful for me, taught me a lot of things, and I just want to give a shout out to them.

[MUSIC BREAK]

[AD]

[00:15:58] Want to learn more about Kubernetes, but don’t know where to start? The Kubernetes Initializer lets you build your own application right in Kubernetes’ playground in just a few clicks. Automatically configure Ingress, a continuous integration pipeline, authentication and more. Try it for free at getambassador.io/codenewbie.

[00:16:18] RudderStack Smart Customer Data Pipeline is warehouse first. It builds your customer data warehouse and your identity graph on your data warehouse with support for Snowflake, Google BigQuery, Amazon Redshift, and more. Their SDKs and plugins make events streaming easy, and their integrations with cloud applications like Salesforce and Zendesk help you go beyond event streaming. With RudderStack, you can use all of your customer data to answer more difficult questions, and then send those insights to your whole customer data stack. Sign up for free at rudderstack.com.

[AD ENDS]

[00:16:57] SY: So one of the things that I remember was very confusing when I was first starting out is Git and GitHub. Right? I hear Git, obviously GitHub has the word “Git” in it, wasn’t always clear the distinction between the two. Can you just talk a little bit more about that? What is Git and what is GitHub? Where are they the same and where are they different?

[00:17:16] AS: Yeah. I’m really glad you brought this up because this is one of the first lessons in my course and it’s also something that I see a lot because people use those two terms interchangeably and they’re two completely different things.

[00:17:27] SY: Right. Right.

[00:17:28] AS: So basically Git is a program that you download onto your computer. It’s a version control system. Think of it sort of like Microsoft Word. Whereas GitHub is just a company that allows you to host your projects that use Git on a remote server somewhere, in the cloud, let’s say. So GitHub is kind of like Google Drive in that analogy, in that metaphor. There’s a lot of things that are different and GitHub was just smart enough to use the word “Git” in its name. And even though GitHub is one of the most commonly used places that people upload their Git projects to, there are other options. I mean, there’s GitLab, Bitbucket. I think there’s one called DigitalOcean. I mean, there’s other companies that you can use. So that’s the main difference between the two, but you’ll see very often in articles or when people are talking, they’ll use the terms interchangeably. And now that I’ve become a bit of a Git educator, let’s say, I always see those moments and I’m like, “Wait, no. They’re completely different.”

[00:18:42] SY: Absolutely. So tell me about why Git is so scary. Because, I mean, Git has given me of all of my anxiety coding, I think most of it has come from my attempting to use Git and just feeling like I didn’t know what I was doing. But why is it so scary? I mean, Git is supposed to be used as the safety net, right? It’s a safeguard. It’s a thing that’s going to save your code no matter what. But instead of looking at it and embracing it with a lot of hope and positivity, everyone’s so afraid of it. Why is that?

[00:19:11] AS: So I think there’s a couple reasons that it’s so scary. First of all, Git doesn’t act like a human would, for example. So you say something to Git. You type something into Git. And sometimes, Git doesn’t say anything back. So you type something into the terminal and then Git does a bunch of things behind the scenes, but it doesn’t actually communicate to you what it has done. And let’s say that it does, in some instances, maybe it does communicate that it did something. It doesn’t communicate it in a clear way. You don’t really understand what it’s saying. There’s a lot of jargon. There’s a lot of terms that are really obscure and you’ve never used outside of the world of Git. So it’s just not really user-friendly. I mean, Git was created by Linus Torvalds, and he’s a genius when it comes to technical things, but was not really created in a very user-friendly way. The other thing about Git is that it’s not all visual and that’s one of the things that I really focused on in my course. First, I focused on making things tangible. So all of these concepts or things that are intangible in Git that don’t really exist anywhere, you can’t really touch them or see them, I gave them a physical representation because we’re humans and we learn by seeing things and by touching things. So it’s not very tangible and it’s not very visual. And that’s why I think Git is hard to wrap our minds around. And then also another big thing with Git is that we learn Git, but we sometimes get a false mental model of how it works. So we think we’ve learned Git, but in reality, we haven’t. We haven’t really understood how it works. The perfect example for this is Git branches, so branches.

[00:21:14] SY: Okay.

[00:21:14] AS: A lot of people think that branches seem like tree branches and that’s because even in the GitHub interface or in other interfaces, they often make them seem like, “Oh, look, it’s a branch. It’s branching off.” But actually branches in Git are nothing like tree branches. Branches in Git are just pointers to commits. And you can see this if you go in the .git folder inside the refs folder, inside the heads folder. Each branch has a file. And if you click into that file, all you see is a hash, so a commit hash, and that’s the commit that that branch is pointing to.

[00:21:53] SY: Interesting.

[00:21:54] AS: So I think a lot of people think they’ve learned Git, but really they haven’t understood the real basics, and they don’t have a really, really good foundation. And then once you start trying to do more complex things, if you don’t have a really good foundation, that’s where the cracks start to show in your understanding and in your mental model of how Git works.

[00:22:14] SY: So tell me, why is your course so good? What makes it so different, given that there are so many different ways you could learn Git, there are so many videos, tutorials, blog posts, entire books and Bibles about this topic? Clearly there was something that you were doing that was different, that was powerful that made it so popular. What do you think that was? How did you approach that technical topic in a way that maybe others did not?

[00:22:40] AS: So first, I just want to say that there are so many different ways to learn something and you just need to find the right match. So the way that I’ve taught Git will suit a whole bunch of learners, but there will be other people that just don’t jive with the way that I’m teaching things and for whom my course might not be the right match. Now what I think that I did in my course is I challenged myself and said that I would prefer for someone to tell me that my course is too simple than to say that it’s too complex. So I made my course so simple and slow and very basic to the point that sometimes we’re like, “Okay, it’s a bit too slow.” But I just thought I’d rather people say, “This is too simple and this is going too slowly,” than to comment that they didn’t understand something because I went over it too fast.

[00:23:40] SY: Right.

[00:23:40] AS: And then the other thing that I mentioned before, which is making things tangible, so that .git folder showing that folder to people so that they can actually see things happening or giving things like commits and branches a physical representation with diagrams so that people can see these things and you can start having a mental image of them and build up that mental model. And then also the thing that I mentioned before, which is consistency, making sure that every time I introduce a new term, I introduce it in a consistent way. Every time I open up the terminal and do something in the terminal, I do it in a consistent way. And so you really give that smooth user experience for the learner.

[00:24:30] SY: So tell me a little bit more about how your course is organized and structured. Where do you start? Where are kind of the key components? Go through some of the highlights for us.

[00:24:40] AS: So my course is comprised of six sections. The first one is just getting started. It’s just kind of getting your project directory ready, installing Git, and all of that stuff. Then the second part is about working with the local repository. So in that section, I go over how to make a commit and I do everything really, really in depth. And then I get into branches in the third section, and that’s where I get to debunk that myth about branches being like tree branches, which was really, really fun. And then the fourth section is about merging because obviously when you start working with other people and everyone has their own branch and you need to combine work, merging is one of the biggest things that you need to learn. And then I do have the fifth and the sixth section do include more things about GitHub. So the fifth section is about working with a remote repository. So I go over how to push your repository to GitHub, how to pull changes down or how to fetch changes. And the sixth section is about working with others and about how to resolve merge conflicts. And also I even included a lesson on rebasing. And that was one of the lessons that took the most amount of time to work on and to explain in a visual way. So that’s kind of the outline of the course. And there’s something else that I want to add about the course, which is that in the course, I really thought about each lesson being something that someone had to do.

[00:26:18] SY: Interesting.

[00:26:18] AS: So each lesson is an action that you have to take. It’s something that you will actually have to do in your day to day when you’re using Git, rather than trying to teach Git by topic. So by saying like, “Let’s go over commit today. Let’s go over this term the next lesson.”

[00:26:37] SY: I love that. Yeah.

[00:26:37] AS: It’s actually thinking about how do people actually use Git. Let’s actually tell a story. That’s actually something else, storytelling. The key to learning and to life, maybe that’s too big of a statement, but storytelling is a huge thing, and I use a lot of storytelling in my course.

[00:26:57] SY: So I’m wondering, how did you take the learnings from that course and bring it to your current job as a technical writer?

[00:27:06] AS: That’s a good question. So at the end of the day, when I was creating this course, it was almost like technical writing because when you are planning what you’re going to say in each lesson, you’re basically writing out your script or writing out what you have to say. In the end, I made bullet points, obviously, because otherwise maybe it would sound a bit too dry if I was really reading off a script while recording my lessons. But that was really the first time that I started technical writing was already while I was building my online course. And then after I released the course, I actually wrote a couple of medium articles on my own blog, as well as guest articles on other people’s blogs, where I would write about Git, and I would also include screenshots and visuals in those articles. So there, I got more of an introduction into technical writing. And now I’m just getting to do more and more of it in my current job. And honestly, it’s just the same thing that I was doing before, which is you think about your audience, you think about how you’re going to introduce a technical topic, but in a simple way to someone that may not have come across this technical topic before or in general doesn’t have a huge technical background. For some things like developer documentation, perhaps the people do have a technical background, but then it’s just about communicating clearly and being once again consistent in the way that you’re communicating and communicating things in the most simple way possible. It should not be underestimated that to explain things in a simple way is actually a lot harder than to use a lot of terms and to use a lot of texts, finding ways to say things in a more succinct and clear way can sometimes take more time.

[00:28:58] SY: Can you give me an example of a story or a metaphor that you’ve used either for the Git course or for some other technical writing that you’ve done? I’m kind of curious to hear what that sounds like.

[00:29:08] AS: Yeah. So along with the Git course, now I actually also do Git workshops. So either for companies that have junior developers or technical writers that they want to train or for coding bootcamps that want to do a Git workshop for their students or for the audiences. And in that Git workshop, I actually don’t use code in my lesson. I pretend that I’m someone writing a novel and that I have chapter one, chapter two, chapter three, and chapter four of a novel, and that I need to make changes to the different chapters. So instead of making the workshop more complex with more technical things and code in different really obscure file names sometimes, I make it as approachable as possible and as close to something that people will understand from their life that they can relate to.

[00:30:19] SY: Coming up next, Anna talks about what advice she has for those who want to get into technical writing after this.

[MUSIC BREAK]

[AD]

[00:30:38] Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:30:57] New Relic knows that the planet needs our help. That’s why they’ve partnered up with our team at DEV to host Hack the Planet. From now through February 28th, you can take advantage of their free tools to build a climate change monitoring app with the power of software observability. It’s a great chance to win cash, community bragging rights, swag from New Relic and DEV, a tree planted in your name, and other prizes, too. Learn more about the Hack the Planet Contest on New Relic’s dedicated community hub, therelicans.com. The Relicans is your place to connect with other developers. Meet the team behind New Relic’s software monitoring platform and show off the app you built for Hack the Planet. That’s therelicans.com. Happy coding.

[AD ENDS]

[00:31:47] SY: So when I think about technical writing, the other job that kind of comes to mind that comes up for me is developer advocacy and that kind of category because I know that writing and content creation is a big part of that role. And I’m wondering, do you see similarities between those two roles and I’m wondering kind of how you compare and contrast them.

[00:32:09] AS: Yeah. So that’s a really interesting point that you made there. So recently, now that I’ve gotten into the world of technical writing, I actually came across a YouTuber called Amruta Ranade, who is a technical writer, and she does a lot of YouTube videos about how to be a technical writer and a lot of great content. And she just recently moved from a career in technical writing into a career of developer advocacy. So I think that there is a lot of overlap between the two and I guess both of them are related to developer experience or a DX for short. So I think, yeah, they’re very much related. I don’t know if I’ll ever end up going down that route. All I know about my journey is that it is unpredictable and also just a bit random sometimes, but I think the two are very, very related.

[00:33:05] SY: What topics do you get to write about these days?

[00:33:08] AS: So at the moment, I just work on the Mambu product. So Mambu is a fintech company and I’m just working on the API documentation and the support documentation.

[00:33:20] SY: So I know that some people might hear the words technical writing and think that it’s maybe not the most exciting tech job that you could get. And so I wanted to kind of hear a little bit more about your experiences. What do you like about it? Maybe what you don’t like about it? What does it like for you?

[00:33:37] AS: You know what? That’s really funny. And I think it’s true. I mean, so many people would hear, “Oh my God! You write documentation.” And they’d be like, “That’s the thing I hate most about being a coder.”

[00:33:46] SY: Right. Right.

[00:33:47] AS: “I hate documentation.” So what I have to say about that is I’ve always been someone that’s been into organization. I mean, I hope this doesn’t sound too nerdy, but basically I was voted as Most Organized in high school.

[00:34:00] SY: Nice! Good for you. I love that.

[00:34:02] AS: Yeah. And even back then, I remember I studied really hard. I was a really, really good student, let’s say. And I remember I would create these massive study packs in order to prepare for my exams. And I would really enjoy just organizing all the information and preparing the study packs so that I would be able to study more efficiently and understand all the information in a nice way, and I would create diagrams. So I think I’ve always enjoyed the idea of how do you organize information in order to present it in a user-friendly way. These study packs would be something that my fellow students or my brother would ask to borrow because they were like, “Okay, this is so much easier to study from than the textbook or than other class materials that we’d been provided with.” So I do think that technical writing is something that is going to suit some people and it’s not going to suit others. I personally love anything related to communication, anything related to empathy and to thinking about things from another person’s point of view and thinking about how you can present something in a user-friendly way. I really enjoy that. I also really enjoy organization and looking at how we can present things in a consistent way. So I think it just suits me and what I like. But I definitely think that there’s people out there that would maybe not enjoy it at all and that would really struggle with it. So I think the nice thing about the tech space and about any space is that you can figure out how you fit into it and what suits you most and what your strengths are and what you’re going to enjoy most. There’s not just one option. I never thought I’d get into technical writing. It just kind of happened. And I’m glad it did, but you enter the tech space thinking one thing and then you end up maybe doing something different. But I do have to say that gaining technical skills opens up a lot of doors and a lot of opportunities.

[00:36:02] SY: So tell me about the skills you need to be a good technical writer. What are some of those?

[00:36:08] AS: I think some of the skills that you need are good communication skills, good organization skills, and communication skills, not just in terms of knowing how to write things in a simple way, but also collaboration, like communicating with developers or with product managers or with people in the company that have domain knowledge or that know about the topic that you need to write about. Because most likely you’re not going to know everything that you’re writing about. You’re going to have to learn new things or learn about new features. And in order to do that, you’re going to have to talk to people and you’re going to have to collaborate with other people. So having communication skills, having soft skills, being comfortable to reach out to people in the company that you may have never spoken to and being curious, being able to come up with different questions and to think about, “Okay, but what would the user not understand or what would be the questions that would come into the user’s mind when they’re reading through this?” So I think curiosity is definitely another one of them. I guess that’s sort of like the journalist’s curiosity. You have to ask a lot of questions and really get to the bottom of a topic and to really understand it in order to then communicate it to others.

[00:37:27] SY: So what advice do you have for people who might want to get into technical writing?

[00:37:31] AS: Honestly, one of the things that I always recommend to people is if you’re interested in something, anything, just get in touch with people and connect with people. That has always been my approach. I’ll just send messages on LinkedIn and connect with people and just say, “Hey, I’m interested in this. I can see that you work in this or that you have experience in this. Can we grab a call? Can we chat? Can I ask you some questions?” I guess they call it networking. I just call it connecting or speaking to people. I think that would be one of the best things to do, because that will also give you an impression of whether you want to get into technical writing in the first place. Ask the people what their jobs are like and what they enjoy about them, what they don’t enjoy about them. And through that, by connecting with people, you might end up opening up some opportunities. Other than that, just get started. Maybe you don’t end up starting off as a technical writer from the beginning, but just entering this tech space, getting your first tech job, learning the tech language. One of the things that I discovered when I was working as a developer was that I just learned a whole new vocabulary, a whole new world, a whole new language. Just like in the business world, there’s like business speak. In the tech world, there is tech speak. And once you enter the tech world, you learn about all these things like Scrum and Agile and products and features and how a company, how a tech company works, and all of that will inform any job you end up doing in tech and will help you if you end up wanting to become a technical writer, because you’ll understand how software is developed, how a tech company works, all the different departments that it’s comprised of. It’s a whole new landscape, and I really realized that whenever I talked to someone that’s never worked in tech. I realized just how much of a little bubble the world of it of its own that it is.

[00:39:31] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Anna, are you ready to fill in the blanks?

[00:39:38] AS: Yes.

[00:39:39] SY: Number one, worst advice I’ve ever received is?

[00:39:42] AS: I think for me any advice that is absolute. I think that the world is a complex place. And if someone gives you advice that is really absolute, they’ve just not thought about all the nuances and the specific situations that it might not apply to.

[00:39:59] SY: Number two, best advice I’ve ever received is?

[00:40:03] AS: It’s related to the previous one. I hope that’s not cheating, but basically any advice that is nuanced and that takes into account the complexity of the world.

[00:40:14] SY: Number three, my first coding project was about?

[00:40:17] AS: It was a travel app with cities and different activities that you could do in those cities.

[00:40:23] SY: Number four, one thing I wish I knew when I first started to code is?

[00:40:27] AS: A big part of it is just about facing your fear of the unknown.

[00:40:32] SY: I love that. Well, thank you again so much for joining us, Anna.

[00:40:35] AS: Thank you so much for having m

[00:40:43] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.