Software Sessions

Philip Kiely is the author of Writing for Software Developers and has written for companies like Smashing Magazine, CSS-Tricks, and Twilio.We discuss:Doing research beyond the first page of search resultsWriting e-mails people will readThe "get it done" and "learning" modes of readersMaking articles easily skimmableLong form articles vs Stack OverflowPromoting and launching a bookBorrowing the reputation of othersRelated Links:Writing for Software DevelopersPersonal Site@philip_kielyStripe documentation example (Complete code sample with switchable frontends, backends, and walkthrough as you scroll)Go by Example (Straightforward samples readers can copy/paste)Tailwind UI (Sustains Tailwind CSS open source project by providing prebuilt components) Music by Crystal Cola: 12:30 AM / OrionTranscriptYou can help edit this transcript on GitHub.Jeremy: [00:00:35] This episode, I'm talking to Phillip Kiely. He's the author of the book "Writing for Software Developers." We usually talk about code on this show, but knowing how to communicate with developers is just as important. We discuss topics like making articles easily skimmable and writing with a specific audience in mind as well as crafting emails that people will actually read.We also talk about his experience creating, promoting, and launching his book. And what he learned from his many interviews with people like Cassidy Williams and Patrick McKenzie. If you want to get better at writing or you've ever considered launching a product, I think you'll enjoy this conversation with Philip.Phillip, you recently graduated with a computer science bachelor's from Grinnell College and I'm sure you did a lot of research. When you have something new that you're trying to learn how do you get started?Philip: [00:00:48] As a developer, I spend a lot of time getting error messages while I'm coding. The first thing I do whenever I get an error message is I just plop it into Google, see what comes up, see what people are saying on Stack Overflow, GitHub issues, that sort of stuff.I also have a background in journalism. Having worked at the Grinnell College Scarlet and Black newspaper I have a lot of experience going and just talking to people doing interviews. And that's why that felt like a very natural thing to include in the book.It's also something I've been fortunate to do in articles. For example, I wrote an article in Smashing Magazine about remote part time teams using agile development methodologies. As part of that, I did a quick email interview with one of my professors at the time as well as a different professor who had written the book that we were using as the textbook in this class about software development.Bringing in those outside perspectives allowed me to write an article that was so much better than anything I could come up with from my own experience. So really when you're looking for things to use in your own writing look broadly and don't just look at the first page of Google results.Ask specific questions, whether it be of a search engine or of an experienced person in the field. And then cross check that information against each other to make sure that it all matches up and presents the information in a way that's orderly and meaningful to the reader.Jeremy: [00:02:19] The people you're reaching out to most likely don't know you and you're asking them for advice or for an interview. How do you get these people to say yes and agree to help you out?Philip: [00:02:31] It depends on what I'm asking for. In the case of the article that I was mentioning earlier, I was asking for maybe 5-10 minutes of their time to do a quick quoted answer to one or two very specific questions that I knew they had off the top of their head because I had just read a whole book about it and that is actually a pretty easy ask. Most people who are in the public do receive a lot of email but don't necessarily receive a ton of these sort of requests on a daily basis. And if you make yours compelling and specific they are pretty likely to respond to you.I'm nowhere near the public profile of the people I've been reaching out to. But over the past week with this book launch, I've gotten a ton of inbound emails so it's been really interesting to consider this question from the other side. Considering which of these emails I'm taking the time to write very detailed responses to. Which ones I'm shooting back a real quick one liner. And which ones I'm just pretending I never saw and sticking it in the trash.I think that making my emails to these people who I'm trying to get interviews from very short, very specific, very relevant to their interests. Showing that I'm not just reaching out to them because they're a big name or because I had an idle inclination but because I'm very invested in a project that I need help with.In terms of finding interviews for the book. It was the same process just magnified because instead of asking for a quick email exchange, I'm asking for 30-60 minutes of their time. I'm asking to ask them some really tough questions about their work and have them think through it and give answers that are going to get published and have a bunch of people read them.I'm also implicitly asking them to endorse the work that I'm doing and the product itself with their presence in it. I have the picture of everyone who I interviewed on the sales page, for example. And with that the pitch is a little different. It's about investing credibility. The people who I interviewed for this book were kind enough to invest some of their credibility in this project and if the book was total garbage they would have gotten a negative return on that investment and future projects that they're involved with.On the other hand, if I put in a lot of work editing and producing a great book then they're going to get a positive return on investment and to some small degree be even more credible for their involvement with this project.I never state that explicitly, but throughout the process both the first short cold email, the scheduling, the interview itself, and then keeping them up to date on the progress of the project after the interview... I just have to deliver to them professional correspondence that gives them confidence that this project is going to have a positive return on the credibility that they invest in it.Regarding the interview itself... I want to make sure that I'm asking them questions that people haven't asked them before or at least asking them these questions in new ways that allow them to say new things that they haven't said publicly in the past. Both because it's more interesting for them and it allows me to create a better product in doing so.I'm going to inform them that I've read their work and not just by saying, "Hey, I've read your books" or "I've read your articles", "I've listened to your podcast". I'm going to say something specific that I liked about a previous thing that they've done. Or I'm going to reference that I just interviewed someone for the book that they know from a previous interaction. By establishing that credibility and proof that I'm going to be very invested in the project I can make them more likely to respond.The final thing is that it really is a volume game as well. I sent almost a hundred pitches to the sort of people who you would expect to see on the list next to the 11 who did say yes. A number of people were just too busy to respond, have a policy against doing interviews or for any number of reasons didn't want to appear in the book, and that's totally fine that's their prerogative.What I would encourage people to say is, okay, if I need 10 interviews for the thing that I'm trying to do I'm going to send a hundred emails. If I'm writing an article and I only need one or two interviews I'm going to send 10 emails. If you get more interviews than you're looking for, that's great. I was only planning on putting eight in this book and I got 11. And they all add a ton to the product. It takes a lot of time because you are sending specific targeted emails at scale but it was also worth it.Jeremy: [00:07:18] So basically when you want to talk to someone... do your research, read their work, learn a little bit about their background and show them that in your email so it'll be more personal and it will make it clear that you're not just shooting emails out to everybody and hoping for a response.Philip: [00:07:32] Then the other approach that you can take is more of the approach that I used pitching you to come on this show. I think I wrote you about a three sentence email and the first sentence was: "Hey, I just graduated from college and made $20,000 selling a book." The second sentence was: "I'm doing a podcast book tour." The third sentence was: here's how you can contact me.When you're doing cold email like that it's almost like a non-negative form of clickbait. You're trying to intrigue the person who you're reaching out to say: Hey, I'm going to give you some information that might be interesting to you given what I know about your background. I'm going to include links so that you can verify that I'm not some scammer. Then here is the exact actionable steps that you can take with this information if you're interested.Jeremy: [00:08:22] It was very straightforward. Then if you click the link, you see the landing page and see all the people that you interviewed whether that's Patrick McKenzie of Stripe or Cassidy Williams from Netlify. And I think anybody who sees that landing page and sees all the people that you interviewed it'll probably make them think there's something to the book so there's two different strategies for getting someone to notice your email.Philip: [00:08:45] Right. You don't need that. I didn't have any of the social proof when I was getting the people who I was interviewing to interview with me. But if you have it you should definitely use it cause it makes it way easier.Jeremy: [00:08:58] And when I received your email, I previously saw the post on Hacker News about your book. It was really easy to make that connection because I saw the same title in your email and I didn't have to think too hard about it.Philip: [00:09:13] All credit for this title goes to my mother. I wanted to call this book the "Technical Content Development Handbook" and "Writing for Software Developers" is a much better title because it more accurately describes what the book is about, who the audience is, how they're going to use it. But also when you're sending cold email like this, every single bit of this very, very short email counts a lot. Having every aspect of your product optimized for people can understand this quickly is really helpful when you're sending cold email.Jeremy: [00:09:45] You had an interview with Cassidy Williams and she was saying developers don't like being sold to. I think developers like in a broader sense knowing the specifics of what they're getting.They want that title that says this is what this book is about. So that was a smart move.Philip: [00:10:07] Yeah. Her interview definitely influenced how I created the sales page for this book by highlighting the interviews that I did, providing a free sample chapter, answering a bunch of made up questions in my frequently asked questions section. All of that was designed to do exactly the same thing that I do when I'm writing articles for clients that then use them for content marketing. I'm just providing a bunch of information and trusting that the people in my target audience are smart and engaged and want to find valuable things on the internet and that all I have to do to make the sale is provide them with the information they need to make their own decisions.Jeremy: [00:10:49] Now that you're on the other end looking at inbound emails, what gets you to click versus just keep scrolling?Philip: [00:10:59] It's a little difficult because there are so many different things that can make me interested. I'm still new to this so every email I receive is in some way incredibly exciting. Check back in 10 years and see if that's still the case. But I think that having confident well written emails about just about anything will pique my interest as long as someone demonstrates that they've put a bit of thought and effort into the communication. I feel somewhat of an obligation to respond with an equal amount of thought and effort.Jeremy: [00:11:35] Instead of emails, how about when you are researching something. You're trying to learn how to do something and you see the list of tutorials on Google. Do you have a heuristic or something that you look at to decide this one doesn't look good I'm going to keep scrolling?Philip: [00:11:50] Absolutely. And it depends on why I'm doing research. If I am programming myself and I want to solve an issue like I was talking about at the beginning of this episode I'm just going to be clicking through things as fast as I can, looking for code samples and trying it and seeing what works.On the other hand, when I'm trying to learn a new skill or get some general background knowledge because I'm about to write about a topic, I do a much more methodical approach where first I click through the first few results, find something, read it, and then I read all of the things that article references. And then I read all of the things that those articles reference. It's more of a depth first search than a breadth first search.And by doing that, I rely on the efforts that other authors have made to curate good information in the text or a further reading or sources section at the end. And I make the conscious effort to do the same thing in my own writing including in most articles some combination of in text citations or a list of further reading at the end that both talks about the exact topics that I used in the article and maybe includes all of the sources that I've cited as well as interesting things in tangential topics that might not have made it into the article proper, but are going to be really useful to someone embarking in a similar journey trying to figure out a topic.Jeremy: [00:13:22] There's two very different modes of research. You're saying one is I am working on a problem right now and I want to know how to solve it. And for that you're basically scrolling through and looking for code samples that you can copy and paste.And the other would be trying to get some kind of deeper knowledge and the way you search through things is very different. I think it's interesting to think about it that way.Philip: [00:13:50] It is and it's very important to think about your audience's mode when you're writing. A lot of people talk about picking an audience, finding and defining exactly who you want to write for, and figuring out things like: How much programming experience does my potential reader have?Those questions are very, very important and can be difficult to address because as a writer you get to define your own audience. You write for someone with a specific background and that person comes and finds your work if you do a good job of distributing it. And people without that background might come across it but don't read it.However when you're thinking about your audience's mode that is something that you have even more control over because you can write the exact same topic with the exact same background two very different ways depending on whether or not you're trying to get someone to sit down, work through an entire sample application with you, and really develop a broad and deep understanding of a particular topic.Or you're just trying to get someone in and out and get them a code sample and get them a quick explanation of why they might be experiencing an error and what they can do in the future to resolve it and then get them back to their work.I think great publishers understand this difference and they're going to hire people to write technical content or they're going to write technical content themselves with an eye towards intentionally creating both types of content and trying to avoid hanging out in the middle where they have an article that's difficult to parse and doesn't provide sufficient depth.Jeremy: [00:15:28] When I'm looking for a specific code sample a lot of times I'll look for links that are to Stack Overflow because I know that if I go to Stack Overflow then it's going to be the short code snippet and I'm not going to have extra time trying to find the thing that I'm looking for.How do you decide whether to go to Stack Overflow vs click on a long blog post?Philip: [00:15:56] Stack Overflow is an incredibly important part of the technical content ecosystem online. When I think about my competitors I don't think about the people who I'm competing against to maybe write an article for a client or land on the front page of hacker news every day.I'm competing against the vast amount of free technical content already available on sites like Stack Overflow and what Stack Overflow is really great for is exactly this quick answer stuff that we've been talking about. But the places where I think blog posts can shine is when someone is not asking how, but instead asking why or what or who or any of these other questions.Because if all you need is a code sample it's probably because you already know how to use it. You already know exactly what you want to do. Bringing back my original point about asking specific questions: Sometimes you don't yet have a specific question and your goal in research is not to find an answer, it's to find a better question.And a lot of times going to longer form resources like blog posts or articles or even books is a great way of asking better questions which is a really, really critical first step in research that is easy to overlook because it might not feel like progress. It's kind of like when you're programming and you've been stuck on an error message for awhile and then you change something. And you got another error message but at least it's a new message and that's really exciting and that feels like progress. The same thing with asking a newer, better, more specific question can be achieved by consulting longer form resources first. Then you say, okay, great. I know that I just need to sort this database index by date ascending rather than descending and that's my issue. That's what's causing all these problems. I can look up the SQL query to do that on Stack Overflow.Jeremy: [00:17:51] Yeah, that's a great point because stack overflow is not always the best place to understand why you would do something a certain way. Somebody will answer with a code snippet and if you copy and paste that, it'll probably work. But sometimes what gets lost is, is that the thing that you really should have been doing?If you're not quite sure what you want it makes a lot of sense to have that be a long form blog post or a book or something like that.Philip: Absolutely.Jeremy: [00:18:23] Julia Evans creates zines, they're these illustrated guides on technical concepts. One thing she recommends is that people write for one person.How do you decide who that person is and what's the best way to let the reader decide if they are that person you're writing for?Philip: [00:18:45] That's a great question because once you figure that out, everything else is pretty easy. A lot of the time I write for myself in the past. I write the guide or the article or the book that I wish I had that I wish I had been able to read before starting out on a project.But sometimes I think about, okay, I have a friend who wants to do something. I have a coworker who struggled with this. Just figuring out someone from my life who I can think about as a example of the audience. And again, that's sometimes, but not always me. That can be very helpful for solving this question and based on my interviews it's what a lot of other people do as well.Jeremy: [00:19:29] When somebody comes to the article, do you expect them to scroll through and figure out if it's for them? Or do you think there should be a more explicit sign post saying: "Hey, for this tutorial you should probably know these things."Philip: [00:19:44] I don't really believe in categorizing tutorials "This is a beginner tutorial" because maybe it has something really useful. And someone might overlook it if they consider themselves above that or on the flip side "This is an advanced tutorial" could scare away someone who is ready for it but just isn't confident in their work yet.What I think of as some of the implicit markers of a tutorial first is the setting up section. When you talk the reader through here's what you're going to need to configure in your environment in order to run my sample code. If you spend a lot of time walking through the exact minutia of here's how you set up a virtual environment in Python, here's how you PIP install a package. That's going to be a really strong signal that this article is for a beginner level reader and an advanced reader can go ahead and skip that and assume that their thing is configured correctly. Move on to the thing that they're looking for and you haven't really bothered them by including that setup information as long as it isn't pages and pages of it.On the other hand, if I was writing about a very advanced topic I might not include very substantial guidelines on how to get set up both because it's going to save some space that I'm able to instead assign to describing this complicated thing I'm talking about, but also because if someone isn't able to figure out the setup steps that I provide, then they're probably not ready for the advanced article itself.I think that the setup section of any article provides a very important form of positive gatekeeping in terms of implicitly informing people whether or not an article is written with an audience in mind that they were part of.Other than that, I think that like a focus on very specific titles. Not clickbait, but explaining exactly what you're doing, how you're doing it, why you're doing it, both in the title, the summary, the first couple paragraphs is a great way of letting readers know whether or not they're in the audience. And that even ties back to my own book because the title "Writing for Software Developers" lets anyone who's not a software developer know that they're probably not going to get a lot of value out of this book.Jeremy: [00:21:59] Rather than being this gatekeeper you let the reader infer it through the title, introduction, the setup steps, and hopefully they can decide from there whether it makes sense to keep going.Philip: [00:22:16] Exactly. The other thing about technical content in general is that it's an opportunity to provide people with a pathway into the field. People talk about how computer science is one of the easiest things to learn without going to college. I'm fortunate to have gone to a great college with very strong CS program but even still I learned a lot of the things that I use in my actual job and in my work outside of the classroom by using technical content. So I think it would be counterproductive to explicitly tell anyone: " Hey, this isn't for you."Jeremy: [00:22:53] When you are writing an article how do you decide the scope for it? To give you an example: You mentioned you had listened to the episode with Courtland Allen. He talks about a lot of different things that are interesting.For example: How he made his site stand out with the design, how he scaled his site, the technical stack. If you were going to write an article based on something like that, how would you decide whether to put it all in one or split it up into pieces?Philip: [00:23:30] If I'm faced with a very large project like that, I would definitely split it up into pieces. I mean, there's so many interesting aspects of Indie Hackers. I'm sure I could write a entire article just about, the CSS within the upvote downvote buttons. You can get very, very deep and very, very specific and there's a lot of value in doing that.On the other hand. One thing that was consistently mentioned in the interviews is that if you write a series of articles, people aren't necessarily going to read the whole series. So what I would focus on is picking out a bunch of the most interesting aspects and trying to create connected but self-contained pieces of the puzzle.For example, this is something that I've been doing for the past few months with Smashing Magazine. Every so often I've been publishing a Django tutorial that all fit together into a broader understanding of how to use the framework. But I'll also very intentionally create it so that they are individually consumable and do not rely on any other bits of the series in order for you to get the code samples up and running in order for you to get a understanding of what the topic of the article is and what the main takeaways are.I think I would do something very similar. I would take the smallest piece that I think will make an article, because I'm always surprised by how much bigger every topic ends up being once I started writing about it. I would find the most interesting nuggets from this massive project. I would build individually packaged tutorials around each of them. And that's where I'd start.If you knew it was going to be a book or a video course or something that was delivered as a continuous whole, that's where I'd invest some time in talking about, okay, here is the overall structure. Here's how all of these things connect to each other, and here's how you can identify patterns in your own projects or your own work that match patterns in this example and will lead you to the specific pieces of content that I've developed that might address similar issues to the things that you're facing.Jeremy: [00:25:43] You would default to splitting things up into as small a piece as possible while still being valuable on its own. And then if you were going to try a larger project you would have to know upfront whether that's a book or a video course.Philip: [00:26:01] Exactly. And the thing with technical content is you have to trust your audience a lot. For example, the first half of the book is about writing a 2000 word technical tutorial for clients and I talked about this for three reasons.The first is that writing a 2000 word article for a client is a great, achievable first challenge for people who want to get into this.Then there was also a large amount of demand from publishers for this exact format and style of writing.But the main reason is because this is what I have experience in but that experience transfers very easily. Everything we've talked about in this interview about finding an audience, figuring out your scope, figuring out how to make your code samples complete and runnable. All of that applies. If you're writing a book, if you're writing a README, if you're writing documentation, a Wiki, the skills are really transferable.Similarly, when I'm writing technical content, I have to assume that the people who are reading it are smart, they're engaged, and they're going to take the specific context that I've presented them. They're going to take their own context and they're going to figure out how to bridge that gap.Jeremy: [00:27:15] You had an interview with Chris who's a community manager at Digital Ocean and he mentioned how readers will skim code and images and they gloss over long paragraphs.Does that match with how you navigate content or is that more specific to when you're searching for a certain type of thing?Philip: [00:27:35] That interview had a lot of surprising things in it. And that was one of the most surprising to me because I spend a lot of my time when I'm writing focusing on crafting not necessarily sentences that my literature professors would consider to be well-executed, but at least competent English phrasing. And I spent a lot of time thinking about the readability of my paragraphs. Starting at one idea, flowing into another one, and to hear that a lot of people were skipping them was kind of disheartening. But then I did think about how I read content myself. I'm fortunate to be a really fast reader. If I'm trying to read a book with another person, it can be a little unfortunate because I'll get all the way to the end and they'll want to talk about chapter three. The way that I skim articles is I just read the text but really, really fast.Chris had actual statistics based on using Hotjar on scotch.io to see how people were actually interacting with the site. And in aggregate, a large portion of the people were just scrolling down to the first code sample, copying it, and when I think about the mode of: I need to solve a particular issue in this application so that I can commit it and go eat lunch, then absolutely that's what I'm going to do. As a technical content writer, there are two things I can do to address that.One is to increase the skimmability of my content as he was talking about. To maintain the same focus on good writing just put more white space in there, put more paragraph breaks, more bulleted lists, numbered lists, quick summaries. Because if those are going to be really useful to someone, I should absolutely include them. And it's going to do nothing to detract from the experience of someone who wants to really read and sit with the content.And then the second thing is when I'm considering how to write this stuff, I do need to focus a lot more on putting in code samples that are complete, runnable, and understandable without the context of the article around them. Even if that makes those code snippets a little longer.And it makes describing them a little more difficult because I have to parse through eight lines of code including some import statements or configuration. For the majority of the people in get it done mode who are looking at the article if that's going to help them copy it into their application more easily then that's an investment worth making.Jeremy: [00:30:14] Let's say I'm going through a tutorial and I follow the code as it's described and if it's missing import statements or it's missing steps to install prerequisites.That's a lot of time that's sunk. You end up googling how to complete the tutorial that you're currently working on. I can understand why that's frustrating.Philip: [00:30:36] Exactly, and that's something that is worth investing in avoiding. One of the best examples I've ever seen of this is Mark McGranaghan's Go by Example where every single code example on that entire site you can take it, copy it, and paste it into an online go interpreter or your own go environment, hit run, and there you go. It works exactly the way it says on the site. The value of that is incredible.One of the places we can see a real investment being made in that is with Stripe's experimental documentation that they published a couple months ago where instead of just showing people: "Here's the single function you write to integrate the payments API." They created sample applications. Not just one sample application. But the same sample application with three different backends, four different frontends, two different frameworks, all this different stuff. And you can mix and match these and download these sample applications.And then they also did the two column design that Mark McGranaghan talked about where you have the code on the right, the words on the left and they're matched up, and you actually click through the steps in Stripe's documentation and it zooms around in the code example that you're looking for, highlighting the blocks of code that are relevant to the information that you're taking a look at.By doing something like this, you're creating more than just a piece of technical content. You're creating an immersive experience where it's a guided walk through a complete piece of sample code and that makes it really, really easy to figure out how to bring in the thing that you need into the application that you're working on.Or if you're not in get it done mode, you're in learning mode. Then it's really easy to take a broader look at the application and see how it's structured, see the decisions that went into it in the high level, and understand how you can structure things similarly in the future.Jeremy: [00:32:38] It's letting the consumer of the content, the person who's looking at the tutorial decide whether all they need is the code and they understand just by looking at the code or whether they need that extra sort of guidance that's going to show up on the left side.Philip: [00:32:53] Exactly. And making something like that is not a small investment. I don't even want to speculate how many hours of engineering time went into that. If you look at the fully loaded costs, they probably spent hundreds of thousands of dollars of engineering time on this demo. Which is worth it for them because if it gets people to integrate Stripe in the applications then Stripe's gonna make some money.Individuals such as myself can't necessarily make a similar scale investment in technical content. I write almost exclusively about JavaScript, HTML, CSS, Python, Django, because those are the languages that I know really well and that I feel confident teaching people.And if someone would have asked me to write a sample application in 10 different languages and frameworks I just straight up would not be able to do a good job of that. When you're an individual and thinking about how to make meaningful investments in your work. When you don't have those sort of resources, what you can do is even if you're not doing it in a bunch of different languages you can still focus in on one and you can make a really great sample application that's complete, runnable, configured out of the box. And that's going to provide a smaller niche audience of readers that same value. And then what's great is it's going to be free on the internet so someone else can come along and say, Hey, I really like this. They did a really interesting thing here. I'm going to do something similar in my framework and language of choice, and that's how great ideas and practices can propagate around the internet.Jeremy: [00:34:31] When I'm trying to learn something, whether it's searching online or even if it's trying to do something in a company. The way that I typically learn and I think a lot of other people learn is they see an example of something somebody has done before. And that could be a sample project or it could be the way a certain feature was built in a code base at work, and just by seeing how somebody has already done it, it's not a full copy and paste, but it gives you this guide for how you can build something similar. And I think that allows people to be able to build something new a lot quicker than, just looking at API documentation.Philip: [00:35:17] Exactly. There's no new code. We're all standing on each other's shoulders. And I think that's one of the things that's so great about technical content is even though you know a lot of it's paywalled or a lot of it you sell to publishers who release it for free with advertising or content marketing.Ultimately we're all helping each other out to build things and it's about creating a corpus of knowledge across the entire internet that everyone benefits from.Jeremy: [00:35:44] I'm interested to see how we can improve how we share that knowledge going forward. Is there something beyond the current tutorials we have like full featured applications or templates that people could use to learn from.Philip: [00:36:01] I think that an under appreciated source of this knowledge is open source repositories. You can learn a lot just by going and inspecting the actual source code of big open source projects. Now, open source projects have a ton of responsibility already. The developers and maintainers and volunteers are under a massive amount of pressure to keep everything running and up to date and to continue providing new features that people are asking for often with very little funding.So I can't just go ahead and say: "Hey, open source maintainers. You've got to add a bunch of documentation." because that's just not a realistic thing to ask for.But I think that one under explored area that can be pretty interesting is taking a piece of open source code. And writing either as a separate thing or as a contribution to the repository directly an explanation of how it works, and I can give a anecdote about this. Well over a year ago, I was working on this application with my friend and I wanted to render an iPhone in CSS so that I could stick an image inside of it. And I found a library, an open source library that provided these beautiful CSS renderings and the one issue is that they weren't resizable. So I created my own fork of the library and wrote this Python script that used SCSS and some variables and some other things to go through and automatically convert all of these non resizable CSS devices into resizable ones. I used them and just sort of forgot about it.A year later I decide "Hey, I want to write an article for CSS Tricks. When have I done something cool with CSS before? Oh, Hey, this time with this open source library." I pull out the code. I realize that a year ago I had no clue what I was doing and was a terrible programmer. And so I rewrite the whole thing. Which is a very common occurrence when I pull something out from the past to use in an article the first thing I do is decide it's terrible and rewrite it. But that's an important part of my own learning process and then sharing that learning with my audience. So anyway, I'm here. I have this great code. I write an article about it. And CSS Tricks is thrilled. They publish it.What's super great is first off, this is increasing the visibility of an open source product, both the original one and then the modified version that I created.Secondly, anyone who comes to this modified version of the product and wants to know more about it can go look at this article and read more about how it was created and thus really understand how to use it.The third thing is that when people read technical content, as we've been talking about this whole episode, the first thing they do is they take it and they copy it and they paste it into their own applications. Whether that's personal projects, things for work, whatever. So when you're publishing technical content, the responsible thing to do is to make all of the source code open source under some very unrestrictive license. All of my clients do this. Either they'll release it themselves as open source. There'll be a disclaimer in the footer. Or what happens a lot is I create an open source thing and then I write an article based on the thing.I sell the article to the client, but not the thing itself that's not considered part of the work product. And while this might seem like a technicality, it is an important thing to think about in terms of how you're delivering value not only to the client or to your employer, but also to the reader. Because if you're going to create something useful they've got to be able to use it. Open source can help.Jeremy: [00:39:36] That's an interesting example of having this open source library. Having this tutorial or document that describes how it works and that helps other people learn how they can build something similar. And at the same time, you got paid by CSS tricks in this case.So it's like everybody benefits.Philip: [00:39:55] Exactly. It's an indirect model of promoting and funding open source software. And in this case this library is a very small scale thing. It's not something I've dedicated a ton of time to. And the original creators of the library used it as content marketing for their product.But ultimately, I don't know if this model is scalable. I don't think you could support the development of Django by just writing a ton of tutorials about Django. But I think that at the smaller scale it is just another way that individual developers are able to monetize our own and other people's contributions to open source software in order to create useful things and pay the bills.Jeremy: [00:40:44] Yeah. I think an interesting possibility that I don't think I've seen before is, there are some open source applications, like for example, GitLab is an open source project that's written in Ruby on Rails. I wonder if somebody could based on GitLab's code write a book or a series of articles explaining this is how we wrote a real world application in Rails. Because I think when you have a code base that is as large as their's is, telling somebody to just look at the source code can be pretty daunting.I think there could be room to come in and walk people through parts of the source code and have something that they can learn and take to build their own projects with. I think that's a really interesting possibility.Philip: [00:41:38] Absolutely it is. There are two great examples that I can give about the marriage of open source software, technical content, and a sustainable business model.The first is Taylor Otwell's work with Laravel which is a PHP web development framework where he and a team have managed to not only create really great open source products, really great technical content. But also charge for various value adds that larger corporations, larger teams who are using these products are able to invest a lot in because they rely very heavily on this as a foundational part of their infrastructure and stack. Which in turn goes back to fund open source developments that make this whole product better for everyone.Another great example is Adam Wathan's work with Tailwind UI. Tailwind is an open source CSS library that is very, very popular. It's kind of like bootstrap in my mind although I know that power users might disagree. The way that this is monetized is through something called Tailwind UI, which is a collection of components that you can buy either an individual or a team license to which was an inspiration for the team license in my own product actually.You can buy an individual or team license. And it's I think $300 or $600 and this gives you access to a ton of components and a ton of technical content about how to use these components and Tailwind in general to make your websites look great. And if you think about it, $300 is what, three hours of developer time? Maybe less if you are hiring very experienced developers and you have fancy offices somewhere. So it's a total no brainer to purchase a piece of not just technical content, but also reusable example code that you and your development team can use to create something that looks great and drives business results.One of the things that I drew inspiration from them as well as Daniel Vassallo's book is the idea of price discrimination with a corporate license. When you buy an ebook, it's kind of like buying a physical copy of a book. You're not supposed to email a copy of it to everyone on your team. But I figured that some companies have documentation teams or might otherwise want to purchase a copy of this for everyone working there. But I didn't want them to have to go buy a bunch of copies and so I created a team license. A new tier of the product on Gumroad. I added a one page PDF saying, here are the three ISBN numbers that you can share with as many people in your company as you want and set the price a hundred dollars higher, figuring, Hey, this is a huge markup. This is amazing. So all that work took me about 10 minutes.So far, seven people have bought corporate licenses, which is really exciting and is a massive return on that time invested. So that's another facet of thinking about your audience during the product development cycle. How different people in different situations might use your product and then creating something that adjusts to their needs. Because for a company it's worth the hundred dollars to know that they have permission to use this book however they see fit, and to show it with as many people as they want.Having that kind of license both helps me out because it made me all of this extra money. It also helps out the people who are buying it because it lets them use this content in a way that they might not have been able to otherwise to better achieve their goals.Jeremy: [00:45:12] That's a great point. The threshold for what somebody thinks is expensive is very different for the person vs the company. If I look at something and it's a hundred bucks and I'm buying it for myself, it's a little expensive for me to buy. But if it's a business paying for it then it doesn't even register.They'll put it on a card. You don't have to think about it. It makes a lot of sense to price differently depending on who's buying.Philip: [00:45:35] Exactly. It allows me to provide the value to the people who are able to pay for it while also keeping the main product cheaper for everyone else because I'm not trying to hit a midpoint between individual and corporate use.Ultimately what both of these examples show to me is that where a lot of the money is in technical content is first, you make something great, and then you save people time. So you've made some really great open source thing that people want to use. And then you take the businesses who can really invest in saving their teams some time and you say, Hey, I'm going to make you a great resource. It's going to cost a few hundred dollars, but it's going to increase your development velocity so much that you won't care at all. I know that both of these people have also done a lot of other stuff in technical content, written great books, built a big audience doing interesting work in public. And so I'm not sure I can attribute all of their success to this business model or even the majority of it. But I think that this business model is the sort of thing that I'm looking at very closely as I consider longer term more sustainable work in technical content development.Jeremy: [00:46:46] Adam Wathan with Tailwind is a great example because Adam has put together screencasts, he's put together tutorials, and the quality is so incredibly high. Just going through those tutorials I learned a ton about CSS beyond just learning about Tailwind. Then you have this product that helps you move even quicker it's a very easy decision.Philip: [00:47:11] Exactly. And this goes back to what we were quoting earlier from Cassidy Williams saying developers don't like to be sold to. We don't like to be sold to but we love to be taught interesting things. And that's why content marketing, really good content marketing does so well in the developer space. And it's actually something that gave me some pause and some doubts when I was thinking about launching my book is I was thinking I have what, 20 Twitter followers? My website gets a nice dozen hits a day. Half of them are from my friends. So I was thinking, do I have the established credibility to launch a product like this?And are people gonna feel like I've created something that is valuable or they're going to feel like I'm selling them something? And part of that was solved using the investment of credibility for my interview subjects I was talking about earlier, but part of it was a experiment. Everyone says you have to build an audience before you launch a product. My hypothesis was, I can build an audience by launching a product.It happened to succeed. It's a single data point. I don't know if it's repeatable. I can't guarantee it'll work for anyone else, but a lot of people might look at a business model like Adam's, and say, okay, this is great for him, but he already made however much money selling books. He already invested years and years in building this open source library. I need money now. I can't do that. But I think that an iterative approach where you build a thing, you launch a thing, you use the momentum, you build a bigger thing, you launch a bigger thing might be possible and might be a way to introduce more people to this business model and this space.Jeremy: [00:49:02] Like you said, a lot of people do say you should build an audience first. I had a conversation with Ben Orenstein, he did a lot of public work in terms of, conference talks, blog posts, he ran a podcast for a long time, mostly in the Ruby on Rails community.And when you ask him how did you build your audience? He said well, I was just helpful to people for a decade. And you took a very different path where you didn't have that following, but you were able to have a successful launch out the door.And what you were saying makes sense in terms of having other people vouch for you. Having people like Patrick McKenzie, post on Twitter and say like, Hey, there's this, book, writing for developers, I think it's really great. And if you like what I post on Twitter, or you like my blog posts, I think you're really gonna like this. For me as a developer or just as a person, when I see something like that, then I'll go like, Oh yeah, I trust Patrick. I'm definitely gonna check out this book. So I clicked the link and then I get the landing page and that's the second step, right?You get the person to the landing page, And then what's on there is attractive enough where you go to the next step, click the buy button right? So I think that social proof or having somebody else make the recommendation is pretty huge.Philip: [00:50:24] It really is, and I will not sit here and pretend that I would have sold the number of books that I did if I didn't have the buy in from these very successful people with the interviews and the promotions.However, there are some steps that I made that I think anyone can replicate for their own products that I'd like to talk about sort of going through the funnel.So at the top of the funnel, like we've been talking about, it's Twitter and Hacker News, and I had no following on Twitter, but no one has any following on Hacker News. The concept of a follower doesn't exist. Every single post goes into new. So for a week I focused on, I'm going to create a great Hacker News post.I revised it like I would revise a article for a client or even the book itself. I wrote a top level comment that I posted immediately after posting the Show HN. I looked through all data and statistics to see, okay, I'm going to want to launch this on a Tuesday, 8:00 AM central time so that people in Europe are going to be awake to see it, cause it's afternoon there. I'm going to get that East coast and Midwest morning traffic, get it to the top by the time the West coast wakes up, then they're all going to see it. And that's where I'm going to get the massive influx in traffic.So taking the time to really consider how you present yourself on these platforms and that did rely on the fact that I've been a member and user of this platform for years, so I know it well. I know the sort of unwritten rules and what the audience is going to respond well to and not respond well.To contrast that with Product Hunt where I posted the same thing and got 10 up votes and no views. Having an understanding of the platform that you're launching on is really, really important. And is the difference between staying at the top of Show HN for a day vs getting ignored.That's the top of the funnel. Creating a post that really targets the specific audience of the platform that you're using. From there, my sales page, I spend a lot of time working on that. I based it on the advice from Nathan Barry's book Authority, which covers a lot of this stuff and made sure that I included not just the social proof, but also things like a free chapter so that people can look at the formatting and the content and make sure it's something that they want to read.I focused on having a good bio listing my clients which is a form of social proof that I owned for myself over the last 15 months or so writing for people. And then with the Gumroad page itself I spent a lot of time thinking about the layout, the pricing, eventually landing on $36 as the right price because on the one hand, the book teaches a lot of valuable skills. On the other hand. A lot of the people who might be interested in reading it are going to be students like me or other early career people, which is why I also put on the website that anyone who can't afford it can just send me an email. I'll send them a copy for free. So I've sent out dozens and dozens of free copies as well.And all of that just serves to get more Twitter followers, get more people excited about the book, spread the word. Even small things like making the book DRM free. A lot of people worry about what if someone's going to pirate my book? Well, I'm worried about exactly one thing. What if someone goes and lists it on Amazon? That's why I've registered copyright so I could issue a takedown notice. Other than that small authors such as myself have to worry about things like obscurity much more than things like piracy. I'm mostly concerned about getting the word out there about my ideas, of my content, rather than making sure that every single person who looks at the book has done so in the approved manner.Looking at all of that, there are all of these little steps that you can consider in a launch that are going to provide a big impact on the way that your product is received. People are going to be able to perceive that you are really, really invested in this thing that you've created and you've thought through all these things, and thus the thing that you're actually selling them is pretty good too.In summary, absolutely. The people who I interviewed were a massive factor in driving sales, and I'm incredibly grateful to them for that. But none of that would have meant anything if the underlying product hadn't had that time investment that anyone can make.Jeremy: [00:54:51] The way that I found out about the book was through Hacker News. It was seeing the post and the title was very to the point. It's writing for software developers. I do writing being a software developer and I would like to get better at that. I click on the comments, I see your post, which, was very targeted, to hacker news. It understood people want to hear about the process or they would want to hear about Patrick, who is well known on Hacker News. You put a quote from him in your post. It was very effective at getting what I think the average reader would pique their interest and get them to click.Philip: [00:55:31] Throughout the lifetime of that post on Hacker News. It generated almost 10,000 page views on my site. I'd imagine more because I think the average Hacker News user has more trackers and analytics blockers than the average web browser. But as a lower estimate 8,000 or so people looking at the page and converting at remarkably high rates.To anyone who wants to launch something technical content related or anything that the audience might like investing some real time and effort in a great Hacker News launch is really worthwhile for sure.Jeremy: [00:56:10] Another person that you interviewed for your book is Daniel Vassallo. Something that he's been really effective at is distilling thoughts into tweets. As you start to think about the next step of building your audience, how do you approach writing tweets versus more long form content?Philip: [00:56:33] Yeah. This is something I've really been thinking about and struggling with over the past few days because I have this brand new audience and it's the biggest platform I've ever had. Over 750 people follow me on Twitter and that's a sign of trust that I take very, very seriously.I want to focus on quality tweets over quantity and focus on creating threads to get around the 280 character limit. Because I mean, let's face it, I'm a long form sorta guy. I speak and write in a lot of words. And so what I focus on is taking something I've been thinking about or working on that day, distilling it into something actionable, and then providing that on Twitter and just hoping that people like it.The other thing that I've been focusing on as I engage and grow this new audience is responsiveness. I'm trying to answer email really, really quickly. I'm not necessarily always doing a great job. Anytime someone responds to me on Twitter, I want to be answering them right back or at least liking the tweet or something.I've sent so many direct messages. I actually had to look up Twitter's guidelines on how many you could send a day because I'm DMing people who follow me, who have interesting profiles and saying, Hey, you know, what do you want to read about on here? What do you want to know about the topics that I'm working with?All of that is in the pursuit of figuring out what people want and then figuring out what I can provide and operating in the intersection of that.Jeremy: It'll be interesting to see how you grow that audience and how you use Twitter in general.Philip: [00:58:15] Yeah. The thing that I wake up thinking about every morning and go to bed thinking about every night is at this point, more than 20,000 people have looked at the writing for software developers landing page, which is super awesome, and ~560 of them have bought a copy of the book, which is also super awesome.My question is, how do I get the rest of those people interested in this book? Or if it's not the right thing for them what is the right thing for them? What will get them contributing to this online community creating their own technical content for publishers, for themselves in their own learning, for the companies that they work for, the open source projects, and just expanding this idea because one thing that Angel Guarisma said in our interview right at the beginning that's been a real motivation for me over the past few months is there was a lack of a canon or accepted literature on technical content development. There's not a lot of books besides this one and a few others about the things that we do. There was that sense of responsibility as I was writing this book, living up to the title, writing for software developers.I don't think I've made it there yet, but in my pursuit of this field, I have the opportunity to be definitive, and that's something that I take very seriously and want to do a good job of and take my time and do right. But in order to do that, I have to engage with the people who like what I've done so far and ask them what's next?What can I make for you that will help you make the things you want to make? That's an incredibly privileged position to be in and I'm very grateful for it and I just want to live up to it.Jeremy: [01:00:08] Earlier we were talking about when Chris told you that people skim through articles that surprised you. Is there anything else from the interviews that really surprised you?Philip: [01:00:25] One thing I was surprised by is that many of the people who I interviewed were so strongly against advertising, which at the time I was a little confused by. I've never really minded ads all that much but I've also grown up steeped in them. Today with the sharp decrease in the number of advertisers on the market right now and thus the decrease in rates a lot of publications that have been relying on advertising are struggling to find sponsors and get the sort of revenue that they've been previously accustomed to. That was surprisingly prescient of my interview subjects. That's just what comes from all of those years of experience and seeing dips in advertising rates in the past. I've always thought of it as a very solid foundation to build a business on where in fact, it turns out it is not. That was one thing.I wasn't necessarily surprised but it was really interesting to see the level of passion and commitment that everyone puts into the work that they do. That was very inspiring to me because sometimes it can feel like, okay, I've just got to churn out another article. Just got to get something that's going to get the editors approval and be decent and people won't hate.And seeing the amount of effort that all of my interview subjects put into their own work, rekindled my passion for the field and really reminded me that every single article that I create has the opportunity to be my best work and that I should not waste that opportunity.Jeremy: [01:02:06] One thing about your journey learning how to write and publish professional content. This all happened while you were in university. I don't think there's many people who think I'm going to write professional technical content. What was the path for you finding out that was an option and deciding that was something you wanted to do?Philip: [01:02:29] So the great thing is that on the internet, no one knows you're a cat. That's a famous quote and I think that in technical content I have a picture and a byline and maybe a short bio, but that usually shows up at the bottom of the article, not the top.And the great thing about publishing with some of the big names that I've gone with is their aura around my work gives the work the ability to stand for itself and people are able to judge the work rather than the author.How I got into it was almost by accident. I started out doing some freelancing for a company based in Germany who was trying to localize their site for a United States audience. I rewrote their web copy in native English, to improve the perception of the site.And then I noticed that they publish technical content. I asked if they wanted to pay me for some tutorials about how to use Django and they said absolutely. I wrote a couple of tutorials and it was a lot of fun. Then I thought, Hmm. If this one tiny company out in Germany publishes technical content maybe other companies do too, that could be cool. So I went around and I started looking. I found FloydHub, I found Smashing Magazine. I found all of these places.This is a metaphor that I use in the book. Imagine if a college kid being me woke up one day and said, you know what? For my first attempt at journalism, I'm going to write the headline story in the New York Times. That would just go, nowhere.But what's amazing about technical content is because there's so much demand for it even the biggest publishers are willing to give you the time of day if you write a good pitch. So after doing some research and writing some outlines I started pitching people and people said yes a lot more than they said no.I've done a lot of other attempts at freelancing and entrepreneurship and such before this. Building products, all of that stuff. And reaching out to two people to have one say yes instead of reaching out to a hundred people to have one say yes is a massive change of pace.This is what I'm going to wake up over the summer and do at 5:00 AM before work because just that cycle of feedback and validation was really, really inspiring and got me to commit to creating technical content as a important facet of my overall work.Jeremy: [01:05:00] What's interesting is a lot of people when they see a page like Smashing Magazine or CSS tricks, not even just people in school, but people who work professionally. Most of them probably think to themselves there's no way I could write for this publication. You have shown that it's a lot more accessible than people think.Philip: [01:05:22] Yeah. I think unfortunately a lot of people struggle with imposter syndrome working in technology and that's a huge issue in our field. It limits the people coming in. It limits the diversity of the field. It limits the things that we can accomplish together. But I do hope that seeing, Hey, this college guy was able to publish with insert big name here is helpful for people as they decide that they want to either do something similar in technical content or the equivalent in their own field.Jeremy: Cool. I think that's a good place to start wrapping up, but is there anything that you felt we should have talked about or you wanted to mention?Philip: No, I'm really happy with everything we talked about.Jeremy: If people want to check out writing for software developers or see what you're up to where should they head?Philip: [01:06:16] So my central hub on the internet is my website, which is philipkiely.com the book is available at philipkiely.com/wfsd. I maintain an email list that you can sign up for on that website. I'm also increasingly active on Twitter and occasionally post content to YouTube. I'm working on a video right now going through my first week's analytics on this book and looking at where the traffic came from and who converted. I think that's going to be a really interesting thing for people who are interested in their own product launch to look at. And I'd be really thrilled if you purchased a copy of the book or followed my other work.Jeremy: Thanks for chatting Philip and congratulations on the launch of writing for software developersPhilip: Well, thanks, Jeremy. It's been a great time talking to you today.Jeremy: That's it for my chat with Philip you can get the transcript for this episode at softwaresessions.com. See ya!

Sara Leen is a localization programmer for XSEED Games on titles like Ys, Trails in the Sky, and Corpse Party. She got her start reverse engineering and fan translating games.We discuss:What makes games differentHow games store and encode textRewriting Corpse Party (and not being able to run it for a year!)Porting and modernizing gamesReverse engineering raw assemblyThis episode originally aired on Software Engineering Radio.Related Links:@SaraJLeenPersonal SiteCorpse Party PC Programming BlogTrails in the Sky Second Chapter Localization Blog 5Mojibake (Garbled text when text is decoded using the wrong encoding)Shift JIS (Japanese character encoding used in older games)Hot Soup Processor (Obscure programming language used for Corpse Party)XSEED Games Music by Crystal Cola: 12:30 AM / VHS SkylineTranscriptYou can help edit the transcript on GitHub.Jeremy: Hey, this is Jeremy Jung. This episode, I'm talking to Sara Leen, a localization programmer for XSEED Games. Sara has over a decade of experience localizing games from Japanese to English. And we talk about how games are different than other types of software, storing and extracting text, porting games to different platforms, and rewriting a game from scratch.A game written in an obscure programming language called... can you guess it? Hot Soup Processor.Pretty good right? This was a fun episode and I hope you enjoy it.Jeremy: [00:00:35] The first thing I want to start with is you have experience with building other types of software. I was kind of taking a look at your resume. What makes games different than working on a typical software application?Sara: [00:00:48] With games, there's a lot of things that you have to worry about that you otherwise wouldn't like the frame rate of the application becomes very important. For example, you need to make sure that the timers of the application are coded just so that the game will always run at a steady pace. And there are various applications of timers like delta time that are usually used to ensure this goes perfectly smooth.Jeremy: [00:01:17] When you talk about timers, I've heard of this concept called a game loop. Is that what you're referring to?Sara: [00:01:27] Essentially a game is made of graphics, audio, and input. But all of these have to be checked every frame. And so you have your timer going so that it is basically looping through the game 60 times a second or whatever other frame rate your game is running at a lot run at 30. There will be various steps in this process, like game logic and drawing the various models. And of course you have to keep the sound system updating.Jeremy: [00:02:01] As opposed to a web application where a lot of things are in response to something, right? Somebody's going to a webpage, clicking a button. With a game it sounds like there is this consistent loop that's tied to the frame rate. Is that correct?Sara: [00:02:20] Right. And instead of reacting to things, you are occasionally checking the state of course so many times per frame and you will still have to respond to the user input but it's all going to be one part of this large set of functions.Jeremy: [00:02:38] So you're in this loop and let's say somebody was pressing a button on their controller or moving their mouse that would affect the state. And when you're in that loop it's going to look at that state to determine what to do next in the loop?Sara: [00:02:58] Yes, exactly. For example, in your input system you are usually going to be saving every frame, the state of the input system at the moment, like is this button being pushed? Is this button being pushed? Was this button pushed last frame and by comparing it against the previous frame. You know what the user is doing right now, and then many parts of the game logic will have various branches that check exactly what the user is inputting and what the current context is.It's certainly more complex than the idea of I push a button and it calls this function.Jeremy: [00:03:34] That sounds like like an entirely different model of thinking. The structure of the application has to be almost completely different.Sara: [00:03:42] Absolutely.Jeremy: [00:03:43] In terms of skillsets working on a game versus working on a regular application. What parts are really different and which parts are kind of the same?Sara: [00:03:54] Regardless of what you're working on you're going to be working with a lot of external APIs, but these are probably going to be entirely different for a game versus other software.For example, you need to be familiar with APIs like DirectX and OpenGL and all of these typically have different ways of handling graphics, handling audio, handling input.There's also SDL of course that you could use and depending highly on the programming language as well there may be different ways of handling certain things that would be different from handling a normal application.But most importantly you need to be familiar with graphics and audio APIs above all. I think those are typically less important when you're working on normal software because you're more concerned about how to build your window and how to get all of the elements displaying in the proper positions.Jeremy: [00:04:51] With a typical application the actual act of rendering to the screen is abstracted away from you so you don't have to worry about how to draw to this screen. It's more like, I want a button or I want a window and something else is handling that for you.Sara: [00:05:08] Yes, that's pretty much it. And when it comes to video game graphics, you have to consider a lot of different things like differences between graphics cards. Can this graphics card handle square textures or does it need a different shape? As well, of course, as being concerned with the quality of how it's drawing. Like is this texture supposed to be filtered? Will this graphics card filter it correctly? The APIs simplify that, but you're working at a lower level.Jeremy: [00:05:36] And when you were giving examples of APIs you were talking about DirectX and OpenGL and SDL. How low a level are we talking? If I wanted to draw something to the screen at the most base level what kind of work am I looking at?Sara: [00:05:55] Well, for SDL in particular this is somewhat of a simplified process because it handles all of the initialization of devices and such for you.But with DirectX and OpenGL, you have to actually get the list of devices you have to initialize each process that you need. Like you need Direct3D, you need DirectInput, you need DirectSound, and then you have to make sure that you have all the device information that you need, including stuff like the current resolution or the capabilities of the device. Device capabilities is a big thing when it comes to that.And then to actually draw the image, you are going to need to create a texture buffer. You're going to need a back buffer for the screen, and then you will have to load the texture and you will have to draw the texture to the buffer and then present that to the screen.Jeremy: [00:06:53] When you refer to the buffer, at kind of a high level, can you kind of explain what that's doing?Sara: [00:06:58] Essentially you have the screen that you're drawing to, and you usually don't want every single draw command to go directly to the screen. It's better to have a buffer that you can operate with so that you can display things in the correct order at all times. You can have them on the correct Z level, and of course, any sort of processing you need to do, you can do before it's drawn to the screen. And so everything goes onto the buffer after it's ready more or less.Jeremy: [00:07:29] And when something is in the buffer is that what you plan to actually have the video card render? Or is that after it's already been rendered? Where is that in the stage?Sara: [00:07:43] Well, rendering is basically the last step of presentation, but it depends. If you are drawing something 3D naturally you are going to have to do some processing on that via the graphics card. And the APIs allow for things like that, but typically rendering to the screen itself is always going to be the very last step of the frame.Jeremy: [00:08:06] And then elsewhere in your application even though you're putting things into the buffer, you're deciding that there are certain frames that you don't need to render?Sara: [00:08:17] Yeah, and of course that depends highly on the game, but often there may be no difference. So you don't really need a new frame or there might be a case where the game is overall running a little too slow. So skipping some of these frames will get you more CPU cycles free to work with.Jeremy: [00:08:36] We were talking about the loop earlier where all the logic is happening at a set rate, but in terms of the way people see the game of how smooth it is, you may have the game logic running at the same rate, but only choose to render certain frames in the buffer so that it still runs the same it's just that it's a little choppier?Sara: [00:09:03] Yeah and essentially you need your game logic working at the highest that your gameplay can really go. But when it comes to the graphics, it's a little more arbitrary for sure. There are situations where you might intentionally want your game logic running at 120 frames per second and then the player input and such will still come at that speed regardless of the actual refresh rate of the display.Jeremy: [00:09:32] Interesting. I want to talk a little bit about how games can have a lot of binary assets. Typical software development you would use git as a version control system. Would you use the same for games or is there a different system that's more suitable?Sara: [00:09:49] Well naturally, this depends on the company. Quite a few do use git and simply store the binary assets even though there is no real comparison system for them. There are also various internal systems that companies may use that are specially made for handling their specific assets. Essentially version control is not that different in the gaming industry. It just occasionally uses different applications.Jeremy: [00:10:22] And so when somebody uses git even with the binary assets, it's not an issue. You just can't see the diffs properly.Sara: [00:10:32] No, it's typically not a big deal because it's not difficult to look at two different pictures and visually compare them. And generally you're going to be changing the binary assets less as development goes on rather than more, whereas the code that's always going to be changing.Jeremy: [00:10:52] The title you use is localization programmer. What would you say is the main role of a localization programmer?Sara: [00:11:02] Essentially, when a game is being localized from one language to another obviously the goal is that you get all of the text inserted and you make sure that it all looks correct. At base levels this is generally the accepted position of a localization programmer. You are getting all of the texts into the game. You are making all of the code work with the correct fonts and other asset changes that you may need that are different from the original language. However there are a lot of things in this process that you wouldn't normally need as a skill. For example, if you are working with Japanese games, all of the comments and everything are going to be in Japanese of course.Jeremy: [00:11:43] When you're translating games, do you usually have access to the original source code?Sara: [00:11:49] I usually do, but there are plenty of cases where we are working on a game and the original developer is actually the one to handle the localized version. It depends a lot on how much other companies feel they are able to release to other parties, whether it's because of rights issues or they're just kind of nervous about their code quality, which I mean, I would be.Jeremy: [00:12:12] And when you get access to the code do you usually have access to the original developers or are you on your own?Sara: [00:12:21] I would say that completely varies. You never know exactly, but it's usually going to be the same with each partner. Like, they will usually be more than happy to help you if they have the developers on hand to help you. But game companies are constantly developing new titles themselves.So when someone like me is working on a game, we may not have as much access to the developers or they would be working on the game.Jeremy: [00:12:48] You were talking earlier about being able to extract text or bring text into the game. What are some examples of ways that the text would already be stored and how would you bring that out?Sara: [00:13:03] This also varies a lot and it's very interesting. Many games use script files, essentially lists of commands for their events, et cetera. And in these cases, as long as you know the format of the script file, you're usually going to be fine. But some games like to hard code their text, and yet others have been in binary formats that have been compiled in some way, assembled rather.And when that happens, you often have to take a look at the code and figure out exactly what this format is, which may or may not be documented, and basically do the process in reverse unassemble it.Jeremy: [00:13:46] The first example you gave was script files. So would that be a plain text file and you could replace that text with instead of Japanese put in English?Sara: [00:13:57] Essentially, yes, like when there's a script file format, you're going to see various commands, like there will be message and then it will have the text for a message box, that kind of thing. And when that is the case, it's usually pretty easy to change since it is just text. But you might run into some encoding issues.Jeremy: [00:14:17] By encoding issues, would that be where let's say you replaced the Japanese with English and then the game itself tries to load the texts from the script file and it can't due to a different text encoding?Sara: [00:14:29] Not so much that as you might get garbled text, what in the fan community that I used to work in, we would call cave speak.Jeremy: [00:14:38] Could you explain what you mean by that?Sara: [00:14:40] Imagine that you are playing a game in Japanese, but your system doesn't have Japanese fonts loaded. The font not being there for Japanese, you might instead see jibberish like ekvgh, that kind of thing. And that is cave speak.If the encoding is very specific for the game or the font simply doesn't have other symbols, you might get complete jibberish in what font was already there. In Japanese, it's called mojibake.The way that encodings work of course, is that the text is interpreted from its binary or hexadecimal format into characters we can understand. And since there's a lot of different encodings out there, sometimes you don't know exactly what you're going to get. So, for example. If a game was made for an older system, it may have a completely custom encoding where a value like "2" means "a" and in this situation just replacing the text you have no idea what the game's going to output. You're going to have to change it all yourself.Jeremy: [00:15:55] So the original text in the script files, or perhaps you're talking about the binary files, they're not necessarily using a standard encoding like ASCII or Unicode. They may have made up their own encoding format.Sara: [00:16:12] Yes, and this certainly varies. When it comes to Japanese, you'll usually be able to find that it's in the standard Japanese encoding Shift JIS. And Shift JIS largely supports English letters, but because Japanese text tends to include characters that are all the same width, it doesn't often account for the fact that in English you have very thin letters like the letter I. And so when you simply insert the text into those games you might get a situation where all of the letters are spaced really far from each other. And that does not look good.Jeremy: [00:16:52] You were talking about how there's the example of script files or the example of code being hard coded or even binary files. What is the end result you'd like to get this text out for a translator to work on?Sara: [00:17:25] Typically the text you want to get into an Excel sheet because that's the industry standard for translation and keeping texts like that. Sometimes the developer will provide this themselves and that will of course, make the process of translation a little easier because somebody like me can work while the game is being translated but usually it's more a case of what is the translator comfortable working with?Are they comfortable working with script files? Do they need an Excel sheet? Most of them do and that's fine. But obviously this results in more steps. You need to create a tool chain to both extract the text and get it into a sheet, and then you have to make the call of whether you can get that text directly back into the game or if you would need to include more information, like the exact lines it's from.Jeremy: [00:18:21] The simplest would be the script file where you might build a tool to convert the script files to rows in an Excel spreadsheet. A translator works on that to translate it to English. They give the spreadsheet back to you and you run some kind of application to convert their spreadsheet back into the script files.Sara: [00:18:43] Yes, exactly. Although granted if a game is very small, you might just do it all by hand.Jeremy: [00:18:49] In terms of these script files are the lines of dialogue or the text-- are they in their original context? If somebody in a game was having a conversation would all of the sentences be grouped together or is it sometimes just spread all over the place?Sara: [00:19:14] This varies a lot. Sometimes you won't even know which character is speaking unless you actually play through the game while you're working on the script. And obviously this poses some interesting challenges because in general, Japanese is not as context heavy and context apparent as English is.You can't always tell who's talking just by the tone of their voice, so to speak.Jeremy: [00:19:41] Going back to when you have something where the text is hard coded. Is that a case where you basically have to do it by hand or have you found a process to deal with that?Sara: [00:19:53] There are a variety of ways that this can be approached too, which is part of the beauty of games. It's an art form. But what I personally like to do is simply make something that extracts all of the apparent strings, like surrounded by quotes from all of the code and gives that information along with the line number. And just like with any other script, you can usually automate this.Jeremy: [00:20:20] So you create your own version of a script even though they didn't exist originally.Sara: [00:20:29] Yeah. And then you have this list of all the strings in the game, and you can easily put those into a sheet.Jeremy: [00:20:37] When you work on localization, how much of the code base or the game engine do you feel like you need to understand?Sara: [00:20:45] It depends on the scope of the task, but typically I would say that I don't need personally to understand much of the game to start working on it, but by the time that the project is finished, I should understand almost everything except for the raw graphics the APIs being used. Even then, I might need to depending on how the game is functioning and whether we need to do something differently, like making an older game use widescreen.Jeremy: [00:21:15] And what's your strategy when you first start work on a project? You get the source files and you need to find out where the text is stored and how it's stored. What's your strategy for figuring that out?Sara: [00:21:30] First I will look through all the files I received and make sure that the text isn't somewhere extremely obvious. And if it's inobvious, I will then start looking at the source code and getting it to compile. And I will look through that to see exactly what files it's loading. And from there I can usually figure out where the text is stored.Jeremy: [00:21:52] In terms of when you get a project, do you just look at the code or do you figure out how to to run it and all that first?Sara: [00:22:01] Usually I prefer to start by looking at the code itself and getting that to compile, but typically a developer will provide a working copy of the game that you can use to see exactly how everything functions. I do like to know what kind of game I'm working on and the basics of the gameplay, the basics of the setting, because that will help me motivate myself to work on it. It will help me get into the right mindset for it.Jeremy: [00:22:31] You were talking about how there were easier ways of localizing in terms of script files and the hardest being hard coded or binary. What are some ways that if a developer is making a game that they can facilitate the easiest localization?Sara: [00:22:51] The easiest localization would definitely be first you want to make script files for everything, whether it's just the list of strings that the game is using, or a proper script file for all the events. And then you want to make sure that the game is capable of loading a different sets of these based on what language is currently in use.And if the game is already capable of loading different folders or different files for different versions of the scripts then it shouldn't be too hard to localize, but you also need to make sure that there are easy ways to work with the graphics and of course, absolutely all of the assets can be loaded differently based on language.Another problem of course, is when it comes down to stuff like fonts. Because to make a very pretty looking font, you probably want to make the font graphical rather than using a true type or open type font. And of course, the challenge with that is including every character you could need for every language as well as issues like the font could be badly spaced in certain languages and to make a game as easy to localize as possible, you probably want to use Unicode and Unicode fonts and just include everything you possibly can.Jeremy: [00:24:17] And because unicode has most languages used in the world, then you won't have the text and encoding problems.Sara: [00:24:25] Exactly. You would completely skip that step. You wouldn't need to worry about the fonts. You would just be able to put whatever language you need and you won't get tripped up by stuff. Like in Japanese games Shift JIS is the encoding used right? And if you try to insert accents like an E with the little dash over it. It will instead draw a Japanese symbol if you don't change the encoding.Jeremy: [00:24:52] You were talking about graphical fonts, so would that be a raster image, like a giant PNG or a JPEG that has all the different characters on it?Sara: [00:25:06] Yes, exactly. Usually this also has some sort of table containing the geometry of the font so that you can draw it with proper spacing and everything.Jeremy: [00:25:18] And then when you're talking about assets, that would be like textures. For example, if you had a sign in the game, that would be something that somebody would have to go into Photoshop and have a different version for each language?Sara: [00:25:34] Yes, and ideally you want to keep all of the original layered versions of this with the text on a separate layer, because that will make it as easy as possible to change the text that's on it. But of course that isn't always available. So when it's not, you need somebody who's actually able to remove the text and put something new in.There's also things like title screens of course, and any sort of special menu texts you have like that's drawn in a different font or has a special design.Jeremy: [00:26:06] Because something in Japanese versus something in English can look significantly different when you're doing a logo. So you need someone with the artistic expertise to be able to recreate something that looked like the other thing, right?Sara: [00:26:22] Yes. And of course Japanese logos are often written entirely in Japanese, so you will want to come up with a localized title for these games and then put it in the correct localized language, and that will involve basically designing a new logo that looks similar. It gets the same point across which is the big thing in localization. You want to get the point across.Jeremy: [00:26:47] One of the games you worked on was a game where you decided that the game's code needed to be rewritten. Can you talk a little bit about what the game is and why you decided that you needed to rewrite the game?Sara: [00:27:00] Well, in this case, we are talking about a game called Corpse Party. Corpse Party's origins were as an RPG maker game on an obscure Japanese computer (PC98). Obscure over here at least. And when the developers revisited it many years later, they decided to remake it in a programming language called Hot Soup Processor or HSP for short. HSP was taught in many Japanese schools because it was free and it was made for people wanting to get into things like this.Now Hot Soup Processor resembles basically the child of Java and C and in this way, everything is a little different. I wouldn't even compare it to C, honestly more like BASIC. And as a result, your game looks more like a scripting language than a programming language. And the bigger problem is that you don't have as much control over the graphics and sound APIs for games that are coded in HSP, and so to do many things with the graphics properly or get the timers right it may be better to change over to something else. Especially if you're going to put this game on something like Steam, because Steam does not have a version of their API for Hot Soup Processor. I know. Shocking.Jeremy: [00:28:30] About it being like BASIC, is there a high reliance on GOTO statements?Sara: [00:28:38] Unfortunately, yes, there is.Jeremy: [00:28:40] Was this statically typed? What was it like to kind of work in that language?Sara: [00:28:49] Well, when it comes to typing. You don't always know what type it's going to be. You don't know if this variable is necessarily an integer or if it's a float, and the compiler of the scripts largely doesn't care, and obviously that means you can run into some typing issues because you have completely misunderstood what a variable actually was. That definitely gave me some headaches.Jeremy: [00:29:16] So it's sort of like Javascript or Ruby where you can define a variable and that variable, you could put in a string, you could put an a number, you could put in pretty much anything and there isn't really a way to check. I guess it just runs through the interpreter and then you find out at runtime whether something's going to blow up.Sara: [00:29:37] Pretty much, I definitely would compare it to Ruby in that regard.Jeremy: [00:29:42] What was your strategy for rewriting a game? Were you porting function by function? How did you get started?Sara: [00:29:50] Of course, I started by just copying all of the code and then I began rewriting each function one at a time. Trying my best to understand the purpose of each function as I was going along. I knew what some of them did already because we actually inserted the translation before all of this, but the thing is that I was never going to be sure exactly what functions relied on each other and what variables were needed and how exactly they needed to be typed until everything was already basically put together. And so I honestly was pretty scared during this process at times because I had no idea if it was going to work until it worked.Jeremy: [00:30:36] You were rebuilding it function by function but because it wasn't really clear which functions relied on other functions you couldn't run the game. There wasn't this iteration of getting part of it working and moving on to the next part, you had to build everything and then you found out if there were issues?Sara: [00:30:58] Yes, exactly. Because for the most part with games, you are not building the code level by level. You are programming something that will be able to run all of the levels.Jeremy: [00:31:09] Wow, that sounds terrifying.Sara: [00:31:11] It is.Jeremy: [00:31:12] Were you able to on a function by function level, have an idea of what the function was supposed to return so you could at least test certain functions?Sara: [00:31:26] Yes. There were definitely cases like that. However, the most complex parts of the game are often more in the graphics and audio engines and such if you're working at this kind of level. And I wasn't always sure how the graphics functions worked. No fault to the developers, just that it was so much.Jeremy: [00:31:46] Since you didn't quite understand how the graphics functions worked, when you rewrote that portion of the game did you take a different approach rather than trying to recreate what they had done?Sara: [00:31:59] Well, I initially tried to recreate what they'd done, although for certain API functions, et cetera, I basically took my best guess and so when the game was finally running, it definitely didn't look or sound right. At first, there were problems, and these were entirely problems with how I had understood the code rather than anything to do with the game itself of course.Jeremy: [00:32:24] How long did it take from getting the code to actually being able to run the game at all?Sara: [00:32:31] The original version of the game pretty much worked out of the box and compiling it I just needed the version of the HSP tools that the game had been made for. But when it came to actually making my version of the game run it took about a year.Jeremy: [00:32:50] Wow. So a year before you could launch the game. That's intense.Sara: [00:33:00] Believe me, I hated myself for a lot of that project. I was like, why didn't I just use the original code? Why did I put myself through this? But the result was that the game runs very well.Jeremy: [00:33:12] One of the common pieces of advice people get when they work on software is quick iteration in terms of build the thing, see if it works, then you can build the next thing. But in this case it seems like that wasn't possible to do.Sara: [00:33:32] Yeah. Unfortunately. With games everything is going to be more tangled and depending on the way you approached creating the game you can end up with either something that's very clean and parts don't depend too much on each other, more abstracted, or it can be a plate of spaghetti. And just like any application, this is a matter of designing the application before you start building it.Jeremy: [00:34:01] Something you managed to do when you rewrote the game was make it platform agnostic. What are some examples of ways that when you write a game, you make something that can be easily run on different platforms?Sara: [00:34:15] Regardless of the platform, you are going to be dealing with different graphics and audio API APIs. Because you're not going to run DirectX on a PS4 and essentially the approach you need to take with this is mostly related to creating wrapper functions for all of the graphics stuff you need to do so that you can easily change these functions and not have to change any other part of the code.For example, you want to have functions for drawing a sprite. You want to have functions for drawing some text, and you want these to be things that you can easily change the contents of without changing any part of the actual games code directly.Jeremy: [00:35:00] And the parts that are going to be different from platform to platform, would you say that's the graphics, the sound, the input that sort of thing?Sara: [00:35:10] Yes. Basically everything that deals with IO. Aside from the fact that on pretty much any platform you're going to be able to use, fopen() without any issue.Jeremy: [00:35:21] When you rewrote the game, I think you had said that when you got the original version of the game, you had replaced the text. Was that hard coded into the game or was that through scripting files?Sara: [00:35:34] Mostly scripting files, but it took me quite a bit of effort to understand these scripting files. There definitely was some hard coded text in the game. Mostly related to the menu functions. Chapter names for example that you would encounter in the menus were hard coded.Jeremy: [00:35:52] And did your rewrite load in the original script file format?Sara: [00:35:58] Yes, actually. Although interestingly enough with this particular game, all of the original scripts were in Japanese. Even the commands and this is not common. It does happen, but usually the commands and such will be roughly in English because when you're working with programming, you're going to be writing some of it in English no matter what language you speak.But since all of these scripts were completely in Japanese, I decided to replace all of the commands such that the game could still load the original format, but it was using something sort of new in that the script commands were simply translated.Jeremy: [00:36:37] And when you refer to a script command could you give an example of what some of those would be?Sara: [00:36:42] Stuff like message, wait, display picture. Move character to the left, stuff like that, or check a variable.It's a lot like programming. It's just that you are working in a language that is created for the game and is being used by the game without compilation usually.Sometimes there's assembly involved, but when you assemble the script like this, you are just converting the commands to one, two, three, et cetera to make sure that you know what the commands are without having to use as much text and space.Jeremy: [00:37:19] So it's kind of like an enum, is that a good example?Sara: [00:37:24] Yeah. EssentiallyJeremy: [00:37:25] And those commands would use the English letters but they would be written in Japanese words?Sara: [00:37:33] They were actually written in Shift JIS full Japanese.Jeremy: [00:37:36] Wow.Sara: [00:37:37] I never encountered any other project that did that, although I understand it must've made the script files really easy to understand for them.Jeremy: Yeah. It's interesting how we sort of make the assumption when we look at code that there's going to be English in it. I guess sometimes you get surprised.Sara: [00:37:55] Yeah, for the most part, there aren't many programming languages where you can do everything in another language, but if you're creating the language yourself, obviously you have plenty of control over that and you can do anything.Even though we sort of take for granted that there's going to be English there it doesn't have to be, and I find that extremely interesting.Jeremy: [00:38:17] I don't know that it happens very often, but I think a lot of languages do support Unicode for variable names and stuff like that, I just am not sure how many people actually take advantage of that.Sara: [00:38:28] Yeah. When it comes to seeing localized variable names and source that are not in the normal character set? I would say I hardly ever see it. I can only think of one occasion and you will usually instead find that it is written in English characters, but is in that language, which in the case of Japanese is what they call Romaji.So you would have the Japanese written entirely in letters. And you find that a lot when you're localizing Japanese games.Jeremy: [00:39:01] You said after a year you were able to run the game, but there were bugs or there were different issues. How were you able to track down what bugs were in the game? Was it a completely manual process where you just had to keep playing and keep trying things?Sara: [00:39:19] Essentially, as well as having testers within the company also handle that sort of testing, what is called quality assurance. Of course, we just call it QA. But by having people iterate through the game many times we would find all of the bugs with it, essentially like you would any other program. You just have to have people using it.Jeremy: [00:39:41] Were there any bugs or odd behavior in the original version that the game was relying on that you had to reproduce?Sara: [00:39:51] I wouldn't say there were any bugs that I had to reproduce, but since I had copied the game's code as closely as possible, some of the original bugs did carry over initially and I was later able to fix a lot of them.Jeremy: [00:40:08] We've been talking about the process of making games and rewriting games. What is the language that you rewrote the game in?Sara: [00:40:18] C++.Jeremy: Is that pretty typical for the projects you work on?Sara: I would say that the vast majority of professional games are written in C++.Jeremy: [00:40:31] What makes that the default choice that people would go to?Sara: [00:40:38] Frankly, it is widely supported. You have C++ compilers for consoles. You have them for computers, you have them for all kinds of different devices. Whereas you create a game in Ruby, you have no idea if you're going to be able to put that on a PlayStation.Jeremy: So it's just the fact that everybody's using it and there's so many tools, so much support.Sara: [00:41:04] Yeah, exactly. As well as the fairly robust standard libraries and since these are available on so many platforms, it's just always been the choice ever since it came to be. Originally back in the days of like the Nintendo Entertainment System, games were primarily written in raw assembly. But obviously that's not very practical, especially for the scale of games these days.So it eventually changed to C and then C++. There have been efforts to adopt C# in more platforms, but it's kind of a slow going because it's just so deep-rooted.Jeremy: Typically when I hear about C# and games it's within the context of the Unity engine. It seems like that would make it easier for people to get started and work on projects but I don't know what the trade offs are relative to C++.Sara: [00:41:58] Typically, I would say that C++ simply is the most easy to optimize compared to other options like this because of the nature of how it's compiled. Whereas with C#, they take a more native approach where all of the code is managed code, and the native code is easier to optimize, whereas the managed code that makes up most of C# simply isn't something you can optimize much beyond how it's handled for everything.It's a global optimization, whereas optimization specific to various functions in games are better than global optimization in a case like this. The trade off is simply performance. How much you can pull out of the system before it starts choking.Jeremy: [00:42:50] And one of the big differences between the two languages is that C# has a a garbage collector. For games, is that something that's seen as not desirable?Sara: [00:43:02] Rather than having garbage collection, you need to handle all of the games memory very, very strictly. You need to know exactly how much memory everything is going to take at any given time. The reason for this is because consoles typically have much more severe memory limitations than a computer does, and if you start running over that memory, you just don't have a program running anymore. It's problematic.Whereas on PC, there are things like virtual memory to pick up if you end up running out of memory somehow, and as a result, if you have any sort of garbage collection, you're going to be wanting to do it yourself. Frankly, all memory that you're locating, you should be doing yourself. You should have your own memory manager in the game.Jeremy: You said it's probably true for all platforms, but on consoles it's more important just because of the memory restrictions.Sara: [00:43:58] Yes. And of course that is also why when you are porting a game to a console, you have to be very considerate of things like memory space and of course video RAM. It was more important back in the older days of systems like the Super Nintendo and the Nintendo 64 but it still remains important today. If you start running out of memory on console, there's nothing you can do about it.Jeremy: [00:44:27] You've ported some games from low spec hardware like the PlayStation Portable to the PC. What are some of the unique challenges related to porting a game?Sara: [00:44:38] First of all, when it comes to games on an older system or a weaker system such as the PlayStation Portable the game is made exactly for the hardware specifications and you are at the mercy of those specifications at first. For example, the PlayStation Portable, its resolution is quite small. It is something like 480 by 272 and while that is almost 16:9 it's not quite.When it comes to PC games people want options. They want the ability to use different resolutions and customize their controls and the original game is probably not going to have supported this and more importantly if you're working in a game at a low resolution like that, that is not going to look good on a PC screen.With these projects we take as many of the original PSD assets and such as we can and just redo the games assets in HD and that obviously results in a much prettier game.But that also assumes that you actually made the assets in a higher resolution to begin with. Otherwise, they're going to have to be remade, and that is a whole different ballpark of problems.Jeremy: [00:46:00] Yeah, their resolution is so low that if you were to use the original assets, they would just look super blurry or blocky if you were to port it straight to the PC.Sara: [00:46:10] Exactly right. And frankly, that would make the game look a lot worse as a whole and less people would play it because at that point you're just playing something that looks old and you don't want it to look old because you're creating a new version of it. You want it to look new and shiny and sparkly.Jeremy: [00:46:30] How does the process of porting a game differ from your experience rewriting Corpse Party? How much of it is a rewrite versus something different?Sara: [00:46:43] When you're porting the game, hopefully it's in a language that you can still use. And if that's the case then the first step is going to be ripping out all of the stuff that you can't use.For example, when you're working on a console you have to use the console developer's development kit in everything. You have to use their software and while usually this supports the same programming languages that you would be able to use on PC anyway, you won't be able to use most of the graphics functions and the audio functions and you're just going to have to do all of that over instead of copying like I did when I was porting, one language to another.I instead had to basically take guesses at what all of these functions did and then reproduce them to my best. And occasionally this would result in something I didn't understand, just like when I was working on the original corpse party game, but more often I would find that I missed a functionality and that something wouldn't change color when it was supposed to or something wouldn't play from the correct speaker or things like that.One of the latest issues that I got when I was working on my first port last minute was that I realized there were audio files that were supposed to be looping and cross fading. And I had forgotten to implement any of this because I didn't realize what it was. When it comes to porting to PC, there are two main concerns. One is making sure all the functionality is correct in the first place. The second is making sure that the game runs well on a PC because there are different threading models and different timer models that simply don't convert well to a PC. That's the case with changing platforms in general.You want to make sure that everything runs as it should, even though it's on a different platform, which I know I'm just speaking in circles there, but at the same time, you have to realize if you just put a game directly on PC and you don't change anything it is going to run a lot slower than it could because it was optimized for something else.Jeremy: [00:49:04] When you talk about different threading models, could you give an example of something running on a console versus on a PC? What are these different threading models or different choices you'd be looking at?Sara: [00:49:18] Well, for example let's say that you are programming a game that is working on a Nintendo Wii. You will find that you have to handle the graphics at this time and the audio at this time and threading is often a better choice when it's available for simple performance reasons.However, it's also the case that a lot of older games don't use any sort of threads at all. Everything is just a single thread going through that single game loop and you have to deal with the results as they come. But when it comes to a PC game, you of course want threads. You want to be able to use more of the CPU and instead of using the exact CPU number and types that you have on the console like that, you have this audio and this CPU and this console happens to have a dedicated audio processor, stuff like that. You want to use something more general on a PC that'll work on anything.Jeremy: [00:50:20] So in terms of concurrency models on a console, the software development kit for that console may already have ways that you're required to do certain things. Like you were saying, a certain way to do graphics, a certain way to do audio, and once you bring it to PC, then you have more control over how you do concurrency, how you do graphics. And so you may choose to do it completely differently than how it originally worked.Sara: [00:50:52] Yes, and I think in many cases that's preferable because obviously concurrency in something like a game is best used for optimization and making sure that everything runs smoothly without any hitches. But on a console, you are optimizing to such a specific scenario that this optimization does not carry over well and is actually harmful when you are copying it directly to a PC.Jeremy: [00:51:18] Are there any specific APIs for example OpenGL that you would choose when you want to make something that you can consistently use across platforms?Sara: [00:51:29] I would choose OpenGL or possibly SDL because surprisingly SDL exists for quite a lot of platforms. That said, I would say that Vulkan is becoming something that would be very useful in that sort of way.Jeremy: [00:51:43] In terms of the projects that you've worked on, the example you gave with PlayStation Portable, were those games using some APIs specific to the console to do graphics, rendering, audio, that sort of thing?Sara: [00:51:59] Yes. The APIs for these things are typically provided by the development kit and whether they resemble an existing API or not is pretty much up to the console creator's choice. For example, if you're working on a Nintendo 3DS, you can probably use OpenGL straight up with just a few changes. Although the optimization is still going to be a nightmare by comparison because it is completely different.Jeremy: [00:52:26] When you're working on one of these ports have you ever had to go the other way around where you had a less constrained environment and then had to move it to a more constrained environment?Sara: [00:52:40] So far, I would say no, because for the most part, PC is about the least constrained you'll get. But I still try to make sure that when I'm working on a game, it'll run on as many systems as possible, and that means trying to make it run on a toaster if I could. And when your PC is a potato, you don't really expect a fully 3D game to work right.But sometimes they can. Sometimes if you are very careful about the way you optimize the game and take a lot of constraints in what you're doing, you will make a game that looks a lot better than it should on an older PC. And I try to make that a goal of mine. I try to make sure that these games run in older environments, Up until last year I was even making a point of supporting Windows XP with all of my games and that would be more of an issue at times than you would think.Jeremy: [00:53:36] What's an example of something that you would have to do specifically for such an old operating system?Sara: [00:53:42] For supporting old operating systems you essentially are limited when it comes to your compilers and your libraries. You can't use newer versions of libraries because they weren't made for older systems. The windows kernel changed very dramatically with Windows Vista and it's only been evolving more and more since.And you are limited to using this older version of the kernel that is largely still supported, but there's often behaviors that are just a little different between a system and you won't expect them. Like you might be trying to get the size of your window rectangle and it will be off by one. Small things like that. Or you'll be drawing text and Vista might support outlining the text and XP might not.Jeremy: [00:54:32] So there's subtle bugs or small features that don't exist. So when you have to take into account whether you'll have those or not it just makes everything more complicated.Sara: [00:54:44] Yes, exactly. And you don't always have the ability to expect it because often the functions will look the same, but the behavior is simply different.Jeremy: [00:54:56] And these are operating system level calls that you're referring to?Sara: [00:55:01] Yes, largely. Although there is also the matter of APIs for things like graphics that don't exist on older operating systems. For example, you can't use DirectX 10 or later on XP.Jeremy: [00:55:15] One of the things about porting is we were talking about the things that you can't reuse. Are you able to use most of the core game loop and the logic as-is without modification?Sara: [00:55:27] Well, for the most part, most of the game code is going to stay intact like that. You will have to alter stuff like the coordinate calls for various textures because all of a sudden you're worried about different resolutions. Games running on consoles generally run on a single resolution that is their target. And if you are using a different resolution on your TV, the console is scaling the output to that.But when you are working on PC, you need to account for that and you need to account for different aspect ratios because while it's easy to say, Oh, I'm going to make my game this resolution, you might upset the people who have ultra wide monitors or the people who are still using old 4:3 monitors. They exist and ideally you want to support all of these scenarios as smoothly as you can. When you're creating a game, you can account for this better than if you're working on a game that already exists.Jeremy: [00:56:23] It sounds like a lot of work in terms of finding the sections of code that are expecting a specific resolution, a specific aspect ratio. And earlier you were talking about how your assets may change as well, because you need UI elements that can be rendered at a much higher resolution or at a different shape. It seems like there's a lot of work that needs to go into it.Sara: [00:56:51] Yes. A lot of the games that I worked on earlier in my career were older games that were made for 4:3 and in the process of working on these I realized obviously these games need to be widescreen, and so there were a lot of different approaches that could be taken. I could have converted the entire game to widescreen, but then what about the purists?So I made this approach where I could arbitrarily in the code set any graphic to be aligned to the left or right of the screen or the center. Essentially by dividing the screen into regions that were still 4:3. So for example, I would draw a UI element that was always in the bottom right of the screen on the right, and when the aspect ratio increases, this would still be drawn on the right of the screen in the corner.And by separating out HUD elements like this it gives a fairly consistent experience between different platforms without having to limit the user to a specific aspect ratio.Jeremy: [00:58:00] You've worked on a lot of different games that have been made a long time ago or more recently. What are some of the big differences code-wise you've seen in the oldest projects you've worked on versus the newer ones?Sara:[00:58:15] Well, I actually got my start in fan translation, working on things in assembly, disassembly rather. And obviously the challenges for that are very apparent. You're working with very raw code that you don't have any information on. But as I've gone along, I worked on various Japanese indie games as well as Japanese professional titles.As the time has gone along, I feel that on average these games are more abstracted and more object oriented. And back then there was very little object orientation. There were just these loops and loops upon loops. Nowadays, you'll have various objects that might be inherited from other objects.So a video game's character might be a single generic object that has most of the basic behaviors. And then on top of that, you will have the class for the player character or the class for a dragon. And they have their own unique stuff to them. And obviously the game loop has changed a lot over the years as a result of things like this.Jeremy: [00:59:27] I think that matches how software development in general has evolved because there used to be primarily procedural code, right? And now we're seeing more object oriented code, more code related to functional programming. Maybe that parallels the general software community.Sara: [00:59:49] Yes, I believe so, yeah. In this regard, the evolution does seem pretty parallel. The only limiting factor is that adoption of new programming languages is very slow.Jeremy: [01:00:01] I'm not even sure what they would have used before C++Sara: [01:00:07] C. But before that, they really did just program games in basic assembly. And occasionally in BASIC.Jeremy: [01:00:15] You worked on fan translations where you would have to reverse engineer the code. You said that was assembly?Sara: [01:00:27] Yes. Because when it comes to these games that are already compiled and you're working on them as a fan, you're not going to have any access to the source code ever.So there are two options available to from there. You can either learn how to work with the code that's already compiled by learning the assembly and learning how to debug this.Or you can in some cases to an extent decompile the code if it was made in an existing framework that's well understood like .NET or some other programming languages that exist. But usually you're going to be working with the raw assembly when you're working as a fan and you need a strong understanding of the processor that the game was developed for and the exact sort of quirks to expect.Jeremy: [01:01:18] When you're working as a fan you somehow have to determine where the text is in that game right even though everything is raw assembly. How would you even know where to start?Sara: [01:01:35] Well, initially you would have a debugger that works with the game and you would have to step through step by step until you actually see the texts being drawn. And then you basically start stepping back from there to see how the text was loaded. And so it's all a process of finding first something that uses the function you need to edit and then working your way back.Jeremy: [01:02:01] That sounds very, very time consuming.Sara: [01:02:05] It absolutely is, but it's an interesting process because you learn a lot about how different styles are used in different things.Jeremy: [01:02:16] Not only would you have to to find the text but you would have to find a way to re-insert it without the application breaking.Sara: [01:02:26] Yeah, and in some cases the text would be stored in the application itself, but usually it's going to be in some sort of container you don't have any specifications for. And then it might be in some encoding you don't know. It might even be encrypted and obviously all of the functions for you to fix that are right there, but how do you put it back in? It's easier to extract something than it is to create an archive that works exactly as the one before.Jeremy: [01:02:55] That's interesting. You have these files where you don't know how they're encoded but you're looking through the assembly code to maybe get a hint for how they were generated so you can modify or generate them yourself.Sara: [01:03:09] Exactly. And when it comes to compressions and encryptions. It definitely is much easier to get a file that's already encrypted or encoded or compressed open than it is to make a new one because you have to worry about the size of the file. You have to worry about getting the optimization of the compression right. You mess up one part of the encryption key and everything's wrong.Jeremy: [01:03:36] That sounds like pretty intense work for a fan project.Sara: [01:03:40] Yeah. I actually got my start working on just simple script engines in games like Furcadia of all things when I was young. But as it went along I discovered things like emulation and all these interesting games in a language I didn't understand. And all I could think was how could these games be English? Is there a way? And sure enough, there actually was.Jeremy: [01:04:05] That's really impressive and very cool. For somebody who's interested in modifying or localizing games, How would you recommend someone today get started?Sara: [01:04:20] Well, I would find a project that you like on something like GitHub and simply try changing things and improving things in that first. Make it your own. Essentially with something like this, you need to get comfortable working in other people's code. It's not about learning to program a program yourself. It's about learning to be comfortable in other shoes and being able to cope with the decisions they make.Jeremy: [01:04:52] I feel like general software development, a lot of it is also that right? So many of the projects people work on they're not brand new. They're something that a team has been working on for years and you're coming into that environment, living with the decisions that were made, and figuring out where to go from there.Sara: [01:05:16] Yes. With normal game development, you'll find all sorts of tutorials that teach you how to build a basic platform and game engine or such, but it won't necessarily tell you why it's built that way, and you can make games that way, but you can't really work with somebody else's games from tutorials like that.It has to all be about putting in the footwork yourself and just trying. You just have to try and you just have to keep doing it until it gets right. Just like any other skill.Jeremy: [01:05:43] After all the years of experience you've had are there certain things that you do really differently now than what you did before?Sara: [01:05:55] Oh, definitely. For one, I used to do absolutely everything by hand even stuff like text. I used to copy the text and paste it into files as I needed it and rinse and repeat. And when I was working as a fan translator, sometimes early on I would change the pointers for the text manually when I needed more space.And that is just an awful idea. Automate as much as you can, make sure that whatever you're doing, you're doing it the easiest way you can. But at the same time, don't sacrifice quality for this. But typically you won't.Jeremy: [01:06:38] So basically find the things that you are doing that are repetitive. Identify the things that you can automate and build that script or build whatever functionality you need.Sara: [01:06:52] Yes, exactly. Because if you're spending a lot of time pulling the text out or something like that, you obviously don't need to be. There are cases where you might want to do that, like if there's exactly one or two hard coded strings or just a single menu, but if the project you're working is at any sort of scale that makes that an hours long job? Do not do it manually. Please.Jeremy: [01:07:20] I think that applies broadly as well. How much pain do you need to feel before you just automate it and write that script.Sara: [01:07:32] Yes, exactly. The beauty of being a programmer is you shouldn't need to do much math because you can make the program do it for you.Jeremy: [01:07:40] Cool. I think it's a good place to start wrapping up, but is there anything else that you thought we should have mentioned or talked about?Sara: [01:07:50] I suppose another thing I would like to mention is if you're getting into localization programming for a specific language, like Japanese to English or something like that you should probably try to learn as much of the languages you can along the way. So not just the programming language, but the actual language as well.If you are working on Japanese games a lot, knowing Japanese makes your work so much easier.Jeremy: [01:08:15] What are some of the ways that you've found that knowing the language really helped you a lot?Sara: [01:08:21] Even though all of the texts for a programming language is just gonna be in like ASCII, you're going to be dealing with the fact that all of the comments are going to be in another language. A lot of the function names are going to be in another language. You're going to see a file named Zako and you're not going to know that means a small fry enemy.Jeremy: [01:08:42] Yeah, so just helping you get as many hints and context as you can.Sara: [01:08:49] Exactly. Because when you're working on someone else's code in another language, you are not going to be working with documentation you can necessarily read. All of the documentation is absolutely going to be in that language.Jeremy: [01:09:03] I guess code comments as well if those exist.Sara: [01:09:07] They do usually.Jeremy: [01:09:09] For people who are interested in checking out what you're working on or what you're up to how can they follow you?Sara: [01:09:17] First of all, obviously you should keep up with XSEED's work in general if you want to keep up with what I'm doing. But I also have Twitter @SaraJLeen and I also occasionally do Twitch streams, not of programming, but of games in general. And my Twitch username is @saralene. Sort of a corruption of my name.Jeremy: [01:09:45] You work in a very unique field of software development and I really enjoyed the conversation. Sara. Thank you so much for sharing your experience, translating and porting games.Sara: [01:09:55] Thank you for giving me a chance to talk about the technical side of things.Jeremy: Yeah, it was really fun thanks again for coming on the show.Sara: My pleasure.Jeremy: That's it for my chat with Sara. I hope you check out some of her projects like Corpse Party and Trails in the Sky. She put in a lot of work to make sure they run well on old PCs so don't worry if you've got a slow computer. As usual, a transcript for this episode is available at softwaresessions.com. Alright. See ya.

Spencer Dixon, the CTO and cofounder of Tuple, dives into the intricacies of WebRTC and its applications for remote pair programming. He explains how WebRTC facilitates low-latency communication and shares insights about video codec selection and NAT traversal. The conversation covers Tuple's shift from web to native app development, addressing challenges and optimizations along the way. Spencer also shares strategies for effective learning in programming and the role of TURN and STUN servers in enhancing connectivity for seamless user experiences.

Courtland Allen is the founder of Indie Hackers, a community for people who want to start bootstrapped and profitable businesses. It was acquired by Stripe in 2017. We discuss:Why a SPA was the wrong choiceCaching strategiesUsing firebase and algoliaFighting spamWhy he hasn't hired another engineerFocusing on the right problemsBeing a part of StripeRelated Links:Indie Hackers@csallenStripeHow to Build a Life You Love by Quitting Everything Else with Lynne Tye of Key Values (One of Courtland's favorite podcast episodes)Ember (SPA framework)Ember fastboot (Server Side Rendering)Firebase (Authentication provider and NoSQL database)Algolia (Provides search for posts)Render (Web Host)Dribbble (Site to find design inspiration)Egghead (Developer video courses, got started selling zip files of videos to mailing lists)Balsamiq (Wireframing tool, added inspirational quotes to their loading screen so that people wouldn't complain about loading time)Dan Luu (Popular tech blog with no styling)Music by Crystal Cola: OrionVisit the Software Sessions website for a full transcript of the episode.

Iris Zhang is a gameplay engineer at Riot Games on the League of Legends Champions Engineering team. She previously worked on backend services at Microsoft.We discuss:Working at Microsoft and Riot GamesFinding a role and team that fits youBackend services vs gameplay engineeringBuilding features, testing, and debugging gameplayUsing internal tools to create game logicRelated Links:Personal Site@riotnyanbunClean Code (Book used by Microsoft team)Spring Framework (Java web framework used by League of Legends)Chef (Deployment tool used at Riot)Hazelcast (Cache that Riot Games switched to)What it's like to work on League of LegendsSylas (Champion that can steal ultimates)Clash (Public facing mode worked on by backend team)Music by Crystal Cola: 12:30 AM / Orion

Stephen Cleary is the author of the Concurrency in C# Cookbook and a Microsoft MVP. He has also written many blog posts on asynchronous programming.We discuss:Why he calls manual thread creation legacy codeUsing Async/Await and the Task Parallel Library instead of ThreadsAPIs to avoid when writing concurrent applicationsWhy you shouldn't write TCP SocketsContinuously reading from a socket to detect errorsBuilding state machines to manage socket connectionsRelated Links:@aSteveClearyGetting Started with Async/AwaitTCP/IP SocketsThere is no ThreadConcurrency in C# CookbookMusic by Crystal Cola:Intro: 12:30 AMOutro: Orion

Federico has been writing backends for web applications since 2012 and is the co-founder and chef of alto;code. He wrote a post on GitHub named "How I write backends" that summarizes his process. We discuss: His current stackRedis as a primary data storeReducing the number of layers in your softwareHow duplicating input validation makes code harder to understandIntegration tests over unit testsMinimizing dependenciesWhy you should never normalize alerts Federico Pereiro Personal SiteHow I write backendsOur companyac;pic, our pictures applicationac;tools, our backend services Related LinksFred Brooks & The Mythical Man Month (conceptual integrity)Steve Yegge - Code's worst enemySteve Yegge - Platforms rant (no backdoors, all services talking through the wire as if they were external actors)Book of Hook - Suffer no jankinessTaiichi Ohno & the Toyota Production SystemAuto-activation in software

Noah is the CTO and cofounder of Veryable, an on-demand marketplace for manufacturing, logistics, and warehousing labor. He's also the host of the Code Story podcast where tech leaders reflect on the path they took to create their products.We talk about:Leaving the corporate worldHow poor estimation and scoping nearly sunk his agency Why bad software is worse than no softwareHiring for an agency vs a startupValidating ideas and finding your first customersNoah LabhartPersonal SiteLinkedInOther LinksCode Story (Noah's podcast)Veryable (Current startup)Touchtap (Mobile app agency being wound down)Alcon (Previous employer)Dev Mountain Bootcamp (Bootcamp that Noah hired from)Music by Crystal Cola

Daniel is the co-author of the book "The Good Parts of AWS" and previously worked at AWS on the CloudWatch team. He left last year after over 8 years at Amazon to work on his own projects.He's currently working on an end-to-end encrypted user database SaaS called Userbase. Daniel is also openly sharing his experiences building an audience, writing a book, and building Userbase on twitter.We talk about:Why AWS has so many servicesHis default AWS stack and how he chose it (Dynamo, SQS, S3 and EC2)Why he uses EC2 over ECS or EBSWhy services like RDS and ElastiCache aren't in his bookThe difference between SQS and KinesisWhy AWS will probably never build a Heroku-like serviceThe future of AWSDaniel VassalloPersonal Site@dvassalloOther LinksThe Good Parts of AWSUserbaseOnly Intrinsic Motivation Lasts

Ben is the CEO of Tuple, a pair programming application for remote developers.He currently co-hosts The Art of Product with Derrick Reimer.We talk about:His first crazy programming jobWhy you should speak at conferencesThe trade-offs of remote workWhy great coworkers should be the #1 priority for new developersHow these are "the good old days" of TupleBen's favorite smash bros character...and much more!Ben OrensteinPersonal Site@r00kPodcastsThe Art of ProductGiant Robots (Ben hosted this podcast until episode 240)Other LinksTuple (Remote pair programming application)Refactoring Rails (Ben's video course) How to talk to developers (Fantastic talk for anyone giving presentations)Upcase (Rails, vim, and tmux video tutorials)