#166 Helen Scott found her itch in technical writing and content creation

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Helen Scott 0:00
So when I actually started doing technical writing, I very quickly realized that you are often a one woman band.

Tim Bourguignon 0:15
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 team building your own this episode 166, I receive Helen Scott. Helen is a Java developer advocate who simply helps the development community be awesome. She believes that content creation and communication are the best ways to engage with the community and help everyone learn together. Helen has worked at numerous software companies, and has experienced the highs and lows of the software development cycle at all stages. She loves to learn new tools and technologies and share that journey of exploration, which obviously led me to inviting her on the show. Ellen, welcome veteran.

Helen Scott 1:06
Hi, Tim. Thanks for having me. Excited to be here.

Tim Bourguignon 1:09
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 guest. So, Elena, as you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as always, let's go back to your beginnings. Where would you place the start of your journey?

Helen Scott 1:59
The start of my dev journey probably 9096. Long time ago. Let's go back. So 1996 was when i i Just flunked pretty much all my levels, actually. And I've done I've done really well on my GCSEs. But it got to a levels and I just bombed. And then I was under some pressure to take the next step and go on to university. So I, I started looking around at universities, and I had no idea what course I wanted to do. And somebody threw out their computer science because they knew that I kind of liked computers, but I hadn't hadn't programmed Well, technically I had programmed, I just didn't realize it if you call probably won't remember logo, like the little turtle, you could move around the screen. That was the extent of my programming skills. I liked computers, but I knew very little about them. Me being me, I decided that challenge would be good and would be fun. So I settled for computer science. And I was accepted to study at Sussex University for the year starting in 1997, because I had to take a year out for financial reasons to be able to get a head start on on that side of things. So I went to University of Sussex back in 1997. And I studied computer science. And it was really hard, because I didn't know a lot. So I was very fortunate, I think in terms of the people that I met there, the support that I received from the institution. But it was incredibly difficult, especially for the first year because I spent most of it going, Oh, what am I what have I done? What am I even doing here? Everybody was so far ahead of me. And I my skills were definitely more in the Sunday afternoon drinking department than they were in the modules that we were being asked to study but was doing okay. And I said I had amazing friends. That helped me in a number of areas to scale up incredibly quickly. So I graduated from that in 2000 Feeling extraordinarily pleased with myself. And I then took the next the next logical step when you because we had to study Java at University of Java, but in 1987, it was a baby right? It was version one around them. So it was very much in its infancy. And I I took what I thought at the time was the next logical step. When you have a degree in computer science and you've studied Java for three years. You go and be a Java developer. Right? And I I went back while I didn't go back, but I failed. I failed really badly. I spent 18 months As a Java developer, if anybody out there remembers CORBA, client object request broker architecture, it is seared into my brain, I really struggled. I was not able to grasp some of the concepts. I didn't thrive in the environment that I found myself in. And in the end, I quit. And I quit with that another job to go to, because when you're in your 20s, that's seems like a good idea. Because I didn't have a mortgage or a family. So I went home to my mom. And she said, No. So I ended up going out to Asia and teaching English as a foreign language for a year because I was in the place of virtually, I thought I'd wasted these three years. And if I had failed in my first role as a Java programmer, then then what was the point? I had this degree, but I couldn't, I couldn't do this job, or in my head, that sort of thinking, I can't do this job. So I ran away, effectively. Whilst I was out there, again, my amazing group of friends, one of them suggested, have you considered technical writing? And I thought, Well, I remember we did a module on that. In year one, I think it was, and I liked it. And I did well in it. But then I had all these voices in my head saying, Yeah, but you are terrible at English GCSE, and you didn't really like it. So why would you do that? But I persevered. And I took a distance diploma in technical communications, whilst I was out of the country. And when I returned, I took a role as a junior technical writer at a software firm. And I was only there for about a year ish, because there were redundancies. But I learned a lot from that. And I had an amazing boss, who would take me and the other technical writer, also quite Junior into rooms and spend days at a time training us to be technical writers, because he knew what was coming, he knew we were all going to be made redundant, he would spend days at a time just teaching us everything he knew about technical writing, he was far more experienced than we were. So that, that really laid some great foundations for me. And I then went on to my next technical writing role, where I met my now husband, never work and date, it's really hard. And then I progressed on to a different technical role, where I stayed for a number of years, leading the technical writing function, actually, by that time. And then, so that's, I'm going to I'm going to compress about 18 years of technical writing into three sentences. I briefly when I was in the role before this one, I was doing technical writing, I actually pivoted that role to product owning for a year, it was for a number of reasons. So there were some changes in the company that weren't working out well for me. And I had an itch as the best way I could describe it. I had an itch, I loved technical writing, and I'm happy to talk more about that and why that was, but there was something missing for me. And I didn't know what it was. So I pivoted, and I did product learning at same business. They were really supportive. And, you know, everything of me trying that, but it didn't. It didn't scratch the itch. So we're now I've just gone through 20 years so fast. We're at. We are where we were always alright. March 2020. It's still March 2020. In my head, yes. Yeah, exactly. Right. So we're locked down one in the UK. So March 2020. Again, more changes in the business where I was working. And that's when things took the next pivot. For me, that's when I decided that that wasn't scratching the itch. And what would scratch the itch. And of course, I do what I always do when I have an itch, I talked to my friends. And one of those friends, is Tricia G, who I met in 1996, at university. So I spoke to her and she said, Well, look, I'm recruiting for a job advocate. I think you have a lot of the skills needed for this role, especially in the communications department. And you have worked with developers for 20 years. You know, you get and, you know, developers, and I thought, Well, okay, well, that's fair. So she encouraged me to apply it and I, I went through the interview process with with JetBrains and doing the task, check out myself so stressed about and I was successful in my application, which is amazing. So I've now been there a year as a Java developer advocate, so working alongside phenomenal people. Trisha de like I've mentioned Dalia Abbott, shisha, Mala Gupta, and the wider advocacy team learning the craft After all, learning the bits of the craft that I don't or didn't have, and it's just amazing. I'm having the best time the itch is officially being scratched. Yeah, I'm pretty happy about that. So I think I just managed to tell you, where did I start? 1996? And it's now 2021. So, yeah, 27 years and about seven minutes. That's good going. That was.

Tim Bourguignon 10:29
That's a good, that's a good, good start. But let's unpack a little bit of that. Let's go. Let's go back. Do you start as a technical writer? How did you picture the role of a technical writer before starting? And now knowing what you know, how do you GC yourself back then

Helen Scott 10:45
the role of a technical writer. Before I started it, I thought it was somebody who, obviously it's somebody that creates documentation for users. I think before I started the role, I had some misconceptions around it in that maybe it was technical copy editing. The other misconception, I think, was probably the one that I think was probably the biggest was, I think, I thought that I would be, although it'd be lots of technical writers, I just be a really small, small cog in a much, much bigger wheel. And that was kind of true, but it wasn't true in the sense that I thought it would be true. So when I actually started doing technical writing, I very quickly realized that you are often a one woman band, most, you're going to make a gross generalization here. Most companies think about technical writers after the event. And by the time they employ a technical writer, they've already got a product, and then they go home, oh, gosh, we should write some documentation for this. And then when they have that thought process, they then recruit a single technical writer. And not only does that technical writer have to learn the product, write the documentation, because you cannot write the documentation. If you've not learned the product, you have to set up all the processes and procedures for technical writing the function, so everybody knows how to interact and work with you. And then you have to keep up with what is hopefully from a business point of view, an aggressive release cycle. I think when I when I was studying for it, I thought it would be I didn't realize it would be drinking from the firehose quite as much as it is some days. But as it turns out, I absolutely love that. So that was fortunate.

Tim Bourguignon 12:23
I totally agree with that. And that I have not many experiences with with technical writing, but one that was really memorable to me, I think, because it was a very good one, where the technical writers were with us from the very beginning. And pushing back on stories, saying, yeah, yeah, that's a nice function. But why? And why do you want to do that? And how do you want to explain the users? How to use that and why they should use that? Let's push back on that from the very beginning, before we've written some code. And that was the best experience ever having somebody think about five miles down the line? Yeah, before we've even started. And I've had no, the experience was not at all like that more often, like what you say, saying, well, software's done here, you shouldn't take more than two weeks, right. And please write it down.

Tim Bourguignon 13:12
I think you've touched on something really interesting there is it's the ability that a technical writer has to advocate for the user. Because you when you come into the function, unless you're fortunate to have been there from the start and be pushing back on stories, which most technical writers aren't, unfortunately. But you are in a phenomenal position to advocate for the user, because you are a user, and you don't know the software. And not only do you not know the software, you have to know it enough to be able to explain it to other people. And that is that in itself puts you exactly in their shoes. So if something doesn't work, or something doesn't do what you think it should do, or I will caveat that with one thing that I always try and do is come up with solutions, because it's very frustrating for developers, if you say, I don't really like that, or I don't really like how it does that stuff. Rather than saying, can we just reword that to you know, whatever, because that's quite dark UI pattern? Or can we change that the flow of this functionality, because as a user, I got a little bit tripped up that step three came before step two, in my mind. So I think that is something that technical writers, and it's not just a crisis, anybody who is interfacing with the product has that ability, they have the ability, and they should use that ability to advocate for the user. Because it's just, it's so important, and it's going to make the software better. And it's going to help your users have a better experience with the software. So it's a win win scenario.

Tim Bourguignon 15:29
Have you had the chance to do that as often as you think you should? Pushing back and being that early on the creation cycle?

Helen Scott 15:36
Yeah, not in my first role so much, because when I was junior and to assuage redundant, but definitely in my third and fourth row, because we, we were part of the software creation, or at least in both them, I was involved in the software creation in very early days. And even if I wasn't, every time there was a new feature or a new iteration, I would go to go to the feature meetings, ask the questions, download the 90s, try it out, give feedback, it's something you have to get very familiar with, when you're doing that kind of role. Because there's a lot of crossover with business. Unless there's a lot of crossover with testing. There's a lot of crossover with advocacy, and you have to wear a lot of hats, you have to constantly use, like for testing, you have to raise bugs, for advocacy, you have to say, actually, my brain kind of fell over at that point, I'm not really sure what's what's going on here. Can Can we work through it, the other thing that you have to do to enable yourself to to have that interaction with developers, is to build relationships. And I discovered this very early on in my career, because the last person a developer wants to see two days before the release is the technical writer. They just don't want to see you. And, and I get it completely, I completely get it. Because you know, the whole team is under pressure to to deliver the product. So one of the things that I really made sure I did was I knew my colleagues made sure I knew my colleagues as well as I could. So I would talk through I don't know the names, bit of a no brainer, but their partner's names, their kids names, their Furbabies names, but it's also you know, how do they like to interact with you. So, especially when you're getting documentation reviewed? That's a really interesting one, I think, because some reviewers love reviewing documentation, but shouldn't be reviewing it. Some reviewers don't want to be reviewing documentation, but actually need to review it. And then sometimes you get those amazing reviewers that should review it and want to, but they're rare. And you really have to understand their shedule. Because in the same way that you can't go pestering the development team when they're stressed out and trying to get the release. So you can't go pestering. Whoever should be reviewing your documentation, two days before the release goes out. So you constantly have this balancing act of making sure that it's correct, which, of course, is difficult, because it's not the 1990s anymore. We don't code freeze for three months. So the technical writer can catch up, you have to iterate all the time, that's why you're on the 90s. And then you have to make sure you've got it as technically correct as you can get it. And then it's reviewed. And whether that's reviewed in terms of they want you to book a meeting with them and sit down and screenshare and go through it or they want you to drip feed it through to them in the preceding weeks. Everybody works differently. And you have to understand people's workflows and how people like to work in to some extent, well, to a lot of an extent, you have to be really bendy and flexible of fit, fit with other people, obviously, you have your own boundaries, and you should always maintain those. But there's definite element of needing to bend and flex for everybody's schedules when you're in that kind of role. Because ultimately, you as a team have all got to pull it together and deliver that little box with a bow tied around, it can't really stay and you just need to find the right processes and procedures to to deliver that with the minimum amount of stress and of course the highest quality that comes

Tim Bourguignon 19:12
back to the the comment you made with a one woman band. So you're obviously the the project manager for that part, the person doing the technical writing the person scheduling, everything, etc. So yeah, that's exactly. I'd like to come back to one comment you made. You said some people want to review but this shouldn't. Yeah. Why one of the reasons why you should prevent somebody from from reviewing.

Speaker 1 19:35
That's a really interesting question. It's not a case that you should necessarily prevent them from reviewing it. If normally, normally, caveat. Normally the more reviews the better. But sometimes if you've got somebody that wants to review everything and isn't necessarily the SME that you need, or is making comments that They aren't actually particularly constructive. Think about a code review. That's me. Sorry. Sorry, subject matter experts. Okay. Okay. So for the same reason, you know, a code review, they can be quite destructive if somebody just says, Oh, well, you should have read The for loop like that, or, yeah, that they're not always constructive. So if you're getting constructive, timely feedback that's valuable for the product, absolutely. But sometimes, that's not always the case. And you have to push back and say, Actually, that's not the kind of feedback I'm looking for. If you want to continue reviewing the documentation, this is the kind of feedback I need. And this took me a long time to learn in my career, actually, the one you can say, No, you can say I'm not incorporating that feedback, because you're the technical writer. And secondly, you have to train reviewers to review the right stuff. Because especially if you think you're iterating, let's say, I don't know, somewhere between releasing every day and releasing every few weeks, you're, you're on a very rapid release cycle. So you'll always be creating documentation of 90s, you won't have the luxury of a code freeze. So you will want to get that documentation out for review as quickly as you can. And it may not be it may have typos in it may have maybe just dodgy grammar, but you have to train the reviewers that you will fix that stuff that's low hanging fruit, you've got that you've got automated tools for that. You what you really need them to check is is it technically accurate? Is there anything missing? Have I said something that I shouldn't have said, you know, if I've documented a field or a checkbox and gone, this might do something? Or it just might not? We're not really sure, then obviously, that's the kind of stuff that you'd want to be caught?

Tim Bourguignon 21:42
How do you train your colleagues for that? How do you explain them? Well, thank you for the comments you made. I'm going to park half of that, because it's not my focus right now. But thank you for the rest as well.

Speaker 1 21:52
Exactly like that. Okay. Yeah, yeah, because ultimately, everyone that I've ever worked with has respected the role that I've, you know, been doing and been very fortunate that respect. So if you turn around and say, Look, I really do appreciate your feedback. But right now, I need to focus on the technical correctness of this, I will fix that low hanging fruit as and when, but definitely before the release goes out, but your the value that you can bring is not that low hanging fruit, I've got that the value that you can bring is the technical expertise. And when you phrase it in terms of you need them because they are the technical expert. And that's not you, they're much more willing to provide the kind of feedback that is going to be the most valuable for the documentation.

Tim Bourguignon 22:35
How was your pass as a computer science graduate, and you started as a developer helped you along those 18 years,

Speaker 1 22:45
way more than I give it credit for actually, especially recently, I, because I had such a rough time. In my first role. After graduation, I convinced myself of a lot of false traits, like I can't be a developer, like I can't code like, I can't be part of a development team. And it turns out, that was all rubbish. One of the reasons that I think I, well, no, there are numerous reasons why that first role went wrong. But there's many reasons why I'm succeeding now. Versus then I think some of those are around, I am unfortunately, older and wiser, or something like that. And I'm better at applying myself, I'm better. And I'm more focused at knowing what I want from life and to achieve. I also don't have some of my hang ups, call them hang ups of youth in that. Certainly with with Java, it's not that I can't program. It's not that at all. It's I'm now catching up on, you know, 20 years of Java, so 1.2 to version. But are we almost 17 now. So, maybe 17, by the time this goes out. I'm catching up on all that stuff. And it's nowhere near as hard as it was 20 years ago. And I think a lot of that is down to mindset. And that I'm, you know, I've grown in the last 20 years as well. One of the the mindset tricks that I definitely didn't have 20 years ago, and I have now is adopting more of a growth mindset. So the difference between saying, my code doesn't work, this is all crap, versus my code doesn't work yet. I'm going to go for a walk, I'm going to make a cup of tea. I'm going to have a think. And I'm going to come back to it. And then I'm going to see the problem with my code and I'm going to fix my code. So the difference between it doesn't work. Full stop, and it doesn't work yet. And I find that if I put yet at the end of my sentences, it makes such a huge difference to how I think about things and how I approach the challenge because I I'm succeeding this time around If it's that the coding aspect is easier for me. Now, of course, the big caveat there is I'm not in a role whereby I'm a professional Java programmer. I'm in a role where I'm a Java developer advocate, the value there for me is that my, my lack of up to date, or my growing me catching up on all that Java knowledge is, it's a bit, it's my superpower, really, because I don't know the shortcuts. And I don't have 20 years professional Java programming experience behind me, I have 20 years of working with software developers behind me, and integrating very much into the teams and I love working with developers, that's like my biggest passion. But I don't, I don't have that Java knowledge and that Java experience, so I can advocate for others who are learning that. And the other thing that we didn't have in 1997, or, you know, late 90s, started to have in the early 2000s, was IDE s, I am scarred from using VI. And I'm sorry, to all of you out there who love by I didn't love it. You know, now I'm coming back to this Java journey with an IDE, my mind is blown. Yeah, it's a completely different experience. This time around, it's like, sir, it's like comparing apples with pears. It's just a totally different experience to surrounding this time around, I've got the tools and the mindset and the desire that drive if you will, to succeed at this particular task. So it's much more enjoyable this time around,

Tim Bourguignon 26:46
I believe, probably within a year, and what you're saying is in your job, now you have a different skill set than some of your colleagues, some of your colleagues have been in Java deep in the Java basement for years and know the ins and outs of every library. And, and have acquired this this communication, teaching, relating projecting onto users cetera, in order to bring their knowledge out, and you're coming from the opposite. You've been relating and having cetera, and you're acquiring years apart. And I've made this experience as well as, as a coach, when I was very technical coaching in a project with a cold coach who was more of a psychologist. And it was a fantastic experience. Have you experienced that as a technical writer as well, having not a one man or one woman band, but working with somebody else that has a completely different skill set? And seeing this, this back and forth? How you can help each other out with a different skill set? Have you seen that?

Speaker 1 27:47
Yeah, definitely. I think it goes back to one of the things I was saying earlier about. Okay, this is gonna go to one of my BS in my bonnet that I have about technical people versus non technical people. I really don't like that that phrasing because I worry that it puts people in boxes. And I've been on the receiving end of being told that I'm a non technical person, I was like, whoa, I'm a technical writer, pal isn't the job title. So I have definitely got frustrated by that, by that terminology, because it's quite close terminology. But I've also because of the the 20. Yeah, 20 years experience of working with development teams, I didn't realize the number or the amount of skills and crossover that I've acquired, and I hope, I guess people have probably acquired from me as well. I've worked with, I call them closet technical writers, people who secretly love writing documentation, but they don't want anyone else to know about it know about it, because it's not their main job role. Equally, I myself, I love doing a bit of testing. And I'd say advocating for the user is a huge part of that as well. Yeah, I've definitely found a lot of instances, or I'm definitely becoming more aware of a lot of instances where there's been that that skill crossover, and even. Even the time one of the C sharp developers sent me a bit of code and went, This is what it does. And I'm they're going did it? Did it did it? Did I Okay, so it does this. And they're like, Yeah, almost almost done. Okay, fine. So, yeah, there's a lot of there's a lot of crossover, a lot of skill sharing. And I think that's one of the reasons I've loved the job. For the for the whole time that I've done it is that it's, it's such a pleasure to be around development teams as a whole. And when I say as a whole, I mean, the whole, the whole group of people who deliver the product, whether that's developers, testers, business analysts, technical writers, product managers, UI designers, UX, experience it they're all just incredibly talented people that come together and work together in this phenomenally complicated social construct to deliver For a product and when you actually take a step back, and you look at that, and you realize all the people that that move and work so hard to deliver a product, it's it's really special. It's really, really special. It isn't. And I really hope I didn't forget anybody there. I'm sorry, I

Tim Bourguignon 30:22
wanted to dig a little bit into your your new role as it's in the title technical writer. I hear writing. Yeah. And when I hear advocacy, there's a plethora of medium you can video you can be at conferences, you obviously do documentations tutorials, exploring things. First of all, did you miss the writing? And second level? How did you acquire those new skills into going through this this other mediums and apply all the skills you had to this new way? For you new way of working? I assume it's a new way of working? It's a loaded question. Sorry.

Speaker 1 30:57
There was a lot of questions that first one, do I miss the writing? No, because I get to do lots of writing in this new role. Right, on to the next question. Trying to pass all of those questions. No, no, it's good. So when I, when I first took the role, I, I don't know if I'd call it imposter syndrome. Or I think I might just go with plain insecurity, that I wasn't going to be able to do it, even though, you know, had gone through the interview process and met load people and done all the other bits and bobs. But what I discovered was content creation is is a passion of mine. Because, well, I never I always thought technical writing was my passion. But it's bigger than that. It's creating content. And one of the first tasks that I was asked to do was to create a an example screencast to, you know, get a fit so that JetBrains could get a feel for the kind of content that I would like to create and my style. And I completely freaked out about it, obviously, because I've never done anything like that before. But what I've since discovered is I love doing it. My passion for the content creation is bigger than writing, I think it might be the itch that I'm now scratching, is that it's not just the writing, it's creating screencasts but then it's not just screencasts. So we've recently launched a guide for for IntelliJ IDEA that the advocates are looking after. So I'm I'm experimenting on there with doing like little talking head videos, which I never thought in a million years, I would not only do but actually enjoy doing. I never, it just didn't occur to me at all that I would, I would actually enjoy that. And I'm really hoping to do more of those as well. So whatever channels we're putting the content on. Yes, I've spent a long time writing professionally. So I absolutely do have a passion for writing. I'm, you know, that's, that's who I am. That's probably my first love. It will always be a love of mine. But being able to expand that love of content into lots of different mediums now and explore new mediums is it's really challenging, and it's out of my comfort zone, which is a good thing, because I don't I personally don't thrive if I'm in my comfort zone for for a number of years. And I think that might be why there was there was the itch last year. Last year 2020. Yes. Honestly, this March 2020 thing. Yeah, I'm trying to think if I've actually answered your question there or just waffled?

Tim Bourguignon 33:39
Yes, you? Do you do explore those new mediums. You said you're quite quite out of your comfort zone exploring this? Do you explore it on your day job? Or do you explore it besides your day job? And then when you feel comfortable enough bringing into your day job? How do you wiggle this in?

Helen Scott 33:57
So this is this is a recent realization of how I work, I do the the most clicking exploring in my day job. So learning more about them and obviously looking at the content that my colleagues have created and deciding if I want to create similar content or take a different path, whilst always thinking what what is going to be most helpful for the users that I'm advocating for like, what what do they want? How is how can I present this content in such a way that is helpful to them, that's going to help them be awesome. So I do that during during my day job. I've also realized that I think I'm actually turning into my mom, because she always used to do this and I would frustrate the heck out of me as a kid. And she'd say something to me, like, Let me think about it. And honestly, I would just be like, are you done yet? Have you thought about it? And now the value that I find in saying to myself, I'm just gonna have a think about that and I won't actively think about it. But whilst I'm you know, off evenings, weekends, or Ever I've read, I've realized that my brain is doing this amazing thing without me even being aware of it ago. And it's saying, how about this? Have you tried this? Have you thought about that. And then Amazing things happen. And they won't happen if I just sit at the computer and, and try and think this through and work out how I want to structure this, because what I've conveniently apparently forgotten is that any kind of content creation is as much of an art as it is a science. And you need that, that other side of your brain to simplify grossly, I guess, too, think about that, and actually come up with something that's really going to get to work for the users. So I think I do a lot of thinking. I say, I think because it's not an active thinking process. It's a turning over to the subconscious and saying, Get back to me when you have an answer, please. Although sometimes the answers come at inappropriate times. But does happen and I have to run in here and write something down. Don't Don't tell me that now. To in the morning.

Tim Bourguignon 36:04
proverbial light bulb in the shower moment.

Helen Scott 36:07
Yeah, they happen to

Tim Bourguignon 36:11
be some special pens to write on the tiles. I know. Are you in for 18 years of advocacy? No,

Helen Scott 36:20
I hope so. 18 years, I'm like, wait a minute, is that past time? I am loving the job. I am absolutely loving the job. I've moved from a place of thinking that not not that I can't do it, but that I won't be able to do it to a place of this is really fun. I'm desperate for the world to open up again. So I can actually meet users, that's the thing I miss the most is being able to, not so much. I mean, conferences, and advocacy. And speaking everybody knows that. But being able to meet people in real life and understand them, what makes them tick, what challenges they have. And that's what I'm really missing at the moment. That's the thing, that there's definitely a part of the puzzle that I know is missing. And it's that. But yeah, so far everything I've done, I've loved I'm enjoying I learned every day. Oh my goodness, they're learning. I didn't realize how much I loved learning. Maybe I didn't love learning in the late 90s. I'm not sure. But I love learning. I love taking myself through different Java courses or trying different things or experimenting with different video capture tools for whatever kind of content we want to create. Like I mentioned, before, we kicked off the recording for this podcasts. I am a list person. So I make a list of everything that I want to get done in that day. And there's at least one or two things on there. That's learning and whether it's going to be learning and work time or evening time. But it's stuff that I want to do. And I'm really driven by that stuff, because I'm terrible at backing down from challenges. So. So I just I love learning about new technologies and new stuff. And I guess, I guess 20 years or nearly 20 years in technical writing has primed me for that. Because that's and you know, you think technical writing, oh, you must do a lot of writing your job. And you really don't, you really don't you do maybe 30% writing 20% relationship building and 50% learning, because if you don't know the product, you can't write the documentation or advocate for the user, or test it or do any of the other crossover roles that you need to do.

Tim Bourguignon 38:40
Very interesting. Thank you. I'd like to come back to the very beginning. And in this dark place where you had this experience for 18 months, and felt that everything was was broken, breaking down and didn't know where were next could be. What is the one piece of advice that that would have helped you back then to realize, hey, that's okay.

Helen Scott 39:03
The one piece of advice that would have helped me was to acknowledge that I don't know everything. And that's okay. I had a misconception that because I'd spent three years studying Java, I'd be able to be a Java developer. But it's only recently and again, from my experience of working with development teams that I've realized that's a part of a much bigger set of skills that you need, the communication skills, the people skills, the get skills, oh, you need get skills, you didn't like them, but you definitely do know. It's all the other skills that we learn on the job that we don't always give ourselves credit for, that we've learned and we've got and we don't necessarily realize when we're new that we're going to need them. So I think it would have been, it would have been knowing that I don't know everything and also to be a lot kinder to myself. I was very hard on myself back then. And I'm a lot a lot kinder to me. myself. No.

Tim Bourguignon 40:01
Aren't we ever? Oh worst critics? Yes. Yes,

Helen Scott 40:04
we are. Yes, we are. terrible habit.

Tim Bourguignon 40:08
Thank you very much. Very good. Very good advice. Where would be the best place to continue this discussion with you find you online and and start a discussion.

Helen Scott 40:15
Sure. So my Twitter handle is Helen Joe Scott. So Helen, Joe Scott. That's also my website. Helen J. scott.com. Helen Scott's a really common name. So I had to put Joe in there. I think I'm that handle pretty much everywhere but yet DMS on Twitter or open hit me up be good to chat. And, yeah, that would be it'd be nice for anyone to reach out and we can catch up.

Tim Bourguignon 40:42
Awesome. Do you have anything on your plate coming in in fall? And can you want to plug in full color today?

Speaker 1 40:47
I don't actually know I think it's it's gonna be there. There are going to be some exciting things coming up. But they're all in the infancy stage at the moment of they're in that thinking stage there with the subconscious part. So when it when it comes back to me with an answer, I'll be sure to give you a call Tim. And if it's two in the morning, you know

Tim Bourguignon 41:13
you probably posted on Twitter or give some some hints that something's coming up so we can. Awesome, Helen, thank you very, very much. Thank you, Tim. And this has been another episode of developer's journey. We'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website, Dev journey dot info slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you will 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 th e p or per email info at Dev journey dot info. Talk to you soon.