Нам всем по работе приходится читать доки: книги, документацию, rfc, и многое другое. Речь идет о доках, связанных с самой работой, а не тех, которые мы читаем для себя, чтобы так сказать расти и развиваться.
Как известно, порой такие вещи довольно объемны, а контент не прост. Все это выливается в то, что на их чтение потребно весьма и весьма приличное время. Например если читать какой-нибудь RFC, то можно сидеть неделю, и каждый рабочий день только и делать что читать. Я думаю, все согласятся с существованием таких доков с такими трудозатратами.

Тут есть два подхода к выделению времени:
— Читаем в рабочее время
— Читаем в нерабочее время

Соответственно, тут имеется борьба интересов.
Если читать в рабочее время, то тимлид или менеджер, посчитав его стоимость, потраченное на какое-то чтение, легко может упасть в обморок. И полагаю, будет противодействовать.

Сотрудник вовсе не обязательно желает тратить свое личное время на такие вещи. Все-таки, у него найдется еще куча других занятий, а тратить каждый день еще по часа 4 на чтение... Хотя, конечно есть индивидуумы, которые любят обложиться после работы всякими книгами и статьями.

Соответственно, такие вопросы
— Какой подход считается нормальным? Предполагается ли, что программист сначала работает свои 8 часов, а потом где-то еще возится со всякими доками. Просто чтобы что-то улучшить, обновить, узнать, и т.п. Или он имеет полное право заняться этими вопросами на работе? Потратить день, три, неделю. Может, больше.
— Как у вас принято на работе?

Здравствуйте, jamesq, Вы писали:

J>Нам всем по работе приходится читать доки: книги, документацию, rfc, и многое другое. Речь идет о доках, связанных с самой работой, а не тех, которые мы читаем для себя, чтобы так сказать расти и развиваться.

J> — Какой подход считается нормальным? Предполагается ли, что программист сначала работает свои 8 часов, а потом где-то еще возится со всякими доками. Просто чтобы что-то улучшить, обновить, узнать, и т.п.

Я вижу в этих двух фразах некоторое противоречие — то "не тех, которые мы читаем для себя, чтобы так сказать расти и развиваться", то "просто чтобы что-то улучшить, обновить, узнать", ну да фиг с ним.

В общем и целом, разумеется, чтение документации это часть рабочего процесса. Доку, насущно необходимую для решения задачи я, конечно же, буду читать и разбирать столько, сколько понадобится. Если "просто что-то узнать" по моей области — тоже буду читать в рабочее время, тратя на это какое-то разумное время, не во вред текущим задачам.

Здравствуйте, jamesq, Вы писали:

J> — Какой подход считается нормальным? Предполагается ли, что программист сначала работает свои 8 часов, а потом где-то еще возится со всякими доками. Просто чтобы что-то улучшить, обновить, узнать, и т.п. Или он имеет полное право заняться этими вопросами на работе? Потратить день, три, неделю. Может, больше.
J> — Как у вас принято на работе?

У нас совершенно официально до 25% времени выделяется на самообучение, это не считая разбиралок с конкретной задачей время на которую вообще не ограничено. Ограничений всего два: программа самообучения утверждается, т.е. если мы занимаемся биржевыми торгами то про теорию аукциона ты читать можешь, а про геймдев изволь читать в свободное время. Второе ограничение, все эти задачи должны закрываться отчетом, статьей, эссе, презентацией, сертификатом и т.п. Нельзя просто взять и сказать "теперь я знаю кунг-фу".

Здравствуйте, jamesq,

J>Как известно, порой такие вещи довольно объемны, а контент не прост. Все это выливается в то, что на их чтение потребно весьма и весьма приличное время.
J>Если читать в рабочее время, то тимлид или менеджер, посчитав его стоимость, потраченное на какое-то чтение, легко может упасть в обморок. И полагаю, будет противодействовать.

Да и фиг с ним, пусть падает в обморок. Дока, насущно необходимая для работы, есть часть работы, и поэтому читается только в рабочее время. (В нерабочее время — у меня и так есть чем заняться. Семья и растущий пацан сильно важнее любых рабочих док.) И да, изучение/чтение всех необходимых доков, а если необходимо, то и разработка исследовательского прототипа приложения, — все включается в план работ. Главное — правильно это назвать в плане и обосновать необходимость. Если менеджер будет "противодействовать" — ему же хуже. (По счастливому стечению обстоятельств, лично у меня в данный момент на редкость адекватные менеджеры.)

Здравствуйте, jamesq, Вы писали:


J>Соответственно, тут имеется борьба интересов.
J>Если читать в рабочее время, то тимлид или менеджер, посчитав его стоимость, потраченное на какое-то чтение, легко может упасть в обморок. И полагаю, будет противодействовать.

Какая то бредь, у нас можно хоть худ. литературу читать, главное, чтобы не в
ущерб основным обязанностям и умеренно. А так чтение технической или профессиональной
литературы вообще не должны вызывать никаких нареканий.

Здравствуйте, Sharov, Вы писали:

S>А так чтение технической или профессиональной
S>литературы вообще не должны вызывать никаких нареканий.

Я вот лично столкнулся на работе, когда на нее устроился. Читал доки к инструментам, используемым в рабочем процессе, чтобы просто сделать таски. Мне давали понять, что я слишком долго копаюсь, им нужен сделанный таск, а доки почитать я могу потом. Хотя я и не знал инструментария, и физически не мог сделать таск. Мне заявляли, что я могу либо почитать "по-диагонали", либо поискать отрывочную информацию в доках или интернете про те или иные вещи, либо вообще использовать метод подражательства — пиши подобно тому, что есть. Все это только для того, чтобы решить текущие задачи с инструментом.
Разумеется, такие подходы у меня вызывали вопрос о том, как я буду уверен в своем коде. Что он делает именно то что нужно, свободен от багов и другого нежелательного поведения, про которое я попросту не знал бы.

Там вообще дело было такое, что доков к проекту раз-два и обчелся, исходный код как водится, без комментариев, и с долгой историей. А коллеги и начальство вовсе не горят желанием что-либо разъяснять. Ответ один — читай доки и код. В то же время, начальство совсем не готово к тому, что сотрудник будет тратить недели и месяцы на изучение всех этих вещей.
С другой стороны, там имелись индивидуумы-энтузиасты, читающие после работы тонны книг, статей, кода и других материалов. Видимо, в какой-то момент начальство начало считать, что это является нормой. И на этом начал строится рабочий процесс.

Здравствуйте, Vlad_SP, Вы писали:

V_S>И да, изучение/чтение всех необходимых доков, а если необходимо, то и разработка исследовательского прототипа приложения, — все включается в план работ. Главное — правильно это назвать в плане и обосновать необходимость.

А как реагирует заказчик, если ему в обосновании трат написать: эту неделю вы должны оплатить нашему сотруднику, который просто читал бумажки. И не написал ни строчки кода для вашего проекта. Т.е. с точки зрения заказчика, никакого полезного результата для него нет. Ничего такого, чтобы он мог увидеть. Читал — не читал, кто его знает, верно?

Если говорить на более общем уровне. Чтение бумаг можно рассматривать как вид исследовательских работ по проекту. Они имеют свойство, что могут длиться непредсказуемое время, порой довольно долго, а в качестве их результата можно сделать разве что презентацию или отчет. Порой, с глубоко техническими сведениями, ценность которых для заказчика стремится к нулю. Для некоторых вещей, вроде того же чтения, даже отчета сделать нельзя. Самое неприятное, что исследовательские работы могут привести и к отрицательному результату.

Должен ли заказчик их оплачивать? Нормальная ли это практика, заявлять: мы все еще исследуем вашу проблему, нам понадобится еще пара месяцев. И в то же время, предъявлять счета к оплате. Тут же опять, с точки зрения заказчика одни сплошные риски, а результат эфемерен.

Здравствуйте, jamesq,

J>А как реагирует заказчик, если ему в обосновании трат написать: эту неделю вы должны оплатить нашему сотруднику, который просто читал бумажки. И не написал ни строчки кода для вашего проекта.

Сотрудник не "просто" читал бумажки, а — выполнял необходимую работу по проекту. Вот таск у него такой — в течение недели читать бумажки. Все, баста.

Проект-то как финансируется — fixed price или time & materials? Если FP, то заказчика вообще не должно волновать, что делается во "внутренней кухне" проекта. А если TM — то да, нужно обосновать необходимость этих затрат. А вот это зависит от того, как менеджмент вашей фирмы умеет разговаривать с заказчиком.

Здравствуйте,

и да, еще советские ГОСТы тысяча-девяться-замшелого года предусматривали двухфазную схему организации НИОКР: сначала ставится исследовательская НИР, которая должна дать ответ на вопрос "а возможно ли это вообще сделать? и если возможно, то как?", и по результатам которой рождается только куча бумаги — отчет по НИР; и только потом, по результатам НИР ставится уже ОКР — которая должна на выходе выдать промышленный продукт. Важно, что финансирование и планирование этих работ — раздельное.

Здравствуйте, jamesq, Вы писали:

J>Нам всем по работе приходится читать доки: книги, документацию, rfc, и многое другое. Речь идет о доках, связанных с самой работой, а не тех, которые мы читаем для себя, чтобы так сказать расти и развиваться.
J>Как известно, порой такие вещи довольно объемны, а контент не прост. Все это выливается в то, что на их чтение потребно весьма и весьма приличное время. Например если читать какой-нибудь RFC, то можно сидеть неделю, и каждый рабочий день только и делать что читать. Я думаю, все согласятся с существованием таких доков с такими трудозатратами.

J>Тут есть два подхода к выделению времени:
J> — Читаем в рабочее время
J> — Читаем в нерабочее время

В общем случае — только первый вариант.
Исключения нормальны только по инициативе работника.
Например ему нравится этим заниматься и в нерабочее время.(случай редкий но вполне реальный)
Или например разработчик видит что не тянет а остаться на этой работе очень хочется. Тут второй вариант может быть вполне логичен. Ну и как временное явление конечно.

Ну и еще гораздо чаще удается все это с работой совмещать.
Например для конкретной задачи очень часто не надо учить весь RFC. Нашел нужное место. Разобрался. Задачу закрыл.
В таком случае все довольны будут и без обмороков обойдется.
А конечно если заявить "Пока весь RFC не осилю — про статус задач и не спрашивайте" то хорошим дело не закончится.

Конечно бывают и случаи, когда не все так просто.
Но тогда создается research задача с результатом в виде доклада, презентации, демо прототипа (как уже тут упоминали) и все в порядке с отчетом за потраченное время.

Здравствуйте, jamesq, Вы писали:

J> — Как у вас принято на работе?

Читаем на работе в открытую. Фирма покупает книги или компенсирует покупку.
Посылает на курсы в рабочее время и естественно оплачивает это.

Естественно, что если релиз и со временем туго, то никто не читает.

Здравствуйте, Аноним, Вы писали:

А>Читаем на работе в открытую. Фирма покупает книги или компенсирует покупку.
А>Посылает на курсы в рабочее время и естественно оплачивает это.

Эх, губасто живете...

Здравствуйте, jamesq, Вы писали:

J>Нам всем по работе приходится читать доки: книги, документацию, rfc, и многое другое. Речь идет о доках, связанных с самой работой, а не тех, которые мы читаем для себя, чтобы так сказать расти и развиваться.
J>Как известно, порой такие вещи довольно объемны, а контент не прост. Все это выливается в то, что на их чтение потребно весьма и весьма приличное время. Например если читать какой-нибудь RFC, то можно сидеть неделю, и каждый рабочий день только и делать что читать. Я думаю, все согласятся с существованием таких доков с такими трудозатратами.

Недавно меня на работе попросили уделить 3 недели тестированию копмилятора TypeScript. Я потратил 2 недели исключительно на тщательное изучение спецификаций TypeScript и Ecma-262. Оставшуюся неделю я открываю примерно по десятку багов в день. И все понимают, что для меня это — самый эффективный подход к работе.

J>Тут есть два подхода к выделению времени:
J> — Читаем в рабочее время
J> — Читаем в нерабочее время
J> — Какой подход считается нормальным?

Разработка программ во многих случаях является творческой работой. И здесь трудно чётко разделить рабочее и нерабочее время. Какие-то важные идеи могут приходить в голову по дороге домой, в ванной, перед сном и т.д. У кого-то есть вдохновение писать код поздно ночью или на выходных. Бывает сильное утомление посреди рабочего дня, когда и для тебя, и для проекта было бы полезно, если бы ты пошёл и вздремнул часок.

Кто-то спросит: как же быть уверенным, что разрабочик не халтурит и не пинает балду? что он отрабатыват свою зарплату? Мой взгляд — эти вопросы решает рынок. Нормально — это когда разрабочик приносит пользу проекту, а его работа приносит пользу его профессиональной квалификации.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Читаем на работе в открытую. Фирма покупает книги или компенсирует покупку.
А>>Посылает на курсы в рабочее время и естественно оплачивает это.

S>Эх, губасто живете...

Нормально. Это нормальные инвестиции, которые сторицой окупаются.
А как иначе, если фирма живет с разработок?

Здравствуйте, Аноним, Вы писали:

А>Нормально. Это нормальные инвестиции, которые сторицой окупаются.
А>А как иначе, если фирма живет с разработок?

Ну да. Просто у меня фирма живет за счет продажи железа, т.е.
софт сильно второстепенен со всеми вытекающими..

22.08.2013 14:02, jamesq пишет:

> С другой стороны, там имелись индивидуумы-энтузиасты, читающие после
> работы тонны книг, статей, кода и других материалов. Видимо, в какой-то
> момент начальство начало считать, что это является нормой. И на этом
> начал строится рабочий процесс.
Вот видишь. Из сказанного тобой и вытекает, что это ты — ленивый и не
хотел работать. Другие же работали и довольны были.

Здравствуйте, Vlad_SP, Вы писали:

V_S>и да, еще советские ГОСТы тысяча-девяться-замшелого года предусматривали двухфазную схему организации НИОКР: сначала ставится исследовательская НИР, которая должна дать ответ на вопрос "а возможно ли это вообще сделать? и если возможно, то как?", и по результатам которой рождается только куча бумаги — отчет по НИР; и только потом, по результатам НИР ставится уже ОКР — которая должна на выходе выдать промышленный продукт. Важно, что финансирование и планирование этих работ — раздельное.

Что вы что ТС смешиваете в кучу два разных процесса. 30%(или сколько там?) времени сидеть и читать потому что это ну совершенно необходимо, и без этого никуда — всё таки редкость и скорее всего означает, что поставили не того человека. Ваш пример не совсем по теме: во время НИР всё-таки не сидится и не читается что-то околотемное просто для самообразования, "чтобы так сказать расти и развиваться" а проводится вполне конкретный анализ.
И это мы еше оставляем за скобками вопрос а в каком проценте случаев для среднестатистического программиста этот НИР вообще нужен.

23.08.2013 11:33, Yoriсk пишет:

> Что вы что ТС смешиваете в кучу два разных процесса. 30%(или сколько
> там?) времени сидеть и читать потому что это ну совершенно необходимо, и
> без этого никуда — всё таки редкость и скорее всего означает, что
> поставили не того человека.
Вообще-то ТС именно о доках по непосредственной работе говорит, а не
художественной литературе для повышения кругозора.
А вот нечитание доков приводит к такому говнокоду, что хочется убить
того писателя, что оный код писал, не читая доку. Но, зато он написал
быстро и фиг с ним, что через 2 месяца эту писанину дешевле выкинуть,
чем исправить, зато толпы програмеров при деле.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Нормально. Это нормальные инвестиции, которые сторицой окупаются.
А>>А как иначе, если фирма живет с разработок?

S>Ну да. Просто у меня фирма живет за счет продажи железа, т.е.
S>софт сильно второстепенен со всеми вытекающими..

Ну мы формально тоже продаем железо.
Только одно без другого (железо, софт) смысла особого не имеет.
Или у вас железячники "губасто" живут?

22.08.2013 20:19, Аноним 820 пишет:

> А как иначе, если фирма живет с разработок?
Элементарно. Просто у вас начальство верит в то, что эти вложения
окупаются, в других не верят и не тратятся. А живут и те и другие вполне
успешно.