Интереса ради перевёл последнюю статью Джоела Спольски. Сразу предупреждаю, что некоторым перевод местами может показаться достаточно вольным — это сделано сознательно в угоду удобочитаемости по-русски.
Я так же позволил себе добавить в статью ссылок на переводы и описания тех слов и терминов, которые, как мне показалось, будут непонятны большинству русскоговорящих людей, а так же относительно которых я сильно сомневаюсь в адекватности собственного перевода.
Удивительно, как это легко — получить айтишную специальность в топовом университете даже не изучив основных инструментов разработчика, ни разу не поработав в команде, и ни разу не пройдя курс, за который ты не получишь минимальную оценку автоматом просто за участие. Многие айтишные факультеты застряли в 80-х, преподавая тот же старый, уже оторванный от реалий современного софтостроения, курс.
Откуда студентам узнать о контроле версий, багтрекинге, командной работе, планировании, оценке, дебаггинге, юзабилити-тестировании и документации? Где они научатся писать программы длиннее двадцати строк?
Многим университетам удалось убедить себя, что чем более учебный план расходится с реальным миром, тем они элитнее. Гуманитарный подход. Оставим подготовку настоящих программистов ПТУ, краснокирпичным университетам и мелким школам, наделенным в названии кучей точек с компаса типа «Университета Северной Югозападной Флориды». Мировая Лига Плюща должна давать линейную алгебру, теорию вычислений и Хаскель, и все старающиеся айтишные факультеты пытаются поднять свои стандарты, выбрасывая из учебного плана всё практичное в пользу большего количества теории.
Не поймите меня неправильно, это необязательно плохо. Они как минимум заменяют Java на Scheme, хоть и только потому что «так делают в MIT» (Слишком поздно!). И они учат студентов мыслить определённым образом. И, представляя сколько средний айтишный профессор знает о реальном программировании, я бы предпочёл чтобы дети изучали всё это во время интерншипа в Fog Creek.
Грег Вильсон, старший преподаватель из Университета Торонто, читал лекцию на конференции StackOverflow DevDay в Торонто, которая была увлекательна, информативна и прямо в точку. Мы разговорились и он рассказал мне про своё последнее детище — UCOSP, что значит Все Хорошие Имена Заняты (All The Good Names Are Taken).
Это консорциум пятнадцати университетов, в основном канадских, которые устраивают совместные дипломные проекты. Они создают команды по полдюжины будущих выпускников для участия в опенсорсных проектах за зачёт и степень. Как только я услышал о программе, я вызвался спонсировать комманду, которая будет контрибьютить в Mercurial. Спонсорство заключается в оплате путушествия в Торонто для всех участников и предоставлении программиста чтобы шефствовать над коммандой.
Блог UCOSP напомнил мне почему студенческие проекты, хоть и похвальны, зачастую не дают ничего полезного. «Одна из целей данного курса — дать вам шанс выяснить каково это — ставить задачи и потом их выполнять», пишет Грег. «Чистый выхлоп на данный момент вполне ясен: во многих случаях студенты за неделю этого курса делают меньше чем могли бы с более упорядоченным курсом того же содержания.»
Студенты колледжей к их последнему курсу имеют шестнадцать лет опыта коротких проектов и откладывания всего на последний момент. Пока ты не старшекурсник, очень меаловероятно что ты когда либо сталкивался с задачей, которую нельзя сделать за ночь.
У меня есть в этом некоторый опыт — работал со студентами из Rose-Hulman во время их дипломного проекта. Мы позволили им самим выбирать себе график и, разумеется, они откладывали всё до последней минуты и выдавали нечто незавершенное. Типичное айтишное задание подразумевает что студент напишет «интересную» часть кода (в академическом смысле слова). Остальные 90% работы, которые нужны чтобы довести код до уровня «можно пользоваться в реальной жизни», от старшекурсников никогда не ожидаются, потому что фиксать баги и разбираться с реальными условиями не «интересно», и потому что большинство преподавателей никогда в не работало в реальном мире и понятия не имеет что значит делать программы способные выжить при встрече с пользователем.
Обычно виноват тайм-менеджмент. В группе из четырёх студентов, даже если один или два из них достаточно активны чтобы начать в начале семестра, остальные, вероятно, будут тормозить — всегда есть более срочные проекты с других курсов, которые надо сдать завтра. Предприимчивые студенты будут вынуждены выбирать между тем чтобы начать первыми и в итоге сделать больше работы чем им положено по справедливости и ожиданием остальных до последней ночи. Угадайте что выберут.
У студентов нет никакого опыта долгосрочного планирования работы в комманде. Поэтому они почти всегда хреново работают на семестровых проектах, если сами планируют расписание.
Когда из такого рода проектов что-нибудь продуктивное всё же выходит, наверняка есть недельные дедлайны, и наверняка вы видели как вся работа делалась в ночь перед дедлайнами. Похоже то, что долгосрочные дедлайны без промежуточных майлстоунов редко сбываются, является неотделимой частью человеческого естества.
Возможно, это прекрасная возможность попробовать Scrum. Раз в неделю комманда собирается вместе, лично или виртуально, и разбирает работу за прошедшую неделю. Потом решают какие фичи и задачи делать на неделе следующей. Для слежения за всем этим прекрасно подошёл бы FogBugz. Если вы делаете дипломный проект и нужен доступ к FogBugs — дайте знать и мы будем счастливы предоставить его бесплатно. Мы так же можем организовать вам доступ в klin, наш хостинг для Mercurial, в котором есть возможность code review.
Я тут обвинял студентов в недостатке дисциплины для того чтобы делать семестровый проект в течении семестра вместо того чтобы прокрастинировать, но, разумеется, проблема распространена так же и среди не-студентов. На это ушло какое-то время, но я в конце-концов понял, что длинные дедлайны (или вообще отсутствие дедлайнов) совсем не подходят и для профессиональных программистов: для долгосрочной продуктивности нужен график регулярного и частого выхода компонентов. Единственная причина почему в реальном мире это работает нормально, а чисто студенческие комманды проваливаются, в том, что в реальном мире есть менеджеры, которые могут установить дедлайны. Комманда студентов, где все равны, такого не потянет.
Я так же позволил себе добавить в статью ссылок на переводы и описания тех слов и терминов, которые, как мне показалось, будут непонятны большинству русскоговорящих людей, а так же относительно которых я сильно сомневаюсь в адекватности собственного перевода.
Дипломные проекты и тайм-менеджмент
Удивительно, как это легко — получить айтишную специальность в топовом университете даже не изучив основных инструментов разработчика, ни разу не поработав в команде, и ни разу не пройдя курс, за который ты не получишь минимальную оценку автоматом просто за участие. Многие айтишные факультеты застряли в 80-х, преподавая тот же старый, уже оторванный от реалий современного софтостроения, курс.
Откуда студентам узнать о контроле версий, багтрекинге, командной работе, планировании, оценке, дебаггинге, юзабилити-тестировании и документации? Где они научатся писать программы длиннее двадцати строк?
Многим университетам удалось убедить себя, что чем более учебный план расходится с реальным миром, тем они элитнее. Гуманитарный подход. Оставим подготовку настоящих программистов ПТУ, краснокирпичным университетам и мелким школам, наделенным в названии кучей точек с компаса типа «Университета Северной Югозападной Флориды». Мировая Лига Плюща должна давать линейную алгебру, теорию вычислений и Хаскель, и все старающиеся айтишные факультеты пытаются поднять свои стандарты, выбрасывая из учебного плана всё практичное в пользу большего количества теории.
Не поймите меня неправильно, это необязательно плохо. Они как минимум заменяют Java на Scheme, хоть и только потому что «так делают в MIT» (Слишком поздно!). И они учат студентов мыслить определённым образом. И, представляя сколько средний айтишный профессор знает о реальном программировании, я бы предпочёл чтобы дети изучали всё это во время интерншипа в Fog Creek.
Грег Вильсон, старший преподаватель из Университета Торонто, читал лекцию на конференции StackOverflow DevDay в Торонто, которая была увлекательна, информативна и прямо в точку. Мы разговорились и он рассказал мне про своё последнее детище — UCOSP, что значит Все Хорошие Имена Заняты (All The Good Names Are Taken).
Это консорциум пятнадцати университетов, в основном канадских, которые устраивают совместные дипломные проекты. Они создают команды по полдюжины будущих выпускников для участия в опенсорсных проектах за зачёт и степень. Как только я услышал о программе, я вызвался спонсировать комманду, которая будет контрибьютить в Mercurial. Спонсорство заключается в оплате путушествия в Торонто для всех участников и предоставлении программиста чтобы шефствовать над коммандой.
Блог UCOSP напомнил мне почему студенческие проекты, хоть и похвальны, зачастую не дают ничего полезного. «Одна из целей данного курса — дать вам шанс выяснить каково это — ставить задачи и потом их выполнять», пишет Грег. «Чистый выхлоп на данный момент вполне ясен: во многих случаях студенты за неделю этого курса делают меньше чем могли бы с более упорядоченным курсом того же содержания.»
Студенты колледжей к их последнему курсу имеют шестнадцать лет опыта коротких проектов и откладывания всего на последний момент. Пока ты не старшекурсник, очень меаловероятно что ты когда либо сталкивался с задачей, которую нельзя сделать за ночь.
У меня есть в этом некоторый опыт — работал со студентами из Rose-Hulman во время их дипломного проекта. Мы позволили им самим выбирать себе график и, разумеется, они откладывали всё до последней минуты и выдавали нечто незавершенное. Типичное айтишное задание подразумевает что студент напишет «интересную» часть кода (в академическом смысле слова). Остальные 90% работы, которые нужны чтобы довести код до уровня «можно пользоваться в реальной жизни», от старшекурсников никогда не ожидаются, потому что фиксать баги и разбираться с реальными условиями не «интересно», и потому что большинство преподавателей никогда в не работало в реальном мире и понятия не имеет что значит делать программы способные выжить при встрече с пользователем.
Обычно виноват тайм-менеджмент. В группе из четырёх студентов, даже если один или два из них достаточно активны чтобы начать в начале семестра, остальные, вероятно, будут тормозить — всегда есть более срочные проекты с других курсов, которые надо сдать завтра. Предприимчивые студенты будут вынуждены выбирать между тем чтобы начать первыми и в итоге сделать больше работы чем им положено по справедливости и ожиданием остальных до последней ночи. Угадайте что выберут.
У студентов нет никакого опыта долгосрочного планирования работы в комманде. Поэтому они почти всегда хреново работают на семестровых проектах, если сами планируют расписание.
Когда из такого рода проектов что-нибудь продуктивное всё же выходит, наверняка есть недельные дедлайны, и наверняка вы видели как вся работа делалась в ночь перед дедлайнами. Похоже то, что долгосрочные дедлайны без промежуточных майлстоунов редко сбываются, является неотделимой частью человеческого естества.
Возможно, это прекрасная возможность попробовать Scrum. Раз в неделю комманда собирается вместе, лично или виртуально, и разбирает работу за прошедшую неделю. Потом решают какие фичи и задачи делать на неделе следующей. Для слежения за всем этим прекрасно подошёл бы FogBugz. Если вы делаете дипломный проект и нужен доступ к FogBugs — дайте знать и мы будем счастливы предоставить его бесплатно. Мы так же можем организовать вам доступ в klin, наш хостинг для Mercurial, в котором есть возможность code review.
Я тут обвинял студентов в недостатке дисциплины для того чтобы делать семестровый проект в течении семестра вместо того чтобы прокрастинировать, но, разумеется, проблема распространена так же и среди не-студентов. На это ушло какое-то время, но я в конце-концов понял, что длинные дедлайны (или вообще отсутствие дедлайнов) совсем не подходят и для профессиональных программистов: для долгосрочной продуктивности нужен график регулярного и частого выхода компонентов. Единственная причина почему в реальном мире это работает нормально, а чисто студенческие комманды проваливаются, в том, что в реальном мире есть менеджеры, которые могут установить дедлайны. Комманда студентов, где все равны, такого не потянет.
