Если присмотреться чуть внимательнее (а не только издалека), то в тексте как раз и говорится, что за последние 10 лет зарплаты росли, но последние два года немного стагнируют. Иногда стоит промолчать правда? ;)
О! ГОСТы это вообще отдельная тема, особенно когда стандарты идут вразрез с реальной документацией от китайских производителей.
Что касается профессионального роста, ваш "свет в конце тоннеля" звучит мотивирующе. Главное, чтобы он оказался не встречным поездом из бесконечных требований программирования. 😄 А если серьёзно, умение адаптироваться между такими разными сферами — мощный навык, который точно пригодится в любой карьере.
P.S. Менеджеров продукта пинать — это, похоже, у всех техписов стандартный soft skill. 😁
Ну что ж, комментарий как артхаус — читаешь и ощущаешь сразу весь спектр эмоций. Давайте разберём по частям.
Про "карьерный тупик". Это смотря как смотреть. Если техпис видит себя исключительно как "падальщика", который только и делает, что пишет под диктовку, то да, перспектива так себе. Но современный техпис давно уже не про копирование RFC. Это и UX-исследования, и взаимодействие с продуктовой командой, и настройка CI/CD для документации, и работа с API. Ближе к коду? Да это уже давно рядом, просто под другим углом.
"ИИ всё заменит." Вы знаете, как и переводчики, техписы адаптируются. ИИ умеет генерировать тексты, но он не умеет проверять, работает ли оно, и делать так, чтобы разработчику и юзеру было понятно. А ещё у топ-менеджеров иногда и на ИИ реакция «восторг со слюнями», а потом выясняется, что документацию всё равно нужно — и качественную, а не автогенерацию.
"Зависимость." Да, техпис зависит от команды. Но и команда от техписа зависит, если только не хочет тонуть в макулатуре багрепортов, недоумении новых сотрудников и хаосе с API. Это больше про взаимную выгоду, а не "зависимость".
"Обсуждения с техписом." Тут каждый проецирует своё. С кем-то и поговорить приятно, а кому-то, может, и с собачкой общаться тяжело. Но это скорее про личное восприятие, чем про профессию.
"Советую ближе к коду." Отличный совет! А теперь угадайте, сколько техписов уже этим занимаются: пишут скрипты, автоматизируют, мейнтейнят собственные проекты. Техпис XXI века — это практически междисциплинарный специалист, и если вы думаете иначе, возможно, просто не повезло встретить хорошего.
Ну и, конечно, всегда можно уйти в менеджеры. Главное, чтобы это было не из-за усталости от «эффективных».
Такая ситуация действительно имеет место в некоторых компаниях, и она скорее указывает на организационные проблемы, а не на профессию технического писателя как таковую. Хорошая техническая документация — это не просто перевод стандартов или формальное заполнение требований. Это часть пользовательского опыта, которая помогает разработчикам, тестировщикам, инженерам и даже конечным пользователям работать с продуктом.
Случаи, когда документация оказывается оторванной от реальности, как ваш пример с PKCE, чаще всего говорят о слабом взаимодействии внутри команды. Технический писатель не обязан быть экспертом в программировании, но он должен быть интегрирован в процессы, чтобы понимать продукт и его особенности. Это, в свою очередь, зависит от менеджмента: привлекли ли писателя к обсуждению технических требований, дали ли доступ к тестированию, проверяется ли документ специалистами до публикации?
Если "дыры затыкают" без реальной проверки, проблема в подходе, а не в профессии. С хорошими писателями и грамотной организацией вы бы не заметили разницы между документацией и продуктом — всё бы работало как часы.
Ну и к слову: утверждение, что с техписами "не о чем поговорить", — это тоже стереотип. Многие писатели — это люди с инженерным или ИТ-фоном, они способны обсуждать архитектуру, стандарты и фреймворки. Всё зависит от конкретных специалистов и задач, которые перед ними ставят.
Markdown и Git — действительно мощные инструменты для работы с документами, особенно в технических командах. Однако, к сожалению, они требуют определенных навыков и не всегда подходят для всех пользователей. Не все готовы или могут осваивать Git, особенно если речь идет о нетехнических специалистах. Поэтому важно выбирать платформу, которая подходит под уровень команды: где-то достаточно простоты и интуитивного интерфейса, а где-то нужны мощные инструменты для контроля версий. Для таких случаев гибридные решения или визуальные оболочки для Git могут быть хорошим компромиссом.
Разница действительно впечатляющая.
" I need your clothes, your boots, and your motorcycle." ®
Если присмотреться чуть внимательнее (а не только издалека), то в тексте как раз и говорится, что за последние 10 лет зарплаты росли, но последние два года немного стагнируют. Иногда стоит промолчать правда? ;)
Ценное замечание, спасибо! Добавили кратко в начале
О! ГОСТы это вообще отдельная тема, особенно когда стандарты идут вразрез с реальной документацией от китайских производителей.
Что касается профессионального роста, ваш "свет в конце тоннеля" звучит мотивирующе. Главное, чтобы он оказался не встречным поездом из бесконечных требований программирования. 😄 А если серьёзно, умение адаптироваться между такими разными сферами — мощный навык, который точно пригодится в любой карьере.
P.S. Менеджеров продукта пинать — это, похоже, у всех техписов стандартный soft skill. 😁
Ну что ж, комментарий как артхаус — читаешь и ощущаешь сразу весь спектр эмоций. Давайте разберём по частям.
Про "карьерный тупик". Это смотря как смотреть. Если техпис видит себя исключительно как "падальщика", который только и делает, что пишет под диктовку, то да, перспектива так себе. Но современный техпис давно уже не про копирование RFC. Это и UX-исследования, и взаимодействие с продуктовой командой, и настройка CI/CD для документации, и работа с API. Ближе к коду? Да это уже давно рядом, просто под другим углом.
"ИИ всё заменит." Вы знаете, как и переводчики, техписы адаптируются. ИИ умеет генерировать тексты, но он не умеет проверять, работает ли оно, и делать так, чтобы разработчику и юзеру было понятно. А ещё у топ-менеджеров иногда и на ИИ реакция «восторг со слюнями», а потом выясняется, что документацию всё равно нужно — и качественную, а не автогенерацию.
"Зависимость." Да, техпис зависит от команды. Но и команда от техписа зависит, если только не хочет тонуть в макулатуре багрепортов, недоумении новых сотрудников и хаосе с API. Это больше про взаимную выгоду, а не "зависимость".
"Обсуждения с техписом." Тут каждый проецирует своё. С кем-то и поговорить приятно, а кому-то, может, и с собачкой общаться тяжело. Но это скорее про личное восприятие, чем про профессию.
"Советую ближе к коду." Отличный совет! А теперь угадайте, сколько техписов уже этим занимаются: пишут скрипты, автоматизируют, мейнтейнят собственные проекты. Техпис XXI века — это практически междисциплинарный специалист, и если вы думаете иначе, возможно, просто не повезло встретить хорошего.
Ну и, конечно, всегда можно уйти в менеджеры. Главное, чтобы это было не из-за усталости от «эффективных».
Такая ситуация действительно имеет место в некоторых компаниях, и она скорее указывает на организационные проблемы, а не на профессию технического писателя как таковую. Хорошая техническая документация — это не просто перевод стандартов или формальное заполнение требований. Это часть пользовательского опыта, которая помогает разработчикам, тестировщикам, инженерам и даже конечным пользователям работать с продуктом.
Случаи, когда документация оказывается оторванной от реальности, как ваш пример с PKCE, чаще всего говорят о слабом взаимодействии внутри команды. Технический писатель не обязан быть экспертом в программировании, но он должен быть интегрирован в процессы, чтобы понимать продукт и его особенности. Это, в свою очередь, зависит от менеджмента: привлекли ли писателя к обсуждению технических требований, дали ли доступ к тестированию, проверяется ли документ специалистами до публикации?
Если "дыры затыкают" без реальной проверки, проблема в подходе, а не в профессии. С хорошими писателями и грамотной организацией вы бы не заметили разницы между документацией и продуктом — всё бы работало как часы.
Ну и к слову: утверждение, что с техписами "не о чем поговорить", — это тоже стереотип. Многие писатели — это люди с инженерным или ИТ-фоном, они способны обсуждать архитектуру, стандарты и фреймворки. Всё зависит от конкретных специалистов и задач, которые перед ними ставят.
Markdown и Git — действительно мощные инструменты для работы с документами, особенно в технических командах. Однако, к сожалению, они требуют определенных навыков и не всегда подходят для всех пользователей. Не все готовы или могут осваивать Git, особенно если речь идет о нетехнических специалистах. Поэтому важно выбирать платформу, которая подходит под уровень команды: где-то достаточно простоты и интуитивного интерфейса, а где-то нужны мощные инструменты для контроля версий. Для таких случаев гибридные решения или визуальные оболочки для Git могут быть хорошим компромиссом.