Комментарии 184
Но когда на позицию мидла приходят с резюме сеньора и знаниями джуна — это тоже не ок.
По моему личному опыту на 5 собеседуемых — 4 себя переоценивают.
Если Вам за себя не стыдно — Вы плохо себя знаете.
Так и пожалуйста — пусть переоценивают. Обстоятельства все расставят на свои места. А вот робкий и недооценивающий себя просто не попадет в обстоятельства.
Во фронте все кругом сеньоры, а на вопрос про то, что такое SOLID никто ответить не может :(
А загвоздка в том, что правила solid сформулированы весьма абстрактно. И потому без практического опыта их применения они бесполезны и даже вредны (если закрутить гайки и следовать написанному в абсолюте, проект становится фрагментированным, нечитабельным и никогда не заканчивается).
А я вижу в нем набор букв, который бесполезен, если ты заранее не знаешь как делать.
Заранее можно знать, если у тебя есть какой-то опыт. У этого набора букв есть значение. Есть множество книг, которые объясняют что и как, причём с примерами. А сама аббревиатура, это больше запоминалка что ли.
Это довольно очевидно, что просто прочитав расшифровку, сколь бы то ни было эффективно применять вы этот набор принципов не научитесь. Нужно читать книги, общаться с другими разработчиками, практиковаться и т.п. И да, на этом пути будет куча ошибок. Но ведь есть менторство, допустим, есть позиции начинающих разработчиков. Так что я считаю, что лучше пытаться применять лучшие практики с самого начала, чем вообще не обращать на них внимания и не знать о существовании. А то потом у людей с десятилетним стажем наступает прозрение вроде: «Оу, а это уже унифицировано и так нужно делать, да?».
Стаким же успехом момжно ввести принципе «Не быдлокодь!». А что, он куда более универсален. Зачем нам dry, solid, kiss, если он уже все это в себя включает?
Очень странно, что приходится это объяснять, но «Не быдлокодь!» — это абстракное высказывание, которое не подразумевает конкретного набора практик и т.п. К тому же ещё и понятие строго не детерминировано. Т.е. абсолютно бесполезное наставление. А вот всякие там dry, kiss, yagni, solid и т.д. подразумевают набор вполне конкретных практик.
А загвоздка в том, что правила solid сформулированы весьма абстрактно.
Да, опыт практического применения важен, и без него никак. Но я бы не сказал, что все правила SOLID сформулированы абстрактно. Наверно всё, кроме Open/Closed сформулировано очень даже конкретно. Да и то, потому что стабильность API — дискуссионная тема.
Возьмём хотя бы SRP: "The single responsibility principles is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.". Что тут абстрактного-то? Конечно всегда есть простор для фантазии, но как по мне, так вполне себе конкретно.
И потому без практического опыта их применения они бесполезны и даже вредны (если закрутить гайки и следовать написанному в абсолюте, проект становится фрагментированным, нечитабельным и никогда не заканчивается).
Хотелось бы увидеть примеры, если это возможно.
Заранее можно знать, если у тебя есть какой-то опыт. У этого набора букв есть значение. Есть множество книг, которые объясняют что и как, причём с примерами. А сама аббревиатура, это больше запоминалка что ли.Тут такая вещь. Ее видят не как запоминалку, а как центр мироздания и откровение с небес. Соответственно, если ты класть хотел на красивые аббривеатуры, то ты другой религии и предан анафеме.
Т.е. важно не умение применять эти принципы, а умение помнить аббривеатуру.
Очень странно, что приходится это объяснять, но «Не быдлокодь!» — это абстракное высказывание, которое не подразумевает конкретного набора практик и т.п.Как в некоторой степени и SOLID. Просто уровень абстракции разный.
А вот всякие там dry, kiss, yagni, solid и т.д. подразумевают набор вполне конкретных практик.Я мог бы согласиться с dry. Но даже тот же kiss требует дополнительных разъяснений и опыта. С одной стороны, вот что такого сложного в том, чтобы все упростить? А с другой, просто это как? Фрагментировать приложение на крохотные модули, от которых черех минуту начинает рябить в глазах потому что их слишком много? Но они простые, да. И разобраться в них можно тоже просто. Только если надо сделать более-менее значимое изменение коммит получится файлов на 100 (автор применяет прием гипербола, не пытайтесь повторить в домашних условиях).
Что тут абстрактного-то? Конечно всегда есть простор для фантазии, но как по мне, так вполне себе конкретно.Думаю, вполне можно найти людей, которые скажут «вот у этого класса единственная задача — обслуживать REST API». И вкатают туда и логику, и работу с базой и еще Гейтс знает что. Чо, апи ж надо. Да, это опять гипербола. Все-таки реальные примеры будут куда тоньше.
Самая ГЛАВНАЯ проблема с ними в том, что без использования этих правил/принципов они писали код, который попросту нормально не работал — куча ошибок и непродуманных ситуаций. Причем в этой компании бизнесу без разницы какие они клевые, а главное, чтобы задача была выполнена и работала. Но частые ошибки приводили к возврату задач, а далее топы увольняли их, и потом мы переписывали все сами.
Брали человека, который ответил на все мои вопросы. Он мог исправить любую проблему и написать готовый код, который в будущем легко масштабируется и не содержит ошибок. Правда ушел позже на более интересный проект.
Все эти теоретические знания, шаблоны, принципы не просто так придумываются, а для решения многих проблем разработки. И если человек этого не знает, он будет вновь и вновь сам для себя их открывать по мере развития.
Ну а остальное это анекдот. Его, увы, за правило нельзя принять.
Я согласен, что эти принципы проектирования можно частично рассматривать как метрики качества кода. Т.е. приложение, спроектированное с учётом этих принципов обладает определённым качеством. Но почему вы решили, что это только метрики?
Потому что невозможно строить ООП модель, думая: ...
Почему вы так считаете? Можете ли привести примеры, когда SOLID явно мешает проектированию модели? Или всё что вы написали — это только ваше личное мнение?
Я бы даже сказал, что этот набор принципов даже помогает строить хорошо декомпозированную модель, хотя бы за счёт SRP. Ну и за счёт остальных принципов простота поддержки и расширяемости только улучшится.
Solid это очередной пересказ истории про coupling и cohesion
Вообще, про это ну от силы три из принципов SOLID. Но опять же, никто не мешает вам воспринимать эти вещи, как взаимодополняющие.
Только у него бОльшие амбиции благодаря маркетинговому шиту от Дяди Боба. Я уже про это писал, посмотрите у меня в комментариях, если интересна противоположная тз.
Ну вы хоть ссылку дайте, не буду же я ради этого все ваши комментарии пролистывать…
Можете ли привести примеры, когда SOLID явно мешает проектированию модели?По-моему вам явно написали, что он не помогает это сделать, а не мешает. Я так уверен, если применить несколько других инструментов, можно и размахивая СОЛИДолом что-то наварганить. Только зачем вам СОЛИДол, если есть другие инструменты?
PS Было у меня как-то забавное собеседование, не знаю толи меня завлить пытались, толи просто собеседующий тупил (имхо, этот вариант был более вероятен). В общем, спросили у меня алгоритмическую сложность поиска элемента в двоичном дереве. Я ответил, что логарифмическая, собеседующий же спросил основание логарифма. Я попытался объяснить, что основание логарифма в данном случае роли не играет, т.к. дает просто мультипликативную константу. На что мне начали рассказывать, что это очень важно, даже приводили какие-то лютые примеры типа вот мы увеличили входные данные в 10 раз, значит время работы увеличится в log_2(10) раз. В итоге, когда меня позвали на второй этап я тупо отказался. В общем, к чему я это всё — собеседование процесс обоюдоострый — не только работодатель оценивает работника, но и работник оценивает работодателя.
Такое поведение контр-продуктивно, но иногда позволяет сохранить нервную систему когда потратил много сил на дорогу, например.(я про кейс выше а не про ваш)
Зачем тратить свое и чужое время?
Если я правильно понимаю, человек скомпенсировал ущерб, нанесенный его вере в разумность людей, превратив глупую ситуацию в забавную.
Зачем тратить свое и чужое время?
Может я «Робин Гуд» или, наоборот, моральный урод — какая тепереча разница, когда я потратил время на то, что как-то готовился к собеседованию, в том числе морально, приехал, нервничал, всё такое… а вместо ожидаемого адекватного обсуждения меня встречает неадекват. Ну чёрт с ним, потрачу ещё час, но дам сдачи.
Кстати, как бы ни было удивительно (хотя, я наоборот считаю, что это логично), на все работы, куда меня брали легко и непринуждённо, — были такие же и собеседования без занудства и идиотских вопросов, скорее в формате неформального трёпа о жизни и IT.
были такие же и собеседования без занудства и идиотских вопросов, скорее в формате неформального трёпа о жизни и IT.Это лучшие компании! :)
Точно также нанимался сам и осуществлял найм.
Успешность диалога не просто неудивительна, она очевидна(должна быть).
На мой взгляд, самое ценное в соискателе — его опыт: послушать про косяки, интересы, технологии, рассказать о компании, о команде, сформулировать задачи из реального опыта и требований к вакансии.
Самое интересное (думаю, большинство согласится), что даже уровень оклада становится менее принципиальным вопросом, если собеседование действительно к себе располагает.
Встречи по 40 минут с задачками из интернета кажутся какой-то шуткой, ведь самое худшее в задачках то, что при желании их можно выучить наизусть, делая их полностью бесполезными для отсеивания плохих программистов, но заставляя отсеивать хороших, а 10-15 минут "обсудить детали" ну никак не может хватить для создания обоюдного, здорового впечатления о работе.
На что мне начали рассказывать, что это очень важно, даже приводили какие-то лютые примеры типа вот мы увеличили входные данные в 10 раз, значит время работы увеличится в log_2(10) раз.Тоже неоднократно сталкивался с подобным бредом. Это справочный материал, нас учили где и как это можно найти. Если занимаешься подобным ежедневно, то — да: ты это помнишь, ценишь и знаешь разницу log2(n) и ln(n). А так всегда можно подсмотреть за 2-3 мин в википедии.
Но кому-то возможно такое собеседование подходит: либо хорошо запоминают, либо сразу занижают требования и нанимаются на позицию джуна, где требования ниже, а потом растут до сеньора по результатам работы без дурацких собеседований. У нас так несколько джунов получили работу в компании, куда я пяток раз не смог попасть на должность сеньора. :) Но гордость и уверенность в себе не позволяла снижать планку ни по уровню проекта ни по зп, потому эту компанию и ей подобные послал давно далеко и на долго.
Если занимаешься подобным ежедневно, то — да: ты это помнишь, ценишь и знаешь разницу log2(n) и ln(n).В том-то и дело, что тут разницы нет. Когда говорят логарифмическая сложность алгоритма то имеют ввиду, что время работы алгоритма равно O(ln(n)). А O(ln(n)) = O(log_a(n)) при любом положительном a не равном 1. Отсюда и получаем, что в данном случае основание лографма роли не играет. Так что это не справочный материал, это не понимание человеком сложности алгоритма.
А вот на следующий этап время тратить уже точно смысла нет.
ИМХО если человек спросил более точную оценку О() то нет необходимости объяснять ему как соотносятся логарифмы с разными основаниями.
Это значит более широкий класс функций под О(), например включить менее бастрорастущие множители или константы входящие в оценку сложности. Могу сильно ошибиться (не смог сейчас нигде найти это) но в вашем случае точнее это — "пол" log2(n), причём аргумент логарифма тоже можно усилить. Имхо не стоит гнать на интервьюера, его вопрос не технический а скорее на кругозор или даже культуру программиста.
Ну я вроде это и написал) только не соглашусь про безграмотность. О() нотация позволяет "ограничиться" самым быстрорастущим множителем (и константное слогаемое идёт первым на вылет), но интервьюер попросил уточнить и там есть что уточнять.
O(n) — это сложность каждого for, а так как тут 2 раза, то O(2n), но константу отбрасываем, поэтому O(n).
Это как в школе на уроке математики — просто ответа не достаточно, интересен путь, каким вы получили этот ответ.
И да, O(n) + O(n) = O(n) без всяких дополнительных шагов в виде O(2n). Необходимость вводить O(2n) — это как раз неумение оперировать O-нотацией напрямую. Все равно что писать 2 + 2 = 4 + 0 = 4.
У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.
На каждый тупой вопрос с его стороны у меня найдётся ещё более тупой контрвопрос.
Только локально, скармливаете утилите папку с разнородными проектами, а она вам выдаёт CV с описанием того, насколько изощрённые подходы вы умеете использовать в работе.
Заодно, прогоняет статический анализ кода, вычисляя качество кода в вакууме :)
В расчет видимо шли использованные в репозиториях языки, что-то более конкретное уже не помню.
У меня, например, на гитхабе только питонячий скрипт для бэкапа серваков, а занимаюсь я разработкой под андроид.
Вполне возможно, что это был getcoder.io. Только почему-то их сайт больше не открывается, хотя они мне как-то писали. http://www.innopolis.com/business/residents/getcode/
На том сервисе текста-воды (на удивление он мне тогда осмысленным показался) было на 1-1.5 экрана. Довольно забавно было, что в то время я практически не разбирался в гите и залил в один репозиторий консольной утилиты на 5 строк (в буквальном смысле) исходники ru.wikipedia.org/wiki/Tiny_C_Compiler и в итоге большая часть текста описывала какой я крутой с разработчик.
На getcode (опять же судя по страницам из кеша) просто перечисление проектов.
есть такая штука уже для github
Или вот, например, я — SAP Basis Administrator.
Разработчиком тоже был. Но как то не срослось.
1) В 1с, что сами понимаете… Из не 1с опыта то что работает в продакшене это только крошечная компонента на плюсах и нативное приложение под андроид которое работает как довесок к 1сной мобилке. И то и то на пару сотен строк.
2) Из парадигм программирования знаком только с процедурным подходом и немного с ООП. Функциональное? Аспектное? Логическое? Еще какие то? Не а.
3) Познания в алгоритмах на уровне книжек «грокаем алгоритмы» и «теоретический минимум по CS», при этом нельзя даже сказать что я действительно их до конца понял, например с динамическим программированием почти никак, да и вообще.
4) Познания в математике на уровне выпускника сельской школы. В школе то мне математика нравилась, да и егэ сдал неплохо, вот только выбрал экономический факультет с/х академии и в итоге и там ничего почти не изучил, и школу подзабыл.
В итоге записан как старший программист 1с, а по факту джун (и то, сейчас начал активно учиться так как хочу уйти джуном в андроид, но просто по требованиям не пройду).
Да и даже в 1с самый большой проект над которым работал в команде был на 3-4к часов, команда из всего 6 программистов, а пользователей всего 1000 обычных и 2к мобильных (спасибо тому что нужно было мобилку писать, как раз там немного еще разобрался в работе с http, рест api и именно там покодил маленько на плюсах под винду и java под андроид.). Даже по меркам 1с это скорее средний проект чем крупный.
P.S. Ушел в аргументацию, но основной тезис наверно не очень явно виден: Не всяк сеньер что на бумажке сеньер.
Вы довольно часто себя хайрите в комментариях к постараюсь подобной тематики, перестаньте это делать и перечитайте статью
Кстати спасибо, добавлю плюсик к своей черте эгоцентризм, я о ней и так знал, но почти не акцентировался.
P.S. По поводу часто — по моему комментарии такого рода статьям к трем оставлял, что на фоне моих 1.3к каментов не так уж много. Просто они все проскакивали недавно)
P.P.S. До меня дошло что вы имели в виду под словом «хайрите») Не тот случай, возможно нотки тщеславия в посыле моем и были, но точно не по этой причине, а как раз из эгоцентризма, о чем я выше писал. «Хайриться» мне нет смысла из за недостаточности навыков и очень ограниченной локации. Вероятность что это сообщение увидит кто то из моего города занятый в той сфере куда собираюсь валить, да еще и заинтересовавшийся джуном-свитчером — ну такая, около нуля где то).
Если жители НЕ СНГ идут на работу с лозунгами «Не сцать! Если чего-то не знаю, то по ходу дела научусь!», и в большинстве случаев примерно так и получается.
То жители СНГ постоянно думают «Ну вот ещё чуть-чуть подучу и можно попробовать пройти собес на джуна», что в итоге даёт 20-30 лет опыта на одном месте и карьерное загнивание.
И еще я против того чтобы оценивать себя так как записан в трудовой. Потому что сеньер где нибудь в провинции и джун/мидл в jetBrains или яндекс это 2 большие разницы.
Не всяк сеньер что на бумажке сеньер.
Вы сделаете этому миру просто огроменное одолжение, если строго формализуете понятие «сеньёр», чтобы ни у кого больше не оставалось сомнений, кем такового называть и как его выделить из толпы.
По крайней мере мои оценки крутятся вокруг этого. Да, я по своим критериям до сеньерства не доберусь никогда. Но есть у меня подозрение что и многие «сеньеры» по трудовой тоже.
Лично я по своим критериям хорошо если до мидла доползу. При том что сравнивая себя просто со средним программистом на рынке я где то между джуном и начинающим мидлом кручусь возможно, если просто по рынку прикидывать — то это трудно, я пока за всю жизнь всего на одном собеседовании был, 4 года назад.
Стандарта в этой градации нет. Каждый называет, как ему хочется. Оттого и постоянные срачи.
Мне нравится разделение по уровню ответственности:
- Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
- Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
- Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
— может быть разработчик бэка (а может и не быть а ТЗ требует хоть чего то похожего на бэк)
— есть дизайнер
— есть менеджер
— и есть — я как разработчик мобильной части. Все технические решения по проекту (или все кроме бэка) — на мне, и приходится заказчику иногда говорить что работать не будет по какой то причине.
А если это мой личный пет-проект (которым тем не менее люди пользуются)? -:)
Я не понимаю… Что плохого в 1С? Замечательная среда разработки, логичная и удобная. Начиная с экзаменов на специалиста учат писать правильный эффективный код, делать правильные эффективные sql запросы к БД. Система сделана по майкрософтовским стандартам, от нее не возникает ощущения сделанности на коленке, как от большинства фронтэнд и бекэнд фреймворков, кроме опять же майкрософтовских.
У вас непонятные комплексы начинаются уже со среды только потому, что какие-то умственно отсталые сказали вам, что программист 1С не программист.
Я не понимаю… Что плохого в 1С? Замечательная среда разработки, логичная и удобная.
Гм, что плохого в 1с я еще и чуть дальше опишу, пока могу лишь сказать что она слишком ограничена и чрезмерно заточена на решение определенного круга задач. На счет «удобная» — это же такой сарказм был?
Начиная с экзаменов на специалиста учат писать правильный эффективный код, делать правильные эффективные sql запросы к БД.
Я что то пропустил и в 1сных учебных центрах и на разных курсах (не от серебряной пули, которые даже сами себя гиками называют) теперь рассказывают про построение архитектуры, грамотную декомпозицию, абстракцию, юнит и интеграционные тесты, управление зависимостями, CI/CD процессы, о чистом коде, паттернах «обычных» и архитектурных и парадигмах программирования? Недавно коллега эксперта получил — рассказывал что во время подготовки он почти никак не продвинулся как программист, все что он изучил это детали работы 1с и по сути стал ближе к DBA.
Сам спец тоже всему чему учит это не программировать а решать конкретный набор задач, крайне ограниченной сферы.
По сути в 1с мы ограничены одной парадигмой программирования: процедурной. Есть там пара элементов ООП, но именно что пара элементов. Сколько 1сников (кроме опять же серебряной пули и ее коммьюнити, небольшого очень) способны взять и написать что то не на 1с? Не на коленке а поддерживаемое, с грамотной архитектурой и т.п.? Подозреваю число это около нуля. Я вообще не приемлю подхода когда программист должен в первую очередь понимать только один фреймворк и предметную область, а на технические навыки, алгоритмы, архитектуры просто забить. Это получается не нормальный программист, а программист «на языке», даже скорее «на фреймворке». Что раздражает — многие из таких программистов почему то себя считают сеньерами.
Вот снова взять меня: я первые 2-3 года работы как раз и думал что все нормально и так и должно быть, учился себе 1с, иногда на хабр заглядывал, правда редко в технические статьи. Все казалось веселым и радужным. А потом вот решил почитать грамотных книг которые как говорится «must read» для любых программистов, начал более активно читать хабр, слушать подкасты (Радио-Т, The Art of Programming, Podlodka, Solo on .Net, devzen, SDCast, hexlet), и понял насколько же сильно заблуждаюсь что чему то научился или что в 1с что то крутое делают. Да из того что я сделал за свои 4 года работы я могу ограниченно гордиться всего парой вещей. И обе были написаны в порыве вдохновения в сумме за несколько дней, и то в них куча всего что можно было бы улучшить, а одна из них и вовсе бы не понадобилась будь архитектура решения другой (мыж1сники? — сказал мне менеджер, некогда писавший код, — ну значит ты фигней страдаешь когда говоришь что нужен грамотный человек желательно работавший с мобилками или писавший api для них. 3к мобильных пользователей — ну значит будет 3к узлов плана обмена).
пока могу лишь сказать что она слишком ограничена и чрезмерно заточена на решение определенного круга задач
Мне непонятна эта фраза. 1С — это полноценная среда разработки учетных приложений любых видов с оконным и вэб-интерфейсом. В чем именно оно вас ограничивает? Длл на нем писать не можете? 3D Игры? Любой вэб-сайт, связанный с продажами, например стандартный интернет-магазин, это учетное приложение, и создание его серверной логики на 1С в разы быстрее, чем на любом из известных мне фреймворков, потому что:
1) Чтобы создать иерархический список, вам нужно просто несколько раз ткнуть мышкой в конструкторе, задав поля и определив уровень иерархии. Время — 5 минут, после чего вы получаете:
а) дефолтную форму списка с иерархическим деревом, со всеми возможными отборами, сортировками, а в управляемом приложении еще и с группировками
б) дефолтную форму элемента
в) автоматический контроль ссылочной целостности
и т.д. и т.п., не знаю что еще сейчас есть в 1С, 4 года ею не занимаюсь
2) Чтобы создать связанный список достаточно в конструкторе добавить табличную часть и определить ее поля… Никаких дополнительных моделей, никаких миграций, никакого прописывания отношений, никакого прописывания связей в интерфейсе на вэб-странице в админке. Ничего. Просто несколько кликов и все готово.
То же самое с отчетами, то же самое с контролем остатков. Весь «определенный круг» учетных задач, присутствующих, а чаще всего составляющих основу любого крупного сайта, делается на 1С быстрее, чем в любой системе. Именно поэтому за ними 90% российского рынка.
Это я называю удобством без всякого сарказма. Если вы считаете это сарказмом, попробуйте простенький интернет-магазин написать на 1С и на любом допустим PHP фреймворке и сравните затраченное время. Не знаю в чью сторону вы будете после этого саркастировать.
По остальным тезисам из вашего винеггрета:
По сути в 1с мы ограничены одной парадигмой программирования: процедурной.
Вы зачем это пишете? Весь 1С построен на объектах… Запрос.Выполнить().Выгрузить().НайтиСтроки(Новый Структура(«Товар», Товар) это по вашему процедурная парадигма? Очень интересно… При процедурной парадигме вы бы писали НайтиСтроки(Выгрузить(ВыполнитьЗапрос(ТекстЗапроса, Параметры), ТипВыгрузки.Иерархически), «Товар», Товар)
Да, там нет полноценного ООП — от встроенных предметных объектов вы можете унаследовать лишь один класс, остальное через костыли, но далеко не все языки следуют стандартам ООП, заданным в с++, и javascript с php также могут считаться как вы написали «Есть там пара элементов ООП, но именно что пара элементов.»
У каждого языка есть свои особенности и недостатки в сравнении с иными языками, это не делает их неполноценными. Для любителей какого-нибудь Scala все прочие языки неполноценны. После скл-образного linq синтаксиса в С# все прочие языки, не имеющие этого синтаксиса, неполноценны. И т.д. и т.п. Если меньше читать понты на хабре, подобных комплексов может и не возникать. Еще раз повторяю — 1С это сверхудобая и сверхбыстрая среда разработки учетных (в том числе и мобильных) приложений, очень грамотно выстроенная.
А что там могут и не могут одинэсники меня вообще мало волнует. Они очень разные, кто-то спокойно пишет на С++, кто-то даже на 1С написать вменяемый код не может.
Никаких дополнительных моделей, никаких миграций, никакого прописывания отношений, никакого прописывания связей в интерфейсе на вэб-странице в админке. Ничего. Просто несколько кликов и все готово.
Думаю в этом и проблема. Платформа слишком сильно прячет некоторые моменты разработки под капотом, поэтому нет возможности полноценно изучить все эти вещи нa практике.
Любой вэб-сайт, связанный с продажами, например стандартный интернет-магазин, это учетное приложение, и создание его серверной логики на 1С в разы быстрее, чем на любом из известных мне фреймворков
Только в конце 2018го года, интернет магазин — это не такой уж «популярный» нa рынке проект.
1) Если нужно быстро набросать учетную систему — 1с наверно действительно лучшее решение. Проблема в том что для остальных целей она не подходит ни разу.
2) Для ооп нет главного, возможности на уровне кода определять свои объекты. И не нужно рассказывать что можно делать обработки или в модуль менеджера/объекта писать, это совсем не о том.
3) Про мобильные приложения лучше не вспоминайте, мобильный клиент очень крут как концепция и решение, но мобильная платформа как средство создания мобильных приложений — очень уныло из за кучи ограничений на дизайн и функциональность.
4) Коммьюнити которому программирование почти не интересно, а интересен учет и типовые конфигурациии.
5) Политика вендора (плати за каждый чих, программисты идиоты).
6) Неудобные средства разработки (EDT когда еще доползет, да и то эклипс ни в какое сравнение с идеей не идет).
7) Отсутствие ООП ведет к тому что логика часто от данных отделена, а динамическая типизация при этом заставляет слишком много знать и позволяет допускать много ошибок.
Можно на самом деле продолжать и дальше но не вижу смысла, все равно каждый останется при своем мнении.
Можно на самом деле продолжать и дальше но не вижу смысла, все равно каждый останется при своем мнении.
Потому что то вы пишете это на 90% субъективизм типа не хочу создавать обработку, хочу создать класс из кода...(В 7й версии кстати был проект 1С++, который реализовывал полноценное ООП, это к вашим словам, что 1С-ники не интересуются программированием.), а объективность это пункт 1, и рынок потребностей в учетных программах настолько велик, разнообразен и перекликается со всем чем только можно, в том числе и с вэбом, что вобщем-то непонятно что у вас за цели, для которых 1С не предназначен.
Из недостатков 1С:
— Да, отсутствие культуры юнит тестов
— Отсутствие простых и удобных языковых конструкций вроде инкремента через ++ и += или анонимных функций, а так все для удобной разработки на мой взгляд есть.
У меня почти в самом начале было что официально назвали Senior <язык> Developer. По результатам интервью. При этом, по моей личной оценке на тот момент, это было не вполне незаслуженно.
Правда фирма была прямо заинтересована иметь побольше Senior'ов (и требовать больше ставку на одеске, они как agency работали но деньги платили официально и с оформлением).
Недавно же — на интервью (должность не требовала <язык>) спросили — а вы с <язык> какой версии работали? Пришлось честно ответить что два последних стандарта знаю на уровне «ну помню основные новые фичи, вроде бы».
Еще одна проблема — повальная стыдливость. Любой провал на собеседовании расценивается описываемым нами индивидом, как личное поражение, особенно если он годами сидел в одной компании и тянул свою лямку.в десяточку!
Статья как раз попала в моё текущее настроение. Проходил собеседование в понравившейся мне компании, после чего понял, что на вопросы, которые мне задавали у меня был ответ примерно в двух из трёх случаев. В итоге подумал, что недостаточно крут для такой компании и ушёл в другую, как оказалось позже — шарагу (чтоб описать весь масштаб катастрофы — скажу, что про Git они не слышали, всё по FTP, что и вышло боком однажды и пришлось более четырёх сотен документов исправлять вручную), где отстрадал два месяца и вернулся обратно. Подготовился, прошёл собеседование, но помня свою первую неудачу запросил зарплату намного меньше желаемой, соответствующую уровню, так сказать… Следующее некоторое время работал над задачами уровня джуна, пока не попросил лидера команды разработки дать мне задачи посложнее, потому что у меня уже начала полным темпом развиваться депрессия. И вроде опыт в разработке у меня есть довольно большой, сталкивался с разным кошмаром и разной сложностью задач, но не могу перестать занижать свою планку на собеседованиях.
К счастью нормальные компании нанимают и разговаривают с разработчиком напрямую, минуя HR и сразу по собеседованию, навыкам или по тестовому заданию выясняют уровень человека. Хорошо ещё когда на тестовое задание дают от 24 часов до недели, а не эти новомодные тесты, где нетривиальные задачки нужно решить за 30 мин.
Представьте, что в значительном числе компаний России, Украины, etc работают такие недооцененные работники. Часто именно они принимают решение брать нового коллегу к себе в команду или нет. И получается ситуация, когда недооцененный собеседует недооцененного. Это я к тому, что есть уж очень много примеров, когда такой недооцененный, или даже уволенный кандидат на ура устраивается в более пристижную компанию и оттуда машет ручкой, с вершины более высокой ЗП и даже должности. Говорю про своих бывших коллег и тех, кого приходилось собеседовать в команду. Сделал для себя вывод что наши разрабы, админы, девопсы, поголовно недооценены. Но не могу выкинуть из головы, что где то тут есть подвох…
Это я к тому, что есть уж очень много примеров, когда такой недооцененный, или даже уволенный кандидат на ура устраивается в более пристижную компанию и оттуда машет ручкой, с вершины более высокой ЗП и даже должности.Так и есть!
Уважаемый Crossover. А вы можете расписать вашу иерархию квалификаций разработчиков? Начиная от джуна, заканчивая супер пупер архитектором (или выше).
Часто натыкаюсь на ваши вакансии и улыбаюсь от указанных там позиций. Складывается впечатление, что у вас на всех позициях работают только тех директора и тому подобные.
Мы не нанимает исключительно директоров и синьоров, это было весьма странно. У нас есть самые разные позиции, простейшие стартуют от 15$/час и требуют 2 года опыта работы, бакалавра инженера или в CS и определенный стек технологий. Например, вот вакансия для молодого фронтэндщика, можете ознакомиться. Полный перечень позиций, на которые мы нанимаем специалистов, лежит тут. К сожалению, мы не практикуем найм вообще без опыта, так как у нас полностью удаленные распределенные команды, которые работают над корпоративными коммерческими продуктами, обучать людей с нуля возможности нет.
Теперь почему вы видите чаще всего «супер-пупер» вакансии. Очевидно, что высококвалифицированных специалистов намного меньше, чем разработчиков со стажем работы в 2-3 года. Для того, чтобы найти таких высококлассных специалистов уровня ведущего архитектора или CTO мы рекламируем наши вакансии, размещаем информацию на различных ресурсах, проводим Hiring Tournaments по определенным направлениям (обычно это зп от 50$/час, чаще 100$+/час) и так далее. Но даже это не всегда помогает покрыть потребности холдинга ESW Capital в кадрах, так как постоянно покупаются новые компании, которым нужны команды разработки. Поэтому в публичном поле информации о таких позициях намного больше, чем о позициях на 15-30$/час, которые закрыть намного проще в сравнению с условной вакансией SVP of Engineering с зп 200$/час.
Благодарю за пояснения.
Можно такой вопрос к вам, от студента разочаровавшегося в формальном образовании: люди без диплома бакалавра не рассматриваются как кандидаты в принципе, или всё же можно попробовать имея опыт, знания etc.?
Т.е., по факту, если ты находишся в одной из стран с высоким уровнем жизни (куда обычно уезжают программисты), то зарплаты кажутся просто смешными, а отсутствие плюшек только делает всё хуже. Архитектор с з/п в $60k в год, или ведущий/старший архитектор с з/п в $100k, да это просто издевательство. Я бы даже сказал, что в Мск/Спб люди с такими скилами и на аналогичных должностях не меньше получают, если не больше, а ещё и учитывая бонусы… Можете ли поделиться статистикой, откуда у вас люди в основном работают? Просто ради интереса спрашиваю.
Мск/Спб люди с такими скилами и на аналогичных должностях не меньше получают,
Не все хотят/могут переехать в МСК/СПБ, а для провинции — это очень хорошие деньги.
Просто сравните какого-нибудь архитектора Васю из Воронежа, который работает в НПО «Развитие», и допустим архитектора Джима из Сиэтла, который работает, в Амазон. Всё сразу станет понятно, я думаю.
Вот и получается, что с одной стороны, компания хочет нанять, допустим архитектора за небольшие деньги, а с другой стороны, люди, которые реально обладают таким набором навыков, за эти деньги работать не пойдут (скорее всего, я видел на хабре упоминание пары исключений), просто потому, что у них уже обычно есть и опционы в компании и хорошая з/п и прочие бонусы. Ну а если нет по каким-то странным причинам, то проще компанию сменить и получить их.
Просто сравните какого-нибудь архитектора Васю из Воронежа, который работает в НПО «Развитие», и допустим архитектора Джима из Сиэтла, который работает, в Амазон. Всё сразу станет понятно, я думаю.
Вот благодаря подобной удаленной работе, у Васи из Воронежа, есть шанс получать хорошие деньги. Т.к. туда не пойдет Джим из Сиэтла, а работодателям остаются как раз «Васи».
Загвоздка только в том, что реальный опыт в разработке у архитектора Васи, скорее всего будет соответствовать уровню, который требуется для обычного разработчика в Кроссовер. Вася возможно и сменит работу, и будет получать больше денег и набирать опыт, но вот архитектором он не будет.
Вот и получается, что придётся нанимать «архитекторов» и сильно терять в качестве, выращивать своих, или искать годами и не находить. Пример конечно абстрактный, но всё-таки.
В любом случае, мы же обсуждаем сейчас позицию ведущего архитектора. Как раз эту должность я и упомянул. А раз уж для старшего разработчика возможно 50-70, то думаю, что и для старшего архитектора возможны 100.
«8 + years of hands on development experience with 2 + years in an architect or similar position».
Или в этом случае, мы под архитектором понимают обычного разработчика, а под разработчиком начинающего специалиста? Тогда конечно всё не так плохо… Для всех кроме заказчиков, которым в очередной раз продают разработчика по цене двух архитекторов :)
У нас есть самые разные позиции, простейшие стартуют от 15$/час и требуют 2 года опыта работы… К сожалению, мы не практикуем найм вообще без опыта
То есть требуются не знания, не умения, а 2 года опыта? Что вы подразумеваете под «опытом» и как вы можете его проверить? Если я делал сложные проекты для себя, в стол в целях самообучения, но не проработал на оплачиваемой должности ни дня, я изначально не подхожу под ваши минимальные требования? А если я при этом напишу, что проработал 3 года — как вы проверите?
Мне кстати не очевидно, почему людей с опытом меньше. Ведь они никуда не деваются, только накапливается. Для примера, взрослых и стариков же больше, чем детей (в любой стране), почему тут это не работает? Мол, молодая индустрия? Даже в РФ уже лет 20 как минимум активно развивается IT, где все те разработчики, у кого должно быть по 15-20 лет опыта?
Описанное в статье явление имеет научное название — "эффект Даннинга-Крюгера"
Я не граммар-наци, но как может сотрудник Crossover писать «работАдателям»? Они же не производством деревянной мебели занимаются, а наймом!
Мне кажется в нашей профессии очень сильно демотивирует постоянно растущее количество технологий, которое к тому же полностью обновляется раз в два года. Всего не выучишь, за всем не уследишь, а ощущение того, что ты не на гребне волны или есть что-то чего-то не знаешь, сбивает самооценку. Тем более, что вероятно вам никогда не приведется пощупать очередной хайповый тренд, по которому следующие два года будут делать запросы HR-ы. Кроме того немаловажную роль здесь играют всевозможноые расхайпованные на конференциях и соцсетях "гуру", таким образом задающие планку. Наш специалист, сидя в зале, пытается оценить себя по навязанной шкале и то, на что он может претендовать в сравнении с выступающим.
А теперь разложим все "по понятиям".
90% "новых" хайповых технологий на деле является дерьмом, потому как:
- это либо топтание на месте: а давайте все вместе будем дружно использовать новую парадигму/язык/платформу, потому что это сейчас будет модно.
- либо переизобретение велосипеда на другом стеке — происходит периодически каждые 5-10 лет, когда подрастает новое поколение, использующее новые средства разработки. Все эти "новые" идеи уже были когда-то реализованы раньше, либо заимствованы из другого стека. Причем, как правило, "раньше было лучше".
- иногда имеет очень специфическую область применения, с которой вы вряд ли столкнетесь, как например блокчейн или бигдата, но тем не менее расхайповано как средство первой необходимости
- выглядят привлекательно только на презентации. Нормальная технология содержит не столько абстрактную идею, сколько реальный опыт ее применения. При внедрении же новых технологий всегда внезапно вылазит стопицот побочных проблем разного характера.
- есть попытка продать собственный продукт или поддержку.
- выйдут из моды через 2 года или будут заменены другими.
Гуру, выступающие на конференциях или публичных площадках:
- обычно представляют труд большого числа людей "за сценой"
- как правило являются достаточно узкими специалистами в своей области
- многие из них уже давно не пишут код (когда активность в твиттере становится выше, чем активность в репозитории собственной компании)
- редко являются финальными пользователями своих изобретений
- выступают в роли шоуменов для раскрутки собственной компании и продуктов
- так или иначе получают за это деньги
Вы реально классный специалист, если:
- можете с нуля без посторонней помощи написать бизнес-приложение
- владеете определенным стеком технологий для реализации данной задачи
- способны к самостоятельному обучению
- стараетесь быть "в теме": интересуетесь последними веяниями и разработками
- обладаете здравым смыслом и критикой
- несмотря ни на что вам нравится ваша работа, и вы в ней не только из-за денег
Вы должны осознавать:
- большинство HR-ов некомпетентно в IT (а некоторые и в HR)
- универсальный специалист, подобный швейцарскому ножу — это хреновый специалист, не делающий нормально ни одну из функций
- есть люди, которые лучше умеют себя продавать. Это не делает их лучше как специалистов.
- наша работа должа приносить удовлетворение
- если вы не прошли собеседование, то возможно это не вы не подходите компании, а компания не подходит вам
очень сильно демотивирует постоянно растущее количество технологий
Зависит. Меня наоборот мотивирует, т.к. можно ничего не знать, но быть быстро обучаемым. Для каких-то людей (вероятно, иррационалов) это наоборот больше по нраву.
универсальный специалист, подобный швейцарскому ножу — это хреновый специалист, не делающий нормально ни одну из функций
Но узкий подобен флюсу. И странно, что он не трогает другие области, вне своей обычной работы. Может быть, ему они не интересны? А вот как быть, если интересна разработка приложений самой разной направленности? Вот, скажем, сейчас мне крайне интересно, как общаться с видеокамерой по ieee1394 из сишной программы под Windows с помощью совершенно непонятных мне SetupDiGetClassDevs и SetupDiEnumDeviceInterfaces. Информации я нашёл практически ноль. Единственная книжка («Программирование аппаратных средств для Windows») содержит серьёзные ошибки кода, а вот эта самая SetupDiEnumDeviceInterfaces перечисляет платы в компьютере, а не видеокамеры (а в книжке она подаётся, как перечисляющая именно устройства с ieee1394). А год назад мне было интересно (и нужно) сделать драйвер USB-устройства для Windows. Книжка по написанию таких драйверов огромна и сложна. Но есть пример от Microsoft в их DDK. Так же была интересна 3D графика в лице OpenGL, 2D графика, звук и видео в лице DirectDraw и DirectShow. А для QNX нужны были также фишки про создание драйверов и программирование под Unix и Photon Micro GUI в частности. Месяц назад мне потребовалась именованная разделяемая память в QNX. Для Linux когда-то пробовал Qt. А ещё были интересны и нужны сокеты. Ах да, есть ещё приставка PSP с её собственными аппаратными средствами. И STM32, и Atmega и PIC. Для этих штук я тоже писал различное ПО.
Я никогда всего перечисленного не использовал по десять лет каждое и, естественно, не помню/не знаю тонкостей. Более того, все понятые и запомненные тонкости частенько забываются. Это почему-то удивляет некоторых людей. В одной из веток мне написали, что раз я забыл точную реализацию альфа-бета алгоритма, написав на ней шахматную программу, значит, я этот алгоритм никогда и не понимал. Удивительная наивность! В 2011 я разбирался со сжатием, используемым в JPG (потребовалось для одного проекта). Практически вывел алгоритм AA&N (Y.Arai,T.Agui,M.Nakajima). Но вот именно сейчас я не помню уже ничего, кроме того, что я это делал. Это просто вытеснилось из памяти. Но это совершенно нормально, если вы занимаетесь (и это вам нравится) многими вещами. Даже собственные статьи забываются и требуют усилий для понимания заново, как оно так было сделано.
У любого специалиста есть какой-то определенный инструментарий — то, чем он хорошо владеет на данный момент, и что напрямую связано с его работой. Плюс за годы накопился определенный багаж — то, с чем он когда-то работал раньше, но что уже подзабылось или вышло из тренда. Затем у каждого имеются интересы в различных областях — то, что активно хочется изучить и освоить.
В резюме важно, чтобы это все смотрелось органично и не вызывало дополнительных вопросов. Вот добавьте в свое резюме рядом с C/C++ строчку JS/Node, и сразу появится куча вопросов. Вы втихаря пилите свой JS-движок? Участвуете в разработке Node? Или просто ищите вакансию, которая вам поможет в освоении фронтенда? А вот с резюме фронтэндера таких вопросов не возникнет.
Есть люди, у которых баланс нарушен от освоения в сторону лишь изучения нового материала. В этом случае, даже имея официальный сертификат, все их знания будут поверхностны, ибо для освоения технологии требуется более глубокая и объемная работа, нежели написание "Hello World"-ов. А для этого требуется время, которого сверхурочно нигде не возьмешь. Поэтому когда в резюме стоит строчка типа: С/C++, Java, Python, C#, JS, PHP, Go, Rust, то скорей всего он не владеет в достаточной степени ни одним из этих языков.
Более того, все понятые и запомненные тонкости частенько забываются
А это огромный плюс нашей памяти — делать автоматическую очистку мусора. Основной скилл для HR в этом случае не само знание, а то, что чел однажды смог хорошо разобраться с данной технологией.
Если какая-то технология/алгоритм/тонкости языка программирования потребуется работодателю, то с ней можно разобраться за некоторое время с требуемым уровнем погружения, если есть способность и желание разбираться. А не помнить наизусть всё содержимое учебника.
Я тут недавно пробовал сделать такое. (под qnx и gcc 2.95 компилируется (с предупреждением «pointer to member cast from virtual base 'CErrorsAcs' will only work if you are very careful»), но с приведением типа указателя на метод класса к классу CAcsErrors с вызовом функции SetState из CErrorsBased, а не CErrors со всеми вытекающими ) Ну а чего? Дом унаследовал дверь, значит, ручка двери теперь компонент дома. Логично? А вот компиляторы так не думают. Я про такую тонкость и не знал никогда. Теперь знаю. :)
У меня в резюме:
Programming languages:
Assembler, Bash, C, C++, Erlang, Javascript, Pascal, Perl, PHP, Python, Ruby (+Rails), and more (in passive state).
(кстати, наверное надо обновить — Ruby и Pascal ушли в passive, не трогал уже пять лет).
И ни одного сертификата. (доисторические онлайн не считаются).
Всё, мне пора в утиль?
А что такое «достаточная степень» владения?
Степень, достаточная для того, чтобы быть полезным потенциальному работодателю для решения поставленных бизнес-задач.
Сама строчка о языках ничего не говорит. В тайтле вы должны четко дать понять кто вы, и чем конкретно вы можете быть полезны работодателю. Стоит акцентировать внимание не столько на языках, сколько целевых на технологиях, платформах или бизнес-областях, в которых вы работаете. Никому не нужен просто assembler, зато требуется запрограммировать конкретный микроконтроллер или написать драйвер ядра Linux. Вместо bash-а будут искать администрирование Unix/Linux. Что вы делаете на C/C++: программирование под Win32, под Linux, геймдев или еще что? JavaScript тоже ни о чем. Вы фронтендер? Разрабатываете под ключ вебприложения?
Не бойтесь выбрасывать мусор из резюме — больше не лучше. Вы будете реже выходить в поиске, зато более целенаправленно.
P.S. Технологии и языки хорошо указывать в своем портфолио, когда они связаны с конкретными проектами. Так у HR-а создается представление о вашем профиле.
— А мне что, разорваться?
C/C++: программирование под Win32? да. под Linux? да. геймдев? очень давно, тут сорри. драйвера? да. микросервисы? да. ускорение узких мест для erlang-приложения? да.
JS: фронтендер? если придётся. под ключ? если придётся. серверная часть? если уже написано на нем, то остальное тоже допишу, да.
Я к чему — я тот самый ненужный швейцарский нож. Для меня full-stack начинается в hardware и заканчивается в бизнесе, и да, я понимаю на всём протяжении, и могу отлаживать и на уровне ICE'а если понадобится.
Просто когда кто-то говорит что это невозможно или бесполезно… Ну вы или не знаете что так таки бывает, либо вы просто настолько узкоспециализированы, что не знаете когда это бывает надо.
"Подумаешь… Я еще и вышивать могу… И на машинке… тоже..." ;)
Это все очень хорошо, поздравляю. Однако постоянно растущее количество технологий и областей применения так или иначе требует более узкой специализации. Если вы во всех достигли уровня "бог", то снимаю шляпу — тут не о чем разговаривать.
Мне лично попадались за всю практику "специалисты широкого профиля" или "просто программисты" — человеки, которые в 201x на Java итерируют списки при помощи for (int i = 0; i < list.size(); i++) list.get(i). Им впринципе все-равно на чем писать — все языки похожи, а stackoverflow и google всегда под рукой. Требуемую задачу они решают методом копипейста или точечного патчинга чужого кода. Их обычно ставят в проект, чтобы они были вкурсе, и чтобы потом их можно было оставить на саппорте, когда основной девелопмент уже завершен.
Но тем не менее так или иначе на рынке труда все-равно будет необходимо позиционировать себя в какой-то одной области, либо паре смежных областей. Но иногда в некоторых стартапах действительно бывает необходимо хороший специалист, компетентный сразу во многих областях.
Да, нельзя держать up-to-date десяток параллельных технологий в голове.
Но любой даже «классический» сеньёр требует минимум несколько — основной ЯП (например, C# / Java / Python / C++ / etc), зачастую — еще дополнительный ЯП или DSL (JS, HTML, XSLT, CSS), обязательно SQL и/или NoSQL и их обертки для основного ЯП, плюс неплохой снапшот Posix API и/или WinAPI и/или X и/или Wayland и/или GTK и/или…
То есть чистых «фокусистов»-то и нет. Даже в эмбедде, чистый программист эмбедда — бесполезен, если он вообще ничего не понимает в железе.
Итого? Синглтоны — тоже никто. Возникает вопрос исключительно в балансе и обучабельности.
А дальше… Если это стартап — то надо человека который может максимум прямо здесь и сейчас. Если крупный фин.институт — надо вообще чтоб финансисто-математик был. Или как в 1С — с неплохими знаниями бухгалтерии, например. То есть… Так или иначе универсал.
Ну вот под термином "классический сеньор" вы примерно и описали типичный стек, необходимый для решения большого числа бизнес-задач. Но вот например меня лично насторожило бы, если бы я увидел рядом C# и Java, т.к. это совершенно два разных стека, призванных решать сходные задачи. Вы реально хорошо разбираетесь в экосистеме каждого из них и знаете типичные решения, которые там используются? Я не отрицаю, что есть спецы, которые в совершенстве владеют обеими технологиями, но какая практическая цель этого? Просто интересно знать? Получить больше предложений на рынке? На работе заставляют писать на чем угодно? Но любой реальный проект никогда не будет совмещать в себе обе эти технологии, поэтому половина навыков так или иначе останется невостребованной.
С другой стороны, есть специалисты по Oracle, SAP или 1C, которые в гробу видели все эти WinAPI, GTK, C++ и прочее вместе взятое. "Их и так неплохо кормят". Есть дата-аналитики, и у них свои инструменты: Excel, R, Kafa, Hadoop, etc… Есть специалисты по конкретному продукту, и они ценятся на рынке гораздо выше, и их отрывают с руками. Никто их не будет спрашивать что они там еще могут делать, помимо основной работы, потому как странно подписать жутко дорогого спеца по "Супер Пупер Бизнес Платформе (тм)", и заставлять его пописывать на досуге на C/C++.
И естественно, любой специалист ценится, если у него помимо навыков программирования есть определенные знания предметной области.
Ну и без кросс-человека договориться между отделами становится всё сложней и сложней.
Хотя сам знаю и использовал/использую многие технологии, поскольку за годы довелось поработать в самых разных областях (и не по году-два). Даже наногалеру удалось увидеть (единственное место, которое я покинул быстро).
Поверьте — если даже в Москве все хорошие специалисты друг друга знают, то что говорить о городах поменьше. Я не ожидал, но айти тусовка в РФ не такая большая....
Вы не поверите, но тусовка ещё не весь рынок.
Но вот есть необходимость внутреннего общения и обмена опытом и поэтому — почему бы не проводить внутренние митапы/семинары по конкретным тематикам, по отдельным направлениям?
Так же и взаимоотношения между сотрудниками разных компаний. Сколько хороших DS в РФ? Вряд ли десятки тысяч, скорее тысячи. Сколько хороших спецов по k8s? Да тоже самое. И т.п. Поэтому сообщество действительно не очень большое.
> завалят на довольно важных вещах — вот их и стоит проработать плотнее в ближайшие 2-3 месяца
Даже если вы их видите в первый и последний раз в жизни, как того собеседующего? И такому ходящему, пожалуй, не стоит давать серьёзный проект в управление.
Кстати, бывший коллега рассказывал про интересное интервью с ним (оно было недавно, буквально неделю назад, в четверг).
В нем интервьювер еще раз уточнил, какие языки знает собеседуемый (в его случае был C#, Java и Python). Далее он открыл на планшете сайт govnokod.ru и просто выбирал более-менее интересные примеры кода, а потом просил рассказать, что там не так.
С моей точки зрения всё было очень необычно, однако сама задумка довольно интересная: примеры из жизни, они свежие, не выдуманные. И собеседники находятся в равной позиции, так как оба не до конца готовы к этому коду.
Я не вполне согласен с использованием прямо сайта на собеседованиях (просто решение ну очень необычное).
Однако, с моей точки зрения, если на предложение "переписать пример ниже" человек просто уйдет, то он тот самый "не Лев Толстой". Тот, который на словах всё переделает, а на деле не сможет простой случай разобрать.
Как бы вы "закрыли глаза и переписали нормально" буквально одну строчку ниже?
if (market.Handicap != null && market.Name.ToUpper().ToLower().Contains("HANDICAP".ToLower()))
{
............
}
Считаю что никакого голода в IT нет и, по крайней мере, не будет. А вот в космическая отрасль другое дело. Для IT отрасли даже если сейчас претендент не дотягивает до джуна, то ничего страшного, научится. А вот во втором случае часто учиться некому. И скоро будет уже не у кого…
Кажется, в России уже можно делать бизнес с психотерапией, направленной строго на IT. А что – публика платежеспособная, проблемы у каждого второго, да и примерно одного характера. Когнитивная терапия многим будет по душе со своей "отладкой" процесса мышления и постоянным поиском багов.
Хороший психотерапевт обычно имеет медицинское образование, курсы переподготовки (или что-то такое) в каких-нибудь зарубежных институтах, и научную картину мира. Я бы даже сказал, что хороший терапевт имеет более научную картину мира чем средний программист.
Достаточно долго изучал и обучался всему, перед тем, как решиться сходить на собеседования. Буквально недавно просто случайно открыл резюме на хедхантере для работодателей. Пришло достаточно много откликов, прошел 2 собеседования. После второго перезвонили через 2 часа и предложили работу, я согласился и отменил еще 7 собеседований следующих, т.к. кампания понравилась. Через неделю позвонили с первого и тоже предложили работу. Что забавно — просил я небольшую сумму, но предложили мне почти в 2 раза больше.
Непосредственно перед собеседованиями я морально готовился к тому, что меня развернут, и утешал себя тем, что узнаю свои пробелы и смогу их закрыть и уже потом когда-нибудь таки устроюсь на работу. Также несмотря на достаточно хорошую теоретическую подготовку и наличие пары своих проектов — очень был не уверен в том, что это кому-то понравится, и что моих знаний достаточно даже для работы за еду. Я даже думал о том, чтобы начать с какой-нибудь совсем приземленной и небольшой конторы, но в итоге попал в достаточно крупную кампанию с интересными внутренними проектами.
Ок, пусть Коля справляется за 2 часа, Миша за 6.
Но коммуникация, исправление мелких ошибок, различная рутинная работа, code review, refactoring — происходят примерно с одинаковой скоростью и у Миши и у Коли, и может занимать у них обоих по 2 часа в день (И получаем 2 из 8 часов и 2 из 4 часов, соотвественно. Забавно, да? У Коли половина или больше половины работы — вовсе не программирование!).
И в итоге это лишь значит, что Коле нужно работать по гораздо более высокому рейту, пусть и формально на халф-тайм, это будет честнее для всех. К сожалению, мало какие крупные компании умеют такое правильно оценивать, им проще усреднять всех и делить на уровни «по выслуге лет» или «по размеру задач».
У того же Crossover, если я правильно понял, не бывает разработчиков за $60/час, а бывают только «архитекторы».
Ищите заказчиков сами, вместо того, чтобы пытаться обмануть систему работы в подобной компании. Искать заказчиков долго, сложно, но в итоге тот найденный редкий понимающий заказчик будет в восторге от скорости решения Колей проблем и будет платить за это очень хорошие деньги.
{От не разработчика ПО, а научного работника, R&D}
есть и другая крайность, когда аналог Team Lead в небольшой компании постоянно выражает желание создать аналог windows10 "быстро и дёшево".
Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда