Эта статья посвящена тому, как распределять задачи между конвейерами очередей, чтобы минимизировать общее время обработки, а также неожиданной связи между этим методом планирования и методом Томаса Джефферсона.

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

- bool LoadAnimation(str::string filename);
- void DrawLines(std::vector path);
- Matrix RotateObject(Matrix m, Angle angle);
- int DrawSprite(Sprite sprite);

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

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

Все самые важные и интересные финансовые новости в России и мире за неделю: Дуров готов сливать ваши данные органам, 26 льготных ипотек на человека, бескупонная облигация Сбера для гуманитариев, законы о пропаганде чайлдфри и оскорблении чиновников, взлет китайских акций, а также захват онлайн-покеррумов нёрдами из Омска.

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

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

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

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

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

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

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

Меня зовут Саша Киверин, я лид Python-гильдии в Циан. Сейчас в нашем сообществе более 60 разработчиков. За последние 2 года мы совместными усилиями сделали целый ряд крутых проектов. Перевели монолит с версии Python 2.7 на 3.12, создали библиотеку для внешних вызовов и внедрили автоматический чеклист здоровья микросервиса. Дотащить все это до прода нам помогли 5 простых советов, которыми я и поделюсь в этой статье. Надеюсь, они помогут оживить и вашу гильдию. 

Бывает такое, что на вашем проекте есть эксперт, от которого вам надо получить ОК на документацию, или чтобы он сделал важную работу, которая находится на критическом пути проекта. И, внезапно, этот эксперт делать вашу свою работу и давать вам ОК вообще не торопится. Что с ним делать?

Бывает такое, что на проекте произошла неприятность, требующая немедленного извещения вашего руководителя или Заказчика, а те не отвечают? А время идет и вы понимаете, что в бездействии обвинят вас, РП, ведь именно вы должны были всех оповестить. Что делать в этой ситуации?

Эта небольшая статья - продолжение цикла моих статей о том, чего не говорят на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны эти истории - читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо, но мало. Вы должны принимать решения не только исходя из технических деталей задачи, но и с учётом реалий бизнеса, его потребностей и направления развития.

Меня зовут Олег Федоткин, я СТО компании Циан. В этой статье расскажу, почему понимание бизнеса так важно для ИТ-менеджеров, тимлидов и архитекторов, и как оно влияет на принятие технических решений и развитие карьеры. Больше и чаще на подобные темы я пишу в свой ТГ-канал «Инженер и Менеджер».

Кому будет полезна статья:

Менеджерам в ИТ: тим-/юнит-лидам, руководителям направлений и СТО. Без понимания бизнеса у вас не получится построить карьеру — это аксиома.

Специалистам выше уровня senior: staff-/principal-инженерам и архитекторам для выработки полезных для компании технических решений.

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

Как выстраивать грамотную коммуникацию с подчинёнными? По мнению автора статьи Cindy Sridharan*, многие новоиспечённые начальники, стремясь завоевать расположение людей, слишком вовлекаются в заботу о них и пренебрегают другими важными задачами. В итоге, любовь сотрудников может стать опасной штукой, которая принесёт вред и убытки всей организации. Во всём нужно искать баланс. 

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Вонючее начало

Привет, Хабр! Меня зовут Александр Бардаш, я главный архитектор интеграционных платформ в МТС. Сегодня расскажу, почему ИТ-архитекторам важно хотя бы иногда всегда читать книги, и поделюсь подборкой для начинающих. Жду вас под катом и в комментариях!

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

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

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

Привет, Хабр! Это Саша Бардаш, главный архитектор интеграционных платформ в МТС Диджитал. В прошлый раз я рассказывал о пяти книгах, которые стоит почитать начинающему ИТ-архитектору. Большое спасибо всем, кто читал. Были интересные комментарии на тему, какие еще книги почитать — кое-что из этого я добавил в свою новую подборку. Итак, под катом пять книг, которые будут интересны уже более опытным ИТ-архитекторам. Что ж, поехали!

По данным Ассоциации маркетинговых исследований, только 40% продуктов в итоге выходят на рынок. Из них только 60% приносят хоть какой-то доход.

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

Кажется, что успешный запуск продукта сводится всего к двум факторам: донести нужный продукт до нужных людей. Звучит просто. Но это далеко не так. 

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

Около 5 месяцев я был сотрудником одной очень крупной и известной ИТ-компании. Причём 2 месяца я проходил интервью, делал задания и решал тесты. В итоге я продержался совсем недолго. Со мной просто не продлили контракт. Это стало сюрпризом не только для меня, но и для HR-менеджера. Хотя претензий к моей работе за всё это время не было ни разу. Зато был опрос о прохождении онбординга. И я ответил честно.

Писать код — несложно, сложно писать хороший код.

Я всегда знала, что смогу найти работу. Предложений было множество, и что ещё важнее, требования работодателей не зашкаливали. Если ты умел выполнять sling для HTML или работать с командной строкой, рано или поздно находились желающие платить тебе зарплату.

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

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