Это, конечно, не более чем идеологические детали, но интересно вы как-то упорядочили по сложности: IR < NLP. Вообще, IR область более широкая, а NLP — более узкая. Как раз на примере поисковых систем. в NLP, к тому же кроме математики есть еще и лингвистика, которая подтягивает свой набор специфических сложностей, поэтому, одной математики маловато даже будет, на самом деле. Короче, вашу идею понял. Однако, вот в чем вопрос: вот возьмем Deep learning к примеру. Кто должен разрабатывать и поддерживать библиотеки для deep learning'а — первые или вторые? Если чистые девелоперы — то им нужно четкое ТЗ с точностью до формулы. Ну окей разработали, а потом фиксы и улучшения — через оформление документа "Change request specification" аля аутсорс разработка на каждый чих? Если условные "математики" — то высокопроизводительную либу они не сделают, без знания низкоуравневой специфик и работы С++, GPU, итд. В общем, я к тому, что спрос на людей, которые знают, алгоритмы и технологии программирования все еще есть и будет.
Интересно, как автор себе представляет отбор программистов, которые будут разрабатывать не светофор на ассемблере, где нет ни одного алгоритма, а технологии типа поиска и распознавания голоса. У меня есть несколько предположений, но позволю сначала высказаться.
С первым тезисом соглашусь. А вот с надежностью и качеством в узком смысле не соглашусь. Олимпиады не учат писать код красиво и правильно, чтобы он блестел с точки зрения традиций программирования. Практически не учат объективно ориентированному дизайну, и многим другим вещам, которые востребованы в индустрии. Однако, уж чему они точно учат — это писать этот самый код в разумное время, и писать его алгоритмически корректно.
Максимально-требовательный подход к написанию кода, документации и тестов.
Возможно, вы к этому пришли поизучав код критически важных для мироздания проектов типа kernel, gcc. Это проекты production уровня, там все на уровне. А сколько еще в open source существует всего другого, криво понаписанного? Про документацию все то же самое. Даже некоторые либы высокого качества исчерпывающей документации по фичам не содержат.
В мире тысячи и миллионы человек, которые смогут вам написать второй Вконтакте, второй Фейсбук и второй Яндекс, в небезызвестной Индии есть тысячи желающих написать вам что угодно за смешные тысячу долларов.
Очень хорошая статья. Наверное, лучше и не опишешь. К слову про Scrum: возможно кто-то и играет в Scrum без тимлидов, но это создает некоторые проблемы.
спасибо за интересную статью! Имхо, самый безопасный в ожидаемой ситуации способ — закладывать стоимость рефакторинга в стоимость change request'а. Но, на моей практике были и случаи, когда непосредственно заказчику приходилось объяснять, почему нужно прямо сейчас делать рефакторинг, почему не через 2 месяца и к чему приведет обратное. В условиях наличия «компьютерной грамотности» со стороны заказчика, убедить в целом можно. К сожалению, для многих заказчиков (которые этой КГ не имеют), внедрение информационных систем и их разработка — это есть большой черный пузырь, который внешне не отличается, например, от строительства бань или продажи товаров по интернету. Построили вам баню, а потом приходят и говорят «вы знаете, архитектура этой бани недолговечна, нужно бы перелопатить все бревна». Тут ни о каком рефакторинге лучше вообще не упомянать.
Более того: не все заказчики на самом деле понимают, что нужно хотеть. Некоторые из них не понимают, что то, чего они хотят, на самом деле хотеть нельзя, потому что такое решение долго не продержится и придется его переделывать. При работе в таких условиях, работа по принципу YAGNI — есть зло. Код будет выкидываться периодически, а время проекта пожираться.
Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать.
Ага, а любую музыку желательно начинать с записи ее нот на стане.
Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.
Как только принцип YAGNI не понимают люди. Вот некоторые его понимают так «не просили — не делаю — меньше работать». В этом ли, так сказать, его суть?
В целом, не смотря на популярность этих принципов из статьи, у них у всех есть обратный эффект.
ситуация, в которой нельзя на работе писать код, соблюдая его качество хотя бы как-то — есть нездоровая ситуация, и в ней долго, имхо, лучше не находиться.
Действительно, не кажется ли автору статьи, что категории в общем-то не взаимоисключающие? Например, 6 и 4 вполне могут сочетаться. Но в целом, многие категории как-то наталкивают на представления о начинающем программисте.
sebres, спасибо за статью, c performance все более менее понятно. А вы не думали, что есть другие плюсы Scala по сравнению с Python? Например, статическая типизация. Какой размер вашей кодовой базы? (количество функций, количество классов, модули) Если расширяемость вашей кодовой базы (в смысле добавления новых функций пользовательского уровня) примерно происходит в виде «написал(три) одну новую фунцию на Питоне, которая ни от чего особо не зависит», то может быть, разницы вы не почувствуете. Но если приходится менять структуры классов, проводить рефакторинги, да и вообще, понимать, где в программе какие данные, где начала и где концы, образно говоря, верифицировать код до его запуска, то поддерживать такие программы на языках типа Python — есть не очень приятное занятие, ИМХО, если не назвать это оверхэдом.
Т.е. по вашему «приходить в 9.00 и работать до 18.00» — это корпоративная этика? :)
Про интервьюверов, которые поливают грязью — ну, лично я, допустим, их не уважаю, вы не обязаны ведь идти в организацию :)
В вашей статье одна есть хорошая мысль: " Так вот, лучшее, на мой взгляд, с чего стоит начинать работу с начинающим разработчиком — это определить границы вложений, которые готова потратить фирма на новичка, и постараться оформить отношения с новичком так, чтобы не только фирме, но и ему было невыгодно выходить за эти границы.
"
Остальное попахивает эмоциональной полемикой. Начнем с того, что задача HR в том и заключается, что он пытается понять степень адекватности и честности кандидата. Вы же пишите, что он делает предположение, что все кандидаты честные.
Затем, о честности вы написали, но потом пишите, что «зачем мне сидеть на парах — если я там все знаю». :) Соблюдение правил огранизации, будь то компания по производству софта или ВУЗ — это как раз одно из проявлений честности и ответственности, про которую Вы также пишите. Порядок начинается с этого.
цитата: Скажите, какие задачи стоят перед программистом, кроме как «писать код» или «обучать джуниора» (прости, Господи!)? Хотя сюда можно включить, напрмер, решение проблем со звуком и видео, но вот кто мог бы расширить этот список?
В этом предложении заключено все знание HR'ов о работе программистов. а именно: чуть более, чем «никрена».
Давайте порассуждаем конструктивно: вы же HR, и наверняка и Вас и ваших технических коллег распрашивают про вакансию, которую вы разместили. Не задумывались, почему это делают? Потому что вакансий, где нужно просто «писать код», как вы выразились, их миллион. Однако, для специалиста одна работа «писать код» будет интересной, а другая работа «писать код» может быть совершенно неподходящей. Если бы в вакансиях освещался хотя бы примерный scope работы — было бы гораздо проще всем.
Как можно не любить С++, но при этом любить С, а самому программировать на Сишарпе — для меня загадка. Странные у вас предрасположенности. Язык С, я считаю, не имеет права находится вообще в этом обсуждении, поскольку имеет ограниченную сферу применения.
C# не решает любую задачу соразмерно своей сложности, поскольку содержит overhead и набор протекающих абстракций, о которых вы сами здесь и говорите. Вообще, я бы сначала подождал, пока вы сделаете несколько проектов разноплановых, и потом я бы с вами поговорил. У вас есть некоторое знание технологий, но только этого мало, чтобы на столько категорично рассуждать.
Возможно, вы к этому пришли поизучав код критически важных для мироздания проектов типа kernel, gcc. Это проекты production уровня, там все на уровне. А сколько еще в open source существует всего другого, криво понаписанного? Про документацию все то же самое. Даже некоторые либы высокого качества исчерпывающей документации по фичам не содержат.
Ну это от лукавого.
Ага, а любую музыку желательно начинать с записи ее нот на стане.
Как только принцип YAGNI не понимают люди. Вот некоторые его понимают так «не просили — не делаю — меньше работать». В этом ли, так сказать, его суть?
В целом, не смотря на популярность этих принципов из статьи, у них у всех есть обратный эффект.
Про интервьюверов, которые поливают грязью — ну, лично я, допустим, их не уважаю, вы не обязаны ведь идти в организацию :)
"
Остальное попахивает эмоциональной полемикой. Начнем с того, что задача HR в том и заключается, что он пытается понять степень адекватности и честности кандидата. Вы же пишите, что он делает предположение, что все кандидаты честные.
Затем, о честности вы написали, но потом пишите, что «зачем мне сидеть на парах — если я там все знаю». :) Соблюдение правил огранизации, будь то компания по производству софта или ВУЗ — это как раз одно из проявлений честности и ответственности, про которую Вы также пишите. Порядок начинается с этого.
Сарказм 90-го левела.
В этом предложении заключено все знание HR'ов о работе программистов. а именно: чуть более, чем «никрена».
Давайте порассуждаем конструктивно: вы же HR, и наверняка и Вас и ваших технических коллег распрашивают про вакансию, которую вы разместили. Не задумывались, почему это делают? Потому что вакансий, где нужно просто «писать код», как вы выразились, их миллион. Однако, для специалиста одна работа «писать код» будет интересной, а другая работа «писать код» может быть совершенно неподходящей. Если бы в вакансиях освещался хотя бы примерный scope работы — было бы гораздо проще всем.
C# не решает любую задачу соразмерно своей сложности, поскольку содержит overhead и набор протекающих абстракций, о которых вы сами здесь и говорите. Вообще, я бы сначала подождал, пока вы сделаете несколько проектов разноплановых, и потом я бы с вами поговорил. У вас есть некоторое знание технологий, но только этого мало, чтобы на столько категорично рассуждать.