Speaker 1: 0:00

Hello, and welcome to the router, the official podcast of the ACU computing society, where we explore the human side of tech. I'm your host, Olivia. And on this week's episode, we'll be talking to Lucas. Costy about his experience as a technical writer. First things first, tell me a little bit about yourself and what you do.

Speaker 2: 0:30

Cool. Um, hi, my name is Lukas Costie. Uh, I work at, uh, as a technical writer and currently I'm working at GitHub. You may have heard of it. Uh, I previously worked as a, uh, as a technical writer at red hat. And then before that I worked in it support and system administration. So I sorta changed careers from being a CIS admin to a technical writer about seven or eight years ago.

Speaker 1: 1:01

Oh yeah. Um, so what decided you to make that change to technical writing?

Speaker 2: 1:07

Well, um, I'd always been a really good writer even from school and, uh, to go back a little bit towards my time at Yuku. Um, I actually started a journalism career, um, journalism degree, um, as my first thing out of high school, but it took me about four weeks into the semester of journalism to realize that I wasn't cut out for journalism and, um, switched back to an arts degree, which was my initial plan out of school. Um, and I did a few it courses in that and discovered I loved technology as well. So I completed a bachelor of it and a bachelor of arts. Um, as you can imagine, those two timetables didn't work very well. Um, but, um, I, uh, I liked the technology, but I also liked the writing part. So anyway, fast forward towards graduation, I really needed a job quickly because I was getting married at the time. So I just took, um, the first job I could find, which was a, um, a support job, which over the years I transitioned into being like a system administrator and it was comfortable and it paid okay. Um, but I wasn't really happy by the end of it. Um, so about five years into that, um, I actually got really sick and I had to stop working, um, to deal with my health. And, um, and after I sort of got back to, uh, uh, like a time where I could, um, go back to work full time, I sort of had a discussion with my wife and with myself of like, well, do I really want to go back to being a CIS admin? And, um, and I really didn't want it. And I thought, well, what else could I do as a job? And I briefly flirted with the idea of writing a book, um, but realized that I can't really, uh, I can't take criticism of my creative stuff very well. So I started looking around, um, in other careers and, um, I still love technology and I really liked writing. So I thought, Hey, is there any too, I mean, is there any career that can mix the two of those things? And it turned out there is a thing called technical writing. And luckily for me, um, red hat here in Brisbane was hiring new technical writers at the time. And so, um, yeah, I got a job there and, uh, and the rest is history, I suppose.

Speaker 1: 3:48

Yeah. So when, when you, I guess like a lot of people, like you don't really know that much about the technical writing role, um, because even if people have kind of heard of it, there's, it's a little bit mystified in what is kind of actually done within it. Would you be able to talk about, I guess maybe some of the projects that you've worked on over the years?

Speaker 2: 4:12

Yeah, sure. So, um, at red hat, um, I actually worked mainly, I worked on a lot of products, but I work mainly on what's what was called, well, what is it called? Um, J boss enterprise application platform. And, um, if you haven't heard of it, it's essentially a Java application server. And so I worked primarily on that at my time at red hat, but I worked on a ton of other things, um, at GitHub at the moment I'm working on, um, uh, what and get how we call the ecosystem side of GitHub, which includes the GitHub API. And, um, more recently, um, documenting GitHub actions, which is get hubs new, um, CIC D uh, system built into GitHub. So, um, uh, lots of different products covering lots of different sort of, uh, platforms and uses. And I guess that's one of the really great things about technical writing at, um, relatively large technology companies is that you get exposed to a lot of different technologies and a lot of different things. Um, a lot of which is really new and exciting. And so you get to be on that sort of cutting edge or bleeding edge of things and learning about a lot of new stuff, which really helps in terms of like your, uh, exposure to technology and the industry as a whole.

Speaker 1: 5:51

Hmm. Yeah. That's, it's very, I feel like it would be very cool cause you really wouldn't get exposure to all the latest and greatest technology before, I suppose before a lot of other people, um, being the one who has to write on it. Um, what, what was your, what's like one of your favorite, one of your favorite things that you've worked on?

Speaker 2: 6:13

Well, that's a tough question because I'm at least personally as a technical writer, you tend to develop a love, hate relationship with the stuff that you're documenting, um, because you, you sort of, you have to try and understand what the product is doing without having any actual documentation for it because you're the one writing the documentation. So, um, uh, to answer the question about the favorite thing that I've documented, um, Oh geez. I, I think originally it would be right at the start of my technical writing career and that would be with J boss EAP. And the reason for that is, um, it's actually one of the reasons that I gave, well, let I give interviews when I go for a new job is, um, I like to be able to help, um, people understand, um, complex things, uh, that need that information at the time. And why I say J boss is that, uh, when I was assistant administrator, I was actually administering a, uh, Apple, um, excerpt server back when Apple used to actually make servers. And, um, and they actually had a version of J boss built into the actual Apple operating system. And, um, and I remember it being so difficult to understand and use because it was so poorly documented within the Apple's server documentation. Cause they didn't really do a good effort that sort of documenting much of the service specific stuff that, um, that it was quite ironic that eventually when I got a job, um, as a technical writer, that I was sort of not documenting stuff on Apple, but like documenting essentially the same open source products that motivated me to sort of, um, become a technical writer in the first place. And that's to sort of help people understand complex systems.

Speaker 1: 8:38

Yeah. That's, that's very cool. I guess, that you got to experience the struggles of not having good tactical writing and then adjusted to basically fix it so that there was actually decent some, some decent documentation there for uses.

Speaker 2: 8:53

Yeah. And I think that's what, at my opinion, um, makes me a decent technical writer is part of knowing that, that struggle of like, you know, trying to learn something new and trying to understand what is pretty much like a very complex topic and being on the other side of that and helping at least trying to help, um, you know, fix that sort of situation for people that would be where I was like 10 or so years ago.

Speaker 1: 9:25

Yeah. Um, so I guess now that you are more on like obviously the writing side, how did you find giving up or not, not giving up so much, but like transitioning over from like the more technical side to, um, like kind of a little bit over to the other side, like obviously you still have a very technical based role, but it's not as hands on with the technical stuff as you would have previously had.

Speaker 2: 9:53

Um, I actually really enjoy it because at least for myself, I don't feel as much pressure in that. Like I'm not in charge of like, um, keeping a production system running and being responsible for like everybody's productivity inside a company or something like that. But, um, but I still get to, um, get really hands on with things and, um, not, not all technical writers are like this, but I like to get really hands on with something that I'm documenting to make sure that, um, essentially it is what, sorry, what I'm documenting is actually accurate for what say the product or the feature actually does. So, um, as I said before, it sort of gives me really broad access to a lot of different technologies and, um, and parts of features that I would never have sort of touched before, um, to get in there and actually play with it and then to figure out how people would want to use it or might want to use it. And, uh, and then actually write documentation that explains how it works and how people can actually, uh, use it to accomplish their own sort of business needs or user needs.

Speaker 1: 11:14

Hmm. Yeah, I think that's pretty good. Um, pretty good reasoning math. So I guess I'm kind of on a little bit of a different tangent, but how, how would you get started in technical writing? I know you said you like kind of applied for red hat and then got the position there, but I feel like it can definitely be a, a tricky position to get into. Do you have any tips for getting there?

Speaker 2: 11:48

Yeah. I mean, it's one of those things like with any career, there's always a bit of luck getting started. Um, first of all, um, I would say to anybody wanting to be a technical writer is that like, of course being able to write and having a good understanding of like English grammar and what makes good sentences and things like that, um, would be the first thing that you should definitely work on in terms of actually getting your foot in the door at certain places. Um, it's always good to have examples of like what you've done before in terms of technical writing and something that a lot of people always suggest and I think is great as well is to get involved in maybe something like some open source projects that might not have good documentation coverage and just write a few like a guides or how tos or tutorials or something like that on the actual open source product or feature or like scripts or whatever it is on ghetto and just contribute to that community so that you can actually have something that you can show, um, as sort of like a portfolio essentially of stuff that you've done. And, um, and so, yeah, I mean, if you use like an S you know, some something that's open source on GitHub or wherever else, um, and you can show that you've contributed to that and that you have an understanding of like what the thing does and maybe how to explain how to use it to somebody who might not be familiar. Um, I think that's a great start to, um, to sort of, you know, build up some examples of your writing that you can actually show, um, if you're going for a new job.

Speaker 1: 13:39

Yeah. Yeah. Okay. Um, yeah, I feel like I open source working, contributing and working on open source projects is honestly a good, a good bit of advice for anyone in any kind of technical field, because I feel like they do really expose you to, um, so not sure, like what's so much different technology, but, and working with other people as well, especially, um, because obviously you're working open source, you're working with a whole bunch of all the developers and writers together. Um, but how do you, how do you find working within a technical writing, um, team and obviously like you would have to have a lot of, uh, I guess providing feedback to others and feedback provided on yourself. Cause you mentioned that you find it difficult to find, to take creative criticism.

Speaker 2: 14:32

Uh, yeah. Um, I love working on a team. That's probably one of my favorite things and why I've generally shied away from jobs that have like, that are more solo type of technical writing. Um, when I mentioned before about like taking creative, it's more something like creative, like writing a book rather than creative, like writing a, like a technical guide. So, um, uh, I've been lucky that, um, both previously at red hat and of course now I get hub is that we all, um, use, uh, get and, uh, repositories to write and store our documentation before it gets processed into a more readable form, like a website. So, um, we use a, you know, a pull request, um, review sort of get flow process, um, in all of our work. So everything that gets committed into the repository has to be reviewed by somebody else. Um, and you have that sort of discussion like you do on any normal sort of repository of code where multiple people are working, um, on reviews and things like that. So, um, uh, as I said, it's one of my favorite parts of technical writing because, uh, no matter how experienced you think you are, even just in terms of writing with just English and stuff like that, you're always learning something new. Um, there's always bad habits that you have that other people point out that you don't realize that you haven't until somebody points it out. Um, and like, just like with code that there's like a ton of different ways of programming, something to achieve an output it's sorta the same with writing is that there's so many different ways that you can write something and explain something. And a lot of the times you can't even see the different methods after you've written one thing, and somebody will come along and point out a much better, much cleaner, much more succinct way of explaining something that you can't believe that you didn't sort of see that in the first place. So I'm sort of a big thing in technical writing at the moment is treating docs as code essentially both in the way it's stored and that it's ways collaborated on. Um, and I'm a big fan of that because I think, um, reviews and, um, a collaborative process in generating docs is just as useful as the actual code of the product itself as well.

Speaker 1: 17:18

Yeah, it's really, really interesting and cool. I think to hear that you guys use get for technical writing as well. Um, because it is a, like a, a good system for systematically, um, developing, um, I suppose in this case, like writing and you can see other people's edits and yeah, I think that's really cool and interesting. Um, I guess my, my last kind of question that I have written down here is in terms of like the progression of technical writer, like, what is the kind of career progression from, um, just like when you first started out to, um, later on, uh,

Speaker 2: 17:59

There is tons of different things that you can do in technical writing. And, um, I've known people, who've been developers and engineers and come in as technical writers and I've known technical writers that have like been writers and moved on to engineering type of roles, but just within technical writing itself, um, you can be, what's usually called like an individual contributor, which is, um, you're a writer, you produce docs. Um, and that's sort of like where I like to be. And usually just like in an engineering role, there's like a career progression from being like a, uh, a sort of like start a technical writer up to like senior and principal or staff technical writing roles. Um, uh, and then of course just like engineering teams, um, usually, uh, teams or technical writers will have their own, um, like management as well. So there's technical writer managers, um, pretty much, um, producing docs for any sizable product requires a lot of project management as well. So there is just as there's like, um, engineering product managers for a particular like feature or product. Um, there's also product I'm sorry, documentation, product managers.

Speaker 1: 19:26

Okay.

Speaker 2: 19:26

And the other side of it as well is that, um, any good set of docs also needs a good set of engineering to actually, um, process those docs and present them. So, um, I've been lucky at sort of the two large companies that I've worked at as a technical writer that we've had our own dedicated docs engineering team, um, because we have such a large amount of content. Uh, it does take a lot of custom work to sort of stitch that together and present it in a, in a, in a nice way across a lot of different formats. Um, and that involves a lot of like, uh, reuse and, um, and sort of massaging of pretty much our source documentation to get it to what you see at the end. Um, so if you're familiar, I think, um, uh, the QCs did a presentation of, uh, ASCII doc, I think last year or something. And, um, uh, that's a really powerful system as well. Um, like it's a lot more, um, complex than just sort of writing sentences down in a, in a text file. Um, you can have things like reusables and, um, conditions and things like that in your doc. So that depending on who is giving it for what product, for example, it can show something different. So, um, so like dogs engineering is a way to get into it. Um, and yeah, generally there's so many different things just within documentation that you can do as a career. Um, one thing I haven't mentioned that I, of course, should men should mention as well, is that, um, in most big teams as what's called a documentation content strategist, and they sort of can plan out and set sort of the direction on a more larger scale for a set of documentation and provide rules and stuff, or how it should be documented and what kind of, um, like system or like templates that we should use to document things. So, um, that's one thing I've learned from my career and documentation is that like, what might seem simple from the outside does take a lot of work and a lot of different people and a lot of different roles to actually like produce what end users actually see and read.

Speaker 1: 21:58

Hmm. Thank you for that. That's very interesting to hear. I like the such large diversity, I suppose, overall, so there really is. Um, but yeah, that's, that's all I have to ask you for today. Is there anything else you feel like mentioning or adding for anyone potentially looking at pursuing a career in technical writing?

Speaker 2: 22:20

Uh, yeah. Um, I think one of my other biggest suggestions is just to be curious about things, um, because, uh, at least for myself doing documentation, um, pretty much that curiosity is I think what helps me write good documentation in that you always want to know how people use things and how something works, and that's sort of a good basis for how you can actually describe, um, and help other people use what you're curious about. Um, I think that if you're like me, that you enjoy explaining things and that you can actually write a decent English and you're pretty good with tech then, like I think technical writing can be really valuable career, um, that you can still be in technology and still use really exciting stuff. Um, but still also like help people and use your writing skills to really produce some really complex things that are really cool. Um, so yeah, hopefully that answered the question.

Speaker 1: 23:41

Yeah. Yeah, for sure. That was a really, that was actually a really response. Um, well, yeah. Thank you so much for joining me today. It was really fantastic to have you on you're a great, a great speaker and have a really great, um, like it's like story to tell. I feel like we'll be a lot of people like will be very interested to hear and probably a lot of people following it as well. I feel like, um, your, your like starting out in, in a role that you weren't really so happy with, and then moving over to technical writing, I'm sure will really, um, strike to strike a note with a lot of people, um, who might be wanting to pursue a similar thing, you know?

Speaker 2: 24:23

Yeah. And I think that's one of just generally with technology in general and it that's one of the great things about the industry is that, um, no matter where you start off in what you're doing, there is so much variety, um, in, in the whole industry that if you really want to change careers to do something else, and you've got that motivation to that, it's pretty skills are pretty transferable across like a lot of different things in technology. So like, just because you start off doing one thing, doesn't mean you're locked into that thing forever. And, um, and as long as like you're willing to learn and you're willing to like, um, sort of start new things and be a bit uncomfortable then, um, there's no reason why, like, you can't just change things up in the middle of your career and do something new and something better that makes you more happy, I suppose.

Speaker 1: 25:23

Yeah, yeah, yeah, for sure. And that's what we have to stay. Please join us again in two weeks from now for our next episode until then come join our community at Slack. What UGCs dog.