2008 рік — $200, але через ~пів року дали більше проектів та подвоїли ЗП
Плаваю там ледве не щодня з середини вересня і поки на них не натикався 🤷♂️
Іноді Blue Bottles закине хвилями, але якщо це поодинокий випадок, то їх просто викидаю з басейну і плаваю далі :)
Це в якому океані можна плавати і як далеко?
Google Maps підказує мені що це South Pacific Ocean.
Якщо конкретно, то плаваю на Maroubra Beach або в Mahon Pool що поряд з Maroubra Beach (це в Сіднеї, Австралія)
Стосовно дальності плавання в океані не скажу точно, бо саме на цьому пляжі хвилі бувають високі і плавати не зручно. Це більше схоже на виживання в хвилях. Тому останнім часом плаваю в рокпулі, Mahon Pool. Плаваю більше не на відстань, а щоб по часу було ~10хв у воді. Це десь ~10-12 басейнів по 30 метрів.
В моєму instagram є сторіс майже кожного дня зі світанку, і кілька разів постив фото світанків у Threads — @vasyl.zubach
Я прокидаюсь о 5й ранку і розпочинаю робочий день о ~5:25. В
Дуже сподобалась стаття!
Не часто зустрічається компанія з таким рівнем інженерної культури і думаю тут дуже велику роль зіграв саме твій, Романе, досвід в Google. Там для ефективної роботи величезної кількості розробників необхідна досить сильна інженерна культура, але кількість розробників та міжпродуктова/міжкомандна робота нажаль вимагає ускладнення цих процесів з часом.
Кілька коментарів/питань:
Також впровадьте on-call ротацію з найдосвідченіших інженерів.
На мою думку така ротація повинна в себе включати всіх інженерів окрім тих для кого це може негативно впливати на повсякденне життя (наприклад молоді батьки, сон яких і так не стабільний, їм цей on-call пейдж ну взагалі не потрібен посеред ночі коли може дитину розбудити).
Якщо Junior інженер не може виявити якій FeatureFlag вимкнути, чи який попередній реліз відновити щоб виправити помилку — значить це сигнал що треба щось виправити в процесі і зробити його простішим. У нескладних продуктів з постійними релізами в цьому можуть допомогти Sentry наприклад (для аналізу кількості помилок в певній версії релізу), ну і якийсь дашоборд який дає розуміння які FeatureFlags були змінені.
Автотестів треба писати стільки, поки не перестане бути страшно релізитись в production
👍
чи є у вас автотести які раняться не на PullRequests, a просто на production для моніторингу та сповіщення чи всі сервіси працюють як годиться? (щоб знаходити помилки раніше ніж кінцеві користувачі)
self-nominated performance review
Подобається такий підхід! Чи очікуєте ви щоб співробітник сам ініціював розмову про perofrmance review, чи Engineering Manager ініціюють її дивлячись на результати розробника?
Один із факторів, на який ми зважаємо при оцінці успішності — це результати наших щоквартальних OKR
Чи робите ви щомісячну оцінку OKR щоб зрозуміти чи все йде згодно планом?
це окей спробувати багато різних речей/ технологій поки у вас1-3 роки досвіду. Але через три роки потрібно перейти до етапу, де ви розумієте, навіщо пишете цей код і який результат для бізнесу він приносить.
А як порадите інженеру з 3+ досвідом не чіплятись за технології минулого а перевіряти чи нова технологія вирішить проблему краще чи ні?
На мою думку тут знову ж таки грає роль свобода прийняття рішень у вашій культурі. Інженер з 3+ досвідом може виділити трохи часу щоб спробувати кілька підходів з різними технологіями, для підбору оптимального варіанту за певними метриками. Головне не використовувати технологію тому що «всі так роблять», або «я просто це вже юзав і знаю як», а щоб ця технологія була оптимальною для вирішення проблеми. А щоб зрозуміти чи вона оптимальна треба або спробувати і поділитись довсідом з іншими (щоб не витрачали час на свої ідентичні спроби), або ж почитати десь чи хтось з ваших інженерів вже спробував вирішити ідентичну вашій проблему.
Дякую за статтю! :)
Там також пообіцяли, що перерахують усі пожертви співробітників відповідним організаціям через Atlassian Foundation, щоб допомогти українцям, які тікають із зони бойових дій, на місцях.
Не ховсім коректна трансляція того що описано в публічній заяві в секції Our Foundation appeal:
We will be matching all employee donations to eligible organisations via our Atlassian Foundation, to assist with on-the-ground support for Ukrainians fleeing the war zone.
Компанія буде подвоювати всі пожертви співробітників.
Там далее по тексту после упоминания «Caregiver» есть абзац с пояснением нововведений:
політика Atlassian щодо декретних відпусток змінилася. Тепер у нас birthing parent, тобто жінка, яка народжує дитину, отримує 26 тижнів повністю оплачуваної відпустки. Тим часом non-birthing parent — батько — отримує 20 тижнів відпустки.
Дітей ще можна всиновити/вдочерити і тоді мама не є birthing parent, і в такому випадку їй буде доступно 20 тижнів, як і батьку.
Дякую ;)
Из того что заметил: у государства есть для этого необходимые горячие линии для звонков и это достаточно хорошо доносится до населения в случае необходимости. Ощущается что психическому здоровью уделяется достаточно внимания, на уровне с физическим.
Что касается Atlassian (в статье я упомянул момент собственного выгорания), то компания спонсирует 10 консультаций со специалистами в случае необходимости. Я этим не пользовался так как сам понимал, что конкретно повлияло на мое выгорание и знал как с этим справиться.
Наша приватна страховка покриває AU$350 в рік того що відноситься до стоматології.
Ця цифра залежить від пакету страховки, що надає страхова компанія.
Державна страховка Medicare, на скільки мені відомо, не покриває такі питання.
Знайшов для вас публічний тікет jira.atlassian.com/...-tabpanel#comment-2955787 з коментарем від Raul Gomis — скоро буде SourceTree під Mac M1 в беті
Дуже дякую DOU та Марії за можливіть поділитись своєю історією та досвідом!
Сподіваюсь інсайти будуть корисними і мотивуючими.
Якщо комусь будуть цікаві додаткові деталі, які не розкриті в статті, я залюбки дам відповіді на ваші запитання.
1. Ну да выплаты от государства маленькие, и это правильно. А тем кто неплохо и так зарабатыва(ет/л) — у них вроде и так должно быть все схвачено.
2. не видел никаких «нюансов на практике» среди тех знакомых из неIT и которые троили карьеру. Конечного у каждого своя история, но как по мне, карьера может потерпеть трудности лишь когда слишком публично накосячил, иначе это не карьера.
3. не согласен
Опять таки, повторюсь: спланировать декретный отпуск можно, для этого есть условия и государство это кое-как а таки поддерживает (надо же и свои усилия приложить, а не во всем на государство надеяться). Основное что для этого надо это желание самих родителей.
Реальный бариста смог, уверен и другие смогут если решатся подойти к вопросу правильно.
Разговор сейчас не про возможность разгуляться, а возможность уделить время семье вместо работы. Финансовые рекомендации и планы это тоже отдельная тема. Закон известен, дает возможность спланировать и с правильной стратегией накопить денег на то чтоб уделить время семье (не особо разгуливаясь). Бариста смог.
Во всем штате по закону можно родителям взять до 1 года отпуска без оплаты и получить Parental Leave Pay от государства. Конечно же есть условия определенные от государства и от компании в дополнение, но к примеру я лично знаю парня баристу который уже второй раз берет такой год отпуска с появлением второго ребенка.
Працюю в Atlassian в Сіднеї і у нас нещодавно ввели зміни щодо декретної відпустки для батьків. Раніше розподіл був на Primary Carer та Non Primary Carer і вони отримували 20 та 6 тижнів повністю оплачуваної відпустки відповідно, а зараз розподіл на Birthing Parent та Non Birthing Parent з відпустками 26 та 20 тижнів відповідно.
Я перші 6 тижнів використав одразу з народженням доньки (ще до цих змін у процесі відпустки), а з початку квітня піду ще в 14 тижневу відпустку вдобавок до першої частини, щоб сумарно було 20.
Так, перевіряю, проте не всі. Дуже залежить від проекту та компанії.
Часто доводилось працювати на проектах та з компаніями у які дійсно вірив і хотілось щоб вони розвивались та допомагали користувачам.
З деякими компаніями чи проектами/командами був контракт на розробку, вкінці якого були прописані умови передачі коду іншій команді для підтримки й подальшої розробки. Виконавши свою частину та передавши код і бачення для подальшого розвитку проекту з технічної сторони. Досить часто підтримую контакт як з засновниками, так і з розробниками, та іноді дізнаюсь чи все пішло за планом чи ні.
Щодо компаній, то наприклад з 2010 по 2015 рік я працював у MacPaw, підтримую зв’язок з кількома людьми що ще там, та кількома що вже не в компанії. Проте це зовсім не для того щоб випитати що і як, а просто тому що мені не байдуже на розвиток цієї компанії та їх проектів, і завжди цікаво побачити їх нові проекти, та почути про їх досвід. Якби з’явилась така можливість то залюбки співпрацював би з компанією знову :)
Також вже в Atlassian я взяв за звичку завжди розмовляти з людьми які йдуть з проекту над яким разом працювали. Це як додаток до регулярних ретроспектив та 1:1 мітингів з розробниками, також дає зрозуміти над чим варто попрацювати зсередини щоб покращити стан речей.