Экстраполяция IT
Программирование
Подписаться

Ну ничего себе как я недооценил интересность темы! Ладно, давайте продолжим с тегом #экстразарплата.

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

Из вышесказанного естественным образом вытекает простое следствие.

Работодатель согласен заплатить в следующих месяцах больше, если это выгоднее, чем искать нового сотрудника. Конечно, учитывая все риски долго его искать, найти не того, какое-то время вводить новичка в курс дела.

Скажем, ваша зарплата $1000 и вы хотите 10% повышения. Работодатель знает, что найти вам замену можно за месяц и еще месяц уйдет, чтобы освоиться новому сотруднику. Отказав вам, вы начнёте искать работу и будете её искать где-то месяц. Получается, уволить вас будет стоить $2000, а повысить вам зарплату будет стоить $1200 в год. Значит руководству выгоднее повысить зарплату, чем лишиться вас.

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

Другие статьи канала Экстраполяция IT

Экстраполяция IT
Программирование
Подписаться

Одно из самых сложных писем для написания у разработчиков
- это письмо о повышении зарплаты. В нём нужно себя хвалить, рассказывать какой ты молодец и вообще достоин большего.

И вот, в процессе написания такого письма, к каждому критерию приходится мысленно придумывать контраргументы. Их в общем и целом только три.

Первый
- это когда «твоя работа в этом и заключается»:


- Я настроил вон там автоматический процесс, хотя всю жизнь там было всё вручную.

- Это и есть твоя работа.

- Я увеличил конверсию вон того, и у нас теперь больше чего-то там и там.

- За это тебе и платят зарплату.

Второй контраргумент
- «это не твоё дело».


- Я тут инициативно сделал вон то, теперь соседний отдел доволен.

- Это была не твоя работа.

- Я организовал митап и теперь все коллеги стали образованнее.

- Компании это вообще не интересно.

Третий
- «этого не достаточно». Понятно без примеров.

Примечательно, что эти контраргументы не оспариваются вообще. Хуже этого письма может быть только письмо о том, что ты увольняешься.


-
-
-Эксперимент: тема зарплат продолжится другими постами, если наберется суммарно 100 любых реакций под этим постом.

Экстраполяция IT
Программирование
Подписаться
Когда в руках микроскоп, всё вокруг кажется гвоздями.

Это микроскопно-гвоздевая концепция, знакомая всем разработчикам буквально с пелёнок, сильно недооценена. Со стороны всегда видно, что вон тот вот чувак зачем-то пытается решить проблему вот так, хотя надо совершенно по-другому. А вот когда решает задачу и вот почти её решил, начинают влезать с советами, мол, ты всё не так делаешь, и вообще «перепиши все на другом языке, фреймворке и вообще Монгодиби, понял?»

Человек не в состоянии понять какой инструмент подходит лучше, пока он о нём не узнает. У разработчиков это явно прослеживается, но это касается вообще всех. Менеджер проблемы разработки будет решать, добавляя новые отчеты и метрики. Тестировщик вспомнит о новом виде тестирования. Эйчар начнёт искать супер-пупер сеньора. Директора начнут добавлять еще одного Хэд-Оф-Что-то-там. Разработчики будут автоматизировать еще не автоматизированное.

Да, очень часто решение лежит не в той плоскости, в которой вот конкретно вам всё видно и можно что-то изменить. Отсюда и микроскоп в руках, когда вокруг одни гвозди.

Особо страшно становится, когда появляются инструменты, которые одинаково плохо решают вообще все задачи, вроде Экселя. Более-менее освоив эксель (или гугловы спредшит), все проблемы начинают казаться просто набором табличек с формулами.

Экстраполяция IT
Программирование
Подписаться
Один мой хороший знакомый и по совместительству второй сын моих родителей пишет игру.

Пристально и с интересом слежу за процессом. Следите и вы: @SyncopeTheGame

Экстраполяция IT
Программирование
Подписаться

Ребята, нас тут всех приглашают на «RM Вечорниці/RM Online Evening» в эту субботу, 25 июля в 21:00 по киевскому времени.

Программа:21:00
- Приветствие и проверка связи21:10
- Управление проектом в условиях отсутствия пм’а, Андрей Мосин (укр)21:40
- Афтепати с темой: Помните как мы волновались о психическом состоянии на третьей неделе карантина? Или способы адаптации к новым условиям современности. (англ, укр, русс)

Объясним почему так поздно решили проводить ивент: чтобы участники и сам спикер с западного полушария смогли к нам присоединиться.

Регистрация здесь https://bit.ly/3jBBcMR

Если есть вопросы, пишите в чатик, там есть Кристина, которая ответит на вопросы. Если что, это уже завтра вечером.

Экстраполяция IT
Программирование
Подписаться

Помимо продуктово-сервисного критерия для написания программ, есть ещё один клёвый, пока ещё без названия. Давайте вместе в чатике как-то назовём?

Есть приложения, в которых «уже десять лет назад добавили виджеты», а есть приложения, которые только сейчас пытаются выдавать это за инновации. И это не глупость вторых или самоотверженность первых, это просто разные стратегии.

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

Второй подход условно назовём конкистадорский. Это когда приложение пишется с весьма скудным и ограниченным функционалом. Если это, скажем, мобильная операционная система, то в ней не будет не то, чтобы магазина приложений, но не будет даже будильника. Если это будет мобильный банк, то в первой версии там будет разве что проверка баланса и список транзакций.

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

Экстраполяция IT
Программирование
Подписаться

Разработка софта сегодня кардинально отличается от разработки двадцатилетней давности по одной простой причине: интернет везде. И даже сам софт поменял концепцию, назовём современный софт «internet first». Казалось бы, ну теперь есть постоянный коннекшен и можно обновлять приложения сколько угодно часто. Ну ничего страшного и кардинального. Сократилась длина итераций разработки, быстрее получаем обратную связь, быстрее фиксим баги и делаем новые. Быстрее, выше, сильнее и ничего кардинально нового в разработке не произошло. Ведь так?

А вот и произошло. Софт перестал быть товаром и стал услугой (сервисом) в подавляющем большинстве случаев. Этот переход был плавным и постепенным и выделить момент, когда было так, а стало сяк нельзя.

Но разработчики в большинстве своём до сих пор пишут код так, как будто это товар, а не сервис. И вот что действительно отличает эти два подхода, так это то, что сервис меняется постоянно и, что самое ужасное, внезапно. Главная ценность сервисного подхода к написанию кода
- готовность этого кода поменяться в самую неожиданную сторону.

Экстраполяция IT
Программирование
Подписаться
На правах пятницы, обсудим очень хорошую новость последних дней.

Одна извесная дизайн-студия сделала нейросеть, которая рисует логотипы. И, вместо того, чтобы налево и направо рассказывать об этой нейросети, как это делают почти все, ребята год держали тайну и продавали работы этой нейросети, как работы маститого дизайнера. К самим работам можно относиться как угодно, как и к самой студии, но надо признать, что стратегический ход просто потрясающий. Ни один заказчик даже предположить не мог, что его работа сгенерирована нейросетью. Смотря на работы со знанием того, что это сделала нейросеть, работы выглядят генерируемыми и какими-то нейросеточно топорными. А вот не зная этого факта работы выглядят концептуальными и замысловатыми и, простигосподи, нонконформистскими. Самое интересное для нас, читающих «Экстраполяцию» тут то, что искусственный интеллект действительно потихоньку, маленькими шажками наступают на профессии и оттесняют природный интеллект. И это хорошая новость, потому как порог вхождения в умственные профессии будет повышаться, ведь конкурировать нужно будет не только с другими ленивыми кожаными мешками.

Экстраполяция IT
Программирование
Подписаться
Что на самом деле работало бы в микросервисах, если бы менеджеры этим пользовались.

В большом проекте на 20-30 репозиториев, если вы опытный разработчик, вы неоднократно должны были сталкиваться с тем, что вас менеджер старательно возит лицом по всей кодовой базе. В этом спринте вы тут, а в следующем вы уже где-то ещё, а на вашем месте другой несчастный, который, скорее всего, продолжает ваши задачи, некоторые из которых выписывали именно вы. Вы же старательно вникаете в код, в который уже вникали три месяца назад, но уже всё поменялось и в этом новом витке вы снова его читаете и пытаетесь загрузить в оперативную память до того состояния, чтобы вы могли что-то менять. А в следующий спринт вас потащат куда-то ещё.

Таким образом менеджер реализует принцип коллективного владения кодом и пытается защититься от фактора автобуса. Фактор автобуса
- это мера сосредоточения информации среди отдельных членов проекта;
фактор означает количество участников проекта, после потери которых (в оригинале
- «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

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

Вместо этого, приходится чувствовать себя креветкой, прыгающей по проектам и ничего нигде толком не понимающей. Только отвлёкся от какой-то области
- там уже всё переделали, изучай всё заново.

Конечно, начальство не хочет иметь незаменимых людей.

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

#dimoneverything

Экстраполяция IT
Программирование
Подписаться
Самое сложное в процессе программирования — переключение контекстов.

Самое сложное в процессе программирования
- переключение контекстов. И нет ничего хуже, чем думать одновременно о нескольких задачах сразу.

С другой стороны, у нас есть баги, рабочий продакшен, обсуждение будущих фич, регулярные митапы и беклог нереализованных в возможностей. И за всем этим нужно следить и переключать контексты. Конечно, можно избегать переключения контекстов на регулярных митапах, если перестать вникать в рассказы коллег и их проблемы. Ещё можно не переключаться со своей задачи, когда нужно разбирать беклог. А баги можно фиксить с закрытыми глазами просто расставляя if или try-catch операторы у тех местах, где падает. Тогда, наконец, освобожденные мозговые ресурсы пойдут на текущую задачу.

Производительность разработчика радикально падает, когда переключений контекстов будет больше индивидуального лимита, а кто-то в состянии переключаться пару раз в день, кто-то переключаться вообще не может. Если на работе уверены, что вам нельзя переключаться вообще, а вы в состоянии это делать, то у вас появляется пэт-проект или фриланс-подработка. Если разработчик переключается чаще, чем следовало бы, он начинает выгорать и скоро уволится.

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

Как кто с этим живёт и справляется? Прошу в чат для обсуждения.

Экстраполяция IT
Программирование
Подписаться
Ух, давно ничего не писал.

Не подумайте, что нечего писать, периодически что-то как начну писать, но мысль выходит слишком недоформулированной или безопеляционной. Вроде «прежде чем программировать, выясните зачем у вас это вот просят». Гениальная мысль, я знаю. А вот сформулировать мысль получилось о современных микрофонах и удаленном общении.

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


1. Микрофон. Хватит разговаривать в тапок, купите уже наконец нормальный микрофон. Купленная за десять долларов гарнитура вот уж никак не обеспечит приятное звучание вашего голоса для собеедника. Она будет фонить, рипеть чихать и трещать, а вот вам будет казаться, что все отлично.


2. Блютуз. Беспроводные наушники
- это безусловно хорошо, особенно модные эйпродсы или любые другие аналоги. В некоторых случаях операционная система понижает битрейт передачи данных и звук становится такой, как будто разговариваешь по мобиле в девяностых. Экспериментируйте и гуглите чтобы решить эту проблему.


3. Вебкамера. Посмотрите внимательно что находится за вами
- там не должно быть ничего провокационного и черезчур домашнего. Никаких сушилок для белья или семейных портретов. Откорректируйте угол обзора вебкамеры и расстояние до неё
- никому не интересно смотреть на часть вашего лба и бровей в пол экрана.


4. Внешний вид. Про одежду и прическу банальности говорить не буду, но вот во время разговора ничего не жуйте и не пейте. В половине случаев будут слышны ваши чавкания, а во второй половине случаев собеседник будет недоумевать почему вы делаете такие странные паузы посреди предложения.

В качестве проверки, возьмите и запишите свой голос в аудиодорожку и послушайте как это звучит. Прям вообще в качестве энд-ту-энд тестирования попросите своего коллегу записать ваш разговор и послушайте это аудио. Уверен, большинство удивится насколько дерьмово его слышно и видно на том конце провода.

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

Экстраполяция IT
Программирование
Подписаться
Ребята, кому эликсира?

Наш хорошо знакомый эликсирклуб организует встречу с Андреа Леопарди, который один из разработчиков языка первого круга. Рассказывать будет про OTP и уверен, даже те, кто пишут на эликсире, узнают что-то новое обязательно. Детали по ссылке, нам традиционная десятинная скидка по коду extrapolation https://www.facebook.com/events/293583834971044/?active_tab=discussion

Экстраполяция IT
Программирование
Подписаться

Ребята, мы таки настроили работу с гит сабмодулями в нашей сервисной архитектуре, наступили на кучу граблей и сделали пачку костылей. Год назад в «Экстраполяции» я описывал причины почему этого захотелось и получил много справедливой критики в ответ. Где-то тогда и было решено попробовать эту систему в боевых условиях. Прошёл год и система работает довольно хорошо и стабильно с некоторыми нюансами:


1. Обновление сабмодуля в десяти сервисах
- дело неблагодарное и рутинное. Мы сделали сиай-скрипт, который при релизе конкретного модуля делает по пулл реквесту в каждый репозиторий, где он сабмодуль. В итоге вручную обновлять сабмодули практически никогда не нужно.


2. Всячески избегаем саб-сабмодулей. Такие зависимости становятся логически сложными и неудобными в поддержке. И да, во всех случаях, когда в сабмодуле хочется ещё один сабмодуль
- это всегда костыль и это легко решается правильно выбранной архитектурой.


3. Не все языки и фреймворки готовы к такому. Скажем, джаваскриптовый npm к такому не готов, а вот yarn имеет опцию workspaces, которая ведёт себя ровно так, как хочется.


4. Автотесты становятся просто необходимыми. Без них уж очень много ручной необходимой работы.


5. Публичными зависимостями и их версиями нужно управлять автоматически. У нас настроен бот renovate, который каждое утро делает пулл реквесты с обновлением всех зависимостей во всех репозиториях. Ещё в планах настроить правильный автомерж таких вот пулл реквестов, но пока приходится вручную.


6. Нужна жесткая фиксация версий внешних зависимостей. Никаких ">
=
1.14", только "
1.
14.5". Так и обновлять легче и синхронизировать удобнее.


7. Изменения в сабмодули вносить стало очень удобно. Просто cd submodulename и уже там работаешь с сабмодулем непосредственно. А в родительском репозитории можно даже коммитить изменения дочернего, чтобы оно вместе работало. Потом с релизом дочернего всё станет, как должно быть.


8. Всего-то пару настроек в гите и работа с субмодулями становится такой же, как и без сабмодулей. Все твики и хуки легко можно нагуглить.

В общем, всё, что можно автоматизировано, изменения делать удобно, лишней бюрократии нет. Сплошные плюсы.

Экстраполяция IT
Программирование
Подписаться
Поразительно как точные науки научились систематизировать открытия.

И принцип «научного метода» до одури простой: внимательно наблюдай и систематизируй. В Экстраполяции даже об этом было уже, но там было про css, а сейчас хочется вообще о программировании. Очень важно строить такие абстракции, которые соответствуют реальным процессам. Например, если в компании три отдела и данные между отделами передают строго по процедуре, то архитектура в три сервиса будет лучше монолита. Или если в приложении отдельная штука бывает законченной и незаконченной, то конечный автомат из двух состояний будет правильней поля логического типа.

Если классифицировать все причины важности, то их по сути три:


1. Улучшения и изменения системы. Попросить поменять могут что угодно и когда угодно и нужно быть к этому готовым. Чем прямее код соответсвует реальным процессам, тем проще вносить изменения, которые могут попросить.


2. Красивый легаси. Задачи всегда ставятся по процессам, а не по коду и с прямыми абстракциями сильно легче разобраться в незнакомом участке кода.


3. Автотесты по процессам. Прямые абстракции проще всего тестировать, ведь логику тестов и все нюансы скорее всего записаны в описании к задаче.

Собственно, часть работы программиста и состоит в том, чтобы правильно распознавать такие абстракции и предупреждать неправильное использование подходов и паттернов.

Экстраполяция IT
Программирование
Подписаться
В этот раз, в Лямбдашоу в гостях был Влад Пранскевичус, основатель letsenhance.

io и он рассказал о сложностях планирования проектов с машинным обучением. А это, черт побери, не сайтики рисовать. Смотрите сами: https://youtu.be/utEV6wSvXBo

Экстраполяция IT
Программирование
Подписаться

Есть идея организовать прямую трансляцию и поговорить о том, что поменялось в процессах в разработке с вынужденной удалённой работой. Будет несколько гостей, с которыми, собственно, и будем это обсуждать. Ориентируемся пока на пятницу, но это не точно.

Как вам идея?

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...