Я долго ждал подобного комментария и был удивлен, что он долго не появлялся.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Из комментария следует, что заключение верно на все 100%: пересиливаешь себя — лучше сразу остановиться и не мучать себя. Не хочешь менеджерить и кодить — попробуй обучать.
• ну так в пермом случае главному герою было лет 20-22 и он смотрит на тимлида, как на старика.
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
Я так понимаю, что вместе с этим комментарием прилетел и — в карму ;-)
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
Это достойно отдельной статьи и обсуждения.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
Тут есть один нюанс: В классическом разделении есть только soft-skills и hard-skills.
Я же разделил hard-skills на 2 части
hard-skills — это фундаментальные знания и опыт
tech-skills — это знания именно в конкретной технологии, надстройка, как вы говорите
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
value = ( 0.5 * <знание фреймворка> + 1,0 * <знание принципов программирования> + 1,5 * <умение работать в коллективе>) / 3
Еще помогает интерактивность, например, показ конкретного значения на графике при наведении указателя, чем, собственно, страдает «печатная» инфографика
Ключевое слово было инициализации, т.е. когда вы точно уверены, что MITM атаки нет, а если уверенности нет, то можно использовать отдельное хранилище или пример с https, что я приводил выше.
Технически не мешает и подобное я часто использую (делал внутренний доклад про сценарии использования, однако, на Хабре уже есть статьи на эту тему), но что, если надо зайти на сервер и выполнить
$ git pull
Или scp или rsync да и много чего ещё (на самом деле нет).
Можно использовать парольную аутентификацию или извращаться, а можно воспользоваться агентом.
Часто встречаю ситуацию когда на серверах разработки код стянут по https, ты вызываешь
git pull
А у тебя GIT спрашивает пароль какого-то разраба. Почему нельзя было склонить по SSH? Секурность? Нет — глу… незнание
асскажите, как вы будете управлять ключами десяти тысяч сотрудников на трёх сотнях тысяч серверов.
PAM?
На хабре была статья про использование промежуточных SSH серверов, через них уже ппоизводился выход на целевые сервера. Опять же, если рассматривать тысячи серверов, то это уже enterprise решения и выходит за рамки этой статьи
У меня опыт был использования PAM + ldap для управления пользователями
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Никогда не считал себя гуманитарием
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
Я же разделил hard-skills на 2 части
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
Будущее k8s неотвратимо. Я (как ярый сомневающийся) сейчас уже почти точно решил их попробовать. Спасибо за статью.
Ключевое слово было инициализации, т.е. когда вы точно уверены, что MITM атаки нет, а если уверенности нет, то можно использовать отдельное хранилище или пример с https, что я приводил выше.
Технически не мешает и подобное я часто использую (делал внутренний доклад про сценарии использования, однако, на Хабре уже есть статьи на эту тему), но что, если надо зайти на сервер и выполнить
Или
scpилиrsyncда и много чего ещё (на самом деле нет).Можно использовать парольную аутентификацию или извращаться, а можно воспользоваться агентом.
Часто встречаю ситуацию когда на серверах разработки код стянут по https, ты вызываешь
А у тебя
GITспрашивает пароль какого-то разраба. Почему нельзя было склонить по SSH? Секурность? Нет — глу… незнаниеЯ могу предложить только временные ключи на время сессии
PAM?
На хабре была статья про использование промежуточных SSH серверов, через них уже ппоизводился выход на целевые сервера. Опять же, если рассматривать тысячи серверов, то это уже enterprise решения и выходит за рамки этой статьи
У меня опыт был использования PAM + ldap для управления пользователями
А в энтерпрайзе другие подходы