В кандидатах на вакансии ИТ-компании часто ищут проактивность. Определения проактивного человека по интернету ходит два. С точки зрения психолога это человек, принявший ответственность за себя и свои решения и не ищущий причин событий в окружающем. Бизнес-консультанты немного его перефразировали в “желание контролировать события своей жизни и влиять на них”. Но что все это значит в конкретных ситуациях?
Разбираем на примере командной разработки в ИТ.

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

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

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

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

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

На одном из проектов мы столкнулись с формами из нескольких десятков блоков, которые зависят друг от друга. Как обычно, мы не можем рассказать о задаче в деталях из-за NDA, но попробуем описать свой опыт “укрощения” производительности этих форм на абстрактном (даже немного не жизненном) примере. Расскажу, какие выводы мы сделали из проекта на React с Final-form.


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

Я недавно стал тимлидом на одном из проектов нашей компании.

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

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

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

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

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

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

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


(Григорий Остер)

Поговорим о том, о каких разработчиках мечтает руководство. В этот раз я выступлю в роли абстрактного управленца…

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

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

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

Что ж, поговорим о том, как “правильно” взаимодействовать с разработчиком, например лично со мной…


(Если всей семьей купаться вы отправились к реке,
не мешайте папе с мамой загорать на берегу.
Не устраивайте крика, дайте взрослым отдохнуть.
Ни к кому не приставая, постарайтесь утонуть, — Григорий Остер)...

Тимлиды часто оценивают проекты, и не все делают это хорошо. Тут многое зависит от личности самого тимлида, а также от его понимания команды. Есть много техник оценки проектов от метода “по аналогии” до PERT. Но сегодня я расскажу о том, как я применяю planning poker и другие приемы, чтобы оценивать точнее и с большей пользой.

Говоря о помехах работе, обычно подразумевают посторонние звуки и влияние коллег. Но в моем понимании понятие “помехозащищенности” шире. Это способность работать над текущей задачей, не отвлекаясь на что-то другое.

Сегодня поговорим о том, почему это важно и как этого достичь.

(The Isolator, 1925)

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

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

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



Под катом — о том, так ли все страшно, глазами специалистов из “Максилекта”, уже проходивших через аналогичный выбор.

В этой статье мы решили немного раскрыть внутреннюю кухню. В удаленной команде один из главных элементов — коммуникации. Расскажем, как это у нас организовано, — с целевыми параметрами (SLO) и конкретикой.

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

В этой статье я поделюсь своим мнением, почему стоит идти именно по этому пути и что будет, если в автоматизацию прийти иначе.