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

В командах, особенно быстро растущих, конфликты — не редкость. И часто они возникают вовсе не из-за личных антипатий, а из-за размытой структуры полномочий.

Кажется, вот появился новый человек, чтобы помочь… но почему-то вместо облегчения становится только сложнее. Один руководитель — это порядок. Два — это борьба. Особенно если старый — «свой», а новый — новичок с инициативой.

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

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

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

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

Самое интересное — конфликт чаще всего можно предотвратить, но в ситуации, когда доверие отсутствует, этого не происходит.

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

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

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

Люди приходят работать в компанию, а уходят от руководителей.

Эту фразу сказал Роберт Саттон, автор книги "Искусство быть хорошим руководителем", и с ней трудно спорить. Культура компании, условия, проекты — всё это важно. Но решающим фактором часто становится конкретный человек, который управляет командой.

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

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

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

Разные компании, разные люди – но причины похожи.

Что делает тимлид? Руководит командой? Делегирует задачи? Пишет код? Отвечает перед заказчиком? В книгах всё чётко: тимлид — это лидер, вдохновляющий команду и ведущий её к успеху.

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

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

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

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

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

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

Это визуальная шпаргалка по Angular. Если нужно что-то вспомнить, то достаточно глянуть на нарисованную схему, вместо поиска этой информации в документации. Картинки не просто упрощают сложные вещи — они обогащают ваши воспоминания посредством ассоциативной памяти, позволяя вам уловить больше. Думаю, что эта публикация будет в первую очередь полезна тем, кто уже изучал Angular, но что-то забыл. Так же она должна быть полезна экспертам из схожих платформ разработки, если вдруг им придется столкнутся с Angular. И конечно же картинки помогут новичкам, послужив некой отправной точкой в изучении этой платформы.

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

Рисовал я все это в PowerPoint.

В публикации речь идет о warnings и vulnerabilities при установке библиотек с помощью yarn и о том, как от них избавиться. Я рассмотрел несколько случаев, приведенных ниже, но решения можно применять и к другим, схожим ситуациям:

Warnings типа:

has incorrect peer dependency

has unmet peer dependency

Vulnerabilities:

Prototype pollution in webpack loader-utils

loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS)

Crash in HeaderParser in dicer        

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

По сути в этой публикации речь пойдет о функции done() в jest. Функция очень полезная, так как позволяет разработчику решать в какой момент будет закончен тест. Бывают ситуации, когда это действительно очень нужно. В новом проекте я столкнулся с такой задачей и решил просто описать то, как я её решил.

RStudio, R Markdown, Latex и отчеты в PDF формате. Мой опыт.

Сегодня я хочу рассказать о том, как я писал отчеты на R, с чем сталкивался и как решал проблемы, которые возникали по ходу разработки. Отчеты были в формате PDF и запускались из Python в Camunda.

“И есть еще белые, белые дни, белые горы и белый лед.
Но все, что мне нужно - это несколько слов и место для шага вперед.”

(Виктор Цой)

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

"- Ну как на собеседование сходил? Успешно? - Да. Ручку у них спер" (ссылка)

Часть вопросов будет по typescript, часть по javascript, что-то будет из html, Node.js, настройки, библиотеки, концепции. В общем всё то, о чем говорят на собеседованиях.

“Не люблю темные стекла, сквозь них темное небо.
Дайте мне войти, откройте двери.”

(Виктор Цой)

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

Как мало пройдено дорог — как много сделано отчетов ©

Введение

Ведение