Tech Writer koduje

Podcast o technicznej stronie tworzenia dokumentacji w IT. Skupiamy się na tym jak Tech Writer może wpasować się w środowisko programistów zarówno pod kątem sposobu pracy jak i używanych technologii, narzędzi i rozwiązań. Staramy się też pokazać, że praca Tech Writera może być ciekawa i rozwijająca pod kątem umiejętności technicznych.

Kategorie:
Technologia

Odcinki od najnowszych:

#64 Tech Writer czepia się DITY, czyli jak tworzyć treść, która się dobrze wyszukuje
2024-03-27 10:53:17

Standard DITA, czyli Darwin Information Typing Architecture, nie jest zły sam w sobie, ale może skłaniać nas do stosowania pewnych praktyk, które wpływają negatywnie na wyszukiwanie. Przykładem mogą być strony, które mają bardzo mało treści, przez co nie są zbyt pomocne, a jednocześnie zabierają cenne miejsce na liście wyników wyszukiwania. Kolejną kwestią jest ponownie wykorzystanie treści, czyli reuse. Jest to temat szeroki a problemy z nim związane dotyczą nie tylko standardu DITA. Rozmawiamy o tym co powoduje, że wyniki wyszukiwania nie są pomocne, złych praktykach w tworzeniu dokumentacji w wersji webowej, problemach z reusem i potencjalnych rozwiązaniach. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "Darwin Information Typing Architecture", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture Post Pawła na LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7176518908634439680 "Content reuse – a productivity booster or a vicious circle?", JetBrains blog: https://blog.jetbrains.com/writerside/2022/08/content-reuse-a-productivity-booster-or-a-vicious-circle/ "Chunking", OASIS: https://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/chunking.html "Definition of DITA maps", OASIS: https://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/definition-of-ditamaps.html "Every Page is Page One: Topic-based Writing for Technical Communication and the Web", Mark Baker: http://xmlpress.net/publications/eppo/ "Topic-based authoring", Wikipedia: https://en.wikipedia.org/wiki/Topic-based_authoring "Single-source publishing", Wikipedia: https://en.wikipedia.org/wiki/Single-source_publishing

Standard DITA, czyli Darwin Information Typing Architecture, nie jest zły sam w sobie, ale może skłaniać nas do stosowania pewnych praktyk, które wpływają negatywnie na wyszukiwanie. Przykładem mogą być strony, które mają bardzo mało treści, przez co nie są zbyt pomocne, a jednocześnie zabierają cenne miejsce na liście wyników wyszukiwania. Kolejną kwestią jest ponownie wykorzystanie treści, czyli reuse. Jest to temat szeroki a problemy z nim związane dotyczą nie tylko standardu DITA.

Rozmawiamy o tym co powoduje, że wyniki wyszukiwania nie są pomocne, złych praktykach w tworzeniu dokumentacji w wersji webowej, problemach z reusem i potencjalnych rozwiązaniach.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "Darwin Information Typing Architecture", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
  • Post Pawła na LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7176518908634439680
  • "Content reuse – a productivity booster or a vicious circle?", JetBrains blog: https://blog.jetbrains.com/writerside/2022/08/content-reuse-a-productivity-booster-or-a-vicious-circle/
  • "Chunking", OASIS: https://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/chunking.html
  • "Definition of DITA maps", OASIS: https://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/definition-of-ditamaps.html
  • "Every Page is Page One: Topic-based Writing for Technical Communication and the Web", Mark Baker: http://xmlpress.net/publications/eppo/
  • "Topic-based authoring", Wikipedia: https://en.wikipedia.org/wiki/Topic-based_authoring
  • "Single-source publishing", Wikipedia: https://en.wikipedia.org/wiki/Single-source_publishing

#63 Tech Writer poznaje moc języka w produktach cyfrowych, czyli dlaczego UX writing jest ważny
2024-02-26 06:54:50

Wyobraź sobie aplikację bez interfejsu. Ciężko się nie zgodzić, że używanie takiego produktu byłoby trudne. Dlatego istnieją specjaliści tacy jak UX Designer. A teraz wyobraź sobie interfejs bez tekstu. Efekt jest właściwie taki jakby tego interfejsu w ogóle nie było. Na co dzień nie zwracamy uwagi na to, że aplikacje komunikują się z nami głównie za pomocą tekstu. Dlatego ważne jest, żeby wszelkie opisy pól, przycisków czy komunikaty były napisane w sposób, który efektywnie prowadzi użytkownika do osiągnięcia celu. I tutaj na białym koniu wjeżdza UX Writer. Pewnie mało kto zdaje sobie sprawę z tego, że teksty w interfejsach to osobna dziedzina, która rządzi się swoimi prawami. Razem z naszym gościem, Wojtkiem Aleksandrem, rozmawiamy m.in. o tym czym jest UX writing, o dobrych praktykach, o tym czego unikać i o wyzwaniach jakie pojawiają się kiedy tworzymy teksty w języku polskim. Ramą dla naszej rozmowy jest wydana niedawno książka Wojtka "UX writing. Moc języka w produktach cyfrowych". Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "User experience, UX", Wikipedia: https://pl.wikipedia.org/wiki/User_experience "What is plain language?": https://www.plainlanguage.gov/about/definitions/ Konferencja soap!: https://soapconf.com/ "Bad UX Cost Citibank $500M – What Went Wrong?", CMSWire: https://www.cmswire.com/digital-experience/bad-ux-cost-citibank-500m-what-went-wrong/ "Inbox Zero, czyli porządek w skrzynce pocztowej", Codziennie Produktywnie: https://codziennieproduktywnie.pl/inbox-zero/ Grammarly: https://www.grammarly.com/ Wordtune: https://www.wordtune.com/ Frontitude: https://www.frontitude.com/ Hemingway Editor: https://hemingwayapp.com/ Logios Redaktor: https://redaktor.logios.dev/ "UX writing. Moc języka w produktach cyfrowych" (Helion): https://helion.pl/ksiazki/ux-writing-moc-jezyka-w-produktach-cyfrowych-wojciech-aleksander,uxwri.htm#format/d "UX writing. Moc języka w produktach cyfrowych" (Onepress): https://onepress.pl/ksiazki/ux-writing-moc-jezyka-w-produktach-cyfrowych-wojciech-aleksander,uxwri.htm Profil Wojtka Aleksandra na LinkedIn: https://www.linkedin.com/in/waleksander/

Wyobraź sobie aplikację bez interfejsu. Ciężko się nie zgodzić, że używanie takiego produktu byłoby trudne. Dlatego istnieją specjaliści tacy jak UX Designer. A teraz wyobraź sobie interfejs bez tekstu. Efekt jest właściwie taki jakby tego interfejsu w ogóle nie było.

Na co dzień nie zwracamy uwagi na to, że aplikacje komunikują się z nami głównie za pomocą tekstu. Dlatego ważne jest, żeby wszelkie opisy pól, przycisków czy komunikaty były napisane w sposób, który efektywnie prowadzi użytkownika do osiągnięcia celu. I tutaj na białym koniu wjeżdza UX Writer. Pewnie mało kto zdaje sobie sprawę z tego, że teksty w interfejsach to osobna dziedzina, która rządzi się swoimi prawami.

Razem z naszym gościem, Wojtkiem Aleksandrem, rozmawiamy m.in. o tym czym jest UX writing, o dobrych praktykach, o tym czego unikać i o wyzwaniach jakie pojawiają się kiedy tworzymy teksty w języku polskim. Ramą dla naszej rozmowy jest wydana niedawno książka Wojtka "UX writing. Moc języka w produktach cyfrowych".

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "User experience, UX", Wikipedia: https://pl.wikipedia.org/wiki/User_experience
  • "What is plain language?": https://www.plainlanguage.gov/about/definitions/
  • Konferencja soap!: https://soapconf.com/
  • "Bad UX Cost Citibank $500M – What Went Wrong?", CMSWire: https://www.cmswire.com/digital-experience/bad-ux-cost-citibank-500m-what-went-wrong/
  • "Inbox Zero, czyli porządek w skrzynce pocztowej", Codziennie Produktywnie: https://codziennieproduktywnie.pl/inbox-zero/
  • Grammarly: https://www.grammarly.com/
  • Wordtune: https://www.wordtune.com/
  • Frontitude: https://www.frontitude.com/
  • Hemingway Editor: https://hemingwayapp.com/
  • Logios Redaktor: https://redaktor.logios.dev/
  • "UX writing. Moc języka w produktach cyfrowych" (Helion): https://helion.pl/ksiazki/ux-writing-moc-jezyka-w-produktach-cyfrowych-wojciech-aleksander,uxwri.htm#format/d
  • "UX writing. Moc języka w produktach cyfrowych" (Onepress): https://onepress.pl/ksiazki/ux-writing-moc-jezyka-w-produktach-cyfrowych-wojciech-aleksander,uxwri.htm
  • Profil Wojtka Aleksandra na LinkedIn: https://www.linkedin.com/in/waleksander/

#62 Tech Writer sprawdza co w tech writingu piszczy, czyli rzut oka na ankietę od JetBrains
2024-01-28 20:50:32

Wyniki ankiety JetBrains, "The State of Developer Ecosystem 2023", jakie są, każdy widzi. Mało kto używa dity, wszyscy kodują. Ale skąd takie właśnie wyniki i jaką grupę one odzwierciedlają? Czy Tech Writerzy używają narzędzi enterprise? Czy testują dokumentację? Czy wyłania się nam persona Tech Writera, który koduje? Patrzymy na wyniki ankiety krytycznym okiem, badamy czy mogą one sugerować trendy przyszłości i staramy się ocenić kontekst. Jako bonus bierzemy na warsztat Writerside - narzędzie JetBrains do tworzenia dokumentacji. Omawiamy jego funkcjonalności i fundamentalną zasadę działania. Czy jest to remake MadCap Flare'a? Posłuchaj naszej rozmowy, a dowiesz się co o nim sądzimy. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "The State of Developer Ecosystem 2023", JetBrains: https://www.jetbrains.com/lp/devecosystem-2023/ Writerside: https://www.jetbrains.com/writerside/ "Docs as code", Write the Docs: ⁠https://www.writethedocs.org/guide/docs-as-code/ Chris Chinchilla: https://chrischinchilla.com/ MadCap Flare: https://www.madcapsoftware.com/products/flare/ Adobe RoboHelp: https://www.adobe.com/pl/products/robohelp.html ClickHelp: https://clickhelp.com/ Adobe FrameMaker: https://www.adobe.com/pl/products/framemaker.html Help+Manual: https://helpandmanual.com/ WordPress: https://pl.wordpress.org/ Drupal: https://www.drupal.org/ "Markdown", Wikipedia: https://en.wikipedia.org/wiki/Markdown Schematron: https://www.schematron.com/ Swagger UI: https://swagger.io/tools/swagger-ui/ Redoc: https://github.com/Redocly/redoc "Zintegrowane środowisko programistyczne (IDE)", Wikipedia: https://pl.wikipedia.org/wiki/Zintegrowane_%C5%9Brodowisko_programistyczne IntelliJ IDEA: https://www.jetbrains.com/idea/ Wtyczka Writerside: https://plugins.jetbrains.com/plugin/20158-writerside "XML schema", Wikipedia: https://en.wikipedia.org/wiki/XML_schema "Darwin Information Typing Architecture (DITA)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture "DocBook", Wikipedia: https://en.wikipedia.org/wiki/DocBook Lightweight DITA: http://docs.oasis-open.org/dita/LwDITA/v1.0/cnprd01/LwDITA-v1.0-cnprd01.html "What is vendor lock-in?", TechTarget: https://www.techtarget.com/searchdatacenter/definition/vendor-lock-in

Wyniki ankiety JetBrains, "The State of Developer Ecosystem 2023", jakie są, każdy widzi. Mało kto używa dity, wszyscy kodują. Ale skąd takie właśnie wyniki i jaką grupę one odzwierciedlają? Czy Tech Writerzy używają narzędzi enterprise? Czy testują dokumentację? Czy wyłania się nam persona Tech Writera, który koduje? Patrzymy na wyniki ankiety krytycznym okiem, badamy czy mogą one sugerować trendy przyszłości i staramy się ocenić kontekst.

Jako bonus bierzemy na warsztat Writerside - narzędzie JetBrains do tworzenia dokumentacji. Omawiamy jego funkcjonalności i fundamentalną zasadę działania. Czy jest to remake MadCap Flare'a? Posłuchaj naszej rozmowy, a dowiesz się co o nim sądzimy.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "The State of Developer Ecosystem 2023", JetBrains: https://www.jetbrains.com/lp/devecosystem-2023/
  • Writerside: https://www.jetbrains.com/writerside/
  • "Docs as code", Write the Docs: ⁠https://www.writethedocs.org/guide/docs-as-code/
  • Chris Chinchilla: https://chrischinchilla.com/
  • MadCap Flare: https://www.madcapsoftware.com/products/flare/
  • Adobe RoboHelp: https://www.adobe.com/pl/products/robohelp.html
  • ClickHelp: https://clickhelp.com/
  • Adobe FrameMaker: https://www.adobe.com/pl/products/framemaker.html
  • Help+Manual: https://helpandmanual.com/
  • WordPress: https://pl.wordpress.org/
  • Drupal: https://www.drupal.org/
  • "Markdown", Wikipedia: https://en.wikipedia.org/wiki/Markdown
  • Schematron: https://www.schematron.com/
  • Swagger UI: https://swagger.io/tools/swagger-ui/
  • Redoc: https://github.com/Redocly/redoc
  • "Zintegrowane środowisko programistyczne (IDE)", Wikipedia: https://pl.wikipedia.org/wiki/Zintegrowane_%C5%9Brodowisko_programistyczne
  • IntelliJ IDEA: https://www.jetbrains.com/idea/
  • Wtyczka Writerside: https://plugins.jetbrains.com/plugin/20158-writerside
  • "XML schema", Wikipedia: https://en.wikipedia.org/wiki/XML_schema
  • "Darwin Information Typing Architecture (DITA)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
  • "DocBook", Wikipedia: https://en.wikipedia.org/wiki/DocBook
  • Lightweight DITA: http://docs.oasis-open.org/dita/LwDITA/v1.0/cnprd01/LwDITA-v1.0-cnprd01.html
  • "What is vendor lock-in?", TechTarget: https://www.techtarget.com/searchdatacenter/definition/vendor-lock-in

#61 Tech Writer zaczyna wdrażać semantic search, czyli kilka praktycznych wskazówek na początek
2023-12-22 20:24:46

Po długich miesiącach gadania, przyszedł czas na działanie - wreszcie rozpoczęliśmy wdrażanie semantic searcha! Przejście od teorii do praktyki było dość trudne, dlatego mamy dla Was garść informacji, które ułatwią Wam wejście w temat. Rozmawiamy o tym czym jest semantic search, jakie nam daje korzyści w porównaniu do tradycyjnego wyszukiwania, co musimy mieć, żeby go wdrożyć, jak połączyć ze sobą poszczególne elementy całej układanki i jak takie rozwiązanie zaimplementować. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "What is semantic search?", Elastic: https://www.elastic.co/what-is/semantic-search "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model "What Is Retrieval-Augmented Generation, aka RAG?", NVIDIA Blogs: https://blogs.nvidia.com/blog/what-is-retrieval-augmented-generation/ "Hybrid Search Explained", Weaviate: https://weaviate.io/blog/hybrid-search-explained "Semantic search", SBERT: https://www.sbert.net/examples/applications/semantic-search/README.html#semantic-search Hugging Face: https://huggingface.co/ PyTorch: https://pytorch.org/ TensorFlow: https://www.tensorflow.org/ Node.js: https://nodejs.org/en Elasticsearch: https://www.elastic.co/elasticsearch Kubernetes: https://kubernetes.io/ "Build Semantic-Search with Elastic search and BERT vector embeddings. ( From scratch )", Abid Saudagar: https://www.youtube.com/watch?v=KSwPR9eig7w Jupyter Notebook: https://jupyter.org/ SentenceTransformers Documentation: https://www.sbert.net/ "k-nearest neighbor (kNN) search", Elastic Docs: https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html Transformers.js, Hugging Face: https://huggingface.co/docs/transformers.js/index "Export to ONNX", Hugging Face docs: https://huggingface.co/docs/transformers/serialization "Symmetric vs. Asymmetric Semantic Search", SBERT: https://www.sbert.net/examples/applications/semantic-search/README.html#symmetric-vs-asymmetric-semantic-search "Tutorial: semantic search with ELSER", Elastic Docs: https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-elser.html "The Beginner’s Guide to Text Embeddings", Deepset: https://www.deepset.ai/blog/the-beginners-guide-to-text-embeddings

Po długich miesiącach gadania, przyszedł czas na działanie - wreszcie rozpoczęliśmy wdrażanie semantic searcha! Przejście od teorii do praktyki było dość trudne, dlatego mamy dla Was garść informacji, które ułatwią Wam wejście w temat.

Rozmawiamy o tym czym jest semantic search, jakie nam daje korzyści w porównaniu do tradycyjnego wyszukiwania, co musimy mieć, żeby go wdrożyć, jak połączyć ze sobą poszczególne elementy całej układanki i jak takie rozwiązanie zaimplementować.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "What is semantic search?", Elastic: https://www.elastic.co/what-is/semantic-search
  • "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model
  • "What Is Retrieval-Augmented Generation, aka RAG?", NVIDIA Blogs: https://blogs.nvidia.com/blog/what-is-retrieval-augmented-generation/
  • "Hybrid Search Explained", Weaviate: https://weaviate.io/blog/hybrid-search-explained
  • "Semantic search", SBERT: https://www.sbert.net/examples/applications/semantic-search/README.html#semantic-search
  • Hugging Face: https://huggingface.co/
  • PyTorch: https://pytorch.org/
  • TensorFlow: https://www.tensorflow.org/
  • Node.js: https://nodejs.org/en
  • Elasticsearch: https://www.elastic.co/elasticsearch
  • Kubernetes: https://kubernetes.io/
  • "Build Semantic-Search with Elastic search and BERT vector embeddings. ( From scratch )", Abid Saudagar: https://www.youtube.com/watch?v=KSwPR9eig7w
  • Jupyter Notebook: https://jupyter.org/
  • SentenceTransformers Documentation: https://www.sbert.net/
  • "k-nearest neighbor (kNN) search", Elastic Docs: https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html
  • Transformers.js, Hugging Face: https://huggingface.co/docs/transformers.js/index
  • "Export to ONNX", Hugging Face docs: https://huggingface.co/docs/transformers/serialization
  • "Symmetric vs. Asymmetric Semantic Search", SBERT: https://www.sbert.net/examples/applications/semantic-search/README.html#symmetric-vs-asymmetric-semantic-search
  • "Tutorial: semantic search with ELSER", Elastic Docs: https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-elser.html
  • "The Beginner’s Guide to Text Embeddings", Deepset: https://www.deepset.ai/blog/the-beginners-guide-to-text-embeddings

#60 Tech Writer chce być ponadczasowy, czyli które umiejętności warto posiadać, żeby nie wypaść z gry
2023-11-24 15:52:53

Każdy zawód w IT zmienia się z biegiem czasu i z rozwojem technologii. Bardzo podobnie jest z technical writingiem. Dawniej pisało się na maszynie, potem na komputerze, a ostatnio pisze się próbki kodu i przykłady zawołań do API. Ale czy jest w zawodzie Tech Writera coś, co się nie zmienia? Czy istnieje zestaw umiejętności, który mimo ewolucji branży pozostaje mniej więcej taki sam? Rozmawiamy z Tomkiem Prusem na temat najważniejszych cech i umiejętności dobrego Tech Writera.  Tomek działa w branży od lat i jest managerem doświadczonym w rekrutowaniu Tech Writerów, oraz ogólnie w budowaniu i prowadzeniu zespołów tech writerskich. Poza tym, działa prężnie w ramach MeetContent Wrocław oraz w redakcji techwriter.pl. Jego doświadczenie jest wzbogacone naturalnymi predyspozycjami do motywowania ludzi oraz dużą kreatywnością. W czasie rozmowy z Tomkiem dotykamy różnic między predyspozycjami i umiejętnościami. Rozmawiamy o tym jak wzmacniać swoje mocne strony i na których umiejętnościach się skupić, żeby móc się łatwo odnaleźć w nowej firmie lub w nowej działce technical writingu. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: International Technical Communication Qualifications Foundation (ITCQF): https://itcqf.org/ Studia podyplomowe "Komunikacja techniczna", Akademia Finansów i Biznesu Vistula: https://vistula.edu.pl/kierunki-studiow/komunikacja-techniczna MeetContent: https://meetcontent.org/ Techwriter.pl: https://techwriter.pl Will Robots Take My Job, Technical Writers: https://willrobotstakemyjob.com/technical-writers "Dostępność (projektowanie)", Wikipedia: https://pl.wikipedia.org/wiki/Dost%C4%99pno%C5%9B%C4%87_(projektowanie) "Architektura informacji", Wikipedia: https://pl.wikipedia.org/wiki/Architektura_informacji Information typing: https://docs.oasis-open.org/dita/v1.0/archspec/infotypes.html "Darwin Information Typing Architecture", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture "Użyteczność (informatyka)", Wikipedia: https://pl.wikipedia.org/wiki/U%C5%BCyteczno%C5%9B%C4%87_(informatyka) "Component content management system", Wikipedia: https://en.m.wikipedia.org/wiki/Component_content_management_system Simplified Technical English (STE): https://www.asd-ste100.org/ "Readability", Wikipedia: https://en.wikipedia.org/wiki/Readability "Information architecture", Wikipedia: https://en.wikipedia.org/wiki/Information_architecture "Content strategy", Wikipedia: https://en.wikipedia.org/wiki/Content_strategy "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model "Największy wspólny dzielnik", Wikipedia: https://pl.wikipedia.org/wiki/Najwi%C4%99kszy_wsp%C3%B3lny_dzielnik "Lint, Lint and Away! Linters for the English Language", Chris Ward: https://dzone.com/articles/lint-lint-and-away-linters-for-the-english-languag

Każdy zawód w IT zmienia się z biegiem czasu i z rozwojem technologii. Bardzo podobnie jest z technical writingiem. Dawniej pisało się na maszynie, potem na komputerze, a ostatnio pisze się próbki kodu i przykłady zawołań do API. Ale czy jest w zawodzie Tech Writera coś, co się nie zmienia? Czy istnieje zestaw umiejętności, który mimo ewolucji branży pozostaje mniej więcej taki sam?

Rozmawiamy z Tomkiem Prusem na temat najważniejszych cech i umiejętności dobrego Tech Writera. 

Tomek działa w branży od lat i jest managerem doświadczonym w rekrutowaniu Tech Writerów, oraz ogólnie w budowaniu i prowadzeniu zespołów tech writerskich. Poza tym, działa prężnie w ramach MeetContent Wrocław oraz w redakcji techwriter.pl. Jego doświadczenie jest wzbogacone naturalnymi predyspozycjami do motywowania ludzi oraz dużą kreatywnością.

W czasie rozmowy z Tomkiem dotykamy różnic między predyspozycjami i umiejętnościami. Rozmawiamy o tym jak wzmacniać swoje mocne strony i na których umiejętnościach się skupić, żeby móc się łatwo odnaleźć w nowej firmie lub w nowej działce technical writingu.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • International Technical Communication Qualifications Foundation (ITCQF): https://itcqf.org/
  • Studia podyplomowe "Komunikacja techniczna", Akademia Finansów
    i Biznesu Vistula: https://vistula.edu.pl/kierunki-studiow/komunikacja-techniczna
  • MeetContent: https://meetcontent.org/
  • Techwriter.pl: https://techwriter.pl
  • Will Robots Take My Job, Technical Writers: https://willrobotstakemyjob.com/technical-writers
  • "Dostępność (projektowanie)", Wikipedia: https://pl.wikipedia.org/wiki/Dost%C4%99pno%C5%9B%C4%87_(projektowanie)
  • "Architektura informacji", Wikipedia: https://pl.wikipedia.org/wiki/Architektura_informacji
  • Information typing: https://docs.oasis-open.org/dita/v1.0/archspec/infotypes.html
  • "Darwin Information Typing Architecture", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
  • "Użyteczność (informatyka)", Wikipedia: https://pl.wikipedia.org/wiki/U%C5%BCyteczno%C5%9B%C4%87_(informatyka)
  • "Component content management system", Wikipedia: https://en.m.wikipedia.org/wiki/Component_content_management_system
  • Simplified Technical English (STE): https://www.asd-ste100.org/
  • "Readability", Wikipedia: https://en.wikipedia.org/wiki/Readability
  • "Information architecture", Wikipedia: https://en.wikipedia.org/wiki/Information_architecture
  • "Content strategy", Wikipedia: https://en.wikipedia.org/wiki/Content_strategy
  • "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model
  • "Największy wspólny dzielnik", Wikipedia: https://pl.wikipedia.org/wiki/Najwi%C4%99kszy_wsp%C3%B3lny_dzielnik
  • "Lint, Lint and Away! Linters for the English Language", Chris Ward: https://dzone.com/articles/lint-lint-and-away-linters-for-the-english-languag

#59 Tech Writer wychodzi z mainstreamu, czyli migracja z WordPressa do Docusaurusa i GitHuba
2023-11-05 16:35:04

WordPress to zdecydowanie jeden z największych graczy we współczesnym internecie. Ponad 1/3 stron internetowych jest zbudowana właśnie za pomocą tego narzędzia. Strona techwriter.pl była w tym gronie przez ostatnie 10 lat. W tym roku postanowiliśmy przejść na rozwiązanie oparte na platformie gitowej i generatorze stron statycznych. Rozmawiamy o tym dlaczego zdecydowaliśmy się przejść na Docusaurusa i GitHuba, jak wyglądał proces migracji i czy w ostatecznym rozrachunku była to dobra decyzja, żeby odejść od WordPressa. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: WordPress: https://pl.wordpress.org/ Docusaurus: https://docusaurus.io/ GitHub: https://github.com/ Techwriter.pl: https://techwriter.pl/ "System zarządzania treścią", Wikipeda: https://pl.wikipedia.org/wiki/System_zarz%C4%85dzania_tre%C5%9Bci%C4%85 "Usage statistics and market share of WordPress", W3Techs: https://w3techs.com/technologies/details/cm-wordpress "Docs as code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/ GitHub Pages: https://pages.github.com/ React: https://react.dev/ GitHub Issues: https://github.com/features/issues MDX: https://mdxjs.com/ Disqus: https://disqus.com/ Algolia: https://www.algolia.com/ GitHub Actions: https://github.com/features/actions GitHub Codespaces: https://github.com/features/codespaces MeetContent: http://meetcontent.org/

WordPress to zdecydowanie jeden z największych graczy we współczesnym internecie. Ponad 1/3 stron internetowych jest zbudowana właśnie za pomocą tego narzędzia. Strona techwriter.pl była w tym gronie przez ostatnie 10 lat. W tym roku postanowiliśmy przejść na rozwiązanie oparte na platformie gitowej i generatorze stron statycznych.

Rozmawiamy o tym dlaczego zdecydowaliśmy się przejść na Docusaurusa i GitHuba, jak wyglądał proces migracji i czy w ostatecznym rozrachunku była to dobra decyzja, żeby odejść od WordPressa.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • WordPress: https://pl.wordpress.org/
  • Docusaurus: https://docusaurus.io/
  • GitHub: https://github.com/
  • Techwriter.pl: https://techwriter.pl/
  • "System zarządzania treścią", Wikipeda: https://pl.wikipedia.org/wiki/System_zarz%C4%85dzania_tre%C5%9Bci%C4%85
  • "Usage statistics and market share of WordPress", W3Techs: https://w3techs.com/technologies/details/cm-wordpress
  • "Docs as code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/
  • GitHub Pages: https://pages.github.com/
  • React: https://react.dev/
  • GitHub Issues: https://github.com/features/issues
  • MDX: https://mdxjs.com/
  • Disqus: https://disqus.com/
  • Algolia: https://www.algolia.com/
  • GitHub Actions: https://github.com/features/actions
  • GitHub Codespaces: https://github.com/features/codespaces
  • MeetContent: http://meetcontent.org/

#58 Tech Writer pracuje w zespole rozproszonym - wyzwania i rozwiązania
2023-10-07 19:19:35

Elastyczne godziny pracy, brak obowiązku przychodzenia do biura i praca z dowolnej lokalizacji to w branży IT od jakiegoś czasu już standard. Wielu z nas bardzo sobie chwali takie rozwiązania i skupia się głównie na ich zaletach, ale rzeczywistość nie jest taka różowa. Praca w zespole rozproszonym niesie ze sobą wiele wyzwań, takich jak ograniczone możliwości w zakresie dzielenia się wiedzą i współpracy w czasie rzeczywistym oraz wolniejsze rozwiązywanie problemów. Na szczęście nie wszystko stracone. Można wdrożyć pewne rozwiązania, które sprawią, że wydajność wzrośnie, a poziom frustracji zmaleje. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google", Tech Writer koduje: https://techwriterkoduje.pl/blog/2023/8/1/56 "Why Meetings Suck and How to Fix Them", WorkLife with Adam Grant: https://open.spotify.com/episode/7qVywKBTNnNmuNTKZKwin0?si=43474d5baa734141 Jira: https://www.atlassian.com/software/jira Bitbucket: https://bitbucket.org/ No Hello: https://www.nohello.com/ "Standard DITA (Darwin Information Typing Architecture)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture Markdown: https://daringfireball.net/projects/markdown/syntax Visual Studio (VS) Code: https://code.visualstudio.com/ IntelliJ IDEA: https://www.jetbrains.com/idea/ GitHub: https://github.com/

Elastyczne godziny pracy, brak obowiązku przychodzenia do biura i praca z dowolnej lokalizacji to w branży IT od jakiegoś czasu już standard. Wielu z nas bardzo sobie chwali takie rozwiązania i skupia się głównie na ich zaletach, ale rzeczywistość nie jest taka różowa.

Praca w zespole rozproszonym niesie ze sobą wiele wyzwań, takich jak ograniczone możliwości w zakresie dzielenia się wiedzą i współpracy w czasie rzeczywistym oraz wolniejsze rozwiązywanie problemów. Na szczęście nie wszystko stracone. Można wdrożyć pewne rozwiązania, które sprawią, że wydajność wzrośnie, a poziom frustracji zmaleje.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google", Tech Writer koduje: https://techwriterkoduje.pl/blog/2023/8/1/56
  • "Why Meetings Suck and How to Fix Them", WorkLife with Adam Grant: https://open.spotify.com/episode/7qVywKBTNnNmuNTKZKwin0?si=43474d5baa734141
  • Jira: https://www.atlassian.com/software/jira
  • Bitbucket: https://bitbucket.org/
  • No Hello: https://www.nohello.com/
  • "Standard DITA (Darwin Information Typing Architecture)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
  • Markdown: https://daringfireball.net/projects/markdown/syntax
  • Visual Studio (VS) Code: https://code.visualstudio.com/
  • IntelliJ IDEA: https://www.jetbrains.com/idea/
  • GitHub: https://github.com/

#57 Tech Writer zostaje Prompt Engineerem, czyli nowa potencjalna ścieżka kariery dla technoskryby
2023-08-28 08:56:42

Prompt Engineer to nowa rola, która pojawiła się w związku z galopującym rozwojem sztucznej inteligencji opartej o large language models (LLM). W dużym skrócie, osoba na tym stanowisku zajmuje się generowaniem zapytań (promptów) dla AI, w taki sposób, żeby były one jak najbardziej optymalne i skuteczne. W pracy Prompt Engineera ważna jest bardzo dobra znajomość języka, wiedza na temat działania algorytmów AI oraz pewien zestaw tzw. kompetencji miękkich. Wydaje się, że ze względu na swoje umiejętności i doświadczenie, Tech Writer jest dobrym kandydatem na to nowe stanowisko. W naszej rozmowie staramy się ustalić czy takie założenie jest uzasadnione i czy zostanie Prompt Engineerem to potencjalna ścieżka kariery dla technoskryby. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "Prompt Engineering", Wikipedia: https://en.wikipedia.org/wiki/Prompt_engineering "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model Oferta pracy "Prompt Engineer & Librarian": https://www.linkedin.com/jobs/view/3696512483/?eBP=JOB_SEARCH_ORGANIC&refId=4oyL2%2F11R2E5IHbEPcBQig%3D%3D&trackingId=lwW9sbSFJQjRTdjpdk86pQ%3D%3D&trk=flagship3_search_srp_jobs "Six skills you need to become an AI prompt engineer", ZDNet: https://www.zdnet.com/article/six-skills-you-need-to-become-an-ai-prompt-engineer/ "The Hot New Job That Pays Six Figures: AI Prompt Engineering", Forbes: https://www.forbes.com/sites/bernardmarr/2023/05/11/the-hot-new-job-that-pays-six-figures-ai-prompt-engineering/?sh=5996f037d7fa Langchain: https://github.com/langchain-ai/langchain "Why You Shouldn't Be Writing A New Prompt Every Time", Lance Cummings: https://www.isophist.com/p/why-you-shouldnt-be-writing-a-new Profil Lance'a Cummingsa na LinkedIn: https://www.linkedin.com/in/lance-cummings-phd/ "Prompt Engineering Guide": https://www.promptingguide.ai/

Prompt Engineer to nowa rola, która pojawiła się w związku z galopującym rozwojem sztucznej inteligencji opartej o large language models (LLM). W dużym skrócie, osoba na tym stanowisku zajmuje się generowaniem zapytań (promptów) dla AI, w taki sposób, żeby były one jak najbardziej optymalne i skuteczne. W pracy Prompt Engineera ważna jest bardzo dobra znajomość języka, wiedza na temat działania algorytmów AI oraz pewien zestaw tzw. kompetencji miękkich.

Wydaje się, że ze względu na swoje umiejętności i doświadczenie, Tech Writer jest dobrym kandydatem na to nowe stanowisko. W naszej rozmowie staramy się ustalić czy takie założenie jest uzasadnione i czy zostanie Prompt Engineerem to potencjalna ścieżka kariery dla technoskryby.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "Prompt Engineering", Wikipedia: https://en.wikipedia.org/wiki/Prompt_engineering
  • "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model
  • Oferta pracy "Prompt Engineer & Librarian": https://www.linkedin.com/jobs/view/3696512483/?eBP=JOB_SEARCH_ORGANIC&refId=4oyL2%2F11R2E5IHbEPcBQig%3D%3D&trackingId=lwW9sbSFJQjRTdjpdk86pQ%3D%3D&trk=flagship3_search_srp_jobs
  • "Six skills you need to become an AI prompt engineer", ZDNet: https://www.zdnet.com/article/six-skills-you-need-to-become-an-ai-prompt-engineer/
  • "The Hot New Job That Pays Six Figures: AI Prompt Engineering", Forbes: https://www.forbes.com/sites/bernardmarr/2023/05/11/the-hot-new-job-that-pays-six-figures-ai-prompt-engineering/?sh=5996f037d7fa
  • Langchain: https://github.com/langchain-ai/langchain
  • "Why You Shouldn't Be Writing A New Prompt Every Time", Lance Cummings: https://www.isophist.com/p/why-you-shouldnt-be-writing-a-new
  • Profil Lance'a Cummingsa na LinkedIn: https://www.linkedin.com/in/lance-cummings-phd/
  • "Prompt Engineering Guide": https://www.promptingguide.ai/

#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google
2023-08-01 20:24:18

Inżynieria oprogramowania to coś więcej niż programowanie. To tworzenie kodu z myślą o jego utrzymaniu w kontekście czasu, zasobów i skali. Taka szersza perspektywa wymusza na nas stosowanie pewnych zachowań, procesów i narzędzi. Firma Google stworzyła praktyczny przewodnik opisujący te zagadnienia, który według nas jest wartościową lekturą dla osób pracujących w branży wytwarzania oprogramowania. Rozmawiamy o tym co znajdziecie w książce "Software Engineering at Google", które fragmenty były dla nas najciekawsze i jakie przemyślenia mieliśmy po jej przeczytaniu. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: "Software Engineering at Google", Titus Winters, Tom Manshreck, Hyrum Wright: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ Hyrum's Law: https://www.hyrumslaw.com/ "Bus factor", Wikipedia: https://en.wikipedia.org/wiki/Bus_factor "POIT #203: Kariera pokolenia Z w branży IT", Porozmawiajmy o IT: https://porozmawiajmyoit.pl/poit-203-kariera-pokolenia-z-w-branzy-it/ "Shift-left testing, czyli wczesne testowanie": https://testerzy.pl/baza-wiedzy/shift-left-testing-czyli-wczesne-testowanie "Code review", Wikipedia: https://en.wikipedia.org/wiki/Code_review "Tech Writer koduje w Pythonie. Przewodnik szybkiego startu", Michał Skowron: https://techwriterkoduje.pl/python/teoria "Guard Clause": https://deviq.com/design-patterns/guard-clause

Inżynieria oprogramowania to coś więcej niż programowanie. To tworzenie kodu z myślą o jego utrzymaniu w kontekście czasu, zasobów i skali. Taka szersza perspektywa wymusza na nas stosowanie pewnych zachowań, procesów i narzędzi.

Firma Google stworzyła praktyczny przewodnik opisujący te zagadnienia, który według nas jest wartościową lekturą dla osób pracujących w branży wytwarzania oprogramowania. Rozmawiamy o tym co znajdziecie w książce "Software Engineering at Google", które fragmenty były dla nas najciekawsze i jakie przemyślenia mieliśmy po jej przeczytaniu.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • "Software Engineering at Google", Titus Winters, Tom Manshreck, Hyrum Wright: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/
  • Hyrum's Law: https://www.hyrumslaw.com/
  • "Bus factor", Wikipedia: https://en.wikipedia.org/wiki/Bus_factor
  • "POIT #203: Kariera pokolenia Z w branży IT", Porozmawiajmy o IT: https://porozmawiajmyoit.pl/poit-203-kariera-pokolenia-z-w-branzy-it/
  • "Shift-left testing, czyli wczesne testowanie": https://testerzy.pl/baza-wiedzy/shift-left-testing-czyli-wczesne-testowanie
  • "Code review", Wikipedia: https://en.wikipedia.org/wiki/Code_review
  • "Tech Writer koduje w Pythonie. Przewodnik szybkiego startu", Michał Skowron: https://techwriterkoduje.pl/python/teoria
  • "Guard Clause": https://deviq.com/design-patterns/guard-clause

#55 Tech Writer ocenia dojrzałość dokumentacji, czyli technologiczne marzenia kontra rzeczywistość
2023-06-29 09:21:06

Warto mieć plany i marzenia, szczególnie w kwestii wdrażania usprawnień w swojej pracy. Jako Tech Writerzy często snujemy wizje wykorzystania wspaniałych nowych technologii, które są na topie do przesunięcia naszego procesu tworzenia dokumentacji na wyższy poziom. Często jednak zapominamy o podstawach, bez których takie śmiałe wizje nie mają szansy powodzenia. Zanim zaczniemy rewolucję, powinniśmy przyjrzeć się temu jak się sprawy mają w naszej organizacji. Tutaj przychodzi nam z pomocą model oceny dojrzałości (maturity model), dzięki któremu dowiemy się na jakim etapie rozwoju jest nasza dokumentacja. Dopiero po zrobieniu takiego "rachunku sumienia" będziemy mogli wykonać kolejny krok w postaci planowania usprawnień. Rozmawiamy o przykładowym maturity modelu dla dokumentacji, zastanawiamy się co można zrobić, żeby przejść na wyższe poziomy, subiektywnie oceniamy innych i teoretyzujemy na temat przyszłości. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Informacje dodatkowe: Konferencja soap!: https://soapconf.com/ Etteplan: https://www.etteplan.com/pl "Maturity model", Wikipedia: https://en.wikipedia.org/wiki/Maturity_model "What is ContentOps", Heretto: https://heretto.com/blog/what-is-contentops/ "Content strategy", Wikipedia: https://en.wikipedia.org/wiki/Content_strategy "Generative artificial intelligence", Wikipedia: https://en.wikipedia.org/wiki/Generative_artificial_intelligence "Help authoring tool (HAT)", Wikipedia: https://en.wikipedia.org/wiki/Help_authoring_tool "Darwin Information Typing Architecture (DITA)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture "Component Content Management System (CCMS)", Wikipedia: https://en.m.wikipedia.org/wiki/Component_content_management_system "About pull requests", GitHub : https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests "Docs as Code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/ "Lint (software)", Wikipedia: https://en.wikipedia.org/wiki/Lint_(software) GitHub Copilot: https://github.com/features/copilot "Style guide", Wikipedia: https://en.wikipedia.org/wiki/Style_guide Acrolinx: https://www.acrolinx.com/ Schematron: https://www.schematron.com/ Oxygen XML: https://www.oxygenxml.com/ Visual Studio Code (VS Code): https://code.visualstudio.com/ Jenkins: https://www.jenkins.io/ "Microcontent", Wikipedia: https://en.wikipedia.org/wiki/Microcontent "What is "Intelligent Content"?, Storyblok: https://www.storyblok.com/mp/intelligent-content Docusaurus: https://docusaurus.io/ "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model "The economic potential of generative AI: The next productivity frontier", McKinsey Digital: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier#introduction

Warto mieć plany i marzenia, szczególnie w kwestii wdrażania usprawnień w swojej pracy. Jako Tech Writerzy często snujemy wizje wykorzystania wspaniałych nowych technologii, które są na topie do przesunięcia naszego procesu tworzenia dokumentacji na wyższy poziom. Często jednak zapominamy o podstawach, bez których takie śmiałe wizje nie mają szansy powodzenia.

Zanim zaczniemy rewolucję, powinniśmy przyjrzeć się temu jak się sprawy mają w naszej organizacji. Tutaj przychodzi nam z pomocą model oceny dojrzałości (maturity model), dzięki któremu dowiemy się na jakim etapie rozwoju jest nasza dokumentacja. Dopiero po zrobieniu takiego "rachunku sumienia" będziemy mogli wykonać kolejny krok w postaci planowania usprawnień.

Rozmawiamy o przykładowym maturity modelu dla dokumentacji, zastanawiamy się co można zrobić, żeby przejść na wyższe poziomy, subiektywnie oceniamy innych i teoretyzujemy na temat przyszłości.

Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

Informacje dodatkowe:

  • Konferencja soap!: https://soapconf.com/
  • Etteplan: https://www.etteplan.com/pl
  • "Maturity model", Wikipedia: https://en.wikipedia.org/wiki/Maturity_model
  • "What is ContentOps", Heretto: https://heretto.com/blog/what-is-contentops/
  • "Content strategy", Wikipedia: https://en.wikipedia.org/wiki/Content_strategy
  • "Generative artificial intelligence", Wikipedia: https://en.wikipedia.org/wiki/Generative_artificial_intelligence
  • "Help authoring tool (HAT)", Wikipedia: https://en.wikipedia.org/wiki/Help_authoring_tool
  • "Darwin Information Typing Architecture (DITA)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
  • "Component Content Management System (CCMS)", Wikipedia: https://en.m.wikipedia.org/wiki/Component_content_management_system
  • "About pull requests", GitHub : https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
  • "Docs as Code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/
  • "Lint (software)", Wikipedia: https://en.wikipedia.org/wiki/Lint_(software)
  • GitHub Copilot: https://github.com/features/copilot
  • "Style guide", Wikipedia: https://en.wikipedia.org/wiki/Style_guide
  • Acrolinx: https://www.acrolinx.com/
  • Schematron: https://www.schematron.com/
  • Oxygen XML: https://www.oxygenxml.com/
  • Visual Studio Code (VS Code): https://code.visualstudio.com/
  • Jenkins: https://www.jenkins.io/
  • "Microcontent", Wikipedia: https://en.wikipedia.org/wiki/Microcontent
  • "What is "Intelligent Content"?, Storyblok: https://www.storyblok.com/mp/intelligent-content
  • Docusaurus: https://docusaurus.io/
  • "Large language model (LLM)", Wikipedia: https://en.wikipedia.org/wiki/Large_language_model
  • "The economic potential of generative AI: The next productivity frontier", McKinsey Digital: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier#introduction

Informacja dotycząca prawa autorskich: Wszelka prezentowana tu zawartość podkastu jest własnością jego autora

Wyszukiwanie

Kategorie