Странно, что техническим писателям так мало платят. Научится программировать не так уж и сложно (для выбранного языка есть четкие правила, инструкции, применения, а, и курсы еще, куда же без них) забыл какой-то момент - можешь заново открыть мануалы. А вот для описания всех технических тонкостей, причин и пр. нужно много опыта, понимание всех составляющих и взаимосвязей проекта и главное умение излагать правильно мысли на бумаге. Сюда же понимание того, кто будет читать документацию, и какие вопросы нужно закрыть и в какой последовательности (например программисту не нужны маркетинговые втирания про супер-киллер-фичу-2000 для микросхемы памяти, а нужны четкие регистры, тайминги и всякие осциллограммы).
Мы все сталкивались с даташитами. Есть такие, что мол прям все кейсы закрыты, все структурировано и однозначно дефинировано. Работать с такой документацией очень приятно. А есть документация написанная олигоф***ми, где чтобы понять суть написанного нужно 10 раз перечитывать, листать в разные участки, делать вычисления зависящие от текста на 20й и 73й страницах, и в конце итак останется очень много дыр в понимании. Такой подход к политике подготовки документации очень сильно отталкивает. По своему примеру мне проще взять понятный даташит на устройство (пусть чуточку дороже) и потратить на разработку драйвера 1 день, чем взять студенческий выс*р и потратить 2 недели пытаясь понять как и что работает путем изучения лабиринта хода мыслей аффтара документа потому-что Мега Директор решил секономить на Technical writer. Сэкономил ли?
У себя в городе хорошего технического писателя так и не нашли. Есть хорошие программисты которые пишут письма такие, что хочется делать с ними плохие вещи, или хорошие писаки, но в технические особенности проекта углубляться не могут.
Основная его цель в определении интересов соискателя, чтобы сопоставить их с текущей вакансией.
А в описании самой вакансии об этом написать нельзя?
Впрочем, если человек не способен конгруэнтно реагировать на простые вопросы, то зачем с ним работать?;)
Простые вопросы Вы путаете с глупыми, шаблонными. Причем собеседуемый о них знает, Вы о них знаете. Пустая трата времени. А раскрыть настоящий потанцивал работника могут только модели настоящих ситуаций на работе. Через месяц, когда пройдет стеснительность, все "особенности" сотрудника итак вылезут наружу. Для этого придумали испытательный срок.
Вы знаете, да. Всегда можно найти готовое решение. Но, как Вы думаете, жена инженера будет им гордится если он вместо рисования схемы, разводки и пайки пойдет простым путем?
Если консолидировать источник выработки киловатт*часов (многими предлагаемый как единицу новой валюты) в один генератор, то получится, что курс этой валюты будет зависеть от величины оборотов вала этого генератора. А там и поклонение генератору и прочий стиимпанк. Нравится.
Сетевое программирование - это целая область, со своими "механиками". Новичкам может показаться, что мол "я сейчас возьму либы и примеры и начну слать байты по сети, а обо всем остальном позаботятся высокоуровневые интерфейсы, OSI и т.д.". Но суровая действительность такова, что Pipe - это не просто абстрактное название. Это почти буквально труба(трубопровод) и никто не знает, что там с этим трубопроводом происходит на пути TCP/UDB пакета. Он может оборваться и ни клиент ни сервер об этом не узнают "автоматически". Поэтому иногда к сетевому программированию (особенно для подвижных средств связи с изменяемой пропускной способностью канала) я подхожу как к программированию UART/RS232/485.
В начале статьи не хватает "Новички, пишите статьи в гугл докс" иначе при малейшем чихе Вашу статью удалит новый, улучшенный убер редактор Хабра. Я 2 дня жизни/работы потерял когда писал статью про практику программирования SIM7600 и SIM800 с помощью SDK.
Можно вместо акб припаять DC-DC преобразователь. Понадежнее будет. Думаю такой проект нужно делать через получение root и прошивки устройства каким-то кастомом. Потом с внутренностей кастома выбросить графическую оболочку и получить SBC без всяких приложений с плеймаркета.
Нужно не ставить сроков, а выработать в программистах понимание, что для того или инного програмного модуля нужно потратить минимум времени. Тогда программист сам будет понимать, что заниматься 3 месяца UART портами не приемлемо и сделает четко то что от него требуют не уходя в самосовершенстование кода.
Дико плюсую! У нас небольшой стартап где из HW/SW разработчиков — я и двое чуваков на аутсорсе. Работаем на европейском рынке, по их стандартам и участвуем в программах. А это значит, что по мимо стандартной документации сопровождающей разработку нужно еще писать тонны технических описаний под разными углами и смысловыми оттенками. А там нету четких требований к содержанию документов, в основном все аморфно расписано, что мол нужно все написать так, чтобы у комиссии читающей этот документ сложилось впечатление, что все заявленные цели достигнуты, а технические решения реализованы… и бла бла бла…
И в итоге ты месяц работаешь в «потоке» когда изобретаешь новые подходы к решению технических проблем отрасли, составляешь мат. модели процессоров разомкнутых систем с 2х-3х производительностью с работой по ночам и с перерывами на сон и самое главное — тебе это нравится ибо ты делаешь то, от чего тебя прет и это дает результат!, а потом начинается… Тут надо документик сделать для тех вот чуваков, и потом еще один надо составить… Ну, а кто это может сделать кроме тебя? Ты ж все разрабатываешь и ты в курсе всех нюансов (аутсосреров хер заставишь родить бумажку. Хоть какую), да и больше некому. И документ должен с одной стороны быть понятен очень гуманитарию и очень техническому специалисту с другой стороны.
В итоге ты в течении 2 дней выходишь с потока (пытаешься вспомнить какой сейчас год, кто все эти люди и вообще какая сейчас валюта в обиходе)… Начинаешь составлять какие-то документы по системам которые разрабатывались 2-3 года назад с непрозрачными требованиями по наполнению содержания документов и эффективность предсказуемо падает в 3-4 раза!.. И это все еще нужно вести в project/task management ПО. А потом снова за код/алгоритмизацию/исследования ибо R&D!
Но, когда ты спрашиваешь чтобы нанять в команду Project Managerа!!!1/ Product Ownerа или хотя бы тян, чтобы скрасить серые трудовыебудни — ну, а что они будут делать? Вы сами не можете свои задачи спланировать что-ли?
Много копий было сломано в дискуссиях с руководством о работе программиста… но все сводится к «Ты сначала напиши себе ТЗ, а потом его исполняй, но перед исполнением запланируй разработку всего проекта и тасков, а еще время от времени мы тебя будем дергать на писанину документов не важно чем ты сейчас занимаешся»! Тыжпрограммист, а значит — универсальный солдат :)
Хухх, выговорился. Полегчало. Пойду дальше составлять technical file:)
Ого, не ожидал. Думал, заблокировал все порты и приложения через фаервол и в +- безопасности.
Оси на графиках нужно подписывать.
Странно, что техническим писателям так мало платят. Научится программировать не так уж и сложно (для выбранного языка есть четкие правила, инструкции, применения, а, и курсы еще, куда же без них) забыл какой-то момент - можешь заново открыть мануалы. А вот для описания всех технических тонкостей, причин и пр. нужно много опыта, понимание всех составляющих и взаимосвязей проекта и главное умение излагать правильно мысли на бумаге. Сюда же понимание того, кто будет читать документацию, и какие вопросы нужно закрыть и в какой последовательности (например программисту не нужны маркетинговые втирания про супер-киллер-фичу-2000 для микросхемы памяти, а нужны четкие регистры, тайминги и всякие осциллограммы).
Мы все сталкивались с даташитами. Есть такие, что мол прям все кейсы закрыты, все структурировано и однозначно дефинировано. Работать с такой документацией очень приятно. А есть документация написанная олигоф***ми, где чтобы понять суть написанного нужно 10 раз перечитывать, листать в разные участки, делать вычисления зависящие от текста на 20й и 73й страницах, и в конце итак останется очень много дыр в понимании. Такой подход к политике подготовки документации очень сильно отталкивает. По своему примеру мне проще взять понятный даташит на устройство (пусть чуточку дороже) и потратить на разработку драйвера 1 день, чем взять студенческий выс*р и потратить 2 недели пытаясь понять как и что работает путем изучения лабиринта хода мыслей аффтара документа потому-что Мега Директор решил секономить на Technical writer. Сэкономил ли?
У себя в городе хорошего технического писателя так и не нашли. Есть хорошие программисты которые пишут письма такие, что хочется делать с ними плохие вещи, или хорошие писаки, но в технические особенности проекта углубляться не могут.
А в описании самой вакансии об этом написать нельзя?
Простые вопросы Вы путаете с глупыми, шаблонными. Причем собеседуемый о них знает, Вы о них знаете. Пустая трата времени. А раскрыть настоящий потанцивал работника могут только модели настоящих ситуаций на работе. Через месяц, когда пройдет стеснительность, все "особенности" сотрудника итак вылезут наружу. Для этого придумали испытательный срок.
Вижу Matlab - ставлю лайк.
Вы знаете, да. Всегда можно найти готовое решение. Но, как Вы думаете, жена инженера будет им гордится если он вместо рисования схемы, разводки и пайки пойдет простым путем?
Дорого потому что. Дешевле передавать TCP пакеты классическим способом. Голубями например. Все равно целостность пакета при этом гарантируется.
Если консолидировать источник выработки киловатт*часов (многими предлагаемый как единицу новой валюты) в один генератор, то получится, что курс этой валюты будет зависеть от величины оборотов вала этого генератора. А там и поклонение генератору и прочий стиимпанк. Нравится.
в аспирантуру все равно пошла почти половина нашей группы
У Вас там проходной двор что ли? Или пол группы - одаренные гении с жаждой исследований?
Хочешь быть ученым - начинаешь карьеру с аспирантуры, не хочешь - добро пожаловать в реальный безумный мир.
Сетевое программирование - это целая область, со своими "механиками". Новичкам может показаться, что мол "я сейчас возьму либы и примеры и начну слать байты по сети, а обо всем остальном позаботятся высокоуровневые интерфейсы, OSI и т.д.". Но суровая действительность такова, что Pipe - это не просто абстрактное название. Это почти буквально труба(трубопровод) и никто не знает, что там с этим трубопроводом происходит на пути TCP/UDB пакета. Он может оборваться и ни клиент ни сервер об этом не узнают "автоматически". Поэтому иногда к сетевому программированию (особенно для подвижных средств связи с изменяемой пропускной способностью канала) я подхожу как к программированию UART/RS232/485.
6/8 и я не прочитал ни одной книги по C++ программированию. Самоучка :)
В начале статьи не хватает "Новички, пишите статьи в гугл докс" иначе при малейшем чихе Вашу статью удалит новый, улучшенный убер редактор Хабра. Я 2 дня жизни/работы потерял когда писал статью про практику программирования SIM7600 и SIM800 с помощью SDK.
Можно вместо акб припаять DC-DC преобразователь. Понадежнее будет.
Думаю такой проект нужно делать через получение root и прошивки устройства каким-то кастомом. Потом с внутренностей кастома выбросить графическую оболочку и получить SBC без всяких приложений с плеймаркета.
И в итоге ты месяц работаешь в «потоке» когда изобретаешь новые подходы к решению технических проблем отрасли, составляешь мат. модели процессоров разомкнутых систем с 2х-3х производительностью с работой по ночам и с перерывами на сон и самое главное — тебе это нравится ибо ты делаешь то, от чего тебя прет и это дает результат!, а потом начинается… Тут надо документик сделать для тех вот чуваков, и потом еще один надо составить… Ну, а кто это может сделать кроме тебя? Ты ж все разрабатываешь и ты в курсе всех нюансов (аутсосреров хер заставишь родить бумажку. Хоть какую), да и больше некому. И документ должен с одной стороны быть понятен очень гуманитарию и очень техническому специалисту с другой стороны.
В итоге ты в течении 2 дней выходишь с потока (пытаешься вспомнить какой сейчас год, кто все эти люди и вообще какая сейчас валюта в обиходе)… Начинаешь составлять какие-то документы по системам которые разрабатывались 2-3 года назад с непрозрачными требованиями по наполнению содержания документов и эффективность предсказуемо падает в 3-4 раза!.. И это все еще нужно вести в project/task management ПО. А потом снова за код/алгоритмизацию/исследования ибо R&D!
Но, когда ты спрашиваешь чтобы нанять в команду Project Managerа!!!1/ Product Ownerа или хотя бы тян, чтобы скрасить серые трудовыебудни — ну, а что они будут делать? Вы сами не можете свои задачи спланировать что-ли?
Много копий было сломано в дискуссиях с руководством о работе программиста… но все сводится к «Ты сначала напиши себе ТЗ, а потом его исполняй, но перед исполнением запланируй разработку всего проекта и тасков, а еще время от времени мы тебя будем дергать на писанину документов не важно чем ты сейчас занимаешся»! Тыжпрограммист, а значит — универсальный солдат :)
Хухх, выговорился. Полегчало. Пойду дальше составлять technical file:)