Взял на свою голову стажёра для проекта.
Я был готов, что он ничего не знает и что его нужно обучать. Думал, что запасся терпением.
Первые дня два, он внимательно слушал и спрашивал. Показал ему, что такое HTML, CSS, PHP, MySQL.
Попросил его сделать выполнить простые задачи, небольшие функции. Но каждый раз наступаем на те же грабли. Он не хочет вникать в мануал.
Когда в результатах поиска, я ему посоветовал использовать регулярки, и прочитать про них. Он двух минут не задержался, пошёл писать. Ну я думал, что он понял. А он переписал функцию preg_replace() на свой лад. Полсотни линий кода и 4 часа работы. Я вник в задание и сделал с регулярками в 1 строку и за 5 минут.
Постоянно одно и то же. Чтение значений из файла, которые располагаются через запятую, он мудрил с поиском совпадений вычитанием лишнего, копировании данных и вычислении позиции символа. Минут 20 доказывал мне, что нельзя сделать проще. За 2 минуты, я нашёл в мануале strtok($string, $token), позволяет вытянуть слово, до определённого токена.
И в этой же задаче, передаются две переменные, которые могут содержать 2 из 5 типов. При том каждый тип, либо начинается с особого символа, либо имеет определённую длину. Его код состоял из серий if-else в несколько этажей, в итоге на 250 линий и 2 дня работы. С помощью strncmp($string1, $string2, $length) я уместил в 12 линий и 4 минуты в том числе на поиск функции.
Я понимаю, что у него меньше опыта. Может я неправильно что-то объясняю? Неужели так сложно спросить меня, или Гугл как сделать? Поделитесь опытом, как его поставить на правильный путь?
Нет, нужен был технарь, и были, но не адекватные.
То замкнутые — каждое слово нужно вытягивать на собеседовании.
То гики — в каких то манга-маечках.
То безграмотные — куча ошыибок в резюме, да и в речи.
То гоповатые — на ты сразу и со всеми, и по их словам, это они ведущие проектов Опера, Windows итд.
Хотел взять молчуна, хороший писало, но шеф настоял на активном.
И вот расхлёбываю
Вы как-то описали в основном свойства, не имеющие отношения к профессиональной компетенции. Ну, то есть, я могу предположить, что гоповатый тип вряд ли будет хорошим программистом, безграмотный, возможно, тоже, про остальных же ничего не могу сказать.
Я думаю, что регулярки он не понял, из-за того, что ето совсем другая для него вселенная. Ведь посмотрите на это реально, он новичёк, он хотел справиться с задачей => хорошо! НО!!! Если бы вы ему дали «лёгкий» мануал по автоматам и гарматикам, он бы понял, что такое preg_функции. К сожалению я думаю, что preg_функции нельзя хотеть от новичков сразу, там надо немного вникнуть в проблему. ;-)
Да и вообще, я в ВУЗе автоматы 2 года подряд сдавал, так что знаю, что это за хрень.
Может он себя плохо чувствует, давление, итд?.. Обясните ему, что у него много времени, и что програмированние, это 60% поиска, 30% мозговой активности и 10 написания кода… Я думаю, что главное, чтобы старался!
Мне вспомнились эти же самые цифры из другого контекста :)
В какой-то книге по садоводству автор писал, что по его наблюдениям, у горе-садоводов-любителей лишь 10% усилий направлены непосредственно на результат, 30% против результата и 60% — на борьбу с теми 30-ю.
Имхо это плохое соотношение. Раньше тоже думал, что все уже решено до нас и если ошибка какая-то сходу не решалась, то сразу начинал гуглить. Именно это и расслабляет и разжижает мозг. Человек разучивается (или вообще не обучается) мыслить аналитически, распутывать проблему самому, а всегда лезет в гугол. Зачастую проблема лежит на поверхности и нужно лишь чуть повнимательнее ее рассмотреть и если гугол ответ не выдает, то все стопорится.
«Первые дня два, он внимательно слушал и спрашивал. Показал ему, что такое HTML, CSS, PHP, MySQL.» О.о Дайте ему штуки три книги, две недели времени и пусть сидит дома читает, через две недели проверьке как в школе что он прочитал, и если все читал исправно дальше работайте с ним, это Ваше «обучение» выйдет боком!
Не не, дайте ему обычную русскую книгу, чтоб он попорядку прочитал все от корки до корки. В наше время люди считают себя очень умными, и не читая литературы рвутся в бой, узнав про переменные и циклы думают что умеют программировать. Нужно именно заставить прочитать пару книг, русских дайте, дайте ему время, и обьясняйте что будет спрашивать по книгам.
если ваш подопечный не знает английского, то можно смело гнать его в шею. Вам нужен умный программист в будущем или просто раб для написания простейших функций?
Спрашивать по главе через день — это какой-то бред, прошу прощения. Чай, не в бирюльки играем. Однако дать ему книжки на русском — это хорошая мысль.
Я думаю, что вы всё правильно делаете уже сейчас. И ваш пост — это просто необходимость выпустить пар. Да, поначалу он будет писать плохой код, но если вы будете ему объяснять другие подходы, то будучи вменяемым он постепенно освоится и будет делать рациональнее. И плюс показывайте ему куски вашего реального кода и обсуждайте (точнее, пусть сам вопросы ставит, только отвечайте). Я думаю, это неплохая стратегия.
Собственно самым эффективным всегда был удар по зарплате. Если нет возможности ввести штрафы за говнокод и перерасход времени на бред, то я бы попробовал затащить его на пиво и в непринужденной обстановке выведать что к чему, попытаться переубедить ( или просто заинтересовать в написании нормального кода, хотя бы на «слабо» ), ну и если необучаемый, то на воздух.
Если стажер работает меньше 3-х месяцев, то у вас отличный стажер.
Главное уметь решать задачи. А как это делать эффективнее придет с опытом. Я например очень страдаю от того, что вместо решений в лоб, те же 4 часа сижу и думаю как написать за 5 минут в 1 строчку.
(Есть шанс, что вы взяли «не того» стажера. Судя по вашим комментариям выше я понял что опыт в программировании у него 0. И дело не в наличии/отсутсвии «опыта работы», а в том, что человек которому интересно этим заниматься — часто пишет программы «для себя». «Сильный интерес» — это одно из главных слагаемых успеха, а самостоятельно написанные хобби-программы — как раз признак наличия интереса.)
Как с ним работать (особенно хорошо если сроков жестких нет)
Cформулировать задание (желательно связанное с программированием, а не с изменением width:200px на wiidth 300px в css файле) (скорей всего на первых порах оно будет связано с процедурным программированием), попросить подумать над решением и (т.к. опыт 0) и записать его своими словами на листе бумаги/в текстовом файле в виде словесного описания алгоритма.
Как будет готов — вы просматриваете что он придумал. В этот момент вы сможете увидеть места в которых он пытается реализовать билиотечные функции и для этих мест посоветуете ему ознакомиться с соответсвующей документацией. Кроме того если в этот момент вы видите что получается ерунда, можно или наводящими вопросами подвести его к правильной мысли. Или если вопрос достаточно сложен — предложить свой вараинт и спросить что он по этому поводу думает: достоинства-недостатки-что-лучше.
Как только оно алгоритм скорректирован — ему останется просто, пользуясь словарём, перевести с одного языка на другой.
Когда с процедурным стилем будет получаться лучше — пришло время ознакомить его со стандартами кодирования принятыми в компании (Очень хорошо если они будут без глупостей и фанатизма).
ООП. Если вы уверены что у вас правильное ООП и оно вам действительно нужно, то «когда придёт время», то предварительно пусть ознакомится с принципами SOLID и основами UML (диаграммы классов, объектов, последовательностей) — этом поможет вам обсуждать архитектурные решения. А дальше тоже самое: формулируется задание. Он его обдумывает, рассазывает как решил делать декомпозицию и почему. Вы предлагаете свой вариант. Всё это обсуждается опираясь на принципы SOLID.
Вот примерно так. Не позволяем себе высокомерия и фразочек вроде «чему вас только в институте учат» и «ну кто так пишет», не забываем хвалить когда он всё делает правильно.
но, повторюсь, главное — чтобы он сам этого хотел. Если это есть — то успевай ему только книжки новые выдавать и задачи придумывать.
Ещё, мне кажется, стажёр может просто не успевать за темпом изменений задач. В этом топике он писал тесты, делал рефакторинг, пользовался регулярными выражениями. Может стоит как-то более спокойно работать, не ставить задачу на-гора, а предлагать способ реализации (понимая, что человек с такой задачей сталкивается впервые).
Думаю, изобрести несколько велосипедов для опыта не помешает :) В конце-концов, тогда начинаешь лучше понимать, как примерно работают уже готовые решения, которые используешь.
А как научить использовать готовое — сложный вопрос. Главное здесь — подход мышления. Когда начинаешь что-то делать, сначала поищи, не реализовал ли этого кто-то для тебя? Ведь 99%, что реализовал :)
Какой у него опыт работы? Ранее, чем через 3 месяца после начала требовать чего-то от новичка не надо, его главное задача в это время учится, а не закрывать таски вовремя.
Так в чем проблема? Просто проводите ревизию его кода перед коммитом, если что-то не так — объясняете что и пусть переделывает, пока код не станет идеальным. Через некоторое время это должно дать результат, надо набраться терпения.
Ну и параллельно рассказать какие книжки почитать и какой код посмотреть на досуге, объяснив, что это в лучшую сторону повлияет на его профессиональный уровень (а, следовательно, и оклад).
Может он и не программист, раз после универа он из-под палки все делает? Обычно программисты хотя бы к концу обучения начинают что-то сами осваивать сверх подаваемой программы, когда понимают, что это оно. Если он просто сидел и списывал, то, имхо, вы взяли не того. Программистом нельзя заставить быть.
Ужас. Прошло то поколение, когда приходящий в универ человек уже успевал самостоятельно попробовать к тому моменту несколько ЯВУ и хотя бы парочку ассемблеров…
не подскажите сколько платят стажерам после универа?
сейчас работаю 2й год сисадмином, но говнокожу для себя на питоне и Qt.
написано пара проектов по учебе на Qt, диплом на питоне и проект для знакомого предпринимателя.
вот думаю перебраться в программирование, но хотелось бы знать на что рассчитывать по ЗП в начале пути ибо деньги нужны всем, за интерес не получится работать
смею надеяться что мой уровень чутка повыше описанного стажера))
В России, не подскажу. Во Франции если меньше 3х месяцев - то оплата не обязательна. Больше 3х - оплачивается минимум в 450 евро/мес. В крупынх фирмах от 800евро/мес
я думаю ничего не нужно вообще делать, пусть пишет полсотни строк вместо одной, главное чтобы задача решалась, а со временем придет и опыт и лень :) приободрите, включите в проект, только поддерживать эту часть оставьте его же, когда придет время что-то исправлять или дополнять, он сам все поймет.
а идеального кода не существует, кто сказал что вашу задачу в 1 строку нельзя решить за половину? или вообще переписать этот кусок чтобы ее не было? вариантов масса, дайте человеку думать самому и решать :)
Cогласен.
Автору топика: вы что, программу для АЭС пишете?!
Убейте в себе перфекциониста! Пусть пишет как хочет!
А чтобы было правильно — покройте программу тестами! Если тесты проходит — пусть хоть тысячу строк напишет — это будет правильно.
Я не хочу Вас обидеть, но посоветовать новичку регулярки использовать, это надо было догадаться.
А если конструктивно, то долбить, долбить и долбить, как правильно писать код. Парное программирование, код ревью и прочее. Повторение — мать учения.
Ну и книги какие-то вручить. Например, классический Code Complete.
Очень желаю Вам удачи. Выращивание кадров достойно уважения, не часто такое бывает.
Мда, про регулярки, я согласен. Но появились улучшения.
У него просто другой склад ума. Он думать не умеет, а не кодить. Просто поставленную задачу решает не думая.
Имхо, это беда многих новичков — браться за первое попавшееся решение без оценки последствий и без обдумывания альтернатив с их экспресс-оценкой подходимости. Со временем лечится. Если человек обучается, то бывает и быстро.
Знаете как нас учили на первом курсе? Давали задание и запрещали пользоваться конструкциями языка или функциями стандартной библиотеки (хотя многие их и так не знали), которые позволяли решить данную задачу за пару десятков строк кода. Потом препод на лекции показывал как можно решить проще. Плюса два: во-первых, начинаешь понимать как работают стандартные функции, а во-вторых, запиминаешь их, так как сам, фактически, их изобретал.
Нормально, нормально. Это пройдет.
Сейчас просто у него период эйфории — ух ты, я программы умею писать!
Сам таким был вначале.
Просто пока выбрасывайте весь его код.
Надо мягко пока показывать правильный (свой) код
и обсуждать с ним его.
Простите, какой у Вас стаж? Думаю больше чем полгода+время на опыт. Стажёр ещё не умеет набирать опыт. Не занет где искать и что искать. Обучайте этому.
Вопрос о мотивации очень сложный.
Метод кнута и пряника говорят очень интересная вещь.
Мне часто было все равно на деньги, меня больше интересовало мнение о моих творениях окружающих людей, более опытные программисты снижали мне мораль по полной говорили что я никчемный что я сделал все неправильно итп. Я очень расстраивался хотел часто забросить все, но на следующий день я обязательно садился и пробовал еще раз и пробовал и пробовал… пока не научился.
Человек просто не знает как можно сделать проще, я думаю что если бы он знал то перестал бы писать такое и начал бы пользоваться правильными функциями в нужных местах. Потому что это просто быстрее. Может быть стоит создать атмосферу того что «ААА мы ничего не успеваем», что бы заставить человека думать о том как сделать быстрее.
Главное это ему понять, что в любой задачи есть наиболее правильный путь для ее решения, и иногда стоит потратить время чтобы подумать и поискать этот путь, а не городить первое попавшее в голову решение «В лоб».
Может быть человек своим сознанием еще в университете, и ему лишь бы работало.
Вообще в вашей сютуации многое зависит от личных качеств человека, которые мы сидя тут по другую сторону монитора никак не можем оценить. А вы, думаю сможете найти подход к этому человеку.
>Может быть стоит создать атмосферу того что «ААА мы ничего не успеваем»
Часто это именно это заставляет решать задачу «в лоб» — путь решения видишь, время +- оценить можешь, а вот искать готовое (и не факт, что найдёшь), разбираться в нём, адаптировать — сложно делать какие-либо прогнозы. Особенно если было несколько неудачных попыток.
Может быть стоит создать атмосферу того что «ААА мы ничего не успеваем»
По моему нескромному опыту, работать в условиях цейтнота — это не более просто, а наоборот, намного сложнее.
Когда, даже умея проектировать архитектурно правильный код, сознательно делаешь некрасивый (но работающий), который при этом будет реализован более быстро; но при этом обставляешь его красными флажками, чтобы знать, как его исправить с «некрасивого работающего» на «красивый работающий», когда будет время. Когда сознательно бьёшь себя по рукам наподобие «тут бы надо сразу отрефакторить и сделать честный model-view, но, блин, некогда, нет, я сейчас не буду это трогать, сделаю страшненькими коллбэками, а потом исправлю».
Тут сразу много сложностей. Надо найти вариант, как это сделать красиво. Надо найти вариант, как это сделать пусть и некрасиво, но быстро. Надо модифицировать некрасивый вариант так, чтобы его можно было в будущем легко исправить в красивый. Надо написать некрасивый вариант, но при этом всеми способами обеспечить будущее исправление его (например, жирными метками TODO и чётким описанием, что же сделать потом). Надо всё это рассчитать так, чтобы «написать некрасивый вариант, но модифицируемый в красивый, и обвесить его метками TODO и рассказами» получилось всё-таки быстрее, чем сразу «написать красивый вариант». И в конце концов, код при этом должен работать.
Кстати, к написанию велосипедов склонны и опытные разработчики. Меня как-то просили реализовать очередь сообщений на чистом C без использования внешних библиотек. Конечно, можно учесть, что предназначалась разработка для umpc, но ведь интерфейсы они делали на обычном Qt (или wxWidgets, точно не помню, короче, самая обыкновенная библиотека). И не было интересно, что есть ZeroMQ, например.
Попробуйте говорить ему в какую сторону копать. Еще совсем недавно я публиковал топик, который наполовину, даже больше состоял из чистых костылей и говнокодинга (опыта у меня пока еще маловато, потому что сам стажер :) ). Люди в комментариях посоветовали куда копать и на что смотреть. Понял, посмотрел, попробовал запустить. Проблем с этим нет. Объясните ему, что уже все решения начального уровня давным-давно сделаны за него и пусть не пытается изобретать велосипед. На самом деле это не нужно… не здесь. Такой творческий подход нужен при решении задач, а не изобретении новых стандартов.
Интересная практика. Не думал, что в стажеры берут человека, абсолютно не знакомого с программированием. Вместе с тем, что уже было высказано, советую дать почитать собственно статьи про говнокод (на лурке неплохая) и посмотреть презентацию А.Солнцева «WTF Code» http://www.devclub.eu/2010/08/13/video-wtf-code/.
Объясните, что код надо не только писать, но и сопровождать, в конце концов.
Нужно учить, а вы не учите. У вас сейчас: дал задание, он решил плохо, я сделал хорошо, показал ему. А надо: дал задание, он решил плохо, я объяснил, почему плохо, отправил переделывать, и так, пока не станет приемлемо.
Написал свой preg_replace()? Покажите, почему это неправильно, отправьте переписывать. Опять плохо? Опять переписывать.
Не совсем. Дал задание, работает — а почему? И исправил пару неточностей, мелочи.
Когда не работает, то тот же почему, и объяснение, почему не так нужно делать. Хреновее всего, когда он понимает, что есть проще и что он сам мог додуматься. Но уже потратил свои 10 часов. И тяжко признать.
Пардон, заглянула в профиль и все стало ясно. В любом случае, терпения вам и внимания, если стажёру интересно программировать, то все придёт — с опытом, книжками и гуглом. Все когда-то были начинающими.
Когда я начал изучать программирование (начал с php), то, наверное, первый год я просто узнавал основы синтаксиса и принципов. Например, если написать unset($arr[23]); — что будет: все последующие индексы сместятся или будет дырка? А как, что бы не было дырки? Если в двойных кавычках все переменные заменяются на значения, то будут ли кавычки влиять на ф-цию date(«Y-m-d»)? А что делать, если мне надо дату разбить на две строки br-ом? А как «склеить» два числа: 1+2=12?
В общем, очень много базовых вопросов, которые в документациях явно не прописаны или описаны как-то завуалированно (в пхп не существует нумированных массивов, только ассоциированные!). На такие вопросы я очень много времени тратил в первый год. Базы данных даже не щупал — всё в файлах. Но тогда я программил для себя и понимал, что пока не сделаю самостоятельно несколько сайтов, устраиваться на работу — тупо. А вы хотите: первые дня два,… показал ему, что такое HTML, CSS, PHP, MySQL. Дня два не хватит даже что бы выбрать удобное IDE, а Вы ему 4 языка!
В итоге: либо не экономьте на программерах, либо платите мелкую з/п за то что он ничего не успевает. А этому прогеру надо сначала написать хотя бы пару сайтов для себя/друзей и только после этого уже просить за свою работу денег.
Удобное IDE для HTML, PHP, CSS? Notepad++. По моему чтобы ничего лишнего не было — достаточно.
Я никогда не программил на Джаве, а тем более под андроид. За 3 дня написал свою превую программу.
Я на программерах и не экономлю, я на времени экономлю. Процедура рекрутинга разная для этого. А стажёр получает 32 Т.Р.
Рано ему писать, пустите его на документирование уже имеющегося кода, пусть разбирается в текущих проектах и комментирует каждую нужную строчку, после 1-2х файлов проверяйте правильно ли разобрался.
Просто дайте ему новое задание и подождите пару недель. Потом дайте ему его же старый код, скажите «надо быстро, срочно, аггрх!» Меня самого таким образом научили давать понятные названия переменным, оформлять код, читать доки на предмет «как сделать вот это быстро и в две строчки» и писать комментарии (хотя бы в трудных местах). Правда, проект тот я запорол и пришлось начать с нуля :-)
>> Может я неправильно что-то объясняю?
Ага, более, чем наверняка;)
Но научить стажера более-менее приемлимому стилю как правило проще, чем изменить себя.
Но вообще сложно требовать от человека без опыта программирования сразу писать в хорошем стиле. Тут помогут документация, положительная и отрицательная мотивация, разговоры о жизни и о профессии, но основное — это опыт, приходящий со временем.
Прямо сейчас, видимо, есть смысл признать, что он не понимает, чего вы от него хотите. Возможно, есть смысл дать ему документ с четкими формулировками хорошего стиля типа:
— требования к форматированию
— требования к именованию переменных
— для таких-то алгоритмов и структур данных использовать стандартные реализации
Код написаный с нарушениями этого документа просто не принимать.
Можно также признать его необучаемым и выгнать, но судя по описанию процесса набора сотрудников есть большой шанс принять такого же.
у меня сложилось ощущение что он просто не знает о большинстве возможностей стандартной библиотеки языка, что приводит к самостоятельной реализации, что в свою очередь является одной из проблем. В этой ситуации «для таких-то алгоритмов… использовать стандартные реализации» равнозначно «использовать функции стандартной библиотеки языка» — но он их просто пока не знает и придумывает велосипед.
Хотя я как и вы подозреваю, что они взяли «не того»
Не поверите! Заставил его рефакторить большую часть кода (там есть и его вклад).
В ТЗ неправильно описали данные, и пришлось добавлять новую таблицу в БД, новые поля в некоторые таблицы, и добавлять constraints.
Свой читать код не всегда просто, а чужой, так вообще. Надеюсь ему на пользу пойдёт.
Ему 22, у него 3-ий курс. Получает стажёрскую ставку. В нашей фирме она чуть больше чем в других.
Сам в принципе хотел брать стажёра. Думал что чему-то научу, и чему-то научусь. Не думал что так будет сложно. Иду против пословицы: Взялся за гуж… Но тем не менее его уже не брошу, не мало времени потерял на него.
ключевой момент — это хочет ли стажёр разбираться или не хочет. если он хочет, пытается, но у него ничего не получается — это одно. ему надо помочь и учить. если он не хочет ни в чём разбираться, и пытается только лишь бы вы от него отвязались — это другое.
м мне кажется, что не стоит воображать себя учителем и пытаться учить. раз за 3 года его не научили — то и у вас вряд ли выйдет. учиться он должен сам, а вы скорее старший товарищ, у которого можно что-то спросить и который может подробно объяснить и рассказать.
наберется опыта до определенного уровня и будет использовать мануалы/ я до какого то момента костыли больше любил? но однажды что то в голове того и у меня поселился дома мануал =)
Для простоты в общении, представим, что я стажер и хочу понять, что же вы от меня хотите?
Я считаю что я очень многое уже умею, ведь могу из простых функций написать все, что угодно! Только требуется время, но вы ведь меня не ограничиваете во времени? Так ведь? так зачем мне спешить, мне пока интересно разбираться во всем этом. А как будет работать код мне пока не важно, Вы ведь не ограничиваете меня по размеру выделенной памяти или процессорному времени (/ещё чему-то?)
Тогда чем вы недовольны? я ведь пишу код который работает! Я крут!
Надеюсь, намеки просты и понятны.
[Поясню на всякий случай: совет «используй только джедаевские методы в одну команду» непонятен и неприменим. Давайте более точные ограничения, того. что вам _действительно_ нужно. Вы хотите просто код в одну строку, и вам не важно как он работает? Ставьте ограничение на размер кода. Вам нужен быстрый и легкий код? Проверяйте скорость выполнения кода, написанного им. Он пока не так ленив, как вы, чтобы полчаса искать команду, чтобы написать код за 5 минут, это приходит только с опытом, а ещё для этого нужно понимание условий и ограничений, которые Вы, к сожалению, не ставите...]
