Pull to refresh

Comments 428

С одной стороны вроде все правильно и очень хорошо что хоть кто о думает о проблемах начинающих разработчиков.
Но с другой как вспомню как нам приходилось начинать — ни интернета, ни путевой литературы, ни вменяемых наставников. Да что там интернет — доступ к современному компьютеру был большой проблемой. Так сразу кажется — да молодежи теперь только стоит захотеть и ты уже программист с такими возможностями какие 30 лет назад нам и не снились.
ИМХО, конечно, и наверно это уже старость…
Да, то были прекрасные светлые времена))) Сейчас у джунов на уме только бабки и нежелание учиться… печаль
Ну собственно говоря, девушек заместили бабками и на этом всё.
Вспоминается анекдот про диалог двух дедушек, которые справляют большую нужду:
— Никифор, а помнишь раньше когда срали — яйца до земли доставали?
— Даааа, стопталась землюшка, стопталась…

Нынешние джуны растут в принципиально другой информационной среде и, не побоюсь сказать, практически другой культурной парадигме. Будьте к ним добрее :)
Да, так и есть. До сих пор помню как методом «научного тыка» изучал басик на спектруме. Потом на толкучке приобрел пару книжек. Одна была по программированию игр на ассемблере а вторая была больше похожа на справочник по аппаратному устройству и командам процессора. Как же было их трудно читать не имея ни малейшего понятия почему все устроено так а не иначе и не имея никакой возможности у кого-либо спросить — тогда еще не было не то что интернета, а и сотовых еще не было. А преподаватели часто знали меньше учеников — что в школе что в кружке (там стояли БК со своим басиком И как тогда казалось спектрум их опережал намного по своей продуманности и простоте). Только только в страну потекли первые x86-совместимые компы которые мог себе разве что крупный бизнес позволить. И когда в итоге он появился у меня через пяток лет уже было проще понять как и почему оно работает. И да — это старость =)
А сейчас можно в качестве примера перенести этот опыт на, скажем, ракетостроение.
Тоже практической информации почти нет, до всего нужно самостоятельно доходить ценой свободного времени, терпения соседей и прочности отцовского гаража. Зато раздолье в плане стандартизации — (почти) ничего ж не контролируется, мешай себе реактивы для топлива да следи только, чтоб ничего не сжечь (это я утрированно, уверен, что в реальности много сложнее). Зато лез через сорок уже ничего просто так не запустишь — везде правила, стандарты, обязательные к выполнению, если хочешь получить работу, да еще и небо закидано такими убердевайсами, на которые смотришь, и руки опускаются — до этого уровня надо ракетами заниматься с глубокого детства целенаправленно, а не пройдя пятилетний курс «Основы ракетоведения» в провинциальном педуниверситете.
Тогда была проблема найти информацию. Сейчас есть проблема не проще — отфильтровать информацию. Сложно начинать, когда тебе со всех сторон предлагают совершенно разные пути и никто не может объяснить, чем они отличаются. Я начинал программировать на спектруме (и это в 2000 году!) с одной книгой в руках и отлично вас понимаю. Но ещё я учусь программировать сейчас и считаю проблему поиска качественной информации не менее важной. Я находил фактические ошибки в самой рекомендуемой книге по изучению python, я вижу полнейшее безумие советов в каналах по JS и не вижу тенденций к улучшению. Неверные знания хуже их отсутствия. Поэтому наставник нужен как никогда.
Согласен! Сейчас трудно отфильтровать действительно ценную информацию от мусора.Помню времена, когда в школе стояли «Агаты» и по ним всего пару книг, которые шли в комплекте(по сей день где-то лежат на память). Еще сейчас все делается на фреймворках, изучить хотя бы несколько требует много времени, если заниматься этим самостоятельно. Плюс на изучение только ночи. Днем работа, вечером дети. Устроиться джуном — самый лучший вариант научиться. Учишься и получаешь деньги. Уже голова не болит где взять деньги и жена не терзает, что сидишь в компе занимаешься фигней по ее мнению
Я, кстати, тоже учился ещё на спектруме. Написал программу для решения уравнений методом дискриминанта. Тогда понял, что памяти впритык и начал изучать assembler.
Сейчас конечно гораздо проще учиться, но этого недостаточно для того, чтобы сразу стать мидлом, вот в чём проблема. Опыт работы ничем не заменишь.
Раньше ничего не было, а сейчас слишком много всего и разобраться, что из этого важно, а что нет становится очень сложно, особенно когда нет опыта.
Не согласен. Проблему избытка информации нужно решать систематизацией.
В первую очередь — изучить основы. Во вторую — выбрать для себя направление и методично двигаться по нему, но не забывать оглядываться по сторонам чтобы не оказаться чересчур узким специалистом. Лучше всего конечно делать это с помощью опытного наставника, но если его нет при желании можно справиться и самому.
Логично из фразы вытекает то, что опытных адекватных наставников сейчас навалом. да?
За относительно небольшие деньги да. В крупных городах по крайней мере. В интернете материала для изучения навалом.

Раньше и в требованиях вакансий кучу узкоспецифичных фреймворков не указывали.

А если указывали, то перед этим думали, действительно ли такой фремворк нужен или хотя бы изредка используется. Сейчас в текст вакансии просто копируют из википедии все фреймворки, какие найдут, а пользоваться ими даже не собираются.

Но вообще, господа будущие джуниоры! Ну не надо приходить на собеседование, если вы не способны на основном языке написать код «открыть файл, пересортировать строчки, сохранить файл». Таких приходит больше половины.
Я сейчас тоже не смогу слёту написать код «открыть файл, пересортировать строчки, сохранить файл», потому что не делаю это каждый день
Вообще забыл, когда последний раз с файлами работал

Главное же знать принципы работы, уметь находить решения
А частности на собеседовании спрашивать — я думаю, это лишнее, их лучше перемещать в тестовое задание
Но вообще задач с файлами полно, особенно их много в университетских лабораторных. Про работу с файлами всегда пишут в книгах "<язык программирования> для начинающих".
Так что если человек понятия не имеет как работать с файлами то не понятно что он читал и что делал в университете.

В конце концов если он не помнит конкретных методов, то пусть продемонстрирует как их найти.
Покажете, как это из JS в браузере сделать? Без участия пользователя.

Вы, конечно, сейчас пытаетесь хитрить, но и там найдется винт с резьбой LocalStorage, sessionStorage, IndexedDB и т.д.

Это намого более высокоуровневое API, имеющее мало общего с обычной "работой с файлами".

Да. Это троллинг в ответ на троллинг. Господин выше выбрал заведомо невыполнимый кейс — записать в файл из js в браузере. Если бы он просто сказал js, ему бы указали на node.

Отнюдь, new ActiveXObject(«Scripting.FileSystemObject») — и вперёд. В неправильных браузерах с неправильными настройками работать не будет :)
Но с другой стороны никто особо и не требует знания какого-то конкретного фреймворка. Знаешь один — сработаемся.
Но с другой стороны никто особо и не требует знания какого-то конкретного фреймворка


Чушь. Сплошь и рядом ХРюша сверяет список ключевых слов в вакансии, кратком списке навыков и развернутом описании опыта в резюме.
А чего вы от джуниора ожидаете? К нам часто приходят джуны и мы их охотно берем. Главное увидеть, что человек хочет учится и готов думать башкой при выполнении задач.
А умение решать конкретные задачи — это всего лишь умение прочитать документацию или доступные варианты в интернете. Остальное приходит с опытом.
От джуна ожидаю способности написать Hello World. Без подсказок. (ну со справкой в зубах, конечно.) Приходит же явление, которое через раз на Power User не тянет. Я до ВУЗа умел больше, чем эти ребята — после.
Если не сложно, охарактеризуйте пожалуйста, как понять джуниор ли я.
Ежедневно пытаюсь впитывать пусть (не тонны то хотя бы на пол шишечки) информацию, но все равно при просмотре требований джуниора .NET к примеру, понимаю что там одних только фреймворков сколько, что у меня в школе предметов меньше было, так еще и помимо этого знание и SQL и HTML и CSS и еще много-много страшных слов.
Требования через раз пишут менеджеры (эффективные), которые сами не понимают в теме от слова совсем. Программисты от них отмахиваются общими фразами, а менеджеры эти фразы преобразуют в общие требования. Вот и получаются такие объявления.

Калькулятор написать, скомпилировать и запустить можете? Отлично, вперёд к работе! Через одного — не могут.
> но все равно при просмотре требований джуниора

Требования не важны. Важно, умете ли вы решать на практике конкретные задачи.
Я знаю очень хорошую, а потому очень правдивую шутку.
Миддл может вытянуть проект один без «оркестра». Джуниор, соответственно, не может, а сениор — не будет.
Ну не скажите, анекдот «Если бы водителей нанимали как программистов» я впервые прочитал лет 15 назад:
Вакансия: водитель.Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами “Формулы 1″ — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.Зарплата: определяется по результатам собеседования.
Наверняка он появился бы и раньше, но рунет начал широко продвигаться только тогда.
Описание вакансии, обязанности.
IT: техническая поддержка компьютерного оборудования и программного обеспечения офиса в соответствии с ICT стандартами, принятыми в организации ( включая настройку/наладку оборудования, установку/удаление программ, резервное копирование данных, обновление антивирусных программ, настройку e-mail/интернет), обзор рынка и закупка необходимого оборудования, помощь/обучение пользователей компьютеров;
Транспорт: организация транспортного обеспечения офиса, обслуживание а/м организации (включая техническое обслуживание, страхование, контроль расхода топлива и т.д.), функции водителя (при необходимости);
Закупки: обзор рынка и осуществление местных закупок, ведение соответствующей документации.
Помещения, ремонт и техническое обслуживание: поиск и отбор помещений для заключения договоров аренды (офис, квартиры, склад – по необходимости), участие в переговорах, поддержание всех арендуемых помещений в исправном состоянии, нести ответственность за соблюдение правил пожарной безопасности и охраны труда.
И это не анекдот, а цитата из вакансии пятилетней давности.
Неудачный пример. Всего лишь завхоз-эникейщик с водительскими правами.
Высокой квалификации во всем почти не требуется. Только работы и ответственности навалили.

Честно говоря такое только в вакансиях на пост-советском пространстве видел. На зарубежных сайтах всё вполне цивильно.

UFO just landed and posted this here
Только когда вы начинали, технологий было меньше. Меньше библиотек, фреймворков, языки имели меньше функциональности, паттернов и различного рода подходов к программированию. И они все появились только потому, что те кто начал раньше, раньше увидели что нужно улучшать.
Современному же джуниору нужно знать все эти библиотеки, подходы, паттернов, фреймворки сразу.
Не 30 лет назад, скажем лет 10, тоже свои заморочки, если сейчас браузеры практически сравнялись, то тогда могло быть такое: в firefox все нормально, а в ie все не раскукошится. Разный синтаксис для верстки в различных браузерах. Скругленные углы картинками. Свои события и методы js для разных браузеров и их разных версий.
Да поддержка IE10-11 и сегодня головная боль. Кроссбраузерная верстка тоже имеет отличия (FF-Chrome). Да что там далеко ходить — я добавил alert с выводом служебной информации и пользователь прислал мне (внимание!) скриншот, потому что во всех браузерах можно выделить и скопировать содержимое alert'a, а в Yandex Browser'e — нет. Представьте себе поток, закодированный в base64, который вам скинули в виде скриншота. Умереть не встать.
Да поддержка IE10-11 и сегодня головная боль. Кроссбраузерная верстка тоже имеет отличия (FF-Chrome).

Хорошо, что вы не застали верстку под IE6.

Но вообще-то всё было сложнее. Мы писали на си, где шаг влево, шаг в право это расстрел и всё что ты видишь это «segmentation fault». И у нас не было resharper`а который исправит твои мелкие ошибки в синтаксисе, автоматически подключит недостающие билиотеки. Компилятор, текстовый редактор и развлекайся как хочешь.
Дело не в том больше или меньше технологий, а в том как к ним вообще получить доступ.
Представьте что у вас вообще нет ни домашнего компьютера, ни интернета, ни специальной литературы, а только обрывочные сведения из журналов и ТВ.
Как думаете выросли бы у вас возможности претендовать на вакансии или нет?
Представьте что у вас вообще нет ни домашнего компьютера, ни интернета, ни специальной литературы, а только обрывочные сведения из журналов и ТВ.

Согласен, 10 лет назад был именно в такой ситуации, чего то хотелось — но где инфу брать неясно, как что то делать — неясно. В таких условиях трудно что то делать. Только потом сначала телефон с интернетом появился (сказать честно — не сильно мне помог), а 6 лет назад, на втором курсе уже комп появился, с доступом к нормальному интернету, только тогда смог начать сначала навыки работы с ПК нарабатывать, потом уже пошло: линуксы как десктопная система, разные попытки программировать и т.д. Прогресс пошел только когда появился комп и интернет.
Согласен, 10 лет назад был именно в такой ситуации, чего то хотелось — но где инфу брать неясно, как что то делать — неясно.


Не понял.
Инфы полно уже с прошлого века (это почти 20 лет как).
Интернет давно существует.
Интернет давно существует, доступ у всех к этому интернету — до сих пор не у всех есть.
А мне тут понятно.
В России как раз 10 лет назад стал развиваться массовый доступ в интернет. Телефоны были сильно слабее и дороже.
А если в глухой провинции то все еще сложнее, особенно если некому подсказать и направить.
Но то теперь те кто целыми днями торчат в соцсетях в крутых смартфонах жалуются что не знают где взять нужную инфу. Они просто не знают что такое сидеть без информации.
Да, все именно так, маленький поселок в провинции, стоимость телефона даже просто с интернетом сравнима с месячной зп, про смартфоны и тем более компьютеры не говорю, так что позволить себе это мы не могли. Если сравнивать ситуации без ПК и с переизбытком информации (напомню — комп с интернетом у меня с 2012, не так уж давно чтобы кардинально объемы с тех пор увеличились) — я однозначно выбираю переизбыток информации.

В 2008-м? Похоже на байки бабушки Арины… Уже в сотовых сетях инет был и довольно доступный, а мопедно-дслный так и подавно даже в глухоманях. Не быстрый, конечно. Обычно в Зажопинсках на 64-128 кбит подключал Ростелеком (или что там было на него месте), но этого хватало для полноценной работы, чтения, переписки, чат-общения, просмотра понро и кино

Я там выше описывал что кроме теоретической возможности провести интернет — нужно еще иметь устройство позволяющее к нему подключаться)
Примерно та же ситуация, только на год раньше. И при этом я скучаю по тем временам, когда голова была чиста от информационной лавины. Когда один в классе компоновал рефераты по книжкам и писал их от руки на «зебре», а не качал и печатал готовые. Когда мог целый день заниматься полезными вещами и не тратить время на отвлекающие факторы, кроме редкой болтовни по телефону. Когда надеялся, что программировать буду только на работе, а дома удастся избежать соблазнов, на которые подталкивают компьютеры и интернет… Но вышло строго наоборот.
А мне тут понятно.
В России как раз 10 лет назад стал развиваться массовый доступ в интернет. Телефоны были сильно слабее и дороже.


В 2008 году?
Да ладно.

В 2004 еще поверю.
Я из глухой преглухой Сибири.
У нас еще в 1994 году появился интернет. Да медленный и дорогой. Но в принципе к году 2002 он был уже вполне доступен частному лицу при большом желании.
Большее желание нивелируется финансовой составляющей.
Большее желание нивелируется финансовой составляющей.


Я тогда уже ребенка обеспечивал и квартиру снимал.
Тем не менее интернет у меня был.
А некоторые были с ребёнком и ожиданием зарплаты и обещаниями со своего.

PS. А телефон был или у милиционеров или у железнодорожников. Модема не было — некуда им звонить.
А телефон был или у милиционеров или у железнодорожников.


Вы из 1950-х приехали?
У однокурссницы был интернет на спаренном с соседями телефоне — да. Они ругались что как не позвонишь там что то шипит. Она ругалась что как не выйдешь в интернет — связь рвется из-за соседей.
Вы точно из российской глубинки? Это там где в 2008 было на весь поселок из 2к человек в районе 50 ПК, и почти половина из них в школе? Там где только пару лет как стала сотовая связь в принципе доступна? (помню году в шестом было всего несколько мест где ловило) и т.п.?
Вы точно из российской глубинки? Это там где в 2008 было на весь поселок из 2к человек в районе 50 ПК, и почти половина из них в школе?


У нас федеральные трассы покрыли сотовой связью еще к 2006 году.
Году к 2010 самая дальняя деревня уже была с интернетом.
Да, до сих пор есть места, где плохо ловит интернет и даже телефон.
Но в целом уже лет 10 как ноутбуком уже не удивишь и в самой глухой деревне.

Если вы из горного района — это другое дело. Там проблемы и до сих пор во многих деревнях. Горы экранируют.
Да нет, центральная Россия. Даже представить не могу откуда такая разница. Интернет в деревне к слову был у нескольких человек. Но не у меня (семья скажем так… небогатая была), и у близких знакомых тоже не было.
Но не у меня (семья скажем так… небогатая была), и у близких знакомых тоже не было.


Тут вряд ли деньги.
Скорее — желание, приоритеты.

Дело в том, что я-то вкусил интернета еще в ВУЗе и плотно на него подсел. Стал важнейшим приоритетом.

И после этого уже даже когда было слишком дорого — все равно платил провайдеру.

Это как автомобиль. Пока его нет у человека — он может считать, что автомобиль и не нужен. А как появляется, но потом исчезает (сломался, авария, нет денег) — уже его очень и очень хочется заполучить назад.

Вот только с ним познакомиться нужно еще) А если компьютер вживую только на уроке информатики видишь, да и там изучение ограничивается вордом и qbasic (дико понравился в то время) — то как то даже не представляешь себе каково оно. Ну и все таки позволить мы себе этого действительно не могли. Как то телевизор сломался — больше года без него жить пришлось, а уж компьютер…
Вот только с ним познакомиться нужно еще)


Ну да. Об этом и речь.
Как познакомился — так приоритет появился, родителей убедишь. В принципе им-то все равно чем детя тешилось — лишь бы не плакало.
Дело в том, что я-то вкусил интернета еще в ВУЗе и плотно на него подсел.

Сложно было вкусить то, что показывали на старшем курсе один раз (ездили в Дом Учёных для этого). Но во всяких журналах компьютерных читали, на конференциях рассказывали о такой классной штуке. Идея гипертекста выглядела фантастической (хотя всякие хелпы со ссылками на другой раздел и были чуть ли не в NC3 и сами даже делали из го… подручных материалов).


Скорее — желание, приоритеты.

Приоритеты — пожрать или интернет, отличный выбор.

Приоритеты — пожрать или интернет, отличный выбор.


Я допускаю что где то в отдельных местах был такой выбор.

Но, повторяюсь, я, будучи молодым папашей с неработающей женой и живя на съемной квартире (это очень дорого было — 50% дохода на аренду квартиры) — тем не менее позволял себе интернет.

Не самых быстрый тариф, но тем не менее.

Хорош жаловаться на жизнь.

Все в ваших руках.
В очень многих местах был такой выбор, а позволить себе интернет могли разве что в крупных или особенных городах, где не видели выплату зарплаты продукцией и думают что их исключительные условия были везде.

> Хорош жаловаться на жизнь.

Очень странно называть представление о реальном положении вещей жалобами, у меня-то как раз всё хорошо было, но я бывал не только в крупных городах и имел возможность сравнить очень разные условия. Далеко не везде они были такими прекрасными.
Чуть новее, но даже в начале 0х именно так и было. И это не глухая деревня, а узловая станция (именно потому у железнодорожников — сотовой связи нет и как-то оповестить об аварии надо).
Ваша глухая Сибирь случайно не в районе новосибирского Академгородка?
В моем глухом городке проводной телефон провести было проблемой.
Это теперь он даром не нужен, а тогда в 2002 году надо было подать заявление и ждать в очереди не известно сколько лет.
Впрочем, если среди близких родственников был директор городской АТС то вопрос решался за месяц-другой.
Но у меня со связями всегда было никак, так что до 2008 года интернетом пользовался только на работе и то примерно с 2000-го года.
А интернет в 1994 в преглухой Сибири… Шикарно вы там жили.
Ваша глухая Сибирь случайно не в районе новосибирского Академгородка?


Даже вообще не в передовой по части ИТ Новосибирской области.
Да ладно?!
В 2008 году интернет в России был очень даже хорошо развит. Сайтов и информации уже было море. Тот же хабр уже как два года существовал к этому времени.
Даже модемы к этому времени уже исчезли.
А вот в 1998 да, интернет только развивался, модемы, диалапы…
В 2008 да, интернет уже довольно хорошо развился, но прежде всего в крупных городах.
Какой интернет мог быть в городке где проводной телефон был еще проблемой, а GPRS если был то тормозной, не стабильный и дорогой?
В общем кому как повезло, где то пусто, а где то густо.
что-то вы путаете, наверное всё-таки не 10, а 15 или 20 лет назад?
10 лет назад уже айфон и андроид были, GPRS, ADSL, радиомосты, не говоря уже про диалап
Вы наверно все по столицам да по заграницам.
Я же писал о удаленной провинции. В каком нибудь небольшом городке 10 лет назад с интернетом было гораздо хуже чем в крупных городах.
А в некоторых и теперь проблемы.
А книги, что отменили? Лично я и в 95-м и в 2005-м большую часть информации о компьютерах и программировании получал из книг. Причем стоили они тогда гораздо дешевле чем сейчас. За счёт бОльших тиражей.
Ну да, была в библиотеке школьной пара книжек. Правда было одно но: без компьютера это было не так интересно.
Дело даже не в том что не интересно, а в том что устарело уже на момент издания книги. Если и стоило изучать то чтобы хоть что то знать.
Ну, тут еще сыграли роль мои заблуждения, учитывая уровень информатизации моего поселка — я был в полной уверенности что спрос на программистов никакой (нужно человек по 500 в год, причем только вундеркинды какие то), и планировал этим заняться в будущем, как хобби, а поступать в медицинский, или, если не пройду, то на экономиста))
я был в полной уверенности что спрос на программистов никакой


то есть вы выбираете профессию по спросу, а вовсе не потому что она вам нравится?
Не совсем так, вы пропустили пункт про то что их требовалось по моему мнению тогда человек 500 в год, куда уж мне, хорошисту у которого достижений разве что районные олимпиады по математике, информатике и физике, тягаться с призерами всероссийских олимпиад, краснодипломниками МГУ и т.д. Собственно поэтому «здраво» решил оставить это как хобби которому свободное от учебы и работы время посвящать, а идти работать в нужную сферу типа медицины и экономики. Впрочем даже с медициной не сложилось, не хватило моих 238 баллов по трем предметам для поступления на бесплатное, пришлось на экономиста идти. Для меня тогда программирование выглядело именно как rocket science, круто, интересно, но шансов попасть нет из за тупизны собственной и потому что берут лучших из лучших. Ну а когда понял реальный порог вхождения — было поздно уже что то менять, решил доучиваться на экономиста, благо 2 года всего с копейками оставалось, да и специальность называлась «Прикладная информатика в экономике»
Это Вы о 95-м или 2005-м годе???
Тогда вообще не понятно. Тогда книги не устаревали о-очень долго. Например, Фигурнов издавался несколько раз с не очень большими изменениями. О Фаронове (книга по Турбо-Паскалю) вообще молчу…
Ну это у нас, в СНГ. На западе откуда все приходило гораздо динамичнее все развивалось.
А Фигурнов это ведь про IBM PC, а про Apple, например, не помню литературы.
Ну это у нас, в СНГ. На западе откуда все приходило гораздо динамичнее все развивалось.


Не-а.
И у них раньше было нужно мало программистов.

Скачок в этих технологиях, быстрая их смена и большая востребованность программистов — веяние сравнительно недавних времен.

Разница с Западом только та, что там чуть-чуть раньше началась автоматизация, чуть чуть раньше появлись персональные компьютеры и пр.

Взять ту же Delphi, наследницу Pascal, описанного Фигурновым.
Delphi обеспечивала фирме Borland весьма устойчивое положение на рынке вплоть до границы веков. И MS ничего не могла противопоставить пока не переманила архитектора Pascal/Delphi из Borland. Это было в самом конце 20 века только.

Вы видимо каких то тепличных условиях вообще были.
Наверно и книги и новые программы вам доставляли сразу как только они появлялись. Мне же приходилось ждать их годами.
Дельфи когда я смог посмотреть он был уже то-ли 5й то-ли 6й.
До интернета у меня доступа еще не было. Приходилось во всем разбираться методом тыка либо компилировать в голове какие то обрывочные сведения.
Вы видимо каких то тепличных условиях вообще были.

Сибирский город с населением около 65 000 человек на тот момент, когда я начал изучать ИТ в 1987 году. Железная дорога появилась в 1985 году. До того — только самолеты и вертолеты. Полная изоляция. Автомобильная дорога появилась только в этом веке.
Ближайший населенный пункт с более-менее адекватной инфраструктурой (где то 220 000 жителей) — в 330 км.

Приходилось во всем разбираться методом тыка либо компилировать в голове какие то обрывочные сведения.

Дает более глубокое понимание.

Это скорее плюс, если удается сохранить мотивацию.
Вам грех жаловаться.
Это в глухом сибирском городе у вас был класс с ДВК-2 и DEC или в вузе? Если уже в вузе то все равно вам повезло. У нас в вузе были доступны только чугунные терминалы ЕС ЭВМ и СМ-4 раз в неделю.
Это в глухом сибирском городе у вас был класс с ДВК-2 и DEC или в вузе?


В ВУЗе в середине 199x уже были Apple и IBM PC.
И это уже было в сибирском городе покрупнее — 500 000 жителей.
Много ли компьютеров Apple было в 80-е — начале 90-х в СНГ? Считанные единицы. Если у Вас был, не могу даже сказать, повезло Вам или нет…
Много ли компьютеров Apple было в 80-е — начале 90-х в СНГ? Считанные единицы.


Два полных класса Агат-2 (совместимые с Apple II) в 1988 году в глухом сибирском городке в только одной нашей школе.
Полный класс Apple Macintosh в 1995 году в небольшом сибирском областном центре в ВУЗе
Дело даже не в том что не интересно, а в том что устарело уже на момент издания книги. Если и стоило изучать то чтобы хоть что то знать.


Машина Тьюринга или Pascal — вполне себе актуальны. Даже книжка по Java из 1995 в 2005 году если не актуальна, то на 95% полезна.
30 лет назад и программирование было не как сейчас. 5 лет назад я спокойно писал приложения под андроил, а теперь открываю и не знаю с чего начать. Куча новых SDK, какой то Kotlin… О котором я 5 лет назад и не слышал и сомневаюсь, что он тогда и был.
А при чем тут Kotlin? Это просто язык программирования, изучать его или игнорировать можно независимо от разработки под Android.
Я вообще никаких отличий в программировании под Андроид не вижу с тем что было 5 лет назад.
Был Эклипс, стал Android Studio. Причем этого можно было и не заметить, потому что ведут они себя очень похоже.
Даже уроки по написанию приложений 5 летней давности вполне спокойно делаются сейчас.
Что у вас так сильно изменилось в программировании под Андроид?
А что там особенного? Писал для себя под Android пару лет назад. Действительно интересно, что изменилось.
Да, но что нужно было учить?
Бейсик? HTML?

А сейчас даже не язык программирования, а сразу паттерны + CI + фреймворк
Что нужно было учить 15-20 лет назад? C++ с тогдашним STL, алгоритмы, межпроцессное взаимодействие, работу по сети, способы работы с динамическими библиотеками/модулями/оверлеями, системный API, всякая специфика типа DCOM/ActiveX/OLE или Qt. SQL, bash, MFC, азы криптографии, работа с последовательным портом — это всё могли спросить на собеседовании младшекурсника без опыта работы, претендующего на должность младшего программиста (в трудовой писали: «техник разработки ПО») лет 15-20 назад.
В этой ветке обсуждаем 30 лет назад, а не 15-20.
30 лет назад вместо компьютера, помню, изучал программирование на калькуляторе Электроника Б3-34, а код программ читал в журнале Техника молодёжи в публикуемой частями фантастической повести Путь к Земле (там электронщик Александр Перепёлкин и пилот Михаил Коршунов летят с Луны на Землю на крохотном лунолёте «Кон-Тики»). Эх…
1988 год?
Вовсю уже программировал. ДВК-2, потом Агат
Насчет ДВК-2 вам очень сильно повезло. В 88м только у счастливчиков у кого родные на заводе в АСУП или в институте был доступ к таким аппаратам.
А с агатов в школе мое айти и началось. Только каждый месяц ломались и чинились подолгу. А через год и чинить перестали.
или в институте был доступ к таким аппаратам.


У нас был списанный из вычислительного центра аппарат.
А к году 1990 подтянолась из того же ВЦ списанная DEC (не СМ-ЭВМ, а фирменная)
Целых две списанных персоналки!
Да одна импортная!
Да еще работающие!
Да вы олигарх!
Для того времени, конечно…
Целых две списанных персоналки!

+ класс Агатов-2. Полный класс Агатов-2
А ДВК-2 была не одна, а с терминалами, то есть работало более 1 человека.
Вытирая скупую слезу: Да вы издеваетесь
Два класса Агатов (7 и 8, вроде, в разные годы или замена одного на другой — не помню), 2 класса БК, класс PS/2.
С БК-0010Ш даже кружок был, позволивший прикоснуться к замечательному языку Фокал(«а во втором классе, представляете!, даже клавиатуры не нарисованные, а настоящие»), Агаты тоже были сравнительно доступны, PS уже почти в конце обучения появились (главное разочарование — 5.25" там бесполезны и нужно искать эти новые 3.5", а без них там даже Бейсика в ПЗУ нет, зато с ними — TP, TC и Clipper).
И я о чем говорю. Но что у нас было на ДВК? Фреймворки? Системы контроля версий?

Нет, была простенькая RT11SJ, простой бейсик и не слишком сложный, особенно по текущим меркам ассемблер.
И требования к программам на компьютере, где нет графического режима — невысокие.
В журнале Техника Молодежи, именно в то же время также постилась рубрика «БК за рога» с различными приемами для БК-010-01, а чуть позже и что-то для Спектрума.
В этой ветке обсуждаем 30 лет назад, а не 15-20.

Мало помню, было два года. Но лет в 6 была книжка по алгоритмам для детей, там учили рисовать блок схемы, все перемежалось красочными картинками с изображением компьютера в виде человека в разных ситуациях.

Я когда учился в школе в 90-е был записан во все библиотеки своего города и просто охотился на практически любую литературу по программированию. Но так как я жил в Казахстане не в областном центре, то такой литературы было очень мало. Попалась мне более мене стоящая книжка по Паскалю, ПЛ1 и какая-то совсем простая по Бейсику. Всё остальное были мануалы по досу, нортон коммандеру и т.д. Как-то получилось съездить в областной центр и я там в местной библиотеке удачно нашёл книгу по QBasic, но прочитать успел только несколько страниц. В это время я программировать толком не научился, писал только самые простые программы. Полноценно учится программированию я начал только 10 лет спустя.

С одной стороны юниоры ноют, что не берут, с другой стороны пересмотрел за год около 1500 резюме -простой sql запрос мало кто может написать. Какая то пустота в глазах — берите на испытательный, учите, да и еще некоторые умудряются спросить оплачивается ли тестовое часовое задание. Уровень очень низкий.
Вот тут как раз рекрутеры и нужны, а не там где их применяют. Вот тут как раз нужно фильтровать вменяемых их кучи.
Ну и очень мало компаний имеют программы работы с джунами. Что довольно странно — как раз у них сейчас к сениору ставят в требования коммуникативные навыки и пачку soft-skills. А как миддл может вырасти до сениора, если не будет работать с джунами.
В крупной компании не может быть вменяемого управления талантами и развития сотрудников без стабильного притока джунов.
> А как миддл может вырасти до сениора, если не будет работать с джунами.

А какая связь между ростом до сениора и работой с джунами? Я же верно понял, что речь не о сениор-воспитателе в детском саду?
Нет, но в обязанности сениора входит работа с мидлами. Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем. Повторюсь, речь идет о крупных компаниях, и там как правило нельзя просто подойти и сказать — э, слышь, уася, так не делай, так делай, сосулька башка попадет. Бывает даже вообще просто сказать что где-то ошибка нельзя, нужно «правильно подбирать слова в соответствии с политикой компании». Научится всему этому можно только на реальном опыте. Миддл может его получить только работая с джунами.
К слову говоря, когда миддлы приобретают такой опыт сами, они гораздо лучше работают с сеньорами, для них процесс передачи знаний перестает быть односторонней процедурой.
> Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем.

Энто ведь все в рамках рабочего времени? Ну, типа «я сегодня никаких тасок не выполнил, потому что наставничал с Васей, проходили с ним наследование». Работает же так? Ежели да, то окей.

> Повторюсь, речь идет о крупных компаниях, и там как правило нельзя просто подойти и сказать — э, слышь, уася, так не делай, так делай, сосулька башка попадет.

Согласитесь, это проблема конкретной компании, а не сениора. В нормальных компаниях принято говорить как есть. Ну потому что это банально эффективнее.
Энто ведь все в рамках рабочего времени? Ну, типа «я сегодня никаких тасок не выполнил, потому что наставничал с Васей, проходили с ним наследование». Работает же так? Ежели да, то окей.

В той компании где я работал, там были требования, но не было возможностей. Потому я там больше не работаю, ибо это бред. Но на уровне тимлидов была официальная «статья» расхода времени, управление командой. И на нее можно было списывать определенное количество времени в месяц, да. Хотя и не очень много.
Согласитесь, это проблема конкретной компании, а не сениора. В нормальных компаниях принято говорить как есть. Ну потому что это банально эффективнее.

Нет, это не проблема компании. Потому что это не эффективнее. Ты быстрее передаешь свое сообщение и даешь обратнуюсь связь, по этому кажется что это проще, и в каких-то отдельных случаях или сработаных командах это работает. Но не в масштабах крупной компании. Мало сообщить человеку что он ошибся, надо это сделать так, что бы он остался этим доволен, как это не парадоксально это звучит. В крупняке все держится на горизонтальных связях. Ты скажешь Васе что он накосячил, а он в следующий раз отправит тебя официально оформлять заявку на его работу. А ближайший общий руководитель у вас CEO и заявка пойдет через директоров департаментов, если они между собой договорятся. Нет — через вицепрезидентов. Вопрос который может быть решен за пять минут будет решатся пару недель или месяцев, в зависимости от того, насколько многим людям вы неаккуратно успели высказать свое мнение.
Нет, но в обязанности сениора входит работа с мидлами. Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем.
Это где такие «обязанности»? Что, так прямо в job description и записано? :) Я работал (и работаю) в нескольких весьма крупных американских и транснациональных компаниях, но ни разу подобных «обязанностей» не встречал. И, скажу, жутко бы удивился, встретив подобное… «пионэрское отношение», скажем так.

Это что, в России так крупные компании работают? Пережитки развитого социализма у руководства? ;)
В вакансии этого не пишут, просто потому что смысла нет. Таких кандидатов просто нет, а вакансии закрывать надо. Без этих навыков наймут без проблем, даже на сениора. Но повышение вы не получите. Конкретно та американская компания в которой я работал имеет довольно широкую линейка чисто технических позиций и сениор это что-то в районе середины. И да, для каждой позиции прописаны компетенции, и hard skills там занимает только несколько строчек и прописаны весьма абстрактно, в духе «миддл владеет одним фреймворком, а сениор несколькими». Подавляющее число компетенций это именно soft skills. К слову, что забавно, таблицу эту почему то рядовым сотрудникам не показывают, и доступна она была только директорам департаментов, которые непосредственно участвуют в повышениях, тимлидам только по секрету. Так что не исключено что до вас такие вещи просто не доводили. Я практически уверен что в любой компании >1000 сотрудников >10 лет на рынке есть такие таблицы компетенций.
При всем при этом в компании не было никаких программ повышения этих самых soft skills. Сейчас работаю в отечественной компании, где наиболее продвинутое обучение сотрудников на локальном рынке. Хотя тоже на поток не поставлено.
Вы не ответили на мой вопрос. Я вас не про таинственную таблицу спрашивал (но про которую обязательно, для повышения хабровского ЧСВ, нужно заметить, что «до вас такие вещи не доводили» :) ), а про ваши обязанности (если, конечно, вы работаете senior software engineer) — входит ли в них, официально или не официально требование «быть примером другим, проявлять наставничество» (например, ваш менеджер подошел и сказал вам: «Константин, ты поопекай да поучи наших джунов»).

Замечу, что мой опыт работы (за 25 лет только в Штатах) наверняка намного больше, чем ваш, и в крупных и очень крупных компаниях (в США) я работал в несколько раз чаще, чем вы (если очень интересно, могу в личке рассказать), но нигде и никогда никто не ставил задачи «опекать и учить джунов и/или интернов»!

Учатся здесь в колледжах и университетах, а в компаниях, обычно, занимаются бизнесом, работают. А позиции открываются под конкретный проект и конкретные задачи, а не «а не взять ли нам senior software engineer вообще, пусть наших джунов подучит», и уж что-что, а заниматься сеньору уж есть чем.

Еще замечу, что, во-первых, обычно уровень начинающих разработчиков, с которыми мне приходилось сталкиваться, довольно высок (даже студентов-интернов), а во-вторых, никогда я не видел отношения к ним, как к «джунам», что описывают некоторые тут. Наоборот, обычно менеджмент (team lead или project manager) всегда неоднократно подчеркивает, что «все мы — команда высококлассных экспертов», хотя на деле это далеко не так. В-третьих, западные молодые люди очень не любят непрошеных «учителей» (коими, как я по топику заметил, любят быть выходцы из России или россияне), чувство собственного достоинства и независимости в людях очень сильно развито, и при подобном отношении «морду лица» вам бить не будут, конечно (не тот менталитет и воспитание), но вот менеджеру обязательно пожалуются, хотя могут даже и публично, на митинге. «Наставнику» будет очень стыдно в этом случае.

Учатся же на работе люди сами: реализовывая задачи и проекты от простых к сложным, учась работать над code review (по обе стороны — ведь ревьювить код от гуру не менее поучительно, чем выслушать его замечания касательно собственного кода), во многих крупных компаниях существуют программы по повышению образования и квалификации, так что желающий может за корпоративный счет пройти курсы, получить сертификаты, поучаствовать в семинарах и «хакатонах», или даже вообще, выучиться на MBA (но это уже не для программистов). Было бы желание, как говорится.

Но, подчеркну, нигде и никогда я не встречался с официальными или неофициальными требованиями (цитирую) «ты должен быть примером другим, проявлять некоторое наставничество»!
Упоминание таблицы было не для ЧСВ, оно и было ответом на ваш вопрос, который вы проигнорировали. Да, это совершенно точно было требованием, черным по белому прописанным в списке компетенций по моей позиции. И это было не официально, так как (я уже сказал и вы снова на ЧСВ приписали) это вообще странным образом доводилось до сотрудников.
Возможно, разница в вашем восприятии связана с тем, что вы работаете в американских компаниях, как я понял, в самой Америке? Я то работаю исключительно в России. Тут есть, знаете ли, некоторый дефицит с высококлассными экспертами, уж очень велик спрос и миграция. Ну а про непрошенность — я вроде вполне немало обернул тему наставничества разными условиями, что бы стало понятно, что речь не идет о том что бы лезть и тыкать человека носом в его ошибки. Но смысл — вы же все проигнорировали, да?
Каким «ответом»? Перестаньте отвечать на выдуманные вами же вопросы, и ответьте прямо на мой: кто и когда потребовал от вас «ты должен быть примером другим, проявлять некоторое наставничество»? Ваш менеджер, таинственная таблица, должностные инструкции, памятка сотрудника (employee handbook)?

Я то работаю исключительно в России.
Вот это, скорее всего, и является ответом — да, похоже, это чисто российская специфика плюс менталитет «страны советов».
Особенно занятен металитет страны советов у американского руководства в американских компаниях, да.
Вопрос был — входило или нет, я на него более чем подробно ответил.
Если уж теперь вы спрашиваете кто — непосредственный руководитель. Как на собеседовании так и в процессе работы. При том это было не в одной компании. Звучит это обычно приблизительно так: «Ищем сильного разработчика. У нас есть хорошая команда, ребята молодцы, но все мидлы, нужен кто-то опытный что бы за ними присмотрел». Формулировка от компании к компании отличается в соответствии с реальными обстоятельствами, но смысл остается.
Таблица компетенции — это спускалось уже из головного офиса в силиконовой долине. Бывало как-то даже HR при найме указывал как рекомендацию по конкретному сотруднику при его найме, в устной форме. Не знаю, может и записывали это куда, у меня к их делам не было доступа.
Так вполне конкретно?
Нет у американского руководства американских компаний подобного совкового менталитета, я тут это твержу уже 100500 раз! Не требуют тут «воспитательства», «обучательства», «присмотрения» — лишено всяческого смысла, и бизнес-перспектив.

Если уж теперь вы спрашиваете кто
С чего это вы решили? Я спрашиваю то, что спрашивал с самого начала. На мой вопрос можно ответить либо «да», либо «нет». У вас проблемы с пониманием?

Ну, и про пресловутую «таблицу» (которая, судя по приведенному маразму «миддл владеет одним фреймворком, а сениор несколькими» существует только в вашем воображении — в жизни не поверю, чтобы вменяемый человек с нормальным умом и здравой памятью мог подобное сочинить!) и ЧСВ, процитирую:
К слову, что забавно, таблицу эту почему то рядовым сотрудникам не показывают, и доступна она была только директорам департаментов, которые непосредственно участвуют в повышениях, тимлидам только по секрету. Так что не исключено что до вас такие вещи просто не доводили.
— не нужно быть дипломированным психологом, чтобы понять, для чего написана эта фраза :) И, кстати, только одной это фразой вы раскрылись полностью — ну, да Бог вам судья…
Это уже слишком толсто, сдаюсь.
"- Рабинович, ну почему вы всегда отвечаете вопросом на вопрос?
— Это я отвечаю вопросом на вопрос?!" :P
Вы все-таки ответьте на исходный вопрос. Если к концу недели вы скажете, что не решили ни одной задачи, т.к. занимались «менторством», то это будет ок? К вам не будет предъявлено каких-либо претензий?
Будет точно также, как если вы выберите любую другую не приоритетную задачу и будете заниматься ей одной, а все остальное будете игнорировать — определенно не ок. Хотя, если у вас вдруг, по какой то причине выдалась неделя без работы (а такого там не бывало), то это не было бы проблемой. Да и не очень понятно, как вы собрались тратить на менторство целую неделю? Ментор — не тренер, и не учитель, это не отнимает много времени.
Я не помню, сколько точно отводилось времени, но вроде что-то около 10% в месяц, и оно включало в себя некоторую организационную беготню вроде сдачи месячной отчетности, встреч один на один и плановых ревью (например испытательного срока). Этого было вполне достаточно.
В той компании где я работаю сейчас, есть такое понятие как idle, состояние между проектами. В него тебя привлекают либо к внутренним проектам компании, либо ты тратишь его на обучение. Период может составлять несколько недель. Менторство идет фоном, по аналогичной схеме, но без формализации. Вроде за него, я слышал, даже доплачивают, но я пока еще не вписался. На нашем проекте что-то забуксовало.
> Будет точно также, как если вы выберите любую другую не приоритетную задачу и будете заниматься ей одной, а все остальное будете игнорировать — определенно не ок.

То есть менторством следует заниматься тогда, когда нет приоритетных задач? Вы же понимаете, что де-факто это значит «не заниматься никогда»?

> Ментор — не тренер, и не учитель, это не отнимает много времени.

А что вы понимаете под менторством тогда, давайте определимся?
То есть менторством следует заниматься тогда, когда нет приоритетных задач? Вы же понимаете, что де-факто это значит «не заниматься никогда»?

Если в вашей компании неприоритетные задачи не делаются никогда, то и о менторстве думать несколько преждевременно. Как я выше писал очень немногие компании вообще готовы к этому. Для этого должны быть грамотно выстроены процессы, и, несомненно, решены вопросы выживания бизнеса как факт.
А что вы понимаете под менторством тогда, давайте определимся?

Ментор — наставник, который корректирует и направляет развитие. Его задача не обучать, а направлять обучение, помочь срезать дорогу в развитии. Подсказать какую книгу лучше почитать, какую технологию освоить, и как лучше к ней подступится. Другими словами ментор не учит, а помогает в обучении, что бы оно шло быстрее и качественнее.
> Ментор — наставник, который корректирует и направляет развитие.

Я не вижу, чем «наставник» отличается от «учитель». Человек направляет обучение, то есть обучает, значит, он учитель. Давайте вы попробуете на примере каком-то объяснить разницу?
Обучать и направлять обучение это две большие разницы. Процесс обучения требует активного вовлечения. Условно говоря, учитель тебе рассказывает технологию и как ей пользоваться, а ментор отправляет читать документацию или книгу, уточнив на что стоит обратить внимание, а на что забить. Учитель читает лекции, а ментор нет. Работа с ментором предполагает самостоятельное обучение. Учитель при этом тоже может присутствовать. Например ментор за получением каких либо знаний может отправить к учителю(тренеру, коучу) по определенному направлению или технологии, если в этом есть смысл.
>Работа с ментором предполагает самостоятельное обучение.

Мне кажется, любое обучение предполагает самостоятельное обучение, разве нет?

> Например ментор за получением каких либо знаний может отправить к учителю(тренеру, коучу) по определенному направлению или технологии, если в этом есть смысл.

А учитель не может?
Мне кажется, любое обучение предполагает самостоятельное обучение, разве нет?

Предполагать, и являться — разные вещи. Обучение в университете, прохождение тренингов, лекций и курсов, предполагает сомостоятельное обучение как дополнение, но крайне редко являются обязательной частью программы. Само по себе это обучение не может проходить без ведущего и самостоятельным не является.
А учитель не может?

Может и стоматолог, пока у вас рот анестезией занят. Вопрос в том, к кому зачем вы идете. Если учитель не читает лекций и не учит, а только указывает вам направление, то он уже не учитель, а ментор.
При всем при этом в компании не было никаких программ повышения этих самых soft skills.


А зачем всем повышать soft skills? Тогда никто работать не будет. Ведь soft skills, они для чего нужны? Для того, чтобы припахать работать за «большое спасибо» того, кто ими не обладает.
Это что, в России так крупные компании работают?


Это везде так работает.
Менее квалифицированных специалистов нерентабельно без присмотра более квалифицированных оставлять, если у вас есть эти более квалифицированные.
Про практику code review, поди слышали, да и, полагаю, на практике сталкивались? Вот такой, к примеру, вид наставничества.

С джунами — вообще все сурово. Их если не опекать, не проверять, не формулировать задачи в деталях, то потом за ними 100% переделывать придется. Впрочем, при острой нехватке денег (или при незначительном приоритете каких-то разработок, при отсутствии культуры программирования, при отсуствие квалифицированных спецов в штате) — все же нередко идут и на самостоятельную работу джунов.
Это везде так работает.
Везде так не работает. А «практику code review» в нормальных компаниях применяют ко всем pull request-ам, вне зависимости от того, кто их делал.

Ответьте, ставил ли вам менеджер задачу «опекать и проверять джунов», было ли это упомянуто при вашем устройстве на эту позицию? Или это ваши личные «тараканы» (похоже на то)? Удивляюсь, как вас, при таком отношении, еще не уволили — в Штатах (настоящих, а не выдуманных) очень не любят «опекунов», молодежь здесь самостоятельная, грамотная и с большим чувством достоинства (западное воспитание).
Извините что встреваю, но я вот ваш этот вопрос обдумал и пожалуй отвечу: действительно, не только в солнечных калифорниях задачи опекать джунов никто явно не ставит. Однако этого ожидают, иначе вообще зачем брать сеньора? Раз джунов не надо учить, так они значит все уже умеют и справятся сами. И получается что если вы их не учите (можно это называть красивым импортным словом менторство) то не выполняете одну из основных рабочих обязанностей. И теперь у меня встречный вопрос: а как вместе с джунами делать один проект не обучая их? Джун написал код с ошибками или архитектурно кривой. Что бы ему это объяснить надо показать как должно быть т е научить или же просто выполнить работу за него. Я правильно понимаю, что вы предлагаете второй вариант или у вас есть какой то свой рецепт как не делать первое когда работодатель явно это не указал, но не делать и второе т к второе хуже первого?
Вообще-то, позицию открывают в зависимости от требований и бюджета проекта, а не «на всякий случай, шоб було», или «менторства ради», никто просто так деньги не тратит (не должен, по крайней мере). В каких бы компаниях я не работал (и «совко-перестроечных» — давным-давно, и в американских — последние 20 лет — и крупных, и средних, и в стартапах), исключая первую работу, еще в СССР (там да, брали, ибо положено по штату, есть «дырка в сетке», обязаны заполнить), это правило соблюдалось всегда, ибо собственник считает свои деньги. А зарплата, должен я вам заметить, весьма существенная часть бюджета любого проекта, по крайней мере, в software development (речь, понятное дело, идёт про Запад; не знаю, работает ли это для России).

Отвечая на ваш первый вопрос, скажу: «сеньора», то бишь опытного программиста, берут не для «опекания и наставления джунов», а для решения вполне конкретных задач в текущем проекте/проектах. Если таких задач нет, или бюджет не позволяет — то не берут :) Джунов, как таковых, тоже просто так не берут (да и словосочетания такого, «junior software developer», я давным-давно не встречал в описаниях позиций!); обычно это интерны, студенты на неполный рабочий день за небольшие деньги, которые приходят набраться опыта, ну, и обеспечить себе дальнейшее трудоустройство.

И теперь у меня встречный вопрос: а как вместе с джунами делать один проект не обучая их? Джун написал код с ошибками или архитектурно кривой. Что бы ему это объяснить надо показать как должно быть т е научить или же просто выполнить работу за него


Теперь перейдем ко второму вопросу, на него ответить тоже просто (благодаря моему практическому опыту). Любой, сколь угодно большой и сложный проект, состоит из подзадач, субпроектов, гораздо менее сложных, нежели общее. И практически любую подзадачу можно тоже разбить на еще более мелкие и более простые подзадачи. Вот тут «вступают в бой» project manager с team leads (ну, или Scrum master с product owner, если ваша контора страдает agile в лёгкой или тяжёлой форме :) ). Главная задача хорошего менеджмента заключается в умном распределении работы, программисты с меньшим опытом получают более простые задачи, опытные «бросаются» на более сложные/срочные. Т.е. ситуации «джун не справился с задачей» практически никогда не возникает. «Говнокод с ошибками» отлавливается на этапе code reviews, и, естественно, никакой pull request не будет замержен, пока код не достигнет production качества. А вот много зависит от требований к code review, притом требования предъявляются ко всем, и существуют в виде документа (так было в двух из трех компаний, в которых я работал/работаю). Можно, конечно, объявить code reviews видом «менторства» (если пытаться притягивать за уши), но как быть, когда менее опытный программист ревьювит код senior-а? ;)

Замечу еще, что обычно хороший менеджмент ценит team spirit и хорошие отношения в команде намного выше, нежели отсутствие showstopper в production; я бы сказал, что неизмеримо выше. И, по американски, хорошая команда — это команда равных, когда никто не чувствует себя «лузером джуном» и «супер-дупер гуру сеньором»! Надо сказать, что мне доводилось встречать кьюкамеров, мальчиков из России, мнивших себя супер-экспертами, и соответственно ведших себя в команде. Что можно сказать? Наиболее умные из них быстро понимали, насколько они не правы, и принимали новые правила игры. Менее умные вскоре теряли работу.
По первому пункту я еще могу согласиться — т е берут опытного когда джуны не справляются или берут просто так потому что положено =) А вот со вторым тогда получается заминочка…
Т.е. ситуации «джун не справился с задачей» практически никогда не возникает. «Говнокод с ошибками» отлавливается на этапе code reviews, и, естественно, никакой pull request не будет замержен, пока код не достигнет production качества.

Ну ок — вы отревьюили код джуна и указали ему на ошибки/проблемы. Как предлагаете быть если джун не понимает как их исправлять или даже не понимает вообще суть ошибки?
Можно, конечно, объявить code reviews видом «менторства» (если пытаться притягивать за уши),

Почему бы и не объявить? Тем более что одна из задач code review — это научить того кто писал код так больше не писать =)
но как быть, когда менее опытный программист ревьювит код senior-а?

Это как раз тоже часть обучения через пример. У него в этот момент могут возникнуть вопросы на которые опытный должен ответить. И иногда не понятно где кончается code review и начинается обучение. И это как бы все времени требует. Можно конечно это все засунуть в рамки code review но смысл то тот же — время будет потрачено на обучение.
Ну ок — вы отревьюили код джуна и указали ему на ошибки/проблемы. Как предлагаете быть если джун не понимает как их исправлять или даже не понимает вообще суть ошибки?
На практике такого никогда не возникало; это означает существенные просчеты и ошибки в системе найма. Но если бы я столкнулся с подобной ситуацией (т.е. так называемый «инженер» не умеет, не может выполнять свою работу и не справляется со своими прямыми обязанностями), то я бы передал проблему вышестоящему менеджменту.

Тем более что одна из задач code review — это научить того кто писал код так больше не писать
Нет таких задач у code review. Учите матчасть.

У него в этот момент могут возникнуть вопросы на которые опытный должен ответить.
Слово «должен» здесь лишнее. Никто никому ничего не должен (честно говоря, я уже устал это повторять). Более опытный инженер может помочь менее опытному, что, на практике, часто встречается (ведь проект-то общий!), но может и не помочь, никто обязать его это делать не может. «Учитель может летать! А может и не летать...» (с) :D
Как предлагаете быть если джун не понимает как их исправлять или даже не понимает вообще суть ошибки?


На практике такого никогда не возникало; это означает существенные просчеты и ошибки в системе найма.


Да ладно вам.
Это абсолютно штатная ситуация на первый и второй раз. Показываешь просто. Если не понял с двух раз — увольнять можно.
VulvarisMagistralis, я написал то-же самое, но другими словами. Ну, а на счёт «увольнять можно», то тут все сложно (вы, кстати, действительно в США живёте и работаете, что подобное пишете?). Ну, и по любому, вопросы увольнения находятся вне пределов компетенции senior software engineers.
я написал то-же самое, но другими словами. Ну, а на счёт «увольнять можно», то тут все сложно (вы, кстати, действительно в США живёте и работаете, что подобное пишете?). Ну, и по любому, вопросы увольнения находятся вне пределов компетенции senior software engineers.

  1. Не я писал про США. В РФ есть испытательный срок.
  2. senior может (и должен) выходить на руководство для решения этих вопросов, а не скрывать.


ПыСы:
Джун потому и джун, что «вообще не понимать» он может.
Но он должен быстро учиться по подсказке.
Ну, если писали про США, то должны (вероятно :) ) знать, что уволить человека по причине профнепригодности здесь практически невозможно (ибо вероятность нарваться на многомиллионный встречный иск весьма велика). В настоящей, а не воображаемой реальности, такой человек становится кандидатом на увольнение при следующем lay off. Но чтобы вот так, прямо уволили — такого в американских компаниях просто не бывает (впрочем, по слухам, в «дурных компаниях», организованных русскими/индусскими/китайскими эмигрантами, случается — но это слухи. Кстати, рекомендую прочесть книгу Саши Тараторина «Дурная компания», там, хоть излишне драматизированно, изображена подобная компания. Но той Америки уже нет — хотя я застал кусочек...)
Джун потому и джун, что «вообще не понимать» он может.


Джун это не нуль без палочки, не ученик, не студент и даже не стажер. Джун это младший разработчик, с минимальным или отсутсвием опыта разработки.

Но это не означает, что он совсем не знает теорию, не знает язык и не умеет гуглить.

Это означает, что из-за недостатка опыта, он не может выбрать самое подходящее решение в конкретном случае/проекте, что он может даже не знать названия конкретных технологий (но уметь загуглить, если ментор подскажет какую библиотеку или паттерн или даже структуру данных тут применить будет лучше).

То есть джун должен уметь работать с минимальным количеством подсказок, вдобавок в любом проекте полным полно задач, с которыми вполне справится джун, если ему иногда подсказывать.

Другая проблема в том, что джунов путают с выпускниками 3-месячных курсов, на которые бегут люди вообще без IT бэкграунда. Ну это как бы понятно — вы бы тоже не хотели, чтобы вас обслуживал стоматолог, который пару месяцев смотрел видяшки на ютубе, и 3 месяца посещал курсы из расчета 2-3 часа в неделю.
Замечу вдобавок, что в американских компаниях слово «джун» (это какой-то российский «новояз» — не русский, в русском языке такого ужасного «волопюка» нет, а именно российский) или даже «junior software developer» не употребляется вообще. Есть interns (студенты на part-time), а дальше просто software developers, engineers, вне зависимости от реального стажа.

И мне никогда не доводилось встречать абсолютно «нулевых» интернов; как правило, очень толковые молодые люди, любящие свое дело, и умеющие учиться (поскольку платят за учёбу, в основном, из своего кармана, а стоимость учёбы в приличном заведении в Штатах весьма «кусача»).
Удивительно, а мне приходили письма с предложением прособеседоваться для работы со Steam и там вполне были дополнительные приписки, о розыске разработчиков на Middle-позицию (мол кого знаете — киньте нам, чтобы мы с ним могли связаться).

А раз есть «средняя» позиция, то есть и младшая/старшая — все вполне логично.

Европейские конторы (что в EC), так же отлично знают Junior/Middle/Senior… а тут прям «поле не знающих». Удивительно.

P.S. Искали меня, как Java-EE-QA. Видимо «США разные», как и «РФ большая и разная».
Прям таки «для работы со Steam»? А не с Valve Software? ;) Опять-таки, не бином Ньютона, вот список открытых позиций, никаких «приписок»: www.valvesoftware.com/jobs/job_postings.html
Так что США всё-таки не разные; это фантазии у российских комментаторов однообразные.
Прям таки «для работы со Steam»? А не с Valve Software? ;)

А с логикой и кругозором у вас сильно плохо, раз считаете, что «работа со Steam» только у Valve.
Я не знаю, что это за работа с диваном. У меня вот дома тоже есть диван, и я знаю, как на нём работают.
© Стругацкие, ПНС

Это с «доказательствами» у вас никак, а не с моей логикой. Вместо того, чтобы привести ссылку на открытые позиции со словами «junior software engineer» в американских компаниях, начинаете банально врать.
На деле, в нормальных компаниях редко публикуются junior вакансии — и без публикации вакансии полно кандидатов.
Поэтому публикуются regular, senior, team lead, architect.
А джуниоры и интерны — можно набрать по конкурсам, по договоренностями с вузами, еще и выбрать лучших из них, которые на деле могут оказаться почти regular.

Все зависит от конторы и предполагаемой ЗП.
Сергей, я лично вас уверяю — в нормальных, и ненормальных американских компаниях слово «junior» не употребляется совершенно. Вы можете не верить мне (профессионалу, работающему в IT индустрии уже 23 года в Штатах), но попробуйте просто применить google, если мои слова вас не убеждают. Вообще, на хабре какая-то странная ситуация сложилась — мальчики с россиянским опытом работы в местечковых компаниях «учат» и «доказывают» что-то людям, для которых обсуждаемая тема является реальной жизнью.
Простите о великий белый господин.
К сожалению у меня нет «россиянского опыта работы», и работаю я не в местечковой компании, а вполне себе европейской.

Попробую «погуглить». Правда в офисе гугла в Mountain Views я был много лет назад, но слово junior там все еще использовалось.

Ну а так, первые попавшиеся ссылки:
www.ziprecruiter.com/Jobs/Junior-Software-Engineer/--in-California
www.linkedin.com/jobs/junior-software-developer-jobs-california
А работать в России в местечковой компании это позор?
Цитата из приведенной ссылки на википедию:
It is intended to find mistakes overlooked in software development, improving the overall quality of software.

Как вы собираетесь выполнить эту задачу без обучения? На каждую найденную вами ошибку джун сделает новых таких же три если вы ему не объясните в чем он ошибся и почему так делать не хорошо. Ваше code review превратиться в день сурка. Вы меня отправляете мат. часть учить, а я вас отправлю поработать с джунами (особенно когда их более одного на проекте).
На практике такого никогда не возникало; это означает существенные просчеты и ошибки в системе найма.

Вот это вот вообще странная логика — т е у вас либо джун не ошибается, но тогда почему он джун до сих пор? Либо вы предлагаете его увольнять (ну поскольку у сеньора таких полномочий нет, то свалить эту ответственность на менеджера или еще кого) Вот только тогда зачем его было вообще брать — потому как известно что это человек без опыта и возможно без части необходимых знаний. Т е само по себе его наличие на проекте предполагает, что его кто то должен менторить раз его взяли. Кто если не опытный разработчик?
Слово «должен» здесь лишнее. Никто никому ничего не должен. Более опытный инженер может помочь менее опытному

Вы хотите сказать, что если у вас плохое настроение то разъяснений по code review джун может и не получить. Как следствие он налажает и вы же потом на него донесете начальству что он не справился — что ж удобная позиция =)
> Т е само по себе его наличие на проекте предполагает, что его кто то должен менторить раз его взяли.

А зачем он вообще нужен тогда? Пользы никакой не приносит, отнимает дорогое время у действительно квалифицированных кадров. Зачем брали на работу человека, у которого слюна с подбородка капает?
Как вы собираетесь выполнить эту задачу без обучения?
Где вы нашли слово «обучение» в приведенной цитате? У вас не только с профессиональными терминами проблемы, но и с английским? А ведь вы, небось, внутренне позиционируете себя как «сеньора»? ;) Гмм, возможно, мы вообще говорим о разном? В вашем мире «джуны» не умеют программировать от слова «вообще» и нуждаются в обучении, а т.н. «сеньоры» понятия не имеют, для чего нужны code reviews, и как их правильно делать, да еще и не умеют по английски читать? Тогда нам не о чем просто говорить (а ведь тут обсуждается бред пост американской эмансипированной тётки, уверенной, что «злые буржуи не берут на работу хороших тёток-джунов»).

Вы меня отправляете мат. часть учить, а я вас отправлю поработать с джунами
Я вас никуда не отправлял, а лишь привел ссылку на вики, чтобы вы, наконец, прочли и поняли, что такое code reviews. А на счёт «посылания», опустившись на ваш уровень, могу заметить, что у вас «посылалка» еще не выросла меня посылать! :D

Как следствие он налажает и вы же потом на него донесете начальству что он не справился
Когда вы немного повзрослеете, то вы, надеюсь, поймёте разницу между доносом и продуктивной работе в команде. Взрослые люди на работе занимаются бизнесом, и решают проблемы в рабочем порядке, не привлекая сюда личные отношения; лишь только повзрослевшие дети, с недостатком образования и воспитания, пытаются повышать свою attitude за счёт других, занимаясь непрошеным «обучением, менторством» и прочей ерундой. Таких «детей» на Западе просто-напросто нет, это «выбивается» еще на уровне школы, а не колледжа. Я имею дело с профессионалами, вне зависимости от возраста и опыта работы (да это и не имеет никакой разницы). Люди все прекрасно понимают, и ведут себя соответственно, ведь иначе просто невозможно (нет, ну, можно, конечно, стать лузером, бомом, low wadge worker-ом — каждый выбирает сам, но это к теме разговора не имеет ни малейшего отношения).
Это просто тролль, не тратьте свое время зря.
Ответьте, ставил ли вам менеджер задачу «опекать и проверять джунов», было ли это упомянуто при вашем устройстве на эту позицию?


А про то, что придется пользоваться мышкой — тоже должны были написать? Это такая же естественная часть работы.

Вы ни в коем разе не сеньор будете, если заранее не ожидаете, что фирма за деньги желает получить от вас ваш опыт в разных формах.

Другое дело, что одному нравится слива, а другому яблоко, одному формы клепать, а другому кэши рисовать, одному поучать, другому бегло подсказывать джуну направление…
Т.е. ваш ответ: «Нет, никто такой задачи не ставил, просто я, в силу совкового воспитания и менталитета, так решил, потому, что это повышает мое ЧСВ».
Т.е. ваш ответ: «Нет, никто такой задачи не ставил, просто я, в силу совкового воспитания и менталитета, так решил, потому, что это повышает мое ЧСВ».


С ЧСВ все отлично и задач мне действительно никто не ставит.
Я сам владелец.
;)
хотя вот за детский сад вообще вопрос хороший. Филосовский.
Т.е. гениальному интраверту-аутисту сеньором быть не светит…
Т.е. гениальному интраверту-аутисту сеньором быть не светит…

Только в своем воображении разве что.
Сеньор-девелопер занимается сложной и объемной работой, которая делается большим коллективом. И полностью изолированным в этом коллективе быть не получится.
Одиночки — максимум до миддла дотягивают. За те годы, что их коллеги-неаутисты уже давным давно сеньоры. Вариться в собственном соку — малоэффективное занятие.
в крупной компании шансы мизерные, да. Там гении интраверты вообще нафиг не сдались.
Но и программная инженерия усложнилась многократно. Раньше было: вот С, сиди и код пиши. А сейчас все программные решения невероятно многослойные и многокомпонентные.
Но и программная инженерия усложнилась многократно. Раньше было: вот С, сиди и код пиши. А сейчас все программные решения невероятно многослойные и многокомпонентные.


Упростилась.
Повысилась производительность труда.
Уменьшился порог входа.
Кроме Си был еще и ассемблер, если уж говорить про те годы. А это уже знание как работает «железо» под капотом, знание протоколов, спецификаций.
Я сейчас тоже испытываю проблемы с поиском работы на java. Писал на Delphi до этого, опыта на джаве мало. И учиться вовсе не лень, просто учиться бесплатно уже некогда, деньги надо зарабатывать. Я бы не против устроиться за небольшую ЗП, лишь бы хватало семье на покушать, но с перспективой роста. Но таких вакансий нет (в Питере немного есть, а в моём городе нет совсем).
Насчёт того, что всё есть в инете, ну как сказать… пишу тестовое, проверяю: всё работает, оформил как положено. Приходит ответ: классы не так назвал, SQL не там у меня и т.п. Может инфа об этом в инете всё есть? Ну конечно нет! Большинство примеров, по которым учился уж точно хуже моего кода.
Может инфа об этом в инете всё есть? Ну конечно нет!

Как это нет? Да здесь хотя бы на Хабре поищите. Насчет того что
классы не так назвал, SQL не там у меня
то о таких вакансиях жалеть не стоит. По моему не очень адекватные работодатели, намучаетесь с ними. И вакансия то скорее всего от того что люди бегут от неадекватов. В ответ можете заспамить их вопросами и просьбами рассказать о их требованиях. Это опыт, хоть и негативный, но хоть немного но поможет вам в профессиональном росте.
Здесь хотя бы мне отписался человек, который смотрел моё задание. Обычно приходится иметь дело с рекрутерами, которые ничего не могут объяснить. Так что даже приятно было читать такой ответ (хоть и с отказом) после пары общений с рекрутерами.
то о таких вакансиях жалеть не стоит. По моему не очень адекватные работодатели, намучаетесь с ними.

ну вот я бы не был так категоричен — некоторые настолько мастерски называет классы, что просто печаль-печаль.


@VVS_AM а можете пример своего кода показать (например на гитхаб скинуть)?

Присоединяюсь к запросу webkumo — киньте линк на репо, я так же java-dev. Любопытно глянуть за что вас так мучить могли.
ну не совсем в плане сел почитал и ты уже сеньор
народу много, требования выше, плюс всем нужен реальный большой опыт даже на старте а где его получить не учат
да, есть куча статей, самоучителей, литературы, форумов но не всегда понятно как двигаться, с чего начать, что нужно сейчас а что можно потом понять
если раньше умеешь склепать поле ввода и кнопку ОК то ты уже джуниор фронтенд то теперь надо уже достаточно хорошо знать один из модных фреймворков и помимо него еще пару тройку инструментов так что современного джуниора пропорционально сложнее получить из анона количеству доступной информации для обучения
Думаю ниже описали эти два пункта, но я отпишусь. Сейчас много всего доступно из-за интернета. Но:
1) Фильтрация информации. Так как опыта, допустим, нет, то почти любая информация воспринимается как адекватный совет, который можно попробовать, а вариантов много, но объяснить разумность одного против другого ни кто не сможет\не захочет. Уже потом, когда начинают всплывать проблемы, становится ясно. В итоге метод тыка как был, так и остался;
2)Рост требований в IT индустрии, не только программирования. Причем рост значительный и при самообразовании не известно как развиваться и в каком направлении (сам сейчас на этом этапе).
ИМХО, прежде всего самые основы — устройство компьютера и двоичная логика.
Далее элементарные представления об низкоуровневом программировании.
Даже если программист точно никогда не будет программировать на ассемблере и Си базовые знания о них ему необходимы. Хотя бы чтобы не было иллюзий что оперативная память и дисковое пространство бесконечны.
А далее уже двигаться по выбранному направлению.
Очевидно что этот совет хороший, но не имеет НИЧЕГО общего с реальностью. О том что у вас закончилась оперативка вам сообщит операционная система, а модный язык не позволит управлять памятью. Знаниями о конъюнкции и дизъюнкции сможете только детей пугать.
Да, тяжело вам. Так вы в самом деле ни на какую вакансию не пройдете.
> ИМХО, прежде всего самые основы — устройство компьютера и двоичная логика.
Далее элементарные представления об низкоуровневом программировании.

Очень плохой совет. Пока Вася гробит время на изучение основ, Петя уже освоился с фреймворком Х, устроился на работу и получает реальный опыт.

В результате, спустя пару лет из Пети получился вполне толковый специалист, способный решать задачи, ну а Вася может написать на ассемблере приложение, которое рисует квадрат.
Ну если Вася такой тупой что кроме квадрата больше ни на что не способен то по любому он далеко не уйдет.
Если же рассматривать равные стартовые позиции то для толкового парня на освоение начального уровня в ассемблере много времени не понадобится. Может Вася немного и отстанет на начальном этапе от торопыги и рвача Пети, но потом по любому обгонит просто благодаря широте взглядов. А Петя так и будет ковыряться в давно устаревшем фреймверке Х.
> Может Вася немного и отстанет на начальном этапе от торопыги и рвача Пети, но потом по любому обгонит просто благодаря широте взглядов

Благодаря какой широте взглядов? Какую пользу, хотя бы теоретически, умение программировать на ассемблере даст при, например, написании сайта?

Один человек может сделать тудулист на фреймворке Х, другой рисует квадратики на ассемблере (сходные по сложности задачи), вы кого в качестве джуна для разработки интернет-магазина возьмете? Наверное, все-таки, человека который имеет хотя общее представление о том, чем будет заниматься?
Какую пользу, хотя бы теоретически, умение программировать на ассемблере даст при, например, написании сайта?

Согласен, для написания сайта — ассемблер не нужен. Если Петя хочет всю жизнь потратить на клепание вебформочек то он идет верным путем.
Я всегда смотрел на профессию программиста несколько шире, но если это теперь такой мейстрим то, ИМХО, как то уныло.
> Я всегда смотрел на профессию программиста несколько шире, но если это теперь такой мейстрим то, ИМХО, как то уныло.

Вот именно, профессия программиста несколько шире, чем вы всегда думали. Да, безусловно, есть области, где знание низкоуровневого программирования полезно, но есть и множество областей, где от такого знания толку нет. Если вы хотите работать в этих областях — конечно, стоит учить ассемблер, искать соответствующие места работы. Если же вы не хотите связывать свою жизнь с перекладыванием байтиков — есть множество других вариантов и тогда ассемблер вам нафиг не нужен.
Ну это как у среди медиков некоторые зубных врачей медиками не считают.
Ковыряются вечно в зубах, а что там в остальном организме их не интересует. Если кому то срочно потребуется медицинская помощь то кроме как посмотреть зубы они ничем не помогут.
Так медики ли они?
> Так медики ли они?

А почему, собственно, нет?
А почему, собственно, нет?


В США, к примеру, те, кто занимаются счисткой камней с зубов и т.п. простыми косметическими операциями с зубами — не должны иметь лицензии врача.
Из того, что _какие-то_ конкретные зубные врачи могут не иметь лицензии зубного врача, не следует, что зубных врачей не стоит считать медиками. Наоборот — ваше утверждение говорит о том, что их считать медиками стоит. Ведь для большинства зубных рвачей лицензия требуется!
Я всегда смотрел на профессию программиста несколько шире, но если это теперь такой мейстрим то, ИМХО, как то уныло.


ну-кась, приведите пример где нужен ассемблер программисту?
P.S.:
это не наезд обездоленного.
автор сих строк знает 2 ассемблера (ассемблер это не язык, а мнемонические команды конкретного процессора, поэтому его нужно учить отдельно для каждого вида процессоров)
Я не справочник. Примеров не дам.
Жаль что вы не поняли что я имею в виду.
Чтобы пояснить мою точку зрения скажу, что считаю что программисту нужно знать ассемблер хотя бы на начальном уровне чтобы иметь представление как на самом деле оно работает и чего стоят для процессора и для оперативной памяти на самом деле те или иные новомодные нововведения в языках, новые команды и приёмы.
Я не справочник. Примеров не дам.
Жаль что вы не поняли что я имею в виду.
Чтобы пояснить мою точку зрения скажу, что считаю что программисту нужно знать ассемблер хотя бы на начальном уровне чтобы иметь представление как на самом деле оно работает и чего стоят для процессора и для оперативной памяти на самом деле те или иные новомодные нововведения в языках, новые команды и приёмы.


Вы не можете привести примеры, потому что таких примеров нет в общем случае.


Для частных случаев, да. Например, если вы один из 100 000 программистов, а именно тот, кто разрабатывает криптографические библиотеки — оптимизация отдельных кусков кода на ассемблере позволит серьезно поднять производительность на высоконагруженных системах (опыт из Cloudflare, криптографическая библиотека для языка Go)

Широкий кругозор, конечно, хорошо.
Но где граница этого кругозора? До каких пределов его еще рентабельно повышать?

То что кто-то когда то начинал с ассемблера (как я например) — вовсе не значит, что этот путь и ныне актуален. В прошлом веке ассемблер действительно применялся широко. Например, при создании почти любой игры.
Вы не можете привести примеры

Может я не ясно выражаюсь, но опять вы меня не поняли. Я могу дать пример, но не хочу потому что я не Гугл и не Яндекс.
Впрочем, вот например в С++ и Паскаль можно делать вставки на ассемблере. Так что настоящий профессиональный программист на С++ и Паскаль должен если не уметь то хотя бы быть морально готовым это применить. Кто знает что ему еще потребуется?
А это уже не 1 на 100 000 программистов.
А если вдруг потребуется, что он будет искать того самого 1 на 100 000 или хотя бы попробует сам?
Широкий кругозор, конечно, хорошо. Но где граница этого кругозора?
Это каждый для себя решает сам. Но то что, видимо, в массе принято его за ужать, по моему печально.
Впрочем, вот например в С++ и Паскаль можно делать вставки на ассемблере.
Так это возможность, а не принуждение
Чтобы для одного из 100500 программистов не пришлось выпускать версию «С ассемблерными вставками»
Может я не ясно выражаюсь, но опять вы меня не поняли. Я могу дать пример, но не хочу потому что я не Гугл и не Яндекс.


В Яндексе и Гугле я найду доводы за свою позицию.
Если у вас есть что сказать за вашу позицию — соблаговолите привести.
Иначе это выглядит как слив, уход от ответа. Детский сад, короче.
Впрочем, вот например в С++ и Паскаль можно делать вставки на ассемблере. Так что настоящий профессиональный программист на С++ и Паскаль должен если не уметь то хотя бы быть морально готовым это применить. Кто знает что ему еще потребуется?


Да много где, в Go, например, тоже.

Нигде не понадобится для 99 999 программистов.
Кроме школьных, студенческий экспериментов.
Одному понадобится, я уже привел пример где.

Теперь жду ваших обоснований.

Это каждый для себя решает сам. Но то что, видимо, в массе принято его за ужать, по моему печально.


Если при этом изучаются вещи, непосредственно нужные программированию, — это как раз радостно. Работа становится более эффективно.

А то, за что выступаете вы… ну пусть программист сможет поддержать беседу о творчестве Винсента Ван Гога, это отнюдь не характеризует его как хорошего программиста.
А если время, потраченное на Ван Гога не было потрачено программистом на CI/CD — так это и вовсе, плохой программист.
Нигде не понадобится для 99 999 программистов.
Не жонглируйте цифрами. У вас есть точные данные?
Свои аргументы я уже привел, повторять не стану. Вы же, видимо, говорите о своем, о наболевшем, а именно о проблеме набора квалифицированных специалистов на свой проект.
Сочувствую, у меня тоже такие проблемы.
Понимаю, что требовать от кандидата знания ассемблера глупо, если вакансия на фронтэнд.
Только я говорил не об этом, а требовательности к себе и глубине понимания предметной области. Если требовательность к себе нулевая и заменена требовательностью размеру зарплаты, а глубина ограничена html и JS то и результат будет поверхностным.
Не жонглируйте цифрами. У вас есть точные данные?


Это легко.
Идем на hh и смотрим кто нужен.

Скольких программистов на hh может коснуться ассемблер по работе? Если мы будет листать подряд — даже не долистаем до таковых, утомимся.

Нужно спецфильтр ставить чтобы быстро таких найти — например «микроконтроллеры». Да и то — не 100%. Когда сейчас в микроконтроллеры даже ОС полноценную зачастую помещают…

Только я говорил не об этом, а требовательности к себе и глубине понимания предметной области. Если требовательность к себе нулевая и заменена требовательностью размеру зарплаты, а глубина ограничена html и JS то и результат будет поверхностным.


Вы привели html/js. Следовательно речь о фронтендере?
Если фронтендер делает сайт интернет-магазина, то ему будет полезно знать маркетинговые/торговые нюансы из предметной области.
Если она завтра делает сайт об изучении иностранного языка — было бы неплохо чтобы он хоть немножко ориентировался в языке/методиках обучения.

Вы же предлагаете какие конкретно базовые знания ему?

Ассемблер? Машина Тьюринга?

НФ — да, всенепременно и полезно.
ACID — да.
SOLID — да.
CI/CD — да, это востребованное профессиональное знание.
Т.е. цифр у вас все таки нет и вы, как вы выражаетесь, слили.
ему будет полезно знать маркетинговые/торговые нюансы из предметной области.

неплохо чтобы он хоть немножко ориентировался в языке/методиках обучения.

Вот не согласен. Возможны варианты. Если в команде есть грамотный маркетолог или спец по обучению то программисту знания в нюансах сами по себе не нужны. Т.е. они появятся просто потому что он в этом вынужден вариться, но требуют их от него в последнюю очередь.
Не видел вакансий фронтэнд программиста с требованием знания нюансов маркетинга. Если человек толковый то разберется. А если маленький стартап в котором кроме 2х-3х программистов и нет никого, то тут да — придется знать все.
Вы же предлагаете какие конкретно базовые знания ему?

Да хотя бы азы ассемблера x86 или любого другого. Не важно. Главное представление как там на самом деле все работает.
Я не предлагал нигде требовать с каждого ассемблер.
Как, например, с инженера-электроника не требуют на работе отчета по знаниям физики или высшей математики. Хотя ведь в вузе он это точно изучал. Достаточно знать что эти знания он освоил о чем и говорит диплом.
Не видел вакансий фронтэнд программиста с требованием знания нюансов маркетинга. Если человек толковый то разберется.


Ну вот вы сами себе и противоречие — широкий кругозор, выходит, не нужен?

Т.е. цифр у вас все таки нет и вы, как вы выражаетесь, слили.


Цифры я уже давно назвал: 1 из примерно 100 000 программистов нуждается в фундаментальных знаниях на уровне ассемблера.

Источник цифр — по вакансиям hh.ru
Например, тут удобно сведено habrahabr.ru/company/hh/blog/344724
Хм, один из ста тысяч, все таки мне кажется что в россии таких людей нужно больше чем 2-3
Ну вот вы сами себе и противоречие — широкий кругозор, выходит, не нужен?

Да какое же тут противоречие? Я же говорил о кругозоре в сфере ИТ, а маркетинг тут причем? Сегодня программист, по вашему примеру, кодит интернет магазин, а завтра онлайн иньяз-школу. Сегодня маркетинг, завтра иньяз, послезавтра опять маркетинг. Но все время все это делает на компьютере и никуда он от него не денется.
Я же говорил о кругозоре в сфере ИТ, а маркетинг тут причем?


Да, — в ИТ, согласен: CI/CD, НФ, ACID, REST и т.п.
Но при чем здесь ассемблер? Без этого нельзя просто знать, что интерпретируемые языки отличаются от компилируемых и что такое JIT?
Ну так они знают, что интерпретируемые языки отличаются от компилируемых, может быть.
Но это все что они знают и главное не стремятся знать больше.
> Но это все что они знают и главное не стремятся знать больше.

А зачем им знать больше? Согласитесь, ведь если выбрать случайных 10 программистов, то для 9 из них знание маркетинга окажется полезнее знания ассемблера. Разве не так?
Вот кстати совершенно верно замечено. Нынче прикладные знания по области гораздо важнее фундаментальных знаний по разработке. Вокруг столько готовых решений и фреймворков, что склеить то что нужно — дело не сложное. Обычно сложно понять, что же на самом деле нужно.
> Чтобы пояснить мою точку зрения скажу, что считаю что программисту нужно знать ассемблер хотя бы на начальном уровне чтобы иметь представление как на самом деле оно работает и чего стоят для процессора

Вы сейчас говорите, не осознавая, о такой вещи как «уровень культуры». Вот культурный человек знает, что Париж — столица Франции, а Пушкин — русский поэт. Это бесполезное в жизни знание, человек, который данных фактов не знает — он не становится от этого плохим человеком и жить ему как-то труднее не станет. Но от культурного человека мы ждем такого знания.

Вот и здесь также — есть определенная культура программиста, которая предполагает наличие определенного массива знаний. Если программист этими знаниями не обладает — он не становится худшим программистом, чем тот, кто обладает. Возможно, он прекрасный специалист, который замечательно справляется со своими рабочими задачами, и вполне себе развивается в выбранном направлении. Но можно сказать, что он,… ммм… «некультурный программист». И все.
Если программист этими знаниями не обладает — он не становится худшим программистом, чем тот, кто обладает. Возможно, он прекрасный специалист, который замечательно справляется со своими рабочими задачами, и вполне себе развивается в выбранном направлении. Но можно сказать, что он,… ммм… «некультурный программист». И все.


Тут есть разные слои.

Ассемблер — не нужно на практике большинству. Никогда не увидят на работе.
Распределение памяти динамическое — желательно, но не обязательно.
Стек как работает при рекурсии — более желательно, все таки переполнения стека встречаются.
НФ, ACID — обязательно если у тебя хоть какие то БД есть в работе.

Так же как и с Пушкиным.
Нужно ли знать Велимира Хлебникова, одного из самых выдающихся поэтов эпохи русского авангарда?
А хотя бы парочку произведений более известных Александра Блока или Сергея Есенина, ну если не полностью, то хотя бы начало? Надо или нет?
Но можно сказать, что он,… ммм… «некультурный программист». И все

Да мне вообще наплевать «культурный» или «некультурный» программист. Мне главное чтобы дело свое любил. Чтобы глаза горели. Хотя, последнее совсем идеальный вариант.
> Мне главное чтобы дело свое любил. Чтобы глаза горели.

Так он любит. И глаза горят. Именно по-этому он занимается саморазвитием в рамках этого дела, которое он любит, а не в рамках вещей к этому делу не относящихся — вышивании крестиком, пении в церковном хоре, изучении ассемблера.
> ассемблер это не язык, а мнемонические команды конкретного процессора, поэтому его нужно учить отдельно для каждого вида процессоров

Вообще, ассемблер — это транслятор из некоторого языка _на базе мнемоников_ в опкода. И чуть менее чем всегда язык ассемблер богаче мнемоников, например, именованных меток у процессора нет, а в ассемблере — есть.

А так все верно, конечно, для разных процессоров (архитектур, тем более) он существенно отличается.
Вообще, ассемблер — это транслятор из некоторого языка _на базе мнемоников_ в опкода. И чуть менее чем всегда язык ассемблер богаче мнемоников, например, именованных меток у процессора нет, а в ассемблере — есть.


Не придирайтесь.

Когда мы говорим о С, к примеру, то в общем подразумеваем — и язык С и компилятор для этого языка С вместе с линковщиком и стандартную библиотеку для этого языка С.

Давайте, я тоже придерусь: метки в процессорных кодах есть. Чем же по вашему являются абсолютные или относительные ссылки в каком нибудь jump/jmp? От того, что они записаны цифрами адреса, а не буквами названы они уже и не метки?

> От того, что они записаны цифрами адреса, а не буквами названы они уже и не метки?

Они отличаются на практике весьма и весьма, если вы код поменяете и он сместится, то именованные метки останутся как были рабочими, а смещения к чертям поедут. То есть у них _существенно_ разная семантика на самом деле, это не как соответствие «мнемоник — опкод», где действительно все один в один.
Может Вася немного и отстанет на начальном этапе от торопыги и рвача Пети, но потом по любому обгонит просто благодаря широте взглядов.


Как программист со стажем больше чем лет нашему веку скажу вам, — это не так. Главное для программиста — навыки сугубо его ИТ-шные, и именно в той отрасли, которой он занимается. Крайне полезно ориентироваться в терминах автоматизируемой вами области. И — только.

Есть только небольшое число исключений — какие-нибудь исследовательские задачи типа распознавания речи и т.п, чем занимаются меньше 1% программистов.
По моему это примерно как человек который живет на берегу океана, но все время только плавает и рыбачит вдоль берега на лодочке.
Можно его сравнивать с моряком который ходит в дальние плавания?
Как бы он тоже, конечно, морячек. У него тоже много трудностей и свой профессиональный опыт, но, все таки, настоящие моряки там.
Конечно не все так могут, не вех пускают, не все могут стать капитанами, но стремиться то надо, я считаю.
> Как бы он тоже, конечно, морячек. У него тоже много трудностей и свой профессиональный опыт, но, все таки, настоящие моряки там.

Если работа заключается именно в том, чтобы ловить рыбу удочкой, то чем поможет опыт хождения в дальние плавания?
Сидеть на берегу Океана и быть довольным только тем что рыбачишь удочкой как в каком то пруду.
Даже не мечтать о большем?
Боюсь мы с вами друг друга не поймем.
А вы не думали, что, быть может, этот сидящий на берегу человек всем доволен, а «настоящих моряков» (по-вашему) считает дураками и быдлом, которое в море ходит исключительно от того, что не может удочкой нормально ловить?
Да пусть считает, мне не жалко, каждый имеет право на свое мнение.
Только с ним я не согласен и считаю что если таких удильщиков большинство то это очень плохо.
Потому что чтобы человек делал свое дело хорошо то он должен любить это дело. А если он свое дело любит то стремится разобраться до самой сути.
чтобы человек делал свое дело хорошо то он должен любить это дело.


Совсем не факт. Достаточно может оказаться соответствовать представлениям окружающих, и вуаля, дорога к «с9-17» открыта.
Крайне полезно ориентироваться в терминах автоматизируемой вами области. И — только.

И не суметь перейти в другую область. Отличный совет (серьёзно), нужно меньше конкуренции.


то чем поможет опыт хождения в дальние плавания?

Тем, что отсутствие рыбы рядом не оставит голодным?

Только потом открывается новое направление, а фреймворк X выходит в версии 2.0 и поскольку его любимый Петей автор мыслил как он — совсем не совместим с X1.0 и знания Пети отправляются в /dev/null (о котором он даже не знает), а направление идёт осваивать Вася, который на основе полученной базы легко освоит X, X2.0, Y и Z.

Неправда ваша. У Пети будут общие знания о веб-разработке (HTML там, CSS — а может быть даже JS!) и запас времени (фреймворки мгновенно не устаревают!), а у Васи будет знание как нарисовать квадрат на ассемблере.

Не следует путать низкоуровневое программирование с общими знаниями по программированию. Низкоуровневое программирование — это одна из узких специализаций.
В вашем примере у участников слишком разые интеллектуальные возможности — рисовать квадрат на ассемблере можно за время изучения пары функций фреймворка, ещё за пару функций можно понять почему он так рисуется, а фреймворки устаревают просто — «новый проект начинаем на новом» и без понимания как оно внутри оно не сработает. Да откуда там знания HTML/CSS? Вот откуда у Васи понимания работы ПО внутри — понятно.

Но старые-то проекты никуда не деваются, и с них можно еще долго кормиться.


Да откуда там знания HTML/CSS?

А как без них хоть что-то сделать даже на самом совершенном фреймворке?

> В вашем примере у участников слишком разые интеллектуальные возможности — рисовать квадрат на ассемблере можно за время изучения пары функций фреймворка, ещё за пару функций можно понять почему он так рисуется

Да вы что, правда что ли? Сразу видно, что вы на ассемблере квадрат нарисовать не пытались. Ну или может пытались, сами, уже имея базу. Но не пытались объяснить, как это сделать, кому-то другому.

> Да откуда там знания HTML/CSS?

Потому что написать тудулист даже на самом супер-дупер фреймворке без знания цсс/хтмл невозможно. На самом деле практика современного веба такова, что написать тудулист при помощи фреймворка _сложнее_, чем без него, и требует более высокой квалификации.
> Да вы что, правда что ли?

Абсолютная. Базовый адрес в видеопамяти в один регистр, длину в другой, цикл по длине (dec + jnz или аналог) с приращением адреса и записью цвета по адресу. Я это делал ещё в те времена, когда другого способа не было. Это горизонтальная линии. С вертикальной чуть хуже — надо не inc, а add ширины экрана.
А теперь повторите это в более современных ОС.
В современных ещё проще — рисование примитива есть в графической библиотеке, нужно заполнить структуру и вызвать функцию.

Druu — и бонусом будет понимание «как оно работает», в отличии от простого юзания фреймворка.
Вот только перед этим надо сделать кучу подготовительных вызовов и сформировать кучу служебных структур данных…

И человек умеющий рисовать круг на ассемблере будет рисовать его по пикселям а не воспользуется библиотекой. Я это прекрасно знаю потому что сам таким был…
> Базовый адрес в видеопамяти в один регистр

Воу-воу-воу, полегче! Вы осознаете, что для понимания этой фразы требуется несколько полуторачасовых лекций?
Тоесть вы прямым текстом говорите: «Мне было сложно и я справился, значит ничего менять не надо, жрите кактус» Это явно старческое.
Кроме того, интернет не дает в отметок в трудовой книжке об опыте работы. Не говоря уже о фактическом опыте решения реальных задач, а не примеров из книжек.
«Мне было сложно, пусть и вам так же будет.»

Что то у вас с логикой совсем плохо. Где я это сказал?
Наоборот, я просто по доброму завидую возможностям современных начинающих программистов которые им дает современный интернет. И не понимаю жалобы некоторых, мол не дают возможностей. Возможностей у них на порядки больше чем было у нас в свое время.
интернет не дает в отметок в трудовой книжке об опыте работы

Опять не верно. Например участие в опенсорс проектах во для многих вакансий будет плюсом и специально просят указать ссылку на проекты в гитхаб.
И не понимаю жалобы некоторых, мол не дают возможностей.

Выше вам ответили и про поиск крупиц в море возможностей. И про сложность технологий. И про завышенные требования. Вы просто не пробовали учиться сейчас. Складывать 1+1 на бейсике работодатель уже не требует.
Вы просто не пробовали учиться сейчас

Вы наверно не поверите, я и сейчас учусь. И буду учится.
Просто мне нравится этим заниматься, а что требует работодатель мне до фонаря.
Если не можете определится что вам нравится, а ждете требований от работодателя то может это на самом деле на ваше?
Учусь с 13 года (в 12-м появился первый комп с 3g модемом (по факту edge), но просто базовые навыки поначалу поднимал вроде скорости печати, настройки минимально и т.п.), в 14 устроился стажером, пусть и 1с, но тем не менее продолжаю параллельно изучать программирование (общие концепции, парадигмы, и т.п.). И я только рад широте выбора.
При нынешнем экспоненциально растущем объеме информации, а с ней и количества фреймворков, библиотек и контейнеров, что равно технологиям — порог входа в профессию достаточно высок, в связи с чем увеличивается объем информационного шума, в котором достаточно не просто отфильтровать нужное. Выбора много — глаза разбегаются и поэтому «стоит только захотеть», прерывается не успев начаться, оставив после себя лишь «влажные мечты».
Поэтому ваш старт, считаю только положительной стороной.
имхо конечно.
Джуниором легче найти работу по не мейнстримным технологиям. У нас, например, долго не хватало Scala-программиста и мы готовы были взять джуниора.
В некоторых областях нынче очень не хватает джуниоров просто потому, что порог входа высоковат. Та же разработка прошивок, тут тебе и ассемблер с чистым С, и голое железо, и EFI с Linux на миллион строк кода каждая, и прочее вот такое. При этом простых IDE и утилит из разряда «нажми на кнопку — получишь результат» там не было, нет и не будет, наверное, лет 50 еще.
В итоге джуниором туда идут только самые стойкие оловянные солдатики, с которыми потом и работаем. И это все при том, что тут достаточно обычного компьютера для старта.
Ну, похоже что изменилась терминология.
Если раньше джун — это энтузиаст с горящими глазами. уже освоивший что-то по книгам, написавший несколько минимальных приложений по своим хотелкам, готовый учиться и впитывать…
ТО сейчас, это человек, который закончил профильное заведение не особо заморачиваясь с изучением и хочет найти работу, не особо понимая что на ней придется делать.
имхо, если определять термины именно таким образом, то хороший джун — один на миллион уже исходя из термина.
Ну так и есть.
Один был и раньше, но раньше не нужен был миллион. Раньше было нужно 100. И 1 на 100 легко находился. А вот одного на миллион найти уже тяжело. Тем более на фоне растущего спроса, высокой оплаты, пришли люди не идейные, а желающие получать бабло попроще.
вы так говорите, будто желание зарабатывать бабло с минимумом усилий — это что-то плохое.
Скажите, пожалуйста, ваше мнение, если придет джун-энтузиаст с горящими глазами, без профильного образования, у него есть шансы?
Порог входа намного ниже, чем раньше — это с какой стороны посмотреть.
Да, высокоуровневые языки легче учить, нахвататься основ можно быстро. Но и требования выросли, на Hello World'е сейчас не уедешь.
Не согласен, ваканисий по Embedded в целом мало, а для джунов еще меньше.
Сам ищу первую работу и вижу что всем нужны сеньоры или 3+ года опыта. По сравнению с другими областями (например JS) то там хоть больше вакансий есть в том числе и для джунов.
Мы недавно искали джуна в команду на проект, и это было очень трудно. Приходило много ребят, но почти все они были совсем зеленые, вот прям вот вообще без знаний в голове. Один парень нам подошел, но ему пришел оффер от другой компании, который устроил его больше.
Так что, я не уверен, что джунам не хватает вакансий. Для нормальных джунов, которые не протирали штаны в университетах, а учились, которые обладают знаниями и навыками, которыми должен обладать выпускник ВУЗа, вакансии есть.
UFO just landed and posted this here
что после вуза можно начинать учиться заново, но уже самому.

Учиться самому надо было еще в ВУЗе, если вы вдруг не в курсе, то по учебному плану вам отводится почти 50% времени на самостоятельную работу, вот только все на это забивают, в том числе и преподаватели.
Не совсем представляю какие вам нужны знания от выпускников

Ничего сверхъестественного. Стандартные алгоритмы и структуры данных, основы SQL (как показывает практика, большинство даже с НФ не знакомы), хотя бы базовые знания языка, на который собеседуется соискатель (в нашем случае это Java). Наличие каких-то проектов, портфолио является опциональным, хотя, конечно, важным плюсом.
Это где же такие требования к джунам? Хочу туда. По своему опыту могу сказать, что требуют много больше.
Например, «Необходимо реализовать Web приложение простого интернет-магазина.» В результате, нужно владеть Java Core, Hibernate, JSP/JSF, JSTL, Servlets, JUnit, разбираться в Tomcat, Maven, Git.
Или вот «Напишите приложение (портлет) для портала на платформе Liferay, собирающий вакансии с портала %sitename%».
То есть по факту нужно ознакомиться с неслабым стеком Enterprise-технологий ещё только в самом начале пути. Страшно представить, что творится в голове у мидлов, не говоря уж о сеньорах.
От языка сие не зависит.
Я просто показал, что «Очень простой интернет-магазин» — это очень мало кода.
8 файлов, а не 4. Никто и не спорит, что это работа не на полгода, если знаком с технологиями.
Если вам дают такие задания перед собеседованием, бежать от таких работодателей надо.
Java Core, Hibernate, JSP/JSF, JSTL, Servlets, JUnit, разбираться в Tomcat, Maven, Git.

Ничего сложного в этом нет, никто не требует от джуна быть великим специалистом в соответствующих технологиях. У нас джунам при устройстве дают пару недель на тестовое задание со спрингом, хибернейтом и пр., чтобы посмотреть насколько человек способен искать и находить информацию, и какая помощь ему будет нужна в дальнейшем для развития.
Увы, бежать некуда. Остальные проходят мимо.

Простите, а зачем НФ среднему джуну? НФ же на практике не используется — она больше заморочка DBA.

Это что-то новенькое! Вы точно ничего не путаете?

Может я чего и путаю — за давностью лет, мог перепутать НФ с прочими формами, благо я ни разу не DBA и разработка структуры БД не моя зона ответственности. Вот только если я правильно помню, что нам говорили в университете — НФ хреновато ложится/ложилась на реляционные БД.

Рекомендую вам остановиться и прочитать классическое "Введение в базы данных" Криса Дейта.


Я каждого своего джуна заставляю учить нормальные формы до НФБК, и регулярно, например в курилке или на обеде, терроризирую их спонтанными вопросами-примерами вроде "у тебя есть такая задача, расскажи как ты будешь делать базу..."


Потому что помимо прикладного навыка, это ещё и абстракция инженерного мышления.


Джуны не будут расти, если их не грузить такими вещами. Ну за редким исключением, но такие исключения недолго сидят в джунах))

Использование нормальных форм удобно, когда надо спроектировать готовую статичную базу с нуля. Если же бд приходится постоянно дорабатывать — сохранение нормальности сильно усложняет процесс, т.к. часто требует достаточно глубоко изменять структуру базы, в то время как при отказе от нормальности достаточно добавить одно поле в таблицу. Ну и это не говоря о вопросах производительности, когда то же дублирование данных просто необходимо.

Так что нормальные формы — это что-то вроде заготовки бд, которые еще, в реальности, надо будет доработать напильником.
А без сохранения нормальности надо переписывать весь DAL чтобы он правильно со всей этой хренью работал. Тоже ничего хорошего.

К счастью, в большинстве случаев можно добавить всего одно поле в базу сохранив «нормальность».
> А без сохранения нормальности надо переписывать весь DAL чтобы он правильно со всей этой хренью работал.

Да нет как раз, объем переписывания DAL прямо пропорционален изменениям в устройстве бд.

Единственное, что дает нормальность — это возможность писать запросы _удобно_. При этом страдает расширяемость бд и производительность. Классический трейдофф.

Что-то я в упор не понимаю как при замене какого-нибудь


select distinct customer 
from orders 
order by customer offset 100 rows fetch next 100 rows only

на


select [name]
from customers 
order by [name] offset 100 rows fetch next 100 rows only

может просесть производительность. А вот в обратную сторону — запросто.

В вашем примере — наверное нет (непонятно только, при чем тут нормальные формы).

А вот если, предположим, у вас отношение, для которого есть некоторый набор атрибутов А, по этим атрибутам вычисляется некоторое значение. Вычисляется долго и сложно. Чтобы не вычислять каждый раз — вы можете вычислять заранее, при записи в таблицу, это сразу нарушит 3НФ, а если атрибуты А являются строгим подмножеством потенциального ключа — то и 2НФ. Разобьете на два — надо будет делать джоин по составному ключу, при этом декомпозиция отношения будет еще и бессмысленна с точки зрения предметной области, т.к. отношения с набором атрибутов А просто не будет описывать какую-либо понятную сущность.

Сам факт декомпозиции, к слову, приводит к появлению огромной кучи лишних джоинов, которые и сами по себе не бесплатны.
С другой стороны, если оно и правда вычисляется долго и сложно — имеет смысл не дублировать такие вычисления для одних и тех же наборов значений. Пусть дополнительная таблица и бессмысленна с точки зрения предметной области — но она несет в себе оптимизацию.

Что же до «дорогих» джоинов — индексированные представления в помощь.
… при этом декомпозиция отношения будет еще и бессмысленна с точки зрения предметной области, т.к. отношения с набором атрибутов А просто не будет описывать какую-либо понятную сущность.

Возможно и так. А возможно, что и будет.

Например, в Вашем примере результат этих сложных расчётов — и есть некая сущность.

Если более серьёзно, то всё сильно зависит от парадигмы, которую мы используем при описании предметной области.

Если совсем серьёзно, то ISO 15926. Но это я видел только в областях — добыча нефти и газа, и атомные электростанции.

Если вернуться к более простым вещам, то OWL, RDF, graph databases — то же как-то существуют, хотя можно сказать, что SPARQL — это огромная куча joins…

И всё это страшно далеко от проблем начинающих разработчиков…
Рекомендую вам остановиться и прочитать классическое "Введение в базы данных" Криса Дейта.

Спасибо, обойдусь. Ни к категории джунов (которых могут по теории БД спрашивать), ни к категории тренеров (которым нужно корректно оперировать терминологией) я не отношусь, соответственно и помнить нюансы определений в сфере, где я почти не участвую — нет у меня такой потребности.


Я каждого своего джуна заставляю учить нормальные формы до НФБК, и регулярно, например в курилке или на обеде, терроризирую их спонтанными вопросами-примерами вроде "у тебя есть такая задача, расскажи как ты будешь делать базу..."

А сфера деятельности у вас, простите, какая?


Потому что помимо прикладного навыка, это ещё и абстракция инженерного мышления.

Инженерный навык это хорошо, когда он нужен. Абстракцию инженерного мышления я могу потренировать и на других областях.

Спасибо, обойдусь… нет у меня такой потребности.
Нормальная история для фронтенда или девопса, но бэкенда, заявившего такое, я бы не подпустил к коду и на пушечный выстрел.
А сфера деятельности у вас, простите, какая?
Проектирование и разработка информационных систем — от сайтов общего назначения (новостные порталы, интернет магазины и т. д.) до специальных систем обработки данных, автоматизации процессов и др.
Инженерный навык это хорошо, когда он нужен. Абстракцию инженерного мышления я могу потренировать и на других областях.
Знание баз данных и мышление в их категориях, это один из критичных навыков для бэкенд-разработчика.

Его отсутствие порождает персонажей, которые берут SQL запрос работающий 5мс и переводят в ORM так, что он работает 5 минут — просто потому, что они не понимают как работают индексы по составным ключам, например. Или страдают с запросом N дней просто потому, что не понимают как сделать каскадный JOIN на M-N-K отношение и дербанят его по частям, чтобы потом собирать обратно уже в коде. Примеров много.

Все это произрастает как раз из отсутствия понимания таких базовых вещей как нормальные формы.

Druu там выше написал, что:
Если же бд приходится постоянно дорабатывать — сохранение нормальности сильно усложняет процесс, т.к. часто требует достаточно глубоко изменять структуру базы, в то время как при отказе от нормальности достаточно добавить одно поле в таблицу.
Так вот понимание НФ как-раз и позволяет еще на этапе проектирования базы определить такую структуру, чтобы не приходилось ради добавления пары полей нырять с головой в ад миграций или забивать пол-базы нулями.
При этом страдает расширяемость бд и производительность.
Страдает она именно у тех кто при проектировании положил болт на вещи вроде НФ а-ля «все-равно база будет меняться». Если системный архитектор нормально выполнил свою работу, модификация структуры базы — штатная рутина.
> чтобы не приходилось ради добавления пары полей нырять с головой в ад миграций или забивать пол-базы нулями

Если добавление поля ломает нормальность (а предсказать заранее, когда и как у вас могут такие поля появиться, и делать пустые таблицы «про запас» — невозможно), то вам в любом случае придется обмазываться миграциями, т.к. старые данные оказываются автоматически ненормализованы со всеми вытекающими.

При этом если забить на сломанную нормализацию, вы просто одно поле добавляете, а если не забивать — вам придется добавить несколько таблиц и распределять по ним данные из исходной.
Проектирование и разработка информационных систем — от сайтов общего назначения (новостные порталы, интернет магазины и т. д.) до специальных систем обработки данных, автоматизации процессов и др.

Т.е. у вас — большая часть кода в той или иной степени прокся для данных из БД. Ну ок, вам это надо.


Знание баз данных и мышление в их категориях, это один из критичных навыков для бэкенд-разработчика.

Мне почему-то хватает размышлений о структуре данных в коде. Созданием табличек в БД мне уже больше 2х лет заниматься не приходилось. Ну и знаете, ваше утверждение очень напоминает "без знания математики ты не программист" и прочие подобные, которые под свой юзкейс подводят всех программистов.
Имхо пусть лучше этим займётся профессионал, который не только термины помнит, но и умеет оперировать преобразованиями между формами на лету, знает подробности про индексы (включая оптимальность их настроек). А мне — и хитрого джойна по 5-10 табличкам вполне хватит для разминки ума.


Его отсутствие порождает персонажей, которые берут SQL запрос работающий 5мс и переводят в ORM так, что он работает 5 минут — просто потому, что они не понимают как работают индексы по составным ключам, например. Или страдают с запросом N дней просто потому, что не понимают как сделать каскадный JOIN на M-N-K отношение и дербанят его по частям, чтобы потом собирать обратно уже в коде. Примеров много.

Не беспокойтесь, что такое план запроса, как строить inner/left/right/cross джойны и что такое индексы и для чего они нужны — я прекрасно понимаю и в большинстве случаев способен использовать к пользе дела.


Так вот понимание НФ как-раз и позволяет еще на этапе проектирования базы определить такую структуру, чтобы не приходилось ради добавления пары полей нырять с головой в ад миграций или забивать пол-базы нулями.

Поздравляю вас, что вам приходится добавлять максимум пару полей. Мне вот несколько раз (когда у меня под боком не было выделенного DBA) приходилось добавлять новые отношения. Особенно радостно было добавлять рекурсивное отношение (дерево).

Спасибо, обойдусь.

Только потом иногда получается что не понимающие "это мне не нужно, не моя проблема" делают код, который приходится или переделывать или подпирать с другой стороны.

НФ как раз-таки хорошо ложатся на реляционные БД, потому что как раз под них и придумывались.

А знать их должен тот кто схему БД проектирует или изменяет — а это не обязательно DBA. На начальных стадиях проектов схемой БД частенько управляет ORM — и тут без знания нормальных форм можно наворотить такого что потом никакой DBA такую базу не согласится поддерживать.
А знать их должен тот кто схему БД проектирует или изменяет — а это не обязательно DBA.
Вообще не обязательно. Любой backend-middle уже должен твердо знать такие вещи. Потому что когда у меня в компании over9000 проектов, я как архитектор проектирую только основную концепцию базы. И если я отдаю ее мидлу, я должен быть уверен что он не проморгает в ней какие-то детали и нюансы связанные с реализацией. И что он не впихнет туда не нормализованную таблицу, которая потом превратит в хаос работу с любыми связанными данными. Особенно, если такая таблица успеет накопить миллиарды записей.

А если это распределенная система, работающая в реальном времени, с репликациями, синхронизацией и тяжелыми данными, цена ошибки на этапе проектирования БД будет фатальной.

На начальных стадиях проектов схемой БД частенько управляет ORM — и тут без знания нормальных форм можно наворотить такого что потом никакой DBA такую базу не согласится поддерживать.
ORM управляет схемой? Что вы там курите?)))

ORM в 99% случаев лишь отражает схему в DAL. Но независимо от того мигрирует ли ваша ORM таблицы в классы кода, или же классы в таблицы и отношения СУБД — все-равно сначала нужно спроектировать саму базу и уже только потом реализовывать интерфейсы для нее в ORM.

Проект в котором приложение имеет доступ к миграциям БД для динамической модификации схемы данных — огромная редкость) И я не беру в расчет сейчас банальные вещи вроде Drupal который просто создает таблицы под ваш CCK, потому что думаю мы все знаем что потом происходит с количеством запросов к базе. ИМХО, нужно быть конченым психопатом, чтобы строить большую сложную систему по такому принципу.

Ну, в моем понимании любой backend-middle входит в круг тех кто изменяет схему БД. А потому согласен — он обязан знать такие вещи.


ORM управляет схемой? Что вы там курите?)))

Entity Framework Code First


потому что думаю мы все знаем что потом происходит с количеством запросов к базе

А что с ними такого страшного происходит, если про Eager Loading не забывать?

Entity Framework Code First
Я к тому что даже если ORM позволяет сначала написать классы-модели, а потом накатить миграцию чтобы сгенерить для них БД — все-равно нужно сначала спроектировать БД, в том числе выполнив нормализацию. Т.к. именно по проекту базы будет понятно — какие модели и с какими полями создавать, как декомпозировать, какие отношения определять и т.д. CodeFirst не заменяет собой сам процесс проектирования базы, лишь позволяет после проектирования пойти писать код для ORM, а не create-ы и alter-ы в базу, которые как раз ORM и выполнит.

Возможно разница в восприятии, я когда слышу «ORM управляет схемой», для меня это значит что в приложении есть функционал, который в штатной работе системы на лету модифицирует ее структуру. А не то, что ORM в принципе умеет это делать.

А что с ними такого страшного происходит, если про Eager Loading не забывать?
Это в фреймворке можно так сделать, когда пишешь ручками)) Например в Django это prefetch_related — а вот в коробках типа Drupal где изменение схемы данных автоматизировано и делается мышкой из админки, все работает через mainhook — и количество запросов к базе со временем становится просто убийственным))
Ну разумеется нормализацию делать нужно! Я что, утверждал обратное?

Я потому и упомянул ORM, которые управляют схемой, что они дают возможность создавать и использовать базу чистым программистам без примеси DBA — а значит, им теперь тоже нужно изучать нормальные формы.

Да, говорим об одном и том же) Спасибо за уточнение)

Может я чего и путаю — за давностью лет, мог перепутать НФ с прочими формами, благо я ни разу не DBA и разработка структуры БД не моя зона ответственности. Вот только если я правильно помню, что нам говорили в университете — НФ хреновато ложится/ложилась на реляционные БД.


Возможно, что в очень крупных организациях и не подкускают разработчиков к БД и занимаются всем DBA.

Но в большинстве случаев разработчики сами непосредственно работают с схемами БД. Это сейчас базовая грамотность. И НФ в том числе.

Лол, продолжай)) Я заинтригован)))

Если прямо сейчас меня бы спросили про НФ, смог бы только сказать, что в универе вроде 4 НФ рассматривали, и на пальцах объяснить, что если у нас таблица [имя, город, страна], то что бы привести в НФ(1?) создаем [имя, город] [город, страна]. Предположим я собеседуюсь на должность не связанную напрямую с БД. Меня завернут с таким ответом или есть шансы?
Сейчас в универе учусь, интересно, что думают люди из индустрии.
Зависит от работы, на которую Вы хотите попасть. Если менеджер проектов, то наверное не завернут.
Смотря что за должность. Как я уже писал выше — для фронтенда или девопса это не критично. Но если это бэкенд, то незнание СУБД нужно оправдывать чем-то очень весомым в плане специализации — например «Я сетевой программист и сделаю вам такие сокеты, что синхронизация распределенных по разным ЦОД реалтайм-сервисам будет летать за наносекунды».

Но при этом если вашим конкурентом на должность будет равный вам специалист, который четко ответит что 1НФ это «Атомарность», и означает что каждый кортеж отношения содержит только одно значение для каждого из атрибутов, и нарисует табличку-пример — будьте уверены, возьмут его. Потому что он может оптимизировать сетевое взаимодействие зная как определить, что в лаге виноват косяк в базе сервиса, а не сокет.

Тем не менее, изучить все времени не хватает ни у кого)) Поэтому я рекомендую вам пораньше начинать вливаться в ту сферу и должность, на которой вы хотите работать. Искать инфу, ходить по мероприятиям, докапываться до всех с вопросами.

Вам нужно определить круг критичных для этой работы навыков, без которых у вас просто нет шансов. И круг вторичных навыков — которые повышают вашу конкурентоспособность. Расставить приоритеты и учиться, а если сможете — пробовать делать то, чем собираетесь заниматься.

Идете в бэкенд — пишите сервисы для себя. Идете в РП — пишите бизнес-планы для себя. Идете в SEO — пишите планы продвижения для себя. Идете в маркетинг — пишите рыночные исследования для себя.

Если вы не сможете делать это для себя, не сможете и для кого-то. И в этом нет ничего плохого, просто значит вам это не очень интересно. И это лучше узнать на берегу, чтобы потом не пополнить ряды тех кто ноет что им не нравится их работа.

А если сможете — шикарно, поскольку у вас начнет формирования понимание разницы между учебой и реальностью. Плюс, вы сможете прямо на первое же собеседование принести тучу своих тренировочных примеров. Профит +)))
Сейчас в универе учусь, интересно, что думают люди из индустрии.


Люди из индустрии думают, что хороший разработчик должен легко манипулировать как НФ, так и обратно. Частенько нужна и денормализация. Но в процессе обучения вопросы необходимости денормализации если и рассматривают, то вскользь.

И в результате наблюдаешь, как опытные, вроде бы, разработчики нормализуют все подряд, совершенно не думая, что где-то бы и не следует этого делать.

У меня одно из тестовых заданий для джунов — сделать простой иерархический каталог, чтобы он отображался в дерево на странице — а перейдя на один из его элементов, вывести хлебные крошки к корню. Там кода на полтора экрана, но только 1 из 10 кандидатов знает про MPTT (это к слову о денормализации) и даже этому кандидату (если я его беру) приходится объяснять что он и вывод, и операции благодаря этому может осуществлять над линейным списком за 1 проход, а не рекурсивно.

Меня это удивляло ровно до того момента, пока я не узнал что преподаватели в самых разных ВУЗах тоже про MPTT ничего не знают… все это очень печально(((
Долго думал, что такое MPTT. Потом поискал в интернете что это за аббревиатура. Лично моё мнение, но я бы не рассчитывал, что многие это знают. Особенно те, кто только начинает. И уж тем более такое сокращение (впрочем, я не работаю с java(?) вообще, может это из этого мира такая аббревиатура).

Можно найти несколько книжек, где всё это аккуратно расписано ( — как представлять графы в реляционной модели). Разные варианты. С оценкой сложности для различных операций.

В своей работе я часто предпочитал делать отдельную таблицу, в которой описывают все возможные пути (и их длины) в графе… Но это на любителя…

Ещё раз — с моей точки зрения — я бы не ожидал таких знаний… Пожалуй без доступа к интернету и с ограничением времени я бы Ваш тест и не прошёл.
MPTT (Modified Preorder Tree Traversal) позволяет ЗНАЧИТЕЛЬНО ускорить чтение иерархических данных из базы, путем небольшой сознательной денормализации. Оставлю пару ссылок, там все подробно расписано.

www.sitepoint.com/hierarchical-data-database-2
www.caktusgroup.com/blog/2016/01/04/modified-preorder-tree-traversal-django

Если кратко, без MPTT быстрая вставка но медленное чтение. С MPTT медленная вставка (поскольку приходится пересчитывать атрибуты MPTT) но быстрое чтение. Идеальный вариант для больших и редко меняющихся справочников, вроде общероссийских классификаторов или деревьев гео-данных.

И я нигде не писал что прохождение моего теста сводится к знанию MPTT. Я писал что лишь 1 из 10 джунов знает о нем, остальные решают либо через JOIN-ы, либо через рекурсию.

И я никого не заставляю делать это на собеседовании, обычно даю им такой тест на дом, дня на 2-3, чтобы они могли решить задачу в комфортной для себя обстановке и с интернетом (да хоть под пиво, музыку и с девочками).

Потому что как по мне, способность быстро найти, усвоить и использовать инфу — не менее важный навык для IT-шника, чем базовые знания. Т.е. если джун знал о базах только CRUD, но за пару вечеров разобрался в MPTT и сделал с ним тестовый пример — он мне подходит)
> MPTT (Modified Preorder Tree Traversal) позволяет ЗНАЧИТЕЛЬНО ускорить чтение иерархических данных из базы,

Вы уточняйте, какого именно рода чтение. Значительно ускоряется конкретно извлечение полных поддеревьев. Если же вам надо извлечь прямых потомков или вообще все дерево и над ним произвести какие-то операции — разницы никакой.

Если быстрая операция извлечения полного поддерева вам не нужна (а это бывает очень часто, я бы даже сказал — это обычная ситуация), то и профита никакого МРТТ не даст, а вот операции вставки/удаления замедлит.
> И я нигде не писал что прохождение моего теста сводится к знанию MPTT. Я писал что лишь 1 из 10 джунов знает о нем, остальные решают либо через JOIN-ы, либо через рекурсию.

А в вашем тесте указаны явно требования к производительности данного юзкейса? Просто если нет, то здесь использование МРТТ — типичное premature optimization, и я лично даже зная заранее о такой структуре, париться бы не стал. Когда вопрос перформанса бы встал — не проблема сверху ее накрутить. Ну или (если говорить о тесте) был бы дополнительный вопрос, вроде: «какие вы видите способы для того, чтобы увеличить производительность данного запроса?»
Вы уходите от сути, начинаете рассуждать о нужности или не нужности метода. А я не метод обсуждаю, я пишу что лишь 1 из 10 джунов ЗНАЕТ О НЕМ, что он в принципе существует. Я это привел как пример простейшей сознательной денормализации БД, о котором почему-то редко в каком ВУЗе рассказывают на курсе СУБД.

Например мы все (я надеюсь, а то уже страшновато) знаем сортировку пузырьком. В продакшене никто из нас ее не применяет, потому что есть более оптимальные сортировки. Но мы все начинаем с нее, потому что если на человека сразу вывалить Smoothsort у него порвет шаблон.

Но в то же время — чем больше разных способов сортировки человек знает, тем более оптимальный код он пишет — потому что выбирает инструмент под задачу, а не переизобретает велосипеды в мучениях. С нормальными формами то же самое.
> Вы уходите от сути, начинаете рассуждать о нужности или не нужности метода. А я не метод обсуждаю, я пишу что лишь 1 из 10 джунов ЗНАЕТ О НЕМ

Это довольно специфический метод для специфических задач, я уверен, что найдется множество подобного рода методов, которых вы не знаете, но которые при этом знает кто-нибудь другой (и этот человек так же как вы будет переживать, что вот только один из десяти...).

Если в задаче было указано про оптимизацию, а человек вместо того, чтобы погуглить (сформулировать требуемые кейворды и, с-но, метод найти) все это дело зевнул — вот это уже не очень хорошо.

А предъявлять претензии вида, что кто-то не знает, чего написано в 30 строчке на 384 странице 5 тома справочника Х — не совсем, на мой взгляд, целесообразно.

Аналогично с сортировку — ну их же на самом деле миллион с разными особенностями. Важно, чтобы человек просто этот факт осознавал и был способен понять, что вот сейчас нужно найти такую-то сортировку с такими-то свойствами, и мог подобрать удовлетворительный алгоритм под запросы.
Поправка: избыточность тут есть, а вот денормализации — нет.

Возможно у меня какая-то другая область работы и я термин MPTT не слышал. Но кажется что иерархическое дерево в базе выглядит как табличка с колонками: (id, item_name, parent_id), где parent_id это внешний ключ на id в этой же таблице. Чтобы собрать хлебные крошки к корню, нужно сделать несколько запросов на получение родительского элемента. Для элемента на уровне 3 в этой иерархии будет 3 запроса и т.д. Этот вариант вам видимо не подходит.


MPTT в википедии указывает на Отслеживание точки максимальной мощности, что тоже вам не очень подходит.


Спасибо, что упомянули алгоритм. Возможно он очень поможет моим коллегам. Но я не согласен, что у всех джунов должно быть знание вот этого конкретного алгоритма.

посмотрите по ключевым словам

Joe Celko's Trees and Hierarchies

и

Bill Karwin SQL Antipatterns
> и операции благодаря этому может осуществлять над линейным списком за 1 проход, а не рекурсивно.

Вы не поверите, но операции над деревом, которое хранится в классическом варианте (ссылка на parent) тоже осуществляются за 1 проход…
Вы правы. В некоторых DBMS (и их версиях) — такое бывает. Но, насколько мне известно, не всегда (не везде)…

В целом, мне кажется, огромное количество хороших алгоритмов уже реализовано. К примеру, если посмотреть на python — scipy pandas, numpy — то, иногда кажется, что всё уже украдено сделано до нас…
Те, которых вам не дают в институте. Как слушать других. Как работать в команде. Как ставить другим задачи. Как и в какой момент сообщать, что у тебя что-то не получается. Как узнать, нужно кому-то то, что ты делаешь, или нет. Как хвалить других за хорошо выполненную работу. Как говорить «я не знаю». Как говорить «чувак, мне вот тут плохо от того, что ты делаешь, давай разберёмся в ситуации и поймём, как сделать лучше». И так далее.
Коммуникативные навыки так то ещё в детском саду формируются. И правильно делают что в ВУЗе этому не обучают.
Или отслеживать развитие навыков и переводить тех, кто не очень справляется… в менеджеры проектов

Всегда догадывался, что менеджеры проектов получаются из неудавшихся джуниор-программистов!
Если у такого человека еще и будет неплохой скилл коммуникации, то менеджер из него будет что надо.
Ну, все-таки «неплохой скилл коммуникации» — это как-то маловато для PM.
сходила на мероприятие для женщин в IT


Представляю, чтобы началось, если бы были мероприятия для мужчин)))
Оно могло бы быть в тех областях, где мужчин явное меньшинство. Например, мужчин-домохозяев или кассиров)
UFO just landed and posted this here
Не собирался комментировать этот бред данную статейку, но решил, все же, внести ясность для россиян (поскольку дамочка подразумевает Штаты).

Начнем с фразы
I know the rate is anywhere from $190-$300 an hour.
(специально привожу из оригинала; сначала подумал, что «ляп» переводчика, ан нет).
Это неправда; нет таких рейтов ни anywhere, ни here and there. Вообще, per hour считают свою зарплату контракторы, а «фуллтаймеры», обычно, указывают salary range per year. Округленно годовой доход получается умножением rate per hour * 2. То бишь дамочка говорит, как об обычном, о зарплатах от $380 до $600K. Это вранье, нет таких «обычных» зарплат! Возможно, какие-то сверхуспешные компании в биржевом high speed computer trading-е и платят подобные рейты единицам, но не просто «сеньорам», а реальным гуру, талантам и гениям от программирования, но это, скорее, исключение (а про подобные исключения в web programming я вообще никогда не слышал). В среднем, все гораздо скромнее: опытный программист может рассчитывать на salary от $140 до $200K/y (все зависит от компании, побережья и т.п.) и на рейт от $85 до $120/h при long term контракте по 1099 или W2. Заранее говорю возможным оппонентам: мои слова ну очень легко проверяются…

Вторая фраза
A few months ago I attended an event for women in tech.
(вернее, первая фраза в статье) для знающего человека сразу подскажет, что дамочка, скорее всего, закоренелая феминистка: event for women in tech, my ass! Большая проблема США в том, что феминисткам дозволено проводить подобные мероприятия, а вот попробуй провести event for men in tech, те же феминистки моментально подадут на тебя в суд.

В-третьих: сама позиция junior developer уже давным-давно не в тренде, таких позиций практически не существует на рынке, и компании стараются избегать публиковать такие позиции по многим причинам (но не по тем, которые перечислила дамочка). Толковый студент, еще со времени учебы подрабатывавший интерном в компании (а среди толковых студентов это, скорее, правило, нежели редкость), по получению диплома придет работать software engineer-ом в эту же компанию, и без всяческих приставок типа junior.

Ну, и, наконец, за мою долгую работу в американской IT индустрии (в том числе, и «официальной» позиции senior-а), я не замечал, чтобы компании тратили время senior-ов на обучение junior-ов или кого-то еще, это просто не предусмотрено такого бизнес-планом (а уж поверьте, сеньорам есть чем заняться)! Никто никого за ручку не тянет; хочешь быть в бизнесе, зарабатывать больше, работать над интересными проектами — сам будешь учиться и «рвать когти»; не хочешь, и не будешь справляться с работой — ты кандидат на ближайший lay off (ну, или контракт не продлят).
По поводу денег — а это точно не о цене которую компания заказчикам выставляет?
Neikist, если это касательно денег, упомянутых мной, то это чистый income, без учёта налогов, получаемый опытным инженером (senior software engineer, или даже team lead). С налогами, понятное дело, получится намного меньше (в MA суммарный эффективный налог — federal+state — в прошлом году составлял что-то около 34.6%. Ну, понятно, с dependentam-и (как правильно по-русски будет не работающий член семьи, иждивенец?) будет чуток поменьше, но ненамного.

То, что упомянуто в статье — полный bullshit, ерунда! Нет платят таких денег.

Если же вы имеете ввиду консалтинговые компании, через которые вы работаете (если работаете. Ведь контракт можно иногда и напрямую заключить!), то они дают исполнителю (на найденный ими контракт) от 70 до 80% от реального рейта, то бишь, если заказчик готов платить $100/h, «бадишоп» (так в некоторых узких кругах русских программистов в Штатах называются консалтинговые конторы) будет платить вам $70-80/h, в зависимости от жадности/наглости. Понятное дело, это я говорю про «цивильные» американские конторы, а не про индусские или китайские (там, по слухам, «кошмар-кошмар» творится, но я слухи пересказывать не люблю).
На счёт $300 в среднем в час синьйору не враньё. Если учесть всякого рода компенсации и не только зарплатные, то может и больше получится. Учтите такой расклад:
0. Базовая зп 150-300к в год. Только не говорите что нету 300к, в моём кругу общения таких людей несколько.
1. Компенсация за мед страховку
2. Контрибуции на HSA
3. Матчинг на 401к до 1 к 1 на 100%
4. Стоки компании которые могут превышать 4 годовых дохода (вэстятся на протяжении 3-4 лет).
5. Бонусы которые составляют от 10 до 25% от базового оклада

Ведь 300 в час на на 8 часов и 200 дней рабочих в году всего получается 480 тысяч.

В общем как-то так. Если всё считать получается куда больше чем 300 в час в долине.
Матчинг на 401к до 1 к 1 на 100%


The total contribution limit for 401(a) defined contribution plans under section 415©(1)(A) increased from $54,000 to $55,000 for 2018. This includes both employer and employee contributions.

Стоки компании которые могут превышать 4 годовых дохода (вэстятся на протяжении 3-4 лет).


Это контрактору-то?
Если зарываться в подробности, то максимум 55 тысяч на 401к, но обычно просто 1 к одному, т.е. 36 тысяч.

Контракторам стоки не даются, речь о фултаймерах конечно же.
Базовая зп 150-300к в год.
Уже после этой фразы можно было-бы не отвечать вам, ибо находится на уровне этой статейки. Т.е. для вас 150-300K — это одно и то же? :D А вы точно про USD говорите, или про рубли?
Давайте так: я вам приведу две первые ссылки из гугла по уровню зарплат сеньоров в Бостоне (для Техаса будет даже пониже, я думаю), а вы в ответ мне пару ссылок на позиции с salary от $380K до $600K / year (ну, или контракты с рейтами $190-300/h, о которых писала глупая феминистка). Или даже больше, урежу вам осетра: хоть одну позицию на «базовую зарплату» (LOL!) в $300K/y для senior software engineer in web development!
Вот мои ссылки: первая и вторая (не хочу обременять читателей остальными ссылками, их очень легко получить, кликнув тут).

Для тех, кто не в теме, сообщу, что все остальные ваши «подсчёты» из той же оперы, и той же степени достоверности. А что до ваших друзей в долине, «так вы им тоже рассказывайте»! © старый анекдот. Вы же из Техаса, вроде? Ну, так вам положено все преувеличивать в несколько раз :)
Я вам за долину говорю в целом где центр индустрии, а не за бостон или за техас.
150-300к это разброс зарплат для Senior Engineers. Например база в Netflix сейчас 300-500к (glassdoor врёт).
Оглашаемые позиции зарплаты не включают, про зарплаты договариваются на собеседовании. Работодатели вообще не заинтересованы, чтобы их уровни оплаты труда разглашались.

Смотреть среднее по рынку труда, занятие тоже не благодарное. Стартапы платят мало, но дают большой эквити, если выстрелит, можно уйти с кушем в несколько миллионов долларов.

Ваша фраза о «глупой феминистке» мягко говоря неуместна, уважайте людей и вас уважать будут.

Спасибо за оскорбления не только автора оригинальной статьи, но в том числе и меня.
Все понятно (и ожидаемо): ни одного подтверждения, ни одного факта. Вы сколько лет в Штатах то живёте? (если вообще живете тут, конечно)

Непонятно только одно: зачем вы всю эту ерунду пишете, про «300-500к» (вам самому не смешно?)? Чтобы показать российским читателям, не знакомым с американскими реалиями, какой вы крутой, успешный и богатый? Дык, без копии ваших paystub-ов — кто вам поверит? ;)
UFO just landed and posted this here
1. Я за свой доход не говорю. И пейстаб не покажу. Но могу показать средний палец, он вам к лицу.
2. В штатах уже 7 лет.
3. Как же жить когда мне silveruser не верить, тяжело наверное.
Ну, в присущем обычно врунам хамстве, которым они замещают доказательность и отсутствие реальных аргументов, я и не сомневался. Но вот любопытно, почему это вы сразу затерли в своем профиле Техас? ;)

Пальца я вам в ответ показывать не буду, не за рулем; могу лишь посоветовать прекращать нести bullshit, как у нас говорят. Выглядите вы глупо, вроде пресловутых «плоскоземельщиков» или «маскоотрицателей».
Что за бред вы несёте? Я локацию свою не затирал. К вашему сведению, я в Техасе недавно по причине оффера который побил калифорнийский, но вот это уже редкое исключение и в некотором смысле редкое везение.

Если как вы говорите я вам вру, как же люди в бей эрии покупают дома за 1-2 миллиона долларов и выше? Минимальная Salary на кредит в 700к это 170 тысяч в год, т.е. 340 на 1.4 миллиона или около 500 тысяч на 2 миллиона. Причём жильё продаётся дороже процентов на 20% чем афишируется цена.

И прежде чем говорить, что кто-то врёт, в начале узнайте сколько тот же фейсбук акций даёт простым инженерам и сколько не простым, в случае не простых там цифры на миллионы долларов и при высокой базе зарплаты.
Бред несёте вы, притом буквально в каждой фразе. Судя по всему, вы в штатах весьма недавно (за 7-то лет можно было куда больше всего узнать!), так что вам предстоит еще много «удивительных открытий» — и как дома покупать за миллион, и то, что миллион, и два миллиона — это, как говорят в Одессе, две большие разницы, и еще много всякого другого о реальной американской действительности.

Все, вы меня утомили; читателям «хабра» я свою мысль донес (и, думаю, любопытные сами уже убедились, кто тут прав, а кто нет), а спорить с «в инете кто-то не прав!» у меня нет ни желания, ни времени. Счастливо вам оставаться в вашем выдуманном мире 300-600 тысячных зарплат, «халявной» выдачей миллионных стоков, 100% «матчинга» salary на 401K и прочих «ништяков», живущих в вашем воображении. Правда, боюсь, что после первого же lay off и очередного кризиса в индустрии ваши воздушные замки рухнут, но «проблемы индейцев шерифа не волнуют».
Вы наверное туповатый немного, Salary 150-300 в основном, всё остальное стоки и прочие плюшки догоняют. Я про это писал в самом начале. Базовая ЗП выше это исключение в виде Netflix.

Ну и в общем-то, мне то что? Живите в своём мире низких доходов, не умеете себя продавать значит.
Зря вы не верите. В Долине действительно такие зарплаты — не редкость. Сходите сами за офером в какой-нибудь Фейсбук, например.
Вам лично офер, на позицию senior software engineer с рейтом $190-300/h делали (или на salary $380-600K)? Какой-нибудь Фейсбук, например? :D

Или опять: «мне лично не делали, но такого народа очень много»? Нет таких инженерных зарплат в BA.
Сколько вам ещё раз повторить, что base в пределах 150-300к, а всё остальное в плюшках, в основном в стоках? Salary — это минимальный пэймент, и стоки и прочее в него не в ходят. Вы сколько лет в штатах? Вы вообще знаете как тут жизнь устроена? Похоже вы тут месяц и не ориентируетесь в реалиях и вариантах оплаты труда.
Не знаю, сколько платит Netflix, но их конкурент HBO платит что-то около 120-150 тыс.
Район ЗП непосредственно от их инженеров, я в начале думал 250-300. Но как оказалось, это в прошлом по причине того, что они не дают стоков и в общем-то компанейские плюшки слабоваты, поэтому приходится нагонять в базовой ЗП.
Смотреть среднее по рынку труда, занятие тоже не благодарное. Стартапы платят мало, но дают большой эквити, если выстрелит, можно уйти с кушем в несколько миллионов долларов.

Это настолько большое исключение этот выстрел… что можно его не считать.
О да, с этим спорить бессмысленно если брать всю картинку скопом. Процент успешных ничтожен, но и стартапы выбирать нужно с умом, хвататься за первый попавшийся глупо. И в принципе просто трезво взглянуть на стартап сразу становится ясно есть у него будущее для абсолютного большинства.

Тем не менее из моих близких знакомых, кто работает/
работал в стартапах, и у кого выстрелило процент не малый(относительно) это: Pure Storage, Mykonos(был выкуплен), Plum(девайс по разливу вина, в процессе активного прогресса в развитии), Vision-что-то(выкуплен майкрософтом подразделением XBox, распознавалка телевизионного контента), Sourcefire выкуплен Cisco и сейчас вроде как превратился в Cisco Talos group, Cyphort выкуплен Juniper Networks. Правда с Mykonos и Plum отдельная история, их создал и развил один и тот же человек, Дэвид Корец, который мне также помог получить представление о индустрии в целом с точки зрения инвестора.
И в принципе просто трезво взглянуть на стартап сразу становится ясно есть у него будущее для абсолютного большинства.


Если стартап — верняк, то это видят не только работники потенциально, но и инвесторы. Так что не факт что в верняке работнику вообще долю предложат, а не зарплату обычную.
А смысл тогда идти работать на такой стартап если долю не предложат? На стартапах без доли в стартапе и без сток-опшенов денег не заработаешь, в обычной рутине у них ни бонусов, ничего, сплошные овертаймы, 401к не всегда и без матчингов, мед страховка часто просто отстой, как и зубная страховка в общем-то. Если кто-то идёт работать на стартап без эквити — это от отчаяния найти какую либо работу вообще, что в общем-то говорит о уровне специалиста.
Я только что осознал, что кто-то получает за день мою месячную зарплату и пошёл пить водку, играть на балалайке и грустить с медведем.
Это неправда; нет таких рейтов ни anywhere, ни here and there. Вообще, per hour считают свою зарплату контракторы, а «фуллтаймеры», обычно, указывают salary range per year. Округленно годовой доход получается умножением rate per hour * 2. То бишь дамочка говорит, как об обычном, о зарплатах от $380 до $600K.


Так там же написано, что при таких суммах в час практически никто и не работает полный день. Поэтому о никаких 380-600 К она и не подразумевает.
Интересно, а как вы себе представляете работу senior software engineer в американской компании, который «практически не работает полный день»?! Т.е. я, например, говорю PM-у, который наметил митинг на 9 часов утра, и CTO, который хочет меня видеть в 4 часа: «Мне компания платит такую сумму в час, что я просто не могу себе позволить ее разорять и работать 8 часов, так, что, друзья, уж выбирайте, кому я нужнее, но работать я сегодня буду только 4 часа».

Ну, господа комментаторы, включайте хотя-бы элементарную логику, даже если не имеете ни малейшего представления о теме (хотя лучше, конечно, просто промолчать)!
Интересно, а как вы себе представляете работу senior software engineer в американской компании, который «практически не работает полный день»?!


Мне не нужно представлять.
Я работаю с таким людьми.

Руководство сообщает — с стольки то по стольки то к нам придет мега-специалист (в Слэк), придет он ненадолго. Приготовьтесь задать вопросы, попросить его что-то сделать, что-то посмотреть. И т.д.
Во-первых, то, что «мега-специалист» проведёт у вас несколько часов, вовсе не означает, что это все его рабочие часы :) Во-вторых, попытайтесь все-таки перечитать, о чём идет речь (я понимаю, что это очень трудно, и куда проще слушать только самого себя, но все-таки попытайтесь!). Ладно, я напомню: в посте, обсуждаемом тут, идет речь о
I know the rate is anywhere from $190-$300 an hour.
(речь идет о senior software engineer).

Я не говорю о том, что такие рейты в принципе невозможны: достаточно сходить к доктору, а потом посмотреть, на какую сумму он чаржил страховку, либо обратиться к адвокату, чтобы убедиться, что некоторая часть Америки таки живет в «развитом коммунизме капитализме» (это «шутка юмора» — говорю сразу, чтобы вы не набросились с опровержениями :) ), но для позиции senior software engineer такой рейт не то, что встречается «anywhere», а просто не встречается практически нигде, не существует таких зарплат по факту. Считать же возможность льготной покупки стоков, как некоторые простаки делают, просто глупо: во-первых, это далеко не зарплата (выигрыш в лотерее мы же не считаем за зарплату?), а во-вторых, можно как заработать, так и потерять (ну, либо остаться при своих).

Самая высокая salary, про которую я слышал (но не люблю распространять слухи, поскольку подтверждений никаких, «ОБС», как говорится), была не в долине, а в NYC, в компании, специализирующейся на скоростном реалтаймовом трейдинге, шла речь о порядка $500K/y (плюс вероятный бонус 50% от annual salary). Но там нужен был не «сеньор» по web apps, а гуру, гений с многолетним опытом работы в трейдинге/биржевых операциях. Ну, и, к слову, позиция называлась что-то вроде «chief architect», с непосредственным подчинением CTO.
Если копнуть глубже, там всё сложнее и дороже у фултаймеров. Допустим совокупные выплаты составляют 300 тысяч(зарплата, бонусы, стоки, страховки, 401к матчи), но туда ещё входит налог который контора платит с этих 300к помимо того, что ещё сотрудник платит, а это дополнительных добрых 15% набегает, а там ещё и отпуска, и больничные и парентал ливы — это вообще финансовый кошмар.

А если ещё посчитать сколько стоит нанять сотрудника в целом… ой-йо… около 50ти тысяч расходов с лёту в среднем, не считая потерь на времени которое сотрудник будет тратить на онбоардинг и втягивание в проект.
Не надо быть никакой закоренелой феминисткой, чтобы ходить на такие эвенты. Просто это помогает с поиском работы.

Нынче такие мероприятия часто проводятся. Доля женщин в индустрии — около 16-17%, если мне не изменяет память. Пытаются сделать профессию более привлекательной для женского пола.
Кто "пытается"? Капиталистическая Партия Соединенных Штатов? Мировое Правительство массонов? Закулиса рептиллоидов?

Индустрии не нужны «женщины» там или «мужчины», или «афроамериканцы». Индустрии нужны специалисты, а уж кто этот специалист по полу или цвету кожи — не имеет значения (даже по федеральному закону, должны висеть плакатики в каждом офисе, присмотритесь внимательно).

Я не часто хожу на болтологические event-ы (скажем так, вообще практически не хожу), но спам с рекламой подобных приходит. Никогда не видел еще «гендерной» или «расовой» селекции! Ссылочку на сайт подобного event-а не приведёте (ну, если «часто проводятся», вам не должно составить труда найти), любопытно взглянуть, кто именно проводит подобные мероприятия, если не феминистки (кому такие фокусы сходят с рук).
UFO just landed and posted this here
Многие люди(не все, есть и хорошие примеры) которые считали себя Senior инженерами дома, в долине и до middle не дотягивают — это грустная правда, на родине редко есть с кем себя сравнить, кто действительно стоящий, вот и имеем, что имеем.
UFO just landed and posted this here
я в основном собственными усилиями

мне сказали, что я даже до middle-уровня не дотягиваю


Отсутствие навыков работы в команде.
Отсутствие знаний инструментов организации командной работы.

Интернет-магазин федерального масштаба с непростыми бизнес-требованиями к функционалу

Интернет-магазин даже большой и сложный (если только у вас там нет ИИ рекомендующего покупателю товар), — вполне себе рядовая задача. Да, она может занять много времени.

Что конкретно «непростого в требованиях» там было.
Реально интересно.
Многие интернет-магазины работают медленно, и нагружают клиентские устройства под 100% CPU. А еще спамят запросами к БД.
Сделать магазин, который не будет падать под нагрузкой и с большим количеством товаров надо суметь.
Сделать магазин на 3 товара и 1 покупателя в сутки может и студент, причем не особо и умный.
Сделать магазин, который не будет
падать под нагрузкой и с большим количеством товаров надо суметь.


Количество товара влияет на нагрузку слабо — типовой покупатель не перелистывает все ваши 100 000 товарных предложений. Он и сотню вряд ли пролистает.

Задачу сделать быстрый интернет-магазин я лично ставил пре-джуну (тот что «войти-в-айти»), только-только окончившему кулинарный техникум по специализации информационные технологии. Все очень просто — при обновлении каталога товара или цен нужно перегенерировать html-странички с товаром. Нужно ли говорить, что интернет-магазин, написанный пре-джуном на статике — летал? Динамическая часть (корзина) — естественная была реализована не на статике. Её в это время другой джун прекрасно сделал, попутно изучая новый для себя язык программирования.

Ну да, джун и пре-джуны это делали под присмотром. Тем не менее не вижу проблем специалисту уровня между джуном и миддлом сварганить нечто подобное и быстрое.

Почему-то разработчики OpenCart не справились с такой простой задачей и я наблюдал сотни запросов к БД, когда на сайт заходит единственный человек (потому что они рекурсивно разворачивают всю иерархию товаров). Чем больше у нас производителей, линеек, коллекций, тем медленнее это все ворочается.
И, кстати говоря, они не одни такие альтернативно-одаренные)
Почему-то разработчики OpenCart не справились с такой простой задачей


Универсальная система наааааааамного сложнее и медленее системы узкоспециализрованной. Или сложнее конфигурируемо. Короче, «выберите два из трех». Узкоспециализированную систему подобного уровня, которая будет летать, вполне должен быть способен реализовать программист средней руки. Иначе он не программист.

Другое дело, что с точки зрения это не всегда выгодно. Экономически выгоднее зачастую использовать уже существующее универсальное решение, слегка подтачивая его под конкретную задачу.

Да и это не то же самое что разработать своими силами магазин с нуля. Навключать модулей в OpenCart или Magento или каких плагинов для Wordpress — для этого не нужна квалификация программиста даже.

UFO just landed and posted this here
как получить этот опыт, если при его отсутствии вероятность оказаться в команде весьма невелика.


Джуна возьмут и так. И научат. За соответствующую маленькую зарплату.
Вы, видимо, претендовали сразу на зарплату миддла — тут другие ожидания от вас.
UFO just landed and posted this here
Всё начиналось и заканчивалось на уровне разговоров, но, как правило, не о заработной плате.)


А человека с большим списком работ чтобы взяли на зарплату джуна — ему нужно самому в явном виде высказать свое желание.

Логика работодателя тут проста: у него опыта много, денег хочет мало, видимо рассматривает наше предложение как временное и запросто может срулить хоть через неделю как начнет работать как только найдет место с соответствующей зарплатой.
UFO just landed and posted this here
Несколько месяцев назад я сходила на мероприятие для женщин в IT.


так, я не понял, а на кухне все дела сделаны что ли?
Что-то я вообще не понял, о какой такой смерти джуниора в статье идет речь. Вся Долина в Штатах держится на свежих выпускниках. Куча всяких стартапов в Сан-Франциско — работы для джуниоров вагон и маленькая тележка. Или речь идет о людях, которые вообще программировать не умеют никак? Тогда неудивительно, желающих «войти в айти» сейчас предостаточно.
Мне 29 лет. Учиться программировать я начал чуть более полугода назад. Выбрал направление web-разработки. Вакансий на junior-позиции хватает более чем. Все упирается в уровень подготовки и возможности работать практически бесплатно в начале этого прекрасного пути. Мне кажется, что лучше времени начать карьеру в этой индустрии не было и не будет. А если ты студент и готов самостоятельно изучать программирование, то вариантов не найти работу просто не существует.
Вы правы. «в уровень подготовки и возможности работать практически бесплатно». Но есть два нюанса: первый, это именно работа (а не пет-проекты), потому что пет проекты, может и оценят, но всех интересовало кем и где ты работал (пусть даже за еду), ну и да, все хотят наиболее подготовленных кандидатов. С этим могут быть сложности — каждая компания имеет свое представление о «подготовленном кандидате». Это могут быть настолько разные вещи, что иногда кажется приятным бонусом, где прямо пишут, что будут спрашивать на собеседовании. Где-то будут гонять по фреймворкам, где-то по стандартным библиотекам, где-то по сортировкам, где-то по деревьям, где-то по CI/CD, где-то по чтению из файла (и записью в файл)… Где-то это может быть мультимедия.
Еще хочу добавить. В России найти хорошую работу (достойна оплата труда и интересные задачи), например, инженером-строителем гораздо сложнее, чем каким-либо программистом. А на свои стабильные 60-80 тысяч рублей вы сможете рассчитывать через лет пять в лучшем случае. А до + 100 тысяч доходят далеко не все, хотя люди не глупые и трудятся много. И это если говорить о Москве. В городах за ее пределами ситуация еще хуже.
В старые добрые времена перед джуниором стоял выбор между Си и Паскалем, а сейчас черт его знает что. 80% времени уходит на то, чтобы добраться до кодинга.
старые добрые времена перед джуниором стоял выбор между Си и Паскалем, а сейчас черт его знает что. 80% времени уходит на то, чтобы добраться до кодинга.


Сейчас JS один из однозначных выборов.
А раньше — еще много чего было, вы забыли просто. Скажем, языки семейства xBase

Кроме того, вы преувеличивайте значение знания конкретного языка.

Язык программирования — это базовый инструмент. Вы владеете им ну примерно так же как и быстрым набором на клавиатуре. Трудно выучить только первый.
Не знаю, как там в штатах, но в России в default city ситуация простоя — есть много людей, которые вообще не написали ни строчки кода, но хотят устроиться джуниором за, условно, 100к/мес. При этом обучение такого «джуниора» — это, считай, наполнять чистый лист знаниями в течении нескольких лет. А результат не факт, что приведет к положительному эффекту.

Дело в том, что сейчас программирование — это хайп. Родители отдают своих детей «учиться программировать», не разбираясь, нравится это им или нет, есть ли у них талан и предрасположенность. В итоге получаем армию как бы выученных на разработку ПО людей, но по факту — притянутых за уши. Им это не интересно, они этим не особо хотят заниматься, но понимают, что за это платят деньги, поэтому что-то делать надо.

В итоге, когда приходят на собеседования студенты или совсем свежие выпускники, довольно быстро можно понять, стоит ли вообще тратить время на такого джуниора. Вот общаешься и понимаешь, что просто самый-самый потолок для этого человека, есть он будет что-то делать — middle. Он выучит это, это и вот это, но если шаг в сторону — «это не в моей компетенции, это я не знаю как, это я делать не буду». Я знаю, о чем говорю, такого много. Ну и зачастую нет смысла тратить время на такого джуна, если сколько-либо серьезных задач в будущем он все равно зарешать не сможет.

По моей статистике, только 1 из 10 джунов достойны внимания. То есть таких джунов, которым надо просто дорогу показывать, а дальше они сами все откопают, спросят, напишут. Они быстро станут мидлами, а потом, если их будет дальше переть, и сеньорами. Остальных надо тянуть за уши и вытирать за ними сопли без каких-либо перспектив получить качественный кадр.

на удаленую работу из маленьго города вообще не реально залесть для junior, у меня опыт 1.5 года на yii2 и то уже 2 месяц ищу работу на hh.ru, всем нужешь middle full-stack со знанием настройки сервера
Смотрю, тут одни фапальщики расплакались о том, что трава раньше была зеленее :-DDD
Согласен с oYASo и еще хочу добавить, что программирование — это бизнес, а не благотворительность. И адекватный владелец или руководитель за свои деньги никого непонятно зачем и непонятно на кой учить не будет. Основная масса начинающих это понять не хочет, а хочет учиться и набираться опыта за чужие деньги. В этом вся проблема. Хочешь учиться — плати. Готов работать — работай и зарабатывай. Если в ВУЗе ничему не научили, то это вина не работодателя, а ВУЗа и того кто там учился.
Может, и готовы учиться, если бы была полноценная система переподготовки кадров, а не какие-то непонятные курсы, на которых дают минимум необходимых знаний и за редким исключением вместо обучения на них занимаются профанацией бурной деятельности, повторяя школьный курс информатики. В советские времена можно было получить новую специальность через второе высшее образование, а в наши дни ни о чём подобном для программистов я не слышал.
Если я в чём-то неправ, прошу аргументировать.
С другой стороны, крупные компании всё-таки обучают специалистов и предпочтение отдают студентам и выпускникам вузов, игнорируя соискателей в возрасте, причём у обеих категорий опыт отсутствует. Вот почему одних можно учить «за чужие деньги», а других нет?
Какие вы можете привести причины взять «соискателя в возрасте» без опыта, но зато с условной женой, детьми и ипотекой? Как думаете, какова вероятность, что он будет учиться быстрее и его запросы будут умеренней, чем у вчерашнего выпускника ВУЗа?
Как раз мотивация учиться у человека с женой, детьми и ипотекой выше, поскольку, в отличие от необременённого обязательствами выпускника ВУЗа, необходимо заработать средства на содержание семьи, для чего нужно проявить максимум упорства, чтобы понравиться рабтодателю. Ну а запросы диктует рынок.
Молодой, если адекватный, согласится на более низкую оплату ради опыта. Человек постарше, как правило, обременен некоторыми обязательствами, и на зарплату ниже определенной отметки пойти просто не в состоянии. Плюс, он уже имеет опыт трудовых отношений и понимает, что к месту не приклеен, если что не понравилось. Вчерашнему выпускнику это придет в голову позже, вкупе с тем, что пока ему не с чем сравнивать и некоторые минусы своей работы он может пока не воспринимать как недостатки.
Да, и некоторые конторы буквально живут за счет студентов.
3 месяца бесплатная стажировка, 3 месяца ИС с копейками ЗП, 6 месяцев на смешной ЗП, и год спустя(!), если вести отсчет от первого дня в фирме, можно претендовать на рыночную зарплату junior'a. Передо мной несколько таких фирм, и очередь студентов туда никогда не оскудевает. Еще и конкурс есть — не всякого возьмут даже на таких условиях.
В такую студентовыжималку взрослому человеку смысла идти нет.
Работал в похожей, хотя там не было не совсем так. Была система зп+квартальная премия. Премия начислялась только начиная с квартала, следующего за испытательным сроком (если ИС кончился в самом начале квартала — пролетаешь на 3 месяца). То есть, при самой неудачной дате трудоустройства первую премию получишь через ~10-11 месяцев. С учетом большой текучки и факта, что большинство уходящих делают это в первый год, экономили они неплохо.
Ну и галеры, куда же без них. Переработки считались абсолютной нормой, причем часовые не компенсировались никак, только выходные. Отказ от переработок ничем хорошим не светил, понятное дело.
Да, и некоторые конторы буквально живут за счет студентов.


ИТ-шники — не могут быть полезными с первого дня.

Вот не надо — «живут за счет студентов». Как бы не наоборот.

1) Из этого времени три месяца студенты только гадят в код, за ними не успеваешь подчищать. Еще месяца 3 — студент работает хорошо если в 0. То есть никакой прибыли (а именно прибыль и является целью найма персонала). И только через полгода только начинается от него реальная польза, где уже есть сливки, которые можно снимать с зарплаты и класть в карман владельца.

2) Открою вам секрет: предприятия вообще затем и существуют, чтобы работники создавали т.н. «добавленную стоимость», а владельцы предприятий употребляли эту стоимость туда, куда сочтут нужны. Вообще все предприятия.

Даже опытнейший сеньор первые несколько дней (практика показывает, что нужно 2 недели, чтобы начать эффективно работать) — только вникает.
Из этого времени три месяца студенты только гадят в код

В программировании да. С архитекторами/аналитиками такое тем более не пройдет. Если это крупная контора, то есть такие подходящие для большой текучки подразделения, как тестирование и внедрение. На них и получается сэкономить, вполне себе жизнеспособная бизнес-модель.
С архитекторами/аналитиками такое тем более не пройдет.


Можно пояснить мысль, что такое джун-архитектор?

Насчет джуна-аналитика — сталкивался, написать кучу мутных умных слов в мегатолстый талмуд, оказывается, большого ума не надо. Доводилось читать такие талмуды.

А вот джун-архитектор — это как?

Дело в том, что на огромную толпу разработчиков достаточно одного-единственного архитектора. И нет никаких причин брать на эту должность именно джуна. Уж одного-единственного сеньора найти — в чем проблема-то?

Имею в виду, что этими людьми, как правило, дорожат. И сменить их быстро и безболезненно не всегда можно, даже если берешь опытного человека, в отличие от какого-нибудь тестировщика. Понятное дело, что архитектором вчерашнего студента никто не поставит.
Насчет джуна-аналитика — сталкивался, написать кучу мутных умных слов в мегатолстый талмуд, оказывается, большого ума не надо. Доводилось читать такие талмуды.

Если постановки для разработчиков пишет такой аналитик, то есть сомнения в его необходимости. Ошибка аналитика обходится дорого.
Если постановки для разработчиков пишет такой аналитик, то есть сомнения в его необходимости. Ошибка аналитика обходится дорого.


Да нет. В моем случае это позволило поднять цену клиенту:
«Видите какое толстое описание задачи, значит и моя работа будет стоить дорого».

Сама постановка задачи, написанная аналитиком, была перелистана по диагонали, для оценки стоимости работ этого достаточно.
Уважаемые господа минусующие! Задумайтесь над тем, что будет с вами по достижении определённого возрастного порога с устареванием квалификации.
Уважаемые господа минусующие! Задумайтесь над тем, что будет с вами по достижении определённого возрастного порога с устареванием квалификации.


Первую программу написал в 1988 году.
Начал работать программистом в конце 20 века.

Ничего не устарело еще…
Вон, ковыряю Kubernetes…

Вы как то странно смотрите на мир.
Что мол то что изучено давно — только этим и ограничивается квалификация программиста.

Основные принципы все так же не меняются, да. И потому ваше древнее знание вполне актуально и полезно сейчас.
А конкретные библиотеки, фреймворки, языки — какие тут проблемы? Справочники же есть, интернет. Нужно только понимать по каким ключевым словам смотреть. Имхо, тут начинающие программисты от опытных ничем не отличаются — в интернете по своей работе ищут все.
Согласен, но вполне можно попасть в ситуацию, когда для потенциального работодателя по уровню квалификации окажешься джуном, т.к., большинству нужны готовые сотрудники
Согласен, но вполне можно попасть в ситуацию, когда для потенциального работодателя по уровню квалификации окажешься джуном, т.к., большинству нужны готовые сотрудники


Тут я вообще не понял.

Если вы специалист в какой то узкой специализации и кроме нее вас ничего не интересует и вы ничего не знаете — то какой смысл рассматривать работодателей из других профессиональный специализаций.

Напротив, в этой специализации — вас с годами будут ценить все больше и больше.

Если же вы хотите сменить специализацию — то нужно было бы подготовиться заранее. Поскольку базу вы уже знаете, то изучить новый язык, к пример… тьфу, а не задача.

В какой-то одной фирме может произойти резкий скачок, быстрое изменение технологий на те, что вам совершенно не знакомы. Но в целом по рынку труда — подобные изменения происходят медленно, у вас есть время для переквалификации.

Например, 1С 7.7 выпущенная еще в прошлом веке — до сих пор встречается нередко.

Сайтов, писанных на (не помню какой, но знаю, что она обратно несовместима из-за большого числа уже состоявшихся deprecated) древней версии PHP тоже полно. Эта версия уже выкинута из пакетов всех современных дистрибутивов.

До сих пор активно и широко используется еще Python 2, хотя уже много очень лет усиленно продвигается не обратно совместимый Python 3.

До сих пор используется Cobol, который был устаревшим еще когда я начал изучать программирование 30 лет тому назад.

Человечеством написано очень много кода. Этот код никто не жадет переписывать, если он нормально функционирует. Это же деньги, время. А в результате получим те же яйца, только вид в профиль.

То есть всегда можно будет найти работу и со древними знаниями, если уж вам так не хочется изучать новинки.

Если же вы хотите сменить специализацию — то нужно было бы подготовиться заранее. Поскольку базу вы уже знаете, то изучить новый язык, к пример… тьфу, а не задача.

В какой-то одной фирме может произойти резкий скачок, быстрое изменение технологий на те, что вам совершенно не знакомы. Но в целом по рынку труда — подобные изменения происходят медленно, у вас есть время для переквалификации.


Справедливо. Речь о сложностях трудоустройства для переквалификацирующегося специалиста.

Что касается медленности изменений в отрасли, то давайте вспомним, что в начале нулевых не было сложных технических собеседований с вопросами по теоретической информатике. И тенденций к понижению требований не наблюдается.

М — мотивация)
У студента живущего с родителями мотивация может быть гораздо ниже (хватило бы на платеж за новый смартфон и ладно).

Или гораздо выше (съехать бы от них поскорее).

Или сверх-высокая:
— жить в автономке
— платить за ипотеку
— «содержать» (помогать финансово) будущей супруге
Лично я работал тогда на двух работах сразу… брррррр.
Молодого человека проще «переделать» под свои нужды, привить полезные привычки. Со взрослым такое получается реже. Молодые люди привыкли учить большие объемы информации. Если сравнивать, то в 30 лет и в 18 лет работа мозга, интенсивность, заметно отличается (обычно).
С другой стороны — у взрослых людей есть ответственность, семья, они не увольняются (обычно) СМС-кой «мне надоело, на работу больше не пойду», они умеют жить в рабочем коллективе (подчиняться, работать в команде).
Но выгода в скорости обучения перевешивает недостатки.
Плюс студенты профильные (хоть профильное образование может и храмать на обе ноги), а кандидаты в возрасте это либо самоучки и там нужно проводить комплексную оценку знаний, чтобы дать недостающее, либо «войти в айти», что принципиально мало отличается от предыдущего, но может отличаться целями.
Здесь следует разграничить возрастных кандидатов, которые не имеют профильного образования, и специалистов с опытом в других областях, которые переходят в более перспективное направление, привыкли усваивать большие объёмы информации и, соответственно, обучаться.
Взять свежего выпускника проще, чем найти человека «в возрасте», который:
  1. имеет околопрофильное образование
  2. готов работать на позиции начинающего с соответствующей оплатой труда
  3. способен обучаться на уровне
Значит в 30 лет программистом не стать? Поезд ушел? Или один случай на миллион?
Значит в 30 лет программистом не стать? Поезд ушел? Или один случай на миллион?


Почему?
До миддла — 100% можно дорости.
До сеньора — при таланте и большом желании, то есть далеко не каждому светит. Но отдельным людям вполне достижимо.
У меня вопрос, если можно. Он может показаться странным, но очень он меня стал мучить. Изучение программирования я начала c Python. Прочитал пару книг, решал различные задачи, а параллельно осваивал JS, HTML, CSS. Голова гудела, но дело вроде бы и шло. Дальнейшее развитие видел в Django. Даже решил поступать на заочное отделение для отсутствия барьеров в развитии в будущем. Но оказалось, что в моем регионе Python мало кому нужен. А junior-разработчики особо не нужны даже в Москве (я говорю про web-разработку). Но при этом меня готовы были взять со знаниями PHP, если бы они были. В нескольких местах договорился встретиться вновь после освоения PHP, выполнить тестовое задание и попробовать себя на испытательном сроке. Вот уже неделю сижу за PHP, но как же он мне не нравится. Если до этого программировать было всегда в удовольствие хоть до пяти утра, то сейчас через силу. Хочется вернуться к Python, освоить Django, но такое ощущение, что тридцатилетний начинающий Python/Django разработчик никому не нужен наверняка. А с PHP и его коробочными решениями работы вагон, тележка и еще вагон, поэтому с ним начать карьеру гораздо проще. Так ли это?
Даже решил поступать на заочное отделение для отсутствия барьеров в развитии в будущем.


Не стоит.

Голова гудела, но дело вроде бы и шло.


Это совершенно нормально. Привыкайте.
Да и потом будет легче. Третий, десятый язык — уже намного легчем. Те более что там большая часть принципов повторяется из языка в языке.

Но оказалось, что в моем регионе Python мало кому нужен.


Не показатель.
Заказчикам конечным или мелким конторкам — все равно на каком языке написано. Они вообще не ставят ограничения по языку, или, если даже и ставят, их легко переубедить.

И вообще — четыре-пять языков одновременно это норма. Это не так сложно как кажется, пока учишь первый. Первый — сложно, да. Не очень просто — второй. Потом уже легко.

Хочется вернуться к Python, освоить Django, но такое ощущение, что тридцатилетний начинающий Python/Django разработчик никому не нужен наверняка.


Самая значимая проблема для вас — то, что вам нужно бы чтобы были опытные коллеги. С ними ваш рост профессиональный будет хорошим.

В принципе вы можете быть единственным знатоком языка Python в маленькой конторке, единственным там бэкендером — я таких знаю. Вас возьмут, не будут придираться к языку — у них все равно нет стандарта на бэкенд, нет и требований. Но, к сожалению, не будет и коллег.

С другой стороны:
Выбирать для обучения лучше конторы немелкие, где есть ваши коллеги, специализирующиеся именно на том, чем занимаетесь и вы
А почему Вы не видите смысла в получении профильного (пусть и заочного) образования?
Устаревает с той же скоростью, что вы его получаете. При этом, наоболее вероятно, вы поступите на курс, который устарел лет 5-10 назад. Можно поступать на хорошее фундаментальное образование, только если точно известно что оно реально хорошее. Это сожрет уйму сил, а на ранних этапах не даст практически никакой пользы. Имеет смысл только он сениора и выше, либо если вы точно знаете что конкретно этот курс вам действительно нужен.
А почему Вы не видите смысла в получении профильного (пусть и заочного) образования?

Профильное образование – ещё далеко-далеко не гарантия того, что Вы станете действительно хорошим специалистом. Поэтому любой вменяемый работодатель нынче смотрит прежде всего на реальные навыки и реальные знания, а вовсе не на «корочки». А если смотрит иначе – это первый признак того, что от такой конторы надо держаться подальше.
И вот как раз этих самых реальных навыков и знаний – вполне возможно добиться даже без профильного образования (по крайней мере, в данной сфере). Особенно в нынешние времена интернета, со всеми его громаднейшими пластами информации.
Собственно, именно это и станет Вашим реальным образованием. То есть – тем, благодаря которому Вы сможете стать настоящим специалистом, а не просто «по распределению»…

Иначе говоря, нигде не «научат быть хорошим программистом» (как и врачом, художником, музыкантом, и т.д.). Этот талант (то есть, образ мышления) либо у человека есть, либо его просто нет. Если талант есть – учиться можно где угодно и как угодно. Если нет – не помогут даже десять профильных образований. Да, редкий случай «бинарности» в жизни… ))

P.S. Это всё потому, что любые сферы IT не являются фундаментальными науками – они в постоянном движении, постоянно обновляется информация (как верно заметил kozzztik). Тут просто по определению невозможно никакое понятие «фундаментальности», кроме разве что самых общих принципов «для чайников» – которые можно постичь уже даже в школе…
Не совсем так кстати, зависит от сферы. Например сейчас задумываюсь сменить профиль (образование экономическое, пишу на 1с, и нет, не обновления ставлю и коробки развожу, а нормальная групповая разработка, проекты на тысячи человеко-часов, интеграции, мобилки, http api и т.д.), среди интересных мне для выбора направления развития вариантов в т.ч. ИИ, машинное обучение, анализ данных, вот это все. И судя по вакансиям что я видел когда искал информацию на hh — профильное образование требуется везде. И в общем то я думаю имеет смысл как первичный фильтр, поскольку время самоучек понемногу уходит, имхо, пусть даже есть вероятность отсеять гения-самоучку, но можно вполне найти хорошего человека с вышкой (речь про начинающих, скорее всего людей имеющих нормальный опыт работы это уже вряд ли коснется, у них будут скорее этот самый опыт оценивать).
профильное образование требуется везде

Просто поверьте… Если Вы покажете им реальные знания – примут. Разумеется, при условии, что работодатель обладает достаточным здравомыслием. И что таким же здравомыслием обладают те, кто проводит собеседование.
При этом, конечно же, проводящие отбор (не говоря уж о собеседовании) – должны сами обладать достаточной степенью квалификации, не на уровне «обученных девочек из эйчара»…

Но согласен в том, что сразу в крупную контору устроиться не получится. Только со временем. В дальнейшем за Вас будет говорить уже резюме – что позволит устроиться даже в крупные конторы.

P.S. Сам двадцать лет назад получил должность инженера-программиста в гос(!!!)конторе, ещё даже с «неоконченным высшим». Всё благодаря исключительно той самой «здравости» начальника отдела – для которого реальные навыки были гораздо важнее любых «корочек». И который пробил должность – в итоге не прогадали оба. До сих пор считаю такой подход наиболее правильным. А если такого подхода нет – то и нечего там делать, ИМХО.
P.P.S. Время самоучек не прошло – в нашей сфере оно только начинается, работодатели и заказчики только-только входят во вкус… ;))
А почему Вы не видите смысла в получении профильного (пусть и заочного) образования?


Очное — да. Но оно и очное для программиста весьма умеренную пользу дает. Программисты в 99% случаев вполне достаточно образования уровня специализированного ПТУ/техникума, отнюдь не ВУЗа.
Заочное — вообще бесполезно.

хм… пачка уточняющих вопросов:


  • не нашёл — про какую локацию речь?
  • PHP какой версии смотрели?

Ну а теперь разольём мысль по древу:


  • времена хайпа питона прошли. Сейчас он более-менее активно используется в обучении, науке и изредка в вебе. При этом нужно учитывать, что распределение по локациям у него весьма неравномерно — шанс найти работу джуну в Мск минимальный, в регионах никакого, а вот в ряде локаций Европы/Америки шанс всё же был бы выше. Про науку и обучение у меня данных мало, но там похожая ситуация.
  • PHP в регионах у меня почему-то ассоциируется с "веб-мастерскими" и прочими клепателями массовых сайтов-визиток-форумов.
  • современный PHP вроде по способностям стал условно-конкурентно-способным в плане своего качества, но я сомневаюсь, что кучу старого хлама из него выпилили, но утверждать всё-таки не могу — не изучал различия с 3ей версии.
  • где у джунов хорошие шансы для начала (если говорить про регионы) — фронт (вёрстка, css, js/angular/react), php,
  • а вот для развития php в регионах уже не подойдёт — нужно выбираться в Москву/СПб

PS профессионально вырасти сейчас с питоном шансов мало — больно уж мало вакансий. Хотите развиваться? Если в регионах — почти без вариантов фронтенд. По факту получения сколько-нибудь серьёзных знаний+умений — рвать когти с переферии. В Москве/СПб ассортимент шире — хорошие шансы с Java, фронтом, php, .Net-ом. Шансы пожиже, но вполне реалистичные — c++, c, python, kotlin. С другими языками — вопрос ещё сложнее, хотя шансы всё-же сохраняются.
PPS ситуацией по Новосибу и паре других относительно крупных хабов разработки не владею, поэтому про них просто молчу.


PPPS да ещё нюанс — поступать на заочку (на самом деле) смысл есть. Но смысл заключается исключительно в виде получения бумажки (если захотите рвануть за пределы страны — must have, в пределах страны — некоторое упрощение и облегчение ситуации). Вероятность получения адекватных и актуальных знаний отчаянно стремится к нулю.

Переезжать в Москву для меня вопрос положительно решенный. Просто планировал получить опыт до Москвы. Касаемо PHP и Python. Достаточно много сил было вложено именно в Python. И теперь не пропадает ощущения, что занимался ерундой. Мне гораздо проще сейчас подтянуть Django, чем с ноля осваивать PHP c актуальным фреймворком. Неужели ситуация с Python такая печальная? Если без воды, то Python стоит отложить и взяться за PHP? Тем более осваиваю его в разы быстрее, чем даже JS. Буду безмерно признателен за ответы, данными представителями отрасли.

Не питонист, могу искренне заблуждаться. С точки зрения энтерпрайзных систем ориентированных на веб (речь о бекэнде в пределах РФ!) выглядит следующим образом:


  • есть массовый веб (в основном это php, на хайпе можно попытаться пролезть с node.js)
  • есть всякий энтерпрайз (тут правит бал java и .net)
  • есть различные плохо вписывающиеся и в ту и в другую категорию проекты — тут можно повстречать любую зверушку, но и проектов таких мало, а значит и джуны там не особо нужны

PS питон — не зря, питон вас познакомил с программированием. Но вот стартовать на нём будет тяжело, так что рекомендую что-нибудь более массовое.

Последний вопрос. Параллельно я пытаюсь верстать, в том числе, адаптивно с различными эффектами с помощью CSS, так же активно изучаю нативный JS. Стоит ли верстке и JS уделять внимание или лучше упереться в одно направление backend? И насколько критично избегать linux? Избегаю по причине отсутствия как таковой необходимости на данном этапе обучения.

Ну это вы уж сами определитесь — что вам интереснее бэк или фронт. Ну а определившись с интересом и окунайтесь в соответствующий стек.


Если говорить про фронт, то один лишь vanilla-js там мало кому интересен. Сейчас это уже полноценный стек: низовой уровень — js(или линтируемый язык) + поставщик абстракций — фреймворк (в топе — React и Angular). К ним добавляется и вёрстка — html+css (хотя бы по минимуму — в части команд вёрсткой занимается отдельный человек, но чаще всё же идёт совмещение). И поверх это всё полируется системами сборки — npm, grunt/webpack/..., и различными фиче-поставщиками: less/sass/stylus — иерархическая разработка css, модульная сборка js (из-коробки в сборщиках), различные uglifiers (сжимают js файл до минимума удаляя лишние данные и переименовывая переменные/функции максимально коротко), прочие фичи (мапы и иные инструменты для возможности дебага в браузере и многое другое).


Теперь бекэнд: в каждом языке есть как минимум один стек, в некоторых их даже много. Текущее состояние php/python/ruby/.net не скажу. В Java пара основных системообразующих фреймворка — Spring и Play. В спринге есть ризличные библиотеки и биндинги практически на все случаи жизни, в плее как минимум толковый фреймворк и работа с базой, сильно в него не углублялся — поэтому не скажу что там есть ещё или чего не хватает.


Linux… а как его можно избежать, если >80% прод-систем крутятся на тех самых линуксах?
Так что как минимум вам нужно знать:


  • как там выглядит консолька,
  • как подключиться по ssh,
  • как найти нужную команду, если забыли (гугл в помощь)
  • базовые команды (cd, ps ax, rm, mkdir, cat, grep, ls, mc, vi/vim/nano/...)
Спасибо за потраченное время. Весьма полезно.
С требованиями странная история. Пишут, что нужен backend-разработчик, а на тестовом задании необходимо адаптивно сверстать страничку, сделать слайдеры, реализовать Drag'n'Drop, 2d canvas и в обязательном порядке AJAX. Если претендуешь на front, то ситуация может быть обратной. В любом случае я уверен, что если мой первый язык был PHP, то я бы уже работал начинающим программистом. С другой стороны учить PHP без базовых знаний программирования мне кажется не самым простым занятием, но могу и ошибаться.
«Фуллстек-разработчик» — вы должны уметь работать за троих, а получать будете на треть больше. Почему? Вы же профессионал!
Обычно работать за троих, а получать в лучшем случае столько же )
Свои пять копеек (для Crocodilovich может быть полезным):
Ушел в программисты с поваров (да, все верно, то место, где жарят/варят/рубят/шинкуют) сверх-спонтанно: надо было CSS стилей написать немного… очень быстро это вылилось в знакомство с TB (Twitter Bootstrap) еще ранней альфы v2. Это меня в свою очередь познакомило с продуманной компоновкой js|css|img|fonts и вообще, «правильной» архитектурой «для самых маленьких».
Еще через 3 месяца уже шло освоение PHP.
Дальше был Oracle DB — ушел работать в универ, откуда меня же отчислили до этого.
Еще через 6 месяцев меня взяли в аутсорс-фирму. Где еще через 1 месяц уже щупал Java EE.
На сегодня по языкам (5 лет в Enterprise):
— Java v.8
— PHP v.7
— ECMAScript 6
Ну и кучи фреймворков есс-но.

P.S. Томск — сюда зашло много серьезных игроков: от «центробанка РФ», до «парней, что на Samsung».

Именно Java EE? Или всё-таки SE лишь с некоторыми фичами EE (самая распространённая — сервлеты). Вот прям начинающему разбираться со всеми этими серверами приложений, очередями сообщений и прочими энтерпрайзными радостями тяжковато разбираться будет...


И да — лучше писать или Java 8 или Java v1.8


Crocodilovich по поводу неразберихи с вакансиями — это встречается даже в крупных хабах. Проблема в том, что кадровики/рекрутёры в большинстве своём неграмотные… а в мелких конторах — вообще хотят фулл-стеков-задёшево...


PS не скажу за php7, а вот php версий 2/3/4 легко и непринуждённом добавляет вредных привычек в разработке. В этом плане питон всё-же лучше (и учиться на нём правильнее). Но вообще я апологет строгой типизированности языков… Так что я бы вам предложил посмотреть на Java/Kotlin/Scala/c# — найти работу не сильно сложнее, зато обучиться правильным практикам шанс всё же выше.

Именно Java EE? Или всё-таки SE лишь с некоторыми фичами EE

Ну скажем так, если касаться Java, то тут у меня «широкополосный спектр задач»:
— есть и ORM (by Hibernate)
— есть и микросервисы (by Jersey)
— есть и Sockets&WebSockets
— есть и Android (разнокалиберных версий)
… и т.д., и т.п.

Поэтому всякое и по-разному — более-менее серьезный аутсорс же.
И да — лучше писать или Java 8 или Java v1.8

Да, я и не спорю… странно как-то написал, согласен :)

хм… при таком наборе не вижу смысла упоминать Java EE, всё таки в ней очень много специфики, у вас же тут классическая Java SE в энтерпрайзе.

Питон в энтерпрайзе часто выезжает на интеграции систем. Когда у вас слева портал на пхп, справа какая-то корпоративная система на .NET, и ко всему этому нужно прикрутить пачку C++ приложений, что бы все это было ровно сынтегрировано — тут и выезжает питон.
Задача не совсем для junior-позиции, как мне кажется)
Почему? Интеграция систем не сложное дело на самом деле. Половина задач в духе «сюда добавь галочку, если стоит, тут поменяй параметр в запросе, покрой тестами». Для джуна в самый раз. Учитывая нехватку кадров можно смело подавать резюме на мидловские и даже сениорские позиции.
Полтора года назад начинал с Junior Python и Django. С питоном ситуация не печальная, трудоустроиться реально, но вакансий (особенно джун) меньше, чем по PHP, Java, JS. PHP очень похож на питон, где-то упрощен, что-то хуже и сложнее чем в питоне, а PHP и Python фреймворки похожи и основаны на одинаковых идеях, взять для сравнения те же Django и Symfony, например. Можете быстро подучить PHP, стартовать карьеру с него, а через 1-2 года уже рассматривать вакансии на столь любимом питоне.
Уже какой день погружаюсь в PHP. Неприязнь проходит. Радует, что на голом PHP уже можно что-то делать. Как по мне язык оказался даже приятнее JS. Конечно, в программировании я пока мало понимаю, но кажется мне, что негатив про PHP больше надуман и притянут за уши. Стала образовываться каша в голове от трех языков, синтаксис перемешался, но надеюсь пройдет.
негатив про PHP больше надуман и притянут за уши.

Немного не так:


  • php имеет очень низкий порог вхождения
  • как следствие — много малограмотных разработчиков, гонящих говнокод
  • изначально язык не планировался для сколько-нибудь серьёзных вещей и долгое время развитие носило хаотический характер — соотетственно в языке много возможностей наговнокодить
  • вроде бы сейчас стараются от этого уйти
  • но отмыть репутацию не так просто, и первые два фактора всё равно на неё влияют отрицательно
Неужели низкий порог вхождения это минус? Что бы начать писать на GO тоже не надо месяцы тратить, но от этого он язык не становится плохим. С языками странная история. Ни JS, ни PHP большого будущего не пророчили, а вышло неловко. В любом случае, как показывает практика, работы на PHP много и хватает даже джунам.
А почему так плюются на 1с, пыху и жс? Как раз потому что низкий порог вхождения, а соответственно и тонны говнокода и говнокодеров. Для бизнеса это конечно плюс, для неосиляторов вроде меня которые сходу не смогли в более интересные вещи — тоже плюс, но в целом, имхо, минус.

А я разве минусы рисовал? Я делал "снепшоты" фактов. Вот есть факт про низкий порог. А вот есть факт, что из-за низкого порога есть тонны говнокода. И вот уже он — как раз и минус и источник отрицательной репутации.

На последнем месте работы/стажировки у меня был начальник. Типа главный технический директор. Молодой человек на 10 лет меня моложе с дипломом типа «антикризисное управление в информатике какого-то провинциального ВУЗа.

Я не знаю, чем он занимался. За месяц он сделал два коммита и три комментария в JIRA. Но как ни глянешь — он все время чем-то занят. Чем-то очень важным, потому что сидит, уткнувшись в монитор, иногда что-то печатает, иногда кликает мышкой.

С вопросами подходить нельзя.
»Не знаю", «Думай сам», «Ищи сам», «В гугле не может быть не быть ответа на твой вопрос, ты плохо ищешь», «Я не знаю как работает эта библиотека, мы (я) выбрали её потому что у неё много лайков на гитхабе», «Читай документацию», «Библиотека, у которой 800 лайков на гитхабе не может быть плохой», «Этого не может не быть в документации, ты плохо читаешь», «Нет, мы не будем использовать эту библиотеку, потому что я так сказал», «Нет, мы не будем использовать гитлаб, потому что я привык использовать битбакет», «мне проще найти специалиста, который будет работать с теми же самыми инструментами, с какими привык работать я, чем подстраиваться под чужой опыт».

И комментарии СЕО:
«Он мне слишком дорого обходится, чтобы он отвечал на твои вопросы», «у него много работы, не отвлекай», «я плачу ему слишком много, чтобы он учил тебя чему-то или разбирался в чем-то сам», «нам нужен человек, которого не надо будет учить, это слишком дорого, мы здесь не людей учим, а бизнес делаем»

Получал этот CTO конечно не 300 долларов в час конечно, но в 4-5 раз больше фуллстек-разработчиков (которые получали в полтора раза меньше рынка). Но все равно, он слишком дорого обходился фирме, чтобы он тратил свое время на обучение кого-то чему-то. По крайней мере так считало руководство.

Как по мне, за такие деньги он должен был свой личный опыт ежедневно по часу в день передавать в рамках семинаров.
Тем более что в фирме по сути не было ничего, реально входящего в сферу ответственности техдира с такой з/п.
Было 7 компов, вайфай роутер, не было ни одного сервера, не было ни одного сайта на поддержке, не было ни одной БД на поддержке…


Собственно резюмирую:

«Ничего личного, просто бизнес».

Обучение джуниоров — это как фундаментальные исследования. Это стратегические траты, которые окупятся не вотпрямщас и не через два дня, а через 3 месяца, через полгода или год. Тогда, когда неоперившийся птенец сможет летать сам, а не ждать червячков от мамы. Опасность еще и в том, что оперившись, он возьмет, да и уволится, улетит из гнезда, обесценив для вас ваши затраты на его обучение.

Статегические траты — это не те риски, на которые готовы пойти фирмы, которые «бизнес делают здесь и сейчас». Конторы, которым нужны крутые разработчики прямо сейчас чтобы написать вот эту никому ненужную крутую штуку, продать и отбить бабло, вложенное в разработку.

В таких местах высшие офицеры действительно слишком заняты, чтобы учить кого-то чему-то. У них времени нет.

Получается заколдованный круг.
Крутые разработчики нужны, но взять их неоткуда, потому что крутой разработчик — это опыт, который можно получить только на практике. И выращивается крутой разработчик не из крутого разработчика, а из джуниора. Но джуниор не нужен фирме, на него нет времени, нет денег и он не нужен, нужен крутой разработчик.

У меня всё.
Получал этот CTO конечно не 300 долларов в час конечно, но в 4-5 раз больше фуллстек-разработчиков (которые получали в полтора раза меньше рынка)

По какой причине эти разработчики там работали?
Подавляющее большинство программистов обладает околонулевыми соц. навыками, так что сменить место работы — жуткий стресс.
По какой причине эти разработчики там работали?

Ну вы же понимаете, испытательный срок, молодой стартап, вот сейчас вы поработаете на стажировке 2 недельки на 60 тысяч, потом на испытательном за 80 или 90 месяца два или три, а потом посмотрим. Почти цитата.
Вот! А то тут еще спрашивают, зачем нужны soft skills. Вот за тем и нужны, чтобы припахать лоха.
Ну что вы, речь всего лишь идет о том, чтобы себя эффективно продать.

Я вот себя продавать не умею и вряд ли уже и научусь. А вот тот «технический директор» себя очень эффективно продал.
Вот и ответ на вопрос «Кто убил джуниора?» — государство. И американское, и российское. И там, и тут ситуация одинаковая (не — в России всё-таки хуже — из неё сеньоры с миддлами ещё и убегают в Америку): образование, и без того корявое, отдано на откуп бизнесу, который стратегических задач, таких, как улучшение системы образования, решать в принципе не будет; выпускники ВУЗов на госпредприятия, где они могли бы наработать опыт, не распределяются.
Но, в целом, никакой трагедии нет, так как ИИ скоро заменит не только джуниоров, но и большую часть остальных разработчиков.
Не нужно переживать ни за молодых разработчиков в Штатах, ни за чрезмерные рейты «сеньоров» — все это глупая ложь эмансипированной тётки, которая не имеет ни малейшего представления об индустрии. Толковые студенты находят себе хорошую работу, едва закончив обучение (а многие и ранее), «сеньоры» получают от $80/h до $120/h (но и это достаточно много, можете мне на слово поверить). Проблемы есть только у нихрена не умеющих делать в программировании тёток, которые, вместо того, чтобы обучаться и совершенствоваться (например, зафоркать, развить и послать pull request популярному проекту на github), предпочитают собирать «конгрессы», и с пеной у губ обсуждать, «почему проклятые капиталисты не берут на работу женщин».

Топик — полное «овно», я бы не дал себе труда подобное переводить. Нет ни малейшей корреляции с объективной реальностью.
>выпускников курсов программирования или учебных программ
Это не юниоры, а дикие кодеры, которые не про банду 4 не слышали, не про ООП не про биг О. Юниор — это кто из универа вышел и все это знает, но не знает как и когда все это применить.

Articles