В вакансиях часто стало встречаться требование
"Опыт промышленной разработки"?

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

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?

М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".

Грань может быть зыбкой и о ней нет смысла рассуждать.

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

Мне кажется, что если разработанная тобой программа крутится в режиме 24*7 в десятке стран, на 5000 компьютерах, то можно смело говорить об опыте участия в промышленной разработке. То есть, программы, написанные "для себя", "для нашего банка", "для бухгалтерии" и промышленная разработка это немного разное. Может быть это имеется в виду под "промышленной разработкой"?

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?

М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".
М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином
М>подразумевается.

это означает "мы вам мало заплатим и будем долбить мозг на собеседовании"

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?

М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".
М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином
М>подразумевается.

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

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?

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

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?

М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".
М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином
М>подразумевается.

Могу предположить, что это опыт разработки приложений за деньги.

Можно же и 10 лет програмировать свою мегаигруху, но это врядли даст вам адекватную оценку и направление как програмиста.

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

М>В вакансиях часто стало встречаться требование
М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".

Не стоит так трепетно относиться к текстам резюме и вакансий.

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

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

М>Предложение обсудить этот термин, где проходит грань между "промышленной" и
М>"непромышленной".

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

Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он

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

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

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

M>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он
M>

будет делать то, что ему говорят, проявляя при этом разумную степень инициативы;
M>

будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными;
M>т.е. понимает и принимает правила игры.

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

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

K>Потому что любое требование, любое ограничение имеет причину — и знать её всегда очень полезно.

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

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

B>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот)
B>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры

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

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

M>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он
M>

будет делать то, что ему говорят, проявляя при этом разумную степень инициативы;
M>

будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными;
M>т.е. понимает и принимает правила игры.

А скажем, для "академической" разработки это не применимо?

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

B>До причин обычно можно без особых проблем добраться.
B>То, до чего за пол часа можно докопаться — это вообще скорей всего мелочь.
B>Но вопрос не в этом.
B>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот)
B>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры

Мне не доводилось работать в командах с большой ротацией (потому что я сознательно стараюсь обходить такие конторы стороной), так как у этого явления тоже есть причины, и я не хочу испытать действие этих причин на себе. Обычно к началу проекта команда уже сформирована, и посидеть разок и договориться о стиле не проблема. Кроме того, мне в общем-то всё равно, пробелы там используются или табы, но мне, например, не нравится привычка пихать несколько классов в один файл (потому что я ищу исходный код класса, "выводя" имя файла и расположение из его названия, посему отход от данного правила банально усложняет мне работу).
Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...

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

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

B>>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот)
B>>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры

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

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

Но то был всего лишь пример.
В целом, готовность идти на компромиссы — это весьма и весьма важно.

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

K>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...

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

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

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

M>>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он
M>>

будет делать то, что ему говорят, проявляя при этом разумную степень инициативы;
M>>

будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными;
M>>т.е. понимает и принимает правила игры.

ГВ>А скажем, для "академической" разработки это не применимо?
Для академической правила мягче.

M>>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он
M>>

будет делать то, что ему говорят, проявляя при этом разумную степень инициативы;
M>>

будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными;
M>>т.е. понимает и принимает правила игры.

K>У меня вот всегда были проблемы с этим пунктом. Ибо всякий раз, когда я делал что-то, не понимая смысла, выходила какая-то фигня, и потом она сто раз переделывалась. Так что я предпочитаю провести дополнительные полчаса на митинге, выяснив, зачем это нужно. Потому что любое требование, любое ограничение имеет причину — и знать её всегда очень полезно.
абсолютно верно.

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

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

PS Даже если ты с чем-то несогласен — сделай как решили, причем не саботируй, приложи все усилия — а жизнь покажет кто был прав. Тем более, что не составляет труда для любителей post-mortem разборок отписать свои соображения в процессе обсуждения (или сразу по его итогам) — и потом аппеллировать к тому какой ты был провидец. Суть в том, что все разборки должны быть отложены до подходящего момента — когда ввязались в бой уже поздно выяснять какой умник в штабе нас сюда отправил, надо выполнять задачу, а не выбрасывать белый флаг. PPS Полезно помнить, что часто к цели можно добраться тысячью дорог.

... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>

K>Ибо всякий раз, когда я делал что-то, не понимая смысла, выходила какая-то фигня, и потом она сто раз переделывалась.

+1000

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

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