Comments 31
согласования с юридическими отделами, отдача копирайтов и все такое
Если я работаю в столярной мастерской и делаю табуретки, а потом прихожу домой и в своей домашней мастерской делаю резные стулья, я должен отдать все права на результаты своего труда той мастерской? Звучит как полный бред. Но почему в мире разработки ПО об этом рассуждают как о чём-то нормальном и в порядке вещей? Это вообще законно?
В куче других профессий и в разработке в частности не должно быть никакого конфликта интересов, пока личные проекты не составляют конкуренцию продуктам компании-работодателя, а также сотрудник не пользуется ресурсами компании и рабочим временем при работе над ними. Притянуть за уши и довести до абсурда можно всё что угодно, но чисто практически как могут навредить open source пет-проекты работодателю?
Обучение, обучение, обучение! Лучший способ исследовать новые для себя техники, библиотеки, подходы — это потыкать их на практике. Только так можно натренировать чуйку, чтобы отличать Добро от Зла. Но проблема в том, что такое обучение априори подразумевает высокий риск. Если техника используется неправильно, если в библиотеке таятся баги, если подход не так уж хорош, как казалось изначально, дело может кончиться плачевно. Тащить высокий риск в продукт или проект, который приносит деньги Компании — сомнительная затея. И пет-проекты сотрудников, с точки зрения Компании, могут служить своего рода полигоном для отработки таких высокорисковых, но потенциально высокополезных подходов. Поиграется сотрудник в своей песочнице, набьёт шишки, станет опытным — а потом вернётся в рабочий проект и там сразу сделает всё более правильно.
Если исходить из таких предпосылок, то пет-проекты сотрудников для Компании должны быть выгодны. На них стоит явно выделять время, и даже более того, есть смысл дополнительно стимулировать движение в сторону потенциально полезных экспериментов, предоставлять менторинг, и т.п.
Понимает ли это менеджмент? Не знаю. Возможно, в нашу эпоху KPI и кратко- и средне-срочных целей подход "под лежачий камень всё равно что-то да затечёт" выглядит для управляющего звена всё же более выгодным, нежели вышеуказанный тривиальный риск-менеджмент. Либо же они умеют считать ROI на бумажке, а не на пальцах (как я), и там всё выглядит не столь радужно.
Кстати, вспомнил хорошую цитату в тему. Джефф Ротшильд, сооснователь и ведущий инженер Facebook, утверждал в интервью:
In fact, I would say that I probably have interviewed thousands of people over the last 40 years. I still am waiting for someone to tell me in the interview that the reason I chose computer science as a career is because I'm excited about the idea of implementing other people's ideas. Nobody has ever said that to me. Obviously, nobody ever will.
Никто не приходит в программирование потому, что ему нравится реализовывать чужие идеи. Каждого тянет сделать что-то своё. И чуть дальше в интервью он говорит, что, с его точки зрения, именно внимание к этому моменту отличает выдающегося менеджера от посредственного. Есть над чем подумать!
Если у вас есть непотраченные ресурсы — то пет-проект является хорошим вариантом.
Но если их нет — то ни о каком творчестве не может идти речи.
У человека банально может быть другое хобби или увлечения, кроме написания кода. Или высокая загрузка на работе.
Проще говоря, вложение ресурсов в творчество возможно лишь при сочетании определённых факторов, многие из которых не всегда зависят от личных желаний.
Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?
Хобби проект как раз показывает что человеку интересна его профессия, что он как-то совершенствуется, а не тупо фигачит говнокод ради денег.
Есть небольшой проект на пару сотен звёзд на гитхабе.
Жаль что сейчас нет времени(или сил) его доделывать.
Проект принёс понимание как и почему софт обрастает багами и становится неподдерживаемым, а также важность SOLID, DRY и общих принципов проектирования.
Хобби проект как раз показывает что человеку интересна его профессия, что он как-то совершенствуется, а не тупо фигачит говнокод ради денег.
Для того чтобы заниматься пет проектам нужно прилично времени, и далеко не все готовы 24/7 писать код, чтобы показать «вовлеченность»
Но бывают периоды когда назгрузка небольшая и можно сделать что-то для души.
Про 24/7 никто и не говорит, но хоть что-то за несколько лет в профессии должно накопиться. Хотя бы несколько репозиториев с экспериментами или по курсам.
Так и не надо писать код, чтобы показать вовлечённость. Надо писать код, потому что это интересно.
1. Если компания обременена большим количеством бюрократических процедур, то пет проект это возможность потестировать какие-то вещи быстро, а потом уже работающие внедрять в работу. Это актуально не только для разработчиков, а даже больше для Менеджеров продукта.
2. Это удержание сотрудника. Когда нет пет проекта он может уволиться, чтобы пойти делать свой стартап. А пет проекты он может клепать годами один за другим и не уходить, так как 95% стартапов не взлетают.
Рассказывают о своих проектах — я рассказываю что знаю о них и выясняется, что я знаю больше.
Просят рассказать о личных проектах — тоже рассказываю.
Не перезванивают. Связываюсь, пытаюсь выяснить в чём дело.
Отвечают, что фидбек от последнего собеседования был такой: я не подхожу, поскольку буду больше внимания уделять свои проектам а не их.
Плюс выбор направления развития: иду куда хочу, а не куда тянут пользователи и спонсоры. Тоже важно лично для меня.
Я считаю пет-проекты полезны в первую очередь для самого разработчика. В нашей индустрии надо постоянно учится и соврешенстоваться, без этого никак. В добавок коммерческая разработка очень часто убивает всякое желание. И свой проект это как некая отдушена, где можно воплотить свои идеи, "пощупать" что-то иное. На собеседованиях всегда спрашивал, пишет ли человек для себя. И отдавал предпочтение таким кандидатам.
Pet-проекты: зачем они нужны, и стоит ли тратить на это время в 2020 году + опрос