Tech Writer koduje

Próbki kodu to kluczowy element dokumentacji, a w szczególności dokumentacji dla deweloperów. Dlatego uważamy, że "foo", "bar" i "baz" muszą odejść.

Jako kodujący Tech Writerzy spotykamy się zarówno z dobrymi jak i kiepskimi przykładami, dlatego postanowiliśmy podsumować naszą wiedzę i doświadczenia w tym zakresie i zastanowić się jak tworzyć próbki, które są pomocne i łatwe do zrozumienia.

Rozmawiamy o dobrych i złych praktykach, o potencjalnych problemach i rozwiązaniach oraz, oczywiście, o narzędziach, które możemy wykorzystać, żeby nasze próbki były jeszcze lepsze.

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:

• "Never Use Foo, Bar, Baz, etc. in Software Documentation", Tech Your Chance: https://www.techyourchance.com/never-use-foo-bar-baz/
• "Online resources to learn how to code", StackOverflow Developer Survey 2022: https://survey.stackoverflow.co/2022/#section-learning-to-code-online-resources-to-learn-how-to-code
• "Online resources to learn how to code", StackOverflow Developer Survey 2023: https://survey.stackoverflow.co/2023/#section-learning-to-code-online-resources-to-learn-how-to-code
• "Default behaviour sticks (And so do examples)", Thinkst Thoughts: https://blog.thinkst.com/2023/08/default-behaviour-sticks-and-so-do-examples.html
• "Code blocks", Docusaurus: https://docusaurus.io/docs/markdown-features/code-blocks
• rundoc: https://eclecticiq.github.io/rundoc/
• "Code samples", Google developer documentation style guide: https://developers.google.com/style/code-samples
• "Creating sample code", Google Technical Writing: https://developers.google.com/tech-writing/two/sample-code
• "Guidelines for writing code examples", MDN: https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Writing_style_guide/Code_style_guide
• "Write excellent code examples", The Developer Advocacy Handbook: https://developer-advocacy.com/write-excellent-code-examples
• Dokumentacja React.js: https://react.dev/
• Dokumentacja Yarn: https://yarnpkg.com/
• Dokumentacja react-router: https://reactrouter.com/en/main
• Prism.js: https://prismjs.com/
• Docusaurus: https://docusaurus.io/
• Storybook: https://storybook.js.org/

W tym miesiącu nasz podcast obchodzi 5. urodziny. Przez ten czas nagraliśmy ponad 60 odcinków, w których rozmawialiśmy o wielu rzeczach związanych z techniczną stroną tworzenia dokumentacji, ale nigdy o tym co się dzieje za kotarą, o naszych tajnikach i technikach.

Dlatego z okazji jubileuszu, postanowiliśmy opowiedzieć Wam dlaczego w ogóle zaczęliśmy nagrywać, skąd czerpiemy pomysły, czy pracujemy ze scenariuszem czy raczej jesteśmy mistrzami improwizacji, jakiego sprzętu i oprogramowania używamy, jak działa nasza strona i czy w ogóle ktoś nas słucha.

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:

• "#1 Docs like code - rozważania praktyczne i filozoficzne", Tech Writer koduje: https://techwriterkoduje.pl/blog/2019/5/14/1
• "Polski podkast dla techwriterów!", Techwriter.pl: https://techwriter.pl/polski-podkast-dla-techwriterow/
• Riverside.fm: https://riverside.fm/
• Zencastr: https://zencastr.com/
• Audacity: https://www.audacityteam.org/
• Spotify for Podcasters (dawniej Anchor.fm): https://podcasters.spotify.com/
• "RSS", Wikipedia: https://pl.wikipedia.org/wiki/RSS
• Mikrofon Novox NC-1: https://novox.pl/
• "#51 Tech Writer buduje stronę dla podcastu, czyli praktyczne zastosowanie Next.js", Tech Writer koduje: https://techwriterkoduje.pl/blog/2023/2/26/51
• "MeetContentKRK zaprasza na Content Day", techwriter.pl: https://techwriter.pl/meet-content-krk-content-day/

"Docs as code" to filozofia, która głosi, żeby tworzyć dokumentację za pomocą tych samych narzędzi i procesów co oprogramowanie. W zamian za to otrzymujemy szereg benefitów, takich jak lepsza współpraca z programistami, synchronizacja kodu i dokumentacji, wersjonowanie, automatyczne testy oraz ogólne poczucie, że dokumentacja to wspólna odpowiedzialność.

Czy takie podejście sprawdza się w praktyce? Czy nie są to tylko puste obietnice, których w rzeczywistości nie da się spełnić? W tym odcinku konfrontujemy artykuł "Docs as code is a broken promise" z naszymi własnymi doświadczeniami i przekonaniami. Uwaga, spoiler! Jako żarliwi zwolennicy docs as code, staramy się pokazać, że pomimo wyzwań jakie ze sobą niesie, jest to podejście, które dobrze się sprawdza w świecie dokumentacji do oprogramowania.

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:

• "Docs as code is a broken promise", Sarah Moir: https://thisisimportant.net/posts/docs-as-code-broken-promise/
• "Docs as Code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/
• "Documentation as Code: why you need it and how to get started", Swimm Team: https://swimm.io/learn/code-documentation/documentation-as-code-why-you-need-it-and-how-to-get-started
• Git: https://git-scm.com/
• Subversion (SVN): https://subversion.apache.org/
• Mercurial: https://www.mercurial-scm.org/
• Perforce: https://www.perforce.com/solutions/version-control
• "What version control systems do you regularly use?", JetBrains: https://www.jetbrains.com/lp/devecosystem-2023/team-tools/#tools_vcs
• "Component content management system (CCMS)", Wikipedia: https://en.wikipedia.org/wiki/Component_content_management_system
• GitLab: https://gitlab.com/
• GitHub: https://github.com/
• The Zen of Python: https://peps.python.org/pep-0020/#the-zen-of-python
• MadCap Flare: https://www.madcapsoftware.com/products/flare/
• Markdown: https://daringfireball.net/projects/markdown/
• AsciiDoc: https://asciidoc.org/
• Visual Studio Code (VS Code): https://code.visualstudio.com/
• Kotlin: https://kotlinlang.org/
• IntelliJ IDEA: https://www.jetbrains.com/idea/
• "Emancipation: Why the heck would a tech writer use enterprise tools?", Paweł Kowaluk: https://meetcontent.github.io/events/krakow/2024/20
• Docusuarus: https://docusaurus.io/
• GitLens: https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens

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

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/

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

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

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

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/

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/