Кто такой CTO

Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.

— Расскажи, как прошел свой путь от простого программиста до технического директора

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

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

Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.

За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.

— Чем занимается CTO?

С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.

Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.

В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.

Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.

— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?

Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.

Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.

А для больших компаний желание работать руками скорее будет минусом, чем плюсом.

#интервью #cto

— Какая зарплатная вилка у CTO сейчас?

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

— Как программисту стать управленцем?

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

Для начала сделай так, чтобы тебя не нужно было менеджерить — научись выполнять свои собственные обещания и разбираться в задачах. Покачай софтскиллы — пойми зачем в принципе одни люди приходят к другим людям. Вот классические книги, которые в этом помогут:
• Стивен Кови — 7 навыков высокоэффективных людей. Про принятие решений и обещания.
• Джим Кэмп — Сначала скажите «нет». Про то, как разговаривать с другими людьми, чтобы им было полезно.
• Элияху Голдратт — Цель и Критическая цепь. Как лучше разбираться в постановке задач и управлении проектами.

Когда научишься менеджерить себя, останется совсем немного до того, чтобы научиться менеджерить других.

— Как научился брать на себя ответственность? Как понял, что больше хочешь быть управленцем, чем программистом?

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

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

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

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

прочитайте статью «7 распространенных ошибок обработки исключений», чтобы лучше в этом разбираться:

https://habr.com/post/337536/

Что посмотреть на выходных — 11

Уроки по Android
https://www.youtube.com/playlist?list=PLvqW4wlh9oP7Joa2E4zUYHmGXN4DR-P8A

Интервью сооснователя QIWI
Бориса Кима
https://youtu.be/bAPl6gKNbWk

Принцип экономии мыслетоплива
https://youtu.be/fWR5SFhBUWc

#чтопосмотреть

Ситуация — вы в поиске работы. Характеристика, которая больше остальных повлияет на выбор компании:
anonymous poll

Есть профессиональный рост – 449
👍👍👍👍👍👍👍 72%

Есть амбициозные задачи – 57
👍 9%

Есть карьерный рост – 47
👍 8%

Можно запустить внутренний стартап – 22
▫️ 4%

Можно повлиять на развитие компании – 20
▫️ 3%

Можно выбрать команду при устройстве – 16
▫️ 3%

Можно поменять специализацию – 14
▫️ 2%

👥 625 people voted so far.

Плохо — Хорошо

Методы не должны принимать слишком много входных параметров

​​Плохо

​​Хорошо

Heisenbug 2018

6-7 декабря в Москве прошла конференция для тестировщиков Heisenbug. Публикую ссылки на доклады в Ютуб и их описание от @Zuevasasha78.

Барух Садогурский — "У нас DevOps. Давайте уволим всех тестировщиков".
Идею про Т-специалистов и о том что классическое тестирование будет перерождаться во что-то другое транслируют уже 3-ую конференциию подряд
https://youtu.be/4M55s_YqKc4?t=3540

Артём Ерошенко — "Нужно сделать рефакторинг кода? Есть Idea!"
Что-то в этом есть, но мало применимо для проектов, где меньше 300 тестов
https://youtu.be/4M55s_YqKc4?t=8010

Антон Усманский — "Особенности визуального тестирования интерфейсов".
Интересно, мне понравилось. Антон рассказывал, как устроена hermiona, инструмент для визуального тестирования. О его глубинных настройках и как они в компании боролись с антиалиасингом
https://youtu.be/4M55s_YqKc4?t=14280

Алексей Баранцев — "Заморочки в Selenium WebDriver".
Была на другом докладе. Но спикер один из разработчиков селениума и двигатель российского QA-сообщества, так что должно быть хорошо
https://youtu.be/4M55s_YqKc4?t=20584

Анатолий Пласковский — "Рецепты создания с нуля и развития системы нагрузочного тестирования"
Хорошо, но это на общие подходы. Конкретных инструментов нет
https://youtu.be/4M55s_YqKc4?t=25991

Wylsacom — "Epic fails производителей девайсов". Это дич.
https://youtu.be/4M55s_YqKc4?t=32594

#конфа

Токсичность

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

Так начинается статья с заголовком „Иди-ка ты на !@# со своей «токсичностью»“. Главная мысль статьи — сглаживание углов, псевдодружелюбность и отсутствие критики нахрен не нужны. Ведь без критики и вот этого всего мы не развиваемся как специалисты, а вместе с нами и вся IT-сфера.

Статья: habr.com/post/432700/

Критика — это комплимент

Кстати, у дизайнера Ильи Бирмана есть заметка про критику. Приведу две цитаты:

«Как нормальный человек поведет себя, когда прохожий скажет ему: „простите, у вас шнурок развязался“? Ответит „Спасибо“, завяжет шнурок, пойдет дальше. Если же он ответит: „Твое какое дело? Хочу с развязанным ходить и хожу!“, то в его вменяемости возникнут сомнения. А уж если он всерьез начнет рассуждать о том, что прохожий указывает ему на развязанный шнурок, не замечая всего богатства его внутреннего мира, то уже исчезнут практически все сомнения в невменяемости.

Вроде бы так естественно сказать „Спасибо“, когда тебе указывают на то, где ты налажал. Но для кучи людей это, почему-то, совсем не естественно; естественно для них послать подальше, сказав „Тебя не спросили!“. Почему люди так болезненно воспринимают критику — загадка. Адекватно реагировать на исправление или указание на ошибку — очень полезное в жизни умение. Как без него развиваться-то? Не скажу, что я в этом безупречен, но глядя на то, как реагируют многие другие люди, я понимаю, что могу быть собой вполне довольным»

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

Code conventions

Классы и методы должны быть небольшими и сфокусированы на одной вещи. Плюс в них не должно быть дублирования кода.

Например, Customer.java — это сущность, CustomerDao.java отвечает за работу с БД, в CustomerService.java сосредоточена вся бизнес-логика, а CustomerValidator.java нужен для валидации полей.

Clean code

Не создавайте переменные, которые не будут потом переиспользоваться

Плохо
boolean removed = myItems.remove(item);
return removed;

Хорошо
return myItems.remove(item);

Хорошо — Плохо

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

Плохо
List list;

Хорошо
List<User> users;

5 тысяч Джавистов

Всем привет! Количество подписчиков на канале перевалило за 5 тысяч, и это кайф. Кайф, что так много людей интересуются Джавой.

Для тех, кто недавно присоединился, меня зовут Зыбкин Дмитрий, я работаю в Москве Java-разработчиком с 2016 года. Канал создал в марте 2018-го для того, чтобы простым языком писать о программировании и начинающим девелоперам было где черпать мотивацию и материалы. Но в процессе это превратилось во что-то большее.

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

— трудоустройство: как поднять зп, как составить резюме, как писать сопроводительное письмо;
— продуктивность: как воспитать привычку, 10 правил эффективных встреч, 5 принципов хорошего программиста;
— обучение: как освоить SQL, GIT, 5 ошибок при изучении программирования;
и конечно стараюсь не забывать о самой Джаве.

Если каждая компания в вакансии пишет, что у них работают крутые профессионалы, тогда где же все криворукие говнокодеры трудятся?