Comments 428
С одной стороны вроде все правильно и очень хорошо что хоть кто о думает о проблемах начинающих разработчиков.
Но с другой как вспомню как нам приходилось начинать — ни интернета, ни путевой литературы, ни вменяемых наставников. Да что там интернет — доступ к современному компьютеру был большой проблемой. Так сразу кажется — да молодежи теперь только стоит захотеть и ты уже программист с такими возможностями какие 30 лет назад нам и не снились.
ИМХО, конечно, и наверно это уже старость…
Но с другой как вспомню как нам приходилось начинать — ни интернета, ни путевой литературы, ни вменяемых наставников. Да что там интернет — доступ к современному компьютеру был большой проблемой. Так сразу кажется — да молодежи теперь только стоит захотеть и ты уже программист с такими возможностями какие 30 лет назад нам и не снились.
ИМХО, конечно, и наверно это уже старость…
Да, то были прекрасные светлые времена))) Сейчас у джунов на уме только бабки и нежелание учиться… печаль
Ну собственно говоря, девушек заместили бабками и на этом всё.
Вспоминается анекдот про диалог двух дедушек, которые справляют большую нужду:
— Никифор, а помнишь раньше когда срали — яйца до земли доставали?
— Даааа, стопталась землюшка, стопталась…
Нынешние джуны растут в принципиально другой информационной среде и, не побоюсь сказать, практически другой культурной парадигме. Будьте к ним добрее :)
— Никифор, а помнишь раньше когда срали — яйца до земли доставали?
— Даааа, стопталась землюшка, стопталась…
Нынешние джуны растут в принципиально другой информационной среде и, не побоюсь сказать, практически другой культурной парадигме. Будьте к ним добрее :)
Да, так и есть. До сих пор помню как методом «научного тыка» изучал басик на спектруме. Потом на толкучке приобрел пару книжек. Одна была по программированию игр на ассемблере а вторая была больше похожа на справочник по аппаратному устройству и командам процессора. Как же было их трудно читать не имея ни малейшего понятия почему все устроено так а не иначе и не имея никакой возможности у кого-либо спросить — тогда еще не было не то что интернета, а и сотовых еще не было. А преподаватели часто знали меньше учеников — что в школе что в кружке (там стояли БК со своим басиком И как тогда казалось спектрум их опережал намного по своей продуманности и простоте). Только только в страну потекли первые x86-совместимые компы которые мог себе разве что крупный бизнес позволить. И когда в итоге он появился у меня через пяток лет уже было проще понять как и почему оно работает. И да — это старость =)
А сейчас можно в качестве примера перенести этот опыт на, скажем, ракетостроение.
Тоже практической информации почти нет, до всего нужно самостоятельно доходить ценой свободного времени, терпения соседей и прочности отцовского гаража. Зато раздолье в плане стандартизации — (почти) ничего ж не контролируется, мешай себе реактивы для топлива да следи только, чтоб ничего не сжечь (это я утрированно, уверен, что в реальности много сложнее). Зато лез через сорок уже ничего просто так не запустишь — везде правила, стандарты, обязательные к выполнению, если хочешь получить работу, да еще и небо закидано такими убердевайсами, на которые смотришь, и руки опускаются — до этого уровня надо ракетами заниматься с глубокого детства целенаправленно, а не пройдя пятилетний курс «Основы ракетоведения» в провинциальном педуниверситете.
Тоже практической информации почти нет, до всего нужно самостоятельно доходить ценой свободного времени, терпения соседей и прочности отцовского гаража. Зато раздолье в плане стандартизации — (почти) ничего ж не контролируется, мешай себе реактивы для топлива да следи только, чтоб ничего не сжечь (это я утрированно, уверен, что в реальности много сложнее). Зато лез через сорок уже ничего просто так не запустишь — везде правила, стандарты, обязательные к выполнению, если хочешь получить работу, да еще и небо закидано такими убердевайсами, на которые смотришь, и руки опускаются — до этого уровня надо ракетами заниматься с глубокого детства целенаправленно, а не пройдя пятилетний курс «Основы ракетоведения» в провинциальном педуниверситете.
Тогда была проблема найти информацию. Сейчас есть проблема не проще — отфильтровать информацию. Сложно начинать, когда тебе со всех сторон предлагают совершенно разные пути и никто не может объяснить, чем они отличаются. Я начинал программировать на спектруме (и это в 2000 году!) с одной книгой в руках и отлично вас понимаю. Но ещё я учусь программировать сейчас и считаю проблему поиска качественной информации не менее важной. Я находил фактические ошибки в самой рекомендуемой книге по изучению python, я вижу полнейшее безумие советов в каналах по JS и не вижу тенденций к улучшению. Неверные знания хуже их отсутствия. Поэтому наставник нужен как никогда.
Согласен! Сейчас трудно отфильтровать действительно ценную информацию от мусора.Помню времена, когда в школе стояли «Агаты» и по ним всего пару книг, которые шли в комплекте(по сей день где-то лежат на память). Еще сейчас все делается на фреймворках, изучить хотя бы несколько требует много времени, если заниматься этим самостоятельно. Плюс на изучение только ночи. Днем работа, вечером дети. Устроиться джуном — самый лучший вариант научиться. Учишься и получаешь деньги. Уже голова не болит где взять деньги и жена не терзает, что сидишь в компе занимаешься фигней по ее мнению
Я, кстати, тоже учился ещё на спектруме. Написал программу для решения уравнений методом дискриминанта. Тогда понял, что памяти впритык и начал изучать assembler.
Сейчас конечно гораздо проще учиться, но этого недостаточно для того, чтобы сразу стать мидлом, вот в чём проблема. Опыт работы ничем не заменишь.
Сейчас конечно гораздо проще учиться, но этого недостаточно для того, чтобы сразу стать мидлом, вот в чём проблема. Опыт работы ничем не заменишь.
Раньше ничего не было, а сейчас слишком много всего и разобраться, что из этого важно, а что нет становится очень сложно, особенно когда нет опыта.
Не согласен. Проблему избытка информации нужно решать систематизацией.
В первую очередь — изучить основы. Во вторую — выбрать для себя направление и методично двигаться по нему, но не забывать оглядываться по сторонам чтобы не оказаться чересчур узким специалистом. Лучше всего конечно делать это с помощью опытного наставника, но если его нет при желании можно справиться и самому.
В первую очередь — изучить основы. Во вторую — выбрать для себя направление и методично двигаться по нему, но не забывать оглядываться по сторонам чтобы не оказаться чересчур узким специалистом. Лучше всего конечно делать это с помощью опытного наставника, но если его нет при желании можно справиться и самому.
Раньше и в требованиях вакансий кучу узкоспецифичных фреймворков не указывали.
А если указывали, то перед этим думали, действительно ли такой фремворк нужен или хотя бы изредка используется. Сейчас в текст вакансии просто копируют из википедии все фреймворки, какие найдут, а пользоваться ими даже не собираются.
Но вообще, господа будущие джуниоры! Ну не надо приходить на собеседование, если вы не способны на основном языке написать код «открыть файл, пересортировать строчки, сохранить файл». Таких приходит больше половины.
Но вообще, господа будущие джуниоры! Ну не надо приходить на собеседование, если вы не способны на основном языке написать код «открыть файл, пересортировать строчки, сохранить файл». Таких приходит больше половины.
Я сейчас тоже не смогу слёту написать код «открыть файл, пересортировать строчки, сохранить файл», потому что не делаю это каждый день
Вообще забыл, когда последний раз с файлами работал
Главное же знать принципы работы, уметь находить решения
А частности на собеседовании спрашивать — я думаю, это лишнее, их лучше перемещать в тестовое задание
Вообще забыл, когда последний раз с файлами работал
Главное же знать принципы работы, уметь находить решения
А частности на собеседовании спрашивать — я думаю, это лишнее, их лучше перемещать в тестовое задание
Но вообще задач с файлами полно, особенно их много в университетских лабораторных. Про работу с файлами всегда пишут в книгах "<язык программирования> для начинающих".
Так что если человек понятия не имеет как работать с файлами то не понятно что он читал и что делал в университете.
В конце концов если он не помнит конкретных методов, то пусть продемонстрирует как их найти.
Так что если человек понятия не имеет как работать с файлами то не понятно что он читал и что делал в университете.
В конце концов если он не помнит конкретных методов, то пусть продемонстрирует как их найти.
Покажете, как это из JS в браузере сделать? Без участия пользователя.
Вы, конечно, сейчас пытаетесь хитрить, но и там найдется винт с резьбой LocalStorage, sessionStorage, IndexedDB и т.д.
Но с другой стороны никто особо и не требует знания какого-то конкретного фреймворка. Знаешь один — сработаемся.
А чего вы от джуниора ожидаете? К нам часто приходят джуны и мы их охотно берем. Главное увидеть, что человек хочет учится и готов думать башкой при выполнении задач.
А умение решать конкретные задачи — это всего лишь умение прочитать документацию или доступные варианты в интернете. Остальное приходит с опытом.
А умение решать конкретные задачи — это всего лишь умение прочитать документацию или доступные варианты в интернете. Остальное приходит с опытом.
От джуна ожидаю способности написать Hello World. Без подсказок. (ну со справкой в зубах, конечно.) Приходит же явление, которое через раз на Power User не тянет. Я до ВУЗа умел больше, чем эти ребята — после.
Если не сложно, охарактеризуйте пожалуйста, как понять джуниор ли я.
Ежедневно пытаюсь впитывать пусть (не тонны то хотя бы на пол шишечки) информацию, но все равно при просмотре требований джуниора .NET к примеру, понимаю что там одних только фреймворков сколько, что у меня в школе предметов меньше было, так еще и помимо этого знание и SQL и HTML и CSS и еще много-много страшных слов.
Ежедневно пытаюсь впитывать пусть (не тонны то хотя бы на пол шишечки) информацию, но все равно при просмотре требований джуниора .NET к примеру, понимаю что там одних только фреймворков сколько, что у меня в школе предметов меньше было, так еще и помимо этого знание и SQL и HTML и CSS и еще много-много страшных слов.
Требования через раз пишут менеджеры (эффективные), которые сами не понимают в теме от слова совсем. Программисты от них отмахиваются общими фразами, а менеджеры эти фразы преобразуют в общие требования. Вот и получаются такие объявления.
Калькулятор написать, скомпилировать и запустить можете? Отлично, вперёд к работе! Через одного — не могут.
Калькулятор написать, скомпилировать и запустить можете? Отлично, вперёд к работе! Через одного — не могут.
> но все равно при просмотре требований джуниора
Требования не важны. Важно, умете ли вы решать на практике конкретные задачи.
Требования не важны. Важно, умете ли вы решать на практике конкретные задачи.
Я знаю очень хорошую, а потому очень правдивую шутку.
Миддл может вытянуть проект один без «оркестра». Джуниор, соответственно, не может, а сениор — не будет.
Миддл может вытянуть проект один без «оркестра». Джуниор, соответственно, не может, а сениор — не будет.
С гуглом или без?
Ну не скажите, анекдот «Если бы водителей нанимали как программистов» я впервые прочитал лет 15 назад:
Вакансия: водитель.Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами “Формулы 1″ — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.Зарплата: определяется по результатам собеседования.
Наверняка он появился бы и раньше, но рунет начал широко продвигаться только тогда.
Вакансия: водитель.Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами “Формулы 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, который вам скинули в виде скриншота. Умереть не встать.
Но вообще-то всё было сложнее. Мы писали на си, где шаг влево, шаг в право это расстрел и всё что ты видишь это «segmentation fault». И у нас не было resharper`а который исправит твои мелкие ошибки в синтаксисе, автоматически подключит недостающие билиотеки. Компилятор, текстовый редактор и развлекайся как хочешь.
Дело не в том больше или меньше технологий, а в том как к ним вообще получить доступ.
Представьте что у вас вообще нет ни домашнего компьютера, ни интернета, ни специальной литературы, а только обрывочные сведения из журналов и ТВ.
Как думаете выросли бы у вас возможности претендовать на вакансии или нет?
Представьте что у вас вообще нет ни домашнего компьютера, ни интернета, ни специальной литературы, а только обрывочные сведения из журналов и ТВ.
Как думаете выросли бы у вас возможности претендовать на вакансии или нет?
Представьте что у вас вообще нет ни домашнего компьютера, ни интернета, ни специальной литературы, а только обрывочные сведения из журналов и ТВ.
Согласен, 10 лет назад был именно в такой ситуации, чего то хотелось — но где инфу брать неясно, как что то делать — неясно. В таких условиях трудно что то делать. Только потом сначала телефон с интернетом появился (сказать честно — не сильно мне помог), а 6 лет назад, на втором курсе уже комп появился, с доступом к нормальному интернету, только тогда смог начать сначала навыки работы с ПК нарабатывать, потом уже пошло: линуксы как десктопная система, разные попытки программировать и т.д. Прогресс пошел только когда появился комп и интернет.
Согласен, 10 лет назад был именно в такой ситуации, чего то хотелось — но где инфу брать неясно, как что то делать — неясно.
Не понял.
Инфы полно уже с прошлого века (это почти 20 лет как).
Интернет давно существует.
Интернет давно существует, доступ у всех к этому интернету — до сих пор не у всех есть.
А мне тут понятно.
В России как раз 10 лет назад стал развиваться массовый доступ в интернет. Телефоны были сильно слабее и дороже.
А если в глухой провинции то все еще сложнее, особенно если некому подсказать и направить.
Но то теперь те кто целыми днями торчат в соцсетях в крутых смартфонах жалуются что не знают где взять нужную инфу. Они просто не знают что такое сидеть без информации.
В России как раз 10 лет назад стал развиваться массовый доступ в интернет. Телефоны были сильно слабее и дороже.
А если в глухой провинции то все еще сложнее, особенно если некому подсказать и направить.
Но то теперь те кто целыми днями торчат в соцсетях в крутых смартфонах жалуются что не знают где взять нужную инфу. Они просто не знают что такое сидеть без информации.
Да, все именно так, маленький поселок в провинции, стоимость телефона даже просто с интернетом сравнима с месячной зп, про смартфоны и тем более компьютеры не говорю, так что позволить себе это мы не могли. Если сравнивать ситуации без ПК и с переизбытком информации (напомню — комп с интернетом у меня с 2012, не так уж давно чтобы кардинально объемы с тех пор увеличились) — я однозначно выбираю переизбыток информации.
В 2008-м? Похоже на байки бабушки Арины… Уже в сотовых сетях инет был и довольно доступный, а мопедно-дслный так и подавно даже в глухоманях. Не быстрый, конечно. Обычно в Зажопинсках на 64-128 кбит подключал Ростелеком (или что там было на него месте), но этого хватало для полноценной работы, чтения, переписки, чат-общения, просмотра понро и кино
Примерно та же ситуация, только на год раньше. И при этом я скучаю по тем временам, когда голова была чиста от информационной лавины. Когда один в классе компоновал рефераты по книжкам и писал их от руки на «зебре», а не качал и печатал готовые. Когда мог целый день заниматься полезными вещами и не тратить время на отвлекающие факторы, кроме редкой болтовни по телефону. Когда надеялся, что программировать буду только на работе, а дома удастся избежать соблазнов, на которые подталкивают компьютеры и интернет… Но вышло строго наоборот.
А мне тут понятно.
В России как раз 10 лет назад стал развиваться массовый доступ в интернет. Телефоны были сильно слабее и дороже.
В 2008 году?
Да ладно.
В 2004 еще поверю.
Я из глухой преглухой Сибири.
У нас еще в 1994 году появился интернет. Да медленный и дорогой. Но в принципе к году 2002 он был уже вполне доступен частному лицу при большом желании.
Большее желание нивелируется финансовой составляющей.
Большее желание нивелируется финансовой составляющей.
Я тогда уже ребенка обеспечивал и квартиру снимал.
Тем не менее интернет у меня был.
А некоторые были с ребёнком и ожиданием зарплаты и обещаниями со своего.
PS. А телефон был или у милиционеров или у железнодорожников. Модема не было — некуда им звонить.
PS. А телефон был или у милиционеров или у железнодорожников. Модема не было — некуда им звонить.
А телефон был или у милиционеров или у железнодорожников.
Вы из 1950-х приехали?
У однокурссницы был интернет на спаренном с соседями телефоне — да. Они ругались что как не позвонишь там что то шипит. Она ругалась что как не выйдешь в интернет — связь рвется из-за соседей.
Вы точно из российской глубинки? Это там где в 2008 было на весь поселок из 2к человек в районе 50 ПК, и почти половина из них в школе? Там где только пару лет как стала сотовая связь в принципе доступна? (помню году в шестом было всего несколько мест где ловило) и т.п.?
Вы точно из российской глубинки? Это там где в 2008 было на весь поселок из 2к человек в районе 50 ПК, и почти половина из них в школе?
У нас федеральные трассы покрыли сотовой связью еще к 2006 году.
Году к 2010 самая дальняя деревня уже была с интернетом.
Да, до сих пор есть места, где плохо ловит интернет и даже телефон.
Но в целом уже лет 10 как ноутбуком уже не удивишь и в самой глухой деревне.
Если вы из горного района — это другое дело. Там проблемы и до сих пор во многих деревнях. Горы экранируют.
Да нет, центральная Россия. Даже представить не могу откуда такая разница. Интернет в деревне к слову был у нескольких человек. Но не у меня (семья скажем так… небогатая была), и у близких знакомых тоже не было.
Но не у меня (семья скажем так… небогатая была), и у близких знакомых тоже не было.
Тут вряд ли деньги.
Скорее — желание, приоритеты.
Дело в том, что я-то вкусил интернета еще в ВУЗе и плотно на него подсел. Стал важнейшим приоритетом.
И после этого уже даже когда было слишком дорого — все равно платил провайдеру.
Это как автомобиль. Пока его нет у человека — он может считать, что автомобиль и не нужен. А как появляется, но потом исчезает (сломался, авария, нет денег) — уже его очень и очень хочется заполучить назад.
Вот только с ним познакомиться нужно еще) А если компьютер вживую только на уроке информатики видишь, да и там изучение ограничивается вордом и qbasic (дико понравился в то время) — то как то даже не представляешь себе каково оно. Ну и все таки позволить мы себе этого действительно не могли. Как то телевизор сломался — больше года без него жить пришлось, а уж компьютер…
Дело в том, что я-то вкусил интернета еще в ВУЗе и плотно на него подсел.
Сложно было вкусить то, что показывали на старшем курсе один раз (ездили в Дом Учёных для этого). Но во всяких журналах компьютерных читали, на конференциях рассказывали о такой классной штуке. Идея гипертекста выглядела фантастической (хотя всякие хелпы со ссылками на другой раздел и были чуть ли не в NC3 и сами даже делали из го… подручных материалов).
Скорее — желание, приоритеты.
Приоритеты — пожрать или интернет, отличный выбор.
Приоритеты — пожрать или интернет, отличный выбор.
Я допускаю что где то в отдельных местах был такой выбор.
Но, повторяюсь, я, будучи молодым папашей с неработающей женой и живя на съемной квартире (это очень дорого было — 50% дохода на аренду квартиры) — тем не менее позволял себе интернет.
Не самых быстрый тариф, но тем не менее.
Хорош жаловаться на жизнь.
Все в ваших руках.
В очень многих местах был такой выбор, а позволить себе интернет могли разве что в крупных или особенных городах, где не видели выплату зарплаты продукцией и думают что их исключительные условия были везде.
> Хорош жаловаться на жизнь.
Очень странно называть представление о реальном положении вещей жалобами, у меня-то как раз всё хорошо было, но я бывал не только в крупных городах и имел возможность сравнить очень разные условия. Далеко не везде они были такими прекрасными.
> Хорош жаловаться на жизнь.
Очень странно называть представление о реальном положении вещей жалобами, у меня-то как раз всё хорошо было, но я бывал не только в крупных городах и имел возможность сравнить очень разные условия. Далеко не везде они были такими прекрасными.
Чуть новее, но даже в начале 0х именно так и было. И это не глухая деревня, а узловая станция (именно потому у железнодорожников — сотовой связи нет и как-то оповестить об аварии надо).
Ваша глухая Сибирь случайно не в районе новосибирского Академгородка?
В моем глухом городке проводной телефон провести было проблемой.
Это теперь он даром не нужен, а тогда в 2002 году надо было подать заявление и ждать в очереди не известно сколько лет.
Впрочем, если среди близких родственников был директор городской АТС то вопрос решался за месяц-другой.
Но у меня со связями всегда было никак, так что до 2008 года интернетом пользовался только на работе и то примерно с 2000-го года.
А интернет в 1994 в преглухой Сибири… Шикарно вы там жили.
В моем глухом городке проводной телефон провести было проблемой.
Это теперь он даром не нужен, а тогда в 2002 году надо было подать заявление и ждать в очереди не известно сколько лет.
Впрочем, если среди близких родственников был директор городской АТС то вопрос решался за месяц-другой.
Но у меня со связями всегда было никак, так что до 2008 года интернетом пользовался только на работе и то примерно с 2000-го года.
А интернет в 1994 в преглухой Сибири… Шикарно вы там жили.
Да ладно?!
В 2008 году интернет в России был очень даже хорошо развит. Сайтов и информации уже было море. Тот же хабр уже как два года существовал к этому времени.
Даже модемы к этому времени уже исчезли.
А вот в 1998 да, интернет только развивался, модемы, диалапы…
В 2008 году интернет в России был очень даже хорошо развит. Сайтов и информации уже было море. Тот же хабр уже как два года существовал к этому времени.
Даже модемы к этому времени уже исчезли.
А вот в 1998 да, интернет только развивался, модемы, диалапы…
что-то вы путаете, наверное всё-таки не 10, а 15 или 20 лет назад?
10 лет назад уже айфон и андроид были, GPRS, ADSL, радиомосты, не говоря уже про диалап
10 лет назад уже айфон и андроид были, GPRS, ADSL, радиомосты, не говоря уже про диалап
А книги, что отменили? Лично я и в 95-м и в 2005-м большую часть информации о компьютерах и программировании получал из книг. Причем стоили они тогда гораздо дешевле чем сейчас. За счёт бОльших тиражей.
Ну да, была в библиотеке школьной пара книжек. Правда было одно но: без компьютера это было не так интересно.
Дело даже не в том что не интересно, а в том что устарело уже на момент издания книги. Если и стоило изучать то чтобы хоть что то знать.
Ну, тут еще сыграли роль мои заблуждения, учитывая уровень информатизации моего поселка — я был в полной уверенности что спрос на программистов никакой (нужно человек по 500 в год, причем только вундеркинды какие то), и планировал этим заняться в будущем, как хобби, а поступать в медицинский, или, если не пройду, то на экономиста))
я был в полной уверенности что спрос на программистов никакой
то есть вы выбираете профессию по спросу, а вовсе не потому что она вам нравится?
Не совсем так, вы пропустили пункт про то что их требовалось по моему мнению тогда человек 500 в год, куда уж мне, хорошисту у которого достижений разве что районные олимпиады по математике, информатике и физике, тягаться с призерами всероссийских олимпиад, краснодипломниками МГУ и т.д. Собственно поэтому «здраво» решил оставить это как хобби которому свободное от учебы и работы время посвящать, а идти работать в нужную сферу типа медицины и экономики. Впрочем даже с медициной не сложилось, не хватило моих 238 баллов по трем предметам для поступления на бесплатное, пришлось на экономиста идти. Для меня тогда программирование выглядело именно как rocket science, круто, интересно, но шансов попасть нет из за тупизны собственной и потому что берут лучших из лучших. Ну а когда понял реальный порог вхождения — было поздно уже что то менять, решил доучиваться на экономиста, благо 2 года всего с копейками оставалось, да и специальность называлась «Прикладная информатика в экономике»
Это Вы о 95-м или 2005-м годе???
Я о конце 80х и начале 90х
Тогда вообще не понятно. Тогда книги не устаревали о-очень долго. Например, Фигурнов издавался несколько раз с не очень большими изменениями. О Фаронове (книга по Турбо-Паскалю) вообще молчу…
Ну это у нас, в СНГ. На западе откуда все приходило гораздо динамичнее все развивалось.
А Фигурнов это ведь про IBM PC, а про Apple, например, не помню литературы.
А Фигурнов это ведь про IBM PC, а про Apple, например, не помню литературы.
Ну это у нас, в СНГ. На западе откуда все приходило гораздо динамичнее все развивалось.
Не-а.
И у них раньше было нужно мало программистов.
Скачок в этих технологиях, быстрая их смена и большая востребованность программистов — веяние сравнительно недавних времен.
Разница с Западом только та, что там чуть-чуть раньше началась автоматизация, чуть чуть раньше появлись персональные компьютеры и пр.
Взять ту же Delphi, наследницу Pascal, описанного Фигурновым.
Delphi обеспечивала фирме Borland весьма устойчивое положение на рынке вплоть до границы веков. И MS ничего не могла противопоставить пока не переманила архитектора Pascal/Delphi из Borland. Это было в самом конце 20 века только.
Вы видимо каких то тепличных условиях вообще были.
Наверно и книги и новые программы вам доставляли сразу как только они появлялись. Мне же приходилось ждать их годами.
Дельфи когда я смог посмотреть он был уже то-ли 5й то-ли 6й.
До интернета у меня доступа еще не было. Приходилось во всем разбираться методом тыка либо компилировать в голове какие то обрывочные сведения.
Наверно и книги и новые программы вам доставляли сразу как только они появлялись. Мне же приходилось ждать их годами.
Дельфи когда я смог посмотреть он был уже то-ли 5й то-ли 6й.
До интернета у меня доступа еще не было. Приходилось во всем разбираться методом тыка либо компилировать в голове какие то обрывочные сведения.
Вы видимо каких то тепличных условиях вообще были.
Сибирский город с населением около 65 000 человек на тот момент, когда я начал изучать ИТ в 1987 году. Железная дорога появилась в 1985 году. До того — только самолеты и вертолеты. Полная изоляция. Автомобильная дорога появилась только в этом веке.
Ближайший населенный пункт с более-менее адекватной инфраструктурой (где то 220 000 жителей) — в 330 км.
Приходилось во всем разбираться методом тыка либо компилировать в голове какие то обрывочные сведения.
Дает более глубокое понимание.
Это скорее плюс, если удается сохранить мотивацию.
Вам грех жаловаться.
Много ли компьютеров Apple было в 80-е — начале 90-х в СНГ? Считанные единицы. Если у Вас был, не могу даже сказать, повезло Вам или нет…
Дело даже не в том что не интересно, а в том что устарело уже на момент издания книги. Если и стоило изучать то чтобы хоть что то знать.
Машина Тьюринга или Pascal — вполне себе актуальны. Даже книжка по Java из 1995 в 2005 году если не актуальна, то на 95% полезна.
30 лет назад и программирование было не как сейчас. 5 лет назад я спокойно писал приложения под андроил, а теперь открываю и не знаю с чего начать. Куча новых SDK, какой то Kotlin… О котором я 5 лет назад и не слышал и сомневаюсь, что он тогда и был.
А при чем тут Kotlin? Это просто язык программирования, изучать его или игнорировать можно независимо от разработки под Android.
Я вообще никаких отличий в программировании под Андроид не вижу с тем что было 5 лет назад.
Был Эклипс, стал Android Studio. Причем этого можно было и не заметить, потому что ведут они себя очень похоже.
Даже уроки по написанию приложений 5 летней давности вполне спокойно делаются сейчас.
Что у вас так сильно изменилось в программировании под Андроид?
Был Эклипс, стал Android Studio. Причем этого можно было и не заметить, потому что ведут они себя очень похоже.
Даже уроки по написанию приложений 5 летней давности вполне спокойно делаются сейчас.
Что у вас так сильно изменилось в программировании под Андроид?
Да, но что нужно было учить?
Бейсик? HTML?
А сейчас даже не язык программирования, а сразу паттерны + CI + фреймворк
Бейсик? 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, потом Агат
Насчет ДВК-2 вам очень сильно повезло. В 88м только у счастливчиков у кого родные на заводе в АСУП или в институте был доступ к таким аппаратам.
А с агатов в школе мое айти и началось. Только каждый месяц ломались и чинились подолгу. А через год и чинить перестали.
А с агатов в школе мое айти и началось. Только каждый месяц ломались и чинились подолгу. А через год и чинить перестали.
или в институте был доступ к таким аппаратам.
У нас был списанный из вычислительного центра аппарат.
А к году 1990 подтянолась из того же ВЦ списанная DEC (не СМ-ЭВМ, а фирменная)
Целых две списанных персоналки!
Да одна импортная!
Да еще работающие!
Да вы олигарх!
Для того времени, конечно…
Да одна импортная!
Да еще работающие!
Да вы олигарх!
Для того времени, конечно…
Целых две списанных персоналки!
+ класс Агатов-2. Полный класс Агатов-2
А ДВК-2 была не одна, а с терминалами, то есть работало более 1 человека.
Вытирая скупую слезу: Да вы издеваетесь
Два класса Агатов (7 и 8, вроде, в разные годы или замена одного на другой — не помню), 2 класса БК, класс PS/2.
С БК-0010Ш даже кружок был, позволивший прикоснуться к замечательному языку Фокал(«а во втором классе, представляете!, даже клавиатуры не нарисованные, а настоящие»), Агаты тоже были сравнительно доступны, PS уже почти в конце обучения появились (главное разочарование — 5.25" там бесполезны и нужно искать эти новые 3.5", а без них там даже Бейсика в ПЗУ нет, зато с ними — TP, TC и Clipper).
С БК-0010Ш даже кружок был, позволивший прикоснуться к замечательному языку Фокал(«а во втором классе, представляете!, даже клавиатуры не нарисованные, а настоящие»), Агаты тоже были сравнительно доступны, PS уже почти в конце обучения появились (главное разочарование — 5.25" там бесполезны и нужно искать эти новые 3.5", а без них там даже Бейсика в ПЗУ нет, зато с ними — TP, TC и Clipper).
И я о чем говорю. Но что у нас было на ДВК? Фреймворки? Системы контроля версий?
Нет, была простенькая RT11SJ, простой бейсик и не слишком сложный, особенно по текущим меркам ассемблер.
И требования к программам на компьютере, где нет графического режима — невысокие.
Нет, была простенькая RT11SJ, простой бейсик и не слишком сложный, особенно по текущим меркам ассемблер.
И требования к программам на компьютере, где нет графического режима — невысокие.
В журнале Техника Молодежи, именно в то же время также постилась рубрика «БК за рога» с различными приемами для БК-010-01, а чуть позже и что-то для Спектрума.
В этой ветке обсуждаем 30 лет назад, а не 15-20.
Мало помню, было два года. Но лет в 6 была книжка по алгоритмам для детей, там учили рисовать блок схемы, все перемежалось красочными картинками с изображением компьютера в виде человека в разных ситуациях.
Я когда учился в школе в 90-е был записан во все библиотеки своего города и просто охотился на практически любую литературу по программированию. Но так как я жил в Казахстане не в областном центре, то такой литературы было очень мало. Попалась мне более мене стоящая книжка по Паскалю, ПЛ1 и какая-то совсем простая по Бейсику. Всё остальное были мануалы по досу, нортон коммандеру и т.д. Как-то получилось съездить в областной центр и я там в местной библиотеке удачно нашёл книгу по QBasic, но прочитать успел только несколько страниц. В это время я программировать толком не научился, писал только самые простые программы. Полноценно учится программированию я начал только 10 лет спустя.
С одной стороны юниоры ноют, что не берут, с другой стороны пересмотрел за год около 1500 резюме -простой sql запрос мало кто может написать. Какая то пустота в глазах — берите на испытательный, учите, да и еще некоторые умудряются спросить оплачивается ли тестовое часовое задание. Уровень очень низкий.
Вот тут как раз рекрутеры и нужны, а не там где их применяют. Вот тут как раз нужно фильтровать вменяемых их кучи.
Ну и очень мало компаний имеют программы работы с джунами. Что довольно странно — как раз у них сейчас к сениору ставят в требования коммуникативные навыки и пачку soft-skills. А как миддл может вырасти до сениора, если не будет работать с джунами.
В крупной компании не может быть вменяемого управления талантами и развития сотрудников без стабильного притока джунов.
Ну и очень мало компаний имеют программы работы с джунами. Что довольно странно — как раз у них сейчас к сениору ставят в требования коммуникативные навыки и пачку soft-skills. А как миддл может вырасти до сениора, если не будет работать с джунами.
В крупной компании не может быть вменяемого управления талантами и развития сотрудников без стабильного притока джунов.
> А как миддл может вырасти до сениора, если не будет работать с джунами.
А какая связь между ростом до сениора и работой с джунами? Я же верно понял, что речь не о сениор-воспитателе в детском саду?
А какая связь между ростом до сениора и работой с джунами? Я же верно понял, что речь не о сениор-воспитателе в детском саду?
Нет, но в обязанности сениора входит работа с мидлами. Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем. Повторюсь, речь идет о крупных компаниях, и там как правило нельзя просто подойти и сказать — э, слышь, уася, так не делай, так делай, сосулька башка попадет. Бывает даже вообще просто сказать что где-то ошибка нельзя, нужно «правильно подбирать слова в соответствии с политикой компании». Научится всему этому можно только на реальном опыте. Миддл может его получить только работая с джунами.
К слову говоря, когда миддлы приобретают такой опыт сами, они гораздо лучше работают с сеньорами, для них процесс передачи знаний перестает быть односторонней процедурой.
К слову говоря, когда миддлы приобретают такой опыт сами, они гораздо лучше работают с сеньорами, для них процесс передачи знаний перестает быть односторонней процедурой.
> Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем.
Энто ведь все в рамках рабочего времени? Ну, типа «я сегодня никаких тасок не выполнил, потому что наставничал с Васей, проходили с ним наследование». Работает же так? Ежели да, то окей.
> Повторюсь, речь идет о крупных компаниях, и там как правило нельзя просто подойти и сказать — э, слышь, уася, так не делай, так делай, сосулька башка попадет.
Согласитесь, это проблема конкретной компании, а не сениора. В нормальных компаниях принято говорить как есть. Ну потому что это банально эффективнее.
Энто ведь все в рамках рабочего времени? Ну, типа «я сегодня никаких тасок не выполнил, потому что наставничал с Васей, проходили с ним наследование». Работает же так? Ежели да, то окей.
> Повторюсь, речь идет о крупных компаниях, и там как правило нельзя просто подойти и сказать — э, слышь, уася, так не делай, так делай, сосулька башка попадет.
Согласитесь, это проблема конкретной компании, а не сениора. В нормальных компаниях принято говорить как есть. Ну потому что это банально эффективнее.
Энто ведь все в рамках рабочего времени? Ну, типа «я сегодня никаких тасок не выполнил, потому что наставничал с Васей, проходили с ним наследование». Работает же так? Ежели да, то окей.
В той компании где я работал, там были требования, но не было возможностей. Потому я там больше не работаю, ибо это бред. Но на уровне тимлидов была официальная «статья» расхода времени, управление командой. И на нее можно было списывать определенное количество времени в месяц, да. Хотя и не очень много.
Согласитесь, это проблема конкретной компании, а не сениора. В нормальных компаниях принято говорить как есть. Ну потому что это банально эффективнее.
Нет, это не проблема компании. Потому что это не эффективнее. Ты быстрее передаешь свое сообщение и даешь обратнуюсь связь, по этому кажется что это проще, и в каких-то отдельных случаях или сработаных командах это работает. Но не в масштабах крупной компании. Мало сообщить человеку что он ошибся, надо это сделать так, что бы он остался этим доволен, как это не парадоксально это звучит. В крупняке все держится на горизонтальных связях. Ты скажешь Васе что он накосячил, а он в следующий раз отправит тебя официально оформлять заявку на его работу. А ближайший общий руководитель у вас CEO и заявка пойдет через директоров департаментов, если они между собой договорятся. Нет — через вицепрезидентов. Вопрос который может быть решен за пять минут будет решатся пару недель или месяцев, в зависимости от того, насколько многим людям вы неаккуратно успели высказать свое мнение.
Нет, но в обязанности сениора входит работа с мидлами. Это весьма специфичные взаимоотношения — когда ты должен быть примером другим, проявлять некоторое наставничество не будучи при этом руководителем.Это где такие «обязанности»? Что, так прямо в job description и записано? :) Я работал (и работаю) в нескольких весьма крупных американских и транснациональных компаниях, но ни разу подобных «обязанностей» не встречал. И, скажу, жутко бы удивился, встретив подобное… «пионэрское отношение», скажем так.
Это что, в России так крупные компании работают? Пережитки развитого социализма у руководства? ;)
В вакансии этого не пишут, просто потому что смысла нет. Таких кандидатов просто нет, а вакансии закрывать надо. Без этих навыков наймут без проблем, даже на сениора. Но повышение вы не получите. Конкретно та американская компания в которой я работал имеет довольно широкую линейка чисто технических позиций и сениор это что-то в районе середины. И да, для каждой позиции прописаны компетенции, и hard skills там занимает только несколько строчек и прописаны весьма абстрактно, в духе «миддл владеет одним фреймворком, а сениор несколькими». Подавляющее число компетенций это именно soft skills. К слову, что забавно, таблицу эту почему то рядовым сотрудникам не показывают, и доступна она была только директорам департаментов, которые непосредственно участвуют в повышениях, тимлидам только по секрету. Так что не исключено что до вас такие вещи просто не доводили. Я практически уверен что в любой компании >1000 сотрудников >10 лет на рынке есть такие таблицы компетенций.
При всем при этом в компании не было никаких программ повышения этих самых soft skills. Сейчас работаю в отечественной компании, где наиболее продвинутое обучение сотрудников на локальном рынке. Хотя тоже на поток не поставлено.
При всем при этом в компании не было никаких программ повышения этих самых soft skills. Сейчас работаю в отечественной компании, где наиболее продвинутое обучение сотрудников на локальном рынке. Хотя тоже на поток не поставлено.
Вы не ответили на мой вопрос. Я вас не про таинственную таблицу спрашивал (но про которую обязательно, для повышения хабровского ЧСВ, нужно заметить, что «до вас такие вещи не доводили» :) ), а про ваши обязанности (если, конечно, вы работаете senior software engineer) — входит ли в них, официально или не официально требование «быть примером другим, проявлять наставничество» (например, ваш менеджер подошел и сказал вам: «Константин, ты поопекай да поучи наших джунов»).
Замечу, что мой опыт работы (за 25 лет только в Штатах) наверняка намного больше, чем ваш, и в крупных и очень крупных компаниях (в США) я работал в несколько раз чаще, чем вы (если очень интересно, могу в личке рассказать), но нигде и никогда никто не ставил задачи «опекать и учить джунов и/или интернов»!
Учатся здесь в колледжах и университетах, а в компаниях, обычно, занимаются бизнесом, работают. А позиции открываются под конкретный проект и конкретные задачи, а не «а не взять ли нам senior software engineer вообще, пусть наших джунов подучит», и уж что-что, а заниматься сеньору уж есть чем.
Еще замечу, что, во-первых, обычно уровень начинающих разработчиков, с которыми мне приходилось сталкиваться, довольно высок (даже студентов-интернов), а во-вторых, никогда я не видел отношения к ним, как к «джунам», что описывают некоторые тут. Наоборот, обычно менеджмент (team lead или project manager) всегда неоднократно подчеркивает, что «все мы — команда высококлассных экспертов», хотя на деле это далеко не так. В-третьих, западные молодые люди очень не любят непрошеных «учителей» (коими, как я по топику заметил, любят быть выходцы из России или россияне), чувство собственного достоинства и независимости в людях очень сильно развито, и при подобном отношении «морду лица» вам бить не будут, конечно (не тот менталитет и воспитание), но вот менеджеру обязательно пожалуются, хотя могут даже и публично, на митинге. «Наставнику» будет очень стыдно в этом случае.
Учатся же на работе люди сами: реализовывая задачи и проекты от простых к сложным, учась работать над code review (по обе стороны — ведь ревьювить код от гуру не менее поучительно, чем выслушать его замечания касательно собственного кода), во многих крупных компаниях существуют программы по повышению образования и квалификации, так что желающий может за корпоративный счет пройти курсы, получить сертификаты, поучаствовать в семинарах и «хакатонах», или даже вообще, выучиться на MBA (но это уже не для программистов). Было бы желание, как говорится.
Но, подчеркну, нигде и никогда я не встречался с официальными или неофициальными требованиями (цитирую) «ты должен быть примером другим, проявлять некоторое наставничество»!
Замечу, что мой опыт работы (за 25 лет только в Штатах) наверняка намного больше, чем ваш, и в крупных и очень крупных компаниях (в США) я работал в несколько раз чаще, чем вы (если очень интересно, могу в личке рассказать), но нигде и никогда никто не ставил задачи «опекать и учить джунов и/или интернов»!
Учатся здесь в колледжах и университетах, а в компаниях, обычно, занимаются бизнесом, работают. А позиции открываются под конкретный проект и конкретные задачи, а не «а не взять ли нам senior software engineer вообще, пусть наших джунов подучит», и уж что-что, а заниматься сеньору уж есть чем.
Еще замечу, что, во-первых, обычно уровень начинающих разработчиков, с которыми мне приходилось сталкиваться, довольно высок (даже студентов-интернов), а во-вторых, никогда я не видел отношения к ним, как к «джунам», что описывают некоторые тут. Наоборот, обычно менеджмент (team lead или project manager) всегда неоднократно подчеркивает, что «все мы — команда высококлассных экспертов», хотя на деле это далеко не так. В-третьих, западные молодые люди очень не любят непрошеных «учителей» (коими, как я по топику заметил, любят быть выходцы из России или россияне), чувство собственного достоинства и независимости в людях очень сильно развито, и при подобном отношении «морду лица» вам бить не будут, конечно (не тот менталитет и воспитание), но вот менеджеру обязательно пожалуются, хотя могут даже и публично, на митинге. «Наставнику» будет очень стыдно в этом случае.
Учатся же на работе люди сами: реализовывая задачи и проекты от простых к сложным, учась работать над code review (по обе стороны — ведь ревьювить код от гуру не менее поучительно, чем выслушать его замечания касательно собственного кода), во многих крупных компаниях существуют программы по повышению образования и квалификации, так что желающий может за корпоративный счет пройти курсы, получить сертификаты, поучаствовать в семинарах и «хакатонах», или даже вообще, выучиться на MBA (но это уже не для программистов). Было бы желание, как говорится.
Но, подчеркну, нигде и никогда я не встречался с официальными или неофициальными требованиями (цитирую) «ты должен быть примером другим, проявлять некоторое наставничество»!
Упоминание таблицы было не для ЧСВ, оно и было ответом на ваш вопрос, который вы проигнорировали. Да, это совершенно точно было требованием, черным по белому прописанным в списке компетенций по моей позиции. И это было не официально, так как (я уже сказал и вы снова на ЧСВ приписали) это вообще странным образом доводилось до сотрудников.
Возможно, разница в вашем восприятии связана с тем, что вы работаете в американских компаниях, как я понял, в самой Америке? Я то работаю исключительно в России. Тут есть, знаете ли, некоторый дефицит с высококлассными экспертами, уж очень велик спрос и миграция. Ну а про непрошенность — я вроде вполне немало обернул тему наставничества разными условиями, что бы стало понятно, что речь не идет о том что бы лезть и тыкать человека носом в его ошибки. Но смысл — вы же все проигнорировали, да?
Возможно, разница в вашем восприятии связана с тем, что вы работаете в американских компаниях, как я понял, в самой Америке? Я то работаю исключительно в России. Тут есть, знаете ли, некоторый дефицит с высококлассными экспертами, уж очень велик спрос и миграция. Ну а про непрошенность — я вроде вполне немало обернул тему наставничества разными условиями, что бы стало понятно, что речь не идет о том что бы лезть и тыкать человека носом в его ошибки. Но смысл — вы же все проигнорировали, да?
Каким «ответом»? Перестаньте отвечать на выдуманные вами же вопросы, и ответьте прямо на мой: кто и когда потребовал от вас «ты должен быть примером другим, проявлять некоторое наставничество»? Ваш менеджер, таинственная таблица, должностные инструкции, памятка сотрудника (employee handbook)?
Я то работаю исключительно в России.Вот это, скорее всего, и является ответом — да, похоже, это чисто российская специфика плюс менталитет «страны советов».
Особенно занятен металитет страны советов у американского руководства в американских компаниях, да.
Вопрос был — входило или нет, я на него более чем подробно ответил.
Если уж теперь вы спрашиваете кто — непосредственный руководитель. Как на собеседовании так и в процессе работы. При том это было не в одной компании. Звучит это обычно приблизительно так: «Ищем сильного разработчика. У нас есть хорошая команда, ребята молодцы, но все мидлы, нужен кто-то опытный что бы за ними присмотрел». Формулировка от компании к компании отличается в соответствии с реальными обстоятельствами, но смысл остается.
Таблица компетенции — это спускалось уже из головного офиса в силиконовой долине. Бывало как-то даже HR при найме указывал как рекомендацию по конкретному сотруднику при его найме, в устной форме. Не знаю, может и записывали это куда, у меня к их делам не было доступа.
Так вполне конкретно?
Вопрос был — входило или нет, я на него более чем подробно ответил.
Если уж теперь вы спрашиваете кто — непосредственный руководитель. Как на собеседовании так и в процессе работы. При том это было не в одной компании. Звучит это обычно приблизительно так: «Ищем сильного разработчика. У нас есть хорошая команда, ребята молодцы, но все мидлы, нужен кто-то опытный что бы за ними присмотрел». Формулировка от компании к компании отличается в соответствии с реальными обстоятельствами, но смысл остается.
Таблица компетенции — это спускалось уже из головного офиса в силиконовой долине. Бывало как-то даже HR при найме указывал как рекомендацию по конкретному сотруднику при его найме, в устной форме. Не знаю, может и записывали это куда, у меня к их делам не было доступа.
Так вполне конкретно?
Нет у американского руководства американских компаний подобного совкового менталитета, я тут это твержу уже 100500 раз! Не требуют тут «воспитательства», «обучательства», «присмотрения» — лишено всяческого смысла, и бизнес-перспектив.
Ну, и про пресловутую «таблицу» (которая, судя по приведенному маразму «миддл владеет одним фреймворком, а сениор несколькими» существует только в вашем воображении — в жизни не поверю, чтобы вменяемый человек с нормальным умом и здравой памятью мог подобное сочинить!) и ЧСВ, процитирую:
Если уж теперь вы спрашиваете ктоС чего это вы решили? Я спрашиваю то, что спрашивал с самого начала. На мой вопрос можно ответить либо «да», либо «нет». У вас проблемы с пониманием?
Ну, и про пресловутую «таблицу» (которая, судя по приведенному маразму «миддл владеет одним фреймворком, а сениор несколькими» существует только в вашем воображении — в жизни не поверю, чтобы вменяемый человек с нормальным умом и здравой памятью мог подобное сочинить!) и ЧСВ, процитирую:
К слову, что забавно, таблицу эту почему то рядовым сотрудникам не показывают, и доступна она была только директорам департаментов, которые непосредственно участвуют в повышениях, тимлидам только по секрету. Так что не исключено что до вас такие вещи просто не доводили.— не нужно быть дипломированным психологом, чтобы понять, для чего написана эта фраза :) И, кстати, только одной это фразой вы раскрылись полностью — ну, да Бог вам судья…
Вы все-таки ответьте на исходный вопрос. Если к концу недели вы скажете, что не решили ни одной задачи, т.к. занимались «менторством», то это будет ок? К вам не будет предъявлено каких-либо претензий?
Будет точно также, как если вы выберите любую другую не приоритетную задачу и будете заниматься ей одной, а все остальное будете игнорировать — определенно не ок. Хотя, если у вас вдруг, по какой то причине выдалась неделя без работы (а такого там не бывало), то это не было бы проблемой. Да и не очень понятно, как вы собрались тратить на менторство целую неделю? Ментор — не тренер, и не учитель, это не отнимает много времени.
Я не помню, сколько точно отводилось времени, но вроде что-то около 10% в месяц, и оно включало в себя некоторую организационную беготню вроде сдачи месячной отчетности, встреч один на один и плановых ревью (например испытательного срока). Этого было вполне достаточно.
В той компании где я работаю сейчас, есть такое понятие как idle, состояние между проектами. В него тебя привлекают либо к внутренним проектам компании, либо ты тратишь его на обучение. Период может составлять несколько недель. Менторство идет фоном, по аналогичной схеме, но без формализации. Вроде за него, я слышал, даже доплачивают, но я пока еще не вписался. На нашем проекте что-то забуксовало.
Я не помню, сколько точно отводилось времени, но вроде что-то около 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; я бы сказал, что неизмеримо выше. И, по американски, хорошая команда — это команда равных, когда никто не чувствует себя «лузером джуном» и «супер-дупер гуру сеньором»! Надо сказать, что мне доводилось встречать кьюкамеров, мальчиков из России, мнивших себя супер-экспертами, и соответственно ведших себя в команде. Что можно сказать? Наиболее умные из них быстро понимали, насколько они не правы, и принимали новые правила игры. Менее умные вскоре теряли работу.
Отвечая на ваш первый вопрос, скажу: «сеньора», то бишь опытного программиста, берут не для «опекания и наставления джунов», а для решения вполне конкретных задач в текущем проекте/проектах. Если таких задач нет, или бюджет не позволяет — то не берут :) Джунов, как таковых, тоже просто так не берут (да и словосочетания такого, «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 review — это научить того кто писал код так больше не писать =)
Это как раз тоже часть обучения через пример. У него в этот момент могут возникнуть вопросы на которые опытный должен ответить. И иногда не понятно где кончается code review и начинается обучение. И это как бы все времени требует. Можно конечно это все засунуть в рамки code review но смысл то тот же — время будет потрачено на обучение.
Т.е. ситуации «джун не справился с задачей» практически никогда не возникает. «Говнокод с ошибками» отлавливается на этапе 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.
- Не я писал про США. В РФ есть испытательный срок.
- 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. Видимо «США разные», как и «РФ большая и разная».
А раз есть «средняя» позиция, то есть и младшая/старшая — все вполне логично.
Европейские конторы (что в 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.
Все зависит от конторы и предполагаемой ЗП.
Поэтому публикуются 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
К сожалению у меня нет «россиянского опыта работы», и работаю я не в местечковой компании, а вполне себе европейской.
Попробую «погуглить». Правда в офисе гугла в Mountain Views я был много лет назад, но слово junior там все еще использовалось.
Ну а так, первые попавшиеся ссылки:
www.ziprecruiter.com/Jobs/Junior-Software-Engineer/--in-California
www.linkedin.com/jobs/junior-software-developer-jobs-california
А работать в России в местечковой компании это позор?
Цитата из приведенной ссылки на википедию:
Как вы собираетесь выполнить эту задачу без обучения? На каждую найденную вами ошибку джун сделает новых таких же три если вы ему не объясните в чем он ошибся и почему так делать не хорошо. Ваше code review превратиться в день сурка. Вы меня отправляете мат. часть учить, а я вас отправлю поработать с джунами (особенно когда их более одного на проекте).
Вот это вот вообще странная логика — т е у вас либо джун не ошибается, но тогда почему он джун до сих пор? Либо вы предлагаете его увольнять (ну поскольку у сеньора таких полномочий нет, то свалить эту ответственность на менеджера или еще кого) Вот только тогда зачем его было вообще брать — потому как известно что это человек без опыта и возможно без части необходимых знаний. Т е само по себе его наличие на проекте предполагает, что его кто то должен менторить раз его взяли. Кто если не опытный разработчик?
Вы хотите сказать, что если у вас плохое настроение то разъяснений по code review джун может и не получить. Как следствие он налажает и вы же потом на него донесете начальству что он не справился — что ж удобная позиция =)
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 не там у меня и т.п. Может инфа об этом в инете всё есть? Ну конечно нет! Большинство примеров, по которым учился уж точно хуже моего кода.
Может инфа об этом в инете всё есть? Ну конечно нет!
Как это нет? Да здесь хотя бы на Хабре поищите. Насчет того что
классы не так назвал, SQL не там у менято о таких вакансиях жалеть не стоит. По моему не очень адекватные работодатели, намучаетесь с ними. И вакансия то скорее всего от того что люди бегут от неадекватов. В ответ можете заспамить их вопросами и просьбами рассказать о их требованиях. Это опыт, хоть и негативный, но хоть немного но поможет вам в профессиональном росте.
Здесь хотя бы мне отписался человек, который смотрел моё задание. Обычно приходится иметь дело с рекрутерами, которые ничего не могут объяснить. Так что даже приятно было читать такой ответ (хоть и с отказом) после пары общений с рекрутерами.
то о таких вакансиях жалеть не стоит. По моему не очень адекватные работодатели, намучаетесь с ними.
ну вот я бы не был так категоричен — некоторые настолько мастерски называет классы, что просто печаль-печаль.
@VVS_AM а можете пример своего кода показать (например на гитхаб скинуть)?
Присоединяюсь к запросу webkumo — киньте линк на репо, я так же java-dev. Любопытно глянуть за что вас так мучить могли.
ну не совсем в плане сел почитал и ты уже сеньор
народу много, требования выше, плюс всем нужен реальный большой опыт даже на старте а где его получить не учат
да, есть куча статей, самоучителей, литературы, форумов но не всегда понятно как двигаться, с чего начать, что нужно сейчас а что можно потом понять
если раньше умеешь склепать поле ввода и кнопку ОК то ты уже джуниор фронтенд то теперь надо уже достаточно хорошо знать один из модных фреймворков и помимо него еще пару тройку инструментов так что современного джуниора пропорционально сложнее получить из анона количеству доступной информации для обучения
народу много, требования выше, плюс всем нужен реальный большой опыт даже на старте а где его получить не учат
да, есть куча статей, самоучителей, литературы, форумов но не всегда понятно как двигаться, с чего начать, что нужно сейчас а что можно потом понять
если раньше умеешь склепать поле ввода и кнопку ОК то ты уже джуниор фронтенд то теперь надо уже достаточно хорошо знать один из модных фреймворков и помимо него еще пару тройку инструментов так что современного джуниора пропорционально сложнее получить из анона количеству доступной информации для обучения
Думаю ниже описали эти два пункта, но я отпишусь. Сейчас много всего доступно из-за интернета. Но:
1) Фильтрация информации. Так как опыта, допустим, нет, то почти любая информация воспринимается как адекватный совет, который можно попробовать, а вариантов много, но объяснить разумность одного против другого ни кто не сможет\не захочет. Уже потом, когда начинают всплывать проблемы, становится ясно. В итоге метод тыка как был, так и остался;
2)Рост требований в IT индустрии, не только программирования. Причем рост значительный и при самообразовании не известно как развиваться и в каком направлении (сам сейчас на этом этапе).
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 или любого другого. Не важно. Главное представление как там на самом деле все работает.
Я не предлагал нигде требовать с каждого ассемблер.
Как, например, с инженера-электроника не требуют на работе отчета по знаниям физики или высшей математики. Хотя ведь в вузе он это точно изучал. Достаточно знать что эти знания он освоил о чем и говорит диплом.
ему будет полезно знать маркетинговые/торговые нюансы из предметной области.
…
неплохо чтобы он хоть немножко ориентировался в языке/методиках обучения.
Вот не согласен. Возможны варианты. Если в команде есть грамотный маркетолог или спец по обучению то программисту знания в нюансах сами по себе не нужны. Т.е. они появятся просто потому что он в этом вынужден вариться, но требуют их от него в последнюю очередь.
Не видел вакансий фронтэнд программиста с требованием знания нюансов маркетинга. Если человек толковый то разберется. А если маленький стартап в котором кроме 2х-3х программистов и нет никого, то тут да — придется знать все.
Вы же предлагаете какие конкретно базовые знания ему?
Да хотя бы азы ассемблера x86 или любого другого. Не важно. Главное представление как там на самом деле все работает.
Я не предлагал нигде требовать с каждого ассемблер.
Как, например, с инженера-электроника не требуют на работе отчета по знаниям физики или высшей математики. Хотя ведь в вузе он это точно изучал. Достаточно знать что эти знания он освоил о чем и говорит диплом.
Не видел вакансий фронтэнд программиста с требованием знания нюансов маркетинга. Если человек толковый то разберется.
Ну вот вы сами себе и противоречие — широкий кругозор, выходит, не нужен?
Т.е. цифр у вас все таки нет и вы, как вы выражаетесь, слили.
Цифры я уже давно назвал: 1 из примерно 100 000 программистов нуждается в фундаментальных знаниях на уровне ассемблера.
Источник цифр — по вакансиям hh.ru
Например, тут удобно сведено habrahabr.ru/company/hh/blog/344724
Хм, один из ста тысяч, все таки мне кажется что в россии таких людей нужно больше чем 2-3
Ну вот вы сами себе и противоречие — широкий кругозор, выходит, не нужен?
Да какое же тут противоречие? Я же говорил о кругозоре в сфере ИТ, а маркетинг тут причем? Сегодня программист, по вашему примеру, кодит интернет магазин, а завтра онлайн иньяз-школу. Сегодня маркетинг, завтра иньяз, послезавтра опять маркетинг. Но все время все это делает на компьютере и никуда он от него не денется.
Я же говорил о кругозоре в сфере ИТ, а маркетинг тут причем?
Да, — в ИТ, согласен: CI/CD, НФ, ACID, REST и т.п.
Но при чем здесь ассемблер? Без этого нельзя просто знать, что интерпретируемые языки отличаются от компилируемых и что такое JIT?
Ну так они знают, что интерпретируемые языки отличаются от компилируемых, может быть.
Но это все что они знают и главное не стремятся знать больше.
Но это все что они знают и главное не стремятся знать больше.
> Чтобы пояснить мою точку зрения скажу, что считаю что программисту нужно знать ассемблер хотя бы на начальном уровне чтобы иметь представление как на самом деле оно работает и чего стоят для процессора
Вы сейчас говорите, не осознавая, о такой вещи как «уровень культуры». Вот культурный человек знает, что Париж — столица Франции, а Пушкин — русский поэт. Это бесполезное в жизни знание, человек, который данных фактов не знает — он не становится от этого плохим человеком и жить ему как-то труднее не станет. Но от культурного человека мы ждем такого знания.
Вот и здесь также — есть определенная культура программиста, которая предполагает наличие определенного массива знаний. Если программист этими знаниями не обладает — он не становится худшим программистом, чем тот, кто обладает. Возможно, он прекрасный специалист, который замечательно справляется со своими рабочими задачами, и вполне себе развивается в выбранном направлении. Но можно сказать, что он,… ммм… «некультурный программист». И все.
Вы сейчас говорите, не осознавая, о такой вещи как «уровень культуры». Вот культурный человек знает, что Париж — столица Франции, а Пушкин — русский поэт. Это бесполезное в жизни знание, человек, который данных фактов не знает — он не становится от этого плохим человеком и жить ему как-то труднее не станет. Но от культурного человека мы ждем такого знания.
Вот и здесь также — есть определенная культура программиста, которая предполагает наличие определенного массива знаний. Если программист этими знаниями не обладает — он не становится худшим программистом, чем тот, кто обладает. Возможно, он прекрасный специалист, который замечательно справляется со своими рабочими задачами, и вполне себе развивается в выбранном направлении. Но можно сказать, что он,… ммм… «некультурный программист». И все.
Если программист этими знаниями не обладает — он не становится худшим программистом, чем тот, кто обладает. Возможно, он прекрасный специалист, который замечательно справляется со своими рабочими задачами, и вполне себе развивается в выбранном направлении. Но можно сказать, что он,… ммм… «некультурный программист». И все.
Тут есть разные слои.
Ассемблер — не нужно на практике большинству. Никогда не увидят на работе.
Распределение памяти динамическое — желательно, но не обязательно.
Стек как работает при рекурсии — более желательно, все таки переполнения стека встречаются.
НФ, ACID — обязательно если у тебя хоть какие то БД есть в работе.
Так же как и с Пушкиным.
Нужно ли знать Велимира Хлебникова, одного из самых выдающихся поэтов эпохи русского авангарда?
А хотя бы парочку произведений более известных Александра Блока или Сергея Есенина, ну если не полностью, то хотя бы начало? Надо или нет?
Но можно сказать, что он,… ммм… «некультурный программист». И все
Да мне вообще наплевать «культурный» или «некультурный» программист. Мне главное чтобы дело свое любил. Чтобы глаза горели. Хотя, последнее совсем идеальный вариант.
> ассемблер это не язык, а мнемонические команды конкретного процессора, поэтому его нужно учить отдельно для каждого вида процессоров
Вообще, ассемблер — это транслятор из некоторого языка _на базе мнемоников_ в опкода. И чуть менее чем всегда язык ассемблер богаче мнемоников, например, именованных меток у процессора нет, а в ассемблере — есть.
А так все верно, конечно, для разных процессоров (архитектур, тем более) он существенно отличается.
Вообще, ассемблер — это транслятор из некоторого языка _на базе мнемоников_ в опкода. И чуть менее чем всегда язык ассемблер богаче мнемоников, например, именованных меток у процессора нет, а в ассемблере — есть.
А так все верно, конечно, для разных процессоров (архитектур, тем более) он существенно отличается.
Вообще, ассемблер — это транслятор из некоторого языка _на базе мнемоников_ в опкода. И чуть менее чем всегда язык ассемблер богаче мнемоников, например, именованных меток у процессора нет, а в ассемблере — есть.
Не придирайтесь.
Когда мы говорим о С, к примеру, то в общем подразумеваем — и язык С и компилятор для этого языка С вместе с линковщиком и стандартную библиотеку для этого языка С.
Давайте, я тоже придерусь: метки в процессорных кодах есть. Чем же по вашему являются абсолютные или относительные ссылки в каком нибудь jump/jmp? От того, что они записаны цифрами адреса, а не буквами названы они уже и не метки?
> От того, что они записаны цифрами адреса, а не буквами названы они уже и не метки?
Они отличаются на практике весьма и весьма, если вы код поменяете и он сместится, то именованные метки останутся как были рабочими, а смещения к чертям поедут. То есть у них _существенно_ разная семантика на самом деле, это не как соответствие «мнемоник — опкод», где действительно все один в один.
Они отличаются на практике весьма и весьма, если вы код поменяете и он сместится, то именованные метки останутся как были рабочими, а смещения к чертям поедут. То есть у них _существенно_ разная семантика на самом деле, это не как соответствие «мнемоник — опкод», где действительно все один в один.
Может Вася немного и отстанет на начальном этапе от торопыги и рвача Пети, но потом по любому обгонит просто благодаря широте взглядов.
Как программист со стажем больше чем лет нашему веку скажу вам, — это не так. Главное для программиста — навыки сугубо его ИТ-шные, и именно в той отрасли, которой он занимается. Крайне полезно ориентироваться в терминах автоматизируемой вами области. И — только.
Есть только небольшое число исключений — какие-нибудь исследовательские задачи типа распознавания речи и т.п, чем занимаются меньше 1% программистов.
По моему это примерно как человек который живет на берегу океана, но все время только плавает и рыбачит вдоль берега на лодочке.
Можно его сравнивать с моряком который ходит в дальние плавания?
Как бы он тоже, конечно, морячек. У него тоже много трудностей и свой профессиональный опыт, но, все таки, настоящие моряки там.
Конечно не все так могут, не вех пускают, не все могут стать капитанами, но стремиться то надо, я считаю.
Можно его сравнивать с моряком который ходит в дальние плавания?
Как бы он тоже, конечно, морячек. У него тоже много трудностей и свой профессиональный опыт, но, все таки, настоящие моряки там.
Конечно не все так могут, не вех пускают, не все могут стать капитанами, но стремиться то надо, я считаю.
> Как бы он тоже, конечно, морячек. У него тоже много трудностей и свой профессиональный опыт, но, все таки, настоящие моряки там.
Если работа заключается именно в том, чтобы ловить рыбу удочкой, то чем поможет опыт хождения в дальние плавания?
Если работа заключается именно в том, чтобы ловить рыбу удочкой, то чем поможет опыт хождения в дальние плавания?
Сидеть на берегу Океана и быть довольным только тем что рыбачишь удочкой как в каком то пруду.
Даже не мечтать о большем?
Боюсь мы с вами друг друга не поймем.
Даже не мечтать о большем?
Боюсь мы с вами друг друга не поймем.
А вы не думали, что, быть может, этот сидящий на берегу человек всем доволен, а «настоящих моряков» (по-вашему) считает дураками и быдлом, которое в море ходит исключительно от того, что не может удочкой нормально ловить?
Да пусть считает, мне не жалко, каждый имеет право на свое мнение.
Только с ним я не согласен и считаю что если таких удильщиков большинство то это очень плохо.
Потому что чтобы человек делал свое дело хорошо то он должен любить это дело. А если он свое дело любит то стремится разобраться до самой сути.
Только с ним я не согласен и считаю что если таких удильщиков большинство то это очень плохо.
Потому что чтобы человек делал свое дело хорошо то он должен любить это дело. А если он свое дело любит то стремится разобраться до самой сути.
Крайне полезно ориентироваться в терминах автоматизируемой вами области. И — только.
И не суметь перейти в другую область. Отличный совет (серьёзно), нужно меньше конкуренции.
то чем поможет опыт хождения в дальние плавания?
Тем, что отсутствие рыбы рядом не оставит голодным?
Только потом открывается новое направление, а фреймворк X выходит в версии 2.0 и поскольку его любимый Петей автор мыслил как он — совсем не совместим с X1.0 и знания Пети отправляются в /dev/null (о котором он даже не знает), а направление идёт осваивать Вася, который на основе полученной базы легко освоит X, X2.0, Y и Z.
Неправда ваша. У Пети будут общие знания о веб-разработке (HTML там, CSS — а может быть даже JS!) и запас времени (фреймворки мгновенно не устаревают!), а у Васи будет знание как нарисовать квадрат на ассемблере.
Не следует путать низкоуровневое программирование с общими знаниями по программированию. Низкоуровневое программирование — это одна из узких специализаций.
Не следует путать низкоуровневое программирование с общими знаниями по программированию. Низкоуровневое программирование — это одна из узких специализаций.
В вашем примере у участников слишком разые интеллектуальные возможности — рисовать квадрат на ассемблере можно за время изучения пары функций фреймворка, ещё за пару функций можно понять почему он так рисуется, а фреймворки устаревают просто — «новый проект начинаем на новом» и без понимания как оно внутри оно не сработает. Да откуда там знания HTML/CSS? Вот откуда у Васи понимания работы ПО внутри — понятно.
Но старые-то проекты никуда не деваются, и с них можно еще долго кормиться.
Да откуда там знания HTML/CSS?
А как без них хоть что-то сделать даже на самом совершенном фреймворке?
> В вашем примере у участников слишком разые интеллектуальные возможности — рисовать квадрат на ассемблере можно за время изучения пары функций фреймворка, ещё за пару функций можно понять почему он так рисуется
Да вы что, правда что ли? Сразу видно, что вы на ассемблере квадрат нарисовать не пытались. Ну или может пытались, сами, уже имея базу. Но не пытались объяснить, как это сделать, кому-то другому.
> Да откуда там знания HTML/CSS?
Потому что написать тудулист даже на самом супер-дупер фреймворке без знания цсс/хтмл невозможно. На самом деле практика современного веба такова, что написать тудулист при помощи фреймворка _сложнее_, чем без него, и требует более высокой квалификации.
Да вы что, правда что ли? Сразу видно, что вы на ассемблере квадрат нарисовать не пытались. Ну или может пытались, сами, уже имея базу. Но не пытались объяснить, как это сделать, кому-то другому.
> Да откуда там знания HTML/CSS?
Потому что написать тудулист даже на самом супер-дупер фреймворке без знания цсс/хтмл невозможно. На самом деле практика современного веба такова, что написать тудулист при помощи фреймворка _сложнее_, чем без него, и требует более высокой квалификации.
> Да вы что, правда что ли?
Абсолютная. Базовый адрес в видеопамяти в один регистр, длину в другой, цикл по длине (dec + jnz или аналог) с приращением адреса и записью цвета по адресу. Я это делал ещё в те времена, когда другого способа не было. Это горизонтальная линии. С вертикальной чуть хуже — надо не inc, а add ширины экрана.
Абсолютная. Базовый адрес в видеопамяти в один регистр, длину в другой, цикл по длине (dec + jnz или аналог) с приращением адреса и записью цвета по адресу. Я это делал ещё в те времена, когда другого способа не было. Это горизонтальная линии. С вертикальной чуть хуже — надо не inc, а add ширины экрана.
А теперь повторите это в более современных ОС.
В современных ещё проще — рисование примитива есть в графической библиотеке, нужно заполнить структуру и вызвать функцию.
Druu — и бонусом будет понимание «как оно работает», в отличии от простого юзания фреймворка.
Druu — и бонусом будет понимание «как оно работает», в отличии от простого юзания фреймворка.
> Базовый адрес в видеопамяти в один регистр
Воу-воу-воу, полегче! Вы осознаете, что для понимания этой фразы требуется несколько полуторачасовых лекций?
Воу-воу-воу, полегче! Вы осознаете, что для понимания этой фразы требуется несколько полуторачасовых лекций?
Тоесть вы прямым текстом говорите: «Мне было сложно и я справился, значит ничего менять не надо, жрите кактус» Это явно старческое.
Кроме того, интернет не дает в отметок в трудовой книжке об опыте работы. Не говоря уже о фактическом опыте решения реальных задач, а не примеров из книжек.
Кроме того, интернет не дает в отметок в трудовой книжке об опыте работы. Не говоря уже о фактическом опыте решения реальных задач, а не примеров из книжек.
«Мне было сложно, пусть и вам так же будет.»
Что то у вас с логикой совсем плохо. Где я это сказал?
Наоборот, я просто по доброму завидую возможностям современных начинающих программистов которые им дает современный интернет. И не понимаю жалобы некоторых, мол не дают возможностей. Возможностей у них на порядки больше чем было у нас в свое время.
интернет не дает в отметок в трудовой книжке об опыте работы
Опять не верно. Например участие в опенсорс проектах во для многих вакансий будет плюсом и специально просят указать ссылку на проекты в гитхаб.
И не понимаю жалобы некоторых, мол не дают возможностей.
Выше вам ответили и про поиск крупиц в море возможностей. И про сложность технологий. И про завышенные требования. Вы просто не пробовали учиться сейчас. Складывать 1+1 на бейсике работодатель уже не требует.
Вы просто не пробовали учиться сейчас
Вы наверно не поверите, я и сейчас учусь. И буду учится.
Просто мне нравится этим заниматься, а что требует работодатель мне до фонаря.
Если не можете определится что вам нравится, а ждете требований от работодателя то может это на самом деле на ваше?
Учусь с 13 года (в 12-м появился первый комп с 3g модемом (по факту edge), но просто базовые навыки поначалу поднимал вроде скорости печати, настройки минимально и т.п.), в 14 устроился стажером, пусть и 1с, но тем не менее продолжаю параллельно изучать программирование (общие концепции, парадигмы, и т.п.). И я только рад широте выбора.
При нынешнем экспоненциально растущем объеме информации, а с ней и количества фреймворков, библиотек и контейнеров, что равно технологиям — порог входа в профессию достаточно высок, в связи с чем увеличивается объем информационного шума, в котором достаточно не просто отфильтровать нужное. Выбора много — глаза разбегаются и поэтому «стоит только захотеть», прерывается не успев начаться, оставив после себя лишь «влажные мечты».
Поэтому ваш старт, считаю только положительной стороной.
имхо конечно.
Поэтому ваш старт, считаю только положительной стороной.
имхо конечно.
Джуниором легче найти работу по не мейнстримным технологиям. У нас, например, долго не хватало Scala-программиста и мы готовы были взять джуниора.
В некоторых областях нынче очень не хватает джуниоров просто потому, что порог входа высоковат. Та же разработка прошивок, тут тебе и ассемблер с чистым С, и голое железо, и EFI с Linux на миллион строк кода каждая, и прочее вот такое. При этом простых IDE и утилит из разряда «нажми на кнопку — получишь результат» там не было, нет и не будет, наверное, лет 50 еще.
В итоге джуниором туда идут только самые стойкие оловянные солдатики, с которыми потом и работаем. И это все при том, что тут достаточно обычного компьютера для старта.
В итоге джуниором туда идут только самые стойкие оловянные солдатики, с которыми потом и работаем. И это все при том, что тут достаточно обычного компьютера для старта.
Ну, похоже что изменилась терминология.
Если раньше джун — это энтузиаст с горящими глазами. уже освоивший что-то по книгам, написавший несколько минимальных приложений по своим хотелкам, готовый учиться и впитывать…
ТО сейчас, это человек, который закончил профильное заведение не особо заморачиваясь с изучением и хочет найти работу, не особо понимая что на ней придется делать.
Если раньше джун — это энтузиаст с горящими глазами. уже освоивший что-то по книгам, написавший несколько минимальных приложений по своим хотелкам, готовый учиться и впитывать…
ТО сейчас, это человек, который закончил профильное заведение не особо заморачиваясь с изучением и хочет найти работу, не особо понимая что на ней придется делать.
имхо, если определять термины именно таким образом, то хороший джун — один на миллион уже исходя из термина.
Скажите, пожалуйста, ваше мнение, если придет джун-энтузиаст с горящими глазами, без профильного образования, у него есть шансы?
Порог входа намного ниже, чем раньше — это с какой стороны посмотреть.
Да, высокоуровневые языки легче учить, нахвататься основ можно быстро. Но и требования выросли, на Hello World'е сейчас не уедешь.
Порог входа намного ниже, чем раньше — это с какой стороны посмотреть.
Да, высокоуровневые языки легче учить, нахвататься основ можно быстро. Но и требования выросли, на Hello World'е сейчас не уедешь.
Не согласен, ваканисий по Embedded в целом мало, а для джунов еще меньше.
Сам ищу первую работу и вижу что всем нужны сеньоры или 3+ года опыта. По сравнению с другими областями (например JS) то там хоть больше вакансий есть в том числе и для джунов.
Сам ищу первую работу и вижу что всем нужны сеньоры или 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-технологий ещё только в самом начале пути. Страшно представить, что творится в голове у мидлов, не говоря уж о сеньорах.
Например, «Необходимо реализовать Web приложение простого интернет-магазина.» В результате, нужно владеть Java Core, Hibernate, JSP/JSF, JSTL, Servlets, JUnit, разбираться в Tomcat, Maven, Git.
Или вот «Напишите приложение (портлет) для портала на платформе Liferay, собирающий вакансии с портала %sitename%».
То есть по факту нужно ознакомиться с неслабым стеком Enterprise-технологий ещё только в самом начале пути. Страшно представить, что творится в голове у мидлов, не говоря уж о сеньорах.
Например, «Необходимо реализовать Web приложение простого интернет-магазина.»
Да пожалуйста
github.com/manuelkiessling/go-cleanarchitecture/tree/master/src
4 небольших файла.
Если вам дают такие задания перед собеседованием, бежать от таких работодателей надо.
Ничего сложного в этом нет, никто не требует от джуна быть великим специалистом в соответствующих технологиях. У нас джунам при устройстве дают пару недель на тестовое задание со спрингом, хибернейтом и пр., чтобы посмотреть насколько человек способен искать и находить информацию, и какая помощь ему будет нужна в дальнейшем для развития.
Java Core, Hibernate, JSP/JSF, JSTL, Servlets, JUnit, разбираться в Tomcat, Maven, Git.
Ничего сложного в этом нет, никто не требует от джуна быть великим специалистом в соответствующих технологиях. У нас джунам при устройстве дают пару недель на тестовое задание со спрингом, хибернейтом и пр., чтобы посмотреть насколько человек способен искать и находить информацию, и какая помощь ему будет нужна в дальнейшем для развития.
Простите, а зачем НФ среднему джуну? НФ же на практике не используется — она больше заморочка DBA.
НФ же на практике не используется
Где? С каких пор?
Это что-то новенькое! Вы точно ничего не путаете?
Может я чего и путаю — за давностью лет, мог перепутать НФ с прочими формами, благо я ни разу не DBA и разработка структуры БД не моя зона ответственности. Вот только если я правильно помню, что нам говорили в университете — НФ хреновато ложится/ложилась на реляционные БД.
Рекомендую вам остановиться и прочитать классическое "Введение в базы данных" Криса Дейта.
Я каждого своего джуна заставляю учить нормальные формы до НФБК, и регулярно, например в курилке или на обеде, терроризирую их спонтанными вопросами-примерами вроде "у тебя есть такая задача, расскажи как ты будешь делать базу..."
Потому что помимо прикладного навыка, это ещё и абстракция инженерного мышления.
Джуны не будут расти, если их не грузить такими вещами. Ну за редким исключением, но такие исключения недолго сидят в джунах))
Использование нормальных форм удобно, когда надо спроектировать готовую статичную базу с нуля. Если же бд приходится постоянно дорабатывать — сохранение нормальности сильно усложняет процесс, т.к. часто требует достаточно глубоко изменять структуру базы, в то время как при отказе от нормальности достаточно добавить одно поле в таблицу. Ну и это не говоря о вопросах производительности, когда то же дублирование данных просто необходимо.
Так что нормальные формы — это что-то вроде заготовки бд, которые еще, в реальности, надо будет доработать напильником.
Так что нормальные формы — это что-то вроде заготовки бд, которые еще, в реальности, надо будет доработать напильником.
А без сохранения нормальности надо переписывать весь DAL чтобы он правильно со всей этой хренью работал. Тоже ничего хорошего.
К счастью, в большинстве случаев можно добавить всего одно поле в базу сохранив «нормальность».
К счастью, в большинстве случаев можно добавить всего одно поле в базу сохранив «нормальность».
> А без сохранения нормальности надо переписывать весь 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НФ. Разобьете на два — надо будет делать джоин по составному ключу, при этом декомпозиция отношения будет еще и бессмысленна с точки зрения предметной области, т.к. отношения с набором атрибутов А просто не будет описывать какую-либо понятную сущность.
Сам факт декомпозиции, к слову, приводит к появлению огромной кучи лишних джоинов, которые и сами по себе не бесплатны.
А вот если, предположим, у вас отношение, для которого есть некоторый набор атрибутов А, по этим атрибутам вычисляется некоторое значение. Вычисляется долго и сложно. Чтобы не вычислять каждый раз — вы можете вычислять заранее, при записи в таблицу, это сразу нарушит 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. На начальных стадиях проектов схемой БД частенько управляет 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 — и количество запросов к базе со временем становится просто убийственным))
Может я чего и путаю — за давностью лет, мог перепутать НФ с прочими формами, благо я ни разу не DBA и разработка структуры БД не моя зона ответственности. Вот только если я правильно помню, что нам говорили в университете — НФ хреновато ложится/ложилась на реляционные БД.
Возможно, что в очень крупных организациях и не подкускают разработчиков к БД и занимаются всем DBA.
Но в большинстве случаев разработчики сами непосредственно работают с схемами БД. Это сейчас базовая грамотность. И НФ в том числе.
Лол, продолжай)) Я заинтригован)))
Если прямо сейчас меня бы спросили про НФ, смог бы только сказать, что в универе вроде 4 НФ рассматривали, и на пальцах объяснить, что если у нас таблица [имя, город, страна], то что бы привести в НФ(1?) создаем [имя, город] [город, страна]. Предположим я собеседуюсь на должность не связанную напрямую с БД. Меня завернут с таким ответом или есть шансы?
Сейчас в универе учусь, интересно, что думают люди из индустрии.
Сейчас в универе учусь, интересно, что думают люди из индустрии.
Зависит от работы, на которую Вы хотите попасть. Если менеджер проектов, то наверное не завернут.
Смотря что за должность. Как я уже писал выше — для фронтенда или девопса это не критично. Но если это бэкенд, то незнание СУБД нужно оправдывать чем-то очень весомым в плане специализации — например «Я сетевой программист и сделаю вам такие сокеты, что синхронизация распределенных по разным ЦОД реалтайм-сервисам будет летать за наносекунды».
Но при этом если вашим конкурентом на должность будет равный вам специалист, который четко ответит что 1НФ это «Атомарность», и означает что каждый кортеж отношения содержит только одно значение для каждого из атрибутов, и нарисует табличку-пример — будьте уверены, возьмут его. Потому что он может оптимизировать сетевое взаимодействие зная как определить, что в лаге виноват косяк в базе сервиса, а не сокет.
Тем не менее, изучить все времени не хватает ни у кого)) Поэтому я рекомендую вам пораньше начинать вливаться в ту сферу и должность, на которой вы хотите работать. Искать инфу, ходить по мероприятиям, докапываться до всех с вопросами.
Вам нужно определить круг критичных для этой работы навыков, без которых у вас просто нет шансов. И круг вторичных навыков — которые повышают вашу конкурентоспособность. Расставить приоритеты и учиться, а если сможете — пробовать делать то, чем собираетесь заниматься.
Идете в бэкенд — пишите сервисы для себя. Идете в РП — пишите бизнес-планы для себя. Идете в SEO — пишите планы продвижения для себя. Идете в маркетинг — пишите рыночные исследования для себя.
Если вы не сможете делать это для себя, не сможете и для кого-то. И в этом нет ничего плохого, просто значит вам это не очень интересно. И это лучше узнать на берегу, чтобы потом не пополнить ряды тех кто ноет что им не нравится их работа.
А если сможете — шикарно, поскольку у вас начнет формирования понимание разницы между учебой и реальностью. Плюс, вы сможете прямо на первое же собеседование принести тучу своих тренировочных примеров. Профит +)))
Но при этом если вашим конкурентом на должность будет равный вам специалист, который четко ответит что 1НФ это «Атомарность», и означает что каждый кортеж отношения содержит только одно значение для каждого из атрибутов, и нарисует табличку-пример — будьте уверены, возьмут его. Потому что он может оптимизировать сетевое взаимодействие зная как определить, что в лаге виноват косяк в базе сервиса, а не сокет.
Тем не менее, изучить все времени не хватает ни у кого)) Поэтому я рекомендую вам пораньше начинать вливаться в ту сферу и должность, на которой вы хотите работать. Искать инфу, ходить по мероприятиям, докапываться до всех с вопросами.
Вам нужно определить круг критичных для этой работы навыков, без которых у вас просто нет шансов. И круг вторичных навыков — которые повышают вашу конкурентоспособность. Расставить приоритеты и учиться, а если сможете — пробовать делать то, чем собираетесь заниматься.
Идете в бэкенд — пишите сервисы для себя. Идете в РП — пишите бизнес-планы для себя. Идете в SEO — пишите планы продвижения для себя. Идете в маркетинг — пишите рыночные исследования для себя.
Если вы не сможете делать это для себя, не сможете и для кого-то. И в этом нет ничего плохого, просто значит вам это не очень интересно. И это лучше узнать на берегу, чтобы потом не пополнить ряды тех кто ноет что им не нравится их работа.
А если сможете — шикарно, поскольку у вас начнет формирования понимание разницы между учебой и реальностью. Плюс, вы сможете прямо на первое же собеседование принести тучу своих тренировочных примеров. Профит +)))
Сейчас в универе учусь, интересно, что думают люди из индустрии.
Люди из индустрии думают, что хороший разработчик должен легко манипулировать как НФ, так и обратно. Частенько нужна и денормализация. Но в процессе обучения вопросы необходимости денормализации если и рассматривают, то вскользь.
И в результате наблюдаешь, как опытные, вроде бы, разработчики нормализуют все подряд, совершенно не думая, что где-то бы и не следует этого делать.
У меня одно из тестовых заданий для джунов — сделать простой иерархический каталог, чтобы он отображался в дерево на странице — а перейдя на один из его элементов, вывести хлебные крошки к корню. Там кода на полтора экрана, но только 1 из 10 кандидатов знает про MPTT (это к слову о денормализации) и даже этому кандидату (если я его беру) приходится объяснять что он и вывод, и операции благодаря этому может осуществлять над линейным списком за 1 проход, а не рекурсивно.
Меня это удивляло ровно до того момента, пока я не узнал что преподаватели в самых разных ВУЗах тоже про MPTT ничего не знают… все это очень печально(((
Меня это удивляло ровно до того момента, пока я не узнал что преподаватели в самых разных ВУЗах тоже про 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 и сделал с ним тестовый пример — он мне подходит)
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 и сделал с ним тестовый пример — он мне подходит)
Кто убил джуниора?