Как заставить программиста писать код самостоятельно?
Сут такая, пришел новенький программист, без опыта работы, работает уже почти 3 месяца.
Решением его задач занимаются не новички и так постоянно, т.е. новичок сталкивается с проблемой, просит помочь решить его задачу, ему в деталях объясняют как сделать задачу, чтобы прийти к решению, он уходит в себя на несколько часов, потом рождает какие-то дикие нечитаемые костыли. После того, как ты ему говоришь, что твой код никуда не годится и почему же ты не использовал предложенное тебе решение от более опытных коллег, он говорит, что ничего из того, что ему предложили, он не понял и сделал так, как посчитал нужным. В итоге снова более опытные коллеги садятся вместе с ним и чуть ли не под диктовку рассказывают как решить задачу.
К слову, задачи очень простые, поправить какие-то условия в уже имеющемся коде, либо написать свое неочень сложное условие. Проект WinForms, очень простенький, нативный ADO.NET, ничего сверхсложного, все задачи гуглятся на ура, но человек просто не гуглит. Подскажите кто как справлялся с такой ситуацией
да скажите ему просто, что у вас тут не школа, и сопли подтирать за ним вы не собираетесь. Либо человек сам начинает мыслить и включать мозг, либо до свидания.
Зачем он вам такой нужен?
Толковый парень и на чужом коде научится - на примерах. А этот походу непробиваемый.
Денис Загаевский, собеседование чисто формальное, потому что новичку предлагают ЗП продавца, такая уж тут политика нашего отдела разработки, отсюда и вытекают такие новички..
Строго-настрого запретить остальным программистам тратить на него время. Он либо сам уволится, либо начальник, который его по своей наивности взял, его уволит.
Умение самостоятельно учиться - ключевое для программиста, если у него его нет, то это не ваша забота его пытаться выработать у уже взрослого человека (возможность этого вообще сомнительна).
1. Просто перестаньте отвечать на вопросы. Именно так в свое время научили меня (сослались на занятость).
2. Понятие "какие-то дикие нечитаемые костыли" - это субъективное понятие. Может быть художник так видит? :)
А может быть все аксакалы ошибаются и он единственный приводит верное решение?
Тут надо либо аргументацию приводить с отсылкой на отраслевые или внутриорганизационные стандарты, либо уволить нафиг если не готовы его учить.
костыли... чуть изменишь условия и спицы из колеса с треском вылетают.
нечитаемые - код часто бывает даже без пробелов. Проговариваем чуть ли не каждый день как элементарные правила читаемости кода, так и внутриорганизационные стандарты, это разве не готовность учить?)
Денис Загаевский, чаще чем может показаться.
Зачастую профессионалы исповедуют какую то зарекомендовавшую себя философию/культуру/технолгию и мыслят в рамках уже опробованных шаблонов. В то время как новичeк может мыслить вне рамок этих шаблонов. И если дать такому человеку чуточку свободы, то можно получать неожиданный профит.
nubic, нечитаемый код элементарно лечится сугубо техническими методами. например, на одной из моих работ было невозможно закомитить код, не соответствующий принятому код-стайлу; на другой весь код при комите принудительно прогонялся через форматировщик.
но, обычно, если чел не способен писать читаемый код изначально, он не способен и на многое другое.
DevMan, насчёт изначально - а откуда его отсчитывать?) У меня одногруппник на первом курсе код лесенкой писал - каждая строка с отступом 4 пробела. Потом переучился, МГУ с красным дипломом закончил;)
Денис Загаевский, красный диплом ни о чем не говорит. на тостере есть как минимум один бедолага с таким, который никуда не может себя пристроить и периодически постить жалобные вопросы по этому поводу.
код в первую очередь пишется для себя, потом для других. нравится человеку пялится в месиво на экране и он может в нем разобраться? да не вопрос: если он справляется со своими задачами, мы сами отформатируем его код. но за 20 лет практики я встречал только одного человека, месиво которого стоило внимания.
nubic, реформат кода автоматические решается разными способами в зависимости от языка, в том числе можно запретить коммитить не соответствующий стилям, если есть набор правил конечно
Ребят, стандартизация кода это мега важно, но на мой взгляд ключевое слово у топикстартера - "костыли". Видимо речь о культуре разработки в целом.
Сама верстка лечится легко: стандарт + автоформатеры + легкий кодревью. А вот научить человека не переопределять для разных целей одну и туже переменную или не делать SELECT * в переменную типа запись с фиксированным количеством полей или почему надо создавать индексы на поля внешних ключей - это надо учить: объяснять последствия и говорить как их избежать.
И тут ключевой вопрос в том, видишь ли ты как руководитель, смысл тратить свое время на данного персонажа или тебе проще уволить его к чертям и взять уже обученного.
Лично для меня, ключевым моментом при принятии решения "учить или казнить" всегда являлось то как человек относится к работе. Если он добросовестный, понимает что много не знает и хочет вырасти как специалист, то я тратил на него свое время, если нет - досвидос. Это правило старюсь применять и сейчас, когда непосредственно разработкой уже не занимаюсь. Считаю, что людям надо давать шанс как в свое время его дали мне.
Денис Загаевский, вы мне напомнили анекдот.
то, что кто–то смог никак не означает, что смогут и все другие.
ponaehal, так и есть. но судя по вопросу, человек необучаем.
руководителю нужно не только смотреть на человека и его способности, но и учитывать его психологию: не только лишь все способны работать в команде.
Денис Загаевский, я на него отетил: код пишется для себя в первую очередь. если чел не способен это уяснить, он необучаем. а некоторые срут в штаны всю свою жизнь до самого её окончания.
Простой
Сложный
