Во-первых, в отрасли есть крупные компании-гиганты и там лесенка гораздо более длинная: есть стажеры, вы забыли прибавить самого лида, над лидом стоит principal и fellow или рядом может быть senior architect. Просто высокие уровни - это штучный товар и его сложно унифицировать и классифицировать в силу своей штучности, а самый ходовой как раз, рабочие лошадки - это лишь часть диапазона.
Во-вторых, грейды могут дробиться на подуровни. Откройте levels и посмотрите допустим разбивку майкрософт, сравните с другими компаниями. И да, в рамках конкретной компании так зачем-то нужно под задачи компании и под это есть соответствующие процедуры, которые извне могут казаться блажью и различением слишком тонких оттенков вкуса.
В-третьих, вы смешали профессии связанные на впечатлениях/ощущениях (вкусовщине) типа певцов и профессий основанных на процессах и повторяемости. Вам всё равно как токарь споёт свою деталь, в детали важны свойства детали, а не ваши эмоции. А певец вам приносит эмоциии и как бы не был технологичен певец (знает ноты, теорию музыки, закончил консерваторию, умеет писать песни и в аранжировки, имеет широкий диапазон) вас тупо может не торкнуть. А соседа рядом - торкнуть.
Надо было бы сделать опрос не выбором одного пункта и не множественным выбором - а просить отранжировать список факторов, какие из них важны. Опционально - ограничить выбор тремя факторами или пятью (из списка в -цать возможных вариантов).
Ох, спорно это. Я не уверен, что подобные проблемы должны решаться комментариями.
почему здесь используется такая формула, а не такая?
Вероятнее всего - так надо по тех.заданию. Если говорить не только о промышленном коде, а допустим о решении задач на литкоде, то там встречается ситуация когда задачу, которую вы решили подбором (написали бинпоиск), а потом видишь у соседа какую-то формулу - и не зная мат.часть ты никогда не поймёшь что это и почему так (вместо бинпоиска применили формулу Ньютона) если до этого не знаешь.
зачем вы соединили методы именно таким образом?
Не уверен, что правильно понял пример (приведите свой если не так понял), но по-моему это скорее вопрос, который решается изучением типовых паттернов программирования, а не написанием комментариев.
почему тут так все плохо? Или наоборот, хорошо?
Почему всё так плохо - писал новичок без надзора и ревью, либо жёсткий цейтнот "фича нужна вчера". Но непонятно ни то, нафига задаваться такими вопросами читаюему и нафига пишущему код об этом задумываться и подбирать комментарии. Иначе будут появляться комментарии вида "я пьян, поэтому тут г..но полное", а они мешают.
если надо изменить некий функционал, где именно надо изменить?
Ну это вообще вопрос на миллион. Человек пишущий код - должен думать о том, как решить текущую задачу, он понятия не имеет о будущих людях, кто будет этот код потом изменять и дополнять. Да, если у пишущего есть архитектурное мышление - он как правило будет писать код, который в некоторых пределах будет допускать расширение по типовым направлениям, но не всем. (Универсальной архитектуры подо всё нет; бесконечно универсальный код стоит бесконечно много).
И после этой книги можно тут же курс на курсере пройти от автора. Мне чем понравился курс Седжвика - наличием автоматической оценки присланного кода по количеству пройденных юнит-тестов
Максим, есть и такие компании. Я помню ходил в одну контору, которая занимается достаточно себе хайлоадом и где мне помнится был вопрос про gc на который я думал, что ответил хорошо и подробно - но в обратной связи сказали, что я перепутал местами первое и второе поколение. Надо сказать я удивился, но не взяли - и не взяли, негатива особого не осталось: несмотря на то, что было явно видно, то собеседующий а) разбирается в языке на вполне моём уровне б) не проводит собесы чаще раз в квартал в) вопросы были такие, что особо не поймёшь уровень интервьюируемого (просто пять вариантов ответа и хотя я старательно объяснял логику, почему выбираю тот или иной вариант ответа - или честно гадаю, если не знаю и объясняю выбор - меня так ни разу и не макнули более подробно вглубь вопроса, хотя вопросы допускали такое (скажем вопрос на оптимизацию в sql-запросе можно было чуть поменять структуру - и уже было бы сразу намного понятнее, насколько глубоко разбираешься).
При этом я смотрел на их сайт, у них alexa rank был один из топовых в России, поэтому вполне верю, что им взаправду надо хороших специалистов с опытом.
Короче, поскольку мне предложили денег меньше чем на текущем месте работы я долго не думал - и быстро забыл про тот случай.
А почему вы думаете только о "интернете", забывая, что можно подставить конкретный IP из локальной сети и дав адрес предварительно заражённой машины. Были случаи когда заражали сборочный сервер - от какого-нибудь сервера ФСО РФ до сервера SolarWinds, а уж случаев когда внутри корпоративной сети ломают первую машину в качестве плацдарма и вовсе каждый первый. Так что вектор атаки мне кажется более серьёзным, потому что если с моделью внешних угроз все худо-бедно научились жить (то же ограничение IP-адресов "снаружи", скажем, ходить на адреса ЦБ РФ за обновлёнными данными по валютным парам), то внутри компании ограничения могут быть намного более слабыми.
Ммммм.... Да, в мире много плохого и негативного, поэтому мне очень нравится определение данное чуть ниже в комментах - "святочные истории". Это типа как красивая история о Золушке, ставшей принцессой, просто в детстве девочкам не говорят, что Золушек - миллионы, а принцессой станет дай бог если одна из миллиона. И вот за это раздувание мифологии вам и прилетело: тут же в комментариях верно указывают, что в жизни бывает и так, что в продуктовой компании бардак хуже чем в галере, и у вас вроде тезис тот же самый, просто одни дают прагматичный взгляд на реальную жизнь, а у вас какой-то сильный ореол сказочности и мифичности, подчёркнутый ещё и выбором формы статьи.
В этой статье не сказать чтобы краем, но и не как основная поднята интересная для меня тема построения личных баз знаний. Лично я веду заметки не в Joplin, а просто в .md-файлах - создал себе по репозиторию на каждую базу знаний (например, algo, career, cs, health, math и т.д.) и пишу себе заметки, которые раскладываю по папочкам. Удобно: в markdown есть поддержка кода, есть поддержка latex и можно писать формулы (не то, чтобы я виртуоз tex, в шпаргалке всего пунктов 20 самых нужных).
Закладываться на конкретную программу мне показалось рискованным на интервале более пяти лет, тут легко может оказаться что и попытка заложиться на конкретный формат разметки может оказаться наивной и плохо продуманной (я например помню ещё господство bbcode).
В статье никак не раскрыта тема объяснения time to leave. Во-первых, это не точка на оси времени - а вообще не обозначенный интервал. (Просто попробуйте сказать: TTL - это в момент пересечения линии импакта линии зарплаты в конкретной компании или в момент пересечения линии импакта рыночной зарплаты. Или где-то между? Или позже? Да они даже не подписаны!) Во-вторых, нет объяснения, ПОЧЕМУ именно в этой точке, а не раньше/позже. Нет механики.
Кроме того, не раскрыта тема взаимодействия с другой компанией и не раскрыта тема того, как идеальная компания должна была бы менять линию зарплаты в зависимости от импакта или от выслуги.
Уже сейчас можно в некоторых компаниях подписывать кадровые документы при помощи ЭЦП, поэтому даже и подпись ставить - возможно окажется уходящим навыком.
Мне удобнее открыть рабочий ноут и посмотреть в интранет.
Из минусов - не во всех компаниях просто открыть с сотового телефона, т.к. безопасники очень неодобрительно смотрят на торчащие наружу вещи и в первый день не до этого квеста.
И это ещё хорошо, если он скажет "необщительный", а не "токсичный" или "пока я фигачу бизнес-вэлью за один день он сидит неделю в коде ради штук, которые не приносят бизнес-вэлью". И с точки зрения недальновидного или не очень опытного руководителя очевидно кто молодец, а кого надо взашей гнать с работы. Потому что это как в анекдоте про "Спасаю Землю от зелёных человечков" (И не благодарите): вот есть какой-то парень который постоянно кричит "<s>волк, волк</s> надо снижать техдолг иначе потом сроки внедрения фич будут увеличиваться в десятки раз" -- а на деле этого никогда не происходит. И поймёт это дай бог если только через полгода после увольнения нормального разраба, когда уже будет поздно. (Один из таких кейсов числится даже за корпорацией Оракл, когда на фичу месяцы уходили - что уж говорить про более мелкие конторы?)
Статья огонь! Я сам наверное вообще посторонний человек - разве что в детстве видел схему Радио-86РК, Специалиста и прочего КР580ВМ80А и аналогах построенного, сам я больше по софту чем по железкам упарываюсь. Но мне понравились военкоматовские аналогии и ещё хорош концепт ментального рывка (вероятно в каждой профессии он свой, но везде есть - то, что отличает профи от любителя и где надо совершить это ментальное усилие)
Подразумевается видимо разница между конторами, в которых процесс подавления жоп происходит на ранних стадиях и конторами в которых успевают разгребать жопы на стадии когда они уже выросли в сочные, мясистые жопы. Так сказать риск-менеджмент есть и есть планомерная работа или когда горизонт планирования настолько узок, что нет времени подумать о том, как не доводить жопы до крупных неконтролируемых.
У Лили Ким была фраза "нам нужно сажать картошку чтобы есть картошку чтобы были силы снова сажать картошку" (колесо сансары), так вот это вот такая же дурная бесконечность, когда не успеваешь разгрести все жопы, поэтому нет сил подумать о том, как разгребать жопы на более ранних стадиях. (И квадрат Эйзенхауэра об этом же: надо забыть про несрочные и неважные жопы, а разгребать несрочные важные жопы пока они не доросли до срочных и важных жоп)
Аналогично думаю. Сидел 10 лет в одной конторе, при этом и проекты кардинально менялись и технологии (переходили на тот же докер/куб) и успел язык программирования сменить. Это не обязательно красный флаг, ситуации разные бывают. И можно просто поговорить, но даже по резюме это видно - так что если вас на этом этапе зарубают - то и к лучшему, что вы даже не потратили на такую компанию время.
Братья Стругацкие в "Граде" писали, что сложно жалеть сытого человека. Ведь большинство директоров-учредителей поди не на 30 тысяч рублей в месяц выгорают, верно?
Ну вообще, если вы разработчик - то лучше идти SWE, а не SRE (иногда некоторые путают, да). И не раскрыта тема "нужно SRE ли фигачить литкод и как им вообще готовиться к собесам".
Во-первых, в отрасли есть крупные компании-гиганты и там лесенка гораздо более длинная: есть стажеры, вы забыли прибавить самого лида, над лидом стоит principal и fellow или рядом может быть senior architect. Просто высокие уровни - это штучный товар и его сложно унифицировать и классифицировать в силу своей штучности, а самый ходовой как раз, рабочие лошадки - это лишь часть диапазона.
Во-вторых, грейды могут дробиться на подуровни. Откройте levels и посмотрите допустим разбивку майкрософт, сравните с другими компаниями. И да, в рамках конкретной компании так зачем-то нужно под задачи компании и под это есть соответствующие процедуры, которые извне могут казаться блажью и различением слишком тонких оттенков вкуса.
В-третьих, вы смешали профессии связанные на впечатлениях/ощущениях (вкусовщине) типа певцов и профессий основанных на процессах и повторяемости. Вам всё равно как токарь споёт свою деталь, в детали важны свойства детали, а не ваши эмоции. А певец вам приносит эмоциии и как бы не был технологичен певец (знает ноты, теорию музыки, закончил консерваторию, умеет писать песни и в аранжировки, имеет широкий диапазон) вас тупо может не торкнуть. А соседа рядом - торкнуть.
Надо было бы сделать опрос не выбором одного пункта и не множественным выбором - а просить отранжировать список факторов, какие из них важны. Опционально - ограничить выбор тремя факторами или пятью (из списка в -цать возможных вариантов).
Ох, спорно это. Я не уверен, что подобные проблемы должны решаться комментариями.
Вероятнее всего - так надо по тех.заданию. Если говорить не только о промышленном коде, а допустим о решении задач на литкоде, то там встречается ситуация когда задачу, которую вы решили подбором (написали бинпоиск), а потом видишь у соседа какую-то формулу - и не зная мат.часть ты никогда не поймёшь что это и почему так (вместо бинпоиска применили формулу Ньютона) если до этого не знаешь.
Не уверен, что правильно понял пример (приведите свой если не так понял), но по-моему это скорее вопрос, который решается изучением типовых паттернов программирования, а не написанием комментариев.
Почему всё так плохо - писал новичок без надзора и ревью, либо жёсткий цейтнот "фича нужна вчера". Но непонятно ни то, нафига задаваться такими вопросами читаюему и нафига пишущему код об этом задумываться и подбирать комментарии. Иначе будут появляться комментарии вида "я пьян, поэтому тут г..но полное", а они мешают.
Ну это вообще вопрос на миллион. Человек пишущий код - должен думать о том, как решить текущую задачу, он понятия не имеет о будущих людях, кто будет этот код потом изменять и дополнять. Да, если у пишущего есть архитектурное мышление - он как правило будет писать код, который в некоторых пределах будет допускать расширение по типовым направлениям, но не всем. (Универсальной архитектуры подо всё нет; бесконечно универсальный код стоит бесконечно много).
И после этой книги можно тут же курс на курсере пройти от автора. Мне чем понравился курс Седжвика - наличием автоматической оценки присланного кода по количеству пройденных юнит-тестов
Максим, есть и такие компании. Я помню ходил в одну контору, которая занимается достаточно себе хайлоадом и где мне помнится был вопрос про gc на который я думал, что ответил хорошо и подробно - но в обратной связи сказали, что я перепутал местами первое и второе поколение. Надо сказать я удивился, но не взяли - и не взяли, негатива особого не осталось: несмотря на то, что было явно видно, то собеседующий а) разбирается в языке на вполне моём уровне б) не проводит собесы чаще раз в квартал в) вопросы были такие, что особо не поймёшь уровень интервьюируемого (просто пять вариантов ответа и хотя я старательно объяснял логику, почему выбираю тот или иной вариант ответа - или честно гадаю, если не знаю и объясняю выбор - меня так ни разу и не макнули более подробно вглубь вопроса, хотя вопросы допускали такое (скажем вопрос на оптимизацию в sql-запросе можно было чуть поменять структуру - и уже было бы сразу намного понятнее, насколько глубоко разбираешься).
При этом я смотрел на их сайт, у них alexa rank был один из топовых в России, поэтому вполне верю, что им взаправду надо хороших специалистов с опытом.
Короче, поскольку мне предложили денег меньше чем на текущем месте работы я долго не думал - и быстро забыл про тот случай.
А почему вы думаете только о "интернете", забывая, что можно подставить конкретный IP из локальной сети и дав адрес предварительно заражённой машины. Были случаи когда заражали сборочный сервер - от какого-нибудь сервера ФСО РФ до сервера SolarWinds, а уж случаев когда внутри корпоративной сети ломают первую машину в качестве плацдарма и вовсе каждый первый. Так что вектор атаки мне кажется более серьёзным, потому что если с моделью внешних угроз все худо-бедно научились жить (то же ограничение IP-адресов "снаружи", скажем, ходить на адреса ЦБ РФ за обновлёнными данными по валютным парам), то внутри компании ограничения могут быть намного более слабыми.
Ммммм.... Да, в мире много плохого и негативного, поэтому мне очень нравится определение данное чуть ниже в комментах - "святочные истории". Это типа как красивая история о Золушке, ставшей принцессой, просто в детстве девочкам не говорят, что Золушек - миллионы, а принцессой станет дай бог если одна из миллиона. И вот за это раздувание мифологии вам и прилетело: тут же в комментариях верно указывают, что в жизни бывает и так, что в продуктовой компании бардак хуже чем в галере, и у вас вроде тезис тот же самый, просто одни дают прагматичный взгляд на реальную жизнь, а у вас какой-то сильный ореол сказочности и мифичности, подчёркнутый ещё и выбором формы статьи.
В этой статье не сказать чтобы краем, но и не как основная поднята интересная для меня тема построения личных баз знаний. Лично я веду заметки не в Joplin, а просто в .md-файлах - создал себе по репозиторию на каждую базу знаний (например, algo, career, cs, health, math и т.д.) и пишу себе заметки, которые раскладываю по папочкам. Удобно: в markdown есть поддержка кода, есть поддержка latex и можно писать формулы (не то, чтобы я виртуоз tex, в шпаргалке всего пунктов 20 самых нужных).
Закладываться на конкретную программу мне показалось рискованным на интервале более пяти лет, тут легко может оказаться что и попытка заложиться на конкретный формат разметки может оказаться наивной и плохо продуманной (я например помню ещё господство bbcode).
В статье никак не раскрыта тема объяснения time to leave. Во-первых, это не точка на оси времени - а вообще не обозначенный интервал. (Просто попробуйте сказать: TTL - это в момент пересечения линии импакта линии зарплаты в конкретной компании или в момент пересечения линии импакта рыночной зарплаты. Или где-то между? Или позже? Да они даже не подписаны!) Во-вторых, нет объяснения, ПОЧЕМУ именно в этой точке, а не раньше/позже. Нет механики.
Кроме того, не раскрыта тема взаимодействия с другой компанией и не раскрыта тема того, как идеальная компания должна была бы менять линию зарплаты в зависимости от импакта или от выслуги.
В общем, замах был на рубль, удар - много слабее.
Уже сейчас можно в некоторых компаниях подписывать кадровые документы при помощи ЭЦП, поэтому даже и подпись ставить - возможно окажется уходящим навыком.
Мне удобнее открыть рабочий ноут и посмотреть в интранет.
Из минусов - не во всех компаниях просто открыть с сотового телефона, т.к. безопасники очень неодобрительно смотрят на торчащие наружу вещи и в первый день не до этого квеста.
И это ещё хорошо, если он скажет "необщительный", а не "токсичный" или "пока я фигачу бизнес-вэлью за один день он сидит неделю в коде ради штук, которые не приносят бизнес-вэлью". И с точки зрения недальновидного или не очень опытного руководителя очевидно кто молодец, а кого надо взашей гнать с работы. Потому что это как в анекдоте про "Спасаю Землю от зелёных человечков" (И не благодарите): вот есть какой-то парень который постоянно кричит "<s>волк, волк</s> надо снижать техдолг иначе потом сроки внедрения фич будут увеличиваться в десятки раз" -- а на деле этого никогда не происходит. И поймёт это дай бог если только через полгода после увольнения нормального разраба, когда уже будет поздно. (Один из таких кейсов числится даже за корпорацией Оракл, когда на фичу месяцы уходили - что уж говорить про более мелкие конторы?)
«своим — всё, чужим — по закону»
Пробочка, выполняющая функции иностранного агента.
Куда уж ниже-то? Он и так менее одного процента. В суде РФ вас практически с 99% вероятностью признают виновным.
Статья огонь! Я сам наверное вообще посторонний человек - разве что в детстве видел схему Радио-86РК, Специалиста и прочего КР580ВМ80А и аналогах построенного, сам я больше по софту чем по железкам упарываюсь. Но мне понравились военкоматовские аналогии и ещё хорош концепт ментального рывка (вероятно в каждой профессии он свой, но везде есть - то, что отличает профи от любителя и где надо совершить это ментальное усилие)
Подразумевается видимо разница между конторами, в которых процесс подавления жоп происходит на ранних стадиях и конторами в которых успевают разгребать жопы на стадии когда они уже выросли в сочные, мясистые жопы. Так сказать риск-менеджмент есть и есть планомерная работа или когда горизонт планирования настолько узок, что нет времени подумать о том, как не доводить жопы до крупных неконтролируемых.
У Лили Ким была фраза "нам нужно сажать картошку чтобы есть картошку чтобы были силы снова сажать картошку" (колесо сансары), так вот это вот такая же дурная бесконечность, когда не успеваешь разгрести все жопы, поэтому нет сил подумать о том, как разгребать жопы на более ранних стадиях. (И квадрат Эйзенхауэра об этом же: надо забыть про несрочные и неважные жопы, а разгребать несрочные важные жопы пока они не доросли до срочных и важных жоп)
Аналогично думаю. Сидел 10 лет в одной конторе, при этом и проекты кардинально менялись и технологии (переходили на тот же докер/куб) и успел язык программирования сменить. Это не обязательно красный флаг, ситуации разные бывают. И можно просто поговорить, но даже по резюме это видно - так что если вас на этом этапе зарубают - то и к лучшему, что вы даже не потратили на такую компанию время.
Братья Стругацкие в "Граде" писали, что сложно жалеть сытого человека. Ведь большинство директоров-учредителей поди не на 30 тысяч рублей в месяц выгорают, верно?
Ну вообще, если вы разработчик - то лучше идти SWE, а не SRE (иногда некоторые путают, да). И не раскрыта тема "нужно SRE ли фигачить литкод и как им вообще готовиться к собесам".