
Типичный программист
Заметки программиста
Здравствуйте, я Кони, и я программист самоучка.
Предался я тут воспоминаниям, как я начинал свой путь, и хочу поделиться этим с вами.
Какова цель? Да не знаю, просто исповедаться. Может новички прочитают, поржут, что у них все не так уж и плохо.
Начал я прогать весьма внезапно. Всегда думал, что этому должен обязательно кто-то научить. Как учат естественные языки, так вот и должен быть человек, который научит меня этому таинственному языку машин.
При чем вот те школьные уроки казались чем-то далёким от реального программирования, типа: ну и чё, да я вот на паскале сделал калькулятор, а как колдовать то, я игры вообще-то делать хочу.
С такими мыслями я и поступил в ВУЗ, но внезапно выяснилось, что в программе у сетевиков нет программирования. А если ты вписывался в какие-то проекты, то ты уже априори должен все уметь.
Я не особо унывал, ведь теплилась надежда, вот у нас на втором курсе будет распределение, я пройду на ИБ, и вот тогда-то меня точно всему научат.
Но тут начался ковид с удаленкой, а это значит что? Наконец можно спать, а не драпать к 9 на пары. Так прошло две недели, а потом ВУЗ выпустил нерф - теперь в начале каждой пары требовалось заходить в ЛК и тыкать кнопочку, типа ты на паре. Я стал гуглить, может быть есть какие-то умные кликеры, чтобы вот сами все нажимали. По итогу набрёл на гайды какого-то деда по selenium на шарпе, и пошло поехало. Следующие пол года я дорабатывал эту несчастную прожку на сотню строк, постепенно изучая как оно работает. Загрузил туда и расписание пар, и список входников одногруппников, чтобы их тоже отмечало.
Тут то я и преисполнился, вот я - настоящий программист, я умею. Начал делать лабы соседям за денюжку, сам копаться в разных приколах, пробовать игровые движки. Правда возвращаясь к старым проектам даже через пару месяцев хотелось выколоть себе глаза, от того прекрасного кода.
Однажды с другом взялись писать клиент-серверную приложуху. По отдельности все просто, да и tcp соединение прокинуть 5 минут гугления. А вот как в нем нормально передавать информацию мы не знали. Текст пихаешь, и оно передается, но это же надо ещё структурировать. Да, мы не знали про json, да, головы у нас чтобы кушать. Короче, придумали мы ПОГ - протокол орочьей грамоты.
Мы уже тогда понимали, что делаем хрень, оттуда и название, но раз начали, надо делать. По сути, структура была проста: имя запроса|переменная 1|переменная 2|и т.д.
Самое забавное, что даже спустя 3 года, и узнав дохренища нового, мы всё ещё используем ПОГ: в телеграмм ботах на колбеках кнопок висит жесткое ограничение на символы, при этом нет требований к сложным струтурам, и ПОГ оказался в этом плане наиболее оптимальным.
Когда требовалось хранить какую-то информацию, какие БДшки, это ж че-то для веба, вы о чем, есть же текстовые файлики. Однажды я даже в качестве такого хранилища использовал excel доки. Не спрашивайте, просто примите, что я одаренный.
С другой стороны, все эти изыскания подарили мне прекрасные навыки обработки текстов, я теперь моментально нахожу опорные точки для парсинга, и придумываю как это все можно оптимизировать.
Тут не будет концовки, про то что я теперь зарабатываю 100 тыщ мильёнов в наносекунду.
На самом деле, до сих пор, даже пройдя несколько курсов, прочитав тонну статей и уроков, написав несколько коммерческих проектов, меня не покидает ощущение, что я всё ещё пишу на той самой орочьей грамоте. По иронии, я работаю в командах, где либо я самый шарящий за код, либо люди на том же уровне и нет тех, кто указал бы на явные косяки.
Но я до сих пор получаю кайф от этого занятия, я всё ещё не потерял того вдохновения: "я могу, я творец". Так что всё ещё впереди.
Грейды в IT: можно ли стать CTO в 24 года?
Можно ли стать техническим директором в 24 года? Этот вопрос заставляет задуматься, особенно если учесть, что IT — одна из немногих отраслей, где отсутствуют чёткие стандарты для определения квалификации. Здесь всё зависит от компании: кто-то считает мидлом человека с годом опыта, а кто-то требует от сеньора не только глубоких знаний, но и лидерских качеств.
Проблема грейдов в IT
За время работы в IT я провёл сотни собеседований. И вот на что я всё чаще обращаю внимание. В отличие от таких областей, как медицина, авиация или юриспруденция, в сфере информационных технологий нет универсальных стандартов. Врач, чтобы оперировать, обязан пройти многолетнее обучение и подтвердить свою квалификацию. Пилот не станет командиром самолёта, пока не налетает определённое количество часов. В IT же любой может назвать себя мидлом или даже сеньором — и это никем не регулируется.
Часто кандидаты включают в резюме навыки, которыми не обладают, и технологии, с которыми они почти не работали. Например, на «индийский манер» перечисляют всё, что когда-либо слышали: «встретил учебник по Go — значит, я Go-программист». На мой взгляд, это серьёзная проблема.
Честность или амбиции
Лично я с большим энтузиазмом встречу человека, который честно признаёт: «Я джун, но лучший джун, которого вы когда-либо видели». Ведь дело не в том, какой грейд ты себе присвоили, а в том, как ты можешь подтвердить свои слова делом. Но сейчас другая тенденция: год карьеры — уже мидл, два года — сеньор.
Недавно в сообществе менторов мы обсуждали резюме молодого человека 2000 года рождения, который претендует на роль CTO. Технический директор в 24 года? Для меня звучит сомнительно, если только это не Chief Toy Officer.
В ходе дискуссии возник вопрос: а можно ли за одно собеседование понять, готов ли человек к такой роли? Нет, нельзя! Именно поэтому компании выстраивают многоступенчатый процесс отбора. Важно оценить не только знания, но и то, как человек мыслит, принимает решения и работает с командами. Высококвалифицированного профессионала отличает не столько объём знаний, сколько мировоззрение, которое накладывается поверх этих знаний.
Что отличает CTO от линейного специалиста?
CTO — это не просто опытный разработчик. CTO видит проблему целиком: задаётся вопросом, почему она возникла, думает о её последствиях и учитывает риски. Разница между линейным специалистом и лидером — в мировоззрении.
Простой пример. Зададим специалисту вопрос: «Какую базу данных выбрать для системы с отложенной доставкой сообщений?».
Ответ может многое сказать:
- Джун предложит готовое решение, даже не вникая в контекст;
- Мидл уточнит детали и назовёт несколько вариантов;
- Сеньор задаст дополнительные вопросы: каковы требования? Объёмы данных? Риски?
Но CTO пойдёт дальше. Он задумается, зачем вообще появилась такая задача, как она влияет на бизнес, и постарается учесть все зависимости. Мировоззрение CTO — это не объём знаний, а способность объединить их в единую систему.
Нужны ли стандарты для IT?
В авиации есть стандарт: часы налёта для каждого уровня. Это объективный критерий. IT-индустрии тоже нужны подобные инструменты, чтобы определить, кто действительно готов быть мидлом, сеньором или CTO. Ведь даже если ты гений технологий, стать CTO в 24 года — это не вопрос навыков, а вопрос опыта.
Подписывайтесь на мой телеграм-канал — там я делюсь инсайтами из мира IT, размышлениями о кадровых проблемах, кейсами и советами по развитию компетенций для IT-специалистов и менеджеров.
Онлайн-культура на удалёнке: как сделать созвоны распределённых команд эффективнее
За последние 10–15 лет формат работы IT-команд сильно изменился. Когда я только начинал заниматься разработкой, российские компании были более консервативны, традиционно все сотрудники ежедневно собирались в офисе, а удалёнка была исключением из правил, в то время как международных организациях этот формат был гораздо более распространён — причём не только среди айтишников.
В России тенденция перехода на удалённую работу получила значительный импульс только во время карантина, связанного с пандемией коронавируса. Тогда даже тем организациям, которые резко негативно относились к удалёнке, пришлось перевести значительную часть своих сотрудников на дистанционный формат работы. После снятия ограничений многие команды так и остались распределёнными. На рынок труда стали выходить соискатели, которые в принципе никогда не работали в офисе.
Есть база, которая определяет культуру общения распределённых команд.
1. Включайте камеру. На встрече, в которой участвует до 15 человек, камеры должны быть включены у всех. За тысячи лет эволюции человек научился считывать невербальные сигналы собеседника. Камера может быть выключена, если у человека есть весомая причина или формат встречи предполагает, что один участник выступает с презентацией, а другие его только слушают.
2. Соблюдайте тайминг. Этого правила я придерживаюсь не только в онлайн-, но и в офлайн-встречах. Встреча должна быть зафиксирована в календаре, начинаться и заканчиваться ровно в то время, которое обозначили изначально. Если вы опаздываете на созвон, никто не должен вас ждать. После подключения не прерывайте говорящего и не просите повторить то, что было сказано до вас.
Когда отведённое на встречу время истекло, не стоит задерживаться, если у вас стоит следующая встреча, каскадное опоздание — это огромная боль.
Если у вас нет других планов после созвона, конечно, вы можете задержаться с коллегами.
3. Выключайте микрофон, если на встрече присутствуют больше 3 человек. Включайте его только тогда, когда говорите. Прежде чем говорить, поднимите руку, в большинстве сервисов есть волшебная кнопка, в конце концов обозначьте желание высказаться в камеру. Галдёж и гомон не способствуют конструктивному диалогу, к тому же, не стоит забывать про возможные проблемы со связью.
4. Не отвлекайтесь на посторонние вещи. Если вы пьёте, едите или курите во время созвона, вы очень явно демонстрируете, насколько вам неважна встреча. У тебя обед? Не принимай участие во встрече или смести обед, в конце концов, забронируй себе слот в календаре.
Какая разница, если работа делается — главная ошибка руководителя. Лидер таких ошибок не допускает.
Подписывайтесь на мой телеграм-канал. Там я делюсь инсайтами из мира IT, размышлениями о кадровых проблемах, кейсами и советами по развитию компетенций для IT-специалистов и менеджеров. Никакого информационного шума: говорю только о том, в чём разбираюсь и что хорошо обдумал. Не стесняюсь критиковать привычные методы работы и управления — и вы не стесняйтесь.
Помните своего тамагочи?
Если не помните или у вас его не было, то вы где-то потеряли кусочек сердца… но все можно исправить. С тамагочи можно поиграть прямо сейчас.