In this Docs are In episode, RedMonk analyst Kate Holterhoff speaks with Dr. Ryan Feigenbaum, Developer Experience Engineer at Ghost. They discuss the state of DevX in 2023; transitioning to the software industry after a career in academia; and documentation best practices. Dr. Feigenbaum draws parallels between his university work in a philosophy department with the research, communication, and pedagogical aspects of his role as a developer.

This was a RedMonk video, not sponsored by any entity.

Rather listen to this conversation as a podcast?

Transcript

Kate Holterhoff: I’m excited to welcome Ryan Feigenbaum, Developer Experience Engineer at the publishing platform Ghost to RedMonk’s Docs Are In, a series where we talk about docs of all stripes from documentation to doctorates. My name is Kate Holterhoff. I am an analyst at RedMonk. Ryan, thanks so much for joining me.

Ryan Feigenbaum: Thanks, Kate. Thanks for having me.

Kate: All right, so Ryan reached out to me following my whiskey on web, oh sorry, Whiskey Web and Whatnot appearance this fall because we’re pretty much the same person. So we share a Cincinnati connection, got killer German surnames, humanities, PhDs that we pivoted to software development and possibly most shocking, we’ve got October birthdays. So of course I had to invite my doppelgänger on, whose doctorate incidentally is in philosophy with a focus on the history of science to figure out why individuality and free will are an illusion. So we’re gonna start there. But, you know, so mostly kidding, but we are going to go deep on docs and I suspect our academic backgrounds will play a not insignificant part in this conversation. So let’s begin with some background. Ryan, will you tell me a little bit about your journey to Ghost and the tech industry more broadly?

Ryan: Yeah, sure. So I was always interested in the big questions. Is there free will? What is the good? What’s the limits of human knowledge? And what should I name this variable? But so then I was ecstatic when I got to college, and I found out there was a whole discipline that dealt with these big questions. That’s philosophy.

And so that’s what I kind of devoted myself to. I got a BA in philosophy at DePaul University, and then I went to Villanova for my master’s and my doctorate. And so my dissertation, The Epistemic Foundations of German Biology, 1790 to 1802. I don’t usually get to say that, so take every opportunity I get, right? Centered around the big question of what do we mean by life, by biological life? What’s the difference between living and dead, and specifically from the perspective, the historical perspective. And so while I was doing this, while I was reading and researching and writing about these kind of old German dead dudes, I was like, can I do something else other than this? And I thought, well, I should make a website where I can express my thoughts to others about these weird German dead dudes. And so that got me into HTML.

And I learned that learning HTML is a lot easier than learning Kant, and it’s a lot more practical too. And so it’s just really exciting that I could make something and put it on the internet for anyone pretty easily without a lot of cost. And that still is a really exciting idea to me about web development. But that then led to CSS and JavaScript, and it brought me to Ghost, which I’ll talk about a little bit in a minute or two.

But that started kind of me really learning and doing web development. So I was writing my dissertation, and I graduated. And when I graduated, the landscape was dire, which I think you probably know about. For every kind of professor job out there in philosophy, there were 200 really qualified PhDs applying for it. And I saw my colleagues and my friends who were more talented than I were kind of just struggling.

So it was a hard time to try to get a job in academia. And I knew that coding was something that I really enjoyed and was satisfying to me because it’s some sense solving an engineering riddle, it’s kind of like solving a riddle on philosophy. There’s these logical problems that you need to kind of work through. So I got a job in nonprofit management or academic nonprofits, not coding. But while I was at these academic nonprofits, there wasn’t much of a budget for anything. So I got to exercise a lot of my tech skills. And it led me from everything from designing and just doing basic websites to building full-scale apps, like with Vue and Svelte and Superbase and all these different things. And so that really got me even more into the web development space.

And I found out or realized, which was pretty obvious, that the parts of that I really enjoyed the most were the tech stuff. And I was finding any excuse to try to build some kind of app or do some kind of thing like that. And so I saw this position open at Ghost, which I had been using for my own personal website for a really long time. And so I jumped in at that. And so Ghost, give a little kind of just blurb about what Ghost is if you’re not familiar.

So it’s a publishing platform. It’s kind of like a CMS or like WordPress, but it includes a lot of nice kind of bells and whistles along with it. So it includes a membership out of the box. So if you want to monetize your content, you want to kind of gate different content, you can do that really easily. It also has newsletters built in, so you can send newsletters. And then it’s just a really beautiful editor to work with. So I think it’s the best editor I’ve ever used in terms of just writing content. And that’s what I think keeps a lot of people coming back, because it’s really fun just to write things. And I saw a job opened up there in their support department, or in support. And so that’s how I joined. And I was a support engineer working with customers on different things. And then about a year into that, a position opened up there in DevRel, or Dev Experience Engineer, or whatever you kind of want to call it. And then I shifted in that, and that’s where I’ve been ever since.

Kate: That’s a really great story. And I love that your pivot involved not only doing some management in between, which I think I’ve seen a lot of my friends do as well, where they got involved in this sort of nonprofit space. But then, ultimately that your enthusiasm for coding was what kind of moved you onto this new sort of phase in career. Which I think I see so many parallels with what developer experience professionals do and what we do every day as academics.

Can you speak more about connections that you’re seeing between your history as an academic and what you do in the day to day as not only a ghost developer, but someone who speaks to the community more broadly that has the pulse of what developers actually are seeing and what they want?

Ryan: Yeah, so kind of I think made the like about what’s, how does the skills that you kind of develop in academia help you or benefit you in a DevRel role or even just in engineering, I think. So I think there’s a couple of different things. One of them is, so I think that one of the big things that that’s really beneficial is that in academia,

One of the skills you develop, and I think it is a skill, is really reading and reading difficult things, reading hard things. And as many tutorials there are about writing code, there’s not that many about reading code. So I think that having that skill of already being able to read and to take on something that maybe doesn’t make a whole lot of sense at first, at least, but being able to work through it is a really great transfer of skills from academia to engineering.

Another one is that I think the ability to teach yourself or to learn is a huge one. So this is something also that I think, you know, kind of we might take for granted, but so when you’re studying in academia, especially at a higher level, there’s only so much that you’re gonna learn in a class. A lot of it is something you’re gonna need to teach yourself. And that means not only just reading a book, but also figuring out what it is you need to learn, and then what you need to learn to learn that. And that’s a huge, huge skill, especially, right? That development, web development, shifts so quickly. I haven’t been in it that long, but already, like at one point, the single page applications were huge. And now that’s kind of fallen out of favor. And then there’s now so many different frameworks. And all that sort of different stuff. So you always kind of have to be able to learn that next thing. And so I think that that’s a huge skill to have.

I think one of the negatives though, I think there is also maybe some negatives is that in academia, so when I was working on my dissertation, it was working on writing that had been done 200 plus years ago. And if I published my chapter or a book paper or something this month or next month, it wasn’t that big of a deal. But I think in engineering, in getting kind of documentation fixes, that sort of thing, it moves, it’s much more time sensitive. So you kind of have to really be prioritizing and being aware of getting things out quickly and knowing what needs to get out, which is a little bit different than in academia. But I think the art of reading is really important and a big skill. And then also just being able to teach yourself.

Kate: Yeah, I’ve noticed that as well. I tend to frame it as research with what I do more as an analyst. But I mean, it’s the exact same skill that you’re mentioning, where I’m able to use my background as an academic to find resources that are going to give me the information I need, skim what I’m finding so that I can get to the meat of it real quickly, try to my bullshit detector, I think, is pretty good. But then also, yeah, like I just dig in and interview folks that are giving me the information I need.

And then, yeah, what you’re saying about the time sensitivity, I’m definitely seeing that as well, where there’s so many jokes about reader number two and peer review. And I’m a bastion for peer review. I’m like, yes, we definitely need peer review. My research in certifications and upscaling, I’m always bringing up the accreditation thing. But you’re right. I know there’s something about the fact that we need to move so quickly in this space. And with the rise of AI, it’s going to be four times as quick. So yeah, like how do you adhere to that, the medieval model of the university and still hope to keep up with what’s going on in industry? Yeah, it’s a real question, but yeah, that certainly resonates with what I’m seeing as well. So yeah, I guess, thank you for laying it out that way, the good and the bad, because I think we do tend to think of like academia’s, you know, or coming in with a PhD to any field, it’s like, oh, well, this is an unmitigated good. Not sure that’s always the case.

Ryan: Yeah. And I think too, there is that, and I think you kind of brought it up, but there is that in academia, and it depends a lot on the field, but in the humanities, there’s sort of this desire to be exhaustive and to kind of explore every nook and cranny to your heart’s delight in some respect, but that’s just not possible in engineering, right? You need to be much more focused and kind of be able to separate what’s good and what’s bad or what’s useful and what’s not.

Kate: Yeah, I know. I know it kills me too, because I want to go down that rabbit hole and I want to get all the information. I want to read all the things before I hit publish, but you just can’t. You really have to just be like, okay, I’m going to time block an hour to do this task and whatever I find in that time is probably good enough, you know, but you know, because we have spent what, a decade in that role, hopefully what we’re finding is the most, you know, resonant, I guess, I don’t know. It reflects the sort of breadth of what we’re looking for, that it actually gets to the meat of it. Yeah, I wonder these things. But it also kind of forces me to like be working all the time where I’m always listening to podcasts as a way to try to like keep up with the newest things. I mean, you know, you and I both kind of sit in the front end space. And so, yeah, I’ve just always got like this, you know, all these podcasts that try to keep me so that I can be, you know, washing dishes or doing something around the house, watching my kids, but also at the same time, be trying to work because there’s just so much and it’s like impossible to keep up.

Ryan: It is great. I mean, that’s how I found out about you was on the podcast, which is, yeah. And so I’m always listening to those and my favorite, which is, I mean, I’ve been doing it forever and that’s like when I got started in it, I was listening to podcasts a lot. So I like to run and I’m in a, like a neighborhood running group, but I’m always listening to web development podcasts as I’m running, which is kind of weird, but it works. It’s great.

Kate: That’s amazing.

Ryan: And I can even think about there’s a podcast by Syntax, which I like their podcast a lot. But they had one earlier on about kind of, I think the different array methods like filter and sort and map and all that sort of thing. And I can remember now when I think about that, I can remember myself running, I was living in South Bend at the time, but like where I was running when I was listening to that podcast. So it’s just, it’s kind of funny.

Kate: I know exactly what you mean. I can always now when I recall information that I learned on podcasts, I can think of where I was standing when that happened. Yeah. It’s funny how that works instead of like, it used to be when we had physical books long, long ago, right? I would remember where in the book something would occur. And now I can remember where I was standing. Yeah, this multimodal world we’re living in, I don’t know. Now we’re all going to get AI pins, I guess, and be thinking about what our hand was doing at the time.

Ryan: Right. Yeah.

Kate: Yeah, that’s funny. OK, so let’s talk a little bit about DevEx, because I think that that’s such an interesting space right now, and it’s really going through this evolution. So it’s become more and more contentious since tech’s economic downturn, I’d say, last year. So there were a number of high-profile layoffs, and then folks just leaving the space because they were unhappy with the mission and where they think it’s going. So I’m thinking particularly of Ali Diamond’s video, Why I Left Developer Relations.

So do you have a sense of the state of DevEx, as we near the close of 2023, and how do you think this role is going to evolve in the next year, maybe the next five years? I won’t ask you to look in your crystal ball 10 years down the road, but where are we going with this space?

Ryan: Um, it’s a good question. I feel like I don’t know. I don’t have a good sense or a good answer for you, but I do think that. It is, I mean, kind of what’s happened is definitely a symptom of just the larger tech landscape and that sort of the contestations between VC or capital and tech and everything that kind of falls out from that. I think that there’s always going to be certain tensions there. And I don’t think it’s necessarily unique to have like developer experience or developer advocacy. I think that everyone’s kind of subject to it in one way or another. But I do think that one of the things that is interesting, and I think some people don’t like it, but I think it’s actually a positive, is that this role will continue to be amorphous. So that what this means is going to be defined according to the needs of a company, first of all. But it is also going to continue to be a role that needs to wear a lot of different hats. And I think that this actually, to tie it back to the question of having skills from academia, it’s very similar.

And so I think that’s also why someone who’s maybe coming out of academia could be a role for them, or at least having similar skills. So I think, so a professor, an academic, a scholar needs to be able to talk to students who are at the beginning of their learning journey, but then also their colleagues who are at the like highest levels of it. So you have to be able to context switch between this is my, like, you know, this is like, let’s shop talk industry terms, all that sort of thing, the words that we can use, the vocabulary we can use to discuss this at a high level and communicate more efficiently to, like, you might have no idea what’s going on. Let me introduce you to this topic. So being able to do that, I think, is a really important part of the role. And it’s very similar to what a professor needs to do. I think also academics need to navigate that kind of, like the administration, other colleagues, that kind of whole bureaucracy of a university, which is similar to the needs of the board or of your management or whatever of the company, you know, at the same time of your own kind of, you know, research ethics or whatever you wanna, you know, is important for you to push or representing the needs of the user or this sort of thing. So there’s always that kind of tension there that you need to navigate, but that’s something that’s gonna be more familiar to a professor in some ways.

And then also, of course, creating the materials. So creating pedagogical materials like videos, tutorials, documentation, and then even sometimes doing the work of coding. All of that is similar in academic needs to not necessarily code, but produce all that sort of stuff too. But I think coming back then, that’s the role in a lot of ways of the DevEx person, going from talking to different audiences, engaging with community, producing these educational materials, but then also writing code and making sure that the kind of environments and infrastructure and everything is working as it should be.

Kate: All right. And since we are on the Docs Are In, I must dig into your mention of documentation and upscaling documents. So can you tell me a little bit about what the documentation looks like at Ghost and how developer experience ties into that as a philosophy and why it’s just so important to have great docs?

Ryan: Yeah. So I think that from just a kind of a higher perspective, I think why docs are so important or at Ghost, why they’re valued so much — because it is something that the company takes very seriously and that we, especially as a publishing company, like the written word is very important. Everyone in the company writes to some extent and so everything’s really documented well, even internally.

So I give a lot of props to them for that. But it is also thought of as, it’s kind of our primary marketing tool, I think. So it’s the way that our, we want our users to succeed as much as possible with our product or just in general to do well. And our docs, that’s the goal of them. So we have several different facets of it, especially — so Ghost, [we] talked a little bit, so it’s a publishing platform. It’s open source, so you can run Ghost yourself. We have a one-click install on DigitalOcean, but you can run it pretty much anywhere. It’s a JavaScript app, a Node app. So anywhere you can run a Node app, you can run Ghost. But we also then, the way that we make money is through a hosted product. So we host Ghost for you. Take care of all that kind of infrastructure and give you some nice, you know, CDN and some caching and all that sort of stuff. But we’re also, so something that’s interesting, we are, so I didn’t quite get away from nonprofits because Ghost is a nonprofit foundation. So all of our metrics are open. You can go to ghost.org/about and see how much money we’re making. All that money needs to come back into the company. We don’t have any shareholders or any VC. But then we also have, you know, so there’s about 24,000 users on Ghost, our hosted platform. And then we have lots of others in other places. But this sets up a kind of a documentation nightmare because we have a lot of different planes of how people could be using Ghost. So we have people that could be using it on our hosted platform.

We have people who could be doing self-hosting on like a Raspberry Pi in their living room or something. So there’s a wide range of how people are using our product. So we have different kind of outlets for each of these. So we do have our help documents for the product where if you’re just trying to use it, that’s where you’d go for that. We have a resources documentation which is a newsletter, but then also documents about people who are just trying to write and cultivate an audience so that they can succeed in that way. And then the parts that I’m in charge of or responsible for are more developer-centric stuff. So we have things on like how you create a theme, but then also how you self-host. So that’s like our developer documentation.

And then we also have tutorials, which is a different type of content for interacting or doing different things on Ghost, but for a more technical perspective. So I think that one of the things that comes out of that is that documentation isn’t a monolith. There’s a lot of different facets of it. And specifically, I think a big one that we focus on, for me is a big focus is the difference between a tutorial and like developer documentation. Developer documentation is more of a manual. It’s something kind of, you wanna just get the information quickly, kind of you know what you’re looking for, you’re trying to find it out. Whereas a tutorial has more of a narrative, has more of a story. There’s kind of a beginning, a middle and an end. There’s a problem that’s resolved. It’s something that’s a little more engaging, has a little more personality.

And so I can talk more about that kind of approaches that we have to documentation, but that’s sort of the overall landscape, I guess, of documentation at Ghost.

Kate: Yeah, I mean, I appreciate beginning with a philosophy, but I think a lot of folks who are listening to this probably are interested in the sort of tooling that you’re using just because it’s such a big part of writing great documentation. So are you able to dig into that, get into the weeds with us a little bit?

Ryan: Yeah, for sure. So I guess one thing, I’ll take a step back. And one of the things that I’ve learned from being at Ghost, but I think is a really great approach to documentation, which isn’t always, I think, the normal one, maybe. But that’s to begin with your audience. So rather than, so that’s where we begin with all of our documentation is with the audience. And what I mean by that is that, so it’s nothing too foreign or too crazy, but we come up with persona for each one of the possible like people who could be reading our documentation. And we ask sort of not only like, you know, what is their skill level or where are they at in terms of what they know, but also like, what are they looking for, not just out of this documentation, but in life, kind of having this idea really of a person.

Like what’s going to stand in their way to succeed? What’s going to, like what are they worried about? Who do they look up to? These sorts of questions. And it might sound like a little bit hokey kind of or something, but it really helps you when you then start writing to kind of know who you’re writing to or for. And it helps with kind of how you frame the documentation and then also how, like what you leave in and what you take out.

So what you can assume that they know or they don’t know, or I think another kind of facet of this or part of this is that, especially from an engineer will have an, oh, we should document everything and include everything. And I think that part of that, you get too much noise to like signal the noise, you know, that ratio gets, gets messed up. And so you really want to make sure that you’re only including what’s really necessary.

And you don’t need to do — then that means not documenting everything. But having that persona and starting from that persona, or multiple persona and even sub persona and having users in mind, I think that’s the thing that can elevate your docs frame and help you write the best in terms of actual, just more concrete resources. So I think that style guides for technical writing in particular are really important.

So this includes, you know, how you write about the product, how you write the voice and tone, and even how you phrase certain things like tense, what tense you use, all that sort of things helps bring a lot of consistency. And I think that’s probably not something that’s too uncommon at companies, but specifically not just for general marketing, but specifically for technical documentation. Do you all have a technical style guide?

Kate: We don’t, not at RedMonk, no. We kind of do it, I don’t know what, off the hip. So that — I think each of the analysts here, we tend to have our own voice, which is fun, but no, it’s probably should be on our list of things to do.

Ryan: I do find it’s really helpful just even when you write URL, do you have a capital letter in the lowercase or all, these sorts of just kind of little things. It also takes out some of the decision fatigue when you’re writing. Another style guide we have that’s been really helpful is a screenshot style guide. So when you take a screenshot to ensure you get high quality screenshots. In this, so for instance, like one of the things we have is if you’re taking a screenshot, and the application’s white or whatever, and then you’re putting on a white background, make sure that has a border so you can kind of differentiate. And there’s lots of other little things you can do in that way. More concretely, I guess, there’s ShareX on Windows, and then like CleanShotX on Mac, which really are awesome, especially the CleanShotX on Mac. I’m sure lots of people use it, but it’s a fantastic screenshot utility.

I also really like there’s a site called screely.com and they also have a Chrome extension that you can use but that will produce a screenshot inside of a browser frame, like a browser window. And that’s really nice free utility for that. Other tools that we use, I like to use for documentation. So I think diagrams and art, creating graphics for documentation is really interesting. And I’ve seen some people who just do amazing stuff, but I think that there’s oftentimes where a diagram or a graphic or something like that can convey an idea or a concept much better than just writing it or describing it. And so for that, I usually use things like Excalibur, Figma, PowerPoint, Keynote, those sorts of things to create that, nothing too wild. But I really would love to see to more people and how they do that. I feel like that’s something that there’s some people who are really talented at that. Another tool that has been really helpful is feedback. So some way for your users to give you feedback on your documentation. So we use a product called Appzi, A-P-P-Z-I, which is free.

But we have at the bottom of a help doc or the tutorial, what did you think about this? And it’s great for people telling you. It’s usually they’re going to tell you it’s bad and something’s wrong with it. But as is the case, they’re not really going to fill it out if it’s amazing or that once in a while it happens. But it’s basically telling you this is out of date, it’s not working anymore, there’s a typo, or some kind of problem. But it’s really good because you can get that right away, act on it, fix what needs to be fixed.

And then the last, well, maybe two more. So the one, another one examples. So examples are really important. I have three rules about examples. So when you’re thinking about examples for documentation or for a tutorial, so don’t be blasé. So don’t pick something too boring. Try to pick something that’s going to be exciting or fun, right? Don’t be too abstract.

I really dislike when you do a tutorial or a documentation, and they pick either something that would never be a real life or a real use case. It’s so removed from what you would actually be trying to do that it doesn’t really help you, or it’s even so in such a vacuum that it doesn’t take into any of the real complexity. I mean, you kind of have to navigate there, but I like when it’s like, this is actually something that someone would want to do.

And then I think the third is don’t be biased. So this is a big one where, you know, make sure that if you’re talking about an engineer, it’s not all white males. It’s you know, you have diversity in your examples. Another big one that you need to look out for is if your audience isn’t, you know, in the US or is worldwide, is your example going to make sense to an international audience? Is there any kind of cultural norms that you’re assuming that might not play on a larger international stage? I think I had read something one time about someone did a whole thing with cats, and then in someone’s culture that they’re reading this, they had no idea what, they were very confused because the cat wasn’t, didn’t have the same cultural kind of position. And so this is just something to be aware of. So I think biases and yeah, and kind of cultural assumptions.

Then the last thing, which is kind of like, pretty big right now, but AI. So I think it can be a huge tool, great tool for writing docs, of course. I think also though that the docs are what AI is gonna ingest or what’s gonna make up the language model. So this is even a better or like more motivation to have as good as docs as possible. Especially I think something that’s gonna become more popular will be this like retrieval augmented generation bots where it’s kind of the language model and then it’s your documentation on top to give a very bespoke ability for people to interact with your documentation. But that requires you to have really good docs or else it won’t work or at least some kind of educational materials. So producing that is important, but I think it’s, you know, you kind of need to know how to use the AI and then it’s still where it’s going to require a lot of input on your part or at least revision on your part because what you usually get out sounds like, it doesn’t sound like you, it doesn’t have that personality or voice, which I think is important. But yeah, so that’s a lot of different resources and tools.

Kate: No, this is awesome. I love it when we get into brass tacks like that. And I also appreciate that you brought up the idea of accessibility, the fact that you’re speaking to a broad audience and you don’t always know who’s going to be reading this. And then, yeah, of course, got to talk about the AI chatbot version of our documentation that is clearly going to be the future. So many folks have created chatbots that do this already, whether they’re also generating code snippets, but certainly able to query the docs.

One question related to that is, where does the experience of the developer come in? Do you tend to write documentation that you said that it needs to think of experts as well as new users? But how fine grained does that get in terms of reaching junior developers and senior developers who just know how to do things generally, but then also can get past it. And maybe, I don’t know, can we tie this into the idea of pedagogy? I mean, how do you use documentation as part of a larger education portfolio at Ghost or just in general?

Ryan: Yeah. So I think it can be fine grained in some respects. I think it comes back to a little bit that documentation is in a monolith. So there can be lots of different kinds of documentation. And I think that persona enters in a little bit more for certain kinds of documentation, like a tutorial. So we have ghost.org/tutorials.

The tutorials, which the organization might change soon, but right now it’s based on the persona. So there’s fundamentals, level up, do more. And we have very specific guidelines. Like does this tutorial assume a knowledge of CSS and HTML? Does this assume, you know, and that’s like how we put it in there. For our other document, like more of our developer docs, it’s much different.

It’s kind of a single level, I would say, where it’s more, you know, we’re going to assume you have some knowledge of what’s going on here. And there’s not as much of the differentiation. But I think that, you know, in terms of documentation at its heart, it’s just some words on a page to communicate knowledge. And that’s been a standard for a long time. So I think it’s a good, like it’s a good way to do it. It’s a kind of industry best practice. But I think that probably, I think the developer experience or thinking about developers in terms of pedagogy, there are a lot more or newer tools that are coming out that make, I think, this sort of thing easier. And I think some of the bigger people in the space have done good jobs at this. And I’m thinking here like where you can have the, you know, sort of live code playgrounds or you can do launch VS Code in your browser with the whole project setup type of thing. And that’s something I think that Ghost, we want to move toward doing more of that. It’s just a little bit that takes more infrastructure to set up. But I think doing those sorts of tools in terms of pedagogy, specifically for developers, are really exciting and help do a lot where you can really do it in the browser. I think Svelte does this really well.

They have an interpreter right in the browser where you can write spell code and see what the output is and see if it’s going to work. And that’s connected right into their docs, their tutorials. So I think that’s a kind of cool thing that will become more and more possible. And I mean, it already is, but it’ll become even easier, I guess, to do.

Kate: Yeah, that’s fantastic. Did you teach much when you were an academic? Was that a big part of your role?

Ryan: Yes. So Villanova had a very strong pedagogy focus. So as soon as you started, you, I think in your second year, you started maybe TAing and then third year teaching, but I taught a lot. Yeah. I taught a lot of intro to philosophy was the main class I taught, but then I also taught some other kind of related courses, you know, other philosophy, higher level philosophy courses.

Kate: Yeah. So does doing this sort of work kind of scratch that itch of being in front of a classroom and getting to expound upon things that are very interesting and use best practices for communicating information, interactive tutorials, speaking in a way that’s going to be accessible to the greatest number of folks in the room, things like that?

Ryan: I think so. So I think that, so far what I’ve done, I do have videos, I’ve created some videos for Ghost and have my tutorials. It does a little bit, but it’s not quite the same. I think that the being in a classroom is a different, it’s fun. I mean, and I do miss that. That’s probably the thing from academia that I miss the most. I think the closest you get is when presenting at a conference. It’s pretty fun. I would also like to, which I haven’t ever done before, but doing some streaming. That seems like it could be fun. Where I’d love to like build something on stream, but it also seems like a lot of work and pretty hard. And the people who, I mean, who do it too are — it kind of walks that line too of entertainment versus education or what exactly the difference is, but you do get some more of that,you know, instant feedback or interaction, which is cool. I don’t know, how do you feel about it?

Kate: Well, I mean, first off, you’ve committed to creating a stream now, Ryan. So, you know, we’re holding you to this. No, I love teaching. I thought it was a lot of fun. I got such a rush from being in front of the classroom, but you know, like you, I got out because it’s not a viable career path for most PhDs, you know, I just, there’s, you know, in terms of finding a job with healthcare and, you know, able to buy a house eventually, right? There’s all these sort of things that you just don’t get as an academic, unfortunately, because I tell you what, I could walk out today and find a job adjuncting at any of the universities here because they still need the teachers. They just, you know, it’s not a sustainable career, unfortunately, so, but that is a different, we’ll leave that for another video.

Ryan: Yeah, we could speak another hour on that.

Kate: But so I think that’s probably a good note for us to end on, our love of teaching and the fact that the classroom was really where folks with our particular proclivities can shine. So I want to thank Dr. Feigenbaum for coming on The Docs are In today. If you want to follow any of the streaming work that he’s going to be doing in the future, where would be the best place for folks to follow you?

Ryan: So you can find me on my website. So ryanfeigenbaum.com on Ghost. You can also find me on GitHub. So @royalfig, that’s probably the two best things. I’m also on Twitter and Mastodon, but I don’t remember what my things are at the moment. I think it’s, so I’m usually @royalfig. So Feigenbaum in German means fig tree. And Ryan kind of means king or royal, so I have this kind of royal fig name. That’s where you can find me most places.

Kate: All right, excellent. Well, with that, the Docs are out.