Comments 57
IT не только из программистов-тестировщиков состоит.
Должность, например, "церемониймейстера" - он же SCRUM-мастер - он же секретарь-организатор - подразумевает крайне либеральные (даже отсутствующие) требования к собственно "техническим" навыкам, зато уж "софтскиллсов" надо чем больше, тем лучше.
Да и "творчество" в разрезе собственно написания кода - крайне абстрактное и вряд ли передающее истинную суть работы понятие. Скорее, востребованы эрудированность (в области в целом признанных эффективными методологий), лаконичность и лошадиная доза интуиции, позволяющей не только накодить что-то "с нуля", но и заставить свой кусок кода работать с (или заменить) чьим-то ещё творением.
Своё местечко в IT может найти обладатель почти любого набора навыков. Беда в том, что крайне дивные именования должностей и размытость требований с одной стороны и отсутствие единого достоверного мерила навыков с другой делают нахождение "работы своей мечты" крайне... нетривиальным занятием.
Ну и ещё и "все лгут". И трезво оценивающий свои возможности кандидат наверняка будет похоронен под кипой резюме от более наглых соперников.
Но и это, наверное, тема для совершенно другой статьи...
У Вас опечатка в сообщении, лишняя буква R.
Во-первых, scrum-мастер - это не должность, а роль, и иметь эту роль вполне может программист например. Во-вторых, стоит хорошо понимать то, чем управляешь. У любого разработчика есть грустная история о результатах управления проектом людьми без технического бэкграунда.
Ну да, ну да. У нас, например, за срам 10к к зарплате. )))
Ну и ещё и "все лгут". И трезво оценивающий свои возможности кандидат наверняка будет похоронен под кипой резюме от более наглых соперников.
Я бы почитала эту статью, актуально)
Обещаю подумать.
Тут, знаете ли, очень нервный контингент читателей.
За статью о том, что, оказывается, можно планировать крупные проекты детально и скрупулёзно и завершить его с меньшими затратами и без стресса, мне фактически ополовинили репутацию учётки. Второй такой реакции интеллектуального большинства моя учётка не переживёт и "улетит" в recovery mode, - а статья о повальном засильи лжи в вопросах найма точно вызовет не менее скверную реакцию большинства.
Если придумаю, как оформить статью так, чтобы наши нежные-ранимые не расплакались, - напишу всенепременно.
Вообще-то, проституткам, а не россиянам. И уже давно.
Но на что только не пойдёт сова ради глобуса...
(Upd. Чойто чем больше пытаюсь размотать этот клубок новостей - тем больше обалдеваю. Так они запретили порно или да?)
Переучиваться тоже иногда приходится
Не иногда, а ПОСТОЯННО! (если не сидеть на древнем легаси ещё 90х годов)
Не написано кому не подходит и как понять что не подходит.
Никому не подходит, кончайте все лезть в IT, самим вакансий мало.
Да пусть лезут. Чем больше новичков, тем более ценными будут люди с опытом и знаниями. Проблем (конкуренции) прибавится только у джунов.
Зря недооцениваете избыток хоть и нерелевантных, но специалистов. Хрюшке может быть дано указание отбирать помоложе, да подешевле, а если рецессия таки начнется, то мне кажется, что фактор дешевизны ресурса будет основным в отборе на вакансии.
Ну это жизнь... Нужно осваивать смежные направления. Например, я занимался год назад кроме основной работы ещë ремонтом электроники, со сменой работы перестал этим заниматься. Но при желании могу снова этим заняться. Или вообще на сварщика выучиться - весьма востребовано.
Я в компаниях, где возможен такой отбор, работать бы не стал, соответственно конкурировать с толпой "нерелевантных" мне и не придётся.
Поговорку "от сумы да от тюрьмы не зарекайся" Вы, видимо, забыли. Или просто слабо представляете себе что такое глобальная рецессия, у которой один из побочных эффектов - сильное упрощение экономики и резкое падение потребности в высокотехнологичных вещах, где актуально иметь высокую квалификацию. В такое время лучше иметь готовый и прогретый Plan B, где Ваш доход не будет зависеть напрямую от Ваших текущих основных скиллов.
Не мало. Если специалист достиг уровня, хотя-бы, мидл - то для него открывается широкое поле для манёвра. Синьоров вообще из рук в руки передают. Не хватает квалифицированных кадров.
Надо бы всё же пояснить, о каких айтишниках речь. Имхо, настоящим полноценным айтишником можно считать спеца с хорошей математической базой (на уровне тех. ВУЗа) и с хорошим знанием базовых предметов школьного курса. Где-то видел статью (вроде на Хабре), где автор расписывает проблемы при вхождении в айти. Там очень показательны моменты, связанные с слабыми знаниями математики. Ему понадобилось что-то оптимизировать, он полез в алгоритмы, но понял, что без знаний высшей математики не разобраться. Сел за ВУЗовские учебники и... тут же понял, что ему не хватает знаний школьного курса математики... В итоге до 4-го школьного класса докатился.
Так что, если рассматривать айти-профессии по взрослому, то там всё сложно, с наскоку не освоишь.
С другой стороны... сейчас дочку (которая наконец поняла, что работа продавцом в обувном - не лучший вариант) обучаю фронтэнду и легкому бэкэнду (Django/Wagtail). Да, всё очень поверхностно, но достаточно для разработки несложных сайтов. Главное, чего хочу достичь - научить ее самостоятельно нагугливать готовые решения и применять их. Ну и чтобы могла заказать разработку на стороне и проконтролировать процесс и результат.
Так что в принципе и для таких айтишников место найдется. Главное, чтоб интерес был.
Что значит полноценным айтишником? Для чего? Что значит хорошая мат база? Вот я например, имею образование биологическое, защитил диссер медико-биологический, но по-сути занимаюсь тем, что анализир(овал)ую биомедицинские данные. Могу я считаться айтишником, с учетом того что мои основные рабочие инструменты - питон, пандас, скайпай и джупитер ноутбук, а сотни убиенных во имя науки мышей и десятки проведенных своими руками экспериментов в прошлом? Я еще планирую освоить анализ данных геномики и протеомики, это сделает меня айтишником если я еще не?
Вы являетесь научным работником. Для них знание IT становится обязательным. Подготовка публикаций, анализ данных, составление отчетов, работа с наукометрическими базами данных - вот довольно рутинный "стек разработки". Многие работают с системами инженерного анализа и некоторые даже разрабатывают программы. Это уже довольно близко к IT, поэтому довольно много айтишников в прошлом научные работники или сотрудники ВУЗов.
Ваш стек и профиль как нельзя лучше подходят для аналитика данных (с дальнейшим уходом в data science, если есть желание). Да, это тоже айтишники.
Если вы всерьез рассматриваете переход в айти, то нужно чекнуть познания в матстате (скорее всего у вас с этим даже лучше чем у типичного аналитика) и немного изучить SQL (много не получится, ибо тут самый полезный опыт - при решении практических задач на работе). И все)
П.с. Посоветуйте какую-нибудь простенькую книжку по геномике и протеомике. Как-то раз помогал решить простенькую задачку в этой области. Без понимания сути совсем, но было очень интересно
я примерно аналогично, только в физике (оптике) и электронике. Неприятно, что без доп. знаний зарплата была бы выше...
Да не так уж много нужно знать, чтобы быть норм спецом. В большинстве случаев, хватит базового курса информатики.
1. Ну хотя бы было понимание, что "не так" с флотами
2. Булева арифметика
3. Бинарная арифметика
4. Поиск по дереву
5. Поиск пути в графе (в ширину, в глубину, если умеет длину пути по Дейкстре вычислять - вообще блеск).
8. Немного *nix
6. ACID, BASE
7. OSI
9. DDD
10. Hex Arch
11. CQRS
12. Event Sourcing
Пля... не. Пока писал, понял, что у меня еще дохрена пунктов и нужно довольно много знать, да )
Но! Тут вообще нет матана разного, кстати
Так что, если рассматривать айти-профессии по взрослому, то там всё сложно, с наскоку не освоишь.
Вспоминаю, когда искал первую работу именно программистом. А у меня даже IDE не было установлено. Что такое отладка, тоже без понятия. Лишь сексуальный финансовый интерес.
🍪
Где-то на этой фразе я всё понял:
Программисты работают, осваивают новые технологии, алгоритмы, подходы к разработке.
Осваивают новые алгоритмы? RLY? Нет, я, конечно, могу поверить в человека, который for fun полез разбираться в Merkle tree, но как правило по индустрии, вероятнее всего, нет.
А вот что устаревает - так это инструментарий, языки и библиотеки/фреймворки.
Осваивают новые алгоритмы? RLY? Нет, я, конечно, могу поверить в человека, который for fun полез разбираться в Merkle tree, но как правило по индустрии, вероятнее всего, нет.
Зависит от индустрии, я полагаю. Если говорить о разработке типовых сайтов, то может быть и да. Но стоит полезть куда-то, где требуется высокая скорость обработки больших объемов данных или какое-нибудь специфическое распознавание образов и все... Тут уже без алгоритмов никак. То вообще сходу непонятно как к решению подойти и ничего готового нет, то имеющиеся фреймворки не тянут по скорости/ресурсам...
IT - оно большое, направлений много. Всяких и разных.
Буквально недавно наблюдал человека, которому надо было "побыстрее" обработать небольшой массив данных (около 20ПБ), и он не хотел ждать месяц. Знаете, какой алгоритм он для себя нашёл? numpy и multiprocess. Уложился в день изучения и день молочения данных на сервере (вместо ожидаемого 30+ дней).
Изучение алгоритмов - чаще всего забава. Важно знать про их существование, но реализация чаще всего уже написана и любой программист, который вручную реализует поиск кратчайшего расстояния в графе или быстрое умножение матриц в 95% случаев находится в зоне профессиональной некомпетентности (совершает второй большой грех в ИТ - пишет то, что уже написано).
"Быстро" понятие относительное. Когда занимался промавтоматизацией и делал микроядро распределенной системы, одна из задач была выявлять дубли в пакетах от удаленных контроллеров. Там каждый пакет имел уникальный (для данного контроллера) идентификатор и надо было отслеживать дубли т.к. это была нештатная ситуация, свидетельствующая о проблемах на контроллере.
Контроллеров много, трафик плотный, на первичную обработку пакета (проверка на дубли, первичная валидация, передача на дальнейшую обработку) выделялось единицы микросекунд. Ни один из готовых алгоритмов хранения пар контроллер-идентификатор не давал гарантированного времени поиска-сохранения - иногда срабатывает, иногда отваливаемся по таймауту. Пришлось копать самому. Помню, что именно тогда нашел и разобрался с алгоритмом SkipList и построил нужный мне контейнер на его основе.
Сейчас часто приходится сталкиваться с распараллеливанием обработки больших объемов данных. Причем, работает все в мультипроцессоной среде - когда на одной машине работает очень много заданий одновременно. И там первый вопрос - каково допустимое временное окно на выполнение данного задания и сколько ресурсов машины может быть выделено на это задание в данном временном окне. Т.е. всегда ищется баланс между скоростью и утилизацией ресурсов процессора. И тут тоже далеко не всегда подходят готовые алгоритмы т.к. там разработчики не очень сильно озабочены эффективностью.
Переход в IT должен быть по любви! А у большинства нет азарта постигать программирование, аналитику и дизайн.
Тоже раньше верил в любовь. Бывают исключения, но большинство работает за еду. Зарплата - центральный мотив, ради которого люди ходят на работу и меняют профессию. А азарт появляется, если выполненное задание награждается весомой премией. Если бы все богатые были, у вас бы не было ни одного наёмного работника.
Тут есть разные аспекты.
От любви и азарта я пишу код. За еду и прочие деньги я беру за код ответственность и пишу тот код, кторый нужен кому-то еще, а не который интересен лично мне.
Шикарнейшая формулировка!
Писать код ради того, чтобы писать код? Что-то в этом есть. Но менеджеры с этим борются. Им нужны исправление багов и увеличение продаж, а не идеальный код.
Кстати, любовь - опасная уязвимость. Обнаружив религиозного работника, недобросовестный начальник будет манипулировать и закручивать его в бараний рог. Для технарей очень опасно, потому что они часто плохо соображают в отношениях между людьми.
Им нужны исправление багов и увеличение продаж, а не идеальный код.
Поэтому работа — за деньги.
Обнаружив религиозного работника, недобросовестный начальник будет манипулировать и закручивать его в бараний рог.
Например, как? Если мне начнут подкидывать задачи, которые мне интересно делать, то это звучит как win-win.
Те, у кого к IT любовь, не переходят в IT, они идут в него сразу. А переходят те, кто любит что-то другое, но в IT перейти МОЖЕТ.
ИМХО по мере работы в IT люди который пошли по любви будут гораздо более сильными профессионалами, чем те, что работает за еду. Просто скажется разница в мотивации. За еду человек поработал свои 8 часов, выключил комп и забыл. По любви (особенно еще и по молодости) человек поработал 8 часов, пришел домой, ради интереса полез разбираться возможно с каким-то новым интересным языком, алгоритмом, техом, пошел писать свои велосипеды (и не велосипеды). В итоге через условных 10 лет разница опыта в часах будет колоссальная, да и скорее всего в техническом кругозоре тоже.
Тебе больше платят?
Тебя больше уважают?
Ты сам себя больше уважаешь?
У каждого тут будет свой ответ. Для меня ответы 1) да (при смене работы например это значит что будет менше конкуренции и можно просить большую зп. Так же открывает в принципе много компаний куда можно устраиваться), 2) да (так как в профессиональном плане я уважаю больше людей кто более, хм, профессионален). 3) да (мне самому нравится когда я могу решить задачу быстро и максимально оптимально).
Для кого-то ответы будут все нет или частично нет, а те на которые ответ "да" не будут стоить затраченного свободного времени на программирование.
Немного не так. На работу ходите/подключаетесь вы за деньги. Слушаетесь начальника - за деньги. Закрываете issue за деньги.
А вот в процессе закрытия issue есть вариант "закрыть и забыть" или самореализоваться и самоктуализироваться. Этот вариант не все выбирают, но когда человек его выбирает, то (при должной организации труда и ревью) получающееся становится значительно лучше, чем мог себе представить пишущий issue.
Кажется, все же нужно отличать разработчиков от кодеров (названия взяты с потолка, но должны отражать суть). И практически все курсы подготовки "за 3 месяца" готовят на самом деле кодеров (и их эквивалентов в смежных областях).
Я перешел в энерпрайз не так давно, но довольно быстро обнаружил, что большая часть команды -- именно кодеры. Они отлично (часто лучше меня) выполняют стандартные рутинные задачки, пишут стандартные фрагменты кода, но абсолютно не задумываются о том, что они пишут. Из-за чего на ревью выпадают детские ошибки или нерациональные с точки зрения ресурсов конструкции, которые легко можно заменить на более оптимизированные за О(1) времени и сил. А иногда эти ошибки и недочеты едут в прод, если на ревью не попадается такой мчудак как я, который пытается найти баланс между затраченным временем/ресурсами и качеством кода, и доебкапывается до мелочей.
И это более-менее работает на этапе начальной разработки. А потом перестает. Перестает, когда нужно найти проблему и починить. Перестает, когда нужно расширить функционал, а существующая реализация просто чудовищна. Перестает, потому что кодеры могут знать много разных умных слов, описывающих принципы разработки, но не уметь применять их (или применять подобие принципов без реальной пользы). И все это в конечном итоге приводит к потере денег бизнесом. Медленнее разработка, больше багов и работы для саппорта, больше счета за облачную инфраструктуру из-за нерационального использования ресурсов.
"Войти в айти" (тм) и стать кодером -- не так уж и сложно, но все равно требует усилий. Проблема в том что зачастую кодеры производят впечатление чуть более совершенной версии GitHub Copilot, и не на каждую должность можно попасть с такими навыками.
А как вы думаете: что нужно, чтобы стать именно разработчиком, а не кодером?
Вопрос сложный, а ответ и решение скорее всего индивидуально для каждого. Не считаю себя полноценным разработчиком потому что понимаю, сколько вещей я на самом деле (еще) не понимаю.
Скорее всего, граница пролегает в процессе (само-) обучения. Если работать с 9-до-5 и в остальное время не трогать ПК, наверное можно стать крутым разработчиком, но для этого нужен талант. Для простых смертных типа меня работает внерабочая активность -- участие в опенсорсе, пет-проекты, следование за инновациями в платформе (большниство технологий сейчас имеет как минмум один крупный релиз в год, значит каждый год есть что-то новое, что стоит выучить). Посещение конференций (хотя бы в формате просмотра докладов), изучение best-practices. А еще велосипедостроение. Многие считают что это бесполезная трата времени, и это так, когда это касается работы. А вот для себя построить велосипед очень полезно -- по пути вы сделаете ошибки и столкнетесь с ограничениями, а потом сможете изучить, как профессионалы избегали таких ошибок и обошли ограничения, сравнив свой велосипед с industry standard.
Еще помогает смена области. Не в смысле работы, а в смысле "влезть к соседям в свободное время". Возьмите бесплатный движок, напишите игру. Пусть это будут бестекстурные шары на прямоугольной площадке. Сделайте глупый SPA сайт с двумя кнопками или напишите консольную утилиту для группировки любимых сериалов на диске. Скачайте .csv какого-нибудь государственного органа любой страны и посчитаете какую-нибудь простенькую статистику на python/R/Julia. А потом создайте базу и запишите туда результат. Выложите код в репозиторий, наладьте CI, контейнеризуйте, обложите тестами. Возможно, ничего из этого вам напрямую в работе не понадобится, но это способствует двум вещам: 1) получению опыта и обучению процессу "обучения" и 2) изучение практик и подходов в смежных областях, удачные решения из которых можно позаимствовать. После этого никакая новая технология, никакой новый инструмент на вашем основном месте работы вам больше не будет создавать проблем. Скорее всего вы будете сразу думать "А, так это же технология X, которую я видел в проекте Y, только используется по-другому. Ничего сложного."
Как всегда, есть одно "но". Все это легко обсуждать если вам айти-тематика интересна. Если вы в дестве хотели написать свою игру, или хотите создавть свой собственный сайт, или разобраться как что-то работает, или заставить тупой код работать быстрее в 10 раз, применив оптимизацию, или автоматизировать рутину потому что бесит выполнять одно и то же действие -- поздравляю, вас скорее всего ну нужно заставлять в свободное время возиться с кодом, вероятно вы и так уже это делаете. А вот если написание кода это тяжелая работа и после трудового дня нет никакого желания написать даже строчку в своей программе -- достичь результатов будет сложнее просто потому что заставить себя сложнее. Как и везде -- если ваша работа это ваше хобби, жить гораздо проще.
И здесь кроется основная проблема. Если условный гик с детства пришел в айти, ему там комфортно. Даже работая на неинтересной работе в кровавом ынтырпрайзе, это все равно его среда. А если человек, с детства хотевший стать, не знаю, писателем, ненавидящий все эти схемы, чертежи, карты, графики и графы, математику, пытается войти в айти потому что там платят многа деняк, а не потому что хочется -- я не уверен что у такого человека получится поднятся выше условного "кодера", i.e. работника, выполняющего рутинные задачи стандартными способами. Но это не значит, что нужно бросать все и не работать над собой. Просто это будет тяжелее.
как всегда ИТшники это только программисты )
Цитирую "в марте 2022 года спрос на курсы по программированию вырос на 180%, по аналитике — в три раза по сравнению с 2021 годом.", хотелось бы сказать вот что, указ на счёт IT специалистов вышел примерно в марте и тогда было сказано что их трогать пока что не будут, дело в том что их на службу не возьмут и вы должны сами понимаеть, что никто в армию не хочет (особенно те кто уже пойдет на призыв) и поэтому появился такой наплыв в IT, если внимательно следите за новостями то можно всё сопоставить и понять всю суть наплыва :))
Я все хочу написать текст, почему я не хочу в IT, хотя окружающие все время удивляются, почему я туда не иду и полагают, что прямая дорога именно туда.
Если кратенько, то хобби, которое становится работой - это недюжинное испытание, не каждый выдержит.
Ну, например, я пишу периодически разные примочки на работе для автоматизации рутины. Но делается это в щадящем режиме - в основном. когда захотел, тогда иначал, когда захотел, тогда и закончил. Очень редко бывает, что есть какой-то дедлайн, но и в этом случае решение об автоматизации я все равно принимаю сам и внутренне соглашаюсь с сроками, оцениваю трудности, размер труда, планирую работы и подозреваю о подводных камнях. Я не обязан - если мне что-то покажется долгим и сложным, то я решу проблему вручную и к ней если возвращусь, то в удобное время. Или периодически я беру со стороны залетные заказы от мелкочастников за мелкий прайс чисто чтобы не терять навыки и иметь практику - но опять-таки, я как-то договариваюсь о комфортных для меня условиях работы и жестко не связываю себя. Сумею сделать когда надо - получу денежку, не сумею - буду разговаривать, ничего страшного, если не получу ничего и ничего не буду делать, это просто хобби.
Обычно код никто не смотрит, и дальше интерфейса не критикует. А если и смотрит, то обычно это юзеры, которые не соображают ничего в технических вопросах.
У меня муращки по телу пробегают, когда я представляю, что некто будет мне жестко давать задания, ставить сроки, требовать оптимальности (и мне придется извращаться в обязательном порядке для не очень заметной оптиизации), анализировать код, критиковать и снижать за все это зарплату. Я адски не хочу ставить свое благополучие на такую шаткую основу, как нахватанные тут и там бессистемные знания с относительно небольшим опытом, к крупным проектам скорей всего крайне нерелевантным.
Входить в IT с этими знаниями еще можно было в начале 2000х, когда деревья были большие, а перспективы неясные. Но сейчас толкаться за относительно небольшие деньги вместе с молодыми несколько лет - не знаю, нужна просто бездна отчаяния, чтобы я ухватился за эту соломинку.
Вакансия она как бы обычно одна на одно место.
Резюме человек(джун тот же) может разместить пять штук, а легко и десять. Поэтому делить одно на другое такое себе дело.
Трудный вход и легкий выход. Кому не подходит работа в IT?