Конечно, конечно, и знаменитому Шумахеру начали платить с 5 лет, когда он уже начал участвовать в гонках:
Карьера гонщика началась для Михаэля Шумахера с вождения карта, построенного его отцом Рольфом, бывшего управляющим местной трассой картинга. Шумахер сел за руль в возрасте четырёх лет, в пятилетнем возрасте участвовал в гонках на картах.
А без оплаты он конечно же за руль бы даже и не сел. Вот еще, участвовать в гонках только потому, что просто нравится.
Если есть пет-проект, то мужик работящий. А если нет, то человечек с гнильцой - кинет нас на аврале
Вы глумитесь. Наличие пет-проектов показывает, что человеку не лень в свое свободное время позаниматься программированием. Из чего следует, что программирование ему скорее всего нравится. А из этого следует, что его качество кода будет получше, чем в среднем. Опять же, код на github позволяет проверить, так это или нет.
А если человек говорит, что:
Свободное время, выходные дни и отпуска я провожу со своей семьёй и близкими мне людьми - с любимой женой, с родственниками, с друзьями.
То это как бы намекает, что написание кода для него - просто работа. А это уже другое отношение. И если ему за это не платят - то у него есть занятия и поинтереснее.
Опять же, с точки зрения обычного человека это абсолютно нормально. Но есть люди, которым с кодом приятнее проводить время, чем с друзьями, девушками и т.д., и вот таким людям выявить себе подобных можно только через пет-проекты с открытым кодом.
P.S.
Меня вообще поражает, как в среде программистов много людей, которые хвалятся тем, как им плевать на программирование, и что в свободное время у них есть дела и поинтереснее. Я вот ни разу не слышал про гонщиков, которые бы говорили "хорошо в отпуск съездил, ни разу за руль не садился". Вроде бы как обычно стремятся к тому, чтобы и работа и хобби были одним и тем же делом.
А как вам другой вариант - знакомитесь с человеком, он говорит "я художник, очень люблю рисовать, 10 лет уже работаю художником", вы просите его показать свои рисунки, а он "не могу, все что рисую - рисую для работы, а они показывать запретили", согласитесь несколько странно звучит?
Опять же, это не значит, что кто-то должен что-то делать в свое свободное время. Это, лично для меня, говорит о том, что работа для такого человека - это просто работа.
Соответственно, в какой-то критической ситуации (например, на проекте 100 багов на проде) - человек будет абсолютно спокоен - "мне задачи на исправление этих ошибок никто не ставил - какие вопросы?"
Опять же, человек по своему прав, но вот мне, человеку который не равнодушен к своей работе (и я хочу, чтобы проекты, над которыми работаю были качественными), работать с такими очень неприятно.
Понятно, значит в лайт-режиме. Из статьи кстати сложилось впечатление, что команда была за то, чтоб развиваться. Это очень сильно облегчает жизнь тех, кто хочет улучшить продукт и процессы. Чаще же всем пофигу. А иногда еще и мешают.
Не просто так не поднял про деньги вопрос, потому что он не был болезненным
Никогда не понимал таких фраз. Для меня закрытый финансовый вопрос - это когда можешь купить несколько квартир в Москве без ипотеки, и когда ежемесячно отправляешь ~1000$ родителям, которые сидят на нищенской пенсии.
Ну да ладно, видимо мои понятия нормальной зарплаты сильно расходятся с общественным мнением)
Но я все равно горел, делал ревью вечером в нерабочее время, а в рабочее время писал код.
Сколько лет это продолжалось? Вы ничего не пишите про проблемы со здоровьем, а они обязательно появляются, если вы действительно горите на работе и это продолжается несколько лет (хотя у каждого организма свой запас прочности).
Разделение улучшило процессы, но потащило за собой сайд эффекты в виде падения качества продуктов, потому что в командах самый старший был это мидл в лучшем случае.
Обычное дело. Есть средний уровень программиста и средний уровень разработки в компании. Можно приложить титанические усилия (если команда большая) и повысить качество разработки в целом, но если никому кроме вас это не нужно - то с вашим уходом обязательно процессы начнут скатываться в то, что было и до вас.
Выкинь меня из всей этой системы и все будет работать дальше как часы, чего невозможно было бы представить 1 или 2 года назад.
Очень сомневаюсь. Проекты очень легко скатываются в треш. Начиная от замусоривания ненужными технологиями/языками/зависимостями, которые добавляются потому, что Вася захотел попробовать технологию Х, и заканчивая отсутствием тестов, потому что «задача была срочная, сделал по быстрому, а потом доделаю» и это потом никогда не наступает.
Как вы наверное поняли, я обнулил и ушел на другой проект в более сильную команду на роль обычного разработчика. А что бы вы выбрали?
А по зарплате что? Забавно, но отличительная черта таких идейных работников - не упоминать финансовый вопрос вообще.
Не помню, да и не интересовался тогда. Помню в кабинете, где мы занимались практикой (паяли) стояли такие вот древние накопители, именно с таким переплетом.
CI/CD — это сейчас настолько общее место в любой IT-компании
Вам повезло с компаниями. У меня противоположность - только в одной компании из всех (штук 5) где работал, был настроен CI/CD. При чем девопса там не было, просто сами настроили.
Возможно особенности вебразработки на php - средний уровень очень низкий.
Админы - занимаются инфраструктурой для пользователей
DevOps - занимаются инфраструктурой для программ (проектов)
Всегда думал, что это устоявшиеся термины, и мешать их в одну кучу - такое себе. Например админ не должен знать как настраивать CI/CD, а девопс должен. Если в офисе перестал работать интернет - идут к админу. Если упал прод - идут к девопсу.
Другое дело, что в какой-нибудь маленькой компании могут нанять админа и требовать от него все - чтобы еще и сайт корпоративный сделал, но это уже нишевые проблемы.
Автор хотя бы довел свои безумные идеи до реализации
Это скорее недостаток. То, что на первый взгляд выглядит как «упорство и умение добиваться целей» (да и любой крупный проект превращается в бесконечную работу без конца и края), с другой стороны может оказаться неумением отбрасывать безперспективные цели/проекты. Сам на этом застрял.
Сравнивать же автора с какими-то суперуспешными мультимиллиардерами точно не стоит, и тем более вменять ему в вину
Никому ничего не вменяю, просто высказал удивление.
Плюс, есть большая разница между людьми, которые ничего не добились (тм), но всю жизнь прожили на расслабоне и получали удовольствие, и людьми, которые тоже ничего не добились, но всю жизнь пахали, и на дядю, и над своими проектами, на чем еще и здоровье свое подорвали. Опять же личный опыт.
И смысл поднимать эти темы и такой жизненный опыт вижу в том, чтобы другие, кто только жизнь начинает, не упарывались в работе. По крайней мере точно знали, что много работаешь не обязательно приводит к какому-то успеху.
Осознание, что выбранные мной специальности ошибочные, не приносят мне удовлетворения и нужно как-то "войти в IT", пришло только после окончания второго высшего. В результате, поступил на третье, уже связанное с IT. После этого я начал робкие попытки сменить полностью свою специальность.
Как все сложно.
Есть такая черта - умение, или неумение решать свои задачи (например, получать от жизни удовольствие) наиболее оптимальным и простым способом. Замечаю, что у меня этот навык так себе, не умею идти простым путем. Но автор просто анти-рекордсмен.
С другой стороны, многие всю жизнь проводят на нелюбимой работе...
P.S. Тема финансирования больная для всех, но что на счет того, чтобы просто увеличить доход с основной работы? Большой опыт работы + знание английского + работа на зарубежных работодателей позволяет получать сильно больше средних, даже московских зарплат. А там уже можно откладывать на год отпуска.
На коммерческих проектах бизнес решает оплачивать написание тестов или не оплачивать
Вы лишь доказали, то, что я написал)
Нет, ну серьезно, ниужели вы не слышали хотя бы истории строителей, когда они делали не так, как надо, а так как хотел заказчик, и что ничего хорошего из этого не получалось? При чем выноватым всегда остается тот, кто делал, он же специалист.
Бизнес нужно спрашивать что ему нужно, а вот как делать - решают программисты.
Не всегда процент покрытия тестами говорит о качестве кода.
Как там говорят - кто борется, может проиграть, кто не борется, тот уже проиграл.
Если у человека есть личные проекты (и они не в виде Hello World - это, понятное дело, ни о чем) - то большую часть собеседования я бы обсуждал именно их. Человек, который чужой проект выставляет за свой - очень быстро поплывет при обсуждении.
Только что мы разговаривали про нагрузочное и интеграционное тестирование, и, оказывается, он не знаем что такое стек, или структура данных, или… Да, я реально разговаривал с людьми, которые не знают, что такое рекурсия и стек!
Потом столкнулись с таким во второй раз. Было очень больно.
Если мне два кандидата, покажут свои домашние проекты, на одном авто-тесты с 90+% покрытием и CI/CD, но он не знает всего вышеперечисленного, а у другого нет авто-тестов, но в теории он прям все знает - я выберу первого.
На практике самое сложное - это добиться того, чтобы даже простой код на проде работал и не ломался. Не смотря на постоянные обновления и расширения функционала. Не смотря на смену программистов.
Теория это все здорово, но она не всегда конвертируется в надежный код. Более того, замечаю такой интересный феномен, что если программист работает много лет, но так и не дошел до написания тестов - то дальше он скорее всего их никогда и не будет писать. Видимо у человека появляется корона на голове, и писать "скучные" тесты это ниже его достоинства.
P.S. Конечно, в программировании много специфичных сфер. Но в веб-бекенде, где под капотом по микросервисам гоняются json-чики - самой сложной задачей оказываются элементарные вещи: чтобы API возвращало то, что написано в документации, чтобы отправленные данные, пройдя через 10 микросервисов, не сломались по дороге. Казалось бы, ничего сложного - просто внимательно пишите авто-тесты, просто настройте CI/CD, просто не ленитесь обновлять тесты под изменившуюся логику, но... 90% команд этого не могут. И получаем бесконечные баги-баги-баги...
И да, "80 на 20" автор так же не отрицает. Нюанс в том, что первые 80 могут быть освоены за пару недель-месяцев и этого хватит для большинства задач. А оставшиеся 20 да, довольно трудозатратны в освоении, наполнены очень необычными и красивыми вещами, но крайне редко применяются а боевых условиях, ибо поддерживать такое ну очень накладно.
Не знаю о каких 80 на 20 вы говорите. Я с php работаю с 2008 года, и считаю что значительная часть знания этого языка заключается в понимании какие фреймворки использовать не стоит (к слову, не только я отмечаю, что хороший специалист это не только тот, кто знает как и что работает, а тот, кто также знает что использовать не нужно). Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 - это будет тоже самое, что плыть против течения.
А вот чтобы понять, что в языке есть, но использовать не нужно - нужны годы опыта и наблюдений разных проектов и команд.
Хотя и такое понимание приходит только тогда, когда перестаешь довольствоваться тем, что код «просто работает».
Сейчас изучаю Go в свободое время, и то, что я что-то написал на нем, и оно как-то работает - вообще не показатель знания языка. В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте. Через месяц работы - рассказать о судьбе проекта в будущем (жду, когда научусь это делать сразу на собеседовании).
В общем, знать синтаксис и уметь написать что-то, чтобы оно работало - это вообще не говорит о каком-то знании языка. Другое дело, что к сожалению кто-то на таком уровне и остается на всю жизнь.
Конечно, конечно, и знаменитому Шумахеру начали платить с 5 лет, когда он уже начал участвовать в гонках:
А без оплаты он конечно же за руль бы даже и не сел. Вот еще, участвовать в гонках только потому, что просто нравится.
Вы глумитесь. Наличие пет-проектов показывает, что человеку не лень в свое свободное время позаниматься программированием. Из чего следует, что программирование ему скорее всего нравится. А из этого следует, что его качество кода будет получше, чем в среднем. Опять же, код на github позволяет проверить, так это или нет.
А если человек говорит, что:
То это как бы намекает, что написание кода для него - просто работа. А это уже другое отношение. И если ему за это не платят - то у него есть занятия и поинтереснее.
Опять же, с точки зрения обычного человека это абсолютно нормально. Но есть люди, которым с кодом приятнее проводить время, чем с друзьями, девушками и т.д., и вот таким людям выявить себе подобных можно только через пет-проекты с открытым кодом.
P.S.
Меня вообще поражает, как в среде программистов много людей, которые хвалятся тем, как им плевать на программирование, и что в свободное время у них есть дела и поинтереснее. Я вот ни разу не слышал про гонщиков, которые бы говорили "хорошо в отпуск съездил, ни разу за руль не садился". Вроде бы как обычно стремятся к тому, чтобы и работа и хобби были одним и тем же делом.
И денег
А как вам другой вариант - знакомитесь с человеком, он говорит "я художник, очень люблю рисовать, 10 лет уже работаю художником", вы просите его показать свои рисунки, а он "не могу, все что рисую - рисую для работы, а они показывать запретили", согласитесь несколько странно звучит?
Опять же, это не значит, что кто-то должен что-то делать в свое свободное время. Это, лично для меня, говорит о том, что работа для такого человека - это просто работа.
Соответственно, в какой-то критической ситуации (например, на проекте 100 багов на проде) - человек будет абсолютно спокоен - "мне задачи на исправление этих ошибок никто не ставил - какие вопросы?"
Опять же, человек по своему прав, но вот мне, человеку который не равнодушен к своей работе (и я хочу, чтобы проекты, над которыми работаю были качественными), работать с такими очень неприятно.
Понятно, значит в лайт-режиме. Из статьи кстати сложилось впечатление, что команда была за то, чтоб развиваться. Это очень сильно облегчает жизнь тех, кто хочет улучшить продукт и процессы. Чаще же всем пофигу. А иногда еще и мешают.
Никогда не понимал таких фраз. Для меня закрытый финансовый вопрос - это когда можешь купить несколько квартир в Москве без ипотеки, и когда ежемесячно отправляешь ~1000$ родителям, которые сидят на нищенской пенсии.
Ну да ладно, видимо мои понятия нормальной зарплаты сильно расходятся с общественным мнением)
Сколько лет это продолжалось? Вы ничего не пишите про проблемы со здоровьем, а они обязательно появляются, если вы действительно горите на работе и это продолжается несколько лет (хотя у каждого организма свой запас прочности).
Обычное дело. Есть средний уровень программиста и средний уровень разработки в компании. Можно приложить титанические усилия (если команда большая) и повысить качество разработки в целом, но если никому кроме вас это не нужно - то с вашим уходом обязательно процессы начнут скатываться в то, что было и до вас.
Очень сомневаюсь. Проекты очень легко скатываются в треш. Начиная от замусоривания ненужными технологиями/языками/зависимостями, которые добавляются потому, что Вася захотел попробовать технологию Х, и заканчивая отсутствием тестов, потому что «задача была срочная, сделал по быстрому, а потом доделаю» и это потом никогда не наступает.
А по зарплате что? Забавно, но отличительная черта таких идейных работников - не упоминать финансовый вопрос вообще.
Все зависит от человека. Если человек мягкий и пытается всем понравится - на шею сядут в любой компании, потому что это свойство не компании, а людей.
Не помню, да и не интересовался тогда. Помню в кабинете, где мы занимались практикой (паяли) стояли такие вот древние накопители, именно с таким переплетом.
Это было в 2003-2004 годах, очень давно)
О, у нас в техникуме такие стояли (как на первом скриншоте). Раритетные штуки.
Даже немного завидую людям, которые вокруг себя видят проблему в не знании чего-либо
Я вижу проблему в том, что людям просто пофигу.
Написал код - зачем тестировать - пользователи протестируют, если что - сообщат об ошибке.
Написал код - зачем покрывать тестами - и так работает.
Нашел ошибку - зачем править, если пользователи молчат - значит все ок
Куча техдолга в проекте - пофигу, все равно уволюсь.
И так далее.
Он включен по умолчанию, начиная, если не ошибаюсь, с версии 5.6
В текущем описании читателю может показаться, что это что-то, что нужно включать отдельно.
Вам повезло с компаниями. У меня противоположность - только в одной компании из всех (штук 5) где работал, был настроен CI/CD. При чем девопса там не было, просто сами настроили.
Возможно особенности вебразработки на php - средний уровень очень низкий.
Админы - занимаются инфраструктурой для пользователей
DevOps - занимаются инфраструктурой для программ (проектов)
Всегда думал, что это устоявшиеся термины, и мешать их в одну кучу - такое себе. Например админ не должен знать как настраивать CI/CD, а девопс должен. Если в офисе перестал работать интернет - идут к админу. Если упал прод - идут к девопсу.
Другое дело, что в какой-нибудь маленькой компании могут нанять админа и требовать от него все - чтобы еще и сайт корпоративный сделал, но это уже нишевые проблемы.
Это скорее недостаток. То, что на первый взгляд выглядит как «упорство и умение добиваться целей» (да и любой крупный проект превращается в бесконечную работу без конца и края), с другой стороны может оказаться неумением отбрасывать безперспективные цели/проекты. Сам на этом застрял.
Никому ничего не вменяю, просто высказал удивление.
Плюс, есть большая разница между людьми, которые ничего не добились (тм), но всю жизнь прожили на расслабоне и получали удовольствие, и людьми, которые тоже ничего не добились, но всю жизнь пахали, и на дядю, и над своими проектами, на чем еще и здоровье свое подорвали. Опять же личный опыт.
И смысл поднимать эти темы и такой жизненный опыт вижу в том, чтобы другие, кто только жизнь начинает, не упарывались в работе. По крайней мере точно знали, что много работаешь не обязательно приводит к какому-то успеху.
Как все сложно.
Есть такая черта - умение, или неумение решать свои задачи (например, получать от жизни удовольствие) наиболее оптимальным и простым способом. Замечаю, что у меня этот навык так себе, не умею идти простым путем. Но автор просто анти-рекордсмен.
С другой стороны, многие всю жизнь проводят на нелюбимой работе...
P.S. Тема финансирования больная для всех, но что на счет того, чтобы просто увеличить доход с основной работы? Большой опыт работы + знание английского + работа на зарубежных работодателей позволяет получать сильно больше средних, даже московских зарплат. А там уже можно откладывать на год отпуска.
Компания сжалится и вышлет вам оффер с зарплатой чуть выше джуна. Ну а что вы хотели - вы ведь еще столько не знаете!
Вы лишь доказали, то, что я написал)
Нет, ну серьезно, ниужели вы не слышали хотя бы истории строителей, когда они делали не так, как надо, а так как хотел заказчик, и что ничего хорошего из этого не получалось? При чем выноватым всегда остается тот, кто делал, он же специалист.
Бизнес нужно спрашивать что ему нужно, а вот как делать - решают программисты.
Как там говорят - кто борется, может проиграть, кто не борется, тот уже проиграл.
Если у человека есть личные проекты (и они не в виде Hello World - это, понятное дело, ни о чем) - то большую часть собеседования я бы обсуждал именно их. Человек, который чужой проект выставляет за свой - очень быстро поплывет при обсуждении.
Если мне два кандидата, покажут свои домашние проекты, на одном авто-тесты с 90+% покрытием и CI/CD, но он не знает всего вышеперечисленного, а у другого нет авто-тестов, но в теории он прям все знает - я выберу первого.
На практике самое сложное - это добиться того, чтобы даже простой код на проде работал и не ломался. Не смотря на постоянные обновления и расширения функционала. Не смотря на смену программистов.
Теория это все здорово, но она не всегда конвертируется в надежный код. Более того, замечаю такой интересный феномен, что если программист работает много лет, но так и не дошел до написания тестов - то дальше он скорее всего их никогда и не будет писать. Видимо у человека появляется корона на голове, и писать "скучные" тесты это ниже его достоинства.
P.S. Конечно, в программировании много специфичных сфер. Но в веб-бекенде, где под капотом по микросервисам гоняются json-чики - самой сложной задачей оказываются элементарные вещи: чтобы API возвращало то, что написано в документации, чтобы отправленные данные, пройдя через 10 микросервисов, не сломались по дороге. Казалось бы, ничего сложного - просто внимательно пишите авто-тесты, просто настройте CI/CD, просто не ленитесь обновлять тесты под изменившуюся логику, но... 90% команд этого не могут. И получаем бесконечные баги-баги-баги...
Не знаю о каких 80 на 20 вы говорите. Я с php работаю с 2008 года, и считаю что значительная часть знания этого языка заключается в понимании какие фреймворки использовать не стоит (к слову, не только я отмечаю, что хороший специалист это не только тот, кто знает как и что работает, а тот, кто также знает что использовать не нужно). Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 - это будет тоже самое, что плыть против течения.
А вот чтобы понять, что в языке есть, но использовать не нужно - нужны годы опыта и наблюдений разных проектов и команд.
Хотя и такое понимание приходит только тогда, когда перестаешь довольствоваться тем, что код «просто работает».
Сейчас изучаю Go в свободое время, и то, что я что-то написал на нем, и оно как-то работает - вообще не показатель знания языка. В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте. Через месяц работы - рассказать о судьбе проекта в будущем (жду, когда научусь это делать сразу на собеседовании).
В общем, знать синтаксис и уметь написать что-то, чтобы оно работало - это вообще не говорит о каком-то знании языка. Другое дело, что к сожалению кто-то на таком уровне и остается на всю жизнь.