Потому что если в какой-нибудь отпуск, у вас не появляется желания «запилить что-нибудь этакое», или если это желание улетучивается через 1-2 недели — напрашивается вывод, а нравится ли вам вообще программирование?
Лично я полноценное удовольствие от программирования получаю только при работе над пет-проектами. Когда делаешь что хочешь и как хочешь.
Иногда, я задаю себе вопрос: почему я не могу радоваться как другие? Почему есть те, которые машут в камеру заказчику раз в сутки, гоняют х*и джейсонки и им норм?
Может быть, потому что мы за «джейсончиками» видим проекты, которые нужны людям и людей, которые ими пользуются и решают свои проблемы?
Ну а еще, делая любой новый проект, мне по спортивному интересно — выстрелит или нет.
В книге Антихрупкость, автор Нассим Талеб пишет о том что погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.
На какие только ухищрения слов и терминов не идут программисты, лишь бы донести владельцам бизнесов простую мысль, что за скорость всегда приходится платить качеством
Кто-нибудь может посоветовать литературу о том, как разрабатывают ПО для тех областей, где программа не имеет права «зависнуть», «выдать ошибку», и вообще должна работать даже в том случае, если по ней ударили молотком — т.е. продолжать работать, даже если часть железа повреждена.
Очень интересно, какие подходы в разработке железа и ПО используются в таких областях.
Ну, я вот четко соблюдаю свои обязанности. Из своего круга знакомых я единственный человек, который работу ищет (т.е. ходит по собеседованиям) только в отпуск.
И это никак не защищает от того, чтобы кто-то не пытался сесть на шею.
Вообще любовь к своей работе, и желание сделать её хорошо — она из зацепок, за которую могут цепляться и садиться на шею. Постоянно себя приучаю хладнокровно относиться к рабочим проектам, и не пытаться сделать их лучше, чем это нужно работодателю (потому что периодически, в некоторых компаниях, ловил себя на мысли, что мне качественный продукт важен важнее, чем самому бизнесу — WTF?)
Есть такая проблема, в некоторых компания очень процветает.
Что не было озвучено в статье, и что стоит добавить:
Плавающие обязанности тем более плавающие, чем меньше бизнес. Для тех, кто хочет выполнять только свои обязанности и ни капли больше — присматривайтесь к крупным компаниям.
«Кто везет — на том и едут». По этому, если вам активно садятся на шею с новыми задачами — значит видят в вас человека, который эти задачи может сделать. Можно или становиться «раздолбаем» в непрофильных вещах, и разводя руками говорить «не получилось», или начинать пользоваться тем, что вы выполняете все больше и больше обязанностей — например, попросить повышение.
Ну и главное, о чем, почему-то не написано в статье, но что нужно писать большими жирными буквами — Догвилль лучше всего работает на тех, кто не уважает себя и свое время.
7. Соглашаться на неадекватные требования руководства/заказчика.
Например, вас просят сделать задачу в крайне сжатые сроки, говоря при этом «качество не важно, главное, чтобы работало, потом доработаете» — будьте уверенны, потом никогда не наступит, а за плохой код вас обязательно спросят. А о том, что код писался в жуткой спешке — никто не вспомнит.
По этому, в правильно составленном ТЗ должно быть об этом сказано — реализовывать максимально просто и только то, что указано в ТЗ, или сделать с возможностью расширения функционала в дальнейшем.
На сколько понял — в тестовом у автора ничего такого сказано не было, соответственно некорректно обвинять его в том, что он выбрал «энтерпрайз» подход, а ожидался иной.
Писал ниже, но отвечу и здесь — вот что сами HR пишут о тестовых:
Если вы претендуете на опытных экспертов, постарайтесь обойтись без тестового (особенно при найме опытных кандидатов senior уровня). Мотивация делать тестовое есть только у junior или тех, кто мечтает о работе в вашей компании.
По этому, если вы не ждут (а по вашему github вы не джун) — лесом эти тестовые! Уважайте себя и свое время, и будут уважать вас.
Умение пройти по тонкой тропинке между слишком простой и переусложненной архитектурой — это в общем одна из основных задач которую приходится решать разработчику высокого уровня.
А я бы сказал по другому — простота реализации с одной стороны, и недостаточная гибкость и расширяемость решения — это два разных конца одной палки, и какой бы классный программист не был, какой бы хороший код он не написал — его всегда можно упрекнуть в том, что код или переусложнен (а значит можно было сделать быстрее и проще), или его код не расширяем (сделано слишком просто).
Кто-то скажет, что нужно соблюдать золотую середину — вот только практика показывает, что золотая середина у каждого своя.
Если кто-то вас в подобном начинает упрекать — говорите ему, пусть в ТЗ пишет нужную простоту, или нужную расширяемость в дальнейшем. Иначе можно быть всегда виноватым.
Если вы претендуете на опытных экспертов, постарайтесь обойтись без тестового (особенно при найме опытных кандидатов senior уровня). Мотивация делать тестовое есть только у junior или тех, кто мечтает о работе в вашей компании.
Получается, если хороший программист согласился на выполнение тестового (у вас история на github идет с 2012 года — джуниором никак не назвать) — то он уже принизил себя.
Второй момент, о котором они прямо написали:
сложнее, чем могло бы быть
Т.е. они ожидали простое тяп-ляп решение на пару файлов. Ваш случай не уникальный — когда программист делает тестовое задание не тяп-ляп за часик, а качественно (еще и с тестами) — то это воспринимается хуже. Потому что «чет сложно, много кода, и вникать лень».
Как там говорят:
Не бросайте жемчуга перед свиньями
В текущем случае можно сказать: «Не бросайте жемчуга перед теми, кто его не ждет»
Ценится опыт разработки highload-проектов, а также опыт разработки продуктов/проектов/крупных и сложных фичей с нуля.
Забавно, но мне, как разработчику, значительно проще писать крупный и сложный проект с нуля, чем включаться в работу над проектом, который до этого 5-10 лет писали другие программисты.
Опыт работы с нативным языком часто ценится больше, чем опыт написания кода только с использованием фреймворка.
Удивительно, но «велосипедить», опять же, сильно проще, чем писать качественный код на современном фреймворке (том же Symfony в PHP).
Моя карьера «чистого и серьезного» программиста началась в 30 лет.
До этого было много всего, начиная от различных не-ИТ-профессий, и заканчивая SEO/маркетингом в том же ИТ.
И знаете что бросается в глаза, при переходе в коллективы программистов? Что сложно себе представить более подверженных маркетингу людей, чем программистов. Не знаю с чем это связано, но вот складывается впечатление, что банальная, базовая защита от всяких там «купи-купи, вам это подойдет», которая есть у каждого современного человека, у программистов напрочь отсутствует.
Выходит какая-то новая технология. Маркетолог пишет продающий текст о том, какая она классная — и программисты воспринимают это за чистую правду. И не просто бегут пробовать и внедрять эту технологию, а начинают агитировать всех окружающих.
P.S.
С чем это связано — для меня загадка. Может быть, так решается внутреннее желание отрефакторить старый код. Ведь если просто сказать — «надо все переписать» — то нужно будет признать, что код был плохой (и сразу падает тень на тех, кто его писал). А если рефакторинг делается под предлогом «монолит это плохо, вот сейчас все перепишем на микросервисы и будет круто» — то звучит уже не так стыдно.
Соглашусь, добавил бы еще то, что геймдев часто равнозначен нестабильности.
Проекты начинаются и закрываются очень быстро, и если вы приходите в компанию с одним проектом — может оказаться так, что скоро проект с компанией закроют, а вы останетесь на улице. Это особенно неприятно, когда вы получали другие хорошие (и надежные) предложения по работе, но выбрали геймдев «потому что это здорово».
Ни разу не здорово.
Я для себя решил, что если хочется делать игры — лучше работать в ненапряжной работе днем, а игру пилить для души по вечерам.
Делать оценки можно разве что очень приблизительно — день, неделя, месяц. Когда начинают требовать точные сроки — это лишь добавляет работы (считать сроки это тоже работа) и нервотрепки (ой-ой не успеваем в сроки).
Единственный вариант, который как-то на практике помогает в таких ситуациях — это, во первых, предупреждать, что считать сроки — тоже работа, и тоже требует времени, а во вторых, считая, не забывать доносить о том, что «На подсчет сроков такой-то задачи ушло 2 дня». Чтобы руководство знало, что 2 дня программист не код писал, а декомпозировал задачу на самые элементарные подзадачи, прикидывал время на их выполнение, закрывал все неточности в ТЗ.
Ну а самое забавное, это когда на исправление бага требуют обозначить сроки. Особенно, в чужом коде — откуда программист может заранее сказать, решится ли ошибка изменением одной строчки, за 30 минут, или там половину проекта придется переписывать.
P.S.
Самый главный обман, в который попадает офисный разработчик, когда от него требуют четких сроков, и четкого соблюдения сроков — это то, что зарплату он получает за часы работы, а требуют от него уже фактического выполнения задач. Оплата за выполненные задачи — это вообще-то из другой области (там, где не нужно сидеть о офисе, там, где исполнитель сам решает когда и сколько сегодня он будет работать, там, где сделал задачу и свободен).
А так получается, что программист честно отрабатывает свои 40 часов в неделю (а иногда еще и больше), и при этом чувствует себя виноватым. WTF?
Из опыта найма копирайтеров на фрилансе, могу сказать, что женщины в среднем более усердны, и больше готовы выполнять работу качественно.
Среди мужчин такое встречается реже. На в скидку, можно 70% с первого раза встретить хорошую девушку-копирайтера, и 40% с первого раза встретить хорошего мужчину-копирайтера. Плюс женщины дольше готовы сотрудничать. Мужчины, видимо, понимают, что фигней какой-то страдают, и быстро меняют сферу деятельности (в большинстве случаев).
Работать с девушками в программировании (чтобы долго и с разными) не доводилось.
Очень тревожный звоночек на самом деле.
Потому что если в какой-нибудь отпуск, у вас не появляется желания «запилить что-нибудь этакое», или если это желание улетучивается через 1-2 недели — напрашивается вывод, а нравится ли вам вообще программирование?
Лично я полноценное удовольствие от программирования получаю только при работе над пет-проектами. Когда делаешь что хочешь и как хочешь.
Может быть, потому что мы за «джейсончиками» видим проекты, которые нужны людям и людей, которые ими пользуются и решают свои проблемы?
Ну а еще, делая любой новый проект, мне по спортивному интересно — выстрелит или нет.
А кто сказал, что это небольшое требование?
На какие только ухищрения слов и терминов не идут программисты, лишь бы донести владельцам бизнесов простую мысль, что за скорость всегда приходится платить качеством
Кто-нибудь может посоветовать литературу о том, как разрабатывают ПО для тех областей, где программа не имеет права «зависнуть», «выдать ошибку», и вообще должна работать даже в том случае, если по ней ударили молотком — т.е. продолжать работать, даже если часть железа повреждена.
Очень интересно, какие подходы в разработке железа и ПО используются в таких областях.
И это никак не защищает от того, чтобы кто-то не пытался сесть на шею.
Вообще любовь к своей работе, и желание сделать её хорошо — она из зацепок, за которую могут цепляться и садиться на шею. Постоянно себя приучаю хладнокровно относиться к рабочим проектам, и не пытаться сделать их лучше, чем это нужно работодателю (потому что периодически, в некоторых компаниях, ловил себя на мысли, что мне качественный продукт важен важнее, чем самому бизнесу — WTF?)
Что не было озвучено в статье, и что стоит добавить:
Ну и главное, о чем, почему-то не написано в статье, но что нужно писать большими жирными буквами — Догвилль лучше всего работает на тех, кто не уважает себя и свое время.
Например, вас просят сделать задачу в крайне сжатые сроки, говоря при этом «качество не важно, главное, чтобы работало, потом доработаете» — будьте уверенны, потом никогда не наступит, а за плохой код вас обязательно спросят. А о том, что код писался в жуткой спешке — никто не вспомнит.
На сколько понял — в тестовом у автора ничего такого сказано не было, соответственно некорректно обвинять его в том, что он выбрал «энтерпрайз» подход, а ожидался иной.
По этому, если вы не ждут (а по вашему github вы не джун) — лесом эти тестовые! Уважайте себя и свое время, и будут уважать вас.
А я бы сказал по другому — простота реализации с одной стороны, и недостаточная гибкость и расширяемость решения — это два разных конца одной палки, и какой бы классный программист не был, какой бы хороший код он не написал — его всегда можно упрекнуть в том, что код или переусложнен (а значит можно было сделать быстрее и проще), или его код не расширяем (сделано слишком просто).
Кто-то скажет, что нужно соблюдать золотую середину — вот только практика показывает, что золотая середина у каждого своя.
Если кто-то вас в подобном начинает упрекать — говорите ему, пусть в ТЗ пишет нужную простоту, или нужную расширяемость в дальнейшем. Иначе можно быть всегда виноватым.
Вы столкнулись с предвзятостью, которая заключается в двух моментах.
Во первых, вот что говорят сами HR о тестовых:
Получается, если хороший программист согласился на выполнение тестового (у вас история на github идет с 2012 года — джуниором никак не назвать) — то он уже принизил себя.
Второй момент, о котором они прямо написали:
Т.е. они ожидали простое тяп-ляп решение на пару файлов. Ваш случай не уникальный — когда программист делает тестовое задание не тяп-ляп за часик, а качественно (еще и с тестами) — то это воспринимается хуже. Потому что «чет сложно, много кода, и вникать лень».
Как там говорят:
В текущем случае можно сказать: «Не бросайте жемчуга перед теми, кто его не ждет»
Забавно, но мне, как разработчику, значительно проще писать крупный и сложный проект с нуля, чем включаться в работу над проектом, который до этого 5-10 лет писали другие программисты.
Удивительно, но «велосипедить», опять же, сильно проще, чем писать качественный код на современном фреймворке (том же Symfony в PHP).
До этого было много всего, начиная от различных не-ИТ-профессий, и заканчивая SEO/маркетингом в том же ИТ.
И знаете что бросается в глаза, при переходе в коллективы программистов? Что сложно себе представить более подверженных маркетингу людей, чем программистов. Не знаю с чем это связано, но вот складывается впечатление, что банальная, базовая защита от всяких там «купи-купи, вам это подойдет», которая есть у каждого современного человека, у программистов напрочь отсутствует.
Выходит какая-то новая технология. Маркетолог пишет продающий текст о том, какая она классная — и программисты воспринимают это за чистую правду. И не просто бегут пробовать и внедрять эту технологию, а начинают агитировать всех окружающих.
P.S.
С чем это связано — для меня загадка. Может быть, так решается внутреннее желание отрефакторить старый код. Ведь если просто сказать — «надо все переписать» — то нужно будет признать, что код был плохой (и сразу падает тень на тех, кто его писал). А если рефакторинг делается под предлогом «монолит это плохо, вот сейчас все перепишем на микросервисы и будет круто» — то звучит уже не так стыдно.
Мне бы так :)
Столько всего нужно изучать, а свободного от работы времени так мало…
Проекты начинаются и закрываются очень быстро, и если вы приходите в компанию с одним проектом — может оказаться так, что скоро проект с компанией закроют, а вы останетесь на улице. Это особенно неприятно, когда вы получали другие хорошие (и надежные) предложения по работе, но выбрали геймдев «потому что это здорово».
Ни разу не здорово.
Пришел точно к такому же выводу.
Делать оценки можно разве что очень приблизительно — день, неделя, месяц. Когда начинают требовать точные сроки — это лишь добавляет работы (считать сроки это тоже работа) и нервотрепки (ой-ой не успеваем в сроки).
Единственный вариант, который как-то на практике помогает в таких ситуациях — это, во первых, предупреждать, что считать сроки — тоже работа, и тоже требует времени, а во вторых, считая, не забывать доносить о том, что «На подсчет сроков такой-то задачи ушло 2 дня». Чтобы руководство знало, что 2 дня программист не код писал, а декомпозировал задачу на самые элементарные подзадачи, прикидывал время на их выполнение, закрывал все неточности в ТЗ.
Ну а самое забавное, это когда на исправление бага требуют обозначить сроки. Особенно, в чужом коде — откуда программист может заранее сказать, решится ли ошибка изменением одной строчки, за 30 минут, или там половину проекта придется переписывать.
P.S.
Самый главный обман, в который попадает офисный разработчик, когда от него требуют четких сроков, и четкого соблюдения сроков — это то, что зарплату он получает за часы работы, а требуют от него уже фактического выполнения задач. Оплата за выполненные задачи — это вообще-то из другой области (там, где не нужно сидеть о офисе, там, где исполнитель сам решает когда и сколько сегодня он будет работать, там, где сделал задачу и свободен).
А так получается, что программист честно отрабатывает свои 40 часов в неделю (а иногда еще и больше), и при этом чувствует себя виноватым. WTF?
Среди мужчин такое встречается реже. На в скидку, можно 70% с первого раза встретить хорошую девушку-копирайтера, и 40% с первого раза встретить хорошего мужчину-копирайтера. Плюс женщины дольше готовы сотрудничать. Мужчины, видимо, понимают, что фигней какой-то страдают, и быстро меняют сферу деятельности (в большинстве случаев).
Работать с девушками в программировании (чтобы долго и с разными) не доводилось.