Ifedolapo Ojo’s Post

I had an interesting weekend going over technical API docs and the exercise inspired this post. (Closeness bias in technical documentation)😅 Closeness bias happens when you're too familiar with a subject and assume others know more than they do. For technical writers, who often work closely with engineers, product teams, and technology itself, this bias can manifest in various ways, such as skipping essential details, overusing jargon, and many assumptions that overall impact the clarity and accessibility of your content. ⏯️Example: Let's say a technical writer, Bibi, is documenting a new API. She's been in constant communication with developers and knows the API inside out. Because of this, her guide dives right into complex terms like "OAuth flow" without explaining the basics. A new developer trying to learn gets lost because Bibi assumed they already know the background. (This is not good for overall developer experience) Some of the ways I think you can avoid closeness bias include; 🚀Get feedback from people who aren't familiar with the product. 🚀Have someone less involved check if it's clear. 🚀Regularly check if your writing is accessible to beginners, not just experts. Your proximity to a subject tends to make you overlook critical details obvious to an outsider. Being aware of closeness bias helps you create clear, user-friendly documentation for everyone, no matter their expertise level. Well good luck and have a wonderful week. 🥳✨🧡 #documentation #technicalwriting

GM, technical writers! 🌞 Should you learn to code? 🤔 Say it with me: Yes! But not to become developers. You just need to learn enough to really understand your audience—developers. 👨💻👩💻 Here’s why coding helps you as a technical writer: - You’ll relate to developers’ challenges 🛠️ - Your documentation will be clearer and more accurate ✍️ - You’ll speak the same language as developers 💬 It’s not about becoming a coding expert. It’s about leveraging empathy and clarity to improve the content you create. So, say it back: Yes! 💪

This one is too good.🤣 Why did the developer bring a technical writer to the bug fix meeting? Because when they explain it, even the bugs feel documented and understood! #infodev #technicalwriting

🌟 Attention Aspiring Technical Writers! 🌟 As a technical writer in the software industry, I've navigated the intricacies of creating clear and effective documentation. One of the most valuable skills in our field is a solid understanding of the technologies we write about. Today, I want to share an incredible resource for anyone looking to deepen their knowledge of JavaScript: [Introduction to JavaScript | web.dev](https://lnkd.in/e8_tdzyg). This comprehensive guide covers everything from the basics to more advanced concepts, helping you grasp the language that powers so many applications today. Why is this important for technical writers? 1. Clarity in Communication: Understanding the technology you're writing about allows you to explain complex concepts in a simple and engaging manner. 2. Building Credibility: Knowledge of the tools and frameworks strengthens your authority as a technical writer. 3. Collaborative Spirit: Engaging with developers enables better collaboration, leading to effective and accurate documentation. I invite all aspiring technical writers to take a look and enhance your skills. Let’s cultivate our learning journey together! Share your thoughts, experiences, or additional resources in the comments. What challenges have you faced in understanding technical concepts? Happy writing! ✍️ #TechnicalWriting #JavaScript #SoftwareDocumentation #LearningCommunity

✍️✨Calling all #Techies with a flair for #writing! ✍️✨ Are you a tech leader, enterprise #decision-maker, #developer author, or seasoned technical writer? Join #Techscribe - Middleware's community writer program and share your expertise through top-tier, original #articles! Since our inception in 2022, we’ve been focused on creating technical #content to help developers build better #applications. Our blog is read by thousands of developers each month, and we're looking to add more helpful articles. 👥 Who We're Looking For: 💠 Professional experience with backend languages (#Python, Node.js, #Java, #Golang, etc.) 💠Solid understanding of #backend technologies, #DevOps, or #observability practices. 💠Ability to create comprehensive guides/tutorials with clear #code samples. 💡 Why Write for Us? 💠Earn $150 - $350 per published article. 💠Boost your online #presence with clear #bylines and social links. 💠Your content reaches thousands of monthly visitors and gets promoted across our social media, #Slack, and other communities. 💠Get valuable feedback and tips to enhance your writing skills. 👉 Ready to join us? Apply today: https://lnkd.in/gFY9afBq

Developer documentation is the product! If you are a DevRel/technical writer (especially at a devtool company), I wrote a detailed article on how to write good developer documentation. Covered: → Learnings from the best developer docs → 5 tips on writing good developer docs. 🔗 Head on to Hashnode blog to read: hshno.de/Jbxn9LG

𝗔 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝘄𝗿𝗶𝘁𝗲𝗿 𝗶𝘀 𝗮 𝗷𝗮𝗰𝗸 𝗼𝗳 𝗮𝗹𝗹 𝘁𝗿𝗮𝗱𝗲 I've said it before and I'd say it again, there's no field technical writing can't fit into. Just like they say that your web2 jobs can be brought into web3 All you need is to know how to effectively collaborate and the work is done 𝗛𝗼𝘄? 🔸As a technical writer you'd need to build your strength around teamwork, for example if you are to write an API DOCUMENT containing codes but you know nothing about programming languages, the easiest way to land that job is collaboration. Let someone help you with the code while you do the other things. 🔸Learn how to pitch yourself and what you do effectively: Opportunities won't always project itself, sometimes you have to project yourself to opportunities. It's either you are ready for opportunities or opportunities are ready for you but won't Find you worthy. The best way to get easy collaborations is to pitch yourself. 🔸 Carry what you do on your head: Don't hide it that you can write white papers because the person that saw it today might not retweet or repost but recommend you. 🔸 Finally, join communities and be active in them. Are you learning? #Technicalwriting #writing

#TechnicalWriting #SoftwareDocumentation #SoftwareDevelopment #DocsAsCode: "While writing documentation is the most obvious part of a Technical Writer’s job, it’s actually the element you will probably spend the least amount of time on in your day-to-day work. “I write maybe a quarter of my time,” says Mike. The rest of the day is made up of activities like: - Setting up and testing software - Figuring out the process and schedule for releasing a new feature - Identifying and submitting bug reports Technical Writers typically write about brand new features that haven’t been documented or released yet, Mike says. Experimenting in this early stage naturally leads to finding bugs and collaborating with development to determine workarounds. While filing bugs sounds like a diversion, Mike says it’s actually a big part of what makes the role rewarding. “When I finally get to the solution, I think, ‘Wow, this actually works! I can’t wait to write about this.’”" https://lnkd.in/drjDCh7i

#TechnicalWriting #SoftwareDocumentation #SoftwareDevelopment: "I bet that every developer has been at this point in his or her career: when you've been programming for so long that your eyes are starting to tear up a little, you've produced what feels like a million syntax errors and have grudgingly fixed them again, and generating a different error message is already considered a daily success. Until the moment finally comes when everything suddenly works. And why? Well, only God knows! What a really funny meme from Reddit so humorously depicts becomes a problem at the latest when 3 weeks later your colleague wants to know how she can get your code to work. Unfortunately, she reacts slightly irritated to your suggestion to simply drop by at church next Sunday. That this is not an individual case becomes clear when you consider that the image above has received more than 17,000 upvotes. At this point, something should be obvious: if we want to avoid wasting 254 hours trying to understand our software, we need to change the way we work! A solution There is certainly no universal remedy, but there is a promising approach: technical writing." https://lnkd.in/dW84WFht