Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

Студентов, которые еще не доучились на работу не брать! Пусть доучатся.
Для студента/выпускника:
— посмотреть успеваемость в университете, тему дипломной работы. Попросить рассказать чем он занимался в университете, каких успехов достиг. Если студент учился "на отлично" в пристижном университете и имеет пару статей в журналах, то скорее всего он будет показывать хорошие результаты и на работе. Главное его заинтересовать.
— дать несколько тестов на логику, проверить мышление.
— предложить поработать некоторое время на должности тестировщика или программиста авто тестирования.

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

Здравствуйте, franz, Вы писали:

F>Студентов, которые еще не доучились на работу не брать! Пусть доучатся.
Есть такая старая, но мудрая фраза, что учиться надо всю жизнь. Когда же считать, что он доучился?

F>Для студента/выпускника:
F>- посмотреть успеваемость в университете, тему дипломной работы.
Успеваемость не говорит ни о чем. Тема диплома говорит еще меньше — за красивыми темами иногда такое скрывается — просто кошмар.

F>Попросить рассказать чем он занимался в университете, каких успехов достиг.
Какие "успехи" могут быть у студента? Задача студента — получать фундамент и учиться учиться. "Успехом" в получении фундамента может быть что? Наверное, только если докажет какую-нибудь теорему, которую 200 лет доказать не могли.

F>Если студент учился "на отлично" в пристижном университете
Категорически нет. Даже если перед Вами выпускник MIT.

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

F>- предложить поработать некоторое время на должности тестировщика или программиста авто тестирования.
И если согласится — то не брать, ибо либо идиот, либо закомплексованный. Не уверен, по по-моему это еще и Трудовому Кодексу противоречит.

Здравствуйте, Она На Нас Ий, Вы писали:

TG>>а по теме вспомнил интересную статистику по кибернетическим кафедрам лучших вузов москвы ( хотя думаю в МГУ и МФТИ дела обстоят лучше, но тоже не все идеально). Так вот из 50-60 человек, сдающих различные лабы(в тои числе и домашки) в виде программ (хотя более уместно называть их прогами, до уровня настоящих программ явно такие поделки не тянут) реально все сами пишут только 3-6 человек, остальные просто копируют с мелкими изменениями.

ОНН>Т.е. 3-6 человек коряво "изобретают велосипед", не смущаясь и не отвлекаясь на всякие там книжки, накопленный опыт, вылизанные десятилетиями patterns
ОНН>А остальные учатся тому, как должно быть, т.е. качественному Rapid Application Development (RAD) c использованию best practices — копипастят, а может даже и генерируют, вылизанные куски кода (в соответствии с определенными best practices)
Я с тебя просто балдею.
Ты в школе то же все домашние задания списывал?
И объяснял это обучением Rapid Application Development'у?

Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.

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

А для того чтобы сгенерировать код нужно сначала на DSL написать то из чего его будут генерировать.
А для этого нужно сначала сделать DSL.
А сделать DSL это задачка не для копипастеров.
Да и далеко не весь код можно генерить.

ЖМ>>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).
ОНН>Это просто неправильно распланированный проект. В планы любого проекта должны закладываться риски и обучение ... а для средних и больших проектов — расширение-набор и обучение нулевых "студентов", предварительное изучение (если не разработка) общих стилей, принятых в компании
ОНН>Я думаю, что даже, если собирать в новую команду одних гуру, то всё равно нужно время на разработку, изучение и привыкание к общим стилям и стандартам. Тоже работа "замедляется"
Гуру договорятся за несколько дней.
А в фразе на которую ты отвечаешь говорят о людях которые вобще не способны что-то сделать. Те на них можно потратить хоть год времени, а пользы не будет.

Здравствуйте, VovkaMorkovka, Вы писали:

VM>Тестовое задание, причем, чтоб было не обидно такое, которое ты не сможешь потом продать
VM>Например игра, на любом ЯП.Срок — неделя.Сделал — точно бери, ибо умеет педалить, а паттерны, красивый код и тп приходят только с опытом.

У такого подхода есть одна проблема: если не сделал, то точно не брать? Так можно упустить потенциально толкового студента только потому, что он где-то "тупит".

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

Здравствуйте, жертва мехмата, Вы писали:

BZ>>>ошибка здесь. нельзя бросать человека в воду, чтоб он научился плавать. надо увеличивать размер ответственности постепенно. комиттить только после ревью, объяснять что к чему. там и видно будет — кто способен учиться, а кто нет

ЖМ>Мы это понимаем, так и стараемся делать, но часто этого не получается. Бывает срочность, бывают нечеловеческие объемы в короткий срок и ревью приходится откладывать. Приходится включать в сборку их творчество и отдавать в проверку. Потому что версия нужна и именно сегодня.

ЖМ>Кто способен учиться, кто нет — это мы видим через некоторое время, но уже немного поздно. Все-таки он уже у нас побывал и внес свою ложку дерьма.

чисто не там, где убирают, а там, где не гадят. я например физически не способен закомиттить код без комментариев, без рефакторинга, с мусором и т.п.

и вам надо чисто физически принять для себя, что эти ребята не пишут код. они учатся его писать и главное зачем вы даёте им задания — чтобы потом отревьюить. чтобы они эти каракули вообще как код не воспринимали. поскольку если он его смог закомиттить, оно прошло в продукцию — он и будет воспринимать себя программистом, которому занудные дядьки какой-то фигнёй надоедают. ведь работает же! т.е. с самого начала надо развивать правильные рефлексы, как у котёнка которого ТУТ ЖЕ нужно тыкать в сделанную им лужу

и ещё можете попробовать дать им на сопровождение код, сделанный их предшественниками. я сейчас имею такое счастье — a,b,bb,x,xx... и для контраста — написанный вами. пусть почуствуют the difference

вообще, вы ставите вопрос как отбирать, а я хочу сказать, что вуз не готовит промышленного, профессионального программиста. там же программированием занимаются год от силы. ну освоят они основные понятия программовоания и всё. даже человек, который не смог разобраться с деревьями (!!!), получит троечку и будет считаться программистом. учить их реальной работе вам придётся самим. так что отбирать по блеску в глазах и IQ. вот правильная идея — спросить что читал по программированию помимо учебной программы. большинство наверно ничего и не читают, максимум — одну-две книги

Здравствуйте, denisko, Вы писали:

WH>>Даже не знаю как на этот вопрос можно цензурно ответить.
D>А нецензурно? Что плохого в использовании красивых зарекомендовавших себя методов, грабли которых относительно известны?
В том, что большинство из них нужны раз в пятилетку. А попытки использовать их везде, где только можно, приводят к overdesign'у.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>1. "бойтесь человека, прочитавшего одну книгу"
BZ>2. чтение не заменяет опыт работы. это как бы шаблон по которому нужно дальше набивать руку

Вы правы, но мы же вроде говорили о начале карьеры, когда речь не идет об опыте.

BZ>3. проведи опрос в своём вузе — сколько народу изучило хотя бы только упомянутое тобой

К сожалению, учусь не на программиста, поэтому вряд ли получится. Но если бы была возможность, провел бы обязательно.

BZ>4. ... при том, что это ещё далеко не полный список

BZ>так что ты напрасно кипятишься. сначала определись хотя бы, говорим ли мы о среднестатистическом студенте (который, я уверен, ни rsdn, ни по-английски не читает) или тебе лично

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

>>Мне кажется, что смысл фразы "знать программирование" у нормального студента и у вас, вполне совпадает.

BZ>в этих 4 пунктах я озвучил требования исключительно к бывшему студенту, который перестал гадить и наконец стал приносить хоть какую-то прибыль своей фирме (что тут же приводит к требованию повысить зарплату раза в 1.5-2 ). к ведущему требования гораздо меньше — он должен решать проблемы

Ну, я тоже имел в виду "не гадящего" студента, а не Mr. Wolf'а из Pulp Fiction .

Я вот почему это все пишу — в последнее время все чаще и чаще замечаю, с каким неудовольствием работодатели нанимают на работу студентов. Их отношение варьируется от "we could always build more killbots" (всмысле — "всегда можем нанять этих недотёп") до "да ну их нафиг, они все тупые". Но посмотрите на это все со стороны студента — брать на работу не хотят, нет опыта, чтобы приобрести опыт, надо устроиться на работу. Вы можете возразить, что вы с радостью, вот только если он основ не знает, зачем он нужен. И будете правы. Вот только паренек может не знать, каких основ вы от него хотите. Звучит смешно конечно, но если вспомнить, что в нашей стране (и в вашей, я из Харькова) такого понятия как CS не существует, то не так уж и смешно. Так вот, после интервью с очередным "недотепой", ненадо говорить "спасибо, поржал", "о господи, он даже такого не знал", "ну и студенты пошли", а надо рассказать человеку, что и как, почему он провалился, чего он не знает, что ему надо выучить. Глядишь выучит и прийдет второй раз.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Наша организация принимает на работу людей с опытом профессионального программирования и студентов/выпускников, не имеющих опыта.
ЖМ>Большинство из них через несколько месяцев мы можем воспитать до уровня "надо постоянно следить и заставлять переделывать", КПД немного выше нуля. Некоторые, проявив исключительное желание научиться, становятся через годик пригодными к полноценной самостоятельной работе на наших проектах. Совсем редкие вырастают до очень хороших специалистов. Но некоторые из приходящих совершенно безнадежны. И даже через полгода воспитания — нельзя на их работу смотреть без слез. Пищут код курам на смех (зато хорошо умеют присылать смайлики в аське).

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

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Здравствуйте, denisko, Вы писали:

ЖМ> "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать.

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

Студента надо окучивать. Работать с ним, напрявлять. Очень просто объяснять ему что нужно сделать. Впрочем, очень просто объяснять нужно всем. Объяснять сложные вещи просто дано только настоящим профессионалам. Туманнее всего объясняют те, кто вопроса не понимает.

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

Если студент не задает вопросов тогда это плохо. Или плохой студент или плохой наставник.


Сам вот редкого экземпляра выращиваю, sound programmerа. Вроде получается Тьфу x3. Это как панд разводить.

Здравствуйте, жертва мехмата, Вы писали:

1. Сократить список требований до минимума. Дикий список требований выдает нерадивого работодателя или HR. 3-4 пункта оптимально, если есть возможность то меньше. Большой список отпугивает соискателей, особенно умных и толковых, проффесионалов в одной области. Но привлекает эникейщиков-одноневок.
2. Простой тест на алгоритмику.
3. Выяснить насколько человеку интерестна предметная область. Есть ли "врожденные" склонности. Пускай расскажет про себя. Когда Хлестакова понесет, он расскажет на расслабоне много интерестного.
4. Боже упаси вопросы типа "Чему равна константа WM_PAINT" или "Какой по дефолту размер стека в Виндоус". Соискатель сразу поймет что собеседующий лох и/или жмотина, но никак не профессионал.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Мы это понимаем, так и стараемся делать, но часто этого не получается. Бывает срочность, бывают нечеловеческие объемы в короткий срок и ревью приходится откладывать. Приходится включать в сборку их творчество и отдавать в проверку. Потому что версия нужна и именно сегодня.
Это абсолютно неправильно — брать студенческие поделки в реальные проекты. IMHO, такое выйдет себе дороже.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?".

Выглядит как попытка "зачморить" студента и показать, какие вы там все в конторе крутые.

ЖМ>Начинаются сочинения на свободную тему

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

ЖМ>хорошо поржать можно.

И очень зря.

ЖМ>Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?
Давным давно меня просто предупредили, что нужно будет поначалу тупо править HTML, но что меня попробуют научить чему-то большему. Научили

Дело в том, что те студенты, что в состоянии ответить на "глупые" вопросы точно и четко, причем без возмущения этими "глупыми" вопросами — обычно уже вполне сложившиеся профессионалы.

Здравствуйте, SE, Вы писали:

SE>Я, например, вижу людей, понимающих важность комментирования коммитов, реже чем солнечное затмение

ИМХО, все буквально понимают важность комментариев к коммитам, просто не все умеют в одной строчке выразить смысл изменений, которые в коде занимают несколько тысяч строк.

Здравствуйте, _Jane_, Вы писали:

_J_>Здравствуйте, ASolovey, Вы писали:

AS>>Так что думаю это тоже подход. Можно и на работе применить.

_J_>Я кстати и применяю. на рабочих-учебных задачах.

Одно только уточнение — подход такой же как в первом моем посте:
Программа сломана. Точка. Что именно не так — найди сам.
А не так, что у тебя там-то и там-то то-то и то-то не обрабатывается и не работает.
Все! Жестко! Заставляет либо сдаться, либо вылизывать до блеска, до звона. Чтобы нигде, ни полбайта не поскочило! А потом уже в привычку входит.

P.S. Я после таких экспериментов бывало находил ошибки в программе во сне. Спишь, снится код, ходишь мысленно по нему дебаггером, условия вариьируешь — потом в поту просыпаешься — вот же оно!
Раз к компу — смотришь — точняк! Но это конечно в самых тяжелых случаях...

Здравствуйте, жертва мехмата, Вы писали:

В программировании есть только три вещи, понимание которых отличает программиста от непрограммиста. Это:

1. Рекурсия.
2. Указатели.
3. Биты.

Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

Здравствуйте, Lloyd, Вы писали:

L>Причем тут распределенные VCS?

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

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

Моя статистика, в которой у меня нет оснований сомневаться, говорит мне, что на группу в 30 студентов:
* 0-2 -- годятся в программисты
* 5-10 -- годятся во вспомогательные рабочие (тестеры, сисадмины, техписатели)
* прочие годятся только чтобы торговать телефонами в киоске

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

Решил вот добавить свои пять копеек.

Я тоже когда-то был студентом. И уже тогда считал себя офигенным программистом.
Но мои представления о программировании развеял в пыль мой первый босс.
За что я ему безмерно благодарен.
У него был очень простой подход — давал задание, кстати поначалу это были именно заморочки с чужим кодом. Очень помогает. Есть возможность посмотреть как другие люди делают и спросить — это круто или г@вно. И на своей шкуре понять, почему код в дряном стиле, каментов и весь замороченный это плохо.
Да, но вернемся к подходу. Давал он задание и ставил срок. Я ему отдавал код. А он мне в ответ писал: у тебя в программе столько то ошибок. И все. И делай что хочешь но найди их САМ и исправь. И никогда не говорил что именно не так. При ходилось биться об экран чтобы понять что еще не так. Результат — через какое-то время я был отпущен в самостоятельное плавание. Т.е. просто он перестал находить в том, что и писал, значимые недочеты. У меня не было другого выхода. Либо сделай, либо уйди.

Вот такой жесткий подход IMHO учит людей самостоятельности и приводит к отсеву. И unit тесты делать, и код читабельный писать, и каменты и тд. Просто человеческий мозг так устроен, что он ищет самый простой вариант. Если самый простой — это зачекинить без каментов какую-нибудь дрянь, а потом старшие товарищи соберутся и начнут объяснять — где и что не так, то так оно всегда и будет.
А если самый простой и единственный сделать все как следует самому, то те кто это может и ХОЧЕТ сделать — научатся и сделают, кто-то быстрее, кто-то медленнее, а кто не может или НЕ ХОЧЕТ — уйдет сам, т.к. просто не будет справляться с работой.

Здравствуйте, жертва мехмата, Вы писали:

TG>а по теме вспомнил интересную статистику по кибернетическим кафедрам лучших вузов москвы ( хотя думаю в МГУ и МФТИ дела обстоят лучше, но тоже не все идеально). Так вот из 50-60 человек, сдающих различные лабы(в тои числе и домашки) в виде программ (хотя более уместно называть их прогами, до уровня настоящих программ явно такие поделки не тянут) реально все сами пишут только 3-6 человек, остальные просто копируют с мелкими изменениями.

Т.е. 3-6 человек коряво "изобретают велосипед", не смущаясь и не отвлекаясь на всякие там книжки, накопленный опыт, вылизанные десятилетиями patterns
А остальные учатся тому, как должно быть, т.е. качественному Rapid Application Development (RAD) c использованию best practices — копипастят, а может даже и генерируют, вылизанные куски кода (в соответствии с определенными best practices)

ЖМ>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).

Это просто неправильно распланированный проект. В планы любого проекта должны закладываться риски и обучение ... а для средних и больших проектов — расширение-набор и обучение нулевых "студентов", предварительное изучение (если не разработка) общих стилей, принятых в компании
Я думаю, что даже, если собирать в новую команду одних гуру, то всё равно нужно время на разработку, изучение и привыкание к общим стилям и стандартам. Тоже работа "замедляется"

Здравствуйте, VovkaMorkovka, Вы писали:

VM>Ну только тестовое задание, имхо, если чел способен на последнем курсе за неделю написать хорошую версию игрушки а -

а если он на первом курсе написал архиватор — то такого сразу пристрелить шоб не мучался

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?

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

И, почему в ОБЩЕРОССИЙСКИЙ КЛАССИФИКАТОР ПРОФЕССИЙ РАБОЧИХ, ДОЛЖНОСТЕЙ СЛУЖАЩИХ И ТАРИФНЫХ РАЗРЯДОВ — нет ни одной профессии или специальности со слогом "аналитик"?

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Программы, которые им давались для развития, через некоторое время превращались в помойку.

ошибка здесь. нельзя бросать человека в воду, чтоб он научился плавать. надо увеличивать размер ответственности постепенно. комиттить только после ревью, объяснять что к чему. там и видно будет — кто способен учиться, а кто нет

Здравствуйте, ASolovey, Вы писали:

AS>>>Так что думаю это тоже подход. Можно и на работе применить.
_J_>>Я кстати и применяю. на рабочих-учебных задачах.

AS>Одно только уточнение — подход такой же как в первом моем посте:
AS>Программа сломана. Точка. Что именно не так — найди сам.
AS>А не так, что у тебя там-то и там-то то-то и то-то не обрабатывается и не работает.
AS>Все! Жестко! Заставляет либо сдаться, либо вылизывать до блеска, до звона. Чтобы нигде, ни полбайта не поскочило! А потом уже в привычку входит.

Пишу как тестер обычно или даже как клиент, то есть не настолько конкретно и чётко. "найди сам, где не работает", по-моему, сильно жестоко

AS>P.S. Я после таких экспериментов бывало находил ошибки в программе во сне. Спишь, снится код, ходишь мысленно по нему дебаггером, условия вариьируешь — потом в поту просыпаешься — вот же оно!
AS>Раз к компу — смотришь — точняк! Но это конечно в самых тяжелых случаях...

Здравствуйте, EM, Вы писали:

EM>1. назвать 2-х любых своих национальных писателей (одного могут назвать, вдруг они про Шекспира смотрели голливудское кино)
EM>2. когда была вторая мировая война.

EM>Ответы вас сильно удивят

Часто приходилось наблюдать при покупках в небольших магазинах, там, где зачастую обслуживает сам владелец и его жена, например, при покупке газеты, что для вычисления размера сдачи владелец идёт метров за 20-50 к калькулятору, а при нескольких айтемз начинает на глазах потеть за калькулятором
Ну, неинтересно челу была арифметика, что не помешало ему открыть своё дело и преуспевать в нём.
По поводу офисного планктона — у меня нет сомнений, что работать там намного комфортнее и эффективнее, создаёт большее юлагосостояние и качество жизни.
А для взятия интегралов всегда есть очередь из иммигрантов,считающих своих нанимателей недообразованными и тупыми

Cyberax пишет:
>
> D>А нецензурно? Что плохого в использовании красивых зарекомендовавших
> себя методов, грабли которых относительно известны?
> В том, что большинство из них нужны раз в пятилетку. А попытки
> использовать их везде, где только можно, приводят к overdesign'у.
Где логика? Здесь говорят про использование паттернов, но нигде не
говорят, что их нужно пихать всегда и везде.
Тем ни менее, я все больше убеждаюсь в том, что знание, хотя бы с
большего, паттернов проектирования — действительно необходимость. Ну
зачем изобретать собственный велосипед с квадратными колесами, если в
данном месте прекрасно кладется какой-нибудь паттерн.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Наша организация принимает на работу людей с опытом профессионального программирования и студентов/выпускников, не имеющих опыта.
ЖМ>Про первых не говорю, там вариант совершенно отдельный. Вторых — естественно на соответствующие роли и с соответствующими привилегиями. Большинство из них через несколько месяцев мы можем воспитать до уровня "надо постоянно следить и заставлять переделывать", КПД немного выше нуля. Некоторые, проявив исключительное желание научиться, становятся через годик пригодными к полноценной самостоятельной работе на наших проектах. Совсем редкие вырастают до очень хороших специалистов. Но некоторые из приходящих совершенно безнадежны. И даже через полгода воспитания — нельзя на их работу смотреть без слез. Пищут код курам на смех (зато хорошо умеют присылать смайлики в аське).

ЖМ>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).
ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

А не поделитель секретом, что за организация?

а по теме вспомнил интересную статистику по кибернетическим кафедрам лучших вузов москвы ( хотя думаю в МГУ и МФТИ дела обстоят лучше, но тоже не все идеально). Так вот из 50-60 человек, сдающих различные лабы(в тои числе и домашки) в виде программ (хотя более уместно называть их прогами, до уровня настоящих программ явно такие поделки не тянут) реально все сами пишут только 3-6 человек, остальные просто копируют с мелкими изменениями.

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

Здравствуйте, BokiyIS, Вы писали:

BIS>Я вот почему это все пишу — в последнее время все чаще и чаще замечаю, с каким неудовольствием работодатели нанимают на работу студентов. Их отношение варьируется от "we could always build more killbots" (всмысле — "всегда можем нанять этих недотёп") до "да ну их нафиг, они все тупые". Но посмотрите на это все со стороны студента — брать на работу не хотят, нет опыта, чтобы приобрести опыт, надо устроиться на работу. Вы можете возразить, что вы с радостью, вот только если он основ не знает, зачем он нужен. И будете правы. Вот только паренек может не знать, каких основ вы от него хотите. Звучит смешно конечно, но если вспомнить, что в нашей стране (и в вашей, я из Харькова) такого понятия как CS не существует, то не так уж и смешно. Так вот, после интервью с очередным "недотепой", ненадо говорить "спасибо, поржал", "о господи, он даже такого не знал", "ну и студенты пошли", а надо рассказать человеку, что и как, почему он провалился, чего он не знает, что ему надо выучить. Глядишь выучит и прийдет второй раз.

а зачем работодателю смотреть с вашей стороны? ему деньги нужны, а не благотворительность

посмотри сам — человек считает себя программистом, но при этом не то что ничего не знает — не знает даже что он должен знать! и даже не догадывается где спросить об этом!!! при этом он уже требует денег, поскольку он "5 лет учился". он не знаком ни с технологией программирования, ни с технологиями, у него не было "производственной практики", в течении которой он должен был набить свою порцию шишек не за счёт компании. наконец, "вкладывание в будущее" тоже не очень работает — поскольку обучившись (за счёт компании!) человек требует повышения зарплаты до уровня middle-level программиста, которого за те же деньги можно сразу было бы нанять

Здравствуйте, Miroff, Вы писали:

M>ИМХО, все буквально понимают важность комментариев к коммитам, просто не все умеют в одной строчке выразить смысл изменений, которые в коде занимают несколько тысяч строк.

ты коммит с ежемесячным отчётом часом не путаешь?

Здравствуйте, Lloyd, Вы писали:

WH>>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
WH>>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.
L>Почему?
Даже не знаю как на этот вопрос можно цензурно ответить.

Здравствуйте, gandjustas, Вы писали:

G>Функционально мышление не связано с пониманием указателей.
G>В чистом ФП вообще другой уровень абстракции, там указателями и не пахнет.

Это уже потом оно становится не связано, когда понятно как оно работает. Хотя это, в принципе, можно проскочить, точнее прийти к этим абстрациям другими способами. Я не верю, что люди, владеющие ФП. не способны понять фундаментальные вещи типа указателей на функции. Могут не знать, т.к. не надо было, но чтобы не были способны понять, не верю. Если же такие найдутся, то сразу в отсев, знают они ФП или нет уже не важно.

Да и нет там никакого такого "другого" уровня абстракции. Набор паттернов. Всё упирается опять же в способ объяснения. Мне доводилось объяснять что такое карринг человеку, хорошо владеющему указателями на функции, за две минуты в метро под стук колёс и толкотню пассажиров. Ещё три минуты до этого было потрачено на объяснение замыканий. Его реакция была примерно такая — "И это всё? Ясно."

G>Точно, на ассемблере еще вместе писали. Ну нет у некоторых людей абстрактного мышления.

Нет по простой причине. Чтобы абстрагироваться от чего-то нужно то, от чего мы будем абстрагироваться. Если этого нет (нет понимания этого), то и абстрактного мышления не будет. Другими словами, переход к абстракции не делается через пустоту. Даже изучение матиматики начинается не с обстрактного x * y, а с конкретного 2 * 2.

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

Здравствуйте, LordMAD, Вы писали:

LMA>Да и какой вывод делать, если это ему удастся очень или не очень хорошо? Оценить так можно лишь его общечеловеческие качества, но никак не программистские. С тем же успехом можете предложить его помещения убирать...

Надо понимать, что для студента это первое место работы. Он должен начится работать в коллективе, соблюдать корпоративные правила. Гений программирования может быть и не полезен корпорации, а наооборот приносить убытки.
За время испытательного срока студенту надо дать:
— ознакомится с системой, например по-средствам функционального тестирования. Протестировать некую ф-ть по спецификации, которую ему потом придется модифицировать
— написать небольшой участок кода, который не влияет на ф-ть всей системы. Это могут быть юнит тесты или ф-ть пока не входящая в состав продукта
— привлекать его к участию в митингах между программистами
— снабдить полезной литературой, например описанием сторонних API

Что вы кстати подразумеваете под программистскими качествами?

LMA>А по Трудовому Кодексу, вроде, работодатель должен содействовать профессиональному росту сотрудников, не наоборот.
А какой у него до это у него был рост, если это его первое место работы??
У него и трудовой-то не должно быть

ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?"
Главный критерий такого теста -- чтобы человек мыслил с нами( я и мой соподельник) на одной волне. Проверяем чтобы
1) человек знал и любил "нужные книжки" — любил Рихтера, банду, пристально относился к кнуту, восхищался графоманией Хайкина, читал хотябы Юрова с Гуком по процессорам и.т.д.
2) имел конкретную большую СВОЮ задачу, которую он хотел бы решить, но пока не может. Может даже ждет от нас помощи. Я или соподельник очень часто идем навстречу ребятам и тратим свое время, чтобы помочь решить ИХ задачи.
3) поглощал бы информацию в своей области, мог относится к ней со здоровой долей стеба.
4) имел бы чувство юмора.
Если 1)-4) выполняется обычно мы срабатываемся с человеком и он работает на нас с довольно большой отдачей.

ЖМ>Насчет пункта 1 — это для нас не пофиг. Успешное существование компании может обеспечить не только качество софта с точки зрения юзера, но и качество софта с точки зрения программиста. Это и есть наша "этика и эстетика", не так ли?.
Вполне вероятно что ваша этика и эстетика такова. Мне приходится читать код
1) С 40-летнего гуру написанный для DSP
2) C# обычного человека с другого проекта
3) ++ эстетсвующего питераса, начитавшегося таких же питерасов
4) ++ остроумного раздолбая, но насквозь проникнутые стебом надо мной
5) Javу некоторого очень странного типа
6) ++ человека молящегося на хаскелл
7) кальку с матлаба
+ кучу код различных полутоновых личостей. Перестройка переходит за 5-7 минут и никаких сложностей не вызывает. Более того, наиболее остроумные приемы я(и даже соподельник который страше меня на 20 лет) перенимаем и с удовольствием использую.
В самых запущенных случаях, когда полностью готов функционал вместе садимся пишем строгую спецификацию как должно быть и человек переделывает. Довольно вдумчиво и без аврала. В дальнейшем на это закладывает определенное время.
Насчет затупов и конструкторов -- надо понимать, что человек пишет свой первый код и тыркается во многие места в поисках решения. Если бы он уничтожал все свои тырки перед тем как сделать следующий код писался бы с бесконечно малой скоростью.

ЖМ>Насчет пункта номер три — с нами этот номер не проходит
Тут я за вас только рад. В последнее время процент таких людей довольно высок. Причем как среди профей так и среди студентов.

Здравствуйте, жертва мехмата, Вы писали:


Тестовое задание, причем, чтоб было не обидно такое, которое ты не сможешь потом продать
Например игра, на любом ЯП.Срок — неделя.Сделал — точно бери, ибо умеет педалить, а паттерны, красивый код и тп приходят только с опытом.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Наша организация принимает на работу людей с опытом профессионального программирования и студентов/выпускников, не имеющих опыта.
ЖМ>Про первых не говорю, там вариант совершенно отдельный. Вторых — естественно на соответствующие роли и с соответствующими привилегиями. Большинство из них через несколько месяцев мы можем воспитать до уровня "надо постоянно следить и заставлять переделывать", КПД немного выше нуля. Некоторые, проявив исключительное желание научиться, становятся через годик пригодными к полноценной самостоятельной работе на наших проектах. Совсем редкие вырастают до очень хороших специалистов. Но некоторые из приходящих совершенно безнадежны. И даже через полгода воспитания — нельзя на их работу смотреть без слез. Пищут код курам на смех (зато хорошо умеют присылать смайлики в аське).

ЖМ>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).
ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

Я бы ставил вопрос так: как обнаружить талантливых

Здравствуйте, PKz, Вы писали:

PKz>1. А когда вы были студентом, вы знали ответ на вопрос "чем занимается аналитик?"?
PKz>2. Сколько нужно времени среднестатистическому студенту, чтобы узнать чем занимается аналитик.

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

Здравствуйте, Cyberax, Вы писали:

C>В том, что большинство из них нужны раз в пятилетку. А попытки использовать их везде, где только можно, приводят к overdesign'у.
Так это проблема зашоренности тех, кто эти паттерны использует, а не паттернов как таковых. У меня этих паттернов просто на каждом шагу — паттерн это любое полезное решение, которое можно повторно использовать, зная его плюсы и минусы.
Гофовских с фаулеровскими паттернов среди них очень мало, таки да в силу их овердизайна, но вот стратегии, темплейт методы и чуть реже фабрики, просто на каждом шагу приходится имплементить, иначе б я на этом индусском коде свихнулся бы.
Хотя может это у меня проект такой.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?


Как человек, получающий руками, в том числе и, студентов определенные деньги рассказать об опыте правда небольшом
С чем я сталкивался:
1) Пишется нормальный рабочий код, который ужасен только с точки зрения этики и эстетики. Вводятся минимальные правила кодирования( с рсдна, например), дается четкая спецификация или(если задача в принципе может быть нерешаемой) четкий интерфейс вход-выход, задача разбивается на максимальное число этапов и студент или группа оных варится в собственном соку. На выходе каждого этапа жесткое тестирование до блеска.
2) Пишется что-то совсем страшное, которое не подходит с точки зрения производительности/архитектуры/...., но есть желание учиться и получать кайф от работы. Самых трудных удавалось отсеить тестом на эрудированность. Но если не удавалось -- заставлял читать определенные книжки. Детей в них что-то цепляло и начинали понимать что зачем. И все сводилось к 1). А на 1) пофиг, ибо это уже субъективное.
3) Нет ничего кроме желания использовать тебя как Большую Молочную Сиську(С) какой-то умный человек. ХЗ что с ними делать, самых явных мы на собеседовании отсеивали, а остальные либо отсеивались по другим причинам, либо просто не приходили. Но пока повезло, что с ними работать не приходилось.

_Jane_ пишет:
>
>
> На собеседовании это сделать невозможно, но увидеть через 1-2 месяца —
> вполне. И мы не пускаем студентов сразу в разработку — это может очень
> плохо кончиться. Поподробнее могу в личку написать, если интересно.
А вот представьте проект в котором большинство подобных студентов. И,
он, этот проект даже живет неплохо и развивается и в сроки укладывается.
Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
наберешься.

P.S. А вот с проблемой на собеседовании не увидеть уровня человека — ни
разу не сталкивался, когда сам собеседовал. Просто меньше задачек
заковыристых задавать надо, а больше слушать собеседующихся — все сами
расскажут, что знают, что могут и как могут.

Здравствуйте, Она На Нас Ий, Вы писали:

ОНН>все, почему-то интегралам учились в школе, а не неизбежным житейским навыкам (типа сесть вокруг стола) — не научены с детства

Это да, английское образование выпускает хорошо надрессированный офисный планктон. И за столом умеют сидеть и галстуки носят с 5 лет.
Но не стоит и нас ругать — у нашего образования тоже плюсы есть — я например не слышал, чтобы в Росии на вопрос "кто такой Сталин" отвечали "Первый черный президент США".
А над Черчиллем уже поглумились

ЗЫ кто не верит, что их действительно так учат предлагаю отловить знакомого буржуя и задать 2 вопроса:

1. назвать 2-х любых своих национальных писателей (одного могут назвать, вдруг они про Шекспира смотрели голливудское кино)
2. когда была вторая мировая война.

Ответы вас сильно удивят

Здравствуйте, BokiyIS, Вы писали:

BIS>Вы говорите про студентов которые вообще не знают программирования или про всех. Просто по вашим словам получается,
BIS>что большинство какие-то бездари. Меня, как студента, это немного задевает . Извините, пожалуйста, за оффтопик.

видишь ли, под "знать программирование" мы понимаем несколько разные вещи. ты можешь написать небольшой алгоритм. а нужно писать большую программу с определённой архитектурой, соблюдая стандарты кодирования: комментирование, тестирование, ясная структура и т.д. вас этому не учат, даже не говорят, что знание паскаля и деревьев — это ещё не умение программировать на реальной раюоте

у меня были два таких студента. no comments (в смысле комментариев не писали), no architecture — вообще не могдли держать в голове те части программы, которые за пределами экрана. расширение функциональности делалось методом cut-n-paste. это, думаю, самые средние выпускники местного техвуза где-то после года или двух работы. один из них был талантлив, другой нет. но технологией программирования оба не владели, да и откуда собственно. в наших вузах о таких вещах и не подозревали никогда

ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров?

Боюсь, что нет . Я видел только 2 рабочих варианта подбора нормальных студентов без опыта работы:
1. "Внедряется" свой студент с задачей подтянуть в компанию вменяемых сокурсников.
2. "Внедряется" свой молодой лектор/семинарист с задачей определить вменяемых ребят и предложить им работу.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?

Вот хочу спросить.
1. А когда вы были студентом, вы знали ответ на вопрос "чем занимается аналитик?"?
2. Сколько нужно времени среднестатистическому студенту, чтобы узнать чем занимается аналитик.

Кстати, а чем у вас занимается аналитик?

Здравствуйте, WolfHound, Вы писали:

WH>>>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
WH>>>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.
L>>Почему?
WH>Даже не знаю как на этот вопрос можно цензурно ответить.

Ну ответь нецензурно. Просто интересно, что такого преступного в паттернах?

Здравствуйте, Vzhyk, Вы писали:

>> На собеседовании это сделать невозможно, но увидеть через 1-2 месяца —
>> вполне. И мы не пускаем студентов сразу в разработку — это может очень
>> плохо кончиться. Поподробнее могу в личку написать, если интересно.
V>А вот представьте проект в котором большинство подобных студентов. И,
V>он, этот проект даже живет неплохо и развивается и в сроки укладывается.
V>Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
V>наберешься.

Я более чем уверена, что в этом проекте хорошо поставлено руководство этими студентами, контроль и так далее. То есть, не самотёк.

V>P.S. А вот с проблемой на собеседовании не увидеть уровня человека — ни
V>разу не сталкивался, когда сам собеседовал. Просто меньше задачек
V>заковыристых задавать надо, а больше слушать собеседующихся — все сами
V>расскажут, что знают, что могут и как могут.

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

Здравствуйте, WolfHound, Вы писали:

ОНН>>Т.е. 3-6 человек коряво "изобретают велосипед", не смущаясь и не отвлекаясь на всякие там книжки, накопленный опыт, вылизанные десятилетиями patterns
ОНН>>А остальные учатся тому, как должно быть, т.е. качественному Rapid Application Development (RAD) c использованию best practices — копипастят, а может даже и генерируют, вылизанные куски кода (в соответствии с определенными best practices)
WH>Я с тебя просто балдею.
WH>Ты в школе то же все домашние задания списывал?
WH>И объяснял это обучением Rapid Application Development'у?

Вы знаете у меня сын учился некоторое время в неславянской школе, в ЕС, когда я там жил.
Я тоже балдел от того, что, школьные задания, как домой (а домой задавали очень редко, наверное, там считали, что в учебное время — надо учиться, а в неучебное время — не учиться), так и в "рабочее время (т.е. в классе)" задания им задают не per student, а на группу и один из группы — ответственный — сдаёт или отчитывается за всю группу. А, как они организуют это — выберут одного, кто это сделает или решат задачки вместе — методом голосования, это было их делом, учителю в голову не приходило это выяснять, оценка ставилась группе и, соответственно, всем членам та же.
И, сидели они не по 2 за столом, а группами — по 4-6 человек за столом, и не "за", а "вокруг" стола. Припоминается мне, что когда я туда захаживал, то там, кажется, даже стола не было в классе у учителя

Если Вам не дано понять то, что Ваша логика бытия — не единственная, и предположить, что Вы живете и судите не по самым лучшим догмам, и, более чем вероятно, что другим удобно и более эффективно делать по другомк, то мне Вас, а прежде всего Ваших окружающих искренне жаль. А, то у нас грамотных — много, а вот даже неграмотных, умеющих работать в команде и иметь навыки прислушаться друг к другу — днём с огнём не сыщешь:
все, почему-то интегралам учились в школе, а не неизбежным житейским навыкам (типа сесть вокруг стола) — не научены с детства

А в мои школярские годы, когда я учился писать, то я СПИСЫВАЛ из учебника палочки и галочки целыми тетрадями. И, только потом, научившись тому, что было написано в учебнике, я что-то там пытался писать своими буквами и словами.
А. надо было сразу выдумывать мои собственные буквы, шрифты и фонты моей собственной рукописи?

Здравствуйте, Она На Нас Ий, Вы писали:

Кроме демагогии есть что сказать?

Например: как мне сгенерировать код SQL'ной базы данных с мультимастер репликацией?
Готовых нет.
А мультимастер репликацию очень хочется.

Гусары молчать! Я сам знаю что удар ниже пояса.

ОНН>А, как они организуют это — выберут одного, кто это сделает или решат задачки вместе — методом голосования, это было их делом, учителю в голову не приходило это выяснять, оценка ставилась группе и, соответственно, всем членам та же.
Сюр.
В этом случае все сделает один.
А остальные останутся пробками.

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

ОНН>А, то у нас грамотных — много, а вот даже неграмотных, умеющих работать в команде и иметь навыки прислушаться друг к другу — днём с огнём не сыщешь: все, почему-то интегралам учились в школе, а не неизбежным житейским навыкам (типа сесть вокруг стола) — не научены с детства
У нас тут несколько сотен грамотных. Есть конечно несколько неуживчивых но остальные легко договариваются.

Здравствуйте, EM, Вы писали:

E>>пример из реального кода, как увидел такой, меня чуть кондратий не хватил, писал такое мегаархитектор с 15 годами опыта и 20 000 баксов в месяц зарплатой ):

EM>Это где такие зарплаты? Назовите хотя бы страну, дальше я сам !!!

Газпром

Наша организация принимает на работу людей с опытом профессионального программирования и студентов/выпускников, не имеющих опыта.
Про первых не говорю, там вариант совершенно отдельный. Вторых — естественно на соответствующие роли и с соответствующими привилегиями. Большинство из них через несколько месяцев мы можем воспитать до уровня "надо постоянно следить и заставлять переделывать", КПД немного выше нуля. Некоторые, проявив исключительное желание научиться, становятся через годик пригодными к полноценной самостоятельной работе на наших проектах. Совсем редкие вырастают до очень хороших специалистов. Но некоторые из приходящих совершенно безнадежны. И даже через полгода воспитания — нельзя на их работу смотреть без слез. Пищут код курам на смех (зато хорошо умеют присылать смайлики в аське).

Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).
Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров?

Джоэл тоже берет на работу много студентов, читай «The Guerrilla Guide to Interviewing», «Hitting the High Notes» и у него еще много чего на эту тему.

Здравствуйте, denisko, Вы писали:


D>Как человек, получающий руками, в том числе и, студентов определенные деньги рассказать об опыте правда небольшом
D>С чем я сталкивался:
D>1) Пишется нормальный рабочий код, который ужасен только с точки зрения этики и эстетики. Вводятся минимальные правила кодирования( с рсдна, например), дается четкая спецификация или(если задача в принципе может быть нерешаемой) четкий интерфейс вход-выход, задача разбивается на максимальное число этапов и студент или группа оных варится в собственном соку. На выходе каждого этапа жесткое тестирование до блеска.
D>2) Пишется что-то совсем страшное, которое не подходит с точки зрения производительности/архитектуры/...., но есть желание учиться и получать кайф от работы. Самых трудных удавалось отсеить тестом на эрудированность. Но если не удавалось -- заставлял читать определенные книжки. Детей в них что-то цепляло и начинали понимать что зачем. И все сводилось к 1). А на 1) пофиг, ибо это уже субъективное.
D>3) Нет ничего кроме желания использовать тебя как Большую Молочную Сиську(С) какой-то умный человек. ХЗ что с ними делать, самых явных мы на собеседовании отсеивали, а остальные либо отсеивались по другим причинам, либо просто не приходили. Но пока повезло, что с ними работать не приходилось.

Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?

Насчет пункта 1 — это для нас не пофиг. Успешное существование компании может обеспечить не только качество софта с точки зрения юзера, но и качество софта с точки зрения программиста. Это и есть наша "этика и эстетика", не так ли? Рабочий софт худо-бедно выдавать могут процентов 70 после трех месяцев воспитания. Но смотреть туда нельзя, не упав в обморок. Программы, которые им давались для развития, через некоторое время превращались в помойку. Куда потом с этой помойкой? Никуда. Невозможно развивать, невозможно поддерживать. Дается им задание сделать что-нибудь очень похожее на то что было раньше. Берется старый класс, у него добавляется метод, чтобы потом от него унаследоваться и переопределить. Через некторое время туда заглянуть — куча каких-то бестолковых методов, затупы повсюду, куча конструкторов с кучей параметров. Я уже не говорю о создании всяких невидимых окон, чтобы можно было воспользоваться какой-нибудь готовой фигней, идущей вслед за этим окном (и написанной такими же студнями). Это все конечно дышит, юзер видит, что кнопочки давятся, обработка идет... Но нам нужен не такой софт.

Насчет пункта номер три — с нами этот номер не проходит

Здравствуйте, BulatZiganshin, Вы писали:

BZ>видишь ли, под "знать программирование" мы понимаем несколько разные вещи. ты можешь написать небольшой алгоритм. а нужно писать большую программу с определённой архитектурой, соблюдая стандарты кодирования: комментирование, тестирование, ясная структура и т.д. вас этому не учат, даже не говорят, что знание паскаля и деревьев — это ещё не умение программировать на реальной раюоте

Вот и плохо, что вы всех под одну гребенку чешете. Мне кажется, что смысл фразы "знать программирование" у нормального студента и у вас, вполне совпадает. А совпадает потому, что нормальный студент не ограничивается программой университета. Например "Code complete" МакКоннелла выравнивает руки студента в 99 процентах, при этом, не являясь книгой, которую трудно найти. Стандарт кодирования — rsdn'овский в руки и вперед. Паттерны опять же. Главное не лениться. Вывод один — вы встречали студентов, которые сами не заинтересованы в том, чтобы стать профессионалами. Является ли это тенденцией, я не знаю, но по вашему выходит что да.

p.s. Я даже больше скажу — если студент читает rsdn и обращает внимание на посты умных людей, то у него все будет в порядке (хе-хе, себя не похвалишь — никто не похвалит )

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, жертва мехмата, Вы писали:

ЖМ>>Программы, которые им давались для развития, через некоторое время превращались в помойку.

BZ>ошибка здесь. нельзя бросать человека в воду, чтоб он научился плавать. надо увеличивать размер ответственности постепенно. комиттить только после ревью, объяснять что к чему. там и видно будет — кто способен учиться, а кто нет

Категорически поддерживаю

Здравствуйте, VovkaMorkovka, Вы писали:

BZ>>ошибка здесь. нельзя бросать человека в воду, чтоб он научился плавать. надо увеличивать размер ответственности постепенно. комиттить только после ревью, объяснять что к чему. там и видно будет — кто способен учиться, а кто нет

VM>Категорически поддерживаю

Мы это понимаем, так и стараемся делать, но часто этого не получается. Бывает срочность, бывают нечеловеческие объемы в короткий срок и ревью приходится откладывать. Приходится включать в сборку их творчество и отдавать в проверку. Потому что версия нужна и именно сегодня.

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

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

Здравствуйте, жертва мехмата, Вы писали:

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

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

ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?

Вот интересно узнать. Вы сказали про СУБД что там все просто и вы даже ржете. Если еще проще сделать, могли бы Вы сказать что БД — это структура данных?

Здравствуйте, BokiyIS, Вы писали:

BZ>>видишь ли, под "знать программирование" мы понимаем несколько разные вещи. ты можешь написать небольшой алгоритм. а нужно писать большую программу с определённой архитектурой, соблюдая стандарты кодирования: комментирование, тестирование, ясная структура и т.д. вас этому не учат, даже не говорят, что знание паскаля и деревьев — это ещё не умение программировать на реальной раюоте

BIS>Вот и плохо, что вы всех под одну гребенку чешете. Мне кажется, что смысл фразы "знать программирование" у нормального студента и у вас, вполне совпадает. А совпадает потому, что нормальный студент не ограничивается программой университета. Например "Code complete" МакКоннелла выравнивает руки студента в 99 процентах, при этом, не являясь книгой, которую трудно найти. Стандарт кодирования — rsdn'овский в руки и вперед. Паттерны опять же. Главное не лениться. Вывод один — вы встречали студентов, которые сами не заинтересованы в том, чтобы стать профессионалами. Является ли это тенденцией, я не знаю, но по вашему выходит что да.

BIS>p.s. Я даже больше скажу — если студент читает rsdn и обращает внимание на посты умных людей, то у него все будет в порядке (хе-хе, себя не похвалишь — никто не похвалит )

1. "бойтесь человека, прочитавшего одну книгу"
2. чтение не заменяет опыт работы. это как бы шаблон по которому нужно дальше набивать руку
3. проведи опрос в своём вузе — сколько народу изучило хотя бы только упомянутое тобой
4. ... при том, что это ещё далеко не полный список

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

>Мне кажется, что смысл фразы "знать программирование" у нормального студента и у вас, вполне совпадает.

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

Здравствуйте, BokiyIS, Вы писали:

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

но это имхо только критерии оценки алгоритмического мышления — то, чему хоть отчасти учат в вузе

Здравствуйте, BulatZiganshin, Вы писали:

BZ>но это имхо только критерии оценки алгоритмического мышления — то, чему хоть отчасти учат в вузе

Простите, я возможно непонимаю, но мы вроде говорили о студентах, которые в перспективе будут хорошими девелоперами, а не о студентах, которые знают определенный набор технологий. Или я вас неправильно понял?

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Мы это понимаем, так и стараемся делать, но часто этого не получается. Бывает срочность, бывают нечеловеческие объемы в короткий срок и ревью приходится откладывать. Приходится включать в сборку их творчество и отдавать в проверку. Потому что версия нужна и именно сегодня.

Тогда вы просто не можете брать студентов пока, за стресс — режим и проффи не все берутся и платить за это надо весьма и весьма много


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

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

А кого не брать? Отличников, которые умеют только красиво улыбаться и выдавать зазубренные фразы из конспекта...

Здравствуйте, BulatZiganshin, Вы писали:

BZ>посмотри сам — человек считает себя программистом, но при этом не то что ничего не знает — не знает даже что он должен знать! и даже не догадывается где спросить об этом!!! при этом он уже требует денег, поскольку он "5 лет учился". он не знаком ни с технологией программирования, ни с технологиями, у него не было "производственной практики", в течении которой он должен был набить свою порцию шишек не за счёт компании. наконец, "вкладывание в будущее" тоже не очень работает — поскольку обучившись (за счёт компании!) человек требует повышения зарплаты до уровня middle-level программиста, которого за те же деньги можно сразу было бы нанять.

Я вас поддерживаю и считаю что вы правы. Просто хочу, чтобы ребятам объясняли, почему их не берут, почему к ним такое отношение. Никто не говорит о благотворительности. Если человек хочет получить работу, он прислушается, выучит все что необходимо и уже потом прийдет и будет требовать денег =).

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, BokiyIS, Вы писали:

BZ>у меня были два таких студента. no comments (в смысле комментариев не писали), no architecture — вообще не могдли держать в голове те части программы, которые за пределами экрана. расширение функциональности делалось методом cut-n-paste. это, думаю, самые средние выпускники местного техвуза где-то после года или двух работы. один из них был талантлив, другой нет. но технологией программирования оба не владели, да и откуда собственно. в наших вузах о таких вещах и не подозревали никогда

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

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, SE, Вы писали:

SE>>Я, например, вижу людей, понимающих важность комментирования коммитов, реже чем солнечное затмение

M>ИМХО, все буквально понимают важность комментариев к коммитам, просто не все умеют в одной строчке выразить смысл изменений, которые в коде занимают несколько тысяч строк.

Этому лень, тому недосуг, а тот скребет затылок — не умеет он свою мысль выразить. Код писать умеет, а мысли выразить — нет.
Да, и еще это — за коммиты, "которые в коде занимают несколько тысяч строк" надо вообще руки отрывать. Такие коммиты ни откатить по частям, ни отревьювить быстро невозможно.

Но в целом удается побороть эти вещи. Кому книжку "Рефакторинг" на стол подкинуть, кого попросить, кого пнуть даже в нужном направлении.

Здравствуйте, BulatZiganshin, Вы писали:

M>>ИМХО, все буквально понимают важность комментариев к коммитам, просто не все умеют в одной строчке выразить смысл изменений, которые в коде занимают несколько тысяч строк.

BZ>ты коммит с ежемесячным отчётом часом не путаешь? :)))

Ну может, у них еще не постигли дао распределенных VCS вообще и локальных коммитов в частности.

Здравствуйте, Roman Odaisky, Вы писали:

M>>>ИМХО, все буквально понимают важность комментариев к коммитам, просто не все умеют в одной строчке выразить смысл изменений, которые в коде занимают несколько тысяч строк.

BZ>>ты коммит с ежемесячным отчётом часом не путаешь?

RO>Ну может, у них еще не постигли дао распределенных VCS вообще и локальных коммитов в частности.

Причем тут распределенные VCS?

ЖМ>хорошо умеют присылать смайлики в аське

Ну вот один критерий.

Здравствуйте, жертва мехмата, Вы писали:

По моему безнадежных нет, просто нужно уметь их грамотно применять.

Кодер — должен кодировать — соответсвенно четкая постановка задачи на входе A на выходе B шаг вправо — попытка к бегству.
Очень нужен в команде человек который умеет быстро и красиво что-нибудь сваять, чтобы закрыть на время вопрос. Не верю, что таких задач у Вас не бывает.
Тот кто умеет лечить — должен лечить, только пусть он лечит не Вас а заказчика, иногда и это полезно.
Некоторые отлично работают дома, некоторым свобода противопоказана, люди настолько разные...

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

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

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

Здравствуйте, Miroff, Вы писали:

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

И все таки это скорее дао рефакторинга и дзен TDD. Тогда не будет вставать вопрос про несобирающийся код, пусть там даже VSS используется. А коммиты/чекины, каждый из которых прост, понятен и преследует одну простую и понятную (промежуточную) цель — это же наслаждение для взора, можно прямо с логов отчеты генерировать о проделанной работе. Дзен же TDD в том, чтобы писать тестопригодный код, даже если написание тестов не предусмотрено процессом (и такое бывает).

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, Lloyd, Вы писали:

L>>Причем тут распределенные VCS?

M>Поясняю. Есть фича на несколько тысяч строк и две недели. Коммитить несобирающийся или незаконченный код в корень VCS считается моветоном достойным канделябра.

Коммитить несобирающийся или незаконченный код считается моветоном вне зависимости от того, распределенная VCS или нет

M>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают.

А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.

M>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.

В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS?

Здравствуйте, Lloyd, Вы писали:

M>>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают.
L>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.
А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.

M>>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.
L>В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS?
Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Lloyd, Вы писали:

M>>>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают.
L>>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.
C>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.

TFS

M>>>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.
L>>В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS?
C>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.

И в чем принципиальное отличие от ветки?

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется).
ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

На собеседовании это сделать невозможно, но увидеть через 1-2 месяца — вполне. И мы не пускаем студентов сразу в разработку — это может очень плохо кончиться. Поподробнее могу в личку написать, если интересно.

Здравствуйте, Lloyd, Вы писали:

C>>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.
L>TFS
А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу...
А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису?
А как у него с распределенной мультимастер репликацией?

C>>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.
L>И в чем принципиальное отличие от ветки?
В распределенных VCS каждый коммит ветка.

Здравствуйте, WolfHound, Вы писали:

C>>>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.
L>>TFS
WH>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу...
WH>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису?
WH>А как у него с распределенной мультимастер репликацией?

Это и есть обещанный "геморрой с мерджем веток"?

C>>>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.
L>>И в чем принципиальное отличие от ветки?
WH>В распределенных VCS каждый коммит ветка.

То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?

Здравствуйте, Lloyd, Вы писали:

L>И в чем принципиальное отличие от ветки?

Реализовано это именно как ветка. Собственно, в распределенных VCS всё представлено ветками. Результат bzr checkout ‹url› — ветка, общий репозиторий — тоже ветка, результат bzr branch ‹откуда-то› ‹куда-то› — тем более ветка. Можно обновить свою ветку, сделав ее копией другой ветки (bzr pull), можно учесть изменения других веток (bzr merge). (Можно s/bzr/hg/g, у Mercurial основной интерфейс такой же точно.)

Разница в том, что при использовании SVN или другой классической VCS есть централизованный репозиторий, и создание ветки — серверная операция. Коммиты — тоже. В то же время распределенные VCS позволяют коммитить в свою ветку, создавать локальные ветки, и вести прочую работу, не засоряя сервер кодом, который даже не компилируется. А когда всё будет готово, можно с легкостью сделать bzr push в центральный репозиторий. Опять же, push можно делать в любую ветку. Например, в ветку того, кто ведет code review.

Здравствуйте, Roman Odaisky, Вы писали:

L>>И в чем принципиальное отличие от ветки?

RO>Реализовано это именно как ветка. Собственно, в распределенных VCS всё представлено ветками. Результат bzr checkout ‹url› — ветка, общий репозиторий — тоже ветка, результат bzr branch ‹откуда-то› ‹куда-то› — тем более ветка. Можно обновить свою ветку, сделав ее копией другой ветки (bzr pull), можно учесть изменения других веток (bzr merge). (Можно s/bzr/hg/g, у Mercurial основной интерфейс такой же точно.)

А если нет отличий от ветки, то куда девается "геморрой с мерджем веток"?

Здравствуйте, WolfHound, Вы писали:

WH>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
WH>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.

Почему?

Здравствуйте, Lloyd, Вы писали:

L>>>TFS
WH>>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу...
WH>>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису?
WH>>А как у него с распределенной мультимастер репликацией?

L>Это и есть обещанный "геморрой с мерджем веток"?
На вопросы ответь.
Ибо если он все это не может то гемор будет по люблому.
Хотябы из-за тормозов на удаленные вызовы. Это даже если предположить что сеть хорошо работает.

L>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
Да.
А в чем проблема?

Здравствуйте, Lloyd, Вы писали:

L>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.

Мерждить ветку в транк можно только один раз. После этого классическая VCS "забывает" о мердже и в следующий раз предлагает опять разрешить кучу невнятных конфликтов, причем разрешить руками. Аналогично, мерджить по частям неудобно, потому что легко забыть что уже смерджено, а что еще нет. В распределенных VCS с этим получше. Тот же git отслеживает ближайшего общего родителя для файла в ветке и в транке и сдвигает его после мерджа. Плюс branch, merge и rebase операции в классических VCS довольно медленные. По крайней мере в CVS и SVN.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, жертва мехмата, Вы писали:

ЖМ>>Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?

M>Моя статистика, в которой у меня нет оснований сомневаться, говорит мне, что на группу в 30 студентов:
M>* 0-2 -- годятся в программисты
M>* 5-10 -- годятся во вспомогательные рабочие (тестеры, сисадмины, техписатели)
M>* прочие годятся только чтобы торговать телефонами в киоске
У меня в группе из тех, кто остался к 5 курсу работают программерами все! (11 или 12 человек)
3 отчислили.
Учился я в СПбГПУ (Политех), Физико-механический факультет, кафедра "прикладная математика"
Кстати, начиная с 4 курса нам давали именно программерские дисциплины. (Теория алгоритмов, комп. графика, выч. геом. и пр.)
IMHO, ваша статистика не совсем верна.

Здравствуйте, WolfHound, Вы писали:

L>>>>TFS
WH>>>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу...
WH>>>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису?
WH>>>А как у него с распределенной мультимастер репликацией?

L>>Это и есть обещанный "геморрой с мерджем веток"?
WH>На вопросы ответь.

Ага, разбежался. Ты сначала прочти про что ветка, а потом пыхти.

L>>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
WH>Да.
WH>А в чем проблема?

А зачем, если репозитарий локальный?

Здравствуйте, Miroff, Вы писали:

L>>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.

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

Я не знаю, кто такая классическая VCS, я с ветками только в TFS работал, там никто ничего не забывает и ближайшего родителя тоже запоминает.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Lloyd, Вы писали:

WH>>>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
WH>>>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.
L>>Почему?
WH>Даже не знаю как на этот вопрос можно цензурно ответить.
А нецензурно? Что плохого в использовании красивых зарекомендовавших себя методов, грабли которых относительно известны?

Здравствуйте, Lloyd, Вы писали:

L>Ага, разбежался. Ты сначала прочти про что ветка, а потом пыхти.
Слив засчитан.

L>А зачем, если репозитарий локальный?
Вобщето они все одинаковые.

Здравствуйте, WolfHound, Вы писали:

L>>Ага, разбежался. Ты сначала прочти про что ветка, а потом пыхти.
WH>Слив засчитан.

Если тебе лень посмотреть выше по ветке, то я процитирую:

M>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают.

А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.

И к чему тут был твой вопрос про оффлайновый режим?

L>>А зачем, если репозитарий локальный?
WH>Вобщето они все одинаковые.

И все-таки зачем?

Здравствуйте, Lloyd, Вы писали:

C>>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.
L>TFS
Ну да, там есть merge tracking.

C>>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.
L>И в чем принципиальное отличие от ветки?
Оно и есть ветка, только локальная. Полностью на машине пользователя, со всеми вытекающими преимуществами (и недостатками).

В принципе, можно и серверные ветки использовать, но это не так эстетично — сервер всякой фигнёй засоряется.

Здравствуйте, Lloyd, Вы писали:

L>>>И в чем принципиальное отличие от ветки?
WH>>В распределенных VCS каждый коммит ветка.
L>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
Технически так оно и есть. Для пользователя, естественно, оно представлено в привычном виде линейной истории.

Здравствуйте, Cyberax, Вы писали:

L>>>>И в чем принципиальное отличие от ветки?
WH>>>В распределенных VCS каждый коммит ветка.
L>>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
C>Технически так оно и есть. Для пользователя, естественно, оно представлено в привычном виде линейной истории.

А в чем тогда будет преимущество при merge-е?

Здравствуйте, Cyberax, Вы писали:

C>В принципе, можно и серверные ветки использовать, но это не так эстетично — сервер всякой фигнёй засоряется.

Это единственное преимущество работы с ветками или что-то еще есть?

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, denisko, Вы писали:

WH>>>Даже не знаю как на этот вопрос можно цензурно ответить.
D>>А нецензурно? Что плохого в использовании красивых зарекомендовавших себя методов, грабли которых относительно известны?
C>В том, что большинство из них нужны раз в пятилетку. А попытки использовать их везде, где только можно, приводят к overdesign'у.
Ну естественно соразмерять цель и средства, но совсем отказываться от фабрик тех же просто неудобно.

Здравствуйте, Lloyd, Вы писали:

C>>Технически так оно и есть. Для пользователя, естественно, оно представлено в привычном виде линейной истории.
L>А в чем тогда будет преимущество при merge-е?
Каждый коммит в распределённой VCS однозначно идентифицирует всю свою историю предков. Так что merge получается очень простым — находим общего предка и объединяем изменения с этого момента.

В общем, проще попробовать, чтобы понять как оно работает.

Здравствуйте, Lloyd, Вы писали:

C>>В принципе, можно и серверные ветки использовать, но это не так эстетично — сервер всякой фигнёй засоряется.
L>Это единственное преимущество работы с ветками или что-то еще есть?
Ещё локальный репозиторий работает ОЧЕНЬ быстро. Это сильно меняет многие привычки. Например, я могу в IDEA за секунду посмотреть всю историю выделенного фрагмента текста. С SVN мне пришлось бы ждать минуты две, пока оно всё с сервера подтянется.

Ну и локальные коммиты тоже рулят, конечно.

Здравствуйте, Cyberax, Вы писали:

C>>>Технически так оно и есть. Для пользователя, естественно, оно представлено в привычном виде линейной истории.
L>>А в чем тогда будет преимущество при merge-е?
C>Каждый коммит в распределённой VCS однозначно идентифицирует всю свою историю предков. Так что merge получается очень простым — находим общего предка и объединяем изменения с этого момента.

C>В общем, проще попробовать, чтобы понять как оно работает.

Дык TFS так же работает, чего тут пробовать-то?

Здравствуйте, Cyberax, Вы писали:

C>>>В принципе, можно и серверные ветки использовать, но это не так эстетично — сервер всякой фигнёй засоряется.
L>>Это единственное преимущество работы с ветками или что-то еще есть?
C>Ещё локальный репозиторий работает ОЧЕНЬ быстро. Это сильно меняет многие привычки. Например, я могу в IDEA за секунду посмотреть всю историю выделенного фрагмента текста. С SVN мне пришлось бы ждать минуты две, пока оно всё с сервера подтянется.

C>Ну и локальные коммиты тоже рулят, конечно.

Но это вроде слабо относится к работе с ветками.

Здравствуйте, franz, Вы писали:

F>Студентов, которые еще не доучились на работу не брать! Пусть доучатся.
F>Для студента/выпускника:
F>- посмотреть успеваемость в университете, тему дипломной работы...
F>- дать несколько тестов на логику, проверить мышление.
F>- предложить поработать некоторое время на должности тестировщика или программиста авто тестирования.

Я учился в институте просто отвратно, и вроде как вырос в отличного сениор девелопера. Ну так говорят во всяком случае. А еще я скромный.
Но очень жалею что учился в полсилы и "не там".

F>Я знал многих студентов, которые программировали после университета похлеще тех, у кого за плечами было несколько лет работы в крупных компаниях. А после окончания меньше чем через два года становились начальниками отделов.

А я знаю человека, который будучи студентом работал researcher'ом, и еще до защиты диплома получил отдел, и не за красивые глаза. И защитился он с красным дипломом, к слову.
Опыт он у всех разный. Можно любую теорию из него вывести.

F>Все мы были когда-то студентами
Эт точно

_Jane_ пишет:
>
> V>А вот представьте проект в котором большинство подобных студентов. И,
> V>он, этот проект даже живет неплохо и развивается и в сроки укладывается.
> V>Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
> V>наберешься.
>
> Я более чем уверена, что в этом проекте хорошо поставлено руководство
> этими студентами, контроль и так далее. То есть, не самотёк.
Ну что тебе сказать — моя кровушка ушла и в немалых количествах.
Контроль — фактически они контролируют сами себя — основная масса людей
самодисциплинированы сами по себе, если режим работы (тут все) не
провоцирует обратное.
Но главное, это не контроль — это вообще самое последнее. Главное, это
делегирование полномочий и ответственности, а люди сами себя прекрасно
контролируют, если видят в этом необходимость.

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

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

Здравствуйте, ASolovey, Вы писали:

AS>Так что думаю это тоже подход. Можно и на работе применить.

Я кстати и применяю. на рабочих-учебных задачах.

Здравствуйте, Vzhyk, Вы писали:

Правильно, вот если они "попили кровушки", так значит надо было их вначале научить работать
Люди-то могут быть самодисциплинированны, но всё же пока остаются джуниорами, а значит, нужен code review, нужно их как-то направлять и так далее. На это тоже время тратится...

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

>> V>А вот представьте проект в котором большинство подобных студентов. И,
>> V>он, этот проект даже живет неплохо и развивается и в сроки укладывается.
>> V>Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
>> V>наберешься.
>>
>> Я более чем уверена, что в этом проекте хорошо поставлено руководство
>> этими студентами, контроль и так далее. То есть, не самотёк.
V>Ну что тебе сказать — моя кровушка ушла и в немалых количествах.
V>Контроль — фактически они контролируют сами себя — основная масса людей
V>самодисциплинированы сами по себе, если режим работы (тут все) не
V>провоцирует обратное.
V>Но главное, это не контроль — это вообще самое последнее. Главное, это
V>делегирование полномочий и ответственности, а люди сами себя прекрасно
V>контролируют, если видят в этом необходимость.

>> Текущий уровень увидеть можно достаточно легко. Обучаемость, отношение к
>> работе, насколько человек настроен на серьёзную работу и карьеру, готов
>> ли он работать в действительно большом проекте (т.е. как минимум
>> следовать многим давно установленным процессам и правилам) — сложнее, а
>> это, в случае студентов, показатели более важные.
V>Неа, я всегда смотрю в глаза и пытаюсь вывести человека на "искорку".
V>Если при рассказе о чем-то рабочем, у человека глаза заблестели, значит
V>и обучится, и разберется, и сделает, и следовать правилам будет (если
V>таковы разумны).
V>Если же остались никакими, то хоть кол на голове чеши, толку не будет.
V>Но, тем ни менее, есть много мест, где именно второй вариант людей и нужен.

_Jane_ пишет:
>
> Правильно, вот если они "попили кровушки", так значит надо было их
> вначале научить работать
Не они, начальство. А мне данное было просто интересно, получится или
нет, получилось.

> Люди-то могут быть самодисциплинированны, но всё же пока остаются
> джуниорами, а значит, нужен code review, нужно их как-то направлять и
> так далее. На это тоже время тратится...
Постольку, поскольку. Unit-tests эффективнее ну и еще когда они видят
реально рабочую систему (2-3 недели — сборка автоматом почти).
А code review — расслабляет людей сильно. Ну а направлять, конечно надо.

P.S. Имхо, не сильно важна красота или не красивость кода, важно, чтобы
код делал то, что надо, а это проходил тесты. А красивость — она с
опытом набирается.

P.P.S И самое главное — это поставить процесс разработки (у меня
получилась некая помесь RUP с XP).

Здравствуйте, Vzhyk, Вы писали:

V>Неа, я всегда смотрю в глаза и пытаюсь вывести человека на "искорку".
V>Если при рассказе о чем-то рабочем, у человека глаза заблестели, значит
V>и обучится, и разберется, и сделает, и следовать правилам будет (если
V>таковы разумны).

Мне как-то попадался человек с горящими глазами, но несколько безалаберный. Если интересна тема — будет работать на совесть (пока интересно), если нет (увы, не всегда есть только интересные задачи) — сделает как-нибудь; не всегда следует рабочим процессам, код правильно оформлять тоже "не интересно" — в общем, общая ситуация не очень утешительна. Хотя толковый и с "искоркой"...
В такой ситуации предпочту работать с надёжным середнячком.

Здравствуйте, Vzhyk, Вы писали:


V>P.P.S И самое главное — это поставить процесс разработки (у меня
V>получилась некая помесь RUP с XP).

Ну вот, значит всё-таки не самотёк

_Jane_ пишет:
>
>
> Мне как-то попадался человек с горящими глазами, но несколько
> безалаберный. Если интересна тема — будет работать на совесть (пока
> интересно), если нет (увы, не всегда есть только интересные задачи) —
> сделает как-нибудь; не всегда следует рабочим процессам, код правильно
> оформлять тоже "не интересно" — в общем, общая ситуация не очень
> утешительна. Хотя толковый и с "искоркой"...
Да. Есть такое. Вот это самое место применения ПМа — вот это и есть
настоящая работа ПМа — как от такого человека получить максимальный
результат.

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

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

> В такой ситуации предпочту работать с надёжным середнячком.
Это зависит от задач, которые вы делаете. По моему опыту — это 90%
контор програмерских в СНГовине, где нужны именно "винтики".

P.S. Но вообще, сколько работал в разных местах, пришел к очень
неутешительному выводу: самое бездарное руководство — в програмерских
конторах в СНГ. Отсюда и посты в стиле: "Приём на работу студентов. Как
обнаружить безнадежных".

_Jane_ пишет:
>
>
> Ну вот, значит всё-таки не самотёк
Конечно, нет. Я и не говорил про самотек.

Здравствуйте, Vzhyk, Вы писали:

>> Мне как-то попадался человек с горящими глазами, но несколько
>> безалаберный. Если интересна тема — будет работать на совесть (пока
>> интересно), если нет (увы, не всегда есть только интересные задачи) —
>> сделает как-нибудь; не всегда следует рабочим процессам, код правильно
>> оформлять тоже "не интересно" — в общем, общая ситуация не очень
>> утешительна. Хотя толковый и с "искоркой"...
V>Да. Есть такое. Вот это самое место применения ПМа — вот это и есть
V>настоящая работа ПМа — как от такого человека получить максимальный
V>результат.

V>Например, посмотрите на это с другой стороны, кто лучше его справиться с
V>реально тяжелой и жутко ограниченной задачей по времени.

Если она будет ему интересна ну и держать человека под конкретного рода задачи — это надо чтобы человек реально приносил на них пользы много.

V>По пунктам выше:
V>Рабочие процессы — я имел возможность наблюдать оное от полного
V>отсутствия до полной дури.
V>Правильное оформление кода — то же, что и выше я написал. Я например
V>видел такие рулесы, где требовалось из каждой функции возвращать int.

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

>> В такой ситуации предпочту работать с надёжным середнячком.
V>Это зависит от задач, которые вы делаете. По моему опыту — это 90%
V>контор програмерских в СНГовине, где нужны именно "винтики".

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

V>P.S. Но вообще, сколько работал в разных местах, пришел к очень
V>неутешительному выводу: самое бездарное руководство — в програмерских
V>конторах в СНГ. Отсюда и посты в стиле: "Приём на работу студентов. Как
V>обнаружить безнадежных".

_Jane_ пишет:
>
>
> V>Например, посмотрите на это с другой стороны, кто лучше его справиться с
> V>реально тяжелой и жутко ограниченной задачей по времени.
>
> Если она будет ему интересна ну и держать человека под конкретного рода
> задачи — это надо чтобы человек реально приносил на них пользы много.
Вот о чем и речь. Был у меня когда-то такой человек, тяжело было ему
здесь. Сейчас вполне неплохо в канадах програмит.

> V>видел такие рулесы, где требовалось из каждой функции возвращать int.
>
> Если рядом не было объяснения, зачем это нужно, правило кажется глупым.
> На самом деле оно может действительно актуальным по какой-либо причине.
Хорошо, назовите хоть одну причину для подобного в программе на С++.

> Хотя, если честно, в правилах много чего устаревшего. Вот чтобы
> соблюдались актуальные правила, мы специально подробно разбираем
> причины. так всё равно не все делают как надо...
Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
должен задавать стиль написания, остальные в большей или меньшей степени
следуют ему.

>
> Да, так оно и есть. задачи предполагают много "винтиков" и некоторое
> количество хорошо квалифицированных людей.
Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.

Здравствуйте, Vzhyk, Вы писали:

V>_Jane_ пишет:
>>
>>
>> V>Например, посмотрите на это с другой стороны, кто лучше его справиться с
>> V>реально тяжелой и жутко ограниченной задачей по времени.
>>
>> Если она будет ему интересна ну и держать человека под конкретного рода
>> задачи — это надо чтобы человек реально приносил на них пользы много.
V>Вот о чем и речь. Был у меня когда-то такой человек, тяжело было ему
V>здесь. Сейчас вполне неплохо в канадах програмит.

>> V>видел такие рулесы, где требовалось из каждой функции возвращать int.
>>
>> Если рядом не было объяснения, зачем это нужно, правило кажется глупым.
>> На самом деле оно может действительно актуальным по какой-либо причине.
V>Хорошо, назовите хоть одну причину для подобного в программе на С++.

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

>> Хотя, если честно, в правилах много чего устаревшего. Вот чтобы
>> соблюдались актуальные правила, мы специально подробно разбираем
>> причины. так всё равно не все делают как надо...
V>Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
V>должен задавать стиль написания, остальные в большей или меньшей степени
V>следуют ему.

Чтобы следовали, надо чётко определиться, что важно, а что не очень. "Интуитивно" не все понимают.

>> Да, так оно и есть. задачи предполагают много "винтиков" и некоторое
>> количество хорошо квалифицированных людей.
V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.

Угу.

_Jane_ пишет:
>
> V>Хорошо, назовите хоть одну причину для подобного в программе на С++.
>
> Про int? тут могу только догадываться. Возможно, это пришло из С-шного
> кода, чтобы везде был одинаковый тип кодов возврата ну и чтобы вообще он
> был.
И даже в С, и даже в Фортране — это было глупостью, призванной тольк для
одной цели, обеспечить занятием толпу манагеров (кстати при резком росте
толпы манагеров "среднего звена"), этот момент отрабатывал всегда.

> А если программа С++ написана тоже в функциональном стиле (без
> классов-исключений), или хотя бы частично, то и там надо единый стиль
> возвращения какого-либо статуса.
А причем тут С++? Если С, тогда "логику особо извращенных" придумать можно.

> V>Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
> V>должен задавать стиль написания, остальные в большей или меньшей степени
> V>следуют ему.
>
> Чтобы следовали, надо чётко определиться, что важно, а что не очень.
Вот вот, именно этот момент меня умиляет. Чтобы было очень четко,
необходимо просто писать одному за всех — все остальное ИБД.

Вообще говоря у меня требования стилю есть:
1. Не изобретать велосипеды с квадратными колесами, до вас уже давно
разработали с круглыми (это и STL и boost и patterns).
2. Все платформо-зависимое или требующее сторонних библиотек в отдельное
место и через прослойку.
3. Голые указатели — это мне долго доказывать придеться его необходимость
4. Каменты на уровне, чтобы через полгода сам понять мог, че написал.

> "Интуитивно" не все понимают.
Архитектор, который может говорить, он может внятно и четко объяснить,
зачем нужно то или другое, если немой, написать может. Ежели не может ни
того, ни другого — то это не архитектор проекта.

> V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.
>
> Угу.
Вот видишь, здесь мы сходимся. Фактически наш спор — это спор об
отношении к разработчикам здесь. А это отношение вытекает из задач.

Здравствуйте, Vzhyk, Вы писали:

V>_Jane_ пишет:
>>
>> V>Хорошо, назовите хоть одну причину для подобного в программе на С++.
>>
>> Про int? тут могу только догадываться. Возможно, это пришло из С-шного
>> кода, чтобы везде был одинаковый тип кодов возврата ну и чтобы вообще он
>> был.
V>И даже в С, и даже в Фортране — это было глупостью, призванной тольк для
V>одной цели, обеспечить занятием толпу манагеров (кстати при резком росте
V>толпы манагеров "среднего звена"), этот момент отрабатывал всегда.

Если честно, не поняла мысли

>> А если программа С++ написана тоже в функциональном стиле (без
>> классов-исключений), или хотя бы частично, то и там надо единый стиль
>> возвращения какого-либо статуса.
V>А причем тут С++? Если С, тогда "логику особо извращенных" придумать можно.

При том, что стиль программирования и язык — это всё-таки не одно и то же. Можно написать функциональную программу и на С++.

>> V>Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
>> V>должен задавать стиль написания, остальные в большей или меньшей степени
>> V>следуют ему.
>>
>> Чтобы следовали, надо чётко определиться, что важно, а что не очень.
V>Вот вот, именно этот момент меня умиляет. Чтобы было очень четко,
V>необходимо просто писать одному за всех — все остальное ИБД.

V>Вообще говоря у меня требования стилю есть:
V>1. Не изобретать велосипеды с квадратными колесами, до вас уже давно
V>разработали с круглыми (это и STL и boost и patterns).
V>2. Все платформо-зависимое или требующее сторонних библиотек в отдельное
V>место и через прослойку.
V>3. Голые указатели — это мне долго доказывать придеться его необходимость
V>4. Каменты на уровне, чтобы через полгода сам понять мог, че написал.
>> "Интуитивно" не все понимают.
V>Архитектор, который может говорить, он может внятно и четко объяснить,
V>зачем нужно то или другое, если немой, написать может. Ежели не может ни
V>того, ни другого — то это не архитектор проекта.

А я о чём говорю. Что надо сделать "вводную" людям.

>> V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.
>>
>> Угу.
V>Вот видишь, здесь мы сходимся. Фактически наш спор — это спор об
V>отношении к разработчикам здесь. А это отношение вытекает из задач.

Здравствуйте, Lonely Dog, Вы писали:

M>>Моя статистика, в которой у меня нет оснований сомневаться, говорит мне, что на группу в 30 студентов:
M>>* 0-2 -- годятся в программисты
M>>* 5-10 -- годятся во вспомогательные рабочие (тестеры, сисадмины, техписатели)
M>>* прочие годятся только чтобы торговать телефонами в киоске
LD>У меня в группе из тех, кто остался к 5 курсу работают программерами все! (11 или 12 человек)
LD>3 отчислили.
Да я тоже в шоке от приведенной статистики... (из двух групп, в которых я учился на первом в/о — ннгу/вмк/инф.системы — процентов 80 работает сейчас программерами/тестерами/сисадминами. но то было четыре года назад, неужто сейчас все так плохо?)

LD>Кстати, начиная с 4 курса нам давали именно программерские дисциплины. (Теория алгоритмов, комп. графика, выч. геом. и пр.)
что-то поздновато алгоритмы... я их чуть ли не с первого курса помню... ну и дискретки(под разными названиями) четыре или пять лет — мало не покажется

LD>IMHO, ваша статистика не совсем верна.
+1

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, жертва мехмата, Вы писали:

IT>В программировании есть только три вещи, понимание которых отличает программиста от непрограммиста. Это:

IT>1. Рекурсия.
IT>2. Указатели.
IT>3. Биты.

IT>Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

Сомневаюсь что программисту на каком-нибудь erlang необходимо понимать указатели.
Более того, я знаю пару человек, которые отлично понимают указатели и биты и вообще не понмают ООП. Видели бы вы что они пишут...

Здравствуйте, gandjustas, Вы писали:

G>Сомневаюсь что программисту на каком-нибудь erlang необходимо понимать указатели.

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

G>Более того, я знаю пару человек, которые отлично понимают указатели и биты и вообще не понмают ООП. Видели бы вы что они пишут...

А они точно понимают что такое указатели? Косвенная адресация и всё такое? А если да, то кто-нибудь им пытался объяснить ООП на пальцах? Нормальным языком, а не книжкой Страуструпа.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>Сомневаюсь что программисту на каком-нибудь erlang необходимо понимать указатели.

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

G>>Более того, я знаю пару человек, которые отлично понимают указатели и биты и вообще не понмают ООП. Видели бы вы что они пишут...
IT>А они точно понимают что такое указатели? Косвенная адресация и всё такое? А если да, то кто-нибудь им пытался объяснить ООП на пальцах? Нормальным языком, а не книжкой Страуструпа.
Точно, на ассемблере еще вместе писали. Ну нет у некоторых людей абстрактного мышления.

_Jane_ пишет:
>
>
> Если честно, не поняла мысли
Мысль в том, что подобное требование: возврат int из всех функций —
может быть только глупостью.
И в то же время подобная глупость позволяет занять толпу народа
бессмысленной деятельностью.

> При том, что стиль программирования и язык — это всё-таки не одно и то
> же. Можно написать функциональную программу и на С++.
Можно, но зачем? В общем-то все, кто знает С++, знают и С. Но и в данном
случае int из всех функций более осмысленным не становиться.

>
> А я о чём говорю. Что надо сделать "вводную" людям.
Эта вводная делается устно, или если команда распределенная одним
маленьким письмом, а еще проще, выложить на внутреннюю страничку проекта.

gandjustas пишет:
>
> Ну нет у некоторых людей
> абстрактного мышления.
Аки Акымы, что видят, то и пишут?

Здравствуйте, IT, Вы писали:

IT>В программировании есть только три вещи, понимание которых отличает программиста от непрограммиста. Это:
IT>1. Рекурсия.
IT>2. Указатели.
IT>3. Биты.
Особенно указатели. Биты и рекурсию, с горем пополам, понимают практически все.

ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров?
Начинать пасти их курса с третьего.

V>Где логика? Здесь говорят про использование паттернов, но нигде не
V>говорят, что их нужно пихать всегда и везде.
V>Тем ни менее, я все больше убеждаюсь в том, что знание, хотя бы с
V>большего, паттернов проектирования — действительно необходимость. Ну
V>зачем изобретать собственный велосипед с квадратными колесами, если в
V>данном месте прекрасно кладется какой-нибудь паттерн.
А я все больше убеждаюсь, что дуракам лишние знания вредят.

Здравствуйте, Dym On, Вы писали:

DO>Особенно указатели. Биты и рекурсию, с горем пополам, понимают практически все.
Ну ну. Я чуть мозги не вывихнул в свое время от попыток врубиться в рекурсию, чтобы понять, как работает рекурсивное решение задачи о ханойских башнях. Врубился, слава аллаху. Но что-то мне подсказывает, что процентов 90 человек (студентов), считающих себя программистами, этого дао не постигли еще, хотя с указателями и битами у них все хорошо. И максимальный уровень владения рекурсией вот такой (пример из реального кода, как увидел такой, меня чуть кондратий не хватил, писал такое мегаархитектор с 15 годами опыта и 20 000 баксов в месяц зарплатой ):

void doSmth(int a) {
    ... очертенеть как много кода
    try{
       ... очертенеть как много кода
       doA(a);
    }catch (Exception ex) {
       doSmth(a);
    }
    ... очертенеть как много кода

PS Этот код работал

DO>>Особенно указатели. Биты и рекурсию, с горем пополам, понимают практически все.
E>Ну ну. Я чуть мозги не вывихнул в свое время от попыток врубиться в рекурсию, чтобы понять, как работает рекурсивное решение задачи о ханойских башнях. Врубился, слава аллаху.
Ну ведь-таки врубился

E>И максимальный уровень владения рекурсией вот такой (пример из реального кода, как увидел такой, меня чуть кондратий не хватил, писал такое мегаархитектор с 15 годами опыта и 20 000 баксов в месяц зарплатой ):
Если бы мне платили 20 000 баксов в месяц, я бы тоже такое писал и не заморачивался

E>PS Этот код работал
И это главное.

Здравствуйте, _Jane_, Вы писали:

_

_J_>Мне как-то попадался человек с горящими глазами, но несколько безалаберный. Если интересна тема — будет работать на совесть (пока интересно), если нет (увы, не всегда есть только интересные задачи) — сделает как-нибудь;

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

Здравствуйте, Lonely Dog, Вы писали:

LD>Кстати, начиная с 4 курса нам давали именно программерские дисциплины. (Теория алгоритмов, комп. графика, выч. геом. и пр.)
LD>IMHO, ваша статистика не совсем верна.

да, жутко программерские — прям каждая вторая контора в них нуждается. это опять выч. математика. собственно кафедра так и называется

Здравствуйте, IT, Вы писали:

IT>В программировании есть только три вещи, понимание которых отличает программиста от непрограммиста. Это:

IT>1. Рекурсия.
IT>2. Указатели.
IT>3. Биты.

IT>Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

в хаскеле нет 2 и 3

Здравствуйте, ASolovey, Вы писали:

AS>P.S. Я после таких экспериментов бывало находил ошибки в программе во сне. Спишь, снится код, ходишь мысленно по нему дебаггером, условия вариьируешь — потом в поту просыпаешься — вот же оно!
AS>Раз к компу — смотришь — точняк! Но это конечно в самых тяжелых случаях...

не теряйся — потребуй поставить кровати на работе! не за счёт же за совего личного времени тебе программу отлаживать

Здравствуйте, IT, Вы писали:

IT>Да и нет там никакого такого "другого" уровня абстракции. Набор паттернов. Всё упирается опять же в способ объяснения. Мне доводилось объяснять что такое карринг человеку, хорошо владеющему указателями на функции, за две минуты в метро под стук колёс и толкотню пассажиров. Ещё три минуты до этого было потрачено на объяснение замыканий. Его реакция была примерно такая — "И это всё? Ясно."

это всё равно что объяснять физику как водить машину, начиная с квантовой хромодинамики

мы с тобой знаем немало людей здесь на rsdn, которые *знакомы* с ФП языками, но не понимают их, поскольку смотрят на них через амбразуру указателей

Здравствуйте, BulatZiganshin, Вы писали:

IT>>1. Рекурсия.
IT>>2. Указатели.
IT>>3. Биты.

IT>>Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

BZ>в хаскеле нет 2 и 3

Ну тогда, тогда... ну пусть для любителей хаскеля критерием будет понимание анонимной рекурсии

Здравствуйте, gandjustas, Вы писали:

G>Сомневаюсь что программисту на каком-нибудь erlang необходимо понимать указатели.

У меня вообще есть серьезные сомнения, что человек, который не в состоянии понять указатели, сможет освоить деревья. Хотя, кто знает

G>Более того, я знаю пару человек, которые отлично понимают указатели и биты и вообще не понмают ООП. Видели бы вы что они пишут...

ИМХО, приведенный список из трех пунктов есть необходимое условие, но не достаточное.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>это всё равно что объяснять физику как водить машину, начиная с квантовой хромодинамики

Если это будет также эффективно, то почему бы и нет? Хотя физику нужно начинать объяснять со слов "Возьмём сферический автомобиль в вакууме"... Впрочем, у меня нет большого желания выпрямлять кривые аналогии.

BZ>мы с тобой знаем немало людей здесь на rsdn, которые *знакомы* с ФП языками, но не понимают их, поскольку смотрят на них через амбразуру указателей

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

Здравствуйте, BulatZiganshin, Вы писали:

IT>>Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

BZ>в хаскеле нет 2 и 3

Боюсь Хаскель как критерий отбора безнадёжных студентов точно не подойдёт

Здравствуйте, LordMAD, Вы писали:

LMA>Здравствуйте, franz, Вы писали:

F>>Студентов, которые еще не доучились на работу не брать! Пусть доучатся.
LMA>Есть такая старая, но мудрая фраза, что учиться надо всю жизнь. Когда же считать, что он доучился?
Я имел ввиду студентов, которые еще не закончили университет.

F>>Для студента/выпускника:
F>>- посмотреть успеваемость в университете, тему дипломной работы.
LMA>Успеваемость не говорит ни о чем. Тема диплома говорит еще меньше — за красивыми темами иногда такое скрывается — просто кошмар.
Как показывает практика, студенты с хорошей успеваемостью будут показывать хорошие результаты и на работе.

F>>Попросить рассказать чем он занимался в университете, каких успехов достиг.
LMA>Какие "успехи" могут быть у студента? Задача студента — получать фундамент и учиться учиться. "Успехом" в получении фундамента может быть что? Наверное, только если докажет какую-нибудь теорему, которую 200 лет доказать не могли.
Основной успех для студента — усвоить те знания, которые ему дали в университете и научиться мыслить самостоятельно.

F>>Если студент учился "на отлично" в пристижном университете
LMA>Категорически нет. Даже если перед Вами выпускник MIT.
Престижном я сказал условно.. не престижный — это разного рода "заборостроительные", где можно не учиться а просто проплачивать каждый семестр.

F>>- предложить поработать некоторое время на должности тестировщика или программиста авто тестирования.
LMA>И если согласится — то не брать, ибо либо идиот, либо закомплексованный. Не уверен, по по-моему это еще и Трудовому Кодексу противоречит.
Не понял чем он идиот и в чем противоречие кодексу?
Просто в качестве испытательного срока надо дать ему область работ связанную с проектом, но не влияющую на качество конечного продукта. Это может быть например авто тестирование, где также надо уметь программировать и знать как устроен конечный продукт.

Здравствуйте, жертва мехмата, Вы писали:

ЖМ>Или же у всех такая беда?

Такая беда у всех. Это та цена которую приходится платить. Если берете людей без опыта, студентов, то приличный процент отсева гарантирован. Зато и в случае удачи вы получаете много — задешево молодых голодных до работы и развития сотрудников. Уменьшить процент "отходов" можно только за счет усложнения процедуры предварительного отбора — а чем такая процедура сложнее, тем она дороже. Получается замкнутый круг. В какой точке этот круг разрывать чтоб получить оптимальное соотношение цена-качество — это вопрос однозначного решения не имеющий IMHO.