Feedback-ът върху задачите в текущата му форма не е добра идея

  1. Преди всичко, искам да кажа, че това не е оплакване, не е hate, не е rant, не е критика. Това е само предложение и е само с идеята за подобрение, за обсъждане и за даване на feedback от нещата в курса от студентите, защото смятам, че това е нещо, което може да допринесе много както за качеството на курса, така и за студентите.

    Смятам, че текущата форма на feedback върху задачите, който се дава, не допринася по положителен начин на курсистите. Основните ми причини са:

    • Дестимулира хората да бъдат старателни в решаването на задачите са.

    Ще дам пример:

    В момента има 5 дена до крайния срок на задача 3. Започвам да пиша решение. Имам 2 избора:

    А: Полагам възможно най-много старание над задачата във всеки един аспект. Старая се да са спазени всички конвенции, да е форматиран правилно кодът, да са спазени всички добри практики, да е възможно най-оптималното решение и т.н. Това ми отнема (съвсем хипотетично) 2 дена.

    B: Пиша нещо, колкото да работи. Не се старая, не губя "излишно" време, важното е да тръгне. Това ми отнема (отново хипотетично) 1 ден. Х дена по-късно получавам feedback с нещата, които не са наред в кода ми. Оправям ги (което гарантирано отнема по-малко от 1 ден, понеже голяма част от допълнителната работа е вече свършена вместо мен) и имам решение (може би почти) като това, което бих получил и от горния вариант.

    Кое от двете бих избрал аз? Не говоря за себе си, конкретно, а говоря кое би избрал, средно-статистически, един курсист. Не искам да казвам, че курсистите са мързеливи, но едното има очевидни предимства пред другото - отнема по-малко време, по-малко усилия. Въпреки това, носи същите крайни резултати - еднакво добро решение.

    Изборът между двете става напълно неволно и несъзнателно и хората ежедневно вземат решения, които им спестяват време и усилия, защото са едни от най-ценните неща. Ясно е, че никой не би си казал "Сега ще напиша нещо набързо, пък те ще ми го оправят". Просто аз, като курсист, след като седна да си пиша задачата не се чувствам задължен и стимулиран да дам най-доброто от себе си. Конкретно за себе си, го правя, но бих се чувствал много по-мотивиран и най-вероятно бих дал много повече от себе си, ако знаех, че това е final решението ми.

    • Създава unfair среда за курсистите.

    Доводите за това са вече по-очевидни. Хората, които учат нещата сами, и хората, които "следват инструкции" са еднакво "наградени". Това, до определена степен, обезсмисля класацията, оценяването и точките, които са много много важна част за един курс. Аргументите за това също са сравнително ясни и щом го има имплементирано в курса, явно са ясни за всички. Това също допринася за дестимулирането на курсистите. Също така, учи курсистите да не правят нещо много важно за ежедневната работа на всеки програмист - да си гугълват нещата. Наистина ще ми е трудно да намеря коментар на решение, в който 90 % от нещата не са googleable.

    Като цяло, стимулира хората да не бъдат проактивни.

    Един възможен контра-аргумент на това е "Важното е, че накрая са се научили как се прави, one way or another". Това не е валиден аргумент по много причини но основно, защото:

    Има значение как си се научил да правиш нещо. Да си проактивен е ужасно важно качество, особено в работата на програмистите, защото ако не успяваш сам да си намериш решенията, няма да успееш да се развиеш никога, а развитието е още по-essential специално в тази сфера. Освен това, ако важното е "да се научат в крайна сметка", съвсем възможен вариант е да се дава feedback-ът след крайния срок. Така пак ще се "научат хората", но няма да бъдат еднакво оценени с хората, които са се научили сами, което съответно ще елиминира горните две причини.

    Моите предложения са:

    • Feedback-ът да бъде много по-абстрактен, неконкретен, несъдържащ код, кратък и необхващаш всички проблеми в решението. Пример: "Рекурсивното решение не е най-оптимално в случая, опитай с итеративно." или "Не са спазени неща от style guide-a.". Примери за "лош" (според моето предложение) feedback: "new_head.zip(direction).map {|element| element.inject(:+)} e overkill. Искаше просто [x1 + y1, x2 + y2]" или "можеш да пренапишеш not on_snake and not on_food and not out_of_bounds като not(on_snake or on_food or out_of_bounds)". Като цяло, не трябва да представлява "Този ред от кода ти е грешен. Напиши го ей така.", а по-скоро "Концепцията/идеята ти за това не е правилна, пробвай с тази другата".

    • Feedback-ът да се дава след крайния срок. Вече го описах това, възможно е да е пак индивидуален, както и "общи проблеми от решенията" на презентация.

    • Feedback-ът да "струва" нещо. Примерно, ако искаш да получиш feedback по-рано, трябва да дадеш 1 точка. Ако искаш още след това, още една. Или просто да се отнемат точки, ако оригиналното решение е имало много неправилни неща и изисква дълъг feedback. Последното е по-скоро не за предпочитане, защото пък е стимул хората да предават в последния момент, за да не им вземат точка преди това.

    • No feedback.

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

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

    И отново, това не е тема с цел "не ме кефи това", а е тема с цел дискусия. Още повече, тема с цел някой да ме убеди в противното е.

  2. Сашо, дал си чудесна обратна връзка за обратната връзка. Коментарът ти засили дискусията, която имаме в екипа по темата. Имаме мнение, което ще споделим в някакъв скорошен момент.

    Благодаря ти, че повдигна въпроса. Stay tuned.

  3. Точно коментарите по изразяването на определен ред са ми най-полезни, защото без supervision по-често ще пиша на C# в Ruby syntax (дори и да отговарям на всичко в style guide-а). Трябва да се излезе от комфорт зоната. Да се каже - "тука го пишем по друг начин". Още повече, като тези промени не променят резултата в автоматичните тестове накрая, а това изглежда е основна грижа.

    Освен това идеята, че имаш някакъв гръб дава ценно спокойствие.

    За коментарите след крайния срок - популярността им ще спадне рязко. Аз като съм уморен мога да си ги погледна 'утре', защото не ги бързаме. (но това си е мой личен проблем)

    Иначе и без тях може. Задачите са описани достатъчно ясно. spec-овете също са страхотен бонус. Очевидно е, че коментарите излизат скъпо. Разбираемо е ако не си струват усилията на екипа.

    Disclaimer: От тук надолу няма нищо конструктивно

    Конкретно по изписаното:

    Не искам да казвам, че курсистите са мързеливи, но го казвам. Не се прави така. Това въобще не ме кефи.

    Пример за същия вид изявление (paralipsis): Не казвам, че gamification-а е единствената мотивация за отваряне на темата във форума, но имай в предвид, че това не е zero-sum game и cooperation-а е по-разумното поведение.

  4. "Точно коментарите по изразяването на определен ред са ми най-полезни"

    Не споря, че няма полза в коментарите като идея. Казвам, че текущата им реализация не е правилна.

    "Трябва да се излезе от комфорт зоната. Да се каже - "тука го пишем по друг начин"."

    Така е, прав си, трябва да излезеш от комфорт зоната. Което включва да отвориш нов таб в браузъра и да прочетеш как се прави, вместо да разчиташ, че някой "така или иначе" ще ти каже накрая.

    "Освен това идеята, че имаш някакъв гръб дава ценно спокойствие."

    Също така да кажем на всички, че накрая ще имат шестици ще им даде "ценно спокойствие". Не вярвам, обаче, да е полезно за някого. Спокойствието ти не трябва да е абсолютно никакъв фактор.

    "За коментарите след крайния срок - популярността им ще спадне рязко."

    В това няма логика. Мотивацията на хората би трябвало да е абсолютно същата, каквато е и сега - да ги прочетат, за да пишат по-качествен код и да бъдат оценявани по-високо. Даже напротив, нищо не те мотивира повече, отколкото "2/10 точки" крещящи в лицето ти "не можеш да пишеш код".

    "Иначе и без тях може."

    Може. Както може и без лекции изобщо. И без презентации. И без отговори във форума. И без курс, като цяло. Има достатъчно информация в Интернет. Идеята на курса не е че "иначе не може", а че е полезно.

    "Не искам да казвам, че курсистите са мързеливи, но го казвам. Не се прави така. Това въобще не ме кефи."

    Това, че си прочел статия на английски за нещо, не означава, че го разбираш. Това, за което се говори в статията, е споменаване на факт/събитие "между другото". Пример за това е: Няма да споменавам факта, че си против това хората да се борят за точки и против изказванията ми за мързела, а същевременно твърдиш, че ако не ти зависят точките ДИРЕКТНО от това, не би си направил усилиието дори да прочетеш коментарите, а просто ще продължа нататък:

    "Не казвам, че gamification-а е единствената мотивация за отваряне на темата във форума, но имай в предвид, че това не е zero-sum game и cooperation-а е по-разумното поведение."

    Тия произволно избрани термини на английски от Гугъл... Не, не е zero-sum game, за това си прав. Това не променя факта, че точките са относителни, съответно колкото повече точки имаш ти, толкова по-малко "струват" моите. И не, не е това единствената ми мотивация за отварянето на темата, няма нужда от предположения. Ако само за това ми пукаше, щях да прекарам това време в нещо друго по-продуктивно, което би ми донесло точки.

  5. Окей. Задача 2 е оценена. Нека видим какъв е най-"успешният" метод за получаване на максимален брой на точки. Да разгледаме решението с най-много точки:

    http://fmi.ruby.bg/tasks/2/solutions/84

    Забелязваме големи разлики между първия изпратен код и последния. Хмм, странно. Поглеждаме по-надолу и забелязваме, че има няколко коментара, които буквално му обясняват как да си направи решението от "лошо" на "много добро". Доста конкретно, при това. Той, естествено, изпълнява това (не го виня, и аз бих). Резултатът е максимален брой точки и 2 БОНУС (!) точки.

    Първо, че това е изключително нечестно към всеки един друг, който си е решил сам решението.

    Второ, че следващата седмица, аз, като един човек, който иска да има много точки, ще направя същото - ще постна каквото и да е решение, ще наспамя форума с "не сте ми проверили решението, моля, проверете го" и ще следвам стъпките. Както би направил и всеки разумен човек, който иска да има хубава оценка. Само че това ще доведе до факта, че никой от курса накрая няма да знае как да си напише сам кода както трябва.

    Дори не го разбирам. Защо просто не оцените решението такова, каквото е било ПРЕДИ промените, които сте предложили? Абсолютно има логика, това е неговото решение. Това, което е след вашите предложения, не е.

    Така ли ще е и на тестовете? Предаваме тестовете и "5ти въпрос не ти е верен, помисли дали случайно В не е вярно."?

    Разбирам, че това "се обсъжда". Разбирам да се обсъжда дали да вземате точки на хора, на които сте им помогнали... но да давате бонус точки на хора, които са следвали вашите стъпки за решението... Еми по-добре просто напишете стъпките за вашето решение и който ги изпълни правилно - максимален резултат. За мен това си е абсолютно преписване, което не само не е санкционирано, ами даже е поощрявано в курса.

    Когато беше просто "пишете също толкова точки на хора, на които сте помогнали" беше неокей, но приемливо някак. Но "пишете БОНУС точки на хора, на които почти собственоръчно сте написали решението" е крайно недопустимо за един курс, който иска да твърди, че има обективно оценяване.

    Друга е темата, че това НЕ е решение за максимален брой точки. Това е решение, което ползва O(N2) памет, за да намери едно свободно поле. За функция, която БИ ТРЯБВАЛО да използва О(1) памет. Решение, което най-вероятно ще отнема минути при размери по-големи от 1000.

  6. @Екипа, това, което сте направили, е нечестно към останалите. Александър е прав и се съмнявам, че е единствения с подобно мнение. Хората все пак се учат като грешат.

    Надявам се до времето когато пуснете задача 4 да има решение на проблема :)

    P.S малко rant относно оценяването: На миналогодишното издание на курса по Go (за тези които не знаят - екипите на 2та курса са kinda related) например имах почти пълния набор точки на проекта си (колегата напрегна очите си за да ми отнеме 3 точки за стил), но заради няколко пропуснати домашни имах 4ка. Не гоня стипендия :D, но какво оценяваме в крайна сметка - крайния резултат на студента или това дали след 8 часа работа сяда да пише домашни по всичките си изборни дисциплини.

  7. Това е малко по-различна тема. Принципно съм съгласен за това, конкретно за този курс не съм, защото:

    В началото беше споменато, че този курс е направен И за "немотивирани хора, които имат нужда някой активно да ги стимулира, за да станат добри". Абсолютно това, което предлагаш, би било по-честно и по-справедливо и аргументът, че "без домашни, някои хора няма да имат стимул за развитие" е невалиден от гледна точка на справедливост и обективност на оценяването. Обаче, когато курсът е направен и с идеята да научи "немотивирани хора как да пишат хубав код", нещата стават спорни, защото от една страна имаш "необективността" на оценяването на това "дали след 8 часа работа някой е седнал да си напише домашните", от друга страна имаш факта, че това е доста essential за мотивацията на някои хора (които са таргети на курса).

  8. Иха, вълнувам се! :satisfied: Форумите се превръщат точно в това, за което са замислени. Моля ви, не спирайте да повдигате такива въпроси и да ги дискутирате. Това са неща, които водят до реални подобрения в курса.

    @Александър Дражев, идваш ли на лекции? Ако да, моля те, ела и ни кажи здрасти около някоя от лекциите, да си кажем пет приказки очи в очи :)

    Сега по темата – Александре, прав си и от екипа сме съгласни с теб за примера с бонус точките.

    Тези бонус точки не са представителни за това как смятаме да даваме бонус точки, или как ще процедираме с коментарите по задачите в курса. По-долу обяснявам какво ще прилагаме от тук нататък за това. За текущата ситуация, грешката е наша, но вече сме я направили и ще живеем (и ние, и вие) с нея.

    Коментарите

    Коментари на задачи ще продължим да оставяме, но ще са по-редки, по-абстрактни и по-кратки.

    Съгласен съм с теб за необходимостта от по-общи и кратки коментари и с това, че на места сме били твърде конкретни и на практика сме отнели възможността авторът да си намери сам решението. Ще коментираме решения, ако студенти поискат преглед от нас, или ако преценим, че коментарът ще е педагогически полезен на дадено място.

    Ако курсът започваше сега, на първа и втора задача вероятно щяхме да даваме и малко по-подробни коментари, според случая. Поне на първа задача пак щяхме да оставим коментари на всички решения.

    Причината за това е, че нивото на всички е много различно и докато някои от вас вече работят, или имат история на дългогодишни състезатели, за други този курс е първият по-сериозен сблъсък с такъв тип програмиране, а понякога и дори с по-съществено писане на код като цяло. Понякога има и проблеми с мотивацията – хора, които са на ръба да се обезсърчат и да се откажат от университета или от занаята като цяло, заради отношението на преподаватели, заради курсове, които им се струват невъзможно сложни, заради това, че много хора около тях изглежда да са със светлинни години напред, или други причини. Аз не искам да изпусна такива хора и искам да им дам още един шанс. Искам да видят, че може да има и друго отношение, че има кой да ги насочи и да им помогне, ако се чувстват затрудени, че е окей да се признае, че нещо не е ясно и да се пита за помощ, че не е задължително във втори курс да имаш вече две години стаж и осем медала от състезания и че ако положат усилие в правиланта посока, имат всички шансове да успеят. Това означава коментари на всички в началото, понякога означава и по-детайлни и конкретни коментари.

    Смятам, че масовите и по-детайлни коментари в началото (първа и частично втора задача) ще помогнат с ангажирането на студентите с курса и с даване на достатъчно увереност, че могат да се справят. За задачите по-натам променяме тази практика и ще помагаме избирателно или при поискване, за да се избегне описаната от теб опасност хората да спрат да полагат усилия и да чакат обратна връзка, за да получат подобрения наготово.

    Добри и лоши решения

    Няма да ползваме бонус точки само за да маркираме добри решения. Ще пробваме нова практика – да пускаме нещо като преглед на добри и лоши моменти от решения в нещо като статия, която ще пускаме във форумите след като е изтекъл срокът на дадена задача. Нещо като компилация от по-детайлните коментари, които има в момента на предните две задачи.

    Със сигурност ще пробваме това при четвърта задача. Дали ще стане и за трета задача е все още под въпрос.

    Бонус точки

    Ще даваме бонус точки за положени значителни усилия и постигнати големи подобрения в кода, или за елегантни решения, които са достигнати без съществена помощ от наша страна.

    Допълнително, може да даваме бонус точки дори и ако финалният код не е достигнал "елегантния" вид, който гоним, ако преценим, че човекът е положил достатъчно усилия към момента и искаме да възнаградим тези усилия, за да стимулираме да ги полага и занапред.

    Някои от тези практики определено могат да доведат до обезценяване на точки в глобален мащаб, но би трябвало да е по-скоро незначително, а и класацията с точките в сайта не е основата на този курс. Искаме да стимулираме някак мисъл, труд, да дадем увереност и да постигнем подобрение у вас и сме готови да платим за това с известна точкова инфлация.

    Отнемане на точки

    На първа задача не сме и няма да отнемаме точки.

    На втора задача отнемаме точки за груби нарушения в конвенцията.

    От трета задача натам ще продължим да отнемаме точки, при това нарастващ брой, за сериозни нарушения в конвенцията (например, идентиране с табове), или силно неидиоматичен код (разбирайте, процедурно писане, стил Фортран и подобни), особено пък ако сме предупредили преди това в коментар, че има проблем.

    Алгоритмична сложност

    В този курс не се фокусираме върху алгоритмичната сложност на кода. Повечето проблеми, които се решават с Ruby, не са алгоритмично-тежки или математически сложни. Проблемите обикновено са свързани с моделиране на някаква бизнес логика, където е важно кодът да работи правилно, да е семпъл, кратък, ясен и изчистен. Лесен за разбиране, поддръжка и разширение. Затова и се опитваме да предадем идеята за "елегантни" решения, следващи стила на Ruby, които определено не са непременно най-алгоритмично оптимални.

    В примера със змията, за едно от елегантните решения на проблема с намирането на нова храна приемаме точно това с Array#product. Проблемът, който се решава тук, е змия и кодът ни никога няма да има нужда да работи с полета с размер хиляди на хиляди. Вярно е, че твоето решение е по-оптимално, но е микрооптимизация за нашия use case. Микрооптимизациите са неща, които често просто усложняват кода излишно.

    Оценяване в края на курса

    @Стояне, kinda related сме с Go, но не сме същите хора :) Реално екипите са изцяло различни. Ето малко мисли за оценяването, които отразяват моето лично мнение, но мисля, че и другите от екипа мислят като мен (ще ме поправят, ако не е така :)).

    Нека приемем, че дойдеш на защитата с перфектен проект, но домашните и тестовете са ти зле (липсват, или имаш много малко точки там). Виждам два възможни сценария:

    1. В началото на курса си бил много зле, просто защото не си имал достатъчно опит. Било ти е много трудно и часовете след лекции и оставащи от други домашни и ангажименти не са ти стигали, за да напреднеш достатъчно бързо. До края на курса, обаче, си усвоил тънките моменти на Ruby и си задобрял доста в занаята – дотам, че да дойдеш с перфектен проект. Е, в този случай бих дал освен пълен брой точки за проекта (60) и още 10 или 20, или дори повече (според случая), за да пиша отличен. Защото резултатът е постигнат и са положени огромни усилия да се постигне този резултат и реално човекът е стигнал от нула до максимум. Заслужена оценка.
    2. Вече владееш Ruby добре, но не си отделял достатъчно време по време на курса, за да правиш домашни и да учиш за тестове. Защо? Може би схващаш по-бързо от другите, или пък имаш повече опит от тях (примерно защото работиш от доста време) и ти върви по-лесно. При всяко положение, си стигнал до същия резултат накрая. Похвално, това е една от основните цели. Но не си положил същото количество усилия. Нужно ли е това? Ако просто се справяш по-бързо от другите, защо трябва да губиш повече време? Не, не е нужно, разбира се. Но е нужно да си положил минималното количество усилия и по време на курса, за да покриеш критериите ни, които сме дефинирали предварително. Ако систематично не си имал време да покриваш тези критерии, защото работиш на осем часа, те разбирам. Много е трудно да си на пълен работен ден и да следваш редовна форма. Някои хора и само с работа на пълен работен ден се чувстват достатъчно източщени. Но трябва да ти напомня, че в повечето случаи, това да работиш на пълен работен ден, си е твой личен избор. Ако ти и други хора зависите финансово от твоята работа, смятам, че в тази сфера би могъл да си намериш и работа на по-малко часове, с която да се издържаш, или пък да платиш цената на това, че в края на годината ще имаш четворка, а не шестица.

Трябва да сте влезли в системата, за да може да отговаряте на теми.