Притеснение в ИТ
Ребята, салют!
Предлагаю немного пообщаться.
На одной из консультаций меня спросили: «Встречается ли в ИТ эйджизм?»
Я замешкался, ведь лично не встречался ни с какими притеснениями. Ко мне всегда относились с уважением, как и я к другим. С одной стороны, в ИТ высокая корпоративная культура, все понимают серьезность и ответственность профессии. Но с другой, если бы все складывалось гладко, то историй, вроде этой или этой не было бы.
А как у вас? Приходилось ли сталкиваться с любыми видами ущемлений (сексизм, эйджизм, расизм и т.д.)? Как боролись с этим? Какие выводы сделали для себя?
Ребята, салют!
Предлагаю немного пообщаться.
На одной из консультаций меня спросили: «Встречается ли в ИТ эйджизм?»
Я замешкался, ведь лично не встречался ни с какими притеснениями. Ко мне всегда относились с уважением, как и я к другим. С одной стороны, в ИТ высокая корпоративная культура, все понимают серьезность и ответственность профессии. Но с другой, если бы все складывалось гладко, то историй, вроде этой или этой не было бы.
А как у вас? Приходилось ли сталкиваться с любыми видами ущемлений (сексизм, эйджизм, расизм и т.д.)? Как боролись с этим? Какие выводы сделали для себя?
🌭7👍1
Как работает Single Sign-On (SSO)?
Определение
Single Sign-On - это процесс аутентификации, который позволяет пользователю получить доступ к нескольким приложениям с помощью одного набора учетных данных. Повышает удобство пользователей, снижает утомляемость от ввода паролей и упрощает доступ к различным платформам.
Как работает SSO
1. Аутентификация: Пользователи входят в систему один раз, используя свои учетные данные.
2. Выдача токена: После успешной аутентификации генерируется токен.
3. Проверка токена: Токен проверяется участвующими приложениями для последующего доступа.
Плюсы SSO
1. Удобство: Пользователи получают доступ к нескольким приложениям с помощью одного логина, что избавляет их от необходимости запоминать несколько паролей.
2. Безопасность: Централизованная аутентификация улучшает контроль, видимость и соблюдение политик безопасности.
3. Производительность: Упорядоченный доступ повышает эффективность и сокращает время, затрачиваемое на процессы аутентификации.
Типы SSO
Корпоративный SSO (ESSO): Доступ к приложениям в корпоративной сети.
Web SSO: доступ к веб-приложениям с использованием единого логина.
SSO протоколы
1. SAML (Security Assertion Markup Language): Стандарт на основе XML для обмена данными аутентификации и авторизации.
2. OAuth (Open Authorization): Протокол для безопасного, делегированного доступа к ресурсам.
3. OpenID Connect: Уровень идентификации поверх OAuth 2.0, облегчающий аутентификацию пользователей.
Примеры SSO
1) Google Sign-In
2) Apple SSO
3) VK SSO
Подробнее
Определение
Single Sign-On - это процесс аутентификации, который позволяет пользователю получить доступ к нескольким приложениям с помощью одного набора учетных данных. Повышает удобство пользователей, снижает утомляемость от ввода паролей и упрощает доступ к различным платформам.
Как работает SSO
1. Аутентификация: Пользователи входят в систему один раз, используя свои учетные данные.
2. Выдача токена: После успешной аутентификации генерируется токен.
3. Проверка токена: Токен проверяется участвующими приложениями для последующего доступа.
Плюсы SSO
1. Удобство: Пользователи получают доступ к нескольким приложениям с помощью одного логина, что избавляет их от необходимости запоминать несколько паролей.
2. Безопасность: Централизованная аутентификация улучшает контроль, видимость и соблюдение политик безопасности.
3. Производительность: Упорядоченный доступ повышает эффективность и сокращает время, затрачиваемое на процессы аутентификации.
Типы SSO
Корпоративный SSO (ESSO): Доступ к приложениям в корпоративной сети.
Web SSO: доступ к веб-приложениям с использованием единого логина.
SSO протоколы
1. SAML (Security Assertion Markup Language): Стандарт на основе XML для обмена данными аутентификации и авторизации.
2. OAuth (Open Authorization): Протокол для безопасного, делегированного доступа к ресурсам.
3. OpenID Connect: Уровень идентификации поверх OAuth 2.0, облегчающий аутентификацию пользователей.
Примеры SSO
1) Google Sign-In
2) Apple SSO
3) VK SSO
Подробнее
👍9❤6👎2
Документация как код
На прошлой работе внедрили офигенную практику – вести документацию как код (docs as a code). Перед нами стояла задача перетащить всю доку из Confluence в Git, сделав удобно всем. Спойлер, получилось не совсем гладко, но давайте по порядку.
Я работал в команде интеграций на бэке. Мы пилили интеграционные адаптеры с различными банками и МФО. Процесс выглядел так: адаптер слушает определенную очередь, получает сообщение, преобразовывает его и отправляет вовне. В рамках адаптера содержится несколько методов, от одного до нескольких десятков. Это чисто техническая история, мы не взаимодействовали с фронтом и не описывали его.
Ситуация “As-Is”. Под каждый адаптер есть статья в Confluence, где пошагово расписан процесс: какую очередь слушаем, куда отправляем результат, в какую очередь складываем ответ, пример/описание входящего/исходящего сообщения, и другая техническая информация. Если методов было много, то прикладывали ссылку на draw.io с Sequence Diagram.
Что же получилось? Для текстового описания выбрали AsciiDoc. У него понятный синтаксис, а главное, он корректно отображается в Confluence. Для того, чтобы не делать двойную работу, вся документация велась в Git, а в Confluence указывались ссылки на репозитории.
Помимо AsciiDoc стали использовать PlantUML. Он сильно ускорил процесс «отрисовки» диаграмм, ведь теперь аналитик работает с текстом, а графическое расположение формируется автоматически. Плюс, для каждого метода стали моделировать Class Diagram. В перспективе из них разработчики могли бы генерировать классы.
Наконец, шлифанули это все OpenAPI. Ранее аналитик прописывал параметры и ограничения запроса, а разработчик дублировал эту работу в коде. OpenAPI позволял делать это один раз – аналитик формирует спеку, а разработчик из нее генерирует код. Искренне не понимаю, почему всю доку API не делают именно в формате OpenAPI, ведь это наглядный и понятный стандарт.
В идеальной картине мы видели следующие плюсы:
- Всегда актуальная документация. Ведь она изменяется только вместе с кодом.
- Ускоренная разработка. Ведь часть работы уже выполнил аналитик.
- Прокаченные аналитики. Ведь им нужно освоить несколько новых инструментов.
Реальность оказалось суровее. После ухода тимлида (мощнейший эксперт, безумно рад, что нам удалось поработать вместе) инициативу стало почти невозможно толкать. В работе использовалось только Ascii описание, а Puml и Swagger никто не использовал. Соседние команды смотрели на нас как на сумасшедших – «ведь аналитикам придется делать столько дополнительной работы». А бизнес говнялся, ведь им было неудобно смотреть рендеринг репозиториев Git в Confluence.
По итогу, из запланированного взлетела только часть. Несмотря на это, каждый раз, когда я говорил на собеседованиях, что веду документацию в Git, в ответ получал только «мое почтение».
А как обстоят дела с докой на работе у вас?
На прошлой работе внедрили офигенную практику – вести документацию как код (docs as a code). Перед нами стояла задача перетащить всю доку из Confluence в Git, сделав удобно всем. Спойлер, получилось не совсем гладко, но давайте по порядку.
Я работал в команде интеграций на бэке. Мы пилили интеграционные адаптеры с различными банками и МФО. Процесс выглядел так: адаптер слушает определенную очередь, получает сообщение, преобразовывает его и отправляет вовне. В рамках адаптера содержится несколько методов, от одного до нескольких десятков. Это чисто техническая история, мы не взаимодействовали с фронтом и не описывали его.
Ситуация “As-Is”. Под каждый адаптер есть статья в Confluence, где пошагово расписан процесс: какую очередь слушаем, куда отправляем результат, в какую очередь складываем ответ, пример/описание входящего/исходящего сообщения, и другая техническая информация. Если методов было много, то прикладывали ссылку на draw.io с Sequence Diagram.
Что же получилось? Для текстового описания выбрали AsciiDoc. У него понятный синтаксис, а главное, он корректно отображается в Confluence. Для того, чтобы не делать двойную работу, вся документация велась в Git, а в Confluence указывались ссылки на репозитории.
Помимо AsciiDoc стали использовать PlantUML. Он сильно ускорил процесс «отрисовки» диаграмм, ведь теперь аналитик работает с текстом, а графическое расположение формируется автоматически. Плюс, для каждого метода стали моделировать Class Diagram. В перспективе из них разработчики могли бы генерировать классы.
Наконец, шлифанули это все OpenAPI. Ранее аналитик прописывал параметры и ограничения запроса, а разработчик дублировал эту работу в коде. OpenAPI позволял делать это один раз – аналитик формирует спеку, а разработчик из нее генерирует код. Искренне не понимаю, почему всю доку API не делают именно в формате OpenAPI, ведь это наглядный и понятный стандарт.
В идеальной картине мы видели следующие плюсы:
- Всегда актуальная документация. Ведь она изменяется только вместе с кодом.
- Ускоренная разработка. Ведь часть работы уже выполнил аналитик.
- Прокаченные аналитики. Ведь им нужно освоить несколько новых инструментов.
Реальность оказалось суровее. После ухода тимлида (мощнейший эксперт, безумно рад, что нам удалось поработать вместе) инициативу стало почти невозможно толкать. В работе использовалось только Ascii описание, а Puml и Swagger никто не использовал. Соседние команды смотрели на нас как на сумасшедших – «ведь аналитикам придется делать столько дополнительной работы». А бизнес говнялся, ведь им было неудобно смотреть рендеринг репозиториев Git в Confluence.
По итогу, из запланированного взлетела только часть. Несмотря на это, каждый раз, когда я говорил на собеседованиях, что веду документацию в Git, в ответ получал только «мое почтение».
А как обстоят дела с докой на работе у вас?
❤12👍4
Документация как код. Инструменты
Это продолжение статьи, выходившей на прошлой неделе. Рекомендую сначала ознакомиться с ней.
Давайте подробнее об инструментах, что нужно использовать, чтобы реализовать подход Docs as a Code.
0) У аналитиков должен быть доступ к коду. Очевидный и главный пункт. Если ИБ считает, что код вам видеть не положено, то дальнейший текст не имеет смысла.
1) IDE. Подойдет любая, но мы работали с продуктами JetBrains. Выбирайте ту, в которой пишут разрабы. Кстати, недавно зарелизилась IDE для документации – Writeside. На боевых проектах не пробовал, но выглядит интересно.
2) Описание. Дальнейшие шаги завязаны на расширениях для IDE, поскольку не все поддерживается из коробки. Мы использовали AsciiDoc для текстового описания. Конкретно этот плагин. Также прикладываю синтаксис. В качестве аналога можно использовать Markdown. Он работает без дополнительных расширений.
3) Диаграммы. Использовали PlantUML. Расширение доступно здесь. Синтаксис можно изучить тут. В качестве альтернативы рассмотрите возможность использования Mermaid.
4) API. Для описания апишек использовали формат OpenAPI. Он также поддерживается без дополнительных расширений. Но для удобства использовал плагин позволяющий быстро перемещаться по разделам. Уроков по использования Swagger очень много, вот один из них.
Как это работало? При написании документации аналитик создавал ветку, где добавлял папку “docs” в корень репозитория, в ней хранились необходимые файлы с расширениями .adoc, .puml и .yaml соответственно. Как только описание было завершено, разработчик начинал писать код в той же ветке. Наконец, дока и код одновременно сливались в мастер.
Стало ли понятнее? Остались ли вопросы? Пишите в комментариях.
Это продолжение статьи, выходившей на прошлой неделе. Рекомендую сначала ознакомиться с ней.
Давайте подробнее об инструментах, что нужно использовать, чтобы реализовать подход Docs as a Code.
0) У аналитиков должен быть доступ к коду. Очевидный и главный пункт. Если ИБ считает, что код вам видеть не положено, то дальнейший текст не имеет смысла.
1) IDE. Подойдет любая, но мы работали с продуктами JetBrains. Выбирайте ту, в которой пишут разрабы. Кстати, недавно зарелизилась IDE для документации – Writeside. На боевых проектах не пробовал, но выглядит интересно.
2) Описание. Дальнейшие шаги завязаны на расширениях для IDE, поскольку не все поддерживается из коробки. Мы использовали AsciiDoc для текстового описания. Конкретно этот плагин. Также прикладываю синтаксис. В качестве аналога можно использовать Markdown. Он работает без дополнительных расширений.
3) Диаграммы. Использовали PlantUML. Расширение доступно здесь. Синтаксис можно изучить тут. В качестве альтернативы рассмотрите возможность использования Mermaid.
4) API. Для описания апишек использовали формат OpenAPI. Он также поддерживается без дополнительных расширений. Но для удобства использовал плагин позволяющий быстро перемещаться по разделам. Уроков по использования Swagger очень много, вот один из них.
Как это работало? При написании документации аналитик создавал ветку, где добавлял папку “docs” в корень репозитория, в ней хранились необходимые файлы с расширениями .adoc, .puml и .yaml соответственно. Как только описание было завершено, разработчик начинал писать код в той же ветке. Наконец, дока и код одновременно сливались в мастер.
Стало ли понятнее? Остались ли вопросы? Пишите в комментариях.
🔥19🫡3
Синдром хорошего парня или как избыток эмпатии может навредить
На протяжении пути меня всегда окружали ответственные, осознанные люди, готовые прийти на помощь. Нас учили работать на результат, даже во вред себе. В школе и универе всегда встречались те, кто делали больше других и получали высшую похвалу. Но такой подход слабо применим к работе. Те, кто обладают повышенной ответственностью и амбициями, взваливают все на себя: перерабатывают, берут больше обязанностей, не спрашивая о вознаграждении, переживают за бизнес и команду. Наконец, медленно превращаются в угли.
«Синдром хорошего парня» или желание понравиться всем сильно вредит в повседневной жизни и на работе. Нет ничего страшного в том, чтобы отказывать людям. Предлагают поработать дополнительно, без оплаты? Нет, спасибо. Выдвигают на новую должность с повышенной нагрузкой, ведь в перспективе можно будет вырасти в зп? Думаю, что откажусь. Никто не посмотрит косо, если вы хотите делать только то, на что договорились, а в свободное время отдыхать. Вы не обязаны подскакивать от каждого уведомления и судорожно бежать делать задачу. Вспомните коллег, которые отвечают вам в течение дня, а не в течение часа. Разве их кто-то упрекает в том, что они недоступны в режиме онлайн?
Плюс на работе всегда встречаются мудаки. Коллеги, которые могут и не хамить напрямую, но отвечать с высока и упрекать вас в некомпетентности. На первом месте был разработчик, который постоянно косячил и не хотел читать ТЗ. Он звонил и говорил: «Я тут ничего не понимаю, и делать ничего не буду». На другой, аналитик из соседней команды отвечал на мои вопросы: «Это же ваша задача, вот и делайте как знаете». Единственно верный выход из ситуации – эскалация. Но не в духе: «Он меня обидел», а с посылом: «Я пытался наладить коммуникацию, но коллега закрыт. Это мешает достижению результата». Крайний случай, не нужно доводить до такого, но подумайте, раз их никто не уволил, почему же вы должны всем нравиться? Плюс, вы ценный и крутой специалист, разве может рандомный человек, мнение которого вас не интересует, пошатнуть ваши компетенции?
Как итог, на работе в первую очередь нужно думать о себе и своем здоровье. Желание быть классным для всех со временем обернется боком. Умейте отказывать и пропускать мимо ушей всякую чушь. Тогда и жить станет легче.
На протяжении пути меня всегда окружали ответственные, осознанные люди, готовые прийти на помощь. Нас учили работать на результат, даже во вред себе. В школе и универе всегда встречались те, кто делали больше других и получали высшую похвалу. Но такой подход слабо применим к работе. Те, кто обладают повышенной ответственностью и амбициями, взваливают все на себя: перерабатывают, берут больше обязанностей, не спрашивая о вознаграждении, переживают за бизнес и команду. Наконец, медленно превращаются в угли.
«Синдром хорошего парня» или желание понравиться всем сильно вредит в повседневной жизни и на работе. Нет ничего страшного в том, чтобы отказывать людям. Предлагают поработать дополнительно, без оплаты? Нет, спасибо. Выдвигают на новую должность с повышенной нагрузкой, ведь в перспективе можно будет вырасти в зп? Думаю, что откажусь. Никто не посмотрит косо, если вы хотите делать только то, на что договорились, а в свободное время отдыхать. Вы не обязаны подскакивать от каждого уведомления и судорожно бежать делать задачу. Вспомните коллег, которые отвечают вам в течение дня, а не в течение часа. Разве их кто-то упрекает в том, что они недоступны в режиме онлайн?
Плюс на работе всегда встречаются мудаки. Коллеги, которые могут и не хамить напрямую, но отвечать с высока и упрекать вас в некомпетентности. На первом месте был разработчик, который постоянно косячил и не хотел читать ТЗ. Он звонил и говорил: «Я тут ничего не понимаю, и делать ничего не буду». На другой, аналитик из соседней команды отвечал на мои вопросы: «Это же ваша задача, вот и делайте как знаете». Единственно верный выход из ситуации – эскалация. Но не в духе: «Он меня обидел», а с посылом: «Я пытался наладить коммуникацию, но коллега закрыт. Это мешает достижению результата». Крайний случай, не нужно доводить до такого, но подумайте, раз их никто не уволил, почему же вы должны всем нравиться? Плюс, вы ценный и крутой специалист, разве может рандомный человек, мнение которого вас не интересует, пошатнуть ваши компетенции?
Как итог, на работе в первую очередь нужно думать о себе и своем здоровье. Желание быть классным для всех со временем обернется боком. Умейте отказывать и пропускать мимо ушей всякую чушь. Тогда и жить станет легче.
❤31🔥15👍6
Карта компетенций бизнес/системного аналитика
Собрал для вас карту навыков, которые необходимо получить для освоения профессии. Перечень тем сформировался исходя из моего опыта, и опыта моих учеников.
Это мастхэв и минимум, который ждут на собеседованиях.
Карта интерактивная, под каждую тему представлена ссылка, где почитать подробнее. А дальше можно гуглить самостоятельно.
@notsystemanalysis
Собрал для вас карту навыков, которые необходимо получить для освоения профессии. Перечень тем сформировался исходя из моего опыта, и опыта моих учеников.
Это мастхэв и минимум, который ждут на собеседованиях.
Карта интерактивная, под каждую тему представлена ссылка, где почитать подробнее. А дальше можно гуглить самостоятельно.
@notsystemanalysis
🔥62👍11❤6👏3😱1
Почему софты все-таки важнее?
По крайней мере для аналитика
Извечный спор о софтах и хардах вряд ли когда-нибудь закончится. Ведь у сторонников того и другого лагерей существуют аргументы, с которыми тяжело спорить. Я придерживаюсь теории, что софт скиллы приоритетнее для аналитика. Хотя статистика реакций и пересылок на постах в канале говорит об обратном. Накидываю еще парочку аргументов в защиту «мягких» навыков.
Софты помогают в работе. Вспомните, как приятно общаться с коллегами, которые всегда готовы выслушать и помочь. И пусть они не знают точного ответа на вопрос, но подскажут, к кому можно обратиться. Уважительное отношение всегда играет на руку: при вопросах поощрения, вас рассмотрят с большей вероятностью, а если вы накосячите, то на это могут закрыть глаза. Плюсом, не стоит забывать, что аналитик постоянно коммуницирует с командой и заказчиком, быть токсиком здесь просто не получится. Правда не стоит забывать, что у вежливости есть обратная сторона
Софты помогают на собеседовании. Я говорю не только о первом впечатлении, но и ораторском искусстве. Умение продавать себя, а также грамотно преподносить достижения, сильно увеличивает шансы на крупный оффер. Можно не знать ответ на вопрос, но уметь отвечать рядом или рассуждать так, что это очарует интервьюера. В конце концов, подумайте, кто вам запомнится больше – кандидат, который структурно и грамотно рассказывает о себе, но не знает некоторые темы или супер хардовый аналитик, который не может связать двух слов?
Софты помогают в жизни. Расширяя кругозор и общую насмотренность. Есть множество увлекательных занятий помимо ИТ. Велик соблазн зарыться в технологии, но в определенный момент становится тупо скучно. Софты помогут окружить себя интересными людьми и развиваться всесторонне. Ваша кукушка скажет спасибо.
Ответьте себе на такой вопрос: «Если бы мне пришлось создавать команды/выбирать кандидата/находить товарища кто бы это был?» Высокомерный профессионал, тяжелый в общении или крепкий середнячок, способный в диалог и эмпатию?
Что думаете по теме?
По крайней мере для аналитика
Извечный спор о софтах и хардах вряд ли когда-нибудь закончится. Ведь у сторонников того и другого лагерей существуют аргументы, с которыми тяжело спорить. Я придерживаюсь теории, что софт скиллы приоритетнее для аналитика. Хотя статистика реакций и пересылок на постах в канале говорит об обратном. Накидываю еще парочку аргументов в защиту «мягких» навыков.
Софты помогают в работе. Вспомните, как приятно общаться с коллегами, которые всегда готовы выслушать и помочь. И пусть они не знают точного ответа на вопрос, но подскажут, к кому можно обратиться. Уважительное отношение всегда играет на руку: при вопросах поощрения, вас рассмотрят с большей вероятностью, а если вы накосячите, то на это могут закрыть глаза. Плюсом, не стоит забывать, что аналитик постоянно коммуницирует с командой и заказчиком, быть токсиком здесь просто не получится. Правда не стоит забывать, что у вежливости есть обратная сторона
Софты помогают на собеседовании. Я говорю не только о первом впечатлении, но и ораторском искусстве. Умение продавать себя, а также грамотно преподносить достижения, сильно увеличивает шансы на крупный оффер. Можно не знать ответ на вопрос, но уметь отвечать рядом или рассуждать так, что это очарует интервьюера. В конце концов, подумайте, кто вам запомнится больше – кандидат, который структурно и грамотно рассказывает о себе, но не знает некоторые темы или супер хардовый аналитик, который не может связать двух слов?
Софты помогают в жизни. Расширяя кругозор и общую насмотренность. Есть множество увлекательных занятий помимо ИТ. Велик соблазн зарыться в технологии, но в определенный момент становится тупо скучно. Софты помогут окружить себя интересными людьми и развиваться всесторонне. Ваша кукушка скажет спасибо.
Ответьте себе на такой вопрос: «Если бы мне пришлось создавать команды/выбирать кандидата/находить товарища кто бы это был?» Высокомерный профессионал, тяжелый в общении или крепкий середнячок, способный в диалог и эмпатию?
Что думаете по теме?
🔥18❤6👍5
Почему постоянное развитие тебя убьет?
Пост навеян статистикой по каналу. Я делаю разный контент, как технический, так и софтовый. И технический всегда репостится больше. Хотя освещать темы, не затрагивающие хардовые вопросы, мне куда интереснее. Рассказываю, почему и вам стоит выйти за пределы ИТ.
Выучить все невозможно, да и не нужно. Чем дольше в профессии, тем больше понимаешь, что знать все просто нереально. «Полезная» информация тупо копится и со временем исчезает. Гораздо эффективнее подход, когда сталкиваешься с задачей и учишь что-то новое для ее решения. Будь то рабочие моменты или прохождение собеседований. Ведь если не проверять себя, то откуда можно узнать, какие знания нужны, а какие нет?
Успешный успех вокруг. Из соцсетей льется посыл: «Ты должен быть лучше». Видосы и статьи, подборки и списки продуктивности только мешают. Вы никогда не станете лучше, если вчера лежали на диване, а сегодня решили стать суперпродуктивным. Постепенное вырабатывание привычки и дисциплина – ключ к успеху. Нужно не гнаться за красивой картинкой, а слушать себя и расставлять приоритеты. Если не давать организму отдохнуть, то в определенной момент можно найти себя в такой яме, из которой придется очень больно выбираться.
Только баланс. Банальная мысль, озвученная недавно в коммьюнити, но без баланса никуда. Ты не станешь успешным специалистом, если будешь качать только харды. Из тебя не выйдет интересный собеседник, если ты можешь говорить только о работе. Ты не сможешь преодолеть новые вершины, если не отдохнешь и не похвалишь себя за достижения. Простые, но важные истины.
Поэтому слушайте себя, развивайтесь и не перегибайте. Никому не нужен очередной выгоревший сеньор. Впереди длинные выходные, проведите их с кайфом!
Пост навеян статистикой по каналу. Я делаю разный контент, как технический, так и софтовый. И технический всегда репостится больше. Хотя освещать темы, не затрагивающие хардовые вопросы, мне куда интереснее. Рассказываю, почему и вам стоит выйти за пределы ИТ.
Выучить все невозможно, да и не нужно. Чем дольше в профессии, тем больше понимаешь, что знать все просто нереально. «Полезная» информация тупо копится и со временем исчезает. Гораздо эффективнее подход, когда сталкиваешься с задачей и учишь что-то новое для ее решения. Будь то рабочие моменты или прохождение собеседований. Ведь если не проверять себя, то откуда можно узнать, какие знания нужны, а какие нет?
Успешный успех вокруг. Из соцсетей льется посыл: «Ты должен быть лучше». Видосы и статьи, подборки и списки продуктивности только мешают. Вы никогда не станете лучше, если вчера лежали на диване, а сегодня решили стать суперпродуктивным. Постепенное вырабатывание привычки и дисциплина – ключ к успеху. Нужно не гнаться за красивой картинкой, а слушать себя и расставлять приоритеты. Если не давать организму отдохнуть, то в определенной момент можно найти себя в такой яме, из которой придется очень больно выбираться.
Только баланс. Банальная мысль, озвученная недавно в коммьюнити, но без баланса никуда. Ты не станешь успешным специалистом, если будешь качать только харды. Из тебя не выйдет интересный собеседник, если ты можешь говорить только о работе. Ты не сможешь преодолеть новые вершины, если не отдохнешь и не похвалишь себя за достижения. Простые, но важные истины.
Поэтому слушайте себя, развивайтесь и не перегибайте. Никому не нужен очередной выгоревший сеньор. Впереди длинные выходные, проведите их с кайфом!
🔥35👍7❤6
Ребята, привет!
Улетаю на неделю в отпуск на Байкал, поэтому ИТ контента не будет.
Не теряйте.
З.Ы. Ставь 🌭 если было бы интересно посмотреть фоточки с Байкала.
Улетаю на неделю в отпуск на Байкал, поэтому ИТ контента не будет.
Не теряйте.
З.Ы. Ставь 🌭 если было бы интересно посмотреть фоточки с Байкала.
🌭90👍4🍌2❤1
Байкал. День 1
С утра прилетели в Иркутск. Суровая Сибирь. Вокруг стройка, разруха и люди с каменными лицами. Ближайший мак в Красноярске. Так далеко по России ещё не ездил. Как сказал классик: «Мне потребовалось только 48 часов, чтобы осознать….»
В первый день наш путь лежал на остров Ольхон. Дорога неблизкая - 230 км от Иркутска. По пути заехали в Усть Ордынск, познакомились с обычаями бурятов. С одной стороны, все выглядит как развлечение для туристов, с другой, я проникся этим. Народные танцы и горловое пение сделано с душой.
Во второй половине дня доехали до Ольхона и заселились в отель. На острове протяженностью 114 километров проживает всего 1744 человека (на 2019 год). Выглядит он, как пыльная деревня, где нет снега, дорог и цивилизации. Гид подсказал, что электричество на острове появилось лишь в 2005. Чтоб вы понимали приоритеты, дорог нет, но интернет ловит.
Зато Байкал, мое почтение. Величие природы во всей красе. Уже успели и проехаться на машине и погулять пешком. Нереальные виды как на само озеро, так и на прилегающие горы и холмы. Вы и сами видите фото.
По еде сегодня весь день на буузах (хинкали) и чебуреках. Жирно и вкусно.
Сейчас умотанные лежим в отеле, получилось насыщенно, плюс джетлаг дает о себе знать.
Отпуск начался!
С утра прилетели в Иркутск. Суровая Сибирь. Вокруг стройка, разруха и люди с каменными лицами. Ближайший мак в Красноярске. Так далеко по России ещё не ездил. Как сказал классик: «Мне потребовалось только 48 часов, чтобы осознать….»
В первый день наш путь лежал на остров Ольхон. Дорога неблизкая - 230 км от Иркутска. По пути заехали в Усть Ордынск, познакомились с обычаями бурятов. С одной стороны, все выглядит как развлечение для туристов, с другой, я проникся этим. Народные танцы и горловое пение сделано с душой.
Во второй половине дня доехали до Ольхона и заселились в отель. На острове протяженностью 114 километров проживает всего 1744 человека (на 2019 год). Выглядит он, как пыльная деревня, где нет снега, дорог и цивилизации. Гид подсказал, что электричество на острове появилось лишь в 2005. Чтоб вы понимали приоритеты, дорог нет, но интернет ловит.
Зато Байкал, мое почтение. Величие природы во всей красе. Уже успели и проехаться на машине и погулять пешком. Нереальные виды как на само озеро, так и на прилегающие горы и холмы. Вы и сами видите фото.
По еде сегодня весь день на буузах (хинкали) и чебуреках. Жирно и вкусно.
Сейчас умотанные лежим в отеле, получилось насыщенно, плюс джетлаг дает о себе знать.
Отпуск начался!
🔥37👍5❤2
КОНКУРС
Придумай самую смешную подпись для фото и получи сувенир с Байкала. Отправлю в любую точку РФ или могу отдать лично, если находитесь в мск.
Оставляйте свои варианты в комментариях к посту.
Выберу двух победителей: за самый залайканный комментарий и тот, который понравится мне.
Конкурс закончится 03.03 в 23:59 по мск.
Придумай самую смешную подпись для фото и получи сувенир с Байкала. Отправлю в любую точку РФ или могу отдать лично, если находитесь в мск.
Оставляйте свои варианты в комментариях к посту.
Выберу двух победителей: за самый залайканный комментарий и тот, который понравится мне.
Конкурс закончится 03.03 в 23:59 по мск.
🔥11❤4🤮1