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

G>>А как выделить обучение?
G>>Если человеку дали второй раз ту же самую задачу, он ведь быстрее ее выполнит? Значит, в процессе работы чему-то обучился. Отделить одно от другого -хз как. Вопрос субъективный.

E>На самом деле просто отделить одно от другого: как только информации достаточно, чтобы выработать решение — значит обучение закончилось.
E>Получается в первый раз твои работы можно разделить так например: обучение — 1 час, выполнение — 1 час.
E>Второй раз та же самая задача: выполнение — 1 час.
Ну мы же не говорим об академической дисциплине. Типа, сначала на лекции рассказывают как решать дифуры, а потом на практике берешь и решаешь.
Как правило, работа в той области, которую неплохо знаешь устроена по-другому.
въезжаешь в задачу, насилуешь аналитика (если такового нет — сам выступаешь в этой роли), прорабатываешь архитектуру, проводишь некоторые исследовательские работы, согласуешь рамки полученных ограничений, кодишь, периодически тестишь/показываешь/задаешь уточняющие вопросы, эпизодически переделываешь, постоянно-постоянно рефакторишь, в процессе кодинга натыкаешься на то, что где-то что-то забыл или не знал. Начиная с синтаксиса и конкретными решениями конкретныъ проблем и заканчивая best practices

Например, не помню и не хочу помнить я команду merge для сиквела (я на нем только 10% вермени работаю, могу позволить себе не знать всего). Полез, посмотрел. Потом писал. Не заработало. Исправлял. Что из этого обучение? время гугления? время исправления?
Напрмер, че-та не пишутся логи. Полез смотреть, как конфигурируется логгер. Смотреть примеры. Стырил нужный конфиг и допилил напильником. Что есть обучение? Время гугления? время пиления напильником?
И ведь это все итеративно.
Ладно, это простые примеры. Вот, скажем, сервис, который тебе достался в наследство, периодически подвисает. И ты его и так и этак крутишь, чтобы изучить и понять что там происходит. Это что, врея ковыряния в говнокоде — обучение?
Гробишь пару дней, выясняешь, что повисает отправитель в topic через SonicMQ. Лезешь изучать, как там топики устроены. Ставишь эксперименты. Общаешься с поддержкой. Еше неделя уходит. Потом выясняешь проблему, плюешься на архитектуру SonicMQ и переводишь durable topic на несколько очередей. Потому что топики — это зло. Переводишь быстро, написав и протестив все за полдня.

Как отделить, где я тут разрабатывал, а где — учил?





G>>Поэтому вердикт: Лепите отчеты, какие хотите, чтобы навешать заказчику любую лапшу, которая будет вам выгодна.
G>>Если же вы заказчик — то будьте готовы, что отчеты будут содержать лапшу.

E>Непонятно, зачем лепить лапшу.
E>Почему нельзя в отчет написать то, что отражает реальность?

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

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

G>>А как выделить обучение?
G>>Если человеку дали второй раз ту же самую задачу, он ведь быстрее ее выполнит? Значит, в процессе работы чему-то обучился. Отделить одно от другого -хз как. Вопрос субъективный.

E>На самом деле просто отделить одно от другого: как только информации достаточно, чтобы выработать решение — значит обучение закончилось.
E>Получается в первый раз твои работы можно разделить так например: обучение — 1 час, выполнение — 1 час.
E>Второй раз та же самая задача: выполнение — 1 час.
Ну мы же не говорим об академической дисциплине. Типа, сначала на лекции рассказывают как решать дифуры, а потом на практике берешь и решаешь.
Как правило, работа в той области, которую неплохо знаешь устроена по-другому.
въезжаешь в задачу, насилуешь аналитика (если такового нет — сам выступаешь в этой роли), прорабатываешь архитектуру, проводишь некоторые исследовательские работы, согласуешь рамки полученных ограничений, кодишь, периодически тестишь/показываешь/задаешь уточняющие вопросы, эпизодически переделываешь, постоянно-постоянно рефакторишь, в процессе кодинга натыкаешься на то, что где-то что-то забыл или не знал. Начиная с синтаксиса и конкретными решениями конкретныъ проблем и заканчивая best practices

Например, не помню и не хочу помнить я команду merge для сиквела (я на нем только 10% вермени работаю, могу позволить себе не знать всего). Полез, посмотрел. Потом писал. Не заработало. Исправлял. Что из этого обучение? время гугления? время исправления?
Напрмер, че-та не пишутся логи. Полез смотреть, как конфигурируется логгер. Смотреть примеры. Стырил нужный конфиг и допилил напильником. Что есть обучение? Время гугления? время пиления напильником?
И ведь это все итеративно.
Ладно, это простые примеры. Вот, скажем, сервис, который тебе достался в наследство, периодически подвисает. И ты его и так и этак крутишь, чтобы изучить и понять что там происходит. Это что, врея ковыряния в говнокоде — обучение?
Гробишь пару дней, выясняешь, что повисает отправитель в topic через SonicMQ. Лезешь изучать, как там топики устроены. Ставишь эксперименты. Общаешься с поддержкой. Еше неделя уходит. Потом выясняешь проблему, плюешься на архитектуру SonicMQ и переводишь durable topic на несколько очередей. Потому что топики — это зло. Переводишь быстро, написав и протестив все за полдня.

Как отделить, где я тут разрабатывал, а где — учил?