Comments 80
Спасибо за статью. Жизнеутверждающая. Как вы оцениваете фактор везения в своей истории?
Напоминает о том, что надо задавать себе вопрос: "Веришь ли ты в то что делаешь?" (главное не забывать об "ошибке выжившего")
Воодушевляет. Я бы поставил лайк, но мне нельзя, я новенький. А в бэкэндера решил выучиться после 35, кстати, вообще из гуманитария. И с дефицитом времени полный порядок (две работы, ИП, семья, дети... кошка). Но похвастаться мне еще нечем, на гитхабе только скрипты, поэтому пойду дальше учиться, а не на хабре мечтать...
Есть мнение, что программирование это как раз гуманитарная наука. Так что из гуманитария вообще может быть даже в каком-то плане удобнее переквалифицироваться.)
Тут главное видеть цель и не замечать препятствий)
Интересно, на чем это мнение основано? :)
Обосновывают тем, что в программировании помимо навыков, связанных с математикой и инженерией есть множество гуманитарных, в частности языковых, ведь у кода есть свои правила, синтаксис и грамматика, а большая часть времени всё же приходится именно на чтение и изучение кода.
Язык программирования ...
Если о самом языке - то это формализованная штука. Очень. Советую написать что-то типа семантического разбора математического выражения, сразу придет понимае :)
С точки зрения сути - язык программирования, это способ изложить свои мысли в рамках определнной парадигмы программирования :) Т.е. это не живой язык, а то, что связано с мвшлением определнным образом, например объекто-ориентированное.
Т.е. мышление первично, а язык связан с ним. Это что-то похоже на связь мышления и языка в философии. Но мышление первично.
А где гуманитарий и объекто-ориенировавнное программирование надеюсь пояснять не надо?
Не являюсь автором причисления программирования в стан гуманитарных наук, но эту идею встречал неоднократно.
Сам я программирование в явном виде, естественно, к гуманитарным не причисляю, но, на мой взгляд, эта теория имеет место быть в плане ряда аспектов.
Про "мёртвый язык" с таким аргументом не совсем согласен.
Само по себе отсутствие живого общения не является существенным доводом (гуманитарные науки – это несколько про другое).
Ещё как раз нужно учитывать то, что большую часть времени мы читаем чужой код и это в том числе своего рода анализ того, что человек хотел этим «сказать» и сделать.
Касательно ООП я бы тоже не считал это весомым аргументом. Во-первых, не все ЯП им обладают, а во-вторых, само по себе наличие какой-либо модели не противоречит теории.
Да и сказать я больше хотел иное: что то, что temabed гуманитарий – это не отягчающее обстоятельство и у него всё получится, а про теорию, просто к слови пришлось, как про один из интересных взглядов на данный аспект.)
Человек кодом не говорит
А записывает результаты мыслительного процесса в определенной парадигме
Если она тебе не известна - ничего не поймешь
И да, слово "язык" многозначно :)
А почему Вы считаете, что при взгляде на программирование как науку частично имеющую элементы гуманитарной это отменяет необходимость знания определённой языковой парадигмы? Вовсе нет.
Я такого не считаю
Я просто не вижу гуманитарной составляюшей
Давай проще - ты видишь, укажи конкретно :) Слова язык недостаточно, так как это разные семантические смыслы
Я уже указывал, просто Вы с этим не согласны, а повторяться, расписывать и пояснять не хочется, простите.
Тем более, что я изначально просто приводил к сведению, что такая теория имеет место быть, не более.)
Если Вам действительно интересно, можете в том же Яндексе вбить вопрос "является ли программирование гуманитарной наукой", материалов на эту тему и так тьма.
Ну честно, много воды ни о чем :)
Сорри, но либо давая по сути, к примеру берем язык и на примере конкретной задачи ищем гуманитарные корни, либо не натягиваем сову на глобус
Тут автор ещё несколько не в теме. Сами ЯП к гуманитарной части отношения не имеют, а вот отсутствие формализма при решении даже типовых задач как раз дают гуманитарный аспект.
На более высоких позициях, чем джун и мидл, уйма времени уходит на обсуждение, как с бизнес-заказчиками и аналитиками, так и с другими программистами и соседними департаментами (devops, sre, dataops, ml)
Я чуток знаю ;) Но - это не гуманитарная наука
Это скилл сет, который требуется на позицию. Люди не роботы, и почти всем, кто видиь других людей и как-то общаеься с ними, нужны soft skills. Но это никак не делает архитектора психологом или, ну не знаю, лингвистом. Ну бред. Я говорю/пишу, просто в жизни? Я гуманитарий, потому что использую язык?
Я написал email. Бинго, я гуманитарий, я перенес мои мысли на "бумагу" а другой человек прочитал. Ну маразм же :)
Если я прочитал чужой код - ну я точно гуманитарий так как смог по наскальным письменная предшественника пофиксить его баг
Это навыки коммунакации, котррые человек использует задолго до того, как это стало "наукой" (в глазах некоторых).
К примеру, я делаю презентацию. Я часто это делаю. Я гуманитарий? Чо, правда?
Ну, тут придётся тогда с определениями сначала определиться)
Что считать гуманитарными аспектами, а что - нет. Если под этим подразумевать только то, что касается изучения общества, человека и культуры, то этого действительно не много. Тем не менее «Человеческий фактор. Успешные проекты и команды», «Мифический человеко-месяц», «Как пасти котов», «Психбольница в руках пациентов» и ещё множество классических книг по разработке как раз про это.
Да все проще. Мир многогранен и на любой объект можно посмотреть с многих ракурсов. К примеру, у Java-програмиста все есть обьект, у менеджера проектов - любая активность проект и т.д.
Это интересно, об этом можно порассуждать за пивом.
Но в момент, когда субъект соверщает действие над объектом, все это многобразие схопывается до того единственного восприятия, либо конечного и небольшого списка, который есть в мозгу у субъекта :)
Если мы возьмем в качестве обстрактного субъекта сферического програмиста, а в качестве объекта програмный код - там будет исчезающе малая величина гуманитарной составляющей.
Но людям, далеких от того типа связей, может показаться, что там этого много. Но так как на код обычно смотрят именно програмисты, то взгляд филолога носит исключительно абстрактный характер :)
И я даже могу допустить, что сферическмй филолог думает по другому :)
Ну, понимать разработку, как исключительно работу с программным кодом, тоже не совсем верно. Так было, когда можно было в одиночку написать какое-то ПО и оно могло стать коммерчески успешным. Сейчас всё уже сложнее.
Да, но новые роли по прежнему технические :)
QA - чисто техника
DevOps - тож технарь
BA - записывать на чуток в гуманитарии, потому что не прячет нолову в песок при виде клиента? Реально глубоко формализованная работа
PM - тоже, что там гуманитарного? Появление бюджета проекта делает его экономистом?
AR - схемы рисует, в живописцы его?
:)
Можно проще, есть четкие требования к вакансиям. Там нет лингвистов, философов, психологов, ...
Я не про другие специальности. Вы читали книги, которые я выше упоминал? Они все для программистов, ну и отчасти для тимлидов. При этом они совсем не про код, но чтобы стать сеньором таких книг по сути надо прочитать чуть ли не больше, чем по технической части.
Нет, я не читал :)
Я боюсь, что вас ввели в заблуждение :) Большинство сеньоров/тимлидов/архитекторов эти книги не читало :)
А употребленное словл "классический" ничего кроме улыбки не вызывает
Мне это слово напоминает Кнута и его книги. Это действительно классика :)
Ну что ж, соберу статистику как-нибудь. Буду сеньоров на собесах спрашивать.
А вообще, почитайте. То, что вы не интересовались этими темами, это фигово. И Кнут тут не спасёт, это про другие компетенции.
Возможно :)
Просто ... я поясню следующим образом. Человечество давно, я б оценил в несколько тысячелетий, научилось:
Собирать людей в команды и достигать общего результата
Понимать требования заказчика
Вкладываться в бюджет и сроки
Нанимать и увольнять людей
...
Т.е это все изобретено еще до Тьюринга, Геделя, ... и даже до Аристотеля. Эти навыки ничем особенным не являются. Поэтому назвать что либо "классическим", написанное условно вчера про то, что человечество знает тысячелетиями как-то самонадеяно. Даже что-то "новое", что пришло в ИТ (я лет 13 назад застал приход Agile в большую организацию, это было весело), на самом деле оно совсем не новое :). Поэтому в реале все намного проще. Если вы хотите выбрать кого повысить до тим лида - выберите самого "взрослого" и ответственного. И почти не ошибетесь. Если к примеру вы построили дом, нанимая бригады, отдельных людей, закупали строй материалы, ругались, торговались, требовали все исправить и переделать ... то справитесь и с командой :). Потому что разницы нет :)
А книжка - это просто нечто, что может помочь систематизировать знания и опыт, но научить условного ной-лайфера как общаться с клиентом - не :)
Ну, отчасти вы правы. Человечество давно освоило командную работу, однако это по большей части касалось физического труда. Интеллектуальные команды инженеров, архитекторов и т.д. появились не так уж давно в исторических масштабах. Можно сказать, что ещё 100 лет назад никакой теоретической базы и стандартов не было на этот счёт.
А IT - отрасль ещё более молодая и со своей спецификой. Я бы не был так уверен, что любой прораб или капитан ВС сможет командой разработки руководить. Скорее наоборот, потому что книги, которые вы отрицаете, как раз и описывают почему тысячелетние наработки в стройке и армии не работают в IT. Да, они создают иллюзию понимания, как можно улучшить ситуацию, но в итоге всё сводится только к фрустрации из-за того, что стало только хуже.
По человечеству. Большинство стран закончило индустриализацию 2-3 столетия назад. Т.е. арзитекторы/инженеры в большом количестве появились не 100 лет. Так как это было массовое явление, я не думаю, что наши предки (хотя тут да, индустриализация и пост совок прошли меньше 100 лет назад) были такими тупыми, что каждый раз изобретали велосипед :) Строя очередной завод или корабль (как вершину технологического прогресса)
Прораб и капитан корабля точно сможет :) Не сразу конечно, но по менеджерским скиллам эти люди на голову выше любого тимлида :) Особенно вторые. Все таки надо понимать, что тимлид всегда может пойти домой, а корабль еще туда надо привести.
Я бы был благодарен за конкретику :) Т.е. вот например в части, что не работает из того, что было раньше. И желательно из современного, так как очевидно что некоторые методы мотивации из истории сейчас банально наказуемы.
Просто, как большой практик, хочется обсуждать более предметно. И да, надо понимать, что современная армия и стройка тоже не такие, как к примеру, армия совка. Не очень убедительно выходит, если есть какие-то книжки без которых никак, а все равно как-то получилось и неплохо. И ведь не только у меня. Противоречие.
Почему сразу тупыми? Это обычная фаза бурного роста, когда есть 100500 разных способов делать или обсуждать одно и то же. Собственно, ISO основали в 1947 году, СИ (которая система единиц, а не язык) приняли в 1960 году и т.д. и т.п. Большинству инженерных стандартов существенно меньше 100 лет, это факт.
Строя очередной завод или корабль (как вершину технологического прогресса)
Прям цитата из рекламного буклета Титаника? 😅
Я бы был благодарен за конкретику
Я ж указал названия нескольких книг. Я не думаю, что пытаться их пересказать в паре абзацев - хорошая идея.
а все равно как-то получилось и неплохо. И ведь не только у меня.
Я думаю, вы себе и всем нам льстите. Скажите ещё, что ни одна из команд, которыми вы управляли, ни разу не роняла прод))
Просто в IT пока что низкий уровень качества воспринимается как должное, отсюда и такая самонадеянность, что вы сами с усами.
Дело в том, что ...
Во-первых не ошибается тот, кто ничего не делает :) Я меня куча лаж как личных, так и командный. Есть такая забавная, как забыл открыть один сетевой доступ, что вскрылось при установке системы. Дело было вечером и наверное можно было решить вопрос через "телефон", но тогда в проде не были закрыты ssh-тунели и тем, что было доступно - прокрутил дырку.
Были и связанные с деньгами, к примеру, первая версия системы, написанной внешним подрядчиком был не очень с точки зрения ее конфигурабельности, и сев собместно со всеми участниками, с усетом полученного опыта описали ТЗ к веосии два и согласовали на Правлении ChR на доп. деньги. Короче, было не мало
Но это лирика. Вопрос в том, что пока от тебя "на столе" мнение, что вот ты пойди и почитай, и поймешь как они важны :) Ну этого маловато :) Просто если речь идеть о разговоре двух профессионалов, каждому не сложно найти пример из дичного опыта и на нем показать, что данные книги бы очень помогли и до того этого никто не знал :)
Если же примеров нет, а в сухом остатке "а ты пойди и почитай", то сразу закрадывается подозрение, что кто-то один в дискуссии не очень то и в теме, как практик и теоретик :)
Вот давай я помогу. Упомянут кейс "упал прод". Да, бывает. Вот чего такого есть в этих книгах, чтобы этот риск еще более минимизировать? Я ж готов обсудить. Но давай предметно. Вот прод. Он предмет "простой". Что мне даст книга(и), чтобы он стал падать меньше? И желательно то, чего не было известно или систематизировано до написания книг.
Я могу даже дать свои примеры:
Прод лег на увеличенной нагрузке. Причина проста - узкое место обработки сообщениц в коде. Решилось заплаткой. Хотя тут падения как такого-го небыло, была знаяимая деградация
Упал network core инфраструктуры заказчика. Легко понятно все, и наше решение в том числе.
Система ушла в 100% CPU. Проблема оказалась в кривом коде, который выбирал "последние" три транзакции, помле локалищации и люлей поставшику проблема бвда закрыта заплаткой
Систему подожили установкой обновновлений. Два раза. Главный менеджер проекта посчитал, что люди, которые занимаются релиз менеджментом просто списывают на его бюджет лишние часы и он сам справится. Ну, все в итоге посмотрели. Главный менеджер возможно понял, что релиз менеджмент - это не только красивые слова, но и много работы :) А может и нет, но сам он уже рутить в этой части не пробовал
Давай?
Спасибо, что подправили, я действительно кроме шуток, не особо в теме.
Но слышал про это от разных людей. Как раз, один из них говорил это человеку, который был гуманитарием по образованию и считал, что это диаметрально противоположная вещь и ничего общего с программированием нет.
Но мне почему-то запомнились больше доводы про то, что каждый программист большую часть времени (тот человек приводил аж 90%, с чем не согласен) читает и анализирует код, чем его пишет и, тем более чем в написании кода использует сложные математические знания.
В чём-чём, а в доводах к этой тории точно могу ошибаться, тем более, что не разделяю её полностью.
Может в аналитики пойдёте - раз ИП было, значит умеете в процессы и коммуникации, я вот 3 года назад - в 31 ушёл в IT с бэкграундом работы в закупках, логистике и ритейле, о программировании думал, но понял, что не моё - а в аналитику получилось залететь и уже вполне мидл)
ИП в смысле "индивидуальное предпринимательство"?)
Такого у меня не было, может я не так где-то выразился в статье?
Я подрабатывал репетитором по английскому, занимался созданием сайтов, фрилансил фотошопом и был ремонтником компьютерной и офисной техники, но ИП у меня не было.
А по основному профилю я работал инженером и занимался разработкой (в основном расчётами) и проектированием компонентов автомобилей для VW, BMW, Audi, Chery.
А в разработку пошёл как раз потому как именно эта роль мне была ближе и на предыдущей работе, на которой с некоторыми аспектами программирования всё же сталкивался.
Нет, я не вам отвечал, а товарищу @temabed он там в 35 с семьёй, кошкой и ИП пытается вкатиться в айтишку именно в программисты, а ему хотел посоветовать в аналитике себя попробовать - я на его комментарий отвечал, а не на вашу статью
Прошу прощения, Ваш коммент поинтил на мой ответ.
Тем ни менее, рад, что у Вас получилось таким образом понять, что Ваше, а что нет и стать аналитиком. Один мой хороший знакомый стал аналитиком только пройдя долгий путь разработчика.)
Ну он наверное стал прям хардовым системным аналитиком, который в постановках пишет типа тут метод вызови пре-сэйвом, тут навесь трейт и т.д.
Я то БА/СА то есть сомещаю эти функции и хоть капаюсь в Idea, в которой у меня локально развёрнуто приложение, чтоб понять логику работы методов и связи классов - постановки пишу по DDD, на едином унивесальном языке, который поймёт и бизнес и разработчик)
Аналитика- это прекрасно. Но очень уж меня увлекает программирование, хоть и не легка наука. Я всё же надеюсь преуспеть в ней. Но благодарен за ценный совет!
Да всегда пожалуйста... вообще читая хабр - кажется, что все хотят быть или программистами или тестеровщиками. Очень редко слышу про другие кейсы входа в IT, а при этом на рынке труда вроде как миллион джунов, после курсов или самообучившихся, мешающих нам, начинающим мидлам устроится на работу... если они мешают - значит они же куда-то попадают. Но вот их историй тут на хабре не вижу что-то🤷♂️
Видимо такие мощные джуны, что про Хабр даже не слышали. И так всё знают и умеют)
Да-да, может они на Пикабу сидят все😆
Именно. Я конечно не аналитик, но уже сделал вывод, что большинство современных джунов, которые решили обучиться после рекламы у блогеров о несметных богатствах в айти, в самой професии не заинтересованы. Формально обучились и кидают миллион однотипных резюме на все подряд вакансии, ждут, пока пойдет дождь из денег. Поэтому и на хабре их нет, они все на хэдхантере) К сожалению, их кейсы мы вряд ли прочитаем. И кстати, надо подумать над площадкой, где HR-ы будут хантить айтишников, но в которую не смогут войти "черные вкатуны"))
Может выборка и не велика, но среди тех джунов, которые мне писали в личку с просьбой помочь, половина действительно повелась на рекламу и хочет «на изи за бабло влететь в IT, чилить и лутить оверхэд бабла», но другая половина – нормальные ребята, замотивированные на самореализацию в профессии.
Про успех людей из первой половины мне периодически рассказывают.
Типичная история: «Без вышки закончил курс, пошёл работать на несколько месяцев на галеру, поднахватался, нарисовал себе пару лет опыта и устроился в MAGNIT на ставку мидла». Я с таких историй, если честно, фигею и не понимаю такого.
Я могу ошибаться, но по отзывам HR-ов, на данный этап такой площадкой, про которую Вы говорите, является Хабр Карьера.
Ну много очковтирателей удачно устраиваются на ставки, не соответствующие их реальным грейдам, я сам такое видел не раз, не только в IT, даже у нас такое бывало за год уже 2 раза, сначала недо PM с большим опытом устроился, который нифига за полгода не оправдал надежд топ-менеджмента и был уволен, потом не QA-лид тоже за оверзп посидел, правда его за 4 месяца вычислили и попросили...
Эти люди не с курсов, просто ушлые по жизни, но в принципе и после курсов такие бывают...
Хабр Карьера был бы такой площадкой, если бы зарегистрироваться там можно было только имея положительный рейтинг на Хабре, например [тут нужно отметить руководителя Хабр Карьеры]. А сейчас там кто угодно может написать что угодно, как и на ХэХэ. И по поводу ушлых, ну они везде есть, надеюсь в айти их не большинство. Меня эта сфера и привлекает тем, что тут вроде важны скилы, а не родственные связи, мздоимство и лихоимство.
К примеру, по одной такой матрице Junior должен как минимум знать monitor, wait/notify/notifyAll/sleep, synchronized, volatile, Thread, Future, Callable, основные Thread-safe коллекции, в то время как Middle должен к этому всему ещё знать ReentantLock, ReentantReadWriteLock, Standard Executors (Single-Thread, Fixed, Pooled), Scheduled Executor, Atomic (Integer, Boolean, etc), Concurrent collections, BlockingQueues.
Простите, но в реальности Junior вообще не должен допускаться до многопоточности (потому что это объективно сложно), особенно — с применением таких низкоуровневых примитивов, как wait/notify/notifyAll и т.п. В тоже время, упомянутые Atomic — средства более высокого уровня, которыми Junior как раз и должен пользоваться, когда пишет прикладное решение (если уж ему вдруг отчего-то такое доверили). Ну то есть, если ты джун, и никогда такого не писал — возьми то, что попроще, и воспользуйся готовым. Ошибиться, применяя ConcurentMap, намного сложнее, чем реализуя что-то свое на базе synchronized или volatile.
Иными словами, все должно быть наоборот — компетенции надо поменять местами, и тогда будет ближе к правде.
Я тоже как и Вы считаю, что Junior не должен заниматься многопоточностью, потому что действительно это – объективно сложно. С этим согласен.
Также возможно Вы отчасти правы касательно коллекций, но при всей низкоуровневости считаю, что методы класса Object wait/notify/notifyAll "Junior должен как минимум знать", а именно в такой формулировке я это привёл изначально.
Wait/notify/notifyAll в совокупности со sleep, synchronized, volatile, Thread, Runnable (+ не всегда, но зачастую ещё Future и Callable) именно так идут во всех учебниках для новичков и начинающих, преподаются на 6-м и 7-м уровнях курса Java Core на JavaRush. Это база.
В отличие от Atomic'ов которых обычно на первом этапе обучения Java нет!, а они появляются уже потом, когда изучается механизм CAS.
считаю, что методы класса Object wait/notify/notifyAll "Junior должен как минимум знать
Дело в том, что от этого знания нет никакого толку. Поэтому если я буду набирать вдруг джунов, я не буду у них это спрашивать. Надо будет — потом изучат. Как-то так. И начнут при этом пусть с высокоуровневых более новых примитивов, а не с того, с чего начинают в учебниках, написанных людьми, которые вообще никогда многопоточные приложения не писали.
Простите, тут я с Вами вообще никак не могу согласиться.
Простите, но вы (исходя из вашего текста) только начали изучать в 2018 году. А я был тимлидом в 2005, а работать на Java начал примерно в 1998. То есть, наш с вами опыт несопоставим. Можете не соглашаться, дело ваше. Мой пойнт в том, что на каждом уровне изучать надо то, что ты в состоянии применить, а не то что принято (на самом деле — то что исторически появилось раньше). Из того что оно раньше появилось — не значит, что оно лучше вообще, или лучше подходит джунам. Ровно наоборот — позже были созданы примитивы и классы (например коллекции или всякие барьеры), которые в использовании проще и удобнее, и дают меньше шансов ошибиться — потому что создали их на основе опыта применения первых версий.
Я сразу понял, что у Вас большой опыт в Java. Никак не хочу принижать вес Вашего опыта и знаний.
Но и Вы поймите, во-первых, то распределение – не моё know how, я не выдаю его за единственно верное и дал его как пример одного из,
а во-вторых, в курсах и учебных пособиях, которые созданы тоже людьми авторитетными в мире Java с опытом таким же значимым как и у Вас каноничным является именно такой приоритет для градации компетенций в Java.
Вашу логику я понимаю, но я буду придерживаться всё же того приоритета, который описал выше.
Так вы не обязаны моей логикой пользоваться, и я тоже не считаю ее единственно верной. Моя логика — это логика человека, который набирает разработчиков в команду, и кому важно, что они могут реально делать. Ваша — логика человека, который хочет сам научиться. У нас вполне могут быть разные приоритеты в порядке изучения чего-то. Да, это просто другой подход к матрицам и компетенциям — что на любом уровне не особо нужны компетенции, с которыми человек все равно не справится. Но если вы хотите все и систематически изучить в теории — то порядок возможно не так и важен.
изучать надо то, что ты в состоянии применить, а не то что принято
Золотые слова!
Могу сказать, что sleep,notify,volatile и ТД спрашивают даже на собесах automation qa:) поэтому для успешного прохождения собесов, как минимум, нужно это знать
Н-да.... Интересно. Учиться 1-2 часа в день и иметь реальные результаты это прям талант. Я учился с полным "отрывом от производства", больше года без выходных и праздников, потом 3 месяца искал работу, повезло устроиться туда где не требовалось знания Спринг, его доучивал уже работая.
Я в нашей компании вообще один "джавист", пилю куски, "побочные" относительно нашей системы и это сразу с нуля, не имея на старте вообще никакого опыта :)
Сейчас, через 2.5 года работы имею:
пару проектов, кое-как доведённых до рабочего состояния, но отложенных т.к. надобность в них временно отпала;
один проект в проде и реально используется (это прям была радость посреди вселенской безнадёги): Spring + Angular, да, я настолько один что и фронт приходится самому :)
текущий в работе: без Spring, но на Reactor-Netty + React, вот такая загогулина :)
Но как-то.... я не мидл, по деньгам уж точно. В общем, я не подвергаю сомнению историю автора, но думаю что это результат сочетания таланта и везения, но никак не "каждый так может".
PS: посоветуйте хорошие ресурсы по Reactor! Очень тяжело идёт эта тема.... В своё время так же не понимал Stream API, но нашёл на Степике отличный курс, который прямо на задачах "провёл" от простого к сложному, открыл мне эту чакру и теперь я с удовольствием использую стримы на практике. Вот бы то же самое для Реактора!
Прочитал вашу статью и понимаю что вы проходили . Та же история: 50 с лишним откликов на джуна в области администрирования и 0 приглашений. Тема везения на старте становится архи важной, так как до этапа , когда можно показать знания, даже не доходит.
Когда я выкладывал резюме, у меня количество приглашений было 20+, а я даже не откликался на эти вакансии, в то время, как у некоторых однокурсников было всего 2-3.
Помимо везения есть ещё ряд факторов и критериев, на которые обращают внимание HR и те, кому они передают резюме для ознакомления.
На эту тему общался с HR и как-то хотел написать это в статье.
Но все эти факторы настолько субъективны, спорны и порой обидны, хотя почти все поправимы, что, боюсь, если я их перечислю, меня закидают шапками, что я вообще не прав и всё совсем не так)))
Через шапкозакидательство проходил, поэтому более чем понимаю.)
Но как человеку, который понимает: 1. что столкнулся с фильтром HR во всей красе 2. осознает, что что-то делает нет так. 3. Готов прислушаться и сделать выводы было бы познавательно.
Ок, тогда напишу в личку.
Будьте добры, закиньте и мне тоже.
Что ж личку то! Если и мне напишете - буду признателен
А в общем знаниями не грех делиться, пусть даже субъективными
Потому что, Во-первых, как я уже сказал выше, многие вещи очень субъективные, спорные и вызывают очень много "да это всё не так" и "да все это и так знают", в то время как эти вещи Реально помогают из моей практики и моих коллег, друзей и знакомых
Во-вторых, это на самом деле действительно индивидуально и зачастую мне говорят, что у них всё так, но вообще ни просмотров, ни откликов, а начинаешь предметно смотреть и там обнаруживаешь один какой-то нюанс, который подправить и всё, у человека всё работает) просмотры у резюме крутятся, приглашения мутятся, так что порой надо таргетировано.
Полный список не буду приводить по вышеуказанным причинам, но вот Топ10, как оказалось, неочевидных вещей, которые казалось бы полный пустяк, но тем ни менее реально решают:
Нужно фото, при том Ваше, нормальное, чтобы Ваша анкета не была обезличенной и не отпугивала.
Нужно убрать из вакансии упоминание Junior, в заголовке анкеты и тексте, в анкете оно не нужно, что джун и так поймут.
Навыки должны быть в пункте "Ключевые навыки", а не где-то в тексте о себе. Поиск по ним.
Туда же в "Ключевые навыки" бесполезно пихать всякие "ответственный и компетентный", "очень хороший и старательный" это наоборот отталкивает.
Берите вакансии, на которые хотели бы откликнуться, посмотрите, какие там требования описаны и если что-то упустили, либо у Вас написано не так как там, то исправляйте.
В те же самые ключевые "Ключевые навыки" не пишите "Умею работать с БД" или "Работа с базой данных в Spirng", пишите конкретные технологии "SQL", "Spring Data", "Spring Data JDBC", "Spring Data JPA", "JPA", "JDBC",... то есть вообще детально нужно описывать.
Не лейте воду. К примеру, я мог бы в начале пути написать "Всегда хотел быть программистом. Мечтал об этом сколько себя помню. Свой путь начал... Хочу стать ...". Нет! Если хочется это как-то написать, то кратко и в одно предложение: "Люблю программировать".
Многие пишут "Я много не знаю, но сейчас этому учусь и буду знать...", "Сейчас не умею, но потом собираюсь приобрести навык в ...", "Готов улучшать и нарабатывать новые навыки ...". Нет! Это тоже не нужно. Учатся все, а вот такие промисы и завтраки никому не нужны, это отталкивает. Важно только то, что умеешь сейчас.
Опыт работы. Всё что меньше года желательно убрать, даже если это была подработка, прыгун не нужен никому. Исключением будет, если это действительно стажировка, первый опыт работы.
Не давать ложную и некорректную информацию, если HR Вас спалит, можете вообще пойти в ЧС, а Вы даже не узнаете об этом.
Поддерживаю ☝️
Когда вы наберете достаточно опыта, то обнаружите что вместе с опытом приходит и возраст. И ваши 50 откликов превратятся в 250 с тем же результатом.
Т.е. до этапа, когда можно показать знания, вы точно так же не дойдете, потому что у эйчаров есть автофильтр по году рождения, отсеивающий вас еще в самом начале.
Про Reactor Netty: В основном, конечно, сейчас реактивное программирование идёт на Spring через WebFlux.
Какого-то удобоваримого ресурса по Reactor Netty в чистом виде на русском я не встречал, в учебниках вроде Spring Boot 2, который я приводил, эта тема даётся как преддверие к WebFlux.
Помимо https://projectreactor.io/learn, роликов на Ютубе и статей, только курсы, где изучается NIO -> Netty -> Reactor Netty -> WebFlux.
Поделитесь пожалуйста ссылкой или названием курса на степике по Stream API.
Я проходил этот курс. Сейчас он устарел и авторы сделали новый. Ссылка на него в описании. Курс на английском, но язык там очень простой, разберёшься без проблем.
Удачи!
Поймите главное, если вас взяли мидлом в одну компанию, это совсем не означает что вы реально миддл. Это деление весьма условно. Миддл в Сбере и в Яндексе это разработчики совершенно разного уровня. Более того я часто видел ситуацию когда синьоры переходили на уровень Джуна, например, в FAANG.
Поверьте, я это прекрасно понимаю, всё очень относительно.
Но считаю, не стоит впадать в крайность, если так, то в каком-то отношении мы все джунишки, я в первых рядах))
Поэтому, чтобы не было недопониманий, предвосхитив такую критику я специально выделил несколько критериев, которыми я оперировал.
Это и заявленный уровень курса, который закончил с отличием, и соответствие по матрице компетенции, в том числе по той, которая была у моей фирмы-работодателя, где тысячи джавистов, и то, как меня оценивали почти во всех других фирмах, и именно прописанная позиция в фирме, и такие критерии как самостоятельное ведение проекта, принятие проектных решений, сдача в релиз и так далее.
Как раз таки и означает. Если человек работает на позиции мидла, то он мидл
Судя по тому что лежит в опенсорс от Яндекса на джаве, там либо не хватает ресурсов и времени, либо олимпиадники не дотягивают до международного уровня промышленного программирования. Смотрел Яндекс db sdk, по сравнению со spring data и прочими спринговыми библиотеками небо и земля. В принципе такое же ощущение и от гугловых sdk, там черт ногу сломит. Так что олимпиадность на мой субъективный взгляд даже вредна для хорошей промышленной разработки.
Раскройте пожалуйста первую з/п, которую вы якобы в 1.7 раз могли выше просить. Время уже прошло можно и раскрыть. Это Москва? Я помнится когда переезжал в Москву 5 лет назад на мидла получал 140к
В целом java rush и top java топчик. Плюс очень разжевано по джаве на курсах Головача
Прошу прощения, я намеренно не раскрываю своей зарплаты по ряду личных причин и мотивов, в том числе, потому что это было всего пару лет назад.
Про то, что "якобы в 1.7 раз" мог просить выше.
Эту информацию я узнал непосредственно у HR и своих коллег, которые тоже таким образом "оплошали", которые пошли на тот же грейд и уже потом постфактум узнали, что в нашей фирме система утверждения з/п элементарно сводится к тому, что даже торга не идёт никакого, если человек называет сумму в пределах вилки, которую собственно потом озвучил HR и это не является фактором, который может сказаться на выборе другого более "дешёвого" кандидата.
Про JavaRush и TopJava согласен на все 100! Ивана Головача видео больше слушал, чем смотрел. Материал хороший, но я бы больше рекомендовал что-то хотя бы 2016+ без съёмок проекции на доску. Но это опять же, на любителя)
В целом согласен с посылом статьи. Я уже не первый год желающим ворваться в IT рекомендую настраиваться на 3-4 года обучения и целиться сразу в мидла.
Добавлю ещё, что выгоднее выбирать не самые хайповые языки. Например, на Python и JS уже деваться некуда от новичков, их тупо раз в 10 больше, чем надо 😂
То ещё что )
А вот войти с опытом Джуна сразу на тимлида - слабо? (Мой вариант, причём, два раза, с опытом в it соответственно 2.5 месяца и 1.5 года соответственно)
Так что статья и правда хорошая, мотивирует, но не забывайте, что возможно всё.
П. С. Если что - я не про связи и/или пускание пыли в глаза - все по честному, хороший тимлид за 3 месяца с нуля это реально, и пофиг, что, сейчас за эту фразу меня может заминусовать половина хабра, я исхожу из личного опыта )
Чисто гипотетически нет ничего невозможного, согласен.)
А упорство, целеустремлённость и энтузиазм порой творят чудеса.
Та стратегия, которая была у меня в плане попытки подтянуть компетенцию на уровень выше, на самом деле не уникальна и является универсальной. Это не моё know how.
В статье хотел показать, что, следуя ей можно действительно иметь положительный (пускай и не стопроцентный) результат, который реально поможет в будущем.
«Входить в IT неспеша» или как стать Middle Java Backend разработчиком минуя ступень Junior