RDD
В Интернете про RDD пишут мало и, в основном, на английском. Но основная суть в том, что разработчики часто выбирают для решения конкретной задачи не наиболее подходящую технологию, а ту, которую выгодно написать в резюме.
Хотелось бы услышать мнения.
Лично я всегда работал по принципу anti-RDD и у меня от этого лишь проблемы. Но опыт одного человека - это не статистика.
Это можно понять двояко. Например, так: узнаём сколько денег у начальства и ищем технологию, наиболее близкую по стоимости. Её и используем, независимо от того, насколько хорошо она подходит. Или можно понять так, что выбираем не самую лучшую технологию, потому что у начальства на хорошую нет денег. Смысл абсолютно разный.
Но всё-таки это отклонение от основной темы.
Но всё-таки это отклонение от основной темы.
А мне показалось, что как раз в тему ответил. Можно тогда по сабжу больше информации в топик, видимо, что-то недопонял.
Например, вам известна технология X, которая хорошо работает с таким типом задач и позволяет получить решение достаточно дёшево. Тем не менее, вы используете вместо X модную технологию Y при отсутствии опыта работы с ней, чтобы изучить её за счёт потребителя. Само собой, повышается риск не уложиться в ограничения или получить говно на выходе. Так понимают это авторы названий типа Asshole Driven Development, от которых меня лично уже блевать тянет. Мне же кажется, что в большинстве случаев Y выбирается всё-таки потому, что "по ходу она может всё то же самое и не только", а резюме уже - дело десятое.
Например, вам известна технология X, которая хорошо работает с таким типом задач и позволяет получить решение достаточно дёшево. Тем не менее, вы используете вместо X модную технологию Y при отсутствии опыта работы с ней, чтобы изучить её за счёт потребителя. Само собой, повышается риск не уложиться в ограничения или получить говно на выходе. Так понимают это авторы названий типа Asshole Driven Development, от которых меня лично уже блевать тянет. Мне же кажется, что в большинстве случаев Y выбирается всё-таки потому, что "по ходу она может всё то же самое и не только", а резюме уже - дело десятое.
Теперь вкурил. Я бы выбирал технологию, которую хочу изучить, да, c целью новых плюшек, а не из-за резюме.
Теперь вкурил. Я бы выбирал технологию, которую хочу изучить, да, c целью новых плюшек, а не из-за резюме.
На самом деле - это разновидность RDD-подхода. И эт достаточно частая проблема, например я лично не однократно попадал в подобную ловушку - когда хочется освоить нечто новое, и из-за этого - срыв сроков и пр. проблемы. После не однократно зарекался - но как говорят у нас - "Зарікалася свиня гівно не їсти" :)
Что бы избежать проблем нужно принять это как оговоренный риск - например заранее оговорить с заказчиком/подрядчиком что в обмен на "плюшки" для него (например снижение стоимости работы, расширенныя поддержка и пр.) будут плюшки для меня (возможности проф.роста).
С другой стороны - необходимо четко сформулировть - что такое anti-RDD - и понимать, что на самом деле это тоже не всегда хорошо. Например, считается проверенным и оправданным решением использовать 1С в бухгалтерском учете - что ведет к раздуванию штата для крупных предприятий (нужна штатная единица программиста - либо затраты на аутсорсинг), росту затрат на поддержку и разработку и, зачастую, росту штата бухгалтерии. В целом ряде случаев более дешевым и оправданным было бы написать собственный продукт - и поддерживать его. Но не нашлось человека, который бы использовал RDD-подход.
Вот тут есть по теме на английском:
http://www.healthcareguy.com/2007/01/19/resume-driven-development-rdd/
Кроме самой статьи интересны и комментарии (читаются снизу вверх).
Например, интересен такой комментарий:
Теперь на счёт anti-RDD. Например, использование таких инструментов (библиотек, фреймворков, ОС) как OpenCV, wxPython, QNX, sqlite, yacc и т.д. даже если они хорошо подходят для конкретной задачи - это anti-RDD, ибо очень трудно найти вакансии, где эти инструменты будут нужны.
Есть и спорные вещи. Например, знание того, что такое алгоритмическая сложность - базовый навык классического программиста. Но мало того, что про алгоритмическую сложность знают немногие профессиональные программисты, так ещё и в вакансиях она не указывается. Возможно, изучение алгоритмической сложности - это тоже anti-RDD.
Что подразумевается под "классическим программистом"?
Разрешите поинтересоваться, в каких вакансиях вы хотите это увидеть, на какую позицию?
Говнокодер же.
Разрешите поинтересоваться, в каких вакансиях вы хотите это увидеть, на какую позицию?
На позицию говнокодера. Это где описание навыков - названия всех статей вики. А в результате нужен "немножко админ", "немножко монтажник", "немножко аникейщик".
P.S. Это сарказм, и он относиться к теме, а не к конкретному лицу.
Подразумевается программист с хорошим знанием базовой теории программирования, то есть он разбирается в алгоритмах, структурах данных, парадигмах программирования и т.д.
Возможно, в предыдущем сообщении я немного неточно термин использовал. Говорил я про O-нотацию при асимптотической оценки функций. Требование этого знания может быть везде, где используют структуры типа контейнеров STL в C++. Иначе, как выбрать, где использовать vector, а где list, например.
Возможно, в предыдущем сообщении я немного неточно термин использовал. Говорил я про O-нотацию при асимптотической оценки функций. Требование этого знания может быть везде, где используют структуры типа контейнеров STL в C++. Иначе, как выбрать, где использовать vector, а где list, например.
Какой же предлагаешь вариант описания вакансии?
Не совсем понял вопрос. Я могу предложить пункт в вакансии: понимание O-нотации при асимптотической оценки функций.
Можно предположить, что такой пункт будет требоваться в вакансиях на программиста, который работает с большим объёмом данных, обработка которых должна производиться за наиболее короткое время. Вероятно, в определённом проекте будет достаточно одного такого специалиста по оптимизации.
Но что-то мы совсем ушли в сторону от основной темы. У меня идея была в том, что с точки зрения RDD не выгодно изучать не только определённые инструменты (пусть и оптимальные для текущей задачи), но и даже некоторые теоретические основы. Зачем цепляться к несущественным деталям?
Не совсем согласен.
Смотря как и что писать в резюме. Ведь это можно преподать так:
большой навык работы с системами компьютерного зрения, распознавания образов (в том числе OpenCV);
большой опыт работы с различными графическими библиотеками (в том числе wxPython);
опыт работы в разных операционных системах (Ubuntu, QNX);
опыт работы с базами данных разных производителей (в том числе с редкими, вроде sqlite);
практические навыки написания парсеров с использованием генераторв парсеров (yacc).
Чуешь? Это уже становится плюсом, а не минусом!
А вообще, смотря где искать работу. Я вот не далее как вчера прошёлся по сайтам поиска работы в рунете и по сайтам родного города, и нашёл тут одну-единственную вакансию: 1C, 18 тысяч руб. Такова жизнь. То есть в данном случае не помогут опыт и знания самых популярных языков и технологий, хоть ты тресни.
Полагаю, где-нибудь в Дефолт-сити или в Кремниевой долине можно найти вакансии, где требуется и OpenCV, и всё остальное из перечисленного.
А так ли нужно на самом деле знание алгоритмической сложности и О-нотации для выбора коллекции?
Я когда впервые познакомился с коллекциями, то прочитал краткий список описания достоинств и недостатков каждой, на этом основании можно подобрать подходящую.
Конечно, это желательно знать. Но процентов для 90 практикующих программеров не так уж и важно.
большой навык работы с системами компьютерного зрения, распознавания образов (в том числе OpenCV);
большой опыт работы с различными графическими библиотеками (в том числе wxPython);
опыт работы в разных операционных системах (Ubuntu, QNX);
опыт работы с базами данных разных производителей (в том числе с редкими, вроде sqlite);
практические навыки написания парсеров с использованием генераторв парсеров (yacc).
Чуешь? Это уже становится плюсом, а не минусом!
Хорошо пошутил.
В большинстве случаев улавливается, что соискатель "преподносит".
Но что-то в этом есть. Например, вакансий с OpenCV в Петербурге нет, а с компьютерным зрением - есть. Кстати, сам я эту технологию почти не знаю - привёл лишь для примера.
Ну и поправка. sqlite - не наиболее редкая, а наиболее распространённая СУБД :)
На счёт поиска работы в родном городе. Вакансий нет, но ведь ты где-то работаешь? Или про то и речь?
С этим я не спорю.
Прекрасное замечание, его следует развить, особенно в контексте вакансионной позиции.
Но что-то мы совсем ушли в сторону от основной темы. У меня идея была в том, что с точки зрения RDD не выгодно изучать не только определённые инструменты (пусть и оптимальные для текущей задачи), но и даже некоторые теоретические основы. Зачем цепляться к несущественным деталям?
А все эти "несущественные детали" определяют направление.
Боюсь вас расстраивать, но это уже "неклассический" программист в понимании большинства, особенно работодателей.
А позицию то вы и не указали.
Ну так и развейте. Только не для идеального параллельного мира, а для нашего. И ни к чему слова зачёркивать - проекты в реальном мире бывают совершенно разные.
Это "нетипичный", а не "неклассический". Классический костюм - это не джинсы, а классическая музыка - это не рэп, не поп-музыка.
Либо уже указал через обязанности, либо термин иначе понимаю.
Например, знание того, что такое алгоритмическая сложность - базовый навык классического программиста. Но мало того, что про алгоритмическую сложность знают немногие профессиональные программисты, так ещё и в вакансиях она не указывается. Возможно, изучение алгоритмической сложности - это тоже anti-RDD.
Сколько людей, столько и мнений.
На другом популярном форуме с бурными срачами в общалке, мне не раз попадались высказывания тех, кто занимается собеседованиями и наймом на работу. Так вот, многие пишут, что если у программера нет высшего образования, то сразу от ворот поворот, не взирая на любой опыт работы и резюме. Другие пишут, что важен опыт и знания, а не бумажки дипломы.
Следующее. Когда, например, в вакансии требуется знание какого-то языка/фреймворка, то естественно подразумевается, что человек должен уметь работать с коллекциями этого языка, и выбирать подходящую в каждом конкретном случае. Т. е. знание алгоритмической сложности подразумевается само-собой. Такое незачем писать в требованиях. Это всё равно, что писать: необходимо знание алфавита. Понятно же, что это бессмыслено, ведь если человек прочёл объявление, написал резюме, то алфавит он знает.
Ещё. Перечисляя Opencv, sqlite, yacc, etc, ты называл конкретные реализации более общих технологий - компьютерное зрение, базы данных, генераторы парсеров. И почему-то счёл, что мой вариант подания информации в резюме непригоден (я предложил указывать именно владение общей технологией). Между тем, алгоритмическая сложность и О-нотация - это тоже общее знание. Тогда уж будь последователен, и пиши: требуется программист умеющий правильно выбирать способ сортировки массива, в котором от одного до двух миллионов элементов, с частично упорядоченными кусками... И если некто писал сортировку для сильно неупорядоченных массивов с количеством элементов менее миллиона, то он не подходит...
Мнэ... Перечитал написанное, сам не понял. :)
Я вот какую мысль хотел донести: если программер освоил sqlite - это значит, он освоил работу с базами данных. Значит работу с любой другой СУБД освоит всяко быстрее, чем программер, совсем не работавший с БД, Следовательно, sqlite - это тоже RDD. Годится для занесения в резюме.
Речь про то, что в одном регионе какие-то знания могут оказаться бесполезными. А в регионе, где много софтверных фирм, почти наверняка пригодятся знания любых технологий. То есть любой опыт можно смело заносить в резюме. Возможно, именно знание экзотики окажется востребованным.
Речь про то, что в одном регионе какие-то знания могут оказаться бесполезными. А в регионе, где много софтверных фирм, почти наверняка пригодятся знания любых технологий. То есть любой опыт можно смело заносить в резюме. Возможно, именно знание экзотики окажется востребованным.
Вот, кстати. Мы говорим о требованиях к сферически-вакуумном программеру или уже смотрим по реалиям?
Вот, кстати. Мы говорим о требованиях к сферически-вакуумном программеру или уже смотрим по реалиям?
Э-э... Я не понял, уточни вопрос.
Как я понял изначальный посыл Когрома, речь идёт о сферически-вакуумном программисте. Но в каждом конкретном случае срабатывают реалии, как бы нам не хотелось этого избежать.
Как я понял изначальный посыл Когрома, речь идёт о сферически-вакуумном программисте. Но в каждом конкретном случае срабатывают реалии, как бы нам не хотелось этого избежать.
Ну, собственно, это я и имею ввиду. У нас получается игра в теннис маленькой и большой ракетками. С одной стороны - аргументы о сферах и вакууме, с другой - факты грустной действительности. Может как-то конкретизируем, а то, так ни к чему и не придем.
Не обязательно. Например, для программистов, использующих скриптовые языки такое знание редко нужно. Есть список, словарь и всё. Остальное - для редких случаев, иначе код коллеги не поймут.
Я говорил про другое. Владение общей технологией - хорошо, но интересна и конкретика. А когда переходим к конкретике, то видим в скобках сомнительные инструменты.
То есть, человек впадающий в крайности - это последовательный. Зачем мне быть таким последовательным?
Частично согласен. Хотя я думаю, при RDD всё-таки в качестве СУБД будет выбираться другая, более востребованная.
И это, я не говорю о сферически-вакуумном программисте. Я говорю про реалии, когда резюме вначале проходит фильтр в виде кадрового работника. Даже если технический специалист будет философски относиться к знанию конкретных технологий (что маловероятно при командной работе), то до такого специалиста надо ещё дойти. То есть, если не знаешь популярных технологий, с помощью резюме можно обойти кадрового работника двумя способами: либо врать, либо привлекать малыми требованиями к зарплате и т.п. Понятно, что не так страшна маленькая зарплата, как место, в котором её платят. Хотя есть и исключения (знаю одно исключение, правда не из программирования).
Не знаю, у кого сферы в вакууме. Ещё полгода не прошло с тех пор, как я два месяца рассылал резюме и ходил по собеседованиям. Так что кое-какие факты грустной реальности знаю.
Один из фактов: можно написать очень краткий список изученных технологий и большой опыт - тогда позовут. Можно написать, что знаешь многие популярные технологии, но опыт маленький - не позовут, если ты уже давно не студент. А откуда опыт взять, как не из реальной работы? Вот отсюда и RDD.
Немного отклонюсь от основной темы. Конечно, прохождение собеседования зависит от многого. Например, от умения общаться и от особенностей психики. Замечал такой эффект: пока ведёт собеседование один человек - отвечаю нормально, как начинают собеседовать одновременно двое - голова отключается. Не с первого собеседования смог побороть этот эффект.
Один из фактов: можно написать очень краткий список изученных технологий и большой опыт - тогда позовут. Можно написать, что знаешь многие популярные технологии, но опыт маленький - не позовут, если ты уже давно не студент. А откуда опыт взять, как не из реальной работы? Вот отсюда и RDD.
Немного отклонюсь от основной темы. Конечно, прохождение собеседования зависит от многого. Например, от умения общаться и от особенностей психики. Замечал такой эффект: пока ведёт собеседование один человек - отвечаю нормально, как начинают собеседовать одновременно двое - голова отключается. Не с первого собеседования смог побороть этот эффект.
Сфера в вакууме у вас будет до тех пор пока вы не определитесь с конкретной вакансионной позицией (возможно даже в конкретной конторе) на которую желаете в конечном счете претендовать, пусть даже заоблачной. Тогда еще можно говорить о каком то RDD. А до тех пор это будет оставаться вакуумным резюме с набором бессмысленных букв и сокращений.
Один из фактов: можно написать очень краткий список изученных технологий и большой опыт - тогда позовут. Можно написать, что знаешь многие популярные технологии, но опыт маленький - не позовут, если ты уже давно не студент. А откуда опыт взять, как не из реальной работы? Вот отсюда и RDD.
Не берут также и с большим списком и большим опытом. Про маленький список и маленький опыт - и говорить не стоит. Поэтому дело не RDD - как таковой и прочих умных аббревиатурах. Дело только в человеке. Можно прекрасно устроиться (и работать!!!), имея лишь поверхностные представления. Это так, из наблюдений.
Немного отклонюсь от основной темы. Конечно, прохождение собеседования зависит от многого. Например, от умения общаться и от особенностей психики. Замечал такой эффект: пока ведёт собеседование один человек - отвечаю нормально, как начинают собеседовать одновременно двое - голова отключается. Не с первого собеседования смог побороть этот эффект.
Эффект известный. Еще Кафка описывал. Допросы на этом эффекте основаны. А раз смог побороть, значит научился концентрироваться на вопросе, а не на спрашивающем, а это трудно, согласен.
Хорошее описание того, как рассуждает человек, применяющий RDD :)
Я не желаю претендовать на конкретную вакансионную позицию, уж тем более в конкретной конторе. Я хочу делать качественные программы в короткие сроки. И постепенно двигаюсь к этой цели. Соответственные и инструменты выбираю, не взирая на их редкое упоминание в вакансиях. Если и другие так рассуждают, то может RDD - действительно миф и сфера в вакууме, и нечего беспокоиться.
Думаю, что эти личные наблюдения из параллельной реальности, если это не намёк на устройство по знакомству.
В общем, неудобен стал форум для таких бесед. Теперь он больше заточен на вопросы студентов. Даже в Jabber-конференции удобнее о таких темах потрындеть. Наверное, там и место.
Не правильно думаешь.
В общем, неудобен стал форум для таких бесед. Теперь он больше заточен на вопросы студентов. Даже в Jabber-конференции удобнее о таких темах потрындеть. Наверное, там и место.
Форум вообще стал НЕУДОБНЫМ. И, скорее всего, просто перестал быть форумом.