Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Нет никаких точек расцвета. Просто если кто-то долго и упорно вколачивает себе в голову знания, то рано или поздно они упорядочиваются в систему. И человек просыпается утром и обнаруживает, что задачи над которыми еще вчера он бы потел и потом утирался, сегодня решаются на интитивном уровне.
Это именно так работает. Все через это проходят, не все понимают.
Это именно так работает. Все через это проходят, не все понимают.
Переход количества в качество? Ну, ок, так бывает
Знания — это как раз система и есть. без системы — это просто информация.
и очень редко накапливаемая бессистемно информация трансформируется в системные знания.
Именно поэтому пока никакие онлайн-курсы и книги не могут отменить нормального обучения нормальным учителем (наставником, тьютором и т.п.). Ибо если наставник даст системность, то пустые места в системе можно уже заполнить информацией из прочих источников.
а вот «инфоормация из прочих источников» в систему знаний складывается гораздо реже и не у всех.
Хотя без набора знаний (он не обязательно должен быть долгим и упорным — он может заполнять ниши в системе знаний по мере необходимости) не обойтись. А «решение задач на интуитивном уровне» возникает в двух случаях: 1) вспоминается, «как аналогичная задача была решена» (т.е. школьный метод прорешивания десятков задач) 2)понимания взаимосвязей и прорешивания Не очень большого количества взаимосвязанных задач.
и очень редко накапливаемая бессистемно информация трансформируется в системные знания.
Именно поэтому пока никакие онлайн-курсы и книги не могут отменить нормального обучения нормальным учителем (наставником, тьютором и т.п.). Ибо если наставник даст системность, то пустые места в системе можно уже заполнить информацией из прочих источников.
а вот «инфоормация из прочих источников» в систему знаний складывается гораздо реже и не у всех.
Хотя без набора знаний (он не обязательно должен быть долгим и упорным — он может заполнять ниши в системе знаний по мере необходимости) не обойтись. А «решение задач на интуитивном уровне» возникает в двух случаях: 1) вспоминается, «как аналогичная задача была решена» (т.е. школьный метод прорешивания десятков задач) 2)понимания взаимосвязей и прорешивания Не очень большого количества взаимосвязанных задач.
Нет никаких точек расцвета. Просто если кто-то долго и упорно вколачивает себе в голову знания, то рано или поздно они упорядочиваются в систему. И человек просыпается утром и обнаруживает, что задачи над которыми еще вчера он бы потел и потом утирался, сегодня решаются на интитивном уровне.
А чем «просыпается утром и обнаруживает» отличается от точки расцвета автора?
Ну это есть основа манипуляции профилем квалификации рабсилы в команде, как функции от времени. Условно говоря, большая планета должна захватить спутник гравитационным полем, и за счет этого, придать ему ускорение. Тогда будет синергия, и польза для всего проекта.
Если захват сорвется из-за большой разницы исходных скоростей, или неправильной пропорции масс — то разгон не получится, и экономия на стоимости ресурсов приведет к снижению качества и/или срыву сроков (т.к. стажер/джун не втянется, повиснет балластом, будет отвлекать дорогие ресурсы на закрытие дыр имплементации функционала, лишние циклы QA итд).
Если же скорости будт равны или близки — срок и качество скорее всего не выйдут из доверительного диапазона, но заметно сэкономить на ресурсах тоже не получится.
В теории информации есть такое понятие — куб информации — это ширина_полосы * отношение_сигнал_шум * битовая_скорость. Если битовая_скорость — это уже выровненный по энтропии поток — то существенно сэкономить не получится, как этот кубик не клади под пресс одним из боков. Вся экономия возможна только на особенностях передаваемого потока и требованиях к достоверности.
В проектной разработке — практически полная аналогия — стоимость_отгруженного_функционала — это произведение индивидуальных параметров качества и производительности на количество людей в команде. Экономить можно на замене избыточного качества и/или производительности на тех этапах, где это не нужно (линейная разработка, поддержка, в какой-то мере циклы коррекции багов итд) — то есть по сути, строя профиль команды динамически обратным по отношению к профилю требований ресурсов в проекте — а это и есть аналогия к устранению избыточной информации из информационного блока.
Феномен же умелого разгона джунов гравитационным полем наставников выбивается из этой теории, т.к. мотивированный джун привносит в систему свою энергию, по сути обменивая результат своей работы частично на деньги, а частично — на получаемый в ее процессе опыт — в итоге система получает заметно больше количества функционала нужного качества в расчете на затраченный рубль ЗП, чем это было бы без умелого наставничества
Если захват сорвется из-за большой разницы исходных скоростей, или неправильной пропорции масс — то разгон не получится, и экономия на стоимости ресурсов приведет к снижению качества и/или срыву сроков (т.к. стажер/джун не втянется, повиснет балластом, будет отвлекать дорогие ресурсы на закрытие дыр имплементации функционала, лишние циклы QA итд).
Если же скорости будт равны или близки — срок и качество скорее всего не выйдут из доверительного диапазона, но заметно сэкономить на ресурсах тоже не получится.
В теории информации есть такое понятие — куб информации — это ширина_полосы * отношение_сигнал_шум * битовая_скорость. Если битовая_скорость — это уже выровненный по энтропии поток — то существенно сэкономить не получится, как этот кубик не клади под пресс одним из боков. Вся экономия возможна только на особенностях передаваемого потока и требованиях к достоверности.
В проектной разработке — практически полная аналогия — стоимость_отгруженного_функционала — это произведение индивидуальных параметров качества и производительности на количество людей в команде. Экономить можно на замене избыточного качества и/или производительности на тех этапах, где это не нужно (линейная разработка, поддержка, в какой-то мере циклы коррекции багов итд) — то есть по сути, строя профиль команды динамически обратным по отношению к профилю требований ресурсов в проекте — а это и есть аналогия к устранению избыточной информации из информационного блока.
Феномен же умелого разгона джунов гравитационным полем наставников выбивается из этой теории, т.к. мотивированный джун привносит в систему свою энергию, по сути обменивая результат своей работы частично на деньги, а частично — на получаемый в ее процессе опыт — в итоге система получает заметно больше количества функционала нужного качества в расчете на затраченный рубль ЗП, чем это было бы без умелого наставничества
Адекватная позиция.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правила прикорма