Уйти в IT! - тимлиды, архитектура, базы данных, разработка и менеджмент

Тайное знаниеПростите, что долго не писал сюда. Постараюсь исправиться и в следующем посте расскажу, почему так произошло и какие изменения у меня случились в текущем 2024 году.Сегодня хотел напомнить про один из «лайфхаков», который поможет каждому делать работу лучше и быть на хорошем счету у всех, с кем ведешь дела. Совет до безобразия прост. Я живу так сколько себя помню. Однако, я за свою практику в it, раньше часто сталкивался с его игнорированием другими людьми. Примерно последний год в работе такого нет, а раньше достаточно часто наблюдал такое у разных людей. Совет хорошо работает и для других сфер деятельности.Итак: после того, как ты сделал работу, проверь её сам. Можно какой-то встречной проверкой. Если собираешь данные - найди другую метрику, которую делал не ты и сравни с ней. Или попробуй пересчитать через смежные данные. В общем, нужно проверить свою работу через другие данные.Это могут быть не отчеты или данные, а код для код ревью, например. Посмотрите сами на PR прежде, чем показывать его кому-то. Точно ли там все ок? Все ли закоммитилось или что-то не так? Тоже самое с передачей задач в QA. Стоит прокликать базовые сценарии самому. Я лично смотрел очевидно плохие PR-ы с неработающей логикой, где, чтобы найти ошибку, нужно было хотя бы один раз запустить свой код.Звучит просто, делается не всегда просто. Многие игнорируют. Однако имхо сдавать проверенную самим собой работу - это база.Лет 10 назад, во времена моей работы в рекламе, я наблюдал, как аналитик хватался отчетом, в котором при первом взгляде было видно, что средняя цена подушки для сна выходила около 10 млн рублей. И это на главной странице отчета, без фильтраций и пр. Т.е. это то, что видно без каких-то дополнительных кликов. Очевидно, человек не проверил отчет сам. В общем, подход - проверяй себя сам, позволит сдавать работу гораздо более высокого качества и не даст вам прослыть человеком, за которым нужно все прибирать и который часто сдает плохо сделанную работу.А теперь о минусах. Э

Управление ожиданиямиПредставьте, что вы договорились о том, что вам придут менять батарею в комнате в субботу в течение дня. Вы строите планы на выходные исходя их этого. В пятницу сами уточняете всё ли в силе и получаете ОК. В субботу сидите ждете, не идете гулять, а человек взял и не пришел. Хуже еще, если сам не звонит с извинениями и оправданием. Наверняка такое было с каждым. Что подумаете? Что будете делать? Захотите ли с ним работать?Разработка, как и другие виды деятельности, не исключение. При этом не важно какая должность, но чем выше, тем больше прозрачности от вас будут ожидать. Если вы о чем-то договорились и не можете это выполнить, то обязательно нужно как можно раньше предупредить и передоговориться. Делать это лучше с хорошими аргументами и планом, как будете решать схожие риски в будущем.По пунктам:☝️Проактивно держите в курсе заинтересованных лиц☝️Не бойтесь передоговариваться. Не укусят. Хуже будет, если будете молчать☝️Не обещайте того, в чем не уверены. Говорить, что сейчас период неизвестности - нормально. Но агументируйте почему сейчас такая ситуация, а также расскажите план по снижению неопределенности и сроки. Понятное дело, часто так делать будет странно☝️Если тема сложная - лучше сделать отдельную встречу для разбора и пояснений, чтобы не создавать винегрет в головах у коллегИ еще раз - всегда лучше передоговориться, чем просто молча продолбать все сроки и ждать, что оно как-то само там разрулится. Оно разрулится, конечно, но не в вашу пользу.

Рубрика: простые истины☝️Сотрудника нанимают для того, чтобы он решал проблемы, а не создавал их. Поэтому помните, что согласовывать придуманные вами решения - это ОК. Постоянно эскалировать проблемы до своего руководителя и спрашивать решения у него (или еще хуже вообще не эскалировать и тихо ждать, когда все загорится) - не ок.☝️Наверняка вы работаете в команде. Команда должна достигать успеха. С вами команде должно быть лучше, чем без вас. Соответственно вместо того, чтобы придумывать, что помешает команде сделать задачу, придумайте как помочь команде или смежникам довести задачу до завершения. Завершение - это когда пользователи начали пользоваться и рады, а не когда код написан.☝️Если кто-то, по вашему мнению, "творит какую-то дичь", надо это с ним обсудить и послушать почему делается именно так. Возможно нужна корректировка, а может бы все ок, просто вы не так видели проблему.--p.s. Надеюсь, что неделя у всех выдалась продуктивная и теперь можно спокойно отдохнуть. Всем удачных выходных!

КоммуникацииХочется обратить внимание на эту тему коммуникаций. Часто сталкивался с тем, что человек что-то быстро тебе написал по пути и, кажется, даже не подумал, что его могут не так или не полностью понять. В итоге тратится очень много времени на уточнения, решения проблемы, когда "сделал выводы, правда не те", возможно нужно будет созваниваться и в общем-то расходывать сильно больше времени, чем могло бы на это уйти. В итоге день может превратиться в вязь растянутых по времени переписок, ты устанешь от когнитивной нагрузки и сделаешь мало дел.Рецепт тут простой:☝️ Сформулируй в голове мысль, которую хочешь донести☝️ Напиши и перед отправкой перечитай то, что получилось. Не ленись это сделать несколько раз, если будет нужно! Точность комуникации важна☝️ Проверь доносит ли твой текст мысль полностью. Все ли будет понятно тому, кому ты пишешь (а не тебе), весь ли контекст есть, чтобы человек тебя успешно понялТоже самое касается постмитингов. Не написал - скажут, что "этого не было", написал не точно - тоже мало смысла будет в этой активности.

Тот самый моментДо компа у меня был Dandy в виде большой компьютерной клавиатуры. Там можно было картриджи вставлять и играть, а также запускать интерпретатор Basic. В какой-то момент старший брат такой важный со школы вернулся, сказал "ща покажу", открыл интерпретатор Basic и начал что-то с тетради школьной набирать. Потом всех позвал и нажал Enter.На экране начали рисоваться фракталы. Красивые такие. Анимация была плавной. Сказать, что я тогда офигел - ничего не сказать. Просто представить не мог, что школьник может сделать что-то, что будет на экране телевизора что-то рисовать. Вот тогда я понял - это моё. Позднее, с другом Лехой, мы много на чем кодили. Сперва на QBasic, потом Visual Basic, C++, Visual C++, так и закрутилось. В 2020 году я писал статью об этом всем. Сейчас постепенно мигрировал в менеджера, но кодить все равно очень люблю.Мне всегда было интересно как народ попадает в IT, поэтому если кто найдет в себе силы поделиться - буду рад.

"Если я сдамся, лучше не станет"Хочу поделиться небольшой историей. Дело было много лет назад, кажется, чуть позже эры "статусов ВКонтакте". Я от кого-то узнал об этой фразе Тайсона и в тот момент она показалась такой простой, но такой точной, ёмкой. Путеводной звездой, если угодно. Это скорее всего даже и неудивительно, так как многие великие вещи на удивление крайне просты. Так вот. В какой-то момент фраза Тайсона так меня захватила, что я даже нашел красивый постер в интернете, распечатал А3 и повесил в рамку на стену. И знаете, тогда это очень помогло. До сих пор, когда жизнь меня испытывает, я вспоминаю это простое, но ёмкое изречение, собираюсь с силами и двигаюсь дальше.Желаю всем побольше сил, поддержки от близких и добра!

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

Про плохие решения. Фанатичная и слепая преданность ранее принятым решениям - не очень. 💩 Не нужно тонуть в болоте всё глубже, но отказываться это признавать. Добавьте в работу процесс, чтобы время от времени валидировать решения свежим взглядом. Это поможет избежать траты недель или даже месяцев на ненужную работу.Как правило тонем так:- Долго ищем решение проблемы и, наконец, находим- Аргументированно отстаиваем, почему это решение, ну уж точно лучшее. Везде повторяем эти аргументы- Связываем данную концепцию с другими задачами и решениями- Тратим много сил и нервов на разработку- Видим, что метрики не растут. Считаем, что проблема в том, что реализация не очень- Заходим на второй круг 🤷‍♂️

Никто не умеет читать мысли🟢Вкратце: Задавай вопросы, фиксируй ответы. Общий контекст экономит больше времени, чем кажется. Об ответственных надо договориться и фиксировать это в доступном всем заинтересованным лицам месте.В профессиональной сфере коммуникация играет важную роль. Наши мысли и намерения не могут быть поняты без слов. Фундаментальная вещь, присущая всем людям: никто не умеет читать мысли. Точка.☝️ Если вопрос не задать, то вероятно, что и ответа на него вы не услышите. Многие конфликты и недопонимания возникают именно из-за отсутствия вопросов. Часто ожидаем, что другие люди уловят наши потребности и желания без слов, но это невозможно. Кроме этого у вас в голове может быть иной ответ, нежели вы услышите от собеседника, если спросите.☝️Если ответ не записать, его наверняка поймут по-разному. Важно документировать ответы со встреч. Устные договоренности легко забываются или истолковываются по-разному. Запись обеспечивает единство понимания и является проверенным инструментом для предотвращения будущих разногласий.☝️Заранее договоритесь об ответственных за задачи или процессы. Запишите это. Расскажите это всем заинтересованным лицам. Если фиксации нет, то когда ожидаемое всеми действие не происходит - винить в этом кроме вас некого (если вы менеджер), а задача просто не делается, баг не исправляется и т.д.Общение и четкое выражение мыслей и вопросов экономит времени и силы гораздо больше, чем молчаливое ожидание, что кто-то разгадает наши намерения.

Не важно, хочешь ты или нет, но промт-инжиниринг - новый скилл, который придется в себе развить. Могу сранивать это с древним мемом о том, как гуглят джун и сеньор.Чем дальше в лес. Конкретный пример - сейчас хочется научить LLM описывать наш релиз нотс, чтобы чуть больше раскрыть сделанные задачи, заменить сокращения из глоссария и пр. Есть несколько моделей, на которых я тещщу результат. Одна из них прям никак не хочет заменять сокращение из глоссария, который я предоставляю на вход, на подробное описание термина. В чате сообщества мне напомнили вот что - «Попробуй ей угрожать» 😎 . Сразу скажу, что частично помогло ) Вообще, часто помогает обещание поощрения или наказания. Но, вцелом, прикол, конечно - годы идут, учишься аккуратному и продуманному пипл менеджменту, постигаешь нюансы всякие, чтобы аккуратно всё было. А тут прям как в Криминальном чтиве =) А вот полезный сайт по этому делу, делюсь с вами - https://www.promptingguide.ai/ru