Полиглотопроблемы
Я "знаю" кучу языков программирования. Начал с синей книжки по С которую отец мне дал читать когда у меня еще компьютера не было, потом в школе Basic, Pascal и немного JS, потом в университете Pascal, asm х86 и микроконтролерный, Java, Ada, потом на работе Java, SQL, Bash, потом на другой работе Python, JS, Bash, потом на третьей работе Objective C, PHP, Ruby, JS, SQL. Сейчас 60/20/10/10 это Ruby/JS/Java/Python (SQL не считаем).
Есть мнение что "jack of all trades master of none" и честно говоря оно имеет под собой некоторые основания. Когда постоянно переключаешься между языками, фреймворками и платформами то начинаешь забывать где
За какими-то базовыми вещами нужно постоянно писать в гугл типа ruby merge arrays. Где-то можно
Различия в базовых API языков здорово напрягают. Причем они часто мелкие и постоянно путаешься во всех этих вызовах и тратишь время на чтение документации. Забываю литералы для хешей и списков, путаюсь в
Более-менее хорошо я уверен только в Java, потому что кодил на ней больше 10 лет и все простые вещи уже прочно засели в мозг чтобы среди ночи можно было ответить на вопрос "перечислите методы класса Object". Со всем остальным постоянно путаюсь и лезу в документацию. Через некоторое время уже что-то запоминается, но потом опять происходит переключение контекстов и снова забываешь как делать for:
И это я еще не зацепил конфигурацию, JSON, XML, YAML, HCL, но тут благо различия посерьезнее + IDE помогает.
Сейчас прихожу к мысли что знание кучи языков это конечно здорово, но проекты которые идут параллельно лучше делать на одном стеке и хотя бы на 80% и минимизировать переключение.
Потому что без
С другой стороны, может быть я пока что слишком мало покодил на отличных от Java языках и через 10 лет буду точно так же помнить все методы Iterable в Ruby.
Я "знаю" кучу языков программирования. Начал с синей книжки по С которую отец мне дал читать когда у меня еще компьютера не было, потом в школе Basic, Pascal и немного JS, потом в университете Pascal, asm х86 и микроконтролерный, Java, Ada, потом на работе Java, SQL, Bash, потом на другой работе Python, JS, Bash, потом на третьей работе Objective C, PHP, Ruby, JS, SQL. Сейчас 60/20/10/10 это Ruby/JS/Java/Python (SQL не считаем).
Есть мнение что "jack of all trades master of none" и честно говоря оно имеет под собой некоторые основания. Когда постоянно переключаешься между языками, фреймворками и платформами то начинаешь забывать где
kek.toString(), где kek.to_s, где str(kek). Где arr.length, где arr.size, где len(arr). Где какие сокращения для лямбд, fat arrow, обычная стрелка, вообще без стрелки.За какими-то базовыми вещами нужно постоянно писать в гугл типа ruby merge arrays. Где-то можно
arr1 + arr2, где-то Arrays.merge(arr1, arr2) где-то еще непонятно что.Различия в базовых API языков здорово напрягают. Причем они часто мелкие и постоянно путаешься во всех этих вызовах и тратишь время на чтение документации. Забываю литералы для хешей и списков, путаюсь в
arr << el и arr.push(el) короче полный бардак еще на уровне молотков и отверток, не то что станков.Более-менее хорошо я уверен только в Java, потому что кодил на ней больше 10 лет и все простые вещи уже прочно засели в мозг чтобы среди ночи можно было ответить на вопрос "перечислите методы класса Object". Со всем остальным постоянно путаюсь и лезу в документацию. Через некоторое время уже что-то запоминается, но потом опять происходит переключение контекстов и снова забываешь как делать for:
for i in arr или for i of arr или еще как-то и чем они отличаются?И это я еще не зацепил конфигурацию, JSON, XML, YAML, HCL, но тут благо различия посерьезнее + IDE помогает.
Сейчас прихожу к мысли что знание кучи языков это конечно здорово, но проекты которые идут параллельно лучше делать на одном стеке и хотя бы на 80% и минимизировать переключение.
Потому что без
to_s ощущаешь себя как без рук, а это не очень приятно.С другой стороны, может быть я пока что слишком мало покодил на отличных от Java языках и через 10 лет буду точно так же помнить все методы Iterable в Ruby.
Главный язык который должен знать любой разработчик
Помимо английского.
Язык который пригодится везде и всегда, бекендеру и фронтендеру, и даже не только разработчику, но и тестировщику, бизнес-аналитику, (дев)опсу и вообще кому угодно.
Язык который можно сказать в своей базовой форме универсален посреди всех платформ и практически не изменялся десятилетиями.
Язык, к вызовам которого сводится 80% всей разработки вообще.
Это...
SQL!
Во времена JavaEE ходили шутки что вся разработка это пересылка XML из одной системы в другую. Описание это не совсем точное, потому что там упущен момент вытягивания данных с помощью SQL из базы, конвертации их в XML, отсылки куда надо по SOAP и обратной процедуре.
80% всей разработки это — достать данные - обработать - конвертировать - отослать куда-то - получить ответ - конвертировать - обработать - сохранить. Вся движуха рано или поздно сводится к
"RDBMS не нужны", скажет иной, и местами будет прав, да вот только если ты знаешь SQL то любой DSL для запросов к No/NewSQL хранилищам является его подмножеством. Знаешь как делать запросы в реляционную таблицу — для тебя все остальное будет просто частным. Это как выучить С и в принципе понимать все процедурные языки (и даже объектные на которых можно писать в процедурной парадигме).
Бонусом идет умение в транзакции, индексы и ускорение запросов — знаешь это и ты вообще топчик, дальше только задроство по всяким функциям и PL/SQL.
Реляционную модель критикуют за избыточность и сложность представления объектов или графов, но я считаю что всё это туфта. До сих пор весь мир крутится на RDBMS и это закончится еще очень очень не скоро. Ну когда закончится — мы уже будем о всеоружии.
Помимо английского.
Язык который пригодится везде и всегда, бекендеру и фронтендеру, и даже не только разработчику, но и тестировщику, бизнес-аналитику, (дев)опсу и вообще кому угодно.
Язык который можно сказать в своей базовой форме универсален посреди всех платформ и практически не изменялся десятилетиями.
Язык, к вызовам которого сводится 80% всей разработки вообще.
Это...
SQL!
Во времена JavaEE ходили шутки что вся разработка это пересылка XML из одной системы в другую. Описание это не совсем точное, потому что там упущен момент вытягивания данных с помощью SQL из базы, конвертации их в XML, отсылки куда надо по SOAP и обратной процедуре.
80% всей разработки это — достать данные - обработать - конвертировать - отослать куда-то - получить ответ - конвертировать - обработать - сохранить. Вся движуха рано или поздно сводится к
SELECT, INSERT, UPDATE (а DELETE не надо потому что вдруг потом пригодится еще). "Но так же можно всё и к ассемблерным вызовам свести" воскликнешь ты и будешь не совсем прав. Потому что SQL оперирует на более высоком уровне абстракции и описывает данные и связи между ними. Умение представлять в голове данные в структурированном виде, дробить их на кусочки, нормализовывать, объединять, потом собирать обратно с помощью агрегаций — нужно всем везде и всегда. "RDBMS не нужны", скажет иной, и местами будет прав, да вот только если ты знаешь SQL то любой DSL для запросов к No/NewSQL хранилищам является его подмножеством. Знаешь как делать запросы в реляционную таблицу — для тебя все остальное будет просто частным. Это как выучить С и в принципе понимать все процедурные языки (и даже объектные на которых можно писать в процедурной парадигме).
Бонусом идет умение в транзакции, индексы и ускорение запросов — знаешь это и ты вообще топчик, дальше только задроство по всяким функциям и PL/SQL.
Реляционную модель критикуют за избыточность и сложность представления объектов или графов, но я считаю что всё это туфта. До сих пор весь мир крутится на RDBMS и это закончится еще очень очень не скоро. Ну когда закончится — мы уже будем о всеоружии.
Таймкоды к записи "стрима х 01"
Виктор Черниявский заморочился и сделал таймкоды к записи стрима за что ему огромное спасибо. Если вы не смотрели потому что 2 часа и непонятно что я там рассказываю, то вот список. Заодно может быть интересным тем, кто пропустил это замечательное событие. Если у вас вдруг есть вакансия джава джуна в Киеве — напишите мне, Виктор сейчас в поисках.
5:00 Как найти хорошего клиента на фрилансе?
10:40 Зачем мне telegram канал?
13:31 Куда инвестировать накопленное?
20:20 Что произошло с моей собственной "шлюпкой"?
35:40 Мой опыт работы в стартапе.
38:18 Жизнь на минималках в моем понимании.
52:40 Зачем учить алгоритмы и фреймворки?
55:40 Что нужно обязательно знать программисту?
57:45 Деньги или интересный проект?
58:45 Как просить повышение ЗП?
1:01:50 Как быстро "вырасти" на "галере"?
1:07:10 Как "интровертность" может повлиять на карьерный успех?
1:10:10 Нужно знание гита или нет?
1:10:25 Стоит ли развивать Opensourсe?
1:12:35 Как развивать уровень английского?
1:13:23 5 вещей, которые должен уметь делать разработчик.
1:21:55 Полезные привычки для самоорганизации
1:24:00 Какой собес правильный?
1:25:45 Какие 2 - 3 книги всем советуешь прочитать?
1:27:04 Имеет ли значение возраст при устройстве на работу?
1:28:45 Как стать архитектором?
1:31:00 Почему мобильные проекты дно?
1:33:25 Как изучить что-то новое не читая книги?
1:37:15 Про курсы
1:38:37 Кем ты себя видишь через 5 лет?
1:45:10 Как поверить в себя, что ты что то можешь?
1:46:05 Об отпуске.
1:47:52 Где я работаю.
1:48:15 Фриланс или галера?
1:51:45 Мое мнение об ML?
1:52:00 Чем бы я занимался, если бы не работал?
1:53:25 Как продвигать себя?
1:56:25 Что такое тлен? Реальный жизненный кейс.
1:59:15 Лучшая десктоп ОС
1:59:40 Сколько часов в неделю я работаю.
2:03:31 Обманывали ли меня на фрилансе?
2:06:20 Насколько сильно нужно прокачивать свои скиллы?
2:07:20 Как стать топ менеджером?
2:13:40 Мои привычки
2:14:10 Из каких стран мои клиенты?
2:15:10 DevOps настройки, как продукт
2:16:10 О паттернах
2:19:50 Java или С++
2:21:26 О технологиях
Виктор Черниявский заморочился и сделал таймкоды к записи стрима за что ему огромное спасибо. Если вы не смотрели потому что 2 часа и непонятно что я там рассказываю, то вот список. Заодно может быть интересным тем, кто пропустил это замечательное событие. Если у вас вдруг есть вакансия джава джуна в Киеве — напишите мне, Виктор сейчас в поисках.
5:00 Как найти хорошего клиента на фрилансе?
10:40 Зачем мне telegram канал?
13:31 Куда инвестировать накопленное?
20:20 Что произошло с моей собственной "шлюпкой"?
35:40 Мой опыт работы в стартапе.
38:18 Жизнь на минималках в моем понимании.
52:40 Зачем учить алгоритмы и фреймворки?
55:40 Что нужно обязательно знать программисту?
57:45 Деньги или интересный проект?
58:45 Как просить повышение ЗП?
1:01:50 Как быстро "вырасти" на "галере"?
1:07:10 Как "интровертность" может повлиять на карьерный успех?
1:10:10 Нужно знание гита или нет?
1:10:25 Стоит ли развивать Opensourсe?
1:12:35 Как развивать уровень английского?
1:13:23 5 вещей, которые должен уметь делать разработчик.
1:21:55 Полезные привычки для самоорганизации
1:24:00 Какой собес правильный?
1:25:45 Какие 2 - 3 книги всем советуешь прочитать?
1:27:04 Имеет ли значение возраст при устройстве на работу?
1:28:45 Как стать архитектором?
1:31:00 Почему мобильные проекты дно?
1:33:25 Как изучить что-то новое не читая книги?
1:37:15 Про курсы
1:38:37 Кем ты себя видишь через 5 лет?
1:45:10 Как поверить в себя, что ты что то можешь?
1:46:05 Об отпуске.
1:47:52 Где я работаю.
1:48:15 Фриланс или галера?
1:51:45 Мое мнение об ML?
1:52:00 Чем бы я занимался, если бы не работал?
1:53:25 Как продвигать себя?
1:56:25 Что такое тлен? Реальный жизненный кейс.
1:59:15 Лучшая десктоп ОС
1:59:40 Сколько часов в неделю я работаю.
2:03:31 Обманывали ли меня на фрилансе?
2:06:20 Насколько сильно нужно прокачивать свои скиллы?
2:07:20 Как стать топ менеджером?
2:13:40 Мои привычки
2:14:10 Из каких стран мои клиенты?
2:15:10 DevOps настройки, как продукт
2:16:10 О паттернах
2:19:50 Java или С++
2:21:26 О технологиях
YouTube
Стрим №1: Работаем в стартапе. Прокачиваем английский. Уходим в отпуск.
Телеграм канал: https://xn--r1a.website/full_of_hatred/
5:00 Как найти хорошего клиента на фрилансе?
10:40 Зачем мне telegram канал?
13:31 Куда инвестировать накопленное?
20:20 Что произошло с моей собственной "шлюпкой"?
35:40 Мой опыт работы в стартапе.
38:18 Жизнь…
5:00 Как найти хорошего клиента на фрилансе?
10:40 Зачем мне telegram канал?
13:31 Куда инвестировать накопленное?
20:20 Что произошло с моей собственной "шлюпкой"?
35:40 Мой опыт работы в стартапе.
38:18 Жизнь…
Сегодня я делаю доклад на KharkivJS, синий зал 17:00.
В 12:00 в баре будет панельная дискуссия на тему "что должен знать js разработчик", я там буду топить за sql =)
Приходите послушать если вы на ивенте.
Когда будет запись, то обязательно выложу.
В 12:00 в баре будет панельная дискуссия на тему "что должен знать js разработчик", я там буду топить за sql =)
Приходите послушать если вы на ивенте.
Когда будет запись, то обязательно выложу.
На конфе вопросы задавали еще, я сюда отвечу, вдруг спрашивающий подписался и прочитает их + другим будет интересно.
>А интересно каждый день делать одно м тоже и просто делать деньги?
Во-первых, как будто что-то плохое.
Во-вторых чел думает что я одно и то же делаю (админки верстаю, наверное из доклада такое впечатление создается), а у меня куча проектов на разных языках и платформах и я все время ищу возможности подучить новое за счет проектов. Вот на прошлом проекте добил наконец недостающие части RoR — ActiveJob, ActionText, ActiveStorage. Я ж инженер епта, мне тоже интересно все красивое и новое, просто я стараюсь сразу все применить.
В-третьих у меня не всегда получается каждый день работать. В пятницу я не работал например.
>Как протолкнуть идею «катосить» и «работать меньше» моему департамент менеджеру?
Человек наверное решил сострить, но вообще если ты норм тип то ты сможешь перейти на парттайм. Если я смог значит и вы сможете. Главное заработать себе хорошую репутацию и доказать что ваша экспертиза будет иметь хорошую ценность даже в рамках 4 часов в неделю.
>Можно ещё больше оптимизировать профит от IT - как вариант брать только предоплаты. Согласен ?
Еще один рофлер. Казалось бы на такой вопрос даже не стоило бы отвечать если бы не одно но. Я сам был свидететелем такой ситуации. Люди сделали контору на 20 людей, набрали предоплат а дальше перестали платить сотрудникам зарплату и начали морозиться от заказчиков и обманывать их. В итоге контора распалась. Так что я не согласен конечно, потому что видел пример когда это не сработало.
>Зарабатываю 5000💶 на галере. Я под потолком?
Типа того.
>А если работать из дома/путешествуя некомфортно? И даже просто отвлекает.
Работать в коворкинге. Ваш кэп.
>Как при удаленной работе не утонуть в прокрастинации?
Отдельный доклад надо делать. Я сам бывает проваливаюсь на несколько дней в тупинг но потом как-то собираюсь с силами и выкарабкиваюсь обратно. Вообще хорошо работает ограничение, например большое количество каких-то нерабочих дел.
>Какая сумма в месяц тебя устроит?
5 косарей норм. Даже 4 — уже неплохо, жить можно. Но вообще хочется больше.
>Ты довольно во многих моделях компаний поработал, поделись, пожалуйста, субъективным мнением, как понять, что пора менять компанию?
Когда зп не повышают в течение года и нет к этому предпосылок.
>Работает ли этот принцип если есть обязательства в виде семьи, собаки, кота, кредитов баушки и т.д.?
У меня есть собака и 4 кошки (было 6), так что работает, все в порядке.
>Как стать жестким чуваком не кодя в свободное от работы время?
Делать это за счет работодателя.
Все остальное совсем уж глупые рофловопросы или на них был ответ в самом докладе. Напоминаю что у нас есть чатик где можно дискаснуть эти темы.
https://xn--r1a.website/joinchat/GPrWF0xXYzHYKz2b4P9nvw
>А интересно каждый день делать одно м тоже и просто делать деньги?
Во-первых, как будто что-то плохое.
Во-вторых чел думает что я одно и то же делаю (админки верстаю, наверное из доклада такое впечатление создается), а у меня куча проектов на разных языках и платформах и я все время ищу возможности подучить новое за счет проектов. Вот на прошлом проекте добил наконец недостающие части RoR — ActiveJob, ActionText, ActiveStorage. Я ж инженер епта, мне тоже интересно все красивое и новое, просто я стараюсь сразу все применить.
В-третьих у меня не всегда получается каждый день работать. В пятницу я не работал например.
>Как протолкнуть идею «катосить» и «работать меньше» моему департамент менеджеру?
Человек наверное решил сострить, но вообще если ты норм тип то ты сможешь перейти на парттайм. Если я смог значит и вы сможете. Главное заработать себе хорошую репутацию и доказать что ваша экспертиза будет иметь хорошую ценность даже в рамках 4 часов в неделю.
>Можно ещё больше оптимизировать профит от IT - как вариант брать только предоплаты. Согласен ?
Еще один рофлер. Казалось бы на такой вопрос даже не стоило бы отвечать если бы не одно но. Я сам был свидететелем такой ситуации. Люди сделали контору на 20 людей, набрали предоплат а дальше перестали платить сотрудникам зарплату и начали морозиться от заказчиков и обманывать их. В итоге контора распалась. Так что я не согласен конечно, потому что видел пример когда это не сработало.
>Зарабатываю 5000💶 на галере. Я под потолком?
Типа того.
>А если работать из дома/путешествуя некомфортно? И даже просто отвлекает.
Работать в коворкинге. Ваш кэп.
>Как при удаленной работе не утонуть в прокрастинации?
Отдельный доклад надо делать. Я сам бывает проваливаюсь на несколько дней в тупинг но потом как-то собираюсь с силами и выкарабкиваюсь обратно. Вообще хорошо работает ограничение, например большое количество каких-то нерабочих дел.
>Какая сумма в месяц тебя устроит?
5 косарей норм. Даже 4 — уже неплохо, жить можно. Но вообще хочется больше.
>Ты довольно во многих моделях компаний поработал, поделись, пожалуйста, субъективным мнением, как понять, что пора менять компанию?
Когда зп не повышают в течение года и нет к этому предпосылок.
>Работает ли этот принцип если есть обязательства в виде семьи, собаки, кота, кредитов баушки и т.д.?
У меня есть собака и 4 кошки (было 6), так что работает, все в порядке.
>Как стать жестким чуваком не кодя в свободное от работы время?
Делать это за счет работодателя.
Все остальное совсем уж глупые рофловопросы или на них был ответ в самом докладе. Напоминаю что у нас есть чатик где можно дискаснуть эти темы.
https://xn--r1a.website/joinchat/GPrWF0xXYzHYKz2b4P9nvw
Про KharkivJS
Небольшие итоги.
Во-первых хочется отметить место проведения — это здание книжной фабрики "Глобус" еще дореволюционной постройки. Очень крутое помещение, высокие потолки, кирпич без отделки, все как я люблю.
Во-вторых очень круто придумали с дискуссионной панелью. На одной из конф где я был тоже была похожая штука, но без явной модерации и подготовленных вопросов. Тут же была тема, ведущий (Сергей Фролов) который имел набор вопросов чтобы удерживать дискуссию он-топик и зрители которые тоже могли задавать вопросы. Получилось отлично как со стороны зрителя так и со стороны спикера.
В-третьих печеньки и прочий чай в постоянном доступе а не только на перерывах.
В-четвертых, грамотная организация — свет звук кликер переходники видеозапись все супер четко.
В-пятых порадовала публика — хотя я пропустил большинство докладов, залы в основном были достаточно заполнеными. В маленьком зале где по прикидкам вмещается человек 100, многие еще и стояли, потому что не хватило места. Вовлеченность аудитории однозначно имела место быть, я тоже переобщался с кучей людей. Спасибо тем кто пришел, вы лучшие!
А вот система вопросов-ответов через приложение и с голосовалкой мне показалась довольно неоднозначной. Во-первых, лайки собирают вопросы которые задают по ходу доклада в первой половине и на которые скорее всего есть ответ в самом докладе. Во-вторых, 30% — это рофл спам и троллинг, которые человек явно не стал бы говорить докладчику в лицо. Модератор это удалит но все равно. В-третьих, теряется контакт с человеком, ты не знаешь кому отвечаешь и не можешь устроить с ним микродискуссию.
Я не знаю как решить эти проблемы, но теперь точно знаю что то, что я считал такой себе серебрянной пулей для сессий Q&A оказалось скорее коричневой пулей. Мне не оч.
Отдельным аспектом я бы выделил необхоимость организации какого-то spearker corner на всякой конференции, чтобы можно было позадавать ответы не только в течение 10 минут после доклада. Так получается что ко мне после доклада подошли люди, мы общались а дальше начался новый доклад и нам пришлось уйти. Во время "исхода" часть людей потерялась и потом не смогли меня найти. То же самое я могу и сказать и про других спикеров — бывает что чел интересный и хотелось бы пообщаться а он раз и куда-то пропал. Я не организатор и не знаю хорошее решение для этой проблемы (особенно когда спикеров много), но обратной связи мне не хватает с обоих сторон.
Ну вот такие дела, все круто, большое спасибо Сергею Фролову (beerjs) и Артёму Захарченко (NameCheap) за приглашение и организацию.
Небольшие итоги.
Во-первых хочется отметить место проведения — это здание книжной фабрики "Глобус" еще дореволюционной постройки. Очень крутое помещение, высокие потолки, кирпич без отделки, все как я люблю.
Во-вторых очень круто придумали с дискуссионной панелью. На одной из конф где я был тоже была похожая штука, но без явной модерации и подготовленных вопросов. Тут же была тема, ведущий (Сергей Фролов) который имел набор вопросов чтобы удерживать дискуссию он-топик и зрители которые тоже могли задавать вопросы. Получилось отлично как со стороны зрителя так и со стороны спикера.
В-третьих печеньки и прочий чай в постоянном доступе а не только на перерывах.
В-четвертых, грамотная организация — свет звук кликер переходники видеозапись все супер четко.
В-пятых порадовала публика — хотя я пропустил большинство докладов, залы в основном были достаточно заполнеными. В маленьком зале где по прикидкам вмещается человек 100, многие еще и стояли, потому что не хватило места. Вовлеченность аудитории однозначно имела место быть, я тоже переобщался с кучей людей. Спасибо тем кто пришел, вы лучшие!
А вот система вопросов-ответов через приложение и с голосовалкой мне показалась довольно неоднозначной. Во-первых, лайки собирают вопросы которые задают по ходу доклада в первой половине и на которые скорее всего есть ответ в самом докладе. Во-вторых, 30% — это рофл спам и троллинг, которые человек явно не стал бы говорить докладчику в лицо. Модератор это удалит но все равно. В-третьих, теряется контакт с человеком, ты не знаешь кому отвечаешь и не можешь устроить с ним микродискуссию.
Я не знаю как решить эти проблемы, но теперь точно знаю что то, что я считал такой себе серебрянной пулей для сессий Q&A оказалось скорее коричневой пулей. Мне не оч.
Отдельным аспектом я бы выделил необхоимость организации какого-то spearker corner на всякой конференции, чтобы можно было позадавать ответы не только в течение 10 минут после доклада. Так получается что ко мне после доклада подошли люди, мы общались а дальше начался новый доклад и нам пришлось уйти. Во время "исхода" часть людей потерялась и потом не смогли меня найти. То же самое я могу и сказать и про других спикеров — бывает что чел интересный и хотелось бы пообщаться а он раз и куда-то пропал. Я не организатор и не знаю хорошее решение для этой проблемы (особенно когда спикеров много), но обратной связи мне не хватает с обоих сторон.
Ну вот такие дела, все круто, большое спасибо Сергею Фролову (beerjs) и Артёму Захарченко (NameCheap) за приглашение и организацию.
Открытая лекция "Freelance, open-source, public-speaking — как учиться и быть полезным в современном ІТ-мире?", 17 октября, Харьков
Лекцию будет проводить Антон Бабенко — создатель и мейнтейнер terraform aws modules (этой штукой без преувеличения пользуются сотни тысяч людей), AWS Community Hero, спикер и организатор митапов и конференций и вообще жоский тип.
С Антоном я познакомился на конфе DevOpsDays Kyiv — мы разговорились на афтерпати и он поведал интереснейшую историю о своём пути от разработки сайтов на PHP до серьезного консультанта энтерпрайз уровня которого приглашают в большие конторы проводить тренинги и воркшопы по Terraform и DevOps практикам.
Прошел эволюцию: фриланс, опенсорс проекты, консалтинг и свой продукт для визуального проектирования и управления инфраструктурой.
Короче говоря, топ чувак, если вы будете в Харькове в это время обязательно посетите — Антон будет говорить толковые вещи которые будут интересны вам если вы ищете пути, как не застрять в найме.
https://dou.ua/calendar/28851/
Лекцию будет проводить Антон Бабенко — создатель и мейнтейнер terraform aws modules (этой штукой без преувеличения пользуются сотни тысяч людей), AWS Community Hero, спикер и организатор митапов и конференций и вообще жоский тип.
С Антоном я познакомился на конфе DevOpsDays Kyiv — мы разговорились на афтерпати и он поведал интереснейшую историю о своём пути от разработки сайтов на PHP до серьезного консультанта энтерпрайз уровня которого приглашают в большие конторы проводить тренинги и воркшопы по Terraform и DevOps практикам.
Прошел эволюцию: фриланс, опенсорс проекты, консалтинг и свой продукт для визуального проектирования и управления инфраструктурой.
Короче говоря, топ чувак, если вы будете в Харькове в это время обязательно посетите — Антон будет говорить толковые вещи которые будут интересны вам если вы ищете пути, как не застрять в найме.
https://dou.ua/calendar/28851/
ДОУ
Відкрита лекція «Freelance, open-source, public speaking — як вчитися і при цьому бути корисним в сучасному IT-світі?», 17 жовтня…
CEO Норвезької компанії Betajob Антон Бабенко на власному прикладі розповість як можна трансформувати цікаві комп'ютерні хобі, щоб бути затребуваним в сучасному IT-світі. А саме, що треба робити? Як розвиватися? З чого почати, якщо цікаво все або нічого?
Як спровокувати срач в інтернеті
Є кілька тем, щодо яких у будь-якої людини є думка:
- Релігія
- Політика
- Стосунки
Обговорення цих тем відразу провокує срач і в термінальних випадках приводить до «знайду по ІР». Два роки тому у твітер треді про women in tech мені люди без жартів погрожували фізичною розправою, хоча я нічого образливого або радикально-провокуючого не казав.
Хочете пошуміти — обирайте одну з цих тем та вперед — гарантовано отримаєте потужну дискусію, щоправда, абсолютно деструктивну та марну.
Нікому не цікаво обговорювати реакт проти вуе проти свелте. Тому що там є чіткі показники — зірочки на гітхабі, успішні проєкти, вакансії та інше. Всі більш-менш можна виміряти, а коли є факти то ніби вже й говорити ні про що. Упороті, що доводять панування однієї технології над іншими швидкою здуваються від пропозиції поділитися історіями успіху (на ДОУ є хлопець що всюди пхає скалу на питання, а на запитання про те, що він сам на ній зробив, нічого не відповідає).
Зовсім інше — базікати про речі, на які не маєш прямого впливу, але маєш надзвичайно важливі переконання що фемінізм/патріархат це добре, християнство/буддизм/атеїзм це дуже правильно, лібералізм/консерватизм це дорога у світле майбутнє.
Працює для будь-якої спільноти, чата, навколопрофесійного чи ні, знайомих, не знайомців і так далі.
Я, за можливості, намагаюсь дистанціюватися від таких обговорень, тому що свою правоту ти нікому не доведеш, а надати голі факти, наприклад «я побудував конструктивну релігійну секту і ось мої результати, що свідчать про те що А ліпше за Б» дуже складно, історичні факти самі по собі досить об'ємні та легко інтерпретуються в обидва боки. Мало хто з нас (лише тільки деякі) мають достатньо впливу, щоб проводити такі експерименти та ще менше хто готовий розповідати про це публічно.
#лайфстайл
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Є кілька тем, щодо яких у будь-якої людини є думка:
- Релігія
- Політика
- Стосунки
Обговорення цих тем відразу провокує срач і в термінальних випадках приводить до «знайду по ІР». Два роки тому у твітер треді про women in tech мені люди без жартів погрожували фізичною розправою, хоча я нічого образливого або радикально-провокуючого не казав.
Хочете пошуміти — обирайте одну з цих тем та вперед — гарантовано отримаєте потужну дискусію, щоправда, абсолютно деструктивну та марну.
Нікому не цікаво обговорювати реакт проти вуе проти свелте. Тому що там є чіткі показники — зірочки на гітхабі, успішні проєкти, вакансії та інше. Всі більш-менш можна виміряти, а коли є факти то ніби вже й говорити ні про що. Упороті, що доводять панування однієї технології над іншими швидкою здуваються від пропозиції поділитися історіями успіху (на ДОУ є хлопець що всюди пхає скалу на питання, а на запитання про те, що він сам на ній зробив, нічого не відповідає).
Зовсім інше — базікати про речі, на які не маєш прямого впливу, але маєш надзвичайно важливі переконання що фемінізм/патріархат це добре, християнство/буддизм/атеїзм це дуже правильно, лібералізм/консерватизм це дорога у світле майбутнє.
Працює для будь-якої спільноти, чата, навколопрофесійного чи ні, знайомих, не знайомців і так далі.
Я, за можливості, намагаюсь дистанціюватися від таких обговорень, тому що свою правоту ти нікому не доведеш, а надати голі факти, наприклад «я побудував конструктивну релігійну секту і ось мої результати, що свідчать про те що А ліпше за Б» дуже складно, історичні факти самі по собі досить об'ємні та легко інтерпретуються в обидва боки. Мало хто з нас (лише тільки деякі) мають достатньо впливу, щоб проводити такі експерименти та ще менше хто готовий розповідати про це публічно.
#лайфстайл
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Ищу джуна за обучение на благотворительный проект
Как некоторым известно, я немного принимаю участие в разных благотворительных инициативах связанных с зоозащитной деятельностью.
Сейчас у нас есть в работе проект переделки сайта https://www.adopt.com.ua Суть такова — каталог животных на пристройство. Сейчас он реализован на вордпрессе с каким-то екоммерс плагином, и его совершенно невозможно поддерживать и модифицировать. Я хочу все это дело переписать на Ruby on Rails но у меня на это не хватает времени.
Поэтому я решил попробовать найти кого-то согласного работать за обучение, потому что проект некоммерческий и я сам за его разработку не получу ни копейки.
Итак, стек технологий
- монолит на Ruby on Rails
- админка на базе AdminLTE
- пользовательскую часть будем верстать вначале на bulma, дальше посмотрим
- js фреймворк Stimulus (stimulusjs.org) для мелких работ на фронтенде. Я хочу чтобы в проекте было минимум js, и максимум простого html с сервера. Никаких SPA.
- база данных Postgres
- CDN на AWS
- Бэкграунд джобы — Sidekiq
- Почта и может быть что-нибудь еще на AWS тоже
- Деплой в Heroku
- Сорцы и CI/CD на GitLab
Уже есть каркас приложения и некоторая базовая функциональность. Нужно это довести до ума.
Что предлагаю я:
- менторство в объеме полчаса-час в день (объем может варьироваться потому что я еще не работал так и не знаю как пойдет)
- запись на линкедине о работе в моей компании (https://www.linkedin.com/company/devlify/about/) и рекомендации при последующем трудоустройстве
- работу по правильным методологиям с правильными инструментами. Jira, GitLab, код ревью и тд.
Что получаете вы:
- изучите Rails на реальном проекте
- получите себе проект который натурально можно будет показывать на собесах и рассказывать что именно и как вы сделали
- помощь в подготовке в собесам
У меня есть пока что только одна success story по Rails: студент без опыта которого я взял на работу в свою компанию пару лет назад проработав у меня около 9 месяцев над схожим проектом (но коммерческим) в итоге устроился в большую контору в Киеве на тыщу баксов или около того.
Кого я ищу:
- человека могущего на чём-нибудь программировать и минимально умеющего в SQL и HTML
- готового уделять проекту 15 часов в неделю
- умеющего в *nix потому что rails на винде это боль
- желательно студента потому что предполагается что работать вы будете за опыт
Где записаться? Заполняйте форму https://forms.gle/pihaXuYjsPJ9WmHPA . Я изучу предложения и после этого выкачу тестовое задание (сделать простой сайт на Rails), дальше собес и начинаем работу.
P.S.: Почему Ruby on Rails? Потому что я очень люблю Ruby и Rails, считаю его лучшим веб и не только фреймворком и сделал на нём кучу проектов.
Как некоторым известно, я немного принимаю участие в разных благотворительных инициативах связанных с зоозащитной деятельностью.
Сейчас у нас есть в работе проект переделки сайта https://www.adopt.com.ua Суть такова — каталог животных на пристройство. Сейчас он реализован на вордпрессе с каким-то екоммерс плагином, и его совершенно невозможно поддерживать и модифицировать. Я хочу все это дело переписать на Ruby on Rails но у меня на это не хватает времени.
Поэтому я решил попробовать найти кого-то согласного работать за обучение, потому что проект некоммерческий и я сам за его разработку не получу ни копейки.
Итак, стек технологий
- монолит на Ruby on Rails
- админка на базе AdminLTE
- пользовательскую часть будем верстать вначале на bulma, дальше посмотрим
- js фреймворк Stimulus (stimulusjs.org) для мелких работ на фронтенде. Я хочу чтобы в проекте было минимум js, и максимум простого html с сервера. Никаких SPA.
- база данных Postgres
- CDN на AWS
- Бэкграунд джобы — Sidekiq
- Почта и может быть что-нибудь еще на AWS тоже
- Деплой в Heroku
- Сорцы и CI/CD на GitLab
Уже есть каркас приложения и некоторая базовая функциональность. Нужно это довести до ума.
Что предлагаю я:
- менторство в объеме полчаса-час в день (объем может варьироваться потому что я еще не работал так и не знаю как пойдет)
- запись на линкедине о работе в моей компании (https://www.linkedin.com/company/devlify/about/) и рекомендации при последующем трудоустройстве
- работу по правильным методологиям с правильными инструментами. Jira, GitLab, код ревью и тд.
Что получаете вы:
- изучите Rails на реальном проекте
- получите себе проект который натурально можно будет показывать на собесах и рассказывать что именно и как вы сделали
- помощь в подготовке в собесам
У меня есть пока что только одна success story по Rails: студент без опыта которого я взял на работу в свою компанию пару лет назад проработав у меня около 9 месяцев над схожим проектом (но коммерческим) в итоге устроился в большую контору в Киеве на тыщу баксов или около того.
Кого я ищу:
- человека могущего на чём-нибудь программировать и минимально умеющего в SQL и HTML
- готового уделять проекту 15 часов в неделю
- умеющего в *nix потому что rails на винде это боль
- желательно студента потому что предполагается что работать вы будете за опыт
Где записаться? Заполняйте форму https://forms.gle/pihaXuYjsPJ9WmHPA . Я изучу предложения и после этого выкачу тестовое задание (сделать простой сайт на Rails), дальше собес и начинаем работу.
P.S.: Почему Ruby on Rails? Потому что я очень люблю Ruby и Rails, считаю его лучшим веб и не только фреймворком и сделал на нём кучу проектов.
Resume Driven Development
Один из частых вопросов у любого инженера (и не только) — как и когда учить новое? Технологии (по крайней мере внешне) обновляются довольно быстро, количество инструментов, которыми необходимо владеть для ежедневной работы растёт и нужно все это как-то изучать и применять.
Для решения этой проблемы и была придумана методология RDD она же Resume Driven Development.
Для начала ответим на вопрос "как?", он же "форма обучения". Я считаю, что всё нужно изучать на реальных и нужных кому-то проектах (e.g. за которые вы получите деньги — зарплату или фиксированную сумму), и чем более они являются реальными и нужными, тем быстрее и качественнее будет идти обучение. Не стоит резать пациента, не умея держать скальпель в руках и нужно соизмерять риски, но сделаем предположение, что совсем новичка не пустят в разработку критичных вещей.
"Когда?" — раз реальные проекты — значит на реальной работе. Я считаю что неэффективно тратить своё личное время на изучение новых штук, когда у вас есть возможность делать это на работе.
Для того чтобы эффективно заниматься RDD нужно выполнить несколько пререквизитов:
- иметь кредит доверия у того, кто решает, что делать на проекте
- своими действиями принести проекту хоть какую-то пользу
Кредит доверия вы получаете в двух случаях: когда вас только взяли на новое место работы или когда вы достаточно долго проработали на текущем месте и каким-то образом зарекомендовали себя.
Понятное дело что явно неопытному инженеру никто не доверит добавлять рисков в проект, так же как и на работу где совершенно точно прямо сейчас нужна некая экспертиза, вас просто не возьмут.
С другой стороны, если вас отсобеседовали и взяли на проект где есть вещи, которые вам не знакомы, значит полностью соизмеряют риски которые связаны с этим.
Приносите пользу вы решая какие-то конкретные проблемы бизнеса. Просто так новая рюшка никому не интересна, она должна закрывать какую-то боль.
Дальше рассмотрим конкретные сценарии и примеры как я занимался RDD, и как учить новые вещи не в личное время а в рабочее.
Один из частых вопросов у любого инженера (и не только) — как и когда учить новое? Технологии (по крайней мере внешне) обновляются довольно быстро, количество инструментов, которыми необходимо владеть для ежедневной работы растёт и нужно все это как-то изучать и применять.
Для решения этой проблемы и была придумана методология RDD она же Resume Driven Development.
Для начала ответим на вопрос "как?", он же "форма обучения". Я считаю, что всё нужно изучать на реальных и нужных кому-то проектах (e.g. за которые вы получите деньги — зарплату или фиксированную сумму), и чем более они являются реальными и нужными, тем быстрее и качественнее будет идти обучение. Не стоит резать пациента, не умея держать скальпель в руках и нужно соизмерять риски, но сделаем предположение, что совсем новичка не пустят в разработку критичных вещей.
"Когда?" — раз реальные проекты — значит на реальной работе. Я считаю что неэффективно тратить своё личное время на изучение новых штук, когда у вас есть возможность делать это на работе.
Для того чтобы эффективно заниматься RDD нужно выполнить несколько пререквизитов:
- иметь кредит доверия у того, кто решает, что делать на проекте
- своими действиями принести проекту хоть какую-то пользу
Кредит доверия вы получаете в двух случаях: когда вас только взяли на новое место работы или когда вы достаточно долго проработали на текущем месте и каким-то образом зарекомендовали себя.
Понятное дело что явно неопытному инженеру никто не доверит добавлять рисков в проект, так же как и на работу где совершенно точно прямо сейчас нужна некая экспертиза, вас просто не возьмут.
С другой стороны, если вас отсобеседовали и взяли на проект где есть вещи, которые вам не знакомы, значит полностью соизмеряют риски которые связаны с этим.
Приносите пользу вы решая какие-то конкретные проблемы бизнеса. Просто так новая рюшка никому не интересна, она должна закрывать какую-то боль.
Дальше рассмотрим конкретные сценарии и примеры как я занимался RDD, и как учить новые вещи не в личное время а в рабочее.
Resume Driven Development. Углубление экспертизы через изменение старого
В далёком 2010 году я зарегался на линкедине и буквально сразу же меня позвали на собес на Java позицию в Люксофт. Если не ошибаюсь, то был мой самый первый собес и спрашивали меня там про Spring и Hibernate. Специфика работы места, где я тогда работал заключалась в том, что разработчики в основном использовали самописные фреймворки, в том числе для доступа к базе и DI. Естественно, ни спринга ни хибера я не знал, потому что у меня на работе их не было, о чем немедленно сообщил интервьюеру. Однако в конце беседы оказалось что я им понравился и они готовы меня брать, а недостающее я подучу по ходу дела. Мне сделали оффер если я не ошибаюсь на 1400$, который я принес и положил руководству на стол. Руководство почесалось и сделало контроффер в 1500$ ну я и остался.
Однако мысли о спринге меня не покидали, беспокоило, что есть какая-то штука, которая всем нужна, но совершенно мне непонятна и нужно было что-то с этим делать.
Шанс представился очень быстро — буквально через несколько месяцев я попал на проект с бравыми ребятами из ThoughtWorks и там мне в популярной форме объяснили что такое TDD и IoC. Однако в нашей платформе не было возможности вообще никак это делать, вот просто потому что не было. Кроме того, по неизвестной мне причине, бытовало мнение что 3rd-party библиотеки вообще сложно протащить в из-за лицензионных ограничений.
Но я это все проигнорировал, и в рабочее и совсем немного в нерабочее время сделал прототип внедрения Spring в нашу платформу. Причем он там реально был нужен, потому что проект требовал возможности переопределять платформенную логику и DI отлично решал эту проблему попутно добавляя разных полезностей вроде тестабельности кода.
- у меня был кредит доверия, потому что я тогда считался сеньеролидом
- внедрение новой технологии однозначно решало определённую (причем довольно серьезную) проблему
- я смог представить это своему руководству как "незначительное улучшение которое позволит нам внедрять проекты быстрее", хотя двумя годами ранее мой тимлид не смог продать ту же самую идею тому же самому начальству
Потом самостоятельно я сделал запрос в отдел который занимался опенсорс лицензиями и получил добро на добавление зависимости на спринг. Что интересно, оказалось что его уже использовали ребята из другого компонента, но не так, как нам нужно было.
Как показали дальнейшие события, я оказался тем человеком, который катализировал использование Spring по всей компании. Дальше на него начали переползать другие отделы. До сих пор считаю это своим самым значительным достижением с точки зрения импакта на инжиниринг.
P.S.: После этого на собесах я уже не терялся на вопросах по IoC, а рассказывал даже больше чем нужно, потому что не пришел на проект где было все готовое, а осознал конкретную проблему, которую решает фреймворк и применил его для этого.
В далёком 2010 году я зарегался на линкедине и буквально сразу же меня позвали на собес на Java позицию в Люксофт. Если не ошибаюсь, то был мой самый первый собес и спрашивали меня там про Spring и Hibernate. Специфика работы места, где я тогда работал заключалась в том, что разработчики в основном использовали самописные фреймворки, в том числе для доступа к базе и DI. Естественно, ни спринга ни хибера я не знал, потому что у меня на работе их не было, о чем немедленно сообщил интервьюеру. Однако в конце беседы оказалось что я им понравился и они готовы меня брать, а недостающее я подучу по ходу дела. Мне сделали оффер если я не ошибаюсь на 1400$, который я принес и положил руководству на стол. Руководство почесалось и сделало контроффер в 1500$ ну я и остался.
Однако мысли о спринге меня не покидали, беспокоило, что есть какая-то штука, которая всем нужна, но совершенно мне непонятна и нужно было что-то с этим делать.
Шанс представился очень быстро — буквально через несколько месяцев я попал на проект с бравыми ребятами из ThoughtWorks и там мне в популярной форме объяснили что такое TDD и IoC. Однако в нашей платформе не было возможности вообще никак это делать, вот просто потому что не было. Кроме того, по неизвестной мне причине, бытовало мнение что 3rd-party библиотеки вообще сложно протащить в из-за лицензионных ограничений.
Но я это все проигнорировал, и в рабочее и совсем немного в нерабочее время сделал прототип внедрения Spring в нашу платформу. Причем он там реально был нужен, потому что проект требовал возможности переопределять платформенную логику и DI отлично решал эту проблему попутно добавляя разных полезностей вроде тестабельности кода.
- у меня был кредит доверия, потому что я тогда считался сеньеролидом
- внедрение новой технологии однозначно решало определённую (причем довольно серьезную) проблему
- я смог представить это своему руководству как "незначительное улучшение которое позволит нам внедрять проекты быстрее", хотя двумя годами ранее мой тимлид не смог продать ту же самую идею тому же самому начальству
Потом самостоятельно я сделал запрос в отдел который занимался опенсорс лицензиями и получил добро на добавление зависимости на спринг. Что интересно, оказалось что его уже использовали ребята из другого компонента, но не так, как нам нужно было.
Как показали дальнейшие события, я оказался тем человеком, который катализировал использование Spring по всей компании. Дальше на него начали переползать другие отделы. До сих пор считаю это своим самым значительным достижением с точки зрения импакта на инжиниринг.
P.S.: После этого на собесах я уже не терялся на вопросах по IoC, а рассказывал даже больше чем нужно, потому что не пришел на проект где было все готовое, а осознал конкретную проблему, которую решает фреймворк и применил его для этого.
Resume Driven Development. Углубление экспертизы через разработку нового
Другая история произошла уже в 2014 году. Помимо известных событий, тогда же я посетил конференцию JavaDay. То было как раз время хайпа по микросервисам и там я попал на доклад, где показывали как работает решение на Spring Cloud Netflix, сервис дискавери, circuit breakers все дела. Я этим докладом очень сильно вдохновился и прям прозрел насколько (как мне казалось тогда) крутые вещи происходят в мире в то время когда я пилю JavaEE монолиты. На работе как раз тогда начинались всякие облачные инициативы и я вписался в архитектурный комитет где мы рисовали диаграмки и занимались другой непродуктивной деятельностью.
Однако довольно быстро я сообразил что просто так что-нибудь поделать, реализовать тут мне никто не даст, и с этим надо было что-то решать. Поэтому я пошел на поиски работы где будут облака и микросервисы. Таковая очень быстро нашлась и меня взяли первым инженером в перспективный стартап.
Когда я туда пришел, то не знал, ни как делаются микросервисы в продакшене, ни как работают облака и имел об этом всём только теоретическое представление. Но CTO дал мне достаточный кредит доверия, на который я разработал прототип, защитил его, и дальше команда на этой базе делала непосредственно продукт. Тот же CTO одним из условий поставил использование NoSQL решений, так что тут еще эту тему пришлось плотно изучить (самый топчик был когда для хранения информации об отложенных задачах использовали записи в S3 бакете который потом читался спарком. Полная дичь. До прода так и не дошло). Все это потом успешно было запущено в продакшн и живет до сих пор в более-менее неизменном виде.
Итак,
- у меня был кредит доверия от руководства, несмотря на то, что я не имел практического опыта с технологиями, которые требовались
- руководство понимало риски и соизмеряло их с потенциальной пользой, поэтому и дало возможность мне и команде обучиться фактически за их время
Таким образом я на работе изучил кучу интересных штук в рамках своей основной экспертизы (Java) и потом еще и запустил это всё в прод.
Эти знания мне позже пригодились как в принципе, потому что многие из них были фундаментальными, так и на собесах где я ловко поражал интервьюеров знаниями как работают потроха Spring Cloud штук.
Другая история произошла уже в 2014 году. Помимо известных событий, тогда же я посетил конференцию JavaDay. То было как раз время хайпа по микросервисам и там я попал на доклад, где показывали как работает решение на Spring Cloud Netflix, сервис дискавери, circuit breakers все дела. Я этим докладом очень сильно вдохновился и прям прозрел насколько (как мне казалось тогда) крутые вещи происходят в мире в то время когда я пилю JavaEE монолиты. На работе как раз тогда начинались всякие облачные инициативы и я вписался в архитектурный комитет где мы рисовали диаграмки и занимались другой непродуктивной деятельностью.
Однако довольно быстро я сообразил что просто так что-нибудь поделать, реализовать тут мне никто не даст, и с этим надо было что-то решать. Поэтому я пошел на поиски работы где будут облака и микросервисы. Таковая очень быстро нашлась и меня взяли первым инженером в перспективный стартап.
Когда я туда пришел, то не знал, ни как делаются микросервисы в продакшене, ни как работают облака и имел об этом всём только теоретическое представление. Но CTO дал мне достаточный кредит доверия, на который я разработал прототип, защитил его, и дальше команда на этой базе делала непосредственно продукт. Тот же CTO одним из условий поставил использование NoSQL решений, так что тут еще эту тему пришлось плотно изучить (самый топчик был когда для хранения информации об отложенных задачах использовали записи в S3 бакете который потом читался спарком. Полная дичь. До прода так и не дошло). Все это потом успешно было запущено в продакшн и живет до сих пор в более-менее неизменном виде.
Итак,
- у меня был кредит доверия от руководства, несмотря на то, что я не имел практического опыта с технологиями, которые требовались
- руководство понимало риски и соизмеряло их с потенциальной пользой, поэтому и дало возможность мне и команде обучиться фактически за их время
Таким образом я на работе изучил кучу интересных штук в рамках своей основной экспертизы (Java) и потом еще и запустил это всё в прод.
Эти знания мне позже пригодились как в принципе, потому что многие из них были фундаментальными, так и на собесах где я ловко поражал интервьюеров знаниями как работают потроха Spring Cloud штук.
Resume Driven Development. Расширение экспертизы через разработку нового
Мы рассмотрели как можно копнуть вглубь своей экспертизы внедряя новые вещи в существующее решение, или разрабатывая что-то с нуля. Теперь поговорим о том, как расширить экспертизу и стать T-специалистом.
Под расширением я понимаю наработку опыта в смежных с вашей областях. Для бекенд разработчика (коим я являюсь) это разработка бекенда на другом языке, фронтенд, инфраструктурные вещи (девопс), автоматизация тестирования, data science и так далее, продолжите сами.
Тут есть несколько вариантов развития:
Первый — заполнение постоянно существующей нехватки или дефицита экспертизы
Возвращаясь к стартапу, где я работал, помимо собственно разработки бекенда, нужно было всё это каким-то образом деплоить. Я (а также мой CTO) решил что мне это интересно и плотно засел за CloudFormation докеры шмокеры облака vpc самопальный дженкинс с сотнями баш скриптов и другие инфраструктурные вещи. У меня получилось относительно неплохо, и со временем я стал все больше заниматься инфраструктурой и инструментарием вокруг этого, и все меньше разработкой продукта. Таким образом я заполнил существующую позицию на которую не было человека (девопса), при этом не отрывался от своей основной работы далеко (бекенд) и решил проблему бизнеса (построил CI/CD).
Продолжая историю, когда я уже отошёл от дел в этом стартапе, то другой коллега, сходив на конференцию где был доклад по Terraform, перепилил CFN в Terrafrom, переписал и упорядочил bash деплоймент скрипты, которые я сделал, и переписал внутреннюю тулзу для деплоя в продакшн (первую версию которой я сделал на node.js) на Go. Всё стало сильно лучше и потом уже я ретроспективно учил Terraform по его наработкам. Парень знает толк в RDD, берите с него пример. Как ему удалось это сделать? У него был кредит доверия :) А у бизнеса — время на реализацию этих штук.
Второй вариант развития — заполнение временной нехватки
Часто бывает так что на некоторых участках работ загруженность значительно выше, нежели на других. Например, весь бекенд уже написали и сейчас пилят фронтенд. Или наоборот. Такие моменты нужно ловить и пробовать расширяться в то время когда у вас спокойный период, а у других — напряжный. Например, вы можете помочь коллегам-фронтендерам с небольшими фиксами или некритичными доработками, пока основные силы будут брошены на более серьезные вещи. Это может происходить по вашей или по менеджерской инициативе, и я советую этим пользоваться даже если вначале не хочется.
Традиционно разработчики предпочитаю засовывать голову в песок и говорить "не, это фронтенд (или бекенд), я этим заниматься не буду и не хочу, мне комфортно в моей песочнице". Конечно можно и так делать, но если есть возможность изучить что-то новое а в идеальном случае еще и получить небольшое менторство, то почему бы и нет? Вы ничем не рискуете, и сможете как только так сразу вернуться к своим делам, команда тоже ничем не рискует потому что очевидно не будет давать вам критичные вещи, все в профите.
Мы рассмотрели как можно копнуть вглубь своей экспертизы внедряя новые вещи в существующее решение, или разрабатывая что-то с нуля. Теперь поговорим о том, как расширить экспертизу и стать T-специалистом.
Под расширением я понимаю наработку опыта в смежных с вашей областях. Для бекенд разработчика (коим я являюсь) это разработка бекенда на другом языке, фронтенд, инфраструктурные вещи (девопс), автоматизация тестирования, data science и так далее, продолжите сами.
Тут есть несколько вариантов развития:
Первый — заполнение постоянно существующей нехватки или дефицита экспертизы
Возвращаясь к стартапу, где я работал, помимо собственно разработки бекенда, нужно было всё это каким-то образом деплоить. Я (а также мой CTO) решил что мне это интересно и плотно засел за CloudFormation докеры шмокеры облака vpc самопальный дженкинс с сотнями баш скриптов и другие инфраструктурные вещи. У меня получилось относительно неплохо, и со временем я стал все больше заниматься инфраструктурой и инструментарием вокруг этого, и все меньше разработкой продукта. Таким образом я заполнил существующую позицию на которую не было человека (девопса), при этом не отрывался от своей основной работы далеко (бекенд) и решил проблему бизнеса (построил CI/CD).
Продолжая историю, когда я уже отошёл от дел в этом стартапе, то другой коллега, сходив на конференцию где был доклад по Terraform, перепилил CFN в Terrafrom, переписал и упорядочил bash деплоймент скрипты, которые я сделал, и переписал внутреннюю тулзу для деплоя в продакшн (первую версию которой я сделал на node.js) на Go. Всё стало сильно лучше и потом уже я ретроспективно учил Terraform по его наработкам. Парень знает толк в RDD, берите с него пример. Как ему удалось это сделать? У него был кредит доверия :) А у бизнеса — время на реализацию этих штук.
Второй вариант развития — заполнение временной нехватки
Часто бывает так что на некоторых участках работ загруженность значительно выше, нежели на других. Например, весь бекенд уже написали и сейчас пилят фронтенд. Или наоборот. Такие моменты нужно ловить и пробовать расширяться в то время когда у вас спокойный период, а у других — напряжный. Например, вы можете помочь коллегам-фронтендерам с небольшими фиксами или некритичными доработками, пока основные силы будут брошены на более серьезные вещи. Это может происходить по вашей или по менеджерской инициативе, и я советую этим пользоваться даже если вначале не хочется.
Традиционно разработчики предпочитаю засовывать голову в песок и говорить "не, это фронтенд (или бекенд), я этим заниматься не буду и не хочу, мне комфортно в моей песочнице". Конечно можно и так делать, но если есть возможность изучить что-то новое а в идеальном случае еще и получить небольшое менторство, то почему бы и нет? Вы ничем не рискуете, и сможете как только так сразу вернуться к своим делам, команда тоже ничем не рискует потому что очевидно не будет давать вам критичные вещи, все в профите.
👍2
Resume Driven Development. Расширение экспертизы через разработку прототипов и RnD проектов
Мы разобрали ситуации, когда фронт работ примерно понятен и нужно только копать. Но бывают случаи, когда надо делать вещи, которые раньше никто не делал, или для которых нет экспертизы вообще.
В этом месте на сцене должны появиться вы.
Однажды ко мне попал проект от сумасшедшего — писатель собирался издать книгу, на страницах которой были бы размещены специальные изображения, при наведении на которые камеры смартфона, нужно было проигрывать аудио или видозаписи. Такой себе расширенный экспириенс. Собственно технически задача состояла в том что у нас был набор эталонных изображений, которые нужно было сопоставлять с тем, что поступает от камеры. Дело осложнялось тем, что всё должно было работать оффлайн и на двух платформах (android/ios)
Для этих целей позвали меня и пришлось быстро освоить OpenCV, потом запихнуть это в мобилы, потом долго вручную подбирать коэффициенты/алгоритмы и экспериментировать с размерами эталонных изображений и того что приходит с камеры.
Нам удалось сделать неплохую точность распознавания, но все равно она местами сбоила из-за похожести эталонных изображений (два почти одинаковых рояля под разными углами например).
Два года спустя этот опыт пригодился мне когда уже другой заказчик пришел с вопросом можем ли мы делать сравнение изображений. Там уже была возможность отправлять данные на сервер, я опять вооружился питоном и OpenCV и соорудил примерно то же самое, что и на первом проекте.
К сожалению, и в этот раз нам дали библиотеку невероятно похожих изображений (потому что их делали без учёта технических требований а просто надизайнили как есть) и точность распознавания получилась очень низкая — 60% или около того и это еще с костылями по сравнению цветов и формы а не только по фичам которые вытащил SIFT.
Думаю, вы уловили суть — на пустом месте мне пришлось быстро вникнуть в совершенно новую для меня технологию, попутно подучить новый язык и реализовать интересную штуку.
- у меня был кредит доверия от руководства в первом случае и от заказчика во втором
- задача была совершенно реальная и за нее мне даже заплатили денег
Про OpenCV только один пример, самый яркий, когда я разбирался вообще с чем-то совершенно новым, непредсказуемым и отличным от моей основной экспертизы. Таким образом я постоянно изучаю новые вещи — ищу возможности где можно применить технологию, сделать прототип и получить из этого пользу в виде новых знаний.
Мы разобрали ситуации, когда фронт работ примерно понятен и нужно только копать. Но бывают случаи, когда надо делать вещи, которые раньше никто не делал, или для которых нет экспертизы вообще.
В этом месте на сцене должны появиться вы.
Однажды ко мне попал проект от сумасшедшего — писатель собирался издать книгу, на страницах которой были бы размещены специальные изображения, при наведении на которые камеры смартфона, нужно было проигрывать аудио или видозаписи. Такой себе расширенный экспириенс. Собственно технически задача состояла в том что у нас был набор эталонных изображений, которые нужно было сопоставлять с тем, что поступает от камеры. Дело осложнялось тем, что всё должно было работать оффлайн и на двух платформах (android/ios)
Для этих целей позвали меня и пришлось быстро освоить OpenCV, потом запихнуть это в мобилы, потом долго вручную подбирать коэффициенты/алгоритмы и экспериментировать с размерами эталонных изображений и того что приходит с камеры.
Нам удалось сделать неплохую точность распознавания, но все равно она местами сбоила из-за похожести эталонных изображений (два почти одинаковых рояля под разными углами например).
Два года спустя этот опыт пригодился мне когда уже другой заказчик пришел с вопросом можем ли мы делать сравнение изображений. Там уже была возможность отправлять данные на сервер, я опять вооружился питоном и OpenCV и соорудил примерно то же самое, что и на первом проекте.
К сожалению, и в этот раз нам дали библиотеку невероятно похожих изображений (потому что их делали без учёта технических требований а просто надизайнили как есть) и точность распознавания получилась очень низкая — 60% или около того и это еще с костылями по сравнению цветов и формы а не только по фичам которые вытащил SIFT.
Думаю, вы уловили суть — на пустом месте мне пришлось быстро вникнуть в совершенно новую для меня технологию, попутно подучить новый язык и реализовать интересную штуку.
- у меня был кредит доверия от руководства в первом случае и от заказчика во втором
- задача была совершенно реальная и за нее мне даже заплатили денег
Про OpenCV только один пример, самый яркий, когда я разбирался вообще с чем-то совершенно новым, непредсказуемым и отличным от моей основной экспертизы. Таким образом я постоянно изучаю новые вещи — ищу возможности где можно применить технологию, сделать прототип и получить из этого пользу в виде новых знаний.
Resume Driven Development. Итоги
Подытожим — как и когда учить новые штуки, применять современные технологии и при этом нормально жить не выжигая глаза кодом 24х7:
- искать работу где применяются интересные вам вещи
- искать возможности улучшить проект, над которым вы работаете с технической стороны так, чтобы это принесло пользу бизнесу
- смотреть за тем, что происходит вокруг и по возможности брать некритичные участки работы из смежных областей
- закрывать дефицит экспертизы, если есть такая необходимость
- не зарывать голову в песок и не бояться пробовать новое. В крайнем случае, если не получается или не нравится то всегда можно отвалиться и сделать лапки (главное не злоупотреблять а то потеряете кредит доверия)
Для того чтобы у вас была возможность всё это делать, нужно всего ничего — быть норм типом с головой на плечах а дальше:
- получить кредит доверия
- грамотно оценивать риски vs польза vs критичность. Плохо будет, если бизнес вам доверится, а вы не вывезете штуку которую обещали сделать, потому что у вас в этом нет глубокой экспертизы или вы наткнулись на неожиданные проблемы.
Такие возможности открываются не сразу и не везде, но я уверен что у каждого на проекте (если это не какой-то махровый энтерпрайз на саппорте) есть возможности двигаться как вглубь так и вширь.
Совершенно необязательно учить новый стек дома по вечерам, нужно просто найти работу, которая позволит это делать днём. Если я смог найти такую работу (и я сейчас говорю про найм, а не про консалтинг), значит и вы сможете.
Некоторые могут сказать что для реализации RDD нужно менять работу каждые полгода — вовсе нет. В стартапе я проработал около трех лет и за это время изучил и применил больше, чем за всю предыдущую жизнь.
Иные скажут — если ты не погружаешься глубоко в какую-то область и работаешь вширь, то это и незачем делать — зачем заниматься девопсом если ты сам не планируешь дальше копать в эту сторон? Ну, я так скажу — во-первых, я за тотальное расширение, E-shape и супер-фуллстечность, когда один в поле воин, во-вторых, как понять что тебе что-то нравится или не нравится если не попробовал, а в-третьих, даже поверхностное знание соседних областей на порядки упрощает коммуникацию ведь ты начинаешь говорить с коллегами на одном языке и дальше, с широкой экспертизой уже смело открываешь себе дверь ногой в архитекторы и CTO.
Подытожим — как и когда учить новые штуки, применять современные технологии и при этом нормально жить не выжигая глаза кодом 24х7:
- искать работу где применяются интересные вам вещи
- искать возможности улучшить проект, над которым вы работаете с технической стороны так, чтобы это принесло пользу бизнесу
- смотреть за тем, что происходит вокруг и по возможности брать некритичные участки работы из смежных областей
- закрывать дефицит экспертизы, если есть такая необходимость
- не зарывать голову в песок и не бояться пробовать новое. В крайнем случае, если не получается или не нравится то всегда можно отвалиться и сделать лапки (главное не злоупотреблять а то потеряете кредит доверия)
Для того чтобы у вас была возможность всё это делать, нужно всего ничего — быть норм типом с головой на плечах а дальше:
- получить кредит доверия
- грамотно оценивать риски vs польза vs критичность. Плохо будет, если бизнес вам доверится, а вы не вывезете штуку которую обещали сделать, потому что у вас в этом нет глубокой экспертизы или вы наткнулись на неожиданные проблемы.
Такие возможности открываются не сразу и не везде, но я уверен что у каждого на проекте (если это не какой-то махровый энтерпрайз на саппорте) есть возможности двигаться как вглубь так и вширь.
Совершенно необязательно учить новый стек дома по вечерам, нужно просто найти работу, которая позволит это делать днём. Если я смог найти такую работу (и я сейчас говорю про найм, а не про консалтинг), значит и вы сможете.
Некоторые могут сказать что для реализации RDD нужно менять работу каждые полгода — вовсе нет. В стартапе я проработал около трех лет и за это время изучил и применил больше, чем за всю предыдущую жизнь.
Иные скажут — если ты не погружаешься глубоко в какую-то область и работаешь вширь, то это и незачем делать — зачем заниматься девопсом если ты сам не планируешь дальше копать в эту сторон? Ну, я так скажу — во-первых, я за тотальное расширение, E-shape и супер-фуллстечность, когда один в поле воин, во-вторых, как понять что тебе что-то нравится или не нравится если не попробовал, а в-третьих, даже поверхностное знание соседних областей на порядки упрощает коммуникацию ведь ты начинаешь говорить с коллегами на одном языке и дальше, с широкой экспертизой уже смело открываешь себе дверь ногой в архитекторы и CTO.
Продажа жопочасов
Большинство из нас продает жопочасы. Работа ли это в найме фулл-тайм или парт-тайм активности — практически всегда вопрос денег сводится к месячной (или годовой) ставке или часовому рейту.
Все так делают, потому что это удобно. Оценивать работу разработчика и проекты сложно, поэтому никто не хочет задаваться этим вопросом. Легко оценить простую повторяющуюся работу, например укладку плитки. Плиточник берет фиксированную сумму за квадратный метр уложенной плитки с поправочными коэффициентами на сложность поверхности и количество подрезок, но даже с ними вычислить стоимость будет довольно просто. Глупо платить мастеру за время, потраченное на укладку? Но с разработчиками не так. Если оценить какую-то бизнес фичу еще с грехом пополам можно, то как быть с багофиксом? Или рефакторингом? Или инфраструктурными улучшениями? Поэтому весь мир дружно забил и платит по часам.
Оставим в стороне вопрос контроля отработанного времени и примем что разрабы репортят часы честно. Что хорошо и что плохо в этой схеме?
Хорошо для разработчика:
- предсказуемость. Ты точно знаешь, что если отсидел Х часов, то получишь за них свои деньги и неважно, сделана задача или нет. Я не видел ни разу, чтобы не платили деньги, даже если выхлопа нет, черт, да я и сам был тем самым человеком который платил за тупинг, ноль прогресса, и ненужные задачи, но считаю это своей проблемой.
- ненапряжность. Отсидел часы и ушел. Менеджер тебя может пожурить за не вовремя сделанную задачу, но больше средств влияния на тебя он не имеет. Максимум что может случиться — это увольнение, вот только на вакантное место придет работать такой же лентяй. Часто ли вы видели чтобы увольняли разработчиков? Я увольнял по причине низкой продуктивности всего два раза — один раз из-за многократных жалоб от проектов и второй раз когда не угадали с наймом джуна.
- полное отсутствие ответственности за результат. Ну не сделал и не сделал, а что? Часы-то отработаны, извольте заплатить.
Хорошо для работодателя:
- предсказуемость по деньгам. Ты точно знаешь какую максимальную сумму заплатишь людям в этом или следующем месяце и можешь планировать затраты
- отсутствие необходимости оценивать и согласовывать каждую задачу в деньгах отдельно (снижаются операционные издержки на РМов и коммуникацию). Time & material и поехали — бей посуду, я плачу. Тут конечно еще можно поспорить хорошо это или плохо, но в основном я вижу что работодателю проще и понятнее платить по часам.
Вроде норм, да? И да и нет, и дальше рассмотрим, почему.
Большинство из нас продает жопочасы. Работа ли это в найме фулл-тайм или парт-тайм активности — практически всегда вопрос денег сводится к месячной (или годовой) ставке или часовому рейту.
Все так делают, потому что это удобно. Оценивать работу разработчика и проекты сложно, поэтому никто не хочет задаваться этим вопросом. Легко оценить простую повторяющуюся работу, например укладку плитки. Плиточник берет фиксированную сумму за квадратный метр уложенной плитки с поправочными коэффициентами на сложность поверхности и количество подрезок, но даже с ними вычислить стоимость будет довольно просто. Глупо платить мастеру за время, потраченное на укладку? Но с разработчиками не так. Если оценить какую-то бизнес фичу еще с грехом пополам можно, то как быть с багофиксом? Или рефакторингом? Или инфраструктурными улучшениями? Поэтому весь мир дружно забил и платит по часам.
Оставим в стороне вопрос контроля отработанного времени и примем что разрабы репортят часы честно. Что хорошо и что плохо в этой схеме?
Хорошо для разработчика:
- предсказуемость. Ты точно знаешь, что если отсидел Х часов, то получишь за них свои деньги и неважно, сделана задача или нет. Я не видел ни разу, чтобы не платили деньги, даже если выхлопа нет, черт, да я и сам был тем самым человеком который платил за тупинг, ноль прогресса, и ненужные задачи, но считаю это своей проблемой.
- ненапряжность. Отсидел часы и ушел. Менеджер тебя может пожурить за не вовремя сделанную задачу, но больше средств влияния на тебя он не имеет. Максимум что может случиться — это увольнение, вот только на вакантное место придет работать такой же лентяй. Часто ли вы видели чтобы увольняли разработчиков? Я увольнял по причине низкой продуктивности всего два раза — один раз из-за многократных жалоб от проектов и второй раз когда не угадали с наймом джуна.
- полное отсутствие ответственности за результат. Ну не сделал и не сделал, а что? Часы-то отработаны, извольте заплатить.
Хорошо для работодателя:
- предсказуемость по деньгам. Ты точно знаешь какую максимальную сумму заплатишь людям в этом или следующем месяце и можешь планировать затраты
- отсутствие необходимости оценивать и согласовывать каждую задачу в деньгах отдельно (снижаются операционные издержки на РМов и коммуникацию). Time & material и поехали — бей посуду, я плачу. Тут конечно еще можно поспорить хорошо это или плохо, но в основном я вижу что работодателю проще и понятнее платить по часам.
Вроде норм, да? И да и нет, и дальше рассмотрим, почему.
👍1
Продажа жопочасов. Чем это плохо для разработчика?
- очевидная невозможность прыгнуть выше рейта. Если зарабатываешь 25$ в час — все, твой максимум в месяц это 4000$, как бы ты не старался (часов больше взять неоткуда будет если не овертаймить). Автоматически устанавливается стеклянный потолок пробить который будет нереально, потому что бизнес не будет нанимать простого консультанта за 300$ в час (будет нанимать топового, но у них отдельное ценообразование).
- невозможность продавать результат своего труда. Ты продаешь свою жопу на стуле а не то, что ты сделал. Норм тип может сделать проект, который два джуна будут колбасить полгода, за две недели. Вот только продавать он будет его не за 12 000$ (сумма полугода работы двух джунов) а за 2000$ при рейте в 25$. Типичная дилемма продажи сырья vs готового продукта.
- контроль над временем делегируется работодателю. Ты уже не можешь просто так делать то, что тебе нужно или интересно, работодатель будет считать, что он купил тебя с потрохами, твоё время принадлежит ему и будет указывать тебе, что делать, попутно занимаясь микроменеджментом и требуя отчетов. Это самый большой минус. Вот ты был свободным человеком, который делал что хотел, а спустя секунду уже стал наймитом, время и свобода которого подчистую выкуплены.
Это самый большой минус, как по мне. В случае парттайм работы дело усложняется тем что приходится объяснять — что было сделано и в какие часы, фиксировать это все, а в терминальных случаях ставить себе на компьютер шпионский софт который будет посылать дяде с деньгами на почту скриншоты твоего рабочего стола и фотографии с вебкамеры.
- отсутствие мотивации развиваться. Зачем работать лучше других если и так заплатят? Я неоднократно такое наблюдал и такие люди приходили ко мне на собесы. Требуют космических денег, а сами ничего не знают. Нет, со своей стороны они конечно правы, потому что хотят ничего не делать а чтобы все было, но все равно я запишу это в минус. Нет никакого смысла работать быстрее и лучше, потому что заплатят так же как и раньше, а сверху еще и задач нагрузят. Известный сюжет в фильмах и книгах — это новичок, который резко выделяется на фоне остальных. Новичок думает что он все делает правильно, хотя коллектив его дружно ненавидит, за то что тот подымает стандарты качества и скорости работы.
Менеджмент в силу своих возможностей пытается вешать морковку перед осликом и как-то заниматься нематериальной мотивацией, но работает это только на начинающих, а опытный разработчик легко будет сидеть на расслабоне и ничего не делать.
Думаю что если в один день начать платить работникам за конкретные закрытые задачи, то внезапно может оказаться что 10x инженеры, о которых говорят что их нет, на самом деле существуют и делают в 10 раз больше работы на те же деньги, что получают их менее мотивированные коллеги.
- очевидная невозможность прыгнуть выше рейта. Если зарабатываешь 25$ в час — все, твой максимум в месяц это 4000$, как бы ты не старался (часов больше взять неоткуда будет если не овертаймить). Автоматически устанавливается стеклянный потолок пробить который будет нереально, потому что бизнес не будет нанимать простого консультанта за 300$ в час (будет нанимать топового, но у них отдельное ценообразование).
- невозможность продавать результат своего труда. Ты продаешь свою жопу на стуле а не то, что ты сделал. Норм тип может сделать проект, который два джуна будут колбасить полгода, за две недели. Вот только продавать он будет его не за 12 000$ (сумма полугода работы двух джунов) а за 2000$ при рейте в 25$. Типичная дилемма продажи сырья vs готового продукта.
- контроль над временем делегируется работодателю. Ты уже не можешь просто так делать то, что тебе нужно или интересно, работодатель будет считать, что он купил тебя с потрохами, твоё время принадлежит ему и будет указывать тебе, что делать, попутно занимаясь микроменеджментом и требуя отчетов. Это самый большой минус. Вот ты был свободным человеком, который делал что хотел, а спустя секунду уже стал наймитом, время и свобода которого подчистую выкуплены.
Это самый большой минус, как по мне. В случае парттайм работы дело усложняется тем что приходится объяснять — что было сделано и в какие часы, фиксировать это все, а в терминальных случаях ставить себе на компьютер шпионский софт который будет посылать дяде с деньгами на почту скриншоты твоего рабочего стола и фотографии с вебкамеры.
- отсутствие мотивации развиваться. Зачем работать лучше других если и так заплатят? Я неоднократно такое наблюдал и такие люди приходили ко мне на собесы. Требуют космических денег, а сами ничего не знают. Нет, со своей стороны они конечно правы, потому что хотят ничего не делать а чтобы все было, но все равно я запишу это в минус. Нет никакого смысла работать быстрее и лучше, потому что заплатят так же как и раньше, а сверху еще и задач нагрузят. Известный сюжет в фильмах и книгах — это новичок, который резко выделяется на фоне остальных. Новичок думает что он все делает правильно, хотя коллектив его дружно ненавидит, за то что тот подымает стандарты качества и скорости работы.
Менеджмент в силу своих возможностей пытается вешать морковку перед осликом и как-то заниматься нематериальной мотивацией, но работает это только на начинающих, а опытный разработчик легко будет сидеть на расслабоне и ничего не делать.
Думаю что если в один день начать платить работникам за конкретные закрытые задачи, то внезапно может оказаться что 10x инженеры, о которых говорят что их нет, на самом деле существуют и делают в 10 раз больше работы на те же деньги, что получают их менее мотивированные коллеги.
Продажа жопочасов. Чем это плохо для работодателя?
- невозможность заплатить конкретные деньги за конкретный продукт. Команды и люди имеют тенденцию растягивать проекты, продалбывать дедлайны, переделывать одно и то же по десять раз и так далее, вы понели. Заказчик платит и платит и платит и платит, а его продолжают кормить завтраками и ничего не выдают. Анекдотичные истории про закопанные миллиарды можно почитать вот тут: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
Просто жесть—сколько бабок могут закопать на разработке не рокет саенс проектов.
- отсутствие возможности контроля за мотивацией работников. Совершенно невозможно определить награду за достижение определенных целей. Ты же не будешь платить 100$ за фикс срочного бага, разработчик и так получает свои 100$ в день, вот пусть на них как-то и работает. Когда нужно делать что-то срочное и критичное то в ход идут всякие манипуляции и запугивания ("давайте поднажмем" или "ты же обещал сделать, где?"), которые не всегда работают. Гораздо честнее и лучше было бы сказать "вот есть функциональность надо сделать её через две недели, сделаешь — вот тебе деньги, не сделаешь — ничего не получишь".
- непрозрачность потраченного времени. Делай скриншоты или не делай, сади разработчиков мониторами к себе или не сади, блокируй ютуб или не блокируй — все это слабо помогает и мало коррелирует с реальной продуктивностью. Человек существо хитрое, и не мне вам рассказывать как легко можно обмануть все эти системы слежения и контроля за проведенным временем. А если я работодатель то никак и не прикопаюсь — вот на скриншоте IDE, какие проблемы? Гони бабло за отработанные часы!
- невозможность заплатить конкретные деньги за конкретный продукт. Команды и люди имеют тенденцию растягивать проекты, продалбывать дедлайны, переделывать одно и то же по десять раз и так далее, вы понели. Заказчик платит и платит и платит и платит, а его продолжают кормить завтраками и ничего не выдают. Анекдотичные истории про закопанные миллиарды можно почитать вот тут: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
Просто жесть—сколько бабок могут закопать на разработке не рокет саенс проектов.
- отсутствие возможности контроля за мотивацией работников. Совершенно невозможно определить награду за достижение определенных целей. Ты же не будешь платить 100$ за фикс срочного бага, разработчик и так получает свои 100$ в день, вот пусть на них как-то и работает. Когда нужно делать что-то срочное и критичное то в ход идут всякие манипуляции и запугивания ("давайте поднажмем" или "ты же обещал сделать, где?"), которые не всегда работают. Гораздо честнее и лучше было бы сказать "вот есть функциональность надо сделать её через две недели, сделаешь — вот тебе деньги, не сделаешь — ничего не получишь".
- непрозрачность потраченного времени. Делай скриншоты или не делай, сади разработчиков мониторами к себе или не сади, блокируй ютуб или не блокируй — все это слабо помогает и мало коррелирует с реальной продуктивностью. Человек существо хитрое, и не мне вам рассказывать как легко можно обмануть все эти системы слежения и контроля за проведенным временем. А если я работодатель то никак и не прикопаюсь — вот на скриншоте IDE, какие проблемы? Гони бабло за отработанные часы!
Продажа жопочасов. Итоги
Плохо для обеих:
- невозможность построить честную и прозрачную схему финансовой мотивации. Мы все так или иначе работаем за деньги и ради денег (а кто нет — тот просто не знает об этом. Попробуйте поработать на "интересных проектах" за зп ниже рыночной). Бабло — наша главная мотивация (по крайней мере, большинства, которое застряло на нижнем уровне пирамиды потребностей). И вот, вместо того, чтобы мотивировать нас деньгами, нам просто предлагают их за то, что мы сидим за клавиатурой и нажимаем на кнопочки с частотой не меньше 10 ударов в минуту. Бизнес не может грамотно оплатить качественную работу, а сотрудники вынуждены играть по правилам уравниловки и не могут прыгнуть выше других, даже если хотят. Как известно, лучше всех в колхозе работала лошадь, но председателем так и не стала.
Нормального решения этой проблемы, я, увы не вижу. Да, Егор Бугаенко делает Zerocracy которая предлагает свои методы, но весь мир думает в парадигме почасовой оплаты, которая является меньшим злом для обеих сторон и пока что подвижек в сторону изменения этого статус-кво нет.
С одним из заказчиков я уже довольно долго (около трёх лет) работаю по fixed-price схеме. Никаких вопросов с репортингом времени или еще чем-то. Вот скоуп — вот деньги. Понятное дело что тут много своих минусов, вроде ситуаций, когда плохо оценил проект, недописал требования, много правок, но мне как-то удается разруливать. Иногда мы оцениваем проект предварительно, иногда, если задач много, то постфактум. Вообще такая схема мне очень нравится но работает она хорошо только для изолированных или целостных проектов которые делаешь от начала до конца сам или со своими людьми. Как только начинается взаимодействие с другими командами, ситуация может усложниться.
С другими заказчиками я пришёл к почасовой схеме, потому что понял, что объем бюрократии, коммуникации и большого количества мелких работ будет неудобен и для меня, и для них, поэтому согласился на почасовую оплату (и уже в полной мере ощущаю на себе недостатки этого, впрочем, как и достоинства).
Вариацией посредине (которую использует Zerocracy и другие компании, например wemake.services) является оценка задачи во времени (например 1 час) и последующая оплата по рейту, независимо от того, сколько времени на самом деле было потрачено на работу. Отличием от фиксед прайса здесь является зависимость от рейта (то есть разные разработчики за одну и ту же задачу получат разные суммы, впрочем и время они тоже потратят разное) и то, что оценку времени задачи определяет заказчик.
Почитать о подходах более подробно:
https://wemake.services/meta/rsdp
http://www.zerocracy.com/policy.html
Плохо для обеих:
- невозможность построить честную и прозрачную схему финансовой мотивации. Мы все так или иначе работаем за деньги и ради денег (а кто нет — тот просто не знает об этом. Попробуйте поработать на "интересных проектах" за зп ниже рыночной). Бабло — наша главная мотивация (по крайней мере, большинства, которое застряло на нижнем уровне пирамиды потребностей). И вот, вместо того, чтобы мотивировать нас деньгами, нам просто предлагают их за то, что мы сидим за клавиатурой и нажимаем на кнопочки с частотой не меньше 10 ударов в минуту. Бизнес не может грамотно оплатить качественную работу, а сотрудники вынуждены играть по правилам уравниловки и не могут прыгнуть выше других, даже если хотят. Как известно, лучше всех в колхозе работала лошадь, но председателем так и не стала.
Нормального решения этой проблемы, я, увы не вижу. Да, Егор Бугаенко делает Zerocracy которая предлагает свои методы, но весь мир думает в парадигме почасовой оплаты, которая является меньшим злом для обеих сторон и пока что подвижек в сторону изменения этого статус-кво нет.
С одним из заказчиков я уже довольно долго (около трёх лет) работаю по fixed-price схеме. Никаких вопросов с репортингом времени или еще чем-то. Вот скоуп — вот деньги. Понятное дело что тут много своих минусов, вроде ситуаций, когда плохо оценил проект, недописал требования, много правок, но мне как-то удается разруливать. Иногда мы оцениваем проект предварительно, иногда, если задач много, то постфактум. Вообще такая схема мне очень нравится но работает она хорошо только для изолированных или целостных проектов которые делаешь от начала до конца сам или со своими людьми. Как только начинается взаимодействие с другими командами, ситуация может усложниться.
С другими заказчиками я пришёл к почасовой схеме, потому что понял, что объем бюрократии, коммуникации и большого количества мелких работ будет неудобен и для меня, и для них, поэтому согласился на почасовую оплату (и уже в полной мере ощущаю на себе недостатки этого, впрочем, как и достоинства).
Вариацией посредине (которую использует Zerocracy и другие компании, например wemake.services) является оценка задачи во времени (например 1 час) и последующая оплата по рейту, независимо от того, сколько времени на самом деле было потрачено на работу. Отличием от фиксед прайса здесь является зависимость от рейта (то есть разные разработчики за одну и ту же задачу получат разные суммы, впрочем и время они тоже потратят разное) и то, что оценку времени задачи определяет заказчик.
Почитать о подходах более подробно:
https://wemake.services/meta/rsdp
http://www.zerocracy.com/policy.html
Обсуждение багов в синхронных чатах
Вчера со мной произошла забавная ситуация. На одном из проектов меня попросили добавить REST API метод. Ничтоже сумнящеся я нафигачил его, отдал фронтенд разработчикам сигнатуру и пошел заниматься своими делами.
Через некоторое время мне пишет в личку разработчик, который пилит свою функциональность на базе моего API, говорит "не работает" и прикладывает скриншот из постмана где написано 404. Я быстро смотрю и вижу что там неверный хост, указываю на это. Разработчик исправляет и опять показывает 404. Я смотрю что там уже неверно прописан путь к ресурсу и говорю уже об этом. Он опять присылает скриншот постмана где опять 404, но уже на метод OPTIONS. Я этого не замечаю, даю ему полный урл еще раз и говорю "пробуй", он тут уже мне говорит что дело в CORS, но так как я сфокусировался на 404, то почему-то продолжал думать что дело в неверном урле или неверном хосте и слал собеседнику курлы и скриншоты своего постмана где все работает.
Так мы тупили полчаса пока я не сообразил что в чем дело и не обратил внимание на то, что именно мне пытались донести.
Такие ситуации встречались и постоянно встречаются я думаю у каждого. Гораздо проще пойти к нужному тебе человеку в личку и сказать "вот, не работает" и приложить скриншот с ошибкой. Так все привыкли работать. Мне такой подход не нравится—во-первых, синхронное общение (даже если прямо сейчас нет времени) предполагает быстроту ответов и не дает включаться Системе 2 по Канеману, и детально вникнуть в проблему, во-вторых знание, полученное в результате общения остается в чате и недоступно для остальных. Если завтра ко мне придет другой разработчик с похожей проблемой, то нам придется повторять всю итерацию.
Какое может быть решение? Конечно же, заводить тикеты!
- создание тикета предполагает какой-то предварительный труд, потому что нужно нормально описать проблему и шаги воспроизведения. У меня часто оказывается так, что во время подготовки я более тщательно смотрю на все и исправляю ошибку без тикета. Просто включил больше внимательности и всё.
- для исполнителя будет гораздо более полезно когда ему дадут контекст и конкретные шаги, а не просто скинут скриншот "не работает", и он не будет делать работу по расшифровке сообщений а будет работать уже с подготовленными данными
- история сообщений останется доступной для поиска. Готов поспорить, у вас были ситуации, когда решение вы находили в закрытом тикете на гитхабе? Кто-то написал проблему, другой написал +1, третий предложил воркэраунд, четвертый подтвердил что он работает, пятый поблагодарил третьего и эта информация остается актуальной годами. А теперь представьте что человек бы вместо тикета писал бы в личку автору? Глупо? Безусловно! Но это то, чем мы занимаемся каждый день.
Все команды, в которых я работал, были завязаны на синхронный метод работы и adhoc решение проблем. Даже там, где я пробовал внедрить культуру асинхронного общения через тикеты, это не получалось совершенно. Люди сопротивляются, не хотят думать, не хотят включать Систему 2, вместо этого предпочитая кидать стектрейсы и ошибки в чаты.
И это печально.
Вчера со мной произошла забавная ситуация. На одном из проектов меня попросили добавить REST API метод. Ничтоже сумнящеся я нафигачил его, отдал фронтенд разработчикам сигнатуру и пошел заниматься своими делами.
Через некоторое время мне пишет в личку разработчик, который пилит свою функциональность на базе моего API, говорит "не работает" и прикладывает скриншот из постмана где написано 404. Я быстро смотрю и вижу что там неверный хост, указываю на это. Разработчик исправляет и опять показывает 404. Я смотрю что там уже неверно прописан путь к ресурсу и говорю уже об этом. Он опять присылает скриншот постмана где опять 404, но уже на метод OPTIONS. Я этого не замечаю, даю ему полный урл еще раз и говорю "пробуй", он тут уже мне говорит что дело в CORS, но так как я сфокусировался на 404, то почему-то продолжал думать что дело в неверном урле или неверном хосте и слал собеседнику курлы и скриншоты своего постмана где все работает.
Так мы тупили полчаса пока я не сообразил что в чем дело и не обратил внимание на то, что именно мне пытались донести.
Такие ситуации встречались и постоянно встречаются я думаю у каждого. Гораздо проще пойти к нужному тебе человеку в личку и сказать "вот, не работает" и приложить скриншот с ошибкой. Так все привыкли работать. Мне такой подход не нравится—во-первых, синхронное общение (даже если прямо сейчас нет времени) предполагает быстроту ответов и не дает включаться Системе 2 по Канеману, и детально вникнуть в проблему, во-вторых знание, полученное в результате общения остается в чате и недоступно для остальных. Если завтра ко мне придет другой разработчик с похожей проблемой, то нам придется повторять всю итерацию.
Какое может быть решение? Конечно же, заводить тикеты!
- создание тикета предполагает какой-то предварительный труд, потому что нужно нормально описать проблему и шаги воспроизведения. У меня часто оказывается так, что во время подготовки я более тщательно смотрю на все и исправляю ошибку без тикета. Просто включил больше внимательности и всё.
- для исполнителя будет гораздо более полезно когда ему дадут контекст и конкретные шаги, а не просто скинут скриншот "не работает", и он не будет делать работу по расшифровке сообщений а будет работать уже с подготовленными данными
- история сообщений останется доступной для поиска. Готов поспорить, у вас были ситуации, когда решение вы находили в закрытом тикете на гитхабе? Кто-то написал проблему, другой написал +1, третий предложил воркэраунд, четвертый подтвердил что он работает, пятый поблагодарил третьего и эта информация остается актуальной годами. А теперь представьте что человек бы вместо тикета писал бы в личку автору? Глупо? Безусловно! Но это то, чем мы занимаемся каждый день.
Все команды, в которых я работал, были завязаны на синхронный метод работы и adhoc решение проблем. Даже там, где я пробовал внедрить культуру асинхронного общения через тикеты, это не получалось совершенно. Люди сопротивляются, не хотят думать, не хотят включать Систему 2, вместо этого предпочитая кидать стектрейсы и ошибки в чаты.
И это печально.
👍1
18-19 ноября иду на конференцию BuildStuff, которая будет проходить в Киеве
https://www.ukraine.buildstuff.events/
Интересно что большинство спикеров—англоязычные. Если я верно помню, то раньше эта конфа была MS-ориентированной, azure, .net, typescript etc. Похоже что сейчас они сместили фокус в сторону более широкого спектра технологий.
Я не фанат технческих докладов, и хорошо что их как раз будет не так много. Вот пара тем которые мне интересны:
Culture, Code and Karaoke: Analogue Leadership for Digital Teams (скорее всего как устраивать "нематериальную мотивацию" вместо построения четких правил)
Full Stack Development (внезапно! в 2019-то!)
Futurology for Developers от типа который работает уже 30 лет и видел все.
Если вам интересно то держите промокод на -10%:
https://www.ukraine.buildstuff.events/
Интересно что большинство спикеров—англоязычные. Если я верно помню, то раньше эта конфа была MS-ориентированной, azure, .net, typescript etc. Похоже что сейчас они сместили фокус в сторону более широкого спектра технологий.
Я не фанат технческих докладов, и хорошо что их как раз будет не так много. Вот пара тем которые мне интересны:
Culture, Code and Karaoke: Analogue Leadership for Digital Teams (скорее всего как устраивать "нематериальную мотивацию" вместо построения четких правил)
Full Stack Development (внезапно! в 2019-то!)
Futurology for Developers от типа который работает уже 30 лет и видел все.
Если вам интересно то держите промокод на -10%:
JOINTHETRIBE
Если вам прямо очень интересно и у вас есть фб, то приходите ко мне в личку, там в какой-то из групп есть -20% за шеринг поста или что-то вроде этого, я дам ссылку.