Надо ли говорить на работе о том, что для сотрудника важно и как это делать, чтобы потом не было мучительно больно?

Статья навеяна вот этой статьей на Хабре: https://habr.com/ru/articles/846700/ (почему не надо оставлять честную обратную связь).

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

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

Но как правильно отвечать на давление? Как правильно и, как сейчас модно говорить, экологично отвечать, когда вы чувствуете, что вас используют, не предлагая ничего стоящего взамен?

Вот про это и предлагаю поговорить ниже.

Привет, Хабр. Я продолжаю делиться «косяками» CSS, которые могут сбить нас с толку. Мне не нравится, что многие плюются от него. Конечно, не без оснований. Я их понимаю, потому что тоже плевался.

Только мне нравится CSS. Хоть и потратил множество часов на изучение неочевидных моментов, я не хочу, чтобы у языка была слава «костыля». Подумав, как помочь другим меньше мучиться, я собираю и объясняю неочевидности CSS.

Эпоха современных хранилищ данных началась с появления реляционных баз данных (далее БД). С появлением бизнес‑аналитики следствием развития БД стала концепция Data Warehouse (корпоративное хранилище данных, DWH).

Дальнейший рост объемов данных, введение термина «большие данные» и разнообразие требований к обработке привели к эволюции архитектур данных.

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

1. Масштабируемость / Scalability

• Масштабируемость — это способность системы поддерживать возросшую нагрузку путем добавления дополнительных ресурсов
• Примером является добавление дополнительных серверов для обработки увеличившегося веб-траффика
• Что такое масштабируемость и как ее достичь?

2. Балансировка нагрузки / Load Balancing

• Балансировка нагрузки — это разделение входящего сетевого траффика между несколькими серверами для снижения нагрузки на каждый из них (во избежание того, чтобы на один сервер приходилось слишком много траффика)
• Примером является распределение веб-траффика между несколькими экземплярами EC2 с помощью сервиса AWS Elastic Load Balancer (ELB)
• Понимание балансировки нагрузки

Конвейер трудится изо всех сил, чтобы повысить производительность твоей программы. А злобные «if»'ы нагло врываются посреди его работы и всё портят!

На сколько полезен конвейер в современных ЭВМ? Как сильно мешаются ветвления в коде, которые ты написал? И как архитекторы процессоров сглаживают ущерб, который «if»'ы наносят по производительности программ?

Ходят слухи, что foreach быстрее for. А ещё ходят слухи, что for быстрее foreach. Пора разобраться, что быстрее!

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

В этой статье я расскажу, как из проекта по созданию метеостанции на Arduino родился проект графического редактора для подготовки bitmap-картинок.

Если в ваших Arduino-проектах используется монохромный OLED-дисплей (например, SSD1306), эта статья поможет вам упростить процесс подготовки картинок для него.

Три года назад у моего мужа нашли рак. А два года назад – у папы. Было страшно и совершенно непонятно, как в целом жить, а не то, чтобы работать и развиваться.

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

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

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же автор серии видео про его устройство.

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

Под катом куча кишков питона и видео на 46 минут с дополнительными кишками питона (ни один настоящий питон не пострадал при написании данной статьи).

До лета 2023 года перед разработчиками Точка.Нетворк стояла проблема: CJM становился сложным, и это затрудняло работу над продуктом. В итоге мы придумали решение — полностью отказались от веба и сосредоточили развитие платформы только в Mini Apps от Телеграма. Без этого было бы невозможно развивать продукт дальше.

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

Легкий и простой способ настроить бесплатную синхронизацию Obsidian между всеми своими устройствами.

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

Техтолк закрывает все эти вопросы. В статье я расскажу, что такое техтолк, зачем мы их запустили и какие проблемы смогли решить.

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

Для кого она? Во‑первых, для тех, кто до сих пор сомневается, имеет ли смысл уходить на удаленку. Или стоит перед выбором (в том числе при смене и поиске новой работы), а иногда и практически перед ультиматумом руководителей, стремящихся минимизировать косты и любыми способами перевести большую часть коллектива на удаленный или гибридный режимы работы.

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

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

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

Привет, хабровчане!

Я Дима, Python-разработчик из 21YARD, сервиса поиска строительных подрядчиков.

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

Все руководители проектов слышали словосочетание «управление рисками». Если спросить на собеседовании, что такое риски и как ими управлять, видно, что РП усердно вспоминают определение риска, вспоминают слово «митигация», но вот ответить на вопрос о том, как с этим работать, не может почти никто. В тоже время есть много книг, посвященных управлению рисками в проектах, на Хабре есть несколько интересных статей (я гуглил, пока готовился).

Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?

Давайте разберемся с рисками.

Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 25 лет опыта в ИТ. Если вам такой опыт интересен, читайте другие мои статьи здесь на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Переход от PosgreSQL-only решения к собственному DataLake для отделения read нагрузки под нужды аналитики и AI.