Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Стойкая уверенность, что я уже читал на хабре про это дашбордовое счастье для всех.
Это повтор или развитие прежней статьи, или мне просто кажется?
На память — идеи высказываются те же, что и в прошлой публикации.
*оглядывается в поисках повторяющихся черных кошек*
Это повтор или развитие прежней статьи, или мне просто кажется?
На память — идеи высказываются те же, что и в прошлой публикации.
*оглядывается в поисках повторяющихся черных кошек*
Все вышесказанное можно заменить простой и известной лет 30-40 фразой в программировании: делая дизайн системы, думайте о ее будущем развитии. Зачем столько буков?
Автору — спасибо за систематизированную подачу того, что собственно каждый разработчик и так знает, но либо откладывает на потом, либо просто игнорирует и плывет по течению.
зачастили вы статьями, начали повторяться.
возьмите передышку.
возьмите передышку.
Пример с дэшбордом красивый, но в нем много «но». Хорошо если программист угадал тренд, а что если нет? Вот он решил, что неплохо бы сделать внешний конфиг для дэшбоарда (а вдруг захотят внешний вид поправить или еще чего), наделал фабрик и прочих паттернов (руководствуясь другими «а что, если»). Ну и уволился. Пришел новый программист, посмотрел на код. Код работает, но лезть в него страшно. И тут понадобилось что-то поменять, т.к. первый разработчик предусмотрел много разных «если», но вот с новым требованием не угадал. В результате, новый программист вынужден разбираться в навороченной архитектуре и тратить лишнее время. А старый программист успешно клонировал этого монстрика на новое место работы.
Кроме этого, не нужно забывать, что решения устаревают. Иногда не только технически, но и идеологически (например, был пейджинг, стал бесконечный скролл).
Кроме этого, не нужно забывать, что решения устаревают. Иногда не только технически, но и идеологически (например, был пейджинг, стал бесконечный скролл).
… наделал фабрик и прочих паттернов ...
Это от опыта, думаю, зависит. «Точки роста» не обязательно (и даже, скорее, вредно) делать готовыми к немедленному использованию. Достаточно куски, которые, возможно, понадобится заменять, вынести в какую-нибудь отдельную сущность, чтобы были явно видны ее границы и было четко понятно, что идет туда и что — оттуда. С тем же конфигом: думаете, у вас будет куча способов его хранить и добавится зависимость, например, от профиля пользователя, но это неточно — сделайте, грубо говоря, вместо констант — какой-нибудь класс-болванку и назовите его так, чтобы все вызовы легко нашлись. Пусть выборка данных будет в отдельном методе, нормализация — в отдельном методе и т.д. Когда захочется добавить «фабрик» — простой поиск по тексту исходников легко даст понять, куда ее приткнуть.
сделайте, грубо говоря, вместо констант — какой-нибудь класс-болванку и назовите его так, чтобы все вызовы легко нашлись. Пусть выборка данных будет в отдельном методе, нормализация — в отдельном методе и т.д.
Как у вас все просто. Таким же способом можно и реализовать новые требования, когда (и если) они появятся.
Это от опыта, думаю, зависит.
Разумеется. Периодически вижу как делают люди с опытом (10+ лет), так вот они оочень сильно себя ограничивают в мыслях «а что если» и делают то, что нужно заказчику с небольшим запасом. Хотя, тут много факторов различных могут влиять.
Таким же способом можно и реализовать новые требования, когда (и если) они появятся.
Я, в общем-то, говорю почти об этом. Не надо ничего реализовывать наперед. Но я считаю правильным постараться сделать возможное расширение более безболезненным, если это дешево. Да, нужно уметь сделать именно максимально дешево и трезво оценивать возможный выигрыш (в том числе, на фоне варианта ничего заранее не предпринимать), для этого опыт и нужен.
Надо понимать, что все что вы делаете на работе за деньги работодателя принадлежит работодателю.
Поэтому переход со своим дашбордом в другую контору может расцениваться, как кража интелектуальной собственности.
Я конечно видел фразу типо восстановил по памяти, но в целом надо очень аккуратно с этим быть.
С другой стороны лейтмотив статьи — надо развиваться и это бесспорно.
Поэтому переход со своим дашбордом в другую контору может расцениваться, как кража интелектуальной собственности.
Я конечно видел фразу типо восстановил по памяти, но в целом надо очень аккуратно с этим быть.
С другой стороны лейтмотив статьи — надо развиваться и это бесспорно.
Надо понимать, что все что вы делаете на работе за деньги работодателя принадлежит работодателю.
Не всё. А только то, что прописано в договоре.
а в большинстве договоров компаний, на которых все стараются равняться, прописано именно это — «все произведенное вами в рабочее время и/или на мощностях компании принадлежит компании». утащить в другое место может выйти боком.
Если говорить за РФ.
Во-первых, авторское право — неотчуждаемое, конторе может принадлежать эксклюзивное право, по прошествии 3х лет, если не заключено новое соглашение или договор, то все эксклюзивные права — автора.
Во вторых, если в договоре прописано, что человек, допустим, админ, а написал программу бух учета, а в договоре не прописано, что его обязанность писать программы, то бух программа и все права — этого самого админа.
ГК РФ 1295.
Во-первых, авторское право — неотчуждаемое, конторе может принадлежать эксклюзивное право, по прошествии 3х лет, если не заключено новое соглашение или договор, то все эксклюзивные права — автора.
Во вторых, если в договоре прописано, что человек, допустим, админ, а написал программу бух учета, а в договоре не прописано, что его обязанность писать программы, то бух программа и все права — этого самого админа.
ГК РФ 1295.
авторское право остается за автором. однако продукт, в котором воплощены идеи, принадлежит компании. если этот чарт был написан в компании, где человек работал, то и принадлежать он скорее всего будет компании. если бы это было иначе, то насколько легко было бы выпустить новый продукт, конкурент существующего — переманить к себе автора существующего, он придет вместе с codebase-ом — через месяц у вас релиз.
С 3 годами аккуратней. Это 3 года неиспользования. Если сделали дашборд и его сразу или в течение 3 лет после передачи работодателю стали использовать, то исключительных прав вы не приобретаете, если не оговорено явно обратное. Вот если сделали, но посмотрели на него и использовать не стали даже через 3 года, вот тогда права ваши.
Вы все верно написали, но только половину.
Есть еще одна часть
Которая сообщает, что если работодатель будет использовать, передавать третьему лицу исключительные права, то автор имеет право на вознаграждение.
Соответственно, если вознаграждения не было(по прошествии трех лет), что подразумевает неиспользование или сохранение в тайне произведения. Что с этим происходит — уже написано вами и мной.
Вырезка из статьи
Если работодатель в течение трех лет со дня, когда служебное произведение было предоставлено в его распоряжение, не начнет использование этого произведения, не передаст исключительное право на него другому лицу или не сообщит автору о сохранении произведения в тайне, исключительное право на служебное произведение возвращается автору.
Есть еще одна часть
Ещё одна часть
Если работодатель в срок, предусмотренный в абзаце втором настоящего пункта, начнет использование служебного произведения или передаст исключительное право другому лицу, автор имеет право на вознаграждение. Автор приобретает указанное право на вознаграждение и в случае, когда работодатель принял решение о сохранении служебного произведения в тайне и по этой причине не начал использование этого произведения в указанный срок. Размер вознаграждения, условия и порядок его выплаты работодателем определяются договором между ним и работником, а в случае спора — судом.
Которая сообщает, что если работодатель будет использовать, передавать третьему лицу исключительные права, то автор имеет право на вознаграждение.
Соответственно, если вознаграждения не было(по прошествии трех лет), что подразумевает неиспользование или сохранение в тайне произведения. Что с этим происходит — уже написано вами и мной.
Обычно вознаграждение выплачивается по факту передачи. Часто типа один рубль или вообще «включено в ЗП». Кроме того право на вознаграждение не означает обязательство автоматической выплаты, вполне могут не выплачивать пока не попросишь (а 3 года не просишь — уже даже через суд потребовать не получится в общем случае)
1) Начну с того, авторское право пожизненно
1.1) Пользуешь пожизненно — платишь пожизненно авторское отчисление
2) ЗП и авторские отчисления это две суммы и оно должно быть прописано в договоре. Если в договоре про авторские отчисления вообще ничего нет, это не говорит о его включении в ЗП.
1.1) Пользуешь пожизненно — платишь пожизненно авторское отчисление
2) ЗП и авторские отчисления это две суммы и оно должно быть прописано в договоре. Если в договоре про авторские отчисления вообще ничего нет, это не говорит о его включении в ЗП.
Не пожизненно, а исключительные 75 лет после смерти, а личные — вечны. Платишь как договорились, вознаграждение может быть разовым, с право пользоваться вечно. Сумма не обязана быть указана в договоре явно, достаточно (ну или многие юристы верят, что достаточно) указания типа «данная сумма включает в себя авторское вознаграждение»).
Особенно это «хорошо» работает, когда есть поток текущих задач. Которые этот «чудо-программист» не успевает делать, потому что делает не то, что просят, а «красиво».
И все счастливы. И уволились в один день.
И все счастливы. И уволились в один день.
недавно читал о программисте из MSFT, которому дали плохое годовое ревью и поставили на Performance Improvement Plan (если за полгода нет заметного улучшения, следует увольнение). в комментариях сотрудников в качестве одной из самых частых причин, по которым люди попадают в такую ситуацию, приводится «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим».
в комментариях сотрудников в качестве одной из самых частых причин, по которым люди попадают в такую ситуацию, приводится «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим».
А у нас почти всегда причина увольнения — «по собственному желанию».
Подозреваю, что тут то же самое. Формулировка «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим» звучит не так плохо, как могла бы звучать реальная причина. А то может показаться, что прямо самых перфекционистов-нонконформистов увольняют, а не низкопроизводительных и некомпетентных.
формулировка «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим» дана не сотруднику, а приведена как самая часто встречаемая настоящая причина в комментариях, оставленных другими сотрудниками. кроме того — это сейчас не про увольнение пока что, а про плохие результаты перф-ревью.
Во всём этом сквозит «программист в компании». Один. Подчиняющийся кому-то из C*O напрямую. Я один раз работал в такой компании, так что я понимаю о чём речь.
… Так вот, это болото для программиста. Во-первых «сам реализовал». Бывает так, что человек идёт и пишет хорошее и полезное. Но чаще всего, продукты или даже внутренние сервисы пишет команда. Из нескольких программистов. В условиях «одинокого карманного программиста» нельзя расти. Можно только баловаться в песочнице. Индустриальный код (если мы говорим про карьеру профессионального программиста) пишется командами и требует работы в команде. Работа в команде радикально отличается от работы в одиночку, и научившись программировать, дальше человек начинает учиться «писать в одиночку», что будет делать жизнь в команде очень сложной. И чем больше человек пишет в одиночку, тем это будет серьёзнее.
… Так вот, это болото для программиста. Во-первых «сам реализовал». Бывает так, что человек идёт и пишет хорошее и полезное. Но чаще всего, продукты или даже внутренние сервисы пишет команда. Из нескольких программистов. В условиях «одинокого карманного программиста» нельзя расти. Можно только баловаться в песочнице. Индустриальный код (если мы говорим про карьеру профессионального программиста) пишется командами и требует работы в команде. Работа в команде радикально отличается от работы в одиночку, и научившись программировать, дальше человек начинает учиться «писать в одиночку», что будет делать жизнь в команде очень сложной. И чем больше человек пишет в одиночку, тем это будет серьёзнее.
>> Во всём этом сквозит «программист в компании». Один. Подчиняющийся кому-то из C*O напрямую. Я один раз работал в такой компании, так что я понимаю о чём речь.
Постепенно развивается профессиональный сдвиг. Обычно приводит к массе костыльных решений — я ведь все равно знаю все ньюансы и помню как работают все костыли, документировать тем более ничего не нужно. Тесты? Так ведь работает, а меняю код только я сам, рисков никаких). Экзотические языки (а мне нравится), используемые фреймворки притянуты потому что захотелось попробовать и т.д.
Но такой же сдвиг может возникнуть и у тимлида/архитектора/техдира, имеющего команду. Такое тоже встречал.
Постепенно развивается профессиональный сдвиг. Обычно приводит к массе костыльных решений — я ведь все равно знаю все ньюансы и помню как работают все костыли, документировать тем более ничего не нужно. Тесты? Так ведь работает, а меняю код только я сам, рисков никаких). Экзотические языки (а мне нравится), используемые фреймворки притянуты потому что захотелось попробовать и т.д.
Но такой же сдвиг может возникнуть и у тимлида/архитектора/техдира, имеющего команду. Такое тоже встречал.
Сознательно ищут работу, на которой нужно решать знакомые задачи. Понятно, что в краткосрочной перспективе так безопаснее. Но что в долгосрочной перспективе?
Подписываюсь!
По другому это называется «зона комфорта». Но, что бы научиться чему-то новому, нужно обязательно выйти из зоны комфорта. Это касается всего — начиная от ИТ, изучения иностранных языков, и заканчивая коньками и ездой на велосипеде :)
хм. обидно как-то про автомобили и резюме.
Может человек просто не привык всю свою историю изливать в резюме. А если по делу позвонить и спросить, то расскажет, что и как делал.
Может человек просто не привык всю свою историю изливать в резюме. А если по делу позвонить и спросить, то расскажет, что и как делал.
Резюме часто единственный способ показать себя, чтобы хотя бы позвонили. Я вот серьёзно задумываюсь при следующем цикле смены работы заказать подготовку моего резюме профессионалам, а в идеале и стартовые коммуникации по заинтересовавшим вакансиям, типа подгонки резюме под конкретные требования и обязанности и написание «бьющего в цель» сопроводительного письма. Ещё бы понять где их найти, таких профессионалов
Про «компетенции» круто. Никогда бы не придумал такого. Ведь часто программисты любят играть в комп. игры, а тут и мотивация по типу комп. игр.
YAGNI
1. Складывается впечатление, что статью писал HR — представитель «предыдущего» работодателя. Объясню почему.
2. Во-первых, IT-специалистов не надо призывать работать на будущего или на текущего работодателя. Работа вообще то от слова «раб», и потому эта рабская психология изначально подходит только для не самодостаточных профессий (для тех, которым нужен офис, начальник, бухгалтерия и прочее). Ввиду глобализации и востребованности IT, вообще не надо внедрять в сознание людей, что они должны на кого то работать, кроме как на самих себя. Т.е. если хотят, могут работать и на кого то, но не надо утверждать это как единственный вариант.
3. В этой связи, утверждение, что бывший работодатель или тем более специалист пришедший тебе на смену должны будут испытывать «вечное счастье» от твоей работы выглядит смехотворно. А с какой собственно стати Вы должны о них думать после смены работы? Пока вы работаете, они удовлетворены, вы удовлеторены (если речь не о случае, когда это Вас увольняют!). А дальше, вам же с ними детей не крестить, о ни же о Вас после ухода не думают.
4. Далее. Когда нас нанимают, мы соглашаемся на совершенно конкретные условия и нам ставят вполне конкретные задачи. Условия работы (т.е. мат. компенсация и соц. пакет) составляют нашу мотивацию к данной конкретной работе, а не к работе вообще на всю оставшуюся жизнь в будущем. Это материальная мотивация к труду. Мы всегда хотим большего, чем может предложить рынок, но принимаем компромисс, так почему работодатель должен мечтать о самом лучшем максимально универсальном результате в плане разработки? (если условия как в российском ООО, то никогда не получите, решения, как в Гугле!). Второе — это собственно работа т.е. задачи по разработке совершенно конкретных решений. Для этого принято сначала делать чёткое ТЗ, по кот. можно отследить, всё ли было сделано, и что и как реализовано (чтобы потом не было повода обзывать экс-сотрудника «говнокодером» и прочее). Но даже более важно, что ничто не происходит в вакууме! Любые разработки всегда упираются в определённый ресурс — временной дедлайн, человеческий ресурс, ограничения мощности железа, требуемую производительность, масштабируемость решения и.т.д. ну и в том числе, никуда не денешься, в нашу мотивацию (за те же деньги), делать «точечное» решение или глобальное универсальное т.е. работать или перерабатывать по-русски говоря. Почему мы должны выходить из зоны комфорта, если нам комфортней в ней оставаться в конкретном случае (т.е. использовать привычные технологии и делать может более узкий, но зато именно тот, что просили функционал)? Не надо забывать, что ценность каждого работодателя в данный момент времени для сотрудника м.б. разной. Не вся работа одинаково полезна и хорошо оплачивается! Возможно программист рассматривает эту работу как временную, возможно он хочет открыть свою контору по разработке или перейти в крупную компанию. Опять же есть вопрос work-life баланса, — что важнее сделать всё идеально на работе или вести в целом полноценную жизнь?! В зависимости от этих целей человек сам себе и выбирает глубину проработки задачи для своего портфолио проектов! Автор же утверждает в статье, что нужно всегда при любых условиях стремиться делать наиболее универсальное, всесторонне масштабируемое и желательно не зависимое от технологии решение. Объяснение одно — это Вам поможет на следующем собеседовании. Ну понятно, что такой подход максимально в интересах вашего текущего работодателя по принципу «сделать из говна конфетку» на все времена. Когда нужен конкретный автоматизированный отчёт и сроку вам 3 дня, делать конструктор отчётов с прикрученной системой аналитики и максимально «кошерным» интерфейсом, это и глупость и «самоубийство» для сотрудника!
5. С чем соглашусь, так это с тем, что построение таких «продвинутых» универсальных решений исключительно благотворно сказывается на твоей профессиональной компетенции и на скорости работы в будущем и даже на общем системном подходе к разработке в вашей голове. Поэтому, если цель — максимальный рост проф. компетенций, то это хороший путь, также, как, когда хочешь серьёзно освоить математику, необходимо после стандартных решать все задачи со звёздочкой! Если хотите проф. роста, то будете «заморачиваться» работой и вне работы по выходным. Но на практике в нашей действительности — это всё благие пожелания, кот. вымощена дорога, сами знаете куда. В мировой IT-индустрии, то что расписал автор — это безусловно best practice к которым стоит стремиться, если Вы работаете на цивилизованного западного работодателя. У нас — это называется «рвать *опу ради Дяди за копьё»!
2. Во-первых, IT-специалистов не надо призывать работать на будущего или на текущего работодателя. Работа вообще то от слова «раб», и потому эта рабская психология изначально подходит только для не самодостаточных профессий (для тех, которым нужен офис, начальник, бухгалтерия и прочее). Ввиду глобализации и востребованности IT, вообще не надо внедрять в сознание людей, что они должны на кого то работать, кроме как на самих себя. Т.е. если хотят, могут работать и на кого то, но не надо утверждать это как единственный вариант.
3. В этой связи, утверждение, что бывший работодатель или тем более специалист пришедший тебе на смену должны будут испытывать «вечное счастье» от твоей работы выглядит смехотворно. А с какой собственно стати Вы должны о них думать после смены работы? Пока вы работаете, они удовлетворены, вы удовлеторены (если речь не о случае, когда это Вас увольняют!). А дальше, вам же с ними детей не крестить, о ни же о Вас после ухода не думают.
4. Далее. Когда нас нанимают, мы соглашаемся на совершенно конкретные условия и нам ставят вполне конкретные задачи. Условия работы (т.е. мат. компенсация и соц. пакет) составляют нашу мотивацию к данной конкретной работе, а не к работе вообще на всю оставшуюся жизнь в будущем. Это материальная мотивация к труду. Мы всегда хотим большего, чем может предложить рынок, но принимаем компромисс, так почему работодатель должен мечтать о самом лучшем максимально универсальном результате в плане разработки? (если условия как в российском ООО, то никогда не получите, решения, как в Гугле!). Второе — это собственно работа т.е. задачи по разработке совершенно конкретных решений. Для этого принято сначала делать чёткое ТЗ, по кот. можно отследить, всё ли было сделано, и что и как реализовано (чтобы потом не было повода обзывать экс-сотрудника «говнокодером» и прочее). Но даже более важно, что ничто не происходит в вакууме! Любые разработки всегда упираются в определённый ресурс — временной дедлайн, человеческий ресурс, ограничения мощности железа, требуемую производительность, масштабируемость решения и.т.д. ну и в том числе, никуда не денешься, в нашу мотивацию (за те же деньги), делать «точечное» решение или глобальное универсальное т.е. работать или перерабатывать по-русски говоря. Почему мы должны выходить из зоны комфорта, если нам комфортней в ней оставаться в конкретном случае (т.е. использовать привычные технологии и делать может более узкий, но зато именно тот, что просили функционал)? Не надо забывать, что ценность каждого работодателя в данный момент времени для сотрудника м.б. разной. Не вся работа одинаково полезна и хорошо оплачивается! Возможно программист рассматривает эту работу как временную, возможно он хочет открыть свою контору по разработке или перейти в крупную компанию. Опять же есть вопрос work-life баланса, — что важнее сделать всё идеально на работе или вести в целом полноценную жизнь?! В зависимости от этих целей человек сам себе и выбирает глубину проработки задачи для своего портфолио проектов! Автор же утверждает в статье, что нужно всегда при любых условиях стремиться делать наиболее универсальное, всесторонне масштабируемое и желательно не зависимое от технологии решение. Объяснение одно — это Вам поможет на следующем собеседовании. Ну понятно, что такой подход максимально в интересах вашего текущего работодателя по принципу «сделать из говна конфетку» на все времена. Когда нужен конкретный автоматизированный отчёт и сроку вам 3 дня, делать конструктор отчётов с прикрученной системой аналитики и максимально «кошерным» интерфейсом, это и глупость и «самоубийство» для сотрудника!
5. С чем соглашусь, так это с тем, что построение таких «продвинутых» универсальных решений исключительно благотворно сказывается на твоей профессиональной компетенции и на скорости работы в будущем и даже на общем системном подходе к разработке в вашей голове. Поэтому, если цель — максимальный рост проф. компетенций, то это хороший путь, также, как, когда хочешь серьёзно освоить математику, необходимо после стандартных решать все задачи со звёздочкой! Если хотите проф. роста, то будете «заморачиваться» работой и вне работы по выходным. Но на практике в нашей действительности — это всё благие пожелания, кот. вымощена дорога, сами знаете куда. В мировой IT-индустрии, то что расписал автор — это безусловно best practice к которым стоит стремиться, если Вы работаете на цивилизованного западного работодателя. У нас — это называется «рвать *опу ради Дяди за копьё»!
В мировой IT-индустрии, то что расписал автор — это безусловно best practice к которым стоит стремиться, если Вы работаете на цивилизованного западного работодателя. У нас — это называется «рвать *опу ради Дяди за копьё»!работайте на аутсорсинге и будет вам счастье. Достаточно один раз поработать на цивилизованного работодателя, чтобы понять — на каких работодателей вам стоит искать.
2. Какая разница как слово произошло? Сейчас оно имеет вполне определённые значения, в частности добровольное исполнение трудовых обязанностей в обмен на, прежде всего, денежное вознаграждение и перекладывание на работодателя забот об организации труда и различных рисков. Вроде никто не утверждает, что каждый должен работать в капиталистическом (хотя бы номинально) обществе. И не надо внедрять в сознание, что работа «на дядю» это что-то плохое, что стремиться нужно к чему-то другому.
3. Как минимум думать о будущем «счастье» работодателя полезно, если прямо сейчас не имеешь конкретных планов на увольнение. Потому что будущее работодателя вполне может оказаться и твоим будущим, если не успеешь уволиться к моменту когда текущее решение потребует изменений.
4. Часто работодатель берёт на работу технического специалиста чтобы тот решал бизнес-задачи техническими методами, а не технические задачи с чётким ТЗ и полным техническим контролем. И работу такого специалиста работодатель проконтролировать может только по одному аспекту: решена или нет бизнес-задача. При этом ему всё равно какие языки, платформы, архитектуры и паттерны использовались. Но он заметит что-то неладное, если оценка сроков/стоимости изменения бизнес-фичи будет равна оценки её разработки с нуля. Ну а в целом посыл статьи, что вообще нужно думать о проработке своего портфолио, если не исключаешь смену работы, а не тупо решать технические задачи.
3. Как минимум думать о будущем «счастье» работодателя полезно, если прямо сейчас не имеешь конкретных планов на увольнение. Потому что будущее работодателя вполне может оказаться и твоим будущим, если не успеешь уволиться к моменту когда текущее решение потребует изменений.
4. Часто работодатель берёт на работу технического специалиста чтобы тот решал бизнес-задачи техническими методами, а не технические задачи с чётким ТЗ и полным техническим контролем. И работу такого специалиста работодатель проконтролировать может только по одному аспекту: решена или нет бизнес-задача. При этом ему всё равно какие языки, платформы, архитектуры и паттерны использовались. Но он заметит что-то неладное, если оценка сроков/стоимости изменения бизнес-фичи будет равна оценки её разработки с нуля. Ну а в целом посыл статьи, что вообще нужно думать о проработке своего портфолио, если не исключаешь смену работы, а не тупо решать технические задачи.
Бывает так, что тебе дают однотипные задачи, и ты ничего не можешь ничего крутого предъявить на следующей работе.
А бывает так, что пилишь для них какую-нибудь интеграцию, тебя увольняют, а твой проект считается теперь их проектом.
Так что всегда следует позаботиться о себе и накопить такой увольнительный пак.
А бывает так, что пилишь для них какую-нибудь интеграцию, тебя увольняют, а твой проект считается теперь их проектом.
Так что всегда следует позаботиться о себе и накопить такой увольнительный пак.
Часто есть возможность как раз на однотипных задачах сделать достаточно универсальное решение. Так и появляются фреймворки, библиотеки, кодогенераторы и т. п. Под вопросом может быть интеллектуальная собственность на это решение, но в целом строчка в резюме типа «оптимизировал процессы разработки, разработав универсальный инструмент для решения задач такого-то типа, внедрение которого сократило время решения такой типовой задачи на 1000%» даже с окончанием «после чего был уволен за ненадобностью» :)
Довольно плоское изложение инженерной работы, как по мне. Часто бывает что время на гибкое или универсальное решение на порядок (!) отличается от времени на добавление нужного функционала «здесь и сейчас». Плюс практически в каждой нетривиальной системе имеется в наличии определенный объем технических долгов, которые точно не ускоряют разработку гибких универсальных фич. Поэтому и получается что «работа на будущего работодателя» может сильно снизить КПД работы для текущего работодателя, особенно при доминировании операционных задач (когда надо просто вклеить новый график в мониторинг, а не изобретать велосипед для мониторинга)
Как-то очень завуалированно у вас получилось донести ясную мысль: «мое дело — резюме наращивать, и чтобы было о чем на собесах рассказывать, а вы тут занимайтесь своим бизнесом-шмизнесом, у меня в нем доли нет». Сказки про синергию и будущих работодателей тут совершенно излишни, хоть и могут оказаться полезными, когда вы будете объяснять сегодняшнему нанимателю, зачем вы на работе точите свои велосипеды.
вот же:
Например, вы тут поработали, там поработали, потом свой бизнес открыли. Бац — оказывается, вы уже умеете команду организовывать, целенаправленно этому учились. А еще в системах налогообложения разбираетесь. А еще у вас с собой облачная система управления проектами, которую сделали на одной из работ.
Причем тут резюме?
Вам могло показаться, что комплект увольнения – это своего рода накопительное резюме. С одной, видимой стороны, это действительно так.
Но суть не в том, что вы сможете показать, а в том, что у вас реально есть, в вашем багаже. Это своего рода продукт, результат инвестиций своего времени в каждого работодателя.
Например, вы тут поработали, там поработали, потом свой бизнес открыли. Бац — оказывается, вы уже умеете команду организовывать, целенаправленно этому учились. А еще в системах налогообложения разбираетесь. А еще у вас с собой облачная система управления проектами, которую сделали на одной из работ.
Причем тут резюме?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Комплект увольнения