 We are pleased to welcome Mr. Puneet Chaganti, a very special guest from Aqba Foundation. Puneet is a seasoned python programmer with over a decades experience and has a blog that has been moderately active for over 14 years. And today they will be sharing with us their expert opinion on writing prose, not just programs. With that, I ask you to give your full attention to Mr. Puneet Chaganti and help me in welcoming him to the stage. Over to you Puneet. Thanks for the introduction, Puneet. Good evening, everyone. Hope you had a nice session, nice day of talks at PyCon. Welcome to my talk titled Write prose, not just programs. I don't know if I need to do the introduction because Puneet gave me a nice one but I'll just say that you can find me online on Twitter or GitHub with the handy punch again. And my blog is at punch-again.news.com. Like you said, it's been moderately active for a while now. There were times where I struggled to keep it alive and had been working on trying to keep it alive in the past couple of years. So I run an informal writing club with a friend of mine and the idea is to set aside time for ourselves to spend some focused time thinking about stuff that we have worked on and stuff that we would like to get more clarity on by writing about them. And I have been working remotely for the last four years or so before COVID forced us all to become remote workers. That's I think important in the context of writing. So yeah, let's begin. So this is the structure of my talk. I mainly have three sections. I'll first talk about why I think writing is important for us as programmers. Then I will briefly mention why having a public place where you write like a blog can be helpful and how it has helped me. And then towards the end, I'll give you some tips on how to make the whole process easier for you and leave you with some references. I'll take questions at the end. I think I'll have enough time to take a few questions. So yeah, like I said, let's generally talk about writing. It could be internal emails that you send to your colleagues or personal notes that you write or an internal blog and stuff like that. So I think writing clarifies our thinking. So this is a quote from one of the Stack Overview users. They say, beginning to ask a question actually helps me debug my problem myself, especially while I'm trying to formulate a coherent and detailed enough question in order to get decent answers. Has this happened to anybody else before? I'm sure some of you have had the experience where you are stuck with a problem. You begin to write out a question to one of your colleagues or chat or email. And while trying to explain your problem clearly, you stumble on the solution yourself. So writing forces you to think more carefully about what you're stuck with or the problem that you're trying to solve. And that sort of leads you to a solution that wasn't otherwise visible to you. This is similar to the concept of rugged ducking, if you've heard of it, that people have a Thai rugged duck on their guest. And they begin to explain problems to the duck and the duck magically gives you solutions. So the idea here is quite similar. I think we all sort of have the experience with writing code that we can only hold so many things in our head. That's why abstractions are useful. And writing things down sort of helps us reduce this mental load. So we are not focused on trying to hold all the things in our head and it frees up the mental space required to actually come up with solutions or make connections between the different parts of the problem or different ideas and things like that. So writing helps improve your thinking and writing and thinking sort of go hand in hand. So as your writing helps you clarify your thinking, so that your clearer thinking makes your writing more readable and understandable to your audience. And as programmers, I think we spend a lot of time not typing away code, but actually thinking about the problem that we need to solve and communicating with our colleagues and other stakeholders in our work about what the problem is and how we solve it and stuff like that. And you may have come across this quote, which is from SICP, which is a very nice programming book. The quote says, programs must be written for people to read and only incidentally for machines to execute. And I think this makes a lot of sense to me. When you're writing a program, you're trying to communicate an idea to your colleagues and not just trying to get something to run. So I argue that writing is essentially a practice for our communication. You have some idea that you want to communicate or express in a way that is understandable to your readers. So writing is some form of communication practice and getting better at thinking, like I said before, and getting better at communication. Both of these, I argue, make us better programmers. And finally, I think writing is the bedrock of remote work, especially I say this after having some experience doing this for a while now. And right now we are all remote workers, right? So I think it's a good time for us to pick up this skill and work on it. A few points to explain why I think so. One is that writing helps those not in the room. It could be your other colleagues, your future self or your future colleagues. It helps facilitate an asynchronous working style. So you don't have to be on Zoom calls all day. And it gives you some focused time where you can not worry about what, about trying to communicate to your teammates what you're doing. You can work on your stuff and later leave a message for them, which also allows them to focus on what they're working on. So asynchronous working style is really good. And searchability aspect of it really shines. Video calls or stuff like this is not really searchable. So I think being able to write well really helps you become a good remote worker. Writing is a vital component of remote work. Now that you've seen why I think writing is an important skill for us, I'll talk a little bit about how having a public blog has helped me and why I try to keep it alive and why you should consider having one too. It's a nice place to have a record of all the problems that you have struggled with over time. And some of them you may have overcome or not. Yeah, and you may encounter some of them again and you surely won't remember all of the problems that you have worked on before. It can also serve as a record for somebody that you're collaborating with. But yeah, it's a nice list of things you can have for yourself. And there have been instances where I totally forgot that I had solved the problem and sometimes I just look it up and I happen to find it on my own blog. So yeah, things like that could happen. I'm sure some of you recognize these two people or these two icons, Avatars on the screen, and Julia Evans and the other is Coding Horror. Both of these are people that I know through their blogs and not because of some tools that I use or things like that. So I think it's a nice body of work blog. It can be a nice portfolio of the work that you have done to show to potential employers, especially if most of the software that you have become is a closed short software. So prospective employers can get insights into how you approach a problem, how you go about thinking about things and how good your communication skills are, which are all important when you're hiring somebody. So yeah, a blog can sort of complement some of the interviews that you go through and it can give a good sense of the culture fit for prospective employers. And then there is the aspect of joy of helping people. It's really nice when people find useful what you have written mostly for yourself. Sometimes I get appreciative comments or tweets or emails saying something that I wrote was helpful for somebody and that keeps me going. This joy is quite something. Also writing publicly sort of helps you be meticulous about the thing that you are writing about, especially when you're learning something new, you tend to slow down and spend time with the ideas that you're learning. It forces you to think about things that you may have just got running by trial and error. To be able to explain something to somebody, you really have to understand what's going on so that you can put the ideas out coherently and your readers can understand what you're trying to communicate. So yeah, my blog has helped me learn a few things by teaching and I also learn from conversations that I stumble into with people on the internet. I happen to have conversations which I otherwise wouldn't have had if I hadn't written about something. So I get to meet some interesting people and also get to learn from them alternative ways of doing something or improving what I'm doing currently and stuff like that. So that's about why I think or how I think my blog has helped me and maybe some of it resonates with you. Let me get to some tips that I have sort of collected over the last few years while trying to write more deliberately. Writing can sometimes feel like work. It might feel like additional work that you need to do. You can look at the internet and find a whole lot of dead blogs, blogs that were started by excited people but then couldn't keep it going after a point of time. So I hope some of these tips will help make the whole process easier for you. Firstly, reduce the friction you have to write. So David McCullough, this popular quote where he says, writing is thinking and to write well is to think clearly which is hard. So you already feel the mental strain when you're trying to write something and trivial things like having to need to login into your blogging service or having to open up your editor and name your file in a particular fashion and things like that. They seem trivial but they can act as mental barriers when you're trying to write something or when you're trying to avoid writing something essentially. So make the process as simple as you can. Automate things like creating a new post or publishing your post after you're done and things like that should be automated and quick to do. That I found really helps me. The other thing I would say is make sharing a part of the process when you feel like writing is additional work, you tend to not do it. But I would argue that you already write a lot in the form of maybe emails or chat messages or things like that and it helps to collate these into something that is more long lasting. So if you're writing an email to a person, think about whether it makes sense to make it an internal blog post and if you're writing an internal blog post, think about whether it makes sense to make it a public blog post so it benefits a bigger audience. And yeah, poor communication creates more work. So ideally you want to communicate as well as you can. So sharing a part of the process helps with all of this. So while you're working keep notes on what you're working on or any thoughts that you have, the inputs, outputs, error messages that you see and stuff like that and when you're done with solving the problem, it's sort of easy to cut bits and pieces out of it and make something which is more coherent for somebody that's not you. So make sharing a part of the process. The other thing that I often stumble or I've seen other people stumble is not knowing what to write about. You sometimes feel like you have to be an expert on the topic when you're writing about something but that's not necessarily true. You can write about things that you're learning. You can write about things that you don't already know and use writing as a form of learning. You can write to test your knowledge, with people who are more knowledgeable and get some feedback on it. So you can write about potential ideas that you don't have time to explore but somebody else might pick it up and things like that. So the piece of writing doesn't have to be the canonical piece on a particular topic or question. Just sharing your learning and experience will sort of help you solidify your learning and understanding. I see a couple more. I think this is the most important thing that I would say I found the most useful. Set aside a specific time to write. Like I mentioned at the beginning, I run a writing club with a couple of friends of mine and that has actually helped me write blog posts which I would never have come up with otherwise. So just forcing myself to sit down and think about things that I want to write about sort of brings out some of these vague ideas that would have just floated by or died down because I didn't have enough time to tie around with those ideas. So setting aside a time to write is really helpful. This talk, for example, was... Yeah, I worked on the talk slides and talk proposal and all of that in some of those sessions. Next thing would be write for one person. Often people are confused including me on who is the audience that we are writing for. And this is a clip from Julia Evans and I found it very useful. Write to one person and write as if you are talking to that person. This gives you three things. Firstly, it gives you a style. You don't have to use very flowery language or anything of that sort. You can just write as if you are talking to that person. So it gives you a consistent style which is your own style. And the second thing it gives you is... You have an idea of what level of detail you need to go into that blog post. You need to start at a beginner level, intermediate level, advanced level, for example, because you know exactly who you are writing this for and the context in which you are writing this. The third thing is people often worry about oh, nobody is going to read my blog post. But now you have one person that you know would be interested in doing this and you can always share it with them. So you don't have an excuse not to write now. And you can write much more clearly. Other people might find this interesting or useful and if they need something, they'll find it if you have it on a public blog. But writing for one person really helps. This I think is something that I've learned in the last couple of years or so. It might be obvious to people who have written stuff over a while, maybe code or programming or like prose. Editing is where the magic happens. So previously I think my writing was more a stream of consciousness type. I could just dump stuff and not spend too much time on rewriting or revising what I have written. And first drafts are rarely any good. So spending time on trying to rewrite what I have written forces you to think harder. And I think that is where the clarity in thinking generally comes from. There is some merit in writing things down but actually rewriting and revising what I have written to communicate things better can actually lead to new ideas and bring more clarity in what you have been thinking about. So review your own blog post. Get other people to review your drafts. Spend some time rewriting and thinking about what you have written. There's one tip that I picked up from somewhere which I found really useful. When you're asking people to review your drafts, you can give them a sense of what kind of feedback you're looking for by using these two options which are called 30 question feedback and 90 question feedback. 30 question feedback essentially means you have your piece of writing is 30 question done. It means it's in the initial stages. You have an initial idea and some idea of how you want to present it, some structure in your mind and you want feedback on the idea itself or the structure or what other things you could add to it and stuff like that. And 90 question feedback would be more nitpicky feedback if you could call it that. More like grammatical errors or minor changes to what you have written and nothing major. Giving people this kind of requirement sort of helps you get better feedback. And finally, if you really want to get good at writing, you can sort of try to work with a professional editor and I've heard from people that it actually really helps a lot. My final tip could be read. Read about things that interest you, what other people have written on the topics that you are interested in, which will give you some content that you can sort of respond to in your writing. But don't just read for the content. Read with the intention of learning to write. Pay attention to the writing style, the structure. Think about what it is about that piece of writing that you like and try to emulate that. A couple of blogs that I like are Julia Ivans and Dan Lu. I share these slides so you can check them out. And I think that's about it. I'll share a couple of references. So in this talk, I haven't actually talked about working on the actual style of writing or improving your content. But I found this last reference a guide to writing well by Julian Shapiro quite useful. The reference before that is a blog course on the Writing Club idea, which actually inspired me to start our writing club. And you should check it out and start something with people you know would be interested in, maybe at your workplace or somewhere else. And that's about it. I hope I get to read some of your writing. And if there's one thing that you take away from this talk, I'd say that writing helps us become better programmers and it is worth setting aside time to write things down. Thank you. I can take questions now instead of me. I don't think you left a lot of untried ends, Manit. On behalf of Bykon India, I thank you for the talk. Manit, frankly, I think I could use a lot of these steps, especially the bit about setting time aside to write. For any late questions, please feel free to catch Manit at the speaker lounge for Zulip. And we'll continue with the next talk in about five minutes. Stay tuned. Thanks, Pesh. Thanks, everyone.