Интересная история. Это уже совсем крайний случай с копированием кода. В местах, где я работал такие бы испытательный срок не прошли.
Софт-скиллы софт-скиллами, но хард-скиллы не должны быть на нуле)
Понятно всё — в компании нет девопса и релизы происходят через ж, вот им и нужны "полуадмины", которые ещё в "другие отделы" будут ходить релизить. Сервер-то небось у бухгалтеров стоит, а сторожат его безопасники, угу.
Нет, совсем не так. Процесс деплоя очень хорошо настроен. Но если разработчик может поправить порт нужный в конфиге кубера или написать докер-композ, то это имхо делает его больше сеньором.
Работал в компании, где пару лет все собирались пилить опенсорс. До самой разработки не дошло, т.к. сначала были проблемы с идеями. Далее менеджмент решил, что разработчики будут рады развивать бренд компании в свое время за даром. Так в итоге и не задалось
Хотя уверен, что если менеджмент идет навстречу, то это и плюс для компании и плюс в резюме. И хороший вклад в развитие комьюнити
1) На моей памяти, работать с микросервисами намного сложнее в организационном плане. Повышается область ответственности разработчика - вот тут и причина.
2) На собеседовании мало что можно проверить. Только если откровенных социопатов. Все-таки прохождение собеседований это отдельный навык. И люди действительно могут отличаться на них и в реальной работе
Всегда казалось, что лучше не напишет инструкцию тот, кто это создавал.
Поясните, пожалуйста, как это происходит. Вы у технических специалистов расспрашиваете всевозможные детали и потом пишете? Или на основе инструкций чужих более бедных создаете свою, более полную?
Очень правильный подход. Жаль только, что это в основном в коммерческом обучении так может быть. В университетах преподаватели чаще поступают с точностью наоборот)
Самые заметные изменения языка php за последние годы
Спасибо за статью! Осталось дождаться, когда concurrency завезут)
Представление о современном backend-разработчике
Интересная история. Это уже совсем крайний случай с копированием кода. В местах, где я работал такие бы испытательный срок не прошли.
Софт-скиллы софт-скиллами, но хард-скиллы не должны быть на нуле)
Нет, совсем не так. Процесс деплоя очень хорошо настроен. Но если разработчик может поправить порт нужный в конфиге кубера или написать докер-композ, то это имхо делает его больше сеньором.
Пять причин для ИТ-компании полюбить опенсорс
Работал в компании, где пару лет все собирались пилить опенсорс. До самой разработки не дошло, т.к. сначала были проблемы с идеями. Далее менеджмент решил, что разработчики будут рады развивать бренд компании в свое время за даром. Так в итоге и не задалось
Хотя уверен, что если менеджмент идет навстречу, то это и плюс для компании и плюс в резюме. И хороший вклад в развитие комьюнити
Представление о современном backend-разработчике
1) На моей памяти, работать с микросервисами намного сложнее в организационном плане. Повышается область ответственности разработчика - вот тут и причина.
2) На собеседовании мало что можно проверить. Только если откровенных социопатов. Все-таки прохождение собеседований это отдельный навык. И люди действительно могут отличаться на них и в реальной работе
Представление о современном backend-разработчике
Я не писал, что хард-скилы не важны. Мысль в том, что они переоценены
А нормальны ли нормы?
Получается, сейчас используются референсные значения, чтобы запугивать пациентов. Прописывать лекарства и брать деньги за еще один прием
Технический писатель в ИТ
Всегда казалось, что лучше не напишет инструкцию тот, кто это создавал.
Поясните, пожалуйста, как это происходит. Вы у технических специалистов расспрашиваете всевозможные детали и потом пишете? Или на основе инструкций чужих более бедных создаете свою, более полную?
Григорий Остер — Вредные советы для учителей программировать
Очень правильный подход. Жаль только, что это в основном в коммерческом обучении так может быть. В университетах преподаватели чаще поступают с точностью наоборот)