По-моему, Вы утрируете. Никто никого не веселит и не развлекает. Если я учусь у отличного преподавателя, который умеет зажечь студентов, и вижу, как вокруг меня «горят» и азартно с увлечением учатся, а меня здесь ничто не радует — то я задумаюсь: а не пойти ли мне в такое место, где я тоже буду «гореть» и учиться с азартом. И сам без понуканий пойду его искать.
Если же вокруг меня «гореть» никто не будет, то и у меня повода задуматься о перемене места просто не будет: какой смысл менять шило на мыло, если вокруг один мрак беспросветный и безнадёга, хоть здесь, хоть везде. Отучусь-ка я здесь как-нибудь…
А искусственных трудностей — не надо, у нас и натуральных хватает.
Таких студентов следует отчислять, а не «зажигать» или что там еще.
В недавнем переводе книги понравилась фраза: «Что вы сегодня сделали альтруистичного, изобретательного, или интересного?». С помощью этого вопроса и интереса к ответам отец «зажигал» своих детей, мотивировал их искать и совершать Поступки.
Человек знает и умеет только то, что ему показали и рассказали другие люди. Если людей вокруг не было, то вырастают Маугли. Не надо сразу отчислять, этих «Маугли» и так слишком много вокруг нас. Будьте гуманнее. Студентам, которые ходят на лекции ради галочки, просто не встретился Человек, с которого они захотели бы брать пример. Они видели вокруг лишь преподавателей, которые тоже ходят на лекцию ради галочки. В Москву с рыбным обозом приходят единицы.
И эта цена — примерно трёх-четырёхкратное замедление времени разработки.
Я считаю, что тут Вы чересчур драматизируете. Чистый и правильный код появляется благодаря выработке относительно небольшого количества навыков. Чтобы их выработать, действительно требуется время. «Тяжело в ученье», как говорится. А потом хороший код будет писаться «на автомате», просто по привычке. Причём сразу же. Время, затрачиваемое на каждое «микро-улучшение» кода в процессе написания, может начинать приносить дивиденты сразу же. Так что общее время, затраченное на «чистый» код, может быть таким же, и даже меньшим.
Сравнение андроида и UWP, мне кажется, за рамками дискуссии. Мы же не архитектуры обсуждаем, а всего лишь код.
Я же как раз наоборот имел в виду именно тех отличников, которые соображают и понимают, а не зубрят. В учебных предметах их способности позволяют им получать верные решения очень быстро, пропуская несущественные промежуточные шаги. Да и в реальных технических задачах высокая скорость решения, как правило, — положительный фактор.
А в программировании промежуточные шаги внезапно оказываются самыми существенными. И отличники начинают искренне недоумевать по поводу наездов на их прекрасные 300-строчные функции. Но они ведь старались, они делали лучшее, на что способны! Просто никто не объяснил, что в программировании нужно в точности наоборот — писать тупой код, а быстрые и умные решения всегда имеют вредные последствия.
Мне в универе рассказывали только про структурное программирование Дейкстры, а про принцип единственной ответственности я узнал много позже. Что удивительного, что я рассуждал о длине метода, опираясь на чьи-то советы по поводу размера экрана, не понимая, какова истинная причина того, почему методы должны быть короткими.
Спасибо, только зря Вы так про технарей. Технари тоже творят, да ещё ого-го как! Что по-вашему есть весь современный материальный мир (я имею в виду человеческий), как не результат творчества технарей? У гуманитариев произведения искусства — это картины и оперы, а у нас — патенты и чертежи, программы.
Само слово «технология» происходит от древне-греческого τέχνη — искусство, мастерство, умение. И фантазии, и смелых решений в нашей работе предостаточно. Иногда смотришь на чей-нибудь хороший код — и реально эстетическое наслаждение получаешь: насколько человек всё изящно и виртуозно сделал!
А как проверить, что она работала, когда все шаги записаны? Можно ведь и списать?
Я думаю, учитель всегда прекрасно знает каждого ученика: его способности и меру ответственности. И если способный и ответственный ученик записывает готовый ответ, учитель, как правило, будет ему доверять (хотя, наверное, будет вздыхать при этом). С таким учеником можно быть уверенным, что если записал ответ без шагов — значит, справился с решением в уме.
А к не очень ответственным и не очень способным — к тем да, возникают вопросы.
Бывает и так, но не всегда. Не все задачи нам раньше попадались, не на все ответ мы знаем. Иногда приходится решать новые, незнакомые задачи. Некоторые несложные вполне по силам и в уме решить.
Почему голый ответ не тренирует навык? Я же задачу решал, значит, навык потренировал. А что шаги не записал — ну так это просто лень ручкой по бумаге водить. Голова-то работала…
Да, борьбу за байты помню как сейчас. Был у меня тогда самодельный набор хакера. В zeus assembler написал утилитку, которая позволяла делать разнообразные дампы, а потом и дизассемблировать код. Утилитка «жила» в экранной памяти, в средней и нижней трети, чтобы остаток от 48К ОЗУ был свободен для подопытных программ. Когда писал дизассемблер, дозволенные 4 Кб закончились, и пришлось переписывать весь дизассемблер с нуля. Получилось, да ещё несколько сот байт дополнительно освободилось.
Много чего в той утилитке было: к полному дизассемблеру Z80 — дампы памяти в десятичном, шестнадцатеричном и символьном видах, в виде спрайтов, поиск байтов и слов, плавная попиксельная прокрутка рабочей области экрана, потом собственный загрузчик добавился и ещё что-то там — не помню.
Сам zeus я тоже дизассемблировал. Хотел стырить код для парсинга команд, и нашёл внутри команду «What is the meaning of life?», которая всегда выдавала какие-то «42» и ничего больше не делала. Тогда я ещё не читал Дугласа Адамса и не понял прикола.
А выводов-то, собственно, ещё и нет. Я же написал: «гипотеза». То, что она не очевидна, не значит, что она не имеет права на существование. Да, она ещё не подтверждена, ну так ведь и не опровергнута. Большинство доводов «против» мне кажутся такими же туманными, как моим оппонентам — мои доводы «за». Хотя никаких особенных доводов я и не стремился приводить — так, высказал идею, предположение.
Брайан Фитцпатрик и Бен Коллинз-Сассмэн в книге «Идеальная IT-компания» в первой же главе утверждают и доказывают, что любую идею нужно выносить на обсуждение. Иначе высока вероятность наделать ошибок в самом начале пути, когда их цена особенно высока. Кому интересно — пункт «Скрываться вредно».
Подтверждение гипотезы — вопрос времени и будущих усилий. Наблюдения, эксприменты, анализ кода, плотное изучение когнитивной теории, наконец.
Я проводил такую аналогию. Тот, кто привык решать задачу, записывая каждый маленький шаг, тот и машину будет программировать так, чтобы она продвигалась к решению маленькими шагами. А тот, кто привык получать сразу готовое решение «из головы», и машину запрограммирует так, чтобы она тоже выдавала готовый результат без фиксации промежуточных шагов.
Разумеется, такая индукция не может претендовать на полноту. Не всякий «отличник» будет писать исключительно готовые решения, и не всякий «троечник» будет придерживаться принципа единственной ответственности.
А Вы знали значение этих иероглифов? Если бы знали значение и знали наизусть их начертание — запомнили бы без труда. А так, задача запомнить произвольный набор из 10+ штрихов — непосильная для человека западной культуры. Это куда сложнее, чем запомнить 10+ произвольных букв.
А вот семь букв или семь слов (знакомых) для нас — это как раз всё равно. Потому что те и другие мы обрабатываем как целостные объекты, гештальты.
Нет пока ещё такого алгоритма. Есть предположение, что, возможно, такая метрика может оказаться полезной. Что в неё следует включать — не до конца ясно. Объекты, которыми оперирует интеллект программиста при написании участка кода. Ясно, что какими объектами он оперирует, те и пишет в код. Но какие именно объекты? Переменные, вызовы методов, операции, константы, элементы структур — что? Какие именно из этих объектов занимают место в рабочей памяти программиста, а какие — нет? Проблема очерчена — есть, над чем поработать.
Это потому, что Вы наступили на достаточное количество граблей и перешли на следующий уровень. Опытный программист отличается от неопытного тем, что пишет понятный код.
Некоторые из отличников пишут длинный запутанный код потому, что могут это делать, интеллект позволяет. А опыт ещё не подсказывает, что так делать нельзя.
Тут всё интересно. Пять и семь — это количество неких «объектов». Если заставить человека запоминать случайную последовательность букв, то такими объектами будут буквы, и человек запомнит в среднем примерно семь букв. А если слова — то примерно семь слов. А букв в этих словах будет существенно больше.
Гений — это далеко после «отличника». Кто же их знает, этих гениев? Может, не все умеют предсказывать результаты своих действий далеко вперёд? Я не гений, подтвердить или опровергнуть не могу.
А про когнитивные метрики — так я же как раз об этом. Как сообщить кодеру, что пора завязывать кодить и настало время подумать об архитектуре? Вот тебе метрика: как только вылезет выше семи — начинай грамотно проектировать. И кстати, такая когнитивная метрика сама по себе работать не будет, а только в комплексе со всеми прочими метриками. Потому что про связность и зацепление тоже надо помнить, и прочее, и прочее.
Если же вокруг меня «гореть» никто не будет, то и у меня повода задуматься о перемене места просто не будет: какой смысл менять шило на мыло, если вокруг один мрак беспросветный и безнадёга, хоть здесь, хоть везде. Отучусь-ка я здесь как-нибудь…
А искусственных трудностей — не надо, у нас и натуральных хватает.
В недавнем переводе книги понравилась фраза: «Что вы сегодня сделали альтруистичного, изобретательного, или интересного?». С помощью этого вопроса и интереса к ответам отец «зажигал» своих детей, мотивировал их искать и совершать Поступки.
Человек знает и умеет только то, что ему показали и рассказали другие люди. Если людей вокруг не было, то вырастают Маугли. Не надо сразу отчислять, этих «Маугли» и так слишком много вокруг нас. Будьте гуманнее. Студентам, которые ходят на лекции ради галочки, просто не встретился Человек, с которого они захотели бы брать пример. Они видели вокруг лишь преподавателей, которые тоже ходят на лекцию ради галочки. В Москву с рыбным обозом приходят единицы.
Я считаю, что тут Вы чересчур драматизируете. Чистый и правильный код появляется благодаря выработке относительно небольшого количества навыков. Чтобы их выработать, действительно требуется время. «Тяжело в ученье», как говорится. А потом хороший код будет писаться «на автомате», просто по привычке. Причём сразу же. Время, затрачиваемое на каждое «микро-улучшение» кода в процессе написания, может начинать приносить дивиденты сразу же. Так что общее время, затраченное на «чистый» код, может быть таким же, и даже меньшим.
Сравнение андроида и UWP, мне кажется, за рамками дискуссии. Мы же не архитектуры обсуждаем, а всего лишь код.
Я же как раз наоборот имел в виду именно тех отличников, которые соображают и понимают, а не зубрят. В учебных предметах их способности позволяют им получать верные решения очень быстро, пропуская несущественные промежуточные шаги. Да и в реальных технических задачах высокая скорость решения, как правило, — положительный фактор.
А в программировании промежуточные шаги внезапно оказываются самыми существенными. И отличники начинают искренне недоумевать по поводу наездов на их прекрасные 300-строчные функции. Но они ведь старались, они делали лучшее, на что способны! Просто никто не объяснил, что в программировании нужно в точности наоборот — писать тупой код, а быстрые и умные решения всегда имеют вредные последствия.
Мне в универе рассказывали только про структурное программирование Дейкстры, а про принцип единственной ответственности я узнал много позже. Что удивительного, что я рассуждал о длине метода, опираясь на чьи-то советы по поводу размера экрана, не понимая, какова истинная причина того, почему методы должны быть короткими.
Само слово «технология» происходит от древне-греческого τέχνη — искусство, мастерство, умение. И фантазии, и смелых решений в нашей работе предостаточно. Иногда смотришь на чей-нибудь хороший код — и реально эстетическое наслаждение получаешь: насколько человек всё изящно и виртуозно сделал!
Я думаю, учитель всегда прекрасно знает каждого ученика: его способности и меру ответственности. И если способный и ответственный ученик записывает готовый ответ, учитель, как правило, будет ему доверять (хотя, наверное, будет вздыхать при этом). С таким учеником можно быть уверенным, что если записал ответ без шагов — значит, справился с решением в уме.
А к не очень ответственным и не очень способным — к тем да, возникают вопросы.
Да, борьбу за байты помню как сейчас. Был у меня тогда самодельный набор хакера. В zeus assembler написал утилитку, которая позволяла делать разнообразные дампы, а потом и дизассемблировать код. Утилитка «жила» в экранной памяти, в средней и нижней трети, чтобы остаток от 48К ОЗУ был свободен для подопытных программ. Когда писал дизассемблер, дозволенные 4 Кб закончились, и пришлось переписывать весь дизассемблер с нуля. Получилось, да ещё несколько сот байт дополнительно освободилось.
Много чего в той утилитке было: к полному дизассемблеру Z80 — дампы памяти в десятичном, шестнадцатеричном и символьном видах, в виде спрайтов, поиск байтов и слов, плавная попиксельная прокрутка рабочей области экрана, потом собственный загрузчик добавился и ещё что-то там — не помню.
Сам zeus я тоже дизассемблировал. Хотел стырить код для парсинга команд, и нашёл внутри команду «What is the meaning of life?», которая всегда выдавала какие-то «42» и ничего больше не делала. Тогда я ещё не читал Дугласа Адамса и не понял прикола.
Брайан Фитцпатрик и Бен Коллинз-Сассмэн в книге «Идеальная IT-компания» в первой же главе утверждают и доказывают, что любую идею нужно выносить на обсуждение. Иначе высока вероятность наделать ошибок в самом начале пути, когда их цена особенно высока. Кому интересно — пункт «Скрываться вредно».
Подтверждение гипотезы — вопрос времени и будущих усилий. Наблюдения, эксприменты, анализ кода, плотное изучение когнитивной теории, наконец.
Я проводил такую аналогию. Тот, кто привык решать задачу, записывая каждый маленький шаг, тот и машину будет программировать так, чтобы она продвигалась к решению маленькими шагами. А тот, кто привык получать сразу готовое решение «из головы», и машину запрограммирует так, чтобы она тоже выдавала готовый результат без фиксации промежуточных шагов.
Разумеется, такая индукция не может претендовать на полноту. Не всякий «отличник» будет писать исключительно готовые решения, и не всякий «троечник» будет придерживаться принципа единственной ответственности.
А вот семь букв или семь слов (знакомых) для нас — это как раз всё равно. Потому что те и другие мы обрабатываем как целостные объекты, гештальты.
Почитайте «Программный код и его метрики», и особенно метрики Холстеда. Там много пищи для размышления.
Некоторые из отличников пишут длинный запутанный код потому, что могут это делать, интеллект позволяет. А опыт ещё не подсказывает, что так делать нельзя.
А про когнитивные метрики — так я же как раз об этом. Как сообщить кодеру, что пора завязывать кодить и настало время подумать об архитектуре? Вот тебе метрика: как только вылезет выше семи — начинай грамотно проектировать. И кстати, такая когнитивная метрика сама по себе работать не будет, а только в комплексе со всеми прочими метриками. Потому что про связность и зацепление тоже надо помнить, и прочее, и прочее.