Выступила на Pyladies 13.02 с рекламой Ruby #моё

И DEV 😎

Как искать удалёнку?

Сразу скажу, что я ищу работу очень редко, "для тонуса" собеседования тоже не прохожу. На это нужно много сил и времени, а выгода не кажется достаточной, чтобы их тратить, по крайней мере на данный момент.

Ещё я устраивалась на все работы "по объявлению". "По знакомству" как-то не попадалось привлекательных предложений: поначалу их вообще не было, а потом требования к работе взлетели до небес :D

Если говорить о поиске вакансий и изучении рынка труда, я больше люблю хоть сколько-то специализированные ресурсы (по тех. стеку, удалёнке или хотя бы просто айтишные), поэтому на хедхантер в поисках работы не хожу. Могу зайти из любопытства, посмотреть, что там за полторы вакансии в Вологде :D

Вот что я использовала для поиска и для анализа рынка:
- хабр карьера (бывший мойкруг)
- каналы в телеграме:
- @Remoteit
- @remotelist (собирает вакансии с разных сайтов, может попадаться не удалёнка или удалёнка только в US и тд. Самих вакансий очень много, надо копаться)
- @rubyjob (подставьте канал с вакансиями по своему тех.стеку)
- https://angel.co/ (работа в стартапах, есть и удалёнка, и офис, в т.ч. с релокацией. Поиск не очень удобный - при выборе удалёнки может всё равно выдавать варианты с офисом)
- stackoverflow jobs (https://stackoverflow.com/jobs)
- всякие weworkremotely (https://weworkremotely.com/)
Ещё помогает подписываться в соцсетях на интересующие компании, к-е нанимают по интересующей специализации, и вообще заглянуть на их сайты.
Во-первых можно сразу увидеть вакансии, а можно и просто найти контакты и написать им, если сильно туда хочется.

Вакансии будут повторяться на многих сайтах, но всё равно есть смысл смотреть несколько источников.

В прошлый раз я искала работу в конце 2018. С этого момента прошло уже много времени, но мне кажется, что это было совсем недавно, ведь до этого в Эврон я работала 8 лет. Я смотрела вакансии в источниках из списка выше в течение нескольких месяцев, но апплаилась не так много: на пару вакансий с angel.co, stackoverflow jobs, напрямую в компании.

Также и в DEV я увидела объявление у них в твиттере (или ещё где-то) и просто заапплаилась. Процесс тогда был довольно быстрым, даже без собеседования: просто анкета, обсуждение в почте, мини-тестовое в виде анализа проекта. Надо понимать, что контракторская позиция несёт мало рисков для работодателя и легко было организовать тестовый период, да и вообще легко "выселить" с работы в случае чего. Тем не менее, когда нанимали новых сотрудников в этот раз (конец 19-го, начало 20-го) процесс был куда более долгим и структурированным, как для контракторов, так и для сотрудников в США.

#поиск_работы@anna_codes

Мы снова делаем RailsGirls! (3 и 4 апреля в спб)
https://vk.com/railsgirls_spb
Делитесь с подругами, которые ещё не программируют, но хотят начать 👩🏻‍💻✨

Открыта подача заявок на RailsGirls Summer of Code.
Правила - https://railsgirlssummerofcode.org/students/application/

Стажировка пройдёт с июля по сентябрь 2020, можно участовать фулл-тайм или парт-тайм (40 или 20 часов)

В этот раз нужно:
- иметь год опыта обучения программированию
- найти партнёршу по проекту в своём городе, чтобы была возможность каждый день встречаться
- найти тренерку (тоже упирают на оффлайн, но тут разрешают и удалённо)
- найти "офис", где можно работать вместе

Стажировка оплачиваемая, стипендия зависит от кол-ва "отработанных" часов. Я предполагаю, что и от места проживания тоже (рассчитают по прожиточному минимуму :D)
Проекты разные, теперь там далеко не только Ruby/Rails (https://teams.railsgirlssummerofcode.org/projects)

Конечно, это право оргов устанавливать ограничения, но, на мой взгляд, их многовато: нужна локальная команда, а это скорее осуществимо в больших городах, где и так больше возможностей для стажировки.
И "сидеть в офисе" - тоже не для всех реально, хотя, я думаю, сильно проверять никто не будет.

Прочитала "Shape Up" и одновременно попробовали первый цикл по похожей схеме на работе.
Книга описывает процесс работы в Basecamp. Работа ведётся 6-недельными циклами активной разработки с 2-хнедельными cooldown-ами между ними.

Сначала senior team (например, фаундеры) определяет области работы. Они пишут питчи, обсуждают их и выбирают, над чем именно команда разработки (builders) будет работать в следующем цикле. Эта работа по "шейпингу" ведётся параллельными циклами с командой разработки (https://bit.ly/2TkHTrE)

В начале цикла команды (у бейзкемпа это дизайнер + ~2 разработчика) получают питч, т.е. описание задачи.

Питч включает в себя:
- описание проблемы
- что примерно можно сделать за 6 недель
- наброски интерфейсов
- возможные детали, в которых можно надолго увязнуть (rabbit holes)
- и то, что точно делать не нужно.
Далее команда самоорганизуется, определяет задачи и выполняет их. Как именно, тоже описывается в книге. За 6 недель нужно выполнить работу и зарелизиться. По умолчанию цикл не продлевается. Cool-down используется для задач, до которых обычно не доходят руки: можно починить баги, исследовать новые технические возможности и тд + нужно определиться, что делать в следующем цикле.

Мне понравилось, что поднимаются проблемы:
- вымышленные vs "открытые" (discovered) задачи
В самом начале трудно определить, что именно нужно делать, и тем более сколько это займёт времени. Понятнее становится только когда начинаешь работать над задачей.
- число задач со временем только растёт, даже внутри нашей фичи/области работы, ограниченной питчем
Тут помогают чёткие дедлайны. Мы определяем, что успеем сделать до дедлайна, а не за какое время успеем "доделать" фичу, ведь доделывать можно бесконечно. Таким образом, имея дедлайн, мы делаем самое важное и релизим в состоянии "good enough". И речь тут идёт не о качестве продукта (типа релизим без тестов), а про урезанную функциональность. Как правило, важно далеко не всё, что изначально хотелось.

Также понравилось то, что авторы рассказывают, как адаптировать процесс для проектов разного размера, даже для стартапов на пару человек. Хотя и есть реклама Basecamp (иначе, ради чего бесплатно раздавать книгу? :), вполне можно пользоваться идеями и без него.

Мои заметки по книге - https://github.com/lightalloy/books-notes/blob/master/development/shape_up.md

Чуть позже расскажу, как у нас прошёл первый рабочий цикл.

#книги

Как мы начали использовать подход Shape Up в команде:
(определения питчей, шейпинга и т.д. в предыдущем посте)

Первый цикл, конечно, прошёл немного хаотично: в него попали встреча команды в Нью-Йорке и мои 2 отпуска по неделе (не в Нью-Йорке, к сожалению :D). Многие члены команды только начали работать и онбордились, что тоже добавило сложностей.

Ни о каком 6-недельном "шейпинге" тоже не могло быть и речи. На первый цикл быстренько расписали задачи и поехали. Конечно, это не прошло без последствий.
Для второго цикла питчи пишем сами во время cooldown, тоже довольно быстро. Выбирать и дорабатывать будут фаундеры, советуясь с дизайнерами и разработчиками.

Что понравилось:
- чёткая область работы, на которую можно спокойно выделить время. До этого иногда было трудно определить, за какие именно задачи стоит браться, и как не распыляться между ними.
- чёткий дедлайн. Помогает определить, что будет "достаточно хорошо" и задеплоить фичу в срок, не растягивая работу бесконечно. Это касается не столько качества кода (не "фигачим код без тестов"), сколько необходимости урезать функциональность до необходимого минимума. Таким образом, делаем то, что действительно нужно, и не тратим время на сомнительные улучшения. Принцип "limited time, variable scope" здесь очень хорошо сработал. Кроме того, определять, что именно нужно, довольно интересно (особенно если члены команды всё-таки доступны для обсуждения)

Что не понравилось:
- было мало времени на работу из-за завершения прошлых задач в начале цикла, отпусков, онбординга новых людей, встречи команды и т.д.
- трудно получить код-ревью, и самой найти время на ревью, особенно под конец цикла. Дедлайн давит, а ведь часто нужно ещё вникнуть в чужую задачу, которая с нашими никак не связана.
- изначально были поставлены очень размытые требования. Приходилось многое выяснять у фаундеров, а это не всегда просто из-за их занятости.
- у нашей команды было 2 проекта, и над вторым мы работали по остаточному принципу. Спасло то, что менее приоритетный показался мне очень интересным, и я быстренько сделала основное за последнюю неделю.

Помимо этого, работа некоторых команд, например, oss (работа с контрибьютерами и не только) и SRE (Software Reliability) не вписывается в циклы и больше похожа на непрерывный процесс.
Конечно, процесс ещё не устаканился, очень многое обсуждаем и будем адаптировать под себя. Например, сейчас выделили на неделю больше на cooldown и, соответственно, шейпинг. Интересно посмотреть, как пойдёт дальше 👩🏻‍💻

#devto #работа

Присмотрела для себя новую книгу "Fundamentals of Software Architecture" =>
https://www.thoughtworks.com/books/fundamentals-of-software-architecture

Можно послушать подкаст и прочитать бесплатную главу, что я и сделала. Пока непонятно, насколько актуальна для меня сейчас, но это не так важно, т.к. темы интересные сами по себе + подобные знания обычно всё-таки получается использовать в том или ином виде (например, для размышлений о карьере :D)
Останавливает неудобный формат: либо бумага, либо киндл. Я бы предпочла пдф-ку, чтобы читать на компьютере: если покупать книгу за 40+$, хочется, чтобы было удобно 🤷🏻‍♀️

#книги

https://vk.cc/arrN68
Отмена RailsGirls и список материалов для новичков.

https://github.com/mobile/
Вышло мобильное приложение для гитхаба ✨ (finally)

Пост про сон и режим дня 😴
https://dev.to/lightalloy/improve-your-sleep-as-a-developer-21a9

Долго писала его, почему-то шёл очень трудно: лежал в черновиках на русском пару лет, несколько раз возвращалась к нему 🤷🏻‍♀️.
В итоге воспользовалась cool-down'ом и переписала его полностью, уже на английском.

Курс "Just Javanoscript" от Дена Абрамова с иллюстрациями Мегги Эпплтон => https://justjavanoscript.com/
Это бесплатный черновой вариант в виде email-рассылки.

Ден подробно объясняет, как работает js, и даёт упражнения для каждой главы. Если будете их выполнять, то материал точно усвоится. Курс подойдёт для относительно лёгкого обучения (меня только на такое сейчас и хватает).
Сначала серии будут приходить ежедневно, а потом по мере готовности, всего их пока 8. Новые выходят не очень регулярно, раз в несколько недель.

Только начала разбирать рассылки за июнь и прочитала, что проект RailsGirls Summer of Code закрывается:
https://railsgirlssummerofcode.org/blog/2020-06-15-foundation-update
В последние годы было что-то непонятное с организацией: в прошлом году они писали о том, что команда занята ребрендингом. Тогда стажировка проводилась, но без стипендий и без особого руководства со стороны оргов. В этом году всё должно было быть, как обычно, но карантин добил проект.

Теперь не придётся думать, поменторить ли на Rgsoc или делать что-то своё :D (когда появятся время и силы на подобные проекты)

Работа над just js приостановлена, по крайней мере в изначальном формате. Материалы должны появиться на сайте, т.к. многие жаловались, что проходить из почты неудобно.
Хотя на мой взгляд, рассылка имеет и свои преимущества: есть повод сразу прочитать и сделать упражнения.

Что-то не получается писать посты 🤷🏻‍♀️

Как будто работаю 👀

Just js всё-таки вышел. Есть региональная скидка для России.

Бесплатный митап для тех, кто проходит курс: https://lu.ma/t1nec6qu

Привет.
Захотелось записать видео (life update), но в целом планирую использовать текстовый формат.
Для тех, кто не хочет смотреть, будет текст ниже.