Id Rather Be Writing Podcast Feed

I'd Rather Be Writing Podcast Feed

Synopsis

A technical writing podcast about the latest trends and practices in the field of technical communication. Technical communication includes topics like technical writing (software help), information architecture, usability, API documentation, information design, web design, illustration, DITA, structured authoring, visual communication, and more. If youre a technical writer or interested in technical writing, this is the one of few podcasts in this niche. I also have a blog at http://idratherbewriting.com where the podcasts and other blog topics are published.

People who listen this also listen:


Episodes

  • Podcast: Dealing with Project Overload -- Strategies to Manage Overflowing Documentation Tasks
    Podcast: Dealing with Project Overload -- Strategies to Manage Overflowing Documentation Tasks
    02/10/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. I was reading a post on the technical writing sub-Reddit community about dealing with project overload and thought it would be a good topic for a podcast. The Reddit post is In over my head - service docs, user docs, and localization (requesting advice). In part, the topic resonated with me because I’m sort of overloaded myself right now, so I thought it would be good to think through some of these challenges. In the post, “keyboardqueen90” describes how she’s buried in work, her manager doesn’t understand what she does, others underestimate the time required to write docs, requests for more support fall on deaf ears, she doesn’t have time to ramp up on tools/tech or influence design because the docs fully occupy her time, she lacks any champion or advocate at the leadership level, she’s a team of one, and more. My podcast is short, but here’s an even shorter summary. To manage incoming work, especially w

  • Podcast: 10 myths about API documentation
    Podcast: 10 myths about API documentation
    29/09/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. 10 myths about API documentation Here are the myths I address in the podcast. You must read source code to write docs. You’ll need to extrapolate sample code from one language to create code samples in another. You must be a former engineer to be competitive in the API doc space. Technical writers usually create the reference material (e.g., OpenAPI spec, Javadoc). Almost all job interviewers care about, when it comes to API doc jobs, is technical know-how. Developers can and will write if you implement a docs-as-code process. Because their role aligns with the audience, with API docs, developers are most suited to be the ones writing for other developers. API documentation and developer documentation are synonymous. Docs that look good are good. People will respect you more if the word “writer” isn’t in your job title. In the podcast, I mentioned this NY Times article: In the Salar

  • Recording of Tech Comm Trends Presentation (STC Puget Sound chapter)
    Recording of Tech Comm Trends Presentation (STC Puget Sound chapter)
    08/06/2019

    Video Audio Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Slides Presentation description Tech comm trends: Providing value as a generalist in a sea of specialists Trends in technical communication can be hard to decipher, even when looking at data. But one underlying trend is that technology seems to be getting more specialized and complex. This trend toward specialization is driving up the value of technical knowledge, making it more prized than writing skills. To handle the complexity, technical writers may find that they are playing increasingly collaborative roles with engineers to create the needed documentation. To drive up their value in organizations, technical writers should look for ways to collaborate more skillfully with engineers in creating content. Takeaways: The growing complexity in the technology landscape is ratcheting up the importance of technical knowledge in organizations, overshadowing writing skills.

  • Crash course in API documentation -- a one-hour video
    Crash course in API documentation -- a one-hour video
    16/05/2019

    I mentioned in my STC Summit slide links post that I recorded my “Intro to API documentation” presentation using the on-board mic on my laptop, and that STC let me post it on my blog. The sound in the recording isn’t great, but if you’re interested, the video is available below. Someone who recently watched the video wrote me to say, Btw, the one hour crash course was great. I just watched it. This will be my go-to-link to send people interested in the space. It’s a lot of content for a beginner, but its variety and your talking more holistically about the workflow/mindset made it a great introduction. Bravo! In this introductory presentation, I explore Sendgrid as a good example of API docs. For more API documentation recordings, see Video recordings of API doc workshops. I also rendered this video as a standalone audio file in case you prefer it this way: Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. var contents=new Array() content

  • Corporate exodus narratives: A close look at the tension between the corporation and academia
    Corporate exodus narratives: A close look at the tension between the corporation and academia
    01/03/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Going to an academic conference Last year I started a project aimed at bridging the gap between practitioners and academics, and after a number of conversations with one academic, I was invited to speak at the Symposium for Communicating Complex Information, which is a small conference (held in Louisiana this year) that consists almost entirely of academics. I’m always intrigued at opportunities to attend conferences I’ve never been to before, especially to interact with people I’m not accustomed to interacting with, so I thought a two-day immersion with academics might be fun. I agreed to present on trends in technical communication. The conference took place in Louisiana Tech University’s Academic Success Center in Bossier City (just outside of Shreveport), LA. Presenters followed a format where they spoke for just 15 minutes and then transitioned to 15-minute Q&A with the audience. The presentatio

  • Recording and slides for my trends presentation at the Symposium for Communicating Complex Information (SCCI)
    Recording and slides for my trends presentation at the Symposium for Communicating Complex Information (SCCI)
    24/02/2019

    About the Symposium for Communicating Complex Information You can view the conference program and schedule for the Symposium for Communicating Complex Information here. My presentation on trends My presentation was a keynote on tech comm trends called Tech Comm Trends: Providing Value as a Generalist in a Sea of Specialists. You can view my slides at trends-growing-disproportions. The recording of my presentation is available here: If you just want to listen to the audio, you can listen here: Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Latest thoughts on trends Although I’ve written and spoken about trends several times this year, I shifted focuses a bit in this presentation. I abandon the argument that technical skills are in such high demand because the technology landscape is getting more complex. (It might be true, but it’s a hard argument to make, and I’m not so sure about it anymore given some responses in my ongoing Engineers writ

  • How to become a 10X technical writer in the workplace
    How to become a 10X technical writer in the workplace
    07/02/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Background The term “10X engineer” (pronounced 10-ex) is sometimes used to describe engineers who are ten times more productive than other engineers. It describes someone who is simply more efficient, capable, and accomplishes more than others. The Silicon Valley Dictionary explains: “10X-engineer”: A concept sometimes used in Silicon Valley to describe an engineer that is 10X more productive than an average engineer although the 10X metric is figurative. Sometimes referred to as “Ninjas”, these engineers are highly sought after by all tech companies Jim: You gave me 100 resumes but none of these guys are 10X engineers. Why hire a few of these guys to slow us down when a 10X engineer is so much more productive? For more on this term, see 10X Engineer Series. What has prompted my interest in becoming a 10X technical writer? Well, lately I feel like I’ve let my edge slip a bit at work. I don’t feel

  • How to motivate users to provide feedback: Show that youre listening to their input
    How to motivate users to provide feedback: Show that you're listening to their input
    01/02/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Our original feedback form A few months ago, we added a feedback form to our Appstore docs at work. Right below the title on every page, we added an easily visible button that says “Submit Feedback.” The button opens a Qualtrics form where users can submit ratings and comments. This initial feedback form looked like this: Not a lot of feedback came in through this form — maybe one legitimate comment a day on average. Our metrics say about a thousand people visit the docs a day, so why weren’t more people leaving feedback? I doubted they were all finding exactly what they needed and leaving happy and satisfied. Designing for feedback I wanted to tweak my feedback form to maximize the number of responses. I considered questions like these: What factors influence whether users decide to leave feedback? Are there design implementations that might double or triple the responses? How could we ra

  • Recording for Menlo Park API documentation workshop now available -- and some thoughts on using cardioid versus omnidirectional microphones for recording
    Recording for Menlo Park API documentation workshop now available -- and some thoughts on using cardioid versus omnidirectional microphones for recording
    04/12/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. I published the recording of the API documentation workshop that I recently gave in Menlo Park (on Nov 8, 2018). You can view the recordings on my API documentation site here: Recorded Video Presentations. This API documentation workshop (which I mentioned earlier) was a full-day workshop, so there are more than 5 hours of recorded material here. If you’re really into workshop recordings, you can also listen to the Denver API workshop that I gave earlier this year (March 2018). Notes on recording – cardioid versus omnidirectional For the Denver workshop, I used a Movo cardioid lapel mic. However, I think cardioid was the wrong choice because it requires you to have a consistent distance from the mic. When you’re presenting, you might turn your head from side to side or up or down. Cardioid mics are very sensitive to changes in position like this, and the volume fluctuated a lot as a result. Also, the au

  • New post in Simplifying Complexity series -- Principle 11: Be both a generalist and specialist through your technical acuity
    New post in Simplifying Complexity series -- Principle 11: Be both a generalist and specialist through your technical acuity
    30/11/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. You can read the essay here: Principle 11: Be both a generalist and specialist through your technical acuity. How exactly does the topic of being a generalist or specialist tie in with simplifying complexity? Here’s an excerpt: Do technical writers, who are typically only familiar with the subjects we write about, need to become engineer-like specialists, focusing in on a couple of domains in depth, so that we can write, edit, and publish more knowledgeably in these domains? Is specialization the only way to handle complexity? Will I need to become a specialist to survive as a technical writer in the future? Note that this content has undergone multiple iterations: First version Second version Third version In this third version, I expanded the research in places, provided better organization in my analysis, and tried to integrate some more personal stories in places. I also narrated it as

  • How to avoid being a secretary for engineers
    How to avoid being a secretary for engineers
    19/11/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Critical inquiry versus vocational knowledge Lately I’ve been thinking about two types of knowledge: intellectual knowledge versus vocational knowledge. Or rather, critical inquiry versus technical how-to. Or theoretical knowledge versus practical knowledge. In short, asking why versus asking how or what. I’m not entirely sure how to characterize the differences, but the difference in focus has contributed to some angst in my tech writing career lately. Rewind a bit to my previous posts on trends (such as this one or this earlier one), and you’ll find that I’ve been wrestling with the question of whether to be a generalist or specialist. Regardless of any generalist/specialist outcomes around research and what employers want, etc., it’s hard to escape this one critical fact: you can’t write without knowledge. Unless you have a more solid technical grounding, you just can’t write much about those topics.

  • Upcoming full-day API documentation workshop in Menlo Park
    Upcoming full-day API documentation workshop in Menlo Park
    31/10/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. You can learn more about the API documentation workshop on eventbright here. The workshop will be held from 8am to 5pm at the Quadrus Conference Center. The workshop will follow my API documentation course closely. In fact, I’ve been updating my workshop activities a bit in preparation for the course. If you’re interested, be sure to sign up. Let me know if you have any questions. var contents=new Array() contents[0]=' Sponsored message:Over 40,000 API developers use SwaggerHub to design and document APIs with Swagger (OpenAPI). Learn how SwaggerHub can help improve your team’s API documentation workflow. >Get started for free.' contents[1]=' Sponsored message:SwaggerHub was built by the team behind Swagger to help organizations collaborate on their API design and documentation from one centralized platform. Find out why SwaggerHub is the platform for design and documenting APIs with Swagger. >G

  • Preferring technical acuity over specialized knowledge
    Preferring technical acuity over specialized knowledge
    24/10/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. The unresolved debate between being a specialist or generalist After I gave a recent presentation on trends, some of the attendees felt I left the dilemma between being a specialist or a generalist unresolved. Some said, “So, should I be a specialist or a generalist, and if I specialize, what should I focus on?” Others were incensed that I wasn’t considering language expertise to count as specialized knowledge. I knew this was a controversial subject, and I would no doubt anger people off because to suggest that their writing expertise doesn’t count as specialized knowledge in the same light as engineering specializations. So there are a few loose ends that I’d like to resolve in this trends presentation before I give it again. Overall, in the Q&A after my session, attendees seemed to come to the conclusion that technical acuity was more important than specialized knowledge, and that it was better th

  • If writing is no longer a marketable skill, what is?
    If writing is no longer a marketable skill, what is?
    09/08/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Site metrics gives insight about the skills people want The other day I looked at site metrics for my two sub-projects: API documentation and Simplifying Complexity. The traffic on my Simplifying Complexity site is only about 1.73% of the overall traffic on my site — here the traffic for Simplifying Complexity for the past 3 months: In contrast, the traffic on my API documentation site (for the past 3 months) is about 60% of my site’s overall traffic: How do you interpret this disparity? It seems pretty clear that one type of content is sought after more than the other. Granted, the API doc site has more pages (96 instead of 11) and it’s been around longer, and I’ve given lots of API doc presentations referring to it. But I think it’s more than that. People seek to learn about skills they lack. API documentation is one of these sought-after skills; simplifying complexity isn’t a skill people search o

  • My conflicted thoughts about the decentralized web (while taking the Census of Technical Communicators survey)
    My conflicted thoughts about the decentralized web (while taking the Census of Technical Communicators survey)
    06/08/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. About the Census Survey Researchers at Concordia University (including Saul Carliner) are conducting a “Census of Technical Communicators.” The survey takes a while to complete (20 min.), but it’s well worth the time, and I’m fascinated to see the upcoming results. You can take the survey here: Census of Technical Communicators Survey. Some of the census questions will prompt some serious reflection. For example, these two questions: As a technical writer, where do you feel the most pain or friction? How do technical writers in your organization feel the most pain or friction? There’s also an entire section about resources you consult for professional development, including blogs. The survey names several blogs specifically, including the one you’re reading: Advertising’s impact on the web’s original ideals I’m excited to see blogs listed as sources for professional development here, because in

Informações: