15 самых полезных навыков для работы в IT

Python, Docker, Spring Boot, k8s, Scrum, Gantt, Kano? Нет. Ничего этого в списке не будет

03 Nov 2022


Этот пост я написала в рамках блогомарафона в ответ на тему “Топ-5 необходимых навыков в моем домене”.

Список у меня получился подлиннее, чем 5 навыков. Но если хочется короткий, то такой тоже составила: дистиллированный топ-5.

Комментарии можно писать в ТГ: https://t.me/WritingOnStickyNotes/89

...

Знакомимся

Я работаю в IT, много лет. Занималась бэкенд-разработкой веб-сервисов, эксплуатацией веб-сервисов и БД, реагированием на инциденты, управлением командами, проектами и даже немного внутренними продуктами.

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

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

Навыки, таблица

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

Плюсик означает особенную пользу этого навыка для этой деятельности, два плюсика – особенно-особенную пользу (sine qua non, так сказать).

Ниже таблицы есть описания, а потом и выбор пяти самых-самых полезных навыков.

Навык Разработка Эксплуатация Инциденты Команды Проекты Продукты
Программировать (заставлять программу делать нужное) ++ +        
Работать с командной строкой + ++ + + + +
Производить диагностику   ++ +      
Быть летучей мышью   ++ +      
Визуализировать + + + ++ ++ ++
Понимать систему, с которой работаешь + ++ ++ + + +
Разворачивать односвязный список +          
Принимать невозможное ++ + ++      
Ставить решение проблемы выше своего Эго     ++ + +  
Уживаться с ситуацией “оно не работает” ++ +        
Радоваться результатам + + + + + +
Иметь план Б   ++ ++   +  
Постепенность ++   +   ++ ++
Задавать вопросы ++ ++ ++ + + +
Сочувствовать пользователям   + +     ++
             

Навыки, описания

(^) Программировать, то есть уметь написать какой-то программный код и добиться, чтобы он делал то, что задумано.

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

(^) Работать с командной строкой.

Во-первых, командная строка дает власть над текстом. Если у тебя в руках инструменты командной строки, ты можешь сделать с текстом все. А текст везде: программный код, конфиги, логи, тикеты, резюме встреч, электронная почта, история чатов, html, postscript, svg и fb2. И если умеешь grep, sed, curl, jq, то посчитаешь статистику, внесешь массовые правки, найдешь информацию по хитрым условиям, и все это на лету, просто и быстро.

В-вторых, командная строка дает возможность быстро собрать массовую обработку вообще любых объектов. Отрезать по 5 писелей с каждой стороне на сотне фоток, порестартить базу данных на десятке серверов, вытащить текст из горы pdf-ок – все это тоже можно сделать ad-hoc, быстро, без тяжеловесного программирования.

(^) Производить диагностику: владеть инструментами для просмотра состяния системы, с которой работаешь. Понимать, что они показывают.

См. также понимать систему и “летучемышность”.

(^) “Быть как летучая мышь”: когда работаешь с сервисами и серверами – на них не получится “просто посмотреть”, как мы смотрим глазами. Надо переключаться в режим “эхолокации”: выпустил команду для диагностики, посмотрел на результат, включил в картину мира, выпустил следующую команду, и так далее.

См. также понимать систему и “производить диагностику”.

(^) Визуализировать: составлять схемы и диаграммы, типичные и кастомные.

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

(^) Понимать свою систему: не просто уметь очередное заклинание, а понимать, почему оно работает, почему перестало и какое новое нужно.

Система у каждого своя: у администратора – серверы и сервисы, у скрам-мастера – команда.

(^) Разворачивать односвязный список: это холиварный вопрос, и мое мнение – списки стоит понимать и уметь развернуть список тоже стоит. Это не страшно.

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

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

(^) Ставить решение проблемы выше своего Я. Когда твой сервис ломается, команда лажает, проект отстает от графика, легко попасть в ловушку самоедства “какой я лажовый лузер, что я тут вообще делаю” или отрицания “нет, с моим сервисом/командой/проектом все хорошо, это вокруг какие-то неправильные обстоятельства”. Ни то ни другое не помогает решить проблему, причем самоедство может быть даже хуже отрицания.

Надо уметь выключать эмоции “я плохой”/”они плохие”/”я ошибся”/”они ошиблись”, и сосредотачиваться на “что надо сделать, чтобы улучшить ситуацию”.

(^) Уживаться с ситуацией “не работает” и разбираться с нею. Написать сколь-нибудь сложную программу или настроить сколь-нибудь интересную систему с первого раза не получится. Надо обжиться в условиях “оно не делает что надо”, воспринимать их как обыкновенные и продолжать работать: смотреть как именно не работает, делать выводы, делить “работает” на кусочки и добиваться правильного поведения постепенно.

См. таже постепенность.

(^) Замечать результаты и радоваться им: иногда (часто) может показаться, что вся работа состоит только из “не работает”, “ломается”, “тормозит” и “падает”. Это не так.

(^) Всегда иметь “План Б”: все, что никак не может пойти не так, будет идти не так с угрожающим темпом. Нужны планы, запасные планы, запасные планы к запасным планам, запасные планы к запасным планам к запасным планам. Цитата из одной презентации: План B, C, D, ξ, ℵ0

(^) Компромиссы и постепенность: не пытаться сделать/получить все сразу. Делить на этапы. Делать самое важное сначала, и начинать извлекать пользу из сделанного, когда еще далеко не все готово.

По-английски есть красивое слово incrementalism.

(^) Задавать вопросы: с одной стороны – быть OK с тем, что чего-то не знаешь; с другой – интересоваться тем, что происходит в головах других людей.

Для технических спецов мне кажется важнее первое, для управленцев – второе.

(^) Сочувствие к пользователям: пользователи доверяют твоему сервису и зависят от него; хорошо помнить про это.

И самые-самые полезные

А если все-таки выбрать топ-5?

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

А глобальный топ универсально-полезных скиллов у меня получается такой:

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

Удачи!

И пишите свои соображения: https://t.me/WritingOnStickyNotes/89