#189 Rich Haines went from screenplays to technical writing
⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes
Rich Haines 0:00
I mean, I think a lot of developers do care about, you know, how the code they're writing is used and like, you know, the end product and our people use it. It's not just all about writing code and making it really as small as possible and whatnot. You know, you want people to use it. And I think people, developers that do write documentation, I think they do. Absolutely. I mean, I'm one of them. But I think it all depends on your organizational structure and how the company you work at how they, as a whole view these things, as you alluded to earlier, I think there are probably a lot more companies in the world that do take documentation seriously. And but I think they're viewing it as a part of the product. So as its own product within the organization is, you know, it's an important step.
Tim Bourguignon 0:44
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode 189, receive rich hate. Rich is a software developer and technical writer. He's into JAMstack, front end development and documentation, and away from computers. He loves watching his favorite football team. And since we're both from the EU, we're talking about real football here. Also playing guitar and listening to music rich Welcome to their journey.
Rich Haines 1:21
Hello, thank you for having me. My pleasure.
Tim Bourguignon 1:23
But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guests. Suraj. As you know, the show exists to help listeners understand what your story look like and imagine how to shape their own future. So as is usual on the show, let's go back to your beginnings. Where would you place the start of your journey?
Rich Haines 2:14
Yeah, that's a tough one. When people normally ask me that question. I normally normally begin like, before I started learning about coding. But I think in this instance, I'll roll all the way back. Because when I was actually thinking about this, this question, it reminded me of like, I thought that I first started playing about with computers when I started to learn how to code but in actual fact, when I think back my I'm not sure it was my mom and my dad, but my parents they had like an old Amstrad or comment, there wasn't a Commodore short as an Amstrad. And it came with this book, and it was like this book, and it was about or you can't see because you're listening, but maybe say, like this, the length of a head thick. And it was like for programming, a Lord of the Rings game. And so what you would do is you'd like, I mean, I can't for the life of me remember the language or what it was, but I remember attempting to follow along with this thing. And then you had the actual game that you can play us. And I remember playing on that. And it was just a green pixelated screen. And it was like super cool. And I love that. That's like my first memory of actually having some kind of interest in a computer or kind of like what it does. I think like from them, were begging my mom to buy me a laptop or laptop or desktop computer. And she made me research it because whenever I wanted something, she would always say, Okay, well, I want you to make sure you're gonna get the right thing here. I want you to go out and I want you to research why we should get it why we should spend this money what's so great about this, you know, and then present your case to me. So I ended up doing some research found this Windows Desktop and actually got it and I think literally within a month I'd broken it because I was just fiddling about with it, going into the settings trying to find things that buy us and changing things around. And you know, I think even at the time I wasn't really thinking like I know what I'm doing I was more of just exploring it and seeing how it worked. And that was like a general pattern throughout my childhood was like I would get presents and I would just destroy them and then just like like watches I would always just take apart a watch. What are you doing? Like I just bought you this watch so they just stopped by the watches. And that was until I got like a Casio because I couldn't take that apart because digital so it's kind of weird. But yes, I had this this. I was always interested in this kind of thing like how things work. And I liked computers when I was younger, but I didn't really do anything with it. When I was young. It was never like something that I decided that I wanted to work with computers or anything. So I mean, if I was going to jump forward a little bit I went to when I went to college, I studied film and drama. And then after that I went to university to study film, and I majored in script writing at university and that was I like really love like the creative kind of do creative stuff basically is like always something that I've loved doing. I like drawing I'm not very good, but I like it. My wife's amazing at drawing my kids really Good drawings, it's nice to see. But from my side like it's having that creative outlet and being able to express yourself in some way. And like when I was studying filming, I always found like, I found it really fun. The course was really fun. And it was really, that was fun learning about how you create a scene and all these different things, cinematography, and that but more I was more drawn to the writing side of it, because I felt that I could express myself a little bit more that I'm not sure why it's just how the cookie crumbles. So anyway, I graduated from university, I lived in London, and I met my wife in London. She's Swedish. And we were living together and after I graduated living in London Film wanting to get intermediate in that, but it was quite hard. I had a friend who was a a cameraman, and he ended up doing a lot of free gigs, unpaid work for a really long time. And that wasn't something that I could really do. So I was working in restaurants and things. And then me and my wife decided to have a child and we were living in like shared accommodation. So we decided to I was like, Well, I haven't really got anything going in London workwise. Let's give it a go. Let's move to Sweden. This was like 11 years ago, this was 2009. We made the decision. We moved in 2010. So I moved to Sweden and I was back to square one. I couldn't talk the language. We moved to a city that's like in the north of the country, beautiful countryside, but small kind of industrial ice hockey See, so I ended up getting a job as a scaffolder. And that was through my wife's my wife's father had some contacts. And so I had to like because I didn't actually get a job where we live, they had to get a job in Stockholm. So this is like a six hour drive. So as soon as we moved to Sweden, and I had to go live in Stockholm with my wife, Santi and I'd come back at the weekends to see her or was pregnant at the time kind of thing. So it was pretty hard. And I did that for like, I think there's like eight months I was doing nearly the whole of the pregnancy, to be honest. And then I've mentioned I've got a scaffolding job in Veeck where we live and it but yeah, I was working in scaffolder here in Novi can, you know, it was okay. But it wasn't I didn't have that creative outlet. I didn't have that thing. But I needed to have that thing in my life that creativity. So my wife actually saw, of course, this must have been in about 2012 13. Maybe she saw a course like a local adult education course for C sharp dotnet. And I She suggested to me, it's like, why don't you look into this? You love computers? It's like, Well, her version of me loving computers is I play computer games. So it was really the same thing. So I didn't I didn't have these kinds of memories about that when I was younger, and I had this Amstrad and all that kind of stuff that wasn't really floating in my mind that maybe deep down I do like computers. But so I was like, No, I think it'd be too hard. It's probably loads of maths. And, you know, I'm not gonna be very good at it, I'm not gonna do it. So I put it to one side. And instead, I decided to start my own business on the side of doing scaffolding. So I was we were looking at ideas. And we wanted to wanted to do like, like design our own children, because we had children, designer and children's clothing, like organic clothing, but the like putting all that together and like sourcing and all that was very expensive. So I took it down a notch. And I started researching what's trendy Google Trends, all this kind of stuff. I found like wooden sunglasses. So I try and keep this a little bit long story short, because I could talk forever about this. But because this is like a big part of my life, this but there's just like, so I basically researched how we could even start this business. And I ended up getting in contact with a company in China, who would manufacture these glasses for us. So what we would do, we would sit me and my wife would sit and draw these glasses on paper, pen and paper, pencil and paper measure the millimeters that the frame style we would want, I would choose the words I would send these to the manufacturer, they were sent over, you know, whatever, blah, blah, blah. During this process of contract designing our first and like collection, I started looking into websites and how you can make a website and I hadn't done any coding before, you know. So this was like my first kind of an entry point into how, you know, that kind of world of websites web development, this kind of stuff and my initial thoughts were that I can't learn how to do this because I have to do all this other stuff. It's a whole nother thing. So I looked at Shopify because it's like this whole all in one solution. So I picked the theme started playing about with it there had to make some customizations had to go a little bit in the code had to look up how to change a color and that but essentially I was keeping it straight up entrepreneur makes a site via Shopify, so yeah, this went on for a couple of years and it went alright, you know, we were selling glasses on in shops here in Urvi. In Stockholm, we had them in a shop some other places online was setting our goal and we were doing okay, but we weren't bringing in enough money to turn over for marketing and also the time cost on the family life. For marketing a company on the side is difficult. So I decided to sell the company and I managed to sell it. I made a little bit of money off it so that was quite nice. But I forgot to mention during this process I raised did a Kickstarter campaign because of the marketing thing and I couldn't raise enough money. And I put it all together and I had to research how to do Kickstarter and all this kind of stuff and they felt dead. On, it's a slight it, nobody did anything, nobody bought anything. So I tried to learn, look, step back a little bit and learn about why and how it went wrong. And it was all to do with my copy how I was presenting myself, the company, the message, the pictures, we have professional pictures and all of that. But people resonate with like the realness not like a brand you're trying to create, they want to see the fact that this is a family business, they want to see a picture of me and my wife, they want to hear why we've done it. And when I changed this copier, and I launched it again, I'd launched it again, like three months later or something, I think it was like, over 260 or 240% funded. So it was like over a double percent funded and we got enough money so that we could do a new collection. And that was like quite a proud moment because it was like we went from nothing. And then suddenly we had it and we could keep on going. But in the end, I ended up selling it because the marketing and this kind of stuff, made a little bit of money on it. But then I was back to square one. And I didn't have that creative outlet anymore. You know, I didn't have that thing that I could do on the side. So this was 2015. And yeah, my wife suggested this course again. So I was like, Okay, right. Let's have a little look at it.
Rich Haines 11:11
Tim Bourguignon 17:52
Stay with us. We'll be right back.
Tim Bourguignon 17:54
Hello imposters. If you work in tech want to work in tech or our tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers, and the journeys we all take throughout our lives as the designers, builders, fixers investigators, explainers and protectors of the world's technology. We call it the imposter syndrome network. And all are welcome. So find the impostor syndrome network podcast, wherever you listen to find podcasts, and look for the isn community on your favorite social platform. Hashtag impostor network.
Tim Bourguignon 18:37
Maybe one question there? How did you picture this world of software development? You hinted at it a little bit with the web site design. But how did you picture it before? versus what you realize it is afterwards? How this is this description? Is there?
Rich Haines 18:52
Yeah, I mean, when before I actually started working in the industry, my view was a bit difficult to describe, but I don't want to use the word magical. But that's there may be a bit of a bad term to use. But like, I thought it was very cool. And I thought that I was picturing this is kind of a you know, honest thing to say, if I was pitching people in cafes, and like working there, just like just coding away and stuff. And I didn't picture all this kind of infrastructure and like teams, and all these different things, and how a company and an organization actually works to make the software. You know, in my mind, maybe I'd seen someone or TV or, you know, these people coding the hacker man and all this kind of stuff, or like, you know, things we do in the course, where we're working together. But you'd think that in the real world, it's not going to be like this, I just got to work at a company. I sit at my desk and I write some code. But then I want to say the harsh truth and the harsh reality because it was harsh, you know, you get in front at the deep end and you have to learn learn on the job a lot of the time, like how to fit in and I don't mean like socially fit in I mean, like fit in your role to like know, what you're supposed to be doing and how you're supposed to be doing these things. And a lot of times, you know, I can't I remember that my onboarding was that great. I had a really good mentor, this other developer who'd been working really long time with web dev, and stuff. And he was always like there for me and coming over and making sure that I was getting on with things and everything was okay. But I think an important part of how that whole process was, they were letting me get on with it. And given me tasks and important tasks, not just like some backlog item that's been sitting there for six months, they've given me something important to do, so that we could ship it. And so I could have that feeling of like, oh, yeah, I shipped something in my first week, you know, and that feels really good. And then that gives you confidence. And then you think, Oh, maybe I do know what I'm doing. And then they give you something a little bit more important. And then you get to work on a team project. And then you have some input, and then people are listening to you. And then it's like, oh, shit, I'm really sorry. I'm really doing this, like, you know, yeah, I guess that's when the confidence kind of grows. And that's when I became the scrum master. Because when I get comfortable, I'm quite a vocal, confident person, I talk a lot. And I think that kind of came across a lot. And, you know, being the scrum master and having to do that kind of responsibility and stuff that kind of that that was a good fit. So yeah, awesome. But yeah, I
Tim Bourguignon 21:05
haven't your LinkedIn profile is open. And I'm very interested in the next sign in exchange in your profile. So after clever stir, you change company, first, I would love to know why. And then I'm not spoiling it. So you made a change in career again. And so I'd love to see to hear about that.
Rich Haines 21:22
Yeah, so. So I was looking at a cluster. And so during this period of working at clovers, I was learning we were working with React and TypeScript. So that was our stack. But we had like this custom made like React thing it was we weren't using any framework specific thing. It was just the library, react and all this, like web pack stuff, and whatnot. And I was getting a little bit bored with the work. I mean, I still enjoyed working for the company, I enjoyed what I did. But I was I started doing a lot more coding in my free time outside of work. And trying out things, experimenting with things that I thought were cool, like in the front end, in the front end kind of space. And it was around about that time that I created my own website. And I started to try and blog about the things that I was like, you know, learning and this wasn't like some attempt to teach other developers about stuff, because I know so much, this was purely about, like, the more you do something, the easier it is to learn it and then writing down and sharing them experiences, it's like, it benefits you it benefits me it better, you know, it goes around, that was the reason for me started doing it. And I found that I really enjoyed it. And it got me back into writing as well. And the thing about like blogging, and I still have this now, even though I still do it is that trying to find your voice is like super hard. And you find that you that were technical writing, and especially blogging with blogging, you technical, right, and you can have like a personality, your own voice, if you're working for a company, maybe they have their own voice and personality or tone. And these kinds of things are ways that you should write. And this was something I was like, fumbling about with at the time, and I really enjoyed it. And then I started to reach out to different companies that were doing that would like pay you to do this. So I was like, I really enjoyed doing this, I'm playing about something I'm writing about it. But then this person is going to pay me to do that instead, why not, you know, get some extra money, do some something I'm enjoying. So I ended up doing that for like, I don't know, two years, I'm not even sure how long, efficiently I still do it. But I haven't done it for a while. But yeah, so I reached out to a few companies and I started doing some like paid technical writing work. And it was like it was really, really, you basically get a brief, a lot of times you would get a brief from the company, they'd have a list of subjects that they want to cover within their field. So if it's like a graph, QL company or if it's like a company that deals with a lot of the articles will be based around that. Or if they're like a CMS, it will be integrations with that CMS with different frameworks and how to do that. So essentially, it was like, look rich, can you go home? And can you go and play about with this thing? Have some fun, right about it, give it back to us, we'll give you some money. And I'll say yes, I can definitely do this. This sounds amazing. So I had loads of fun doing it. And I built up like a body of work. And over time, you know, I built up more and more, I enjoyed it more and more. And then I just saw someone tweet out like this message about I think it was Jason lengstorf That did a tweet. That was like a retweet of someone from Prisma saying that they were looking for a technical writer. And I wasn't like looking for another job. But I thought, well, you know what, this could be a nice little little change of direction. And at the time, it wasn't like that's what I want to do in my career. It was more about like, I'm enjoying this direction. So let's follow that. Let's go with that. It wasn't like reaching for some goal. It was an organic kind of thing. So yeah, then I started working at Prisma. And that was awesome. You know, I was doing technical writing for a living as professionally kind of thing and also doing the blogging getting paid on the side. And we're doing that but that was like a whole new it's a whole new world working as a technical writer as opposed to a software developer a lot of the times I mean it obviously works differently for every company, but a lot of the times you don't have the same processes in place, you don't generally work within Sprint's a bit more async a bit more dynamic, you have to be a bit more flexible with staff, you know, when content needs to be delivered, changed or updated. So yeah, that was a really big learning experience as well. And then I got, then I got another opportunity. So I got, I wasn't looking for work at all. I mean, I was just, I was happy At PRISMA. And then I got approached about a potential opportunity at WsL. So this was like, you know, in the summer, and in the summer, last year, I should say, and yeah, so they I got approached about a potential role there, which I thought, would I initially, I was a little bit reluctant, because I was a bit worried that maybe it's not, maybe it maybe I can't do it, I had the fear of maybe, you know, maybe this isn't for me, maybe, you know, I'm not qualified enough. I don't have enough experience, I can't do this thing. But I was encouraged to apply anyway. And I ended up getting the job. And I'm very thankful that I did, because what I found is that the parts of the elements of the job that I was scared about are the elements that I'm enjoying them. And it's going back to that whole kind of process of learning something new and current kind of really diving into that thing head head on, and facing them fears kind of thing, and then finding out Oh, shit, this isn't actually that bad. I can do this thing. You know. And it's exactly the same thing. When I was starting out and did that adult education course, you know, it was that fear that I can't do this thing. When I think a lot of the times, and I've been speaking to my wife about this recently, as well, a lot of the times, it's like, you just got to face that fear, and then just go for that thing. And the worst thing that can happen is it doesn't work or you don't get it. But that's it. Like literally that's it, then you just go again. And it's like, as soon as you can make that switch in your head and have the confidence to do it, then so many more doors will open up like for yourself and in your career. Because it's like, it's easy to say no to things because you're scared. But then if you start saying yes, and just trying it out. It didn't work. That's cool. I go back or it did work and superduper cool. Now you're doing something you enjoy, and it's really cool and fun. So yeah, that's where I'm at now working on the docks at WsL. I'm loving it. It's brilliant. So that's called a round trip. Yes.
Tim Bourguignon 27:13
And that's a very nice round trip. Start starting with screenwriting and then ending back to screenwriting for another kind of movie. Yeah, exactly. I like to ask you one question about you your would you say you said some parts of the your new role. You were scared off? How did you approach those parts? Once you had the job?
Rich Haines 27:35
I think when I guess it's the same in any industry, but I can only really talk for the tech industry, because that's where I'm at. And where I've been at for a while is that no matter what job you're doing, if you're new to a role, whether that's as a software developer, management, tech writer, whatever, you've got to ask questions, you're not going to be afraid to put yourself out there. And people always say that I don't want to feel or sound stupid. But you know, the old saying goes, there are no stupid questions. And it's true, you know, you don't learn unless you ask. And so I think just asking a lot of questions, and but be mindful that you're not bugging people, you know, I mean, you have to do a bit of research yourself and then ask the question, but for me personally, it's been the more the more management aspect of the role, and the more kind of like looking at documentation as a product, because that's something that's how I feel documentation should be viewed. And that's how WsL views it as well. That's something that drew me to the role. Whereas a lot of times documentation is viewed as an afterthought. In a company, it's something that you work on the end, or it's something that I, we've written a feature, we've got this whole thing, we're going to launch, oh, maybe we need to write documentation because people need to know how to use it. But I think people are taking it a lot more seriously. Nowadays, I think it's almost dare I say, a little bit trendy to be in documentation. Now. You know, it's like, see people talking about it all the time. But that could also be because the people I surround myself with so if I was my bubble, but hey, we live in my bubble. I like that bubble with the treaded docks. So yeah, so but yeah, like I say, it's more of the same. Seeing documentation as a product. What does that mean? Like? How does that work? How would you manage documentation as a product? What are the processes there? These kinds of things that I was initially fearful of, but now I'm really enjoying doing and working on was these
Tim Bourguignon 29:20
documentation as a product already a thing when you started away really something that there was coin and adverse shell wanted to go in? Or is it something in in in the I want to say documentation industry? That's really the right term? Is it? Is there some documentation on this? There are people talking about it and how to do that. So the best way? I'm not sure.
Rich Haines 29:39
You know, I don't think I wouldn't say Versaille coined the term whatsoever at all. I don't think it's like that. I think it's more of taking it in terms of where you place documentation within the organization. So you know, documentation should live close to where the product is, and the products are because it shouldn't. I'm going back to this term afterthought again because it It should be close to what you're doing and what you're creating, because it's a part of it, you know, it's an extension of it, you know, you have a product, you have to document how to use it. That's how I see it. And I in terms of like, inflammation and around that there are communities, which I'm even just now starting to join and, you know, find out about these kinds of documentation and technical writer communities where, you know, people have been talking about this for years. But I think that unless you're in that bubble, then you're not aware, you're not savvy to it. So it can be easy to view it from the outside in and seeing like, oh, is this new thing, or what, you know, are people now taking documentation seriously, when in actual fact, I think people that are doing the documentation have always been taking it seriously. And they've probably been pushing for it to be more of a central thing in organizations. But I think now maybe people are loosening up to the idea and actually seeing that, yeah, is actually superduper important. And maybe that's why a lot more organizations are taking this approach to,
Tim Bourguignon 30:56
okay, I'm trying to picture it, how it would look like since the best the best processes organizations I've experienced so far raise the documentation really, as a first class citizen in one of the things the engineering or product and engineering teams do. It's one of the one of the checkboxes on the definition for done. And really, there is a sit on the table, right from the get go when we're shaping and discovering what we need to do for somebody to think about documentation all the way till until the end, when we release some code, and we have to have some documentation on the sides. And it is only done, when we have completed with what to do and documented, what words to be used, how it's to be installed, how to etc. Is this what you mean? Or do you mean something else?
Rich Haines 31:41
No, I mean, this, that's the kind of process I'm talking about when you describe it, like that's exactly how it should be in a lot of places. And I'm not saying that I have direct kind of like knowledge of lots of different places that don't respect documentation and use it as an afterthought. I'm more generalizing and things that I've heard and how people approach it. And how I've heard other people discuss it is in this way, and I don't I haven't heard. So. I mean, a lot of the times you will have people write in a feature, and they will write the documentation as well. It wasn't where I hasn't been where I've worked before. But you know, there's a lot of companies in the world, I just mean more given documentation, rather than having it on the level where, say, the developers are writing it, and they're writing it as part of the feature. And then you know, then you're shipping it in definition that includes is the documentation done, that's great. And that should still exist, because that's where the knowledge is. But also, there's so much more to documentation nowadays, or maybe there always has been, I don't know. But like, you know, this is like a whole arm of how people interact with your organization and the product that you create, you know, you can have it as a process and you can put stuff out. And it could be something someone can read to understand how to use an API or how to use a certain part of a product. But there should be also so many more things. So much more thought goes into like a documentation site in terms of how you're navigating it, how you're guiding a developer through, you know, their entry point into the docks, how do they find the information they're going to need? Where is that information? Is everything structured correctly, so they can find the correct information, you know, different entry points to like finding something, someone will come from Google directly searches something, someone will go to the landing page of your website, and then use your internal navigation to find exactly where. So it's these kind of processes? Well, I'm talking about how to, and treating documentation as its own product. You know, you have the UI, thinking about this whole UI, the UX, how people are using it, how have things laid out the structural content, this kind of stuff. Okay,
Tim Bourguignon 33:39
I can't remember which product it was, I think it's air table. I'm not sure when you went into their their documentation, it was really interactive, and all your requests are tokens were added to the documentation. So when you weren't copying the snippets, it was already tailored for your account. And you're really, and that was really thoughtful, that was really something that went one step ahead for the people using your product to really be successful in in in using it and not having to swap out tokens and secrets, etc. In hindsight, and that's what I'm picturing. When I hear you talk about about a product. It's not just documenting it thinking how people are going to interact with this and how this is going to impact the experience the users are going to have with the software afterwards. Is that it?
Rich Haines 34:24
Exactly. I'm not nodding vigorously. Yes. Yeah, that's exactly it. That's the beautiful kind of user experience, isn't it? It's including people and including what they need to know while they're within the context of what they're using. I think Stripe does that as well. Actually. Everyone's like, well, Stripe docs are amazing. They are amazing, but I think they include information about you know, I haven't looked at it for a while but I'm pretty sure they do something similar like you've got an API key or you've got like some kind of endpoint then include custom information for where you're at. Yeah, interactivity with Doc's is like number one. On his net, that's how, you know, you want to freshen up a static page, you want to bring it to life, you want to keep people involved people, you know, we know when we read things, we're lazy, we skim stuff, we just want to get to the point and get the information. And there is a place for like long format, conceptual information in Docs, absolutely, you do need that information, people do want to read the house, and the why isn't that but a lot of the time, I'm going to make up a percentage here, I would say 80% of the time, you know, when someone's going to the doctor, they just want to go there, they want to get the information, they want to know what to do learn from it, and then go and use it and get on with what they're doing. You know, it's rare that people will just sit and read everything. So I think having that being like focused and concise and having interactivity and enabling people to like, code snippets and little code examples to fit that I really like that G SAP have this, you know, G sap the Navigate navigation animation library. I'm not sure I remember that. Okay, but they've they like that it's an animation library. But they have this really nice like interactive thing on their page where you can basically you choose, you push some buttons, and it does some things like these bouncy balls, and that but then you can that actually changes the props in this code snippet below. And then you can basically choose and you get to see how this code will render and how it will look and work. And then you get to just paste that code. And that kind of interactivity is like super duper important. I think, you know, it's not for every part of the doc, you know, but for certain elements, rather than just having like a static page where you're trying to explain all the time, you know, you're trying to use your words to explain how, why this works, people just want to kind of depending on what it is, but want to see how it works, and then take that knowledge and then go and use it. So yeah, it's tricky. It's tricky with doctrine. It's not just like writing about how everything works, there's so much more to it, there's so much more things to think about when you're trying to think about who's consuming that stuff, who's consuming the doctor you're writing. It becomes you know more about, you know, caring about how you're putting it together, you know, how is someone going to consume the content? So
Tim Bourguignon 37:07
I have a two fold question now as to both and then we'll see how you attack it. The first one is, so we spoke about text, we thought about code snippets, I'm sure there is more than most of the video will not be hold audio, there must be static and static images, and maybe GIFs and animated stuff, et cetera, et cetera. How do you navigate all this? And balancing all this with the first part of the question? And then the second part, which goes with it is how would you verify that this is indeed indeed working for your users, for you, the users of this documentation?
Rich Haines 37:37
So to your first part, do you mean like, how do you decide what to use in terms of all and different things? So I don't know. I mean, there's, I guess there's lots of different thoughts on this, my personal thought would be to keep keep it to a minimum. And when I say like, everything, you know, interactivity, and the Docs is great, and it is really great. But at the same time, you don't, I don't personally want to see when I'm looking at documentation, loads of stuff that I can click and move about and do things with and you know, can get very confusing and overwhelming, but another element would be video is great. And docs, people consume knowledge in different ways, or they enjoy consuming knowledge in different ways. So given them that service or offering that to them, so they can consume it in a different ways. Great. You also have to worry about kind of maintenance burden and making sure you can keep that up to date if you can. That's super cool. That's a great stretch your boat. And then what's your second question? What was the second part?
Tim Bourguignon 38:32
Then? How will you make sure that this is in what what we envisioned? Yeah, works with a user's? Yeah, okay.
Rich Haines 38:39
Yeah, totally. Yeah, well, I guess, you know, different ways of doing that. I mean, essentially, you want to be getting people to test it out and use it, but you want to do some user testing and see like, A B testing, you do prefer this? Or do you prefer this? I mean, that's like a super simplified way of seeing if something works, I guess, you know, slowly iterating on things and implementing things one after another, rather than a big shebang is also another way of going about things like you do change. You see the feedback, I think, you know, you can gauge a lot of feedback via like analytical feedback via Google and these kinds of things like click through or a page views, but you also need to get that. What's the wording here? I'm looking for like, it's like quantitative and qualitative, probably. Yeah. But like actually talking to people and getting that feedback when I first joined for so I did like this round of interviews with people with developers to just get a like a gauge of where people are at with documentation, what are their thoughts on it, and just real life experiences, as opposed to just some stats on a page and some metrics and it's something that you know, I want to continue doing and it's something that's a good way for me to gauge are we doing well in what we're trying to do is the vision we're putting forward does it match how people are using the docs? Because I think it's very easy to sit and think that oh, yeah, we should add this. We should add this. It's going to be amazing. It's going to Cool, but if people don't use it, and there's just, you know, oh, yeah, looks great, but I just want to get this bit of information that you've hidden down here. So can you elevate that information, please? Perhaps, you know, getting that kind of feedback, mouth to mouth kind of thing. Feedback is a lot more valuable. Yeah. So I think it's, I think it's twofold. You know, you can look at metrics, but at the end of the day, you've also got to talk to people, just to gauge if things are working or not, but you know, you shouldn't be afraid to make them changes. You've got to ship it, you know? Absolutely. Yeah.
Tim Bourguignon 40:29
But that's the most crucial point. I think, as long as we're we're just winging the documentation and just doing it because we have to do it and just as a, something we just do, then we don't care about all this. We don't care about is it adopted? Are people using it? Is this the best way for people to learn, but as soon as you move this into the realm of this is a product that if you have to drive it, like product management with exactly user research, observing people interacting with them, asking them questions, doing a B, testing all the things you said, and it's a whole different beast, but it's a
Rich Haines 41:06
fun piece. Yeah, it becomes it becomes an educational kind of map doesn't it? It's like, you know, you go from this thing, like you say, where you just adding things, oh, we've done this, that show them how it works to like, let's try and help people learn and learn in certain ways. And you know, how can we best focus that learning? So they are actually learning something is?
Tim Bourguignon 41:26
Absolutely. Have you had one or two really key successes in your time? I've ourselves already segmenting this idea. Yes, we're investing in this but as well, I'm
Rich Haines 41:37
not sure. Yeah. I'm hopeful.
Tim Bourguignon 41:41
But by the time the upheaval they are, I'm sure you will. Yeah, exactly,
Rich Haines 41:44
exactly. We'll say I'll swing back around by the time this goes out. Okay. I hope so.
Tim Bourguignon 41:51
I hope so as well. So what would be the one advice you would give developers who are maybe still seeing this documentation as this thing, they have to do the one advice to to maybe change their mindset, get into this, maybe understand that this is a chance for the company to raise the bar for their products cetera? What would be the kind of advice you would give them to step up into this?
Rich Haines 42:14
Wow, that's a good question. I think, besides mindset, I mean, I think a lot of developers do care about, you know, how the code they're writing is used, and like, you know, the end product and our people use it. It's not just all about writing code and making it really as small as possible and whatnot, you know, you want people to use it. And I think people developers that do write documentation, I think they do. Absolutely. I mean, I'm one of them. But I think it all depends on your organizational structure, and how the company work at how they, as a whole view these things. As you alluded to earlier, I think there are probably a lot more companies in the world that do take documentation seriously. And but I think the viewing it as a part of the product or as its own product within the organization is, you know, it's an important step, because it opens up so many more doors, I'm not sure I really have great advice for making the stakeholders and the people in charge know or think about it things insert in that in that kind of way. I guess the only thing I would say would be to look for other companies that do take documentation in this role in this way. And to point to it and say, in much the same way that you would say, oh, X companies using this framework and their bundle size has gone down this much. There's pages of this faster, should we be using that as well, maybe, you know, in the same way, you could be saying that, okay, this company's documentation is super good. I've learned loads from it, look, how they're structuring things. Look how they're doing it this way, or that way compared to ours, where we're not thinking about them things. Do you think this is something that we can implement as well? And then see how that floats. But that would be my only advice. I guess.
Tim Bourguignon 43:50
We're good enough. So I don't know good place to start. And then we mentioned striped, we mention air table, I'm going to look at that and put it in the show notes if it's really irritable or something else. And you mentioned G SAP. Yeah, we need to find out their documentation as well as an example. And you mentioned a community you were starting to join communities around this. You want to give them a shout out.
Rich Haines 44:10
Yeah, I mean, if I could just roll back a little bit just super quick. So like when I started blogging and stuff, and I was like posting on Twitter, I didn't have a big I still don't have a big following, but I didn't especially then. And I found this discord community called party Corgi network. And this is like, I don't know if you've heard of them. But then yeah, a community of content creators and I was invited to join and like super duper helpful kind inclusive lovely people were like pushing you to not just write it but ship it that's almost like the messages like you know, don't sit on your blog posts don't think it's going to be perfect ship it get out there gain confidence keep on writing and that I mean, I'm still remember there but I'm not very active. I don't really look at this code that much anymore, but like they were like super helpful. That group But I think the message that I'm trying to say is to find a group where you can like feel that you're that being supportive or supported and support other people. And it really helps you grow not just being a developer but a writer as well. I think it gives you that confidence to think like, Oh, my work is actually Alright, maybe I should keep on doing maybe I should keep pushing this so yeah, and there's other discord communities as well like right that slack or discord? I think there was slack, right, the docs on Slack, which is like this massive community of like Doc's writers all around the world, there's off there's other ones, you know, I have some I have like 15 servers on my Discord, which I, like, go back to like, do a little wave emoji in. But there are communities out there, if you search for them, that's to the pike call you on would be a great place for people to join, but they're just starting out in their content creation journey. Oh, yeah.
Tim Bourguignon 45:49
Then we'll link that to the show notes. Speaking about the show notes, where should we send people to if they want to contact you and start a discussion with you?
Rich Haines 45:57
I guess that would be Twitter, where you can find me at Studio underscore hungry. That's my Twitter handle. I'm pretty active on Twitter, not very active anywhere else anymore.
Tim Bourguignon 46:07
And your website? Probably,
Rich Haines 46:08
yeah, Richard Haines dot Dev. Is my website.
Tim Bourguignon 46:12
Anything else you want to play?
Rich Haines 46:13
I don't think so. I'll probably think of something after we say goodbye.
Tim Bourguignon 46:18
Looking forward to that. Thank you very much. It's been a blast listening to your wiggling story that circle back and ended up in a wonderful place awkwardly.
Rich Haines 46:30
Cool. Thank you very much for having me. It's very fun.
Tim Bourguignon 46:32
And this has been another episode of Dev was really it was each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and, of course money. Would you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info. Talk to you soon.