Как я могу мотивировать ассистентов учителей ставить более строгие оценки?

Я лектор, ведущий курс с более чем 250 студентами и несколькими ассистентами. ассистенты частично несут ответственность за оценку домашних заданий. Поскольку это задания по программированию, двух одинаковых работ не бывает, поэтому невозможно охватить все возможные случаи в правилах оценивания, а оценивание имеет некоторый субъективный элемент.

Я заметил, что один ТА стабильно строже других. Например, если в рекомендациях говорится, что «эффективность кода» стоит 20 баллов, то этот ТА вычтет 15 баллов, если код неэффективен, в то время как другие ТА вычтут только 5 баллов за аналогичную проблему. Потенциальная проблема здесь заключается в том, что это может быть несправедливо по отношению к учащимся класса строгого ассистента, но это можно решить, распределив задание «по горизонтали» (каждый ассистент оценивает все 250 представленных работ в некоторых заданиях), а не «по вертикали». .

Но у меня другой вопрос: я заметил, что студенты, которым ставят более строгие оценки, более серьезно относятся к отзывам и, как правило, становятся лучшими программистами. Таким образом, вместо того, чтобы просто быть «справедливым», я бы хотел, чтобы все ассистенты ставили более строгие оценки — ради студентов. Проблема в том, что большинство ассистентов не заинтересованы в строгой оценке — они ничего от этого не получают; все, что они получают, - это необходимость обрабатывать жалобы и апелляции студентов и рисковать более низкими оценками в отзывах студентов (поскольку студенты не понимают, что это в их пользу, пока они не закончат учебу).

ассистенты не ленивы - они действительно прикладывают много усилий для обучения и помощи студентам; им просто не нравится быть «плохими парнями», которые ставят низкие оценки. Как я могу мотивировать их ставить более строгие оценки?

ВЫВОД: Большое спасибо всем ответившим. Помимо отличных ответов, я сделал две вещи:

  • Я назначил себя в один из разделов ТА (где задания оцениваются), чтобы получить представление о задаче оценивания с точки зрения ТА. Это был очень интересный и важный опыт, который помог мне уточнить рубрику.
  • Я представил использование инструмента статического анализа (в частности, clang-tidyдля C++) как часть автоматической оценки. Это было намного строже, чем у меня и ассистентов, в выявлении проблем с читабельностью и качеством кода. Студенты многому научились, просто пытаясь запустить clang-tidyсвой код без предупреждений.
Какую обратную связь получают учащиеся, кроме своих «отметок»? Объясняют ли ассистенты, где учащийся ошибся или почему были вычтены баллы?
У меня нет времени писать ответ, но это похоже на проблему с вашей рубрикой. Кажется, непонятно, как выглядят 20 пунктов эффективности против 15 против 10 против 5.
@ Баффи, да, ТА объясняют, и если объяснения недостаточно, студенты спрашивают ТА или спрашивают меня. Им не составляет труда «загонять» нас вопросами.
@Dawn Проблема в том, что каждое задание отличается, и трудно охватить все 250 способов, которыми учащиеся пишут неэффективный код (и аналогично для других критериев оценки).
Я слышу вас, но я думаю, что вы недостаточно творчески подходите к этому. Я бы посоветовал вам изучить рубрики оценивания эссе, чтобы лучше понять, как это сделать. Да, создание хороших рубрик требует времени и усилий, но с практикой вы научитесь делать это лучше.
Для моих собственных действий я считаю полезным отличать «обратную связь» от «оценки». Не нужно «строго/резко оценивать», чтобы дать отзыв. Серьезных студентов не нужно бить дубинками, чтобы понять критику.
Можно ли просто оценивать эффективность кода просто как взвешенное время выполнения для различных выборочных входных данных? Это не будет работать, например, для ясности, но конкретно для эффективности могут быть более объективные (и более эффективные :) ) методы, чем оценка кода ТА. Конечно, ТА все равно придется проверять код, чтобы убедиться, что они просто написали переключатель для всех возможных входов, и в случае низкой эффективности дать обратную связь.
Производительность может быть измерена и оценена автоматически, без какой-либо работы ТА. Я был на нескольких курсах, где это было сделано, этот метод лучше всего принимается всеми, потому что у вас есть абсолютно беспристрастный судья, если вы сравните решения, которые предлагают студенты.
@paulgarrett Да, это! Оценивать (домашние задания) очень трудно справедливо. Я не согласен с тем, что рубрики помогают, на самом деле они только формализуют справедливость и работают как оправдание одной несправедливой системы. Однако проведение четкого различия между «обратной связью» и оценкой (первое — это «не текст, который вы пишете для обоснования второго») обычно значительно уменьшает разницу в оценке. В сочетании с системой, которая не дает баллов (какие оценщики и учащимся трудно понять), но оценка между «очень хорошо», «хорошо», «хорошо» и «плохо» в основном помогает сгладить расхождения
@Polygnome Иногда это может быть сложно. Например, что, если числовая программа работает очень быстро, но в результате имеет более низкую точность? Иногда приходится идти на компромиссы, о которых трудно судить объективно.
@Peter Производительность и точность можно измерить. Автоматически. Схема оценивания может точно отображать точность и производительность в баллах. На самом деле было бы действительно хорошим упражнением, если бы учащиеся могли выбирать между точностью, производительностью или и тем, и другим, и пытаться получить все баллы.
@Polygnome Да, я просто говорю, что потенциально сложно автоматически сопоставить заданную комбинацию производительности и точности (или любую другую комбинацию или показатели) с оценкой, что обычно требует человеческого суждения, а не просто присуждения баллов, например, на основе времени выполнения. относительно некоторого раствора образца.
Можете ли вы уточнить, что это за уровень курса? Вероятно, вам нужен другой метод, если вы беспокоитесь, скажем, о том, выбрали ли учащиеся наиболее эффективный алгоритм сортировки, и если ваша проблема заключается в том, что учащиеся не могут понять цикл for, поэтому они копируют и вставляют одно и то же. блок кода 50 раз.
Я сомневаюсь, что профессиональным программистам дают рубрики. Программистам действительно необходимо выработать собственное суждение о том, какие хорошие методы программирования следует использовать для конкретной задачи. Наличие очень подробных рубрик не помогает привить учащимся потребность развивать собственные суждения (и самокритическую оценку своей работы).
@Polygnome проблема с автоматической оценкой эффективности заключается в том, что она не объясняет, почему код неэффективен. Точно так же для точности можно получить правильный ответ по неправильной причине. Автоматическая оценка — это очень хорошо, но я бы не хотел, чтобы это был единственный способ оценки этих вещей.
@DikranMarsupial Я никогда не говорил, что это должно быть единственное . Но если вы все же измеряете производительность или точность, делать это автоматически — самый объективный способ. Вы можете легко дать 5 баллов за точность, 5 баллов за производительность и 10 баллов за другие вещи. Также можно составить упражнения таким образом, чтобы «неправильные» решения проваливались. Если вы спросите: «Напишите рекурсивное решение для XYZ…», то каждое решение, которое делает это итеративно, — 0 баллов, потому что об этом не спрашивали. Четко определенная схема оценок устраняет двусмысленность как для студентов, так и для ассистентов и, таким образом, уменьшает количество жалоб.
@Polygnome, который по-прежнему оставляет проблему того, как оценить, почему это было неэффективно и т. Д., И мы вернулись к тому, с чего начали. Как я уже сказал, четко определенные схемы оценивания также не помогают учащимся выработать здравые суждения о навыках программирования и написании поддерживаемого кода (который не может быть оценен автоматически — когда мы сможем это сделать, мы все потеряем работу — программисты тоже). Я не возражаю против жалоб, если они «вы не должны требовать, чтобы мы использовали свое собственное суждение», если это является целью обучения.
@paulgarrett «Серьезных студентов не нужно бить дубинкой, чтобы понять критические замечания» Верно, но применение значительных штрафных баллов к критическим замечаниям может также помочь посредственным ученикам стать лучше и потенциально превратиться в серьезных студентов. Как ни странно, когда я вел вводное занятие по программированию, у меня был студент, который часто жаловался на то, как жестко я оцениваю, казалось бы, незначительные ошибки. Но он действительно стал делать меньше таких ошибок. Позже, когда он проходил курс по операционным системам, он зашел ко мне в офис, чтобы сказать, что теперь понимает, почему я настаивал на таком уровне строгости.
Цель оценивания студентов (если это учитывается в их окончательном результате) не в том, чтобы побудить их что-либо делать. Это оценка их работы в соответствии с принятыми стандартами, чтобы учащиеся (и, возможно, их работодатели) имели максимально точное представление об их способностях (с учетом ограничений схемы оценивания). Комментарии в обратной связи хороши для поощрения.
Если ваша проблема заключается в стимулах, в нежелании ассистентов заниматься жалобами, один из способов устранить эту проблему — заниматься жалобами самостоятельно, абсолютно без участия ассистента.

Ответы (9)

Несколько вещей, чтобы добавить:

  • Убедитесь, что ТА знает, что вы поддержите их и будете плохим парнем. Студенты знают, что ассистенты используют ваши рекомендации. Если ассистент использует свое суждение, но был слишком резок, вы дадите понять и ему, и студенту, что это ваша вина, что вы не выразились более ясно.

  • Подчеркните преимущества последовательности для ТА. Напомните им, что студенты сравнивают оценки. Сообщите им, что можно спросить другого ассистента, как они оценивают что-то (или вас). Сообщите им, что если они дают слишком много баллов, это создает проблемы для других ТА.

  • Напомните им, что им пришлось много работать, чтобы сдать этот класс (при условии, что они это сделали). Студенты, как правило, защищают свои специальности, особенно TA, и хотят поддерживать стандарты.

  • Получите одобрение TA по критериям оценивания. Это похоже на последнюю пулю. Предположим, это -50% за неиспользование функций, даже если они работают. Напомните им, что это задание «научиться использовать функции», и в нем говорилось, что они необходимы, и вы всю прошлую неделю повторяли функции в классе. Скидка 50% щедрая.

Мне удалось прожить 5 лет, ни разу не услышав слова Рубрика, а затем еще 6 месяцев, прежде чем я понял, что это то же самое, что и оценочный ключ. Я пытаюсь быть несколько подробным в диапазоне:

Стиль:

  • -5: не пробовал. ерунда имена переменных, случайные отступы, выглядит как мусор
  • -3: еле пробовал и только местами
  • -0: на самом деле пытался, но все еще выглядит плохо.

«Эффективность» кажется слишком расплывчатой. Я пытаюсь перечислить конкретные вещи, которые они должны сделать:

Эффективность:

  • -5: нет циклов массива, просто много ЕСЛИ.
  • -3: нет вложенных if
  • -0: как минимум 2 полезных вложенных варианта if (даже если могут быть и другие)

Но (и я знаю, что это не то, о чем вы спрашивали) на обычных занятиях по кодированию часто просто пытаются изучить что-то новое и заставить его работать. «Хороший стиль» часто слишком многого требует. «Эффективность» может быть еще более пугающей и запутанной.

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

Мне очень нравится тот факт, что «на самом деле пытался, но все еще выглядит плохо» подходит к -0этому ключу. Все, кто оценивает задания, заметно более компетентны в предметной области, чем учащиеся. Я думаю, что четкое изложение этого помогает людям перестать искать идеальные решения для идеального результата.
Рубрика «эффективность» кажется мне странной, сравнивая циклы и если и каким-то образом оценивая вложенные если. Это больше похоже на часть стиля. Если это просто как пример, то ладно, но я очень надеюсь, что никто не использует его на практике. Кроме того, следует отметить, что наиболее эффективный код часто гораздо менее читаем ("выглядит плохо"), чем просто "достаточно хороший" код.
@DanM.Я добавлю пустую строку. Для if я думаю о 5 строках, таких как if(letterGrade==true && g>=70 && g<80), когда вы только что охвачены и требуется-где-применимо вложенные и каскадные if's.
Мне больше всего нравится твой ответ. Я получил оценку по CS (не был специалистом по CS), и с профессионалом у меня был определенный ключ - в основном разные входы и выходы, и они должны совпадать. Затем я читал их код на наличие проблем/комментариев. Учитывая, что им были предоставлены образцы данных и входящие/исходящие различия, не было оправдания тому, что они не генерировали форматирование. При этом любые разногласия по поводу стиля, комментариев или... чрезмерного дублирования чужой работы... шли к профессору.
Первые четыре пункта касаются психологических проблем, связанных с нежеланием ассистентов ставить низкие оценки, что и является основной темой моего вопроса. Спасибо

У вас есть более серьезная проблема, чем поощрение более строгих оценок. Вы должны обеспечить последовательную оценку. В противном случае ваша схема в корне несправедлива.

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

Вы можете сделать рубрику сколь угодно строгой (хотя мне не очень нравится концепция узких интерпретаций), но она должна быть ясной для ваших ассистентов и разумной для ваших студентов.

Один из способов обеспечить некоторую согласованность — привлечь более одного ассистента к работе каждого учащегося. Они должны договориться друг с другом или обратиться к вам за решением. Если они введут оценки учащихся в электронную таблицу, вы сможете легко увидеть различия и также сможете использовать ее для дальнейшего обучения ТА по мере необходимости, например, когда один ТА постоянно «слишком» снисходителен.

В упражнении, состоящем из большого количества частей, можно назначить каждого ТА ответственным только за одну часть. Это, как правило, работает для выпускных экзаменов, когда студенты отвечают на вопросы, но хуже для заданий по программированию.

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

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

Но, опять же, требуется постоянство. Рубрика должна быть полной, чтобы гарантировать это. «Строгость» — это второстепенная проблема, но ее можно улучшить (ваша идея, а не моя) с помощью надлежащей рубрики, понятной всем.

Более того, если вы попытаетесь оценить по фиксированной шкале вещи, которые принципиально «нечетки», перед вами возникнет невыполнимая задача. Если вы можете определить «эффективность» в своем примере, тогда хорошо. Но если это нечеткое понятие, то почти каждая рубрика, скорее всего, оставит оценку интуиции. Ставьте точные оценки за то, что является точным. Но для других вещей, вероятно, необходимы суждение и немного сострадания.

В CS кое-что понятно, конечно. Если учащийся использует пузырьковую сортировку на большом массиве, это явно неэффективно. Но сортировка выбором более эффективна, чем быстрая сортировка в определенном масштабе, поэтому библиотечные версии быстрой сортировки обычно возвращаются к сортировке выбором для небольших разделов исходного набора.

Но суждения о «правильном факторинге» кода субъективны. Если вы чувствуете: «Я не могу определить это, но я узнаю это, когда увижу это ». тогда почти невозможно создать рубрику, которая будет последовательно использоваться группой ассистентов.

Даже в случае сортировки сортировка вставками часто может неожиданно превосходить другие сортировки на современных процессорах из-за предсказуемого потока управления, несмотря на выполнение значительно большего количества инструкций. Так что это может во многом зависеть от вашего определения эффективности. Сейчас так много стандартных библиотек используют это для небольших случаев.
Я не понимаю, как этот адрес заданный вопрос. В вопросе ОП признает эту проблему согласованности, упоминает, что им известно о стандартном и адекватном решении (присваивая оценку «по горизонтали» среди ТА, а не «по вертикали»), а затем объясняет, что они спрашивают о другом (хотя связанный) вопрос.
@PLL правильно сформулированная рубрика по своей природе устанавливает уровень «строгости» при ее применении. Если это не так, то это несовершенная рубрика, оставляющая слишком много для интерпретации.
+1 только за первое предложение. Когда у меня было несколько компетентных ТА, одна вещь, которую я сделал, это собралась вместе, чтобы придумать рубрику и посмотреть, как другие ТА оценивают в начале, чтобы убедиться, что они находятся на той же странице. Оказавшись на одной странице, они по очереди писали рубрики для заданий.
Я согласен с тем, что рубрика важна, но, как вы сказали, даже очень подробная рубрика оставляет определенный субъективный элемент для оценки, и мой вопрос касается конкретно этого оставшегося субъективного элемента. Это больше о психологии нежелания быть «плохим парнем».

По моему опыту, лучший способ обеспечить согласованность — установить простые и четкие рубрики.

Это можно сделать с помощью модерации: пусть все преподаватели вместе отметят 10 сценариев и увидят, в чем заключаются разногласия.

В качестве альтернативы, если у вас есть доступ к инструментам модерации, таким как Gradescope, это избавляет от необходимости встречаться лично.

Итог - просто четко опишите свои ожидания. Объясните ассистентам цель выставления оценок – строгая или снисходительная, а также необходимость последовательности.

Несколько предложений, касающихся нескольких аспектов вопроса.

Потратьте некоторое время на обучение ТА. В начале семестра пусть все оценивают один и тот же набор образцов работ из предыдущего семестра. Соберитесь в группе, чтобы обсудить, что вы и они считаете важным при исправлении неэффективности и неэлегантности. Если вы можете достичь консенсуса, хорошо. Если нет, сделайте свои собственные требования понятными для всех. Возможно, повторите это упражнение с ТА после первого задания.

Рассмотрите две отдельные оценки для каждого задания, одну за правильность и одну за стиль. Может быть, быть строгим по шкале стиля, но меньше весить этой маркой.

Дайте заданиям по программированию в конце семестра больше, чем в начале, и убедитесь, что студенты знают об этом. Это должно смягчить эффект строгих стандартов в начале и научить их тому, что им нужно делать, чтобы работать лучше позже.

Интересные советы, спасибо. Мне особенно нравится последний, который имитирует идею о том, что «низкая оценка теперь хорошо окупается в долгосрочной перспективе».

Для заданий по программированию нет ничего лучше, чем набор автоматических тестов, которые оценивают точность, производительность и запахи кода.

У вас могут быть уровни тестов:

  • Уровень I - базовые тесты
  • Уровень II — расширенные/пограничные тесты
  • Уровень III — тесты производительности, запахов кода

В зависимости от уровня определяются баллы/оценка.

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

У нас это уже есть; мой вопрос касается вещей, которые не могут быть оценены автоматически, например, качество кода и стиль написания.
Что касается качества кода, то в большинстве языков есть анализаторы для автоматической проверки качества кода. Наиболее распространенным является Линтер. Также можно обнаруживать запахи кода, используя другие метрики со специализированными инструментами, такими как цикломатическая сложность, связанность, когерентность и т. Д. Область анализа кода в целом без его запуска называется статическим анализом.
@ErelSegal-Halevi - Как разработчик программного обеспечения я нахожу это весьма ироничным, потому что качество кода в академических кругах ужасно. И, как сказал Феликс, в промышленности у нас есть ТОННА инструментов для качества кода.

Что я и другие ассистенты сделали в прошлом семестре, чтобы убедиться, что мы оцениваем всех студентов как можно более равномерно:

  • Перед тем, как задание было передано ученикам, мы просмотрели рубрику, чтобы попытаться найти в ней дыры. Мы хотели удостовериться, что то, что учащимся было сказано делать в задании, что в задании говорилось, что они будут оцениваться, и фактические критерии, которые мы будем использовать, были согласованы. Если бы они не были согласованы, мы возвращались бы к лектору и предлагали уточнение.
  • Когда пришли результаты, мы взяли пару заявок и оценили их вместе, чтобы откалибровать между ТА, как мы будем применять пункты в рубрике на практике. После первого задания у нас было хорошее представление о сильных и слабых программистах, поэтому мы выбирали предположительно сильную и предположительно слабую заявку для калибровки на обоих концах шкалы.
  • Оценивая задание, мы записывали, какие баллы были набраны по каждому пункту критерия. Таким образом, вы можете посмотреть, почему именно студент получил такую ​​оценку, которую он получил, и что он должен улучшить при повторной сдаче.
  • Мы также отслеживали среднюю оценку, выставленную каждым ассистентом, чтобы мы могли проверить, были ли средние оценки одного ассистента значительно выше или ниже, чем у других.

Этот подход вполне себя оправдал.

Этот ответ недооценен. Написание рубрики, охватывающей все случаи, — невероятно сложная задача. Отметив несколько сценариев вместе, вы с большей вероятностью получите стабильные оценки.

Если вы хотите уменьшить дисперсию, вы можете использовать многопроходную маркировку.

Все выводы происходят из комбинации помеченной части кода, причины и вывода из-за отмеченной части кода.

Возьмите такую ​​информацию и передайте отмеченную часть кода и причины другому ТА, и они самостоятельно определят вычет на основании вашей Рубрики.

Если они существенно не согласны, отправьте их третьему ТА.

Если они по-прежнему в значительной степени расходятся во мнениях, сообщите об этом вам и улучшите Рубрику.

Первый ассистент тратит большую часть времени (ищет проблемы), второй ассистент должен применить Рубрику только к выявленной проблеме, так что это должно вдвое увеличить рабочую нагрузку по выставлению оценок.

Поскольку теперь вы сравниваете два (или три) определения ТА того, насколько серьезным является что-либо, вы можете сместить среднее значение в сторону более серьезной оценки. ассистенты, которые регулярно проявляют наименьшую суровость, работу которых вы можете проверить, и поощрять быть более строгими, если это необходимо.

Вы заметите, что вы даже можете использовать такой механизм для проверки кода между учениками (наблюдение за тем, что другие люди делают неправильно или правильно, имеет большое значение при обучении). Учащимся предлагается использовать Рубрику для просмотра кода другого учащегося и выявления областей, которые нарушают правила. Затем ассистенты могут просматривать выбранные учащимся вопросы и таким образом выставлять оценки.

Этот обзор студентов также можно использовать для выявления проблем, которые отсутствуют в ТА; если ассистент постоянно пропускает нарушения Рубрики, которые улавливают учащиеся (и сторонний аналитик отмечает как хорошие уловы), то это повод подумать о том, чтобы поговорить с этим ассистентом о том, чтобы быть более строгим.

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

Мне кажется, что один из ассистентов корректирует свои оценки не в соответствии с разумными ожиданиями когорты студентов, а в соответствии с абсолютными критериями, например, x-баллов, потерянных для каждого из списка потенциальных недостатков. Это может быть несправедливо, потому что недостатки часто коррелированы, а не независимы, что приводит к бимодальному распределению оценок — все они либо в основном правильно поняли, либо в основном ошиблись. В британской системе, где у нас есть первый класс, высший и младший классы и т. д., я бы попросил ассистента посмотреть на оценку, которую они выставили учащемуся, и спросить себя, соответствует ли она подразумеваемой степени. классификация. Например, если было 20 баллов за эффективность, а маркер присвоил только 5, то это говорит о том, что работа находится на грани провала в соответствии с этим качеством. Сформулировано таким образом, они могут увидеть, что оценка несовместима с их субъективной оценкой работы, а не с объективной оценкой «галочки». Если бы другой маркер мог дать ему 15 баллов, он явно не на территории провала!

... конечно, это может быть другой маркер слишком мягкий, но опять же, это проблема калибровки, они должны спросить себя (в системе Великобритании), была ли работа «первоклассной» с точки зрения эффективности, как это что означает оценка 15 (75%).

Другое дело, как ТА модерируют свои первоначальные оценки, но это проверка их калибровки на вменяемость.

Программирование имеет большой субъективный элемент. Дело не в том, чтобы просто написать программу, которая вычисляет правильный ответ (надеюсь, эффективно), она должна быть написана таким образом, чтобы ее могли понять другие люди, чтобы кто-то еще мог ее поддерживать. Чрезмерно предписывающие рубрики могут вызвать больше проблем, чем пользы, потому что иногда учащиеся могут придумать хорошие решения, которые не соответствуют вашим рубрикам, и их не следует наказывать. У студентов также есть определенная степень свободы для творчества при выполнении заданий по программированию, и я думаю, что в долгосрочной перспективе это делает их лучшими программистами.

@downvoter - некоторые отзывы о том, почему, были бы очень кстати.

Предполагая, что «вы» — это университет: платите своим ассистентам больше, чтобы повысить мотивацию. Вы не можете ожидать хорошего качества работы или более высокой мотивации за низкокачественную оплату. Щедрое оценивание — это оценивание с минимальными усилиями.

Другие ответы, пропагандирующие рубрики и обучение, также верны.

Почему вы считаете, что "Вы" - это университет? Можете ли вы объяснить, как OP может повлиять на их университет, чтобы внести изменения?
Это зависит от университета. Роль «лектора» имеет разные уровни силы в разных местах.
Не могли бы вы немного расширить ответ? Для меня это звучит как «академическое» (= непрактичное) решение, я никогда не слышал, чтобы какой-либо университет платил преподавателям больше, потому что этого хотят некоторые лекции. Это распространено в других местах в мире?
Вы предлагаете уволить их и нанять лучших ассистентов? Или вы имеете в виду, что чем больше вы платите ТА, тем ниже они будут оценивать других?
@pipe Firing не нужен, так как они обычно быстро переворачиваются. В противном случае я не уверен.
@ user111388 Я против длинных ответов. Общеизвестно, что цена товара коррелирует с его качеством. ТА не исключение.
@AnonymousPhysicist: Я знаю это, но (по крайней мере там, где я нахожусь) хорошо известно, что университет скорее снизит качество ТА, чем будет платить ТА больше. Поэтому я хотел бы знать, является ли это (лекции, лоббирующие свои ТА) на самом деле концепцией, которая часто приносит плоды на практике или только в теории.
@user111388 user111388 Вы довольно далеко уходите от темы, но если лекторы и ассистенты находятся в одном союзе, тогда да, это произошло. Студенты также могут влиять на оплату труда преподавательского состава, отказываясь от плохо преподаваемых программ/курсов.
Обратите внимание: нет никаких указаний на то, что ТА не могут выполнить «работу хорошего качества» (проблема только в том, что ОП считает их оценку слишком щедрой, а не в том, что оценка неточна или несправедлива). Также нет никаких доказательств того, что рабочая нагрузка студента несоразмерна его стипендии. По этой логике любая возможная проблема с коллегой может быть связана с недостаточной зарплатой. Вы можете быть против длинных ответов, но я против загадочных с неясной аргументацией :-)
@cag51 Я не считаю вашу критику честной. Я уверен, что вы знаете, что зарплата почти во всех TA очень низкая, поэтому я не утверждаю, что «любая возможная проблема с коллегой может быть связана с неадекватной зарплатой», поскольку в большинстве отраслей платят больше. Вы также знаете, что слишком щедрая оценка на самом деле является низкокачественной работой. Далее в вопросе указана «мотивация» проблемы, что свидетельствует о некачественной работе.
Спасибо за ответ. Я не совсем согласен, но, по крайней мере, теперь я понимаю вашу логику. (Вы можете добавить свой ответ, особенно последние два предложения, в пост, чтобы другие поняли).
Как я могу мотивировать ассистентов учителей ставить более строгие оценки?
СпросиСетьПолитика конфиденциальности1y, 0v