Ну вот опять, набежали комментаторы :), которые путают сложность решаемых задач с качеством подхода к работе.
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
Как уже сказали выше, без подписи исходники не нужны для того, чтобы скомпилировать модифицированную версию.
А тут ни подписи, ни обфускации… никакой защиты.
Что-то ни eset, ни drweb не упомянули, имела ли бэкдорная либа цифровую подпись?
Если да, то внедрить коня без доступа к билд-серверу или полным исходникам не получилось бы. А если подписи нет… то бардак и несоблюдение базовых правил публикации, привели к возможности вот так влёгкую заразить всё и вся…
Как говорится, вот только не надо обобщать.
В моём случае на качество сна кофе не влияет от слова никак. Совершенно спокойно могу выпить чашечку и тут же лечь спать (более того, если я сильно ментально утомлён, то спать захочется немедленно). И бодрость поутру будет завить только от того, сколько я спал и чем занимался накануне :)
Всё же, тут многое зависит как от индивидуальной биохимии организма, так и от личного энергобаланса. И мои наблюдения подсказывают, что изменить и то и другое может и можно, но в большинстве случаев крайне сложно… и очень трудно найти новый баланс. Но это не считая тех, кто неэффективно использует свои ресурсы.
Это вот то самое! Кого именно называть программистом? Дайте однозначное определение, и можно будет сделать перечисление тех самых базовых навыков. А без этого, ответ один — программист должен, как минимум, уметь программировать ;)
Я может по сути уже давно и не программист, но до сих пор пишу код, и этот код работает хорошо и приносит заказчику прибыль, а коллегам не приносит лишней головной боли… Но даже если брать времена весьма далёкие, я также, как и сейчас, почти не сталкивался с потребностью явно писать сложные алгоритмы. И мой продукт не был хуже от того, что я не знал эти алгоритмы.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать из массивасписка элементы, для которых выполняется бизнес-условие, и преобразовать элементы в другой вид». В большинстве случаев никакие пред-сортировки и прочие шаманства не дадут ничего, кроме лишнего кода. А оптимизации чаще всего лежат на несколько уровней выше конкретного участка кода…
И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?
Да уж… На столь хилом примере не показать пользу от ExpressionVisitor, да и мощь ExpressionTrees не раскрыта.
Тем более, что способ использования… не слишком очевиден, попахиает шаманством :)
Я недавно решал в чём-то схожую задачу: делал фильтр для js-грида. В используемом мной гриде был встроенный механизм автофильтров, но работал только на клиентской стороне, а мне очень хотелось не тащить ни клиента лишние данные… Итогом стал универсальный механизм фильтрации на стороне сервера, работающий для любых данных. Со стороны клиента прилетает список фильтров «имя поля/тип фильтра/фильтрующее значение», а коде контроллера получается что-то вроде
IQueryable<T> source = DAL.GetQuery<T>();
IQueryable<T> data = source.ApplyFilter(filters);
Если интересно — могу код выложить и статейку по это набросать.
Ох уж этот вечный холивар…
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и façade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
Немного поддержу автора…
Видно что наболело. Но, тем не менее, такая классификация, как и любая другая имеет смысл, если она даёт возможность оптимизировать процесс. Да, грубовато и неоднозначно, но в целом понятно.
А теперь немного поспорю :)
Всё же, не всё так просто с «врождённостью». Да, есть некое специфическое «воспитание» личности, из-за которого человек будет стремиться к тому или иному привычному способу участвовать в работе. Но, всё же, двигать человека по такой шкале вполне возможно. И это таки задача и даже талан управленца персоналом, сделать так, чтобы в наполнение коллектива разными «характерами» было оптимально. И чем выше требуемая для работы квалификация, тем ценнее возможность предоставить работнику ту позицию, на которой он будет наиболее эффективен, чем просто менять каждый раз на нового.
А есть и ещё более интересные примеры. Тут из личного опыта.
Был момент, когда я сидел на работе по 30-40 часов, но за полтора месяца в одиночку сделал то, что, по идее, должны были делать три человека два месяца. Больше я такие эксперименты не повторял, но, по предложенной шкале я был «героем». Чуть позже там же я был очень ценным «специалистом», при необходимости выскакивая в «герои». Но работа была интересна и с мотивацией было хорошо.
Попозже, на другой работе, я колебался от «пофигиста» до «героя», в зависимости от текущих задач и мотивации.
Так что, эти характеристики совсем не врождённые. И поработав со многими, неоднократно участвуя в формировании команды, для себя сделал такой вывод (приведя его к предложенной схеме): в ИТ-команде желательно иметь колеблющегося героя — ему спасать аврал и преодолевать неординарные вызовы, толпу специалистов — им делать большую часть работы, но и без пофигистов не обойтись — они хороши на скучных задач, за которые лучше совсем не сажать героя, а спецы долго не протянут… Наличие всех остальных — ошибка в управлении проектом и командой.
Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
Тоже, что ли, поделиться… за последние полгода посетил несколько десятков компаний в Москве…
(для уточнение — стэк .net, опыта 15 лет, позиция не ниже ведущего разработчика)
Раздражающие факторы в организации собеседований:
— неполная инструкция к тому, как же найти офис/кабинет/человека. Например: офис в большом бизнес-центре, три здания, ни слова о том, в какое соваться, или нужный вход только с другой улицы да из подворотни.
— отсутствие готовности места/собеседующих. Было и так, что 15 минут ищем, куда бы присесть, потом ещё полчаса собираем тех, кто же хотел меня лицезреть. И это при том, что заранее было оговорено, что времени у меня — час на всё про всё.
— и да, нелепые рукописные анкеты, которые сильно проще было бы заранее заполнить на компьютере.
Печальные факторы:
— нелепые тесты из задачника «как никогда не надо писать код», типа что выведет этот код. Очень хочется сказать «если я такой код увижу в своём проекте, выкину его нафиг», и да, часто так и говорю.
— туда же алгоритмические задачки из разряда «есть решение у гугле на первой странице» и совершенно точно не нужные в реальной работе.
— вопросы из серии «самые редковстречаемые особенности» языка/технологи. Судя по тону спрашивающего — токмо с целью доказать собственное превосходство.
— или как вариант вопросы про азы, которые я уже давно забыл ввиду неиспользуемости нигде, кроме как в начальных туториалах.
Совсем печальные:
— предложение написать тестовое задание-приложение. Да, некто у них там наспор пишет его за 3-4 часа. А я, значит, должен угадать, какой из двух-трёх десятков возможных вариантов решения их удовлетворит.
— уходящие с тень HR-ы. Все клятвенно обещают обязательно перезвонить, даже в случае ядерной войны… Но некоторые умудряются даже переставать отвечать на звонки.
— и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
А тут ни подписи, ни обфускации… никакой защиты.
Если да, то внедрить коня без доступа к билд-серверу или полным исходникам не получилось бы. А если подписи нет… то бардак и несоблюдение базовых правил публикации, привели к возможности вот так влёгкую заразить всё и вся…
В моём случае на качество сна кофе не влияет от слова никак. Совершенно спокойно могу выпить чашечку и тут же лечь спать (более того, если я сильно ментально утомлён, то спать захочется немедленно). И бодрость поутру будет завить только от того, сколько я спал и чем занимался накануне :)
Всё же, тут многое зависит как от индивидуальной биохимии организма, так и от личного энергобаланса. И мои наблюдения подсказывают, что изменить и то и другое может и можно, но в большинстве случаев крайне сложно… и очень трудно найти новый баланс. Но это не считая тех, кто неэффективно использует свои ресурсы.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать из
массивасписка элементы, для которых выполняется бизнес-условие, и преобразовать элементы в другой вид». В большинстве случаев никакие пред-сортировки и прочие шаманства не дадут ничего, кроме лишнего кода. А оптимизации чаще всего лежат на несколько уровней выше конкретного участка кода…И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?
Тем более, что способ использования… не слишком очевиден, попахиает шаманством :)
Я недавно решал в чём-то схожую задачу: делал фильтр для js-грида. В используемом мной гриде был встроенный механизм автофильтров, но работал только на клиентской стороне, а мне очень хотелось не тащить ни клиента лишние данные… Итогом стал универсальный механизм фильтрации на стороне сервера, работающий для любых данных. Со стороны клиента прилетает список фильтров «имя поля/тип фильтра/фильтрующее значение», а коде контроллера получается что-то вроде
IQueryable<T> source = DAL.GetQuery<T>();
IQueryable<T> data = source.ApplyFilter(filters);
Если интересно — могу код выложить и статейку по это набросать.
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и façade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
Видно что наболело. Но, тем не менее, такая классификация, как и любая другая имеет смысл, если она даёт возможность оптимизировать процесс. Да, грубовато и неоднозначно, но в целом понятно.
А теперь немного поспорю :)
Всё же, не всё так просто с «врождённостью». Да, есть некое специфическое «воспитание» личности, из-за которого человек будет стремиться к тому или иному привычному способу участвовать в работе. Но, всё же, двигать человека по такой шкале вполне возможно. И это таки задача и даже талан управленца персоналом, сделать так, чтобы в наполнение коллектива разными «характерами» было оптимально. И чем выше требуемая для работы квалификация, тем ценнее возможность предоставить работнику ту позицию, на которой он будет наиболее эффективен, чем просто менять каждый раз на нового.
А есть и ещё более интересные примеры. Тут из личного опыта.
Был момент, когда я сидел на работе по 30-40 часов, но за полтора месяца в одиночку сделал то, что, по идее, должны были делать три человека два месяца. Больше я такие эксперименты не повторял, но, по предложенной шкале я был «героем». Чуть позже там же я был очень ценным «специалистом», при необходимости выскакивая в «герои». Но работа была интересна и с мотивацией было хорошо.
Попозже, на другой работе, я колебался от «пофигиста» до «героя», в зависимости от текущих задач и мотивации.
Так что, эти характеристики совсем не врождённые. И поработав со многими, неоднократно участвуя в формировании команды, для себя сделал такой вывод (приведя его к предложенной схеме): в ИТ-команде желательно иметь колеблющегося героя — ему спасать аврал и преодолевать неординарные вызовы, толпу специалистов — им делать большую часть работы, но и без пофигистов не обойтись — они хороши на скучных задач, за которые лучше совсем не сажать героя, а спецы долго не протянут… Наличие всех остальных — ошибка в управлении проектом и командой.
Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
(для уточнение — стэк .net, опыта 15 лет, позиция не ниже ведущего разработчика)
Раздражающие факторы в организации собеседований:
— неполная инструкция к тому, как же найти офис/кабинет/человека. Например: офис в большом бизнес-центре, три здания, ни слова о том, в какое соваться, или нужный вход только с другой улицы да из подворотни.
— отсутствие готовности места/собеседующих. Было и так, что 15 минут ищем, куда бы присесть, потом ещё полчаса собираем тех, кто же хотел меня лицезреть. И это при том, что заранее было оговорено, что времени у меня — час на всё про всё.
— и да, нелепые рукописные анкеты, которые сильно проще было бы заранее заполнить на компьютере.
Печальные факторы:
— нелепые тесты из задачника «как никогда не надо писать код», типа что выведет этот код. Очень хочется сказать «если я такой код увижу в своём проекте, выкину его нафиг», и да, часто так и говорю.
— туда же алгоритмические задачки из разряда «есть решение у гугле на первой странице» и совершенно точно не нужные в реальной работе.
— вопросы из серии «самые редковстречаемые особенности» языка/технологи. Судя по тону спрашивающего — токмо с целью доказать собственное превосходство.
— или как вариант вопросы про азы, которые я уже давно забыл ввиду неиспользуемости нигде, кроме как в начальных туториалах.
Совсем печальные:
— предложение написать тестовое задание-приложение. Да, некто у них там наспор пишет его за 3-4 часа. А я, значит, должен угадать, какой из двух-трёх десятков возможных вариантов решения их удовлетворит.
— уходящие с тень HR-ы. Все клятвенно обещают обязательно перезвонить, даже в случае ядерной войны… Но некоторые умудряются даже переставать отвечать на звонки.
— и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.