Кроме управления разработкой, я ещё пишу код. Под тегом «программирование» я выкладываю заметки связанные с разработкой ПО — пишу про технологии, фреймворки, тесты, железки и всё такое.
Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.
Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для домашнего проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта сейчас. Подумайте лучше о том, каким будет ваш фреймворк потом. Удержит ли он комьюнити в ближайшую пару лет? Успеет ли за быстроизменяющейся средой? Будет ли адекватным предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.
В этой заметке рассказываю об инструментах, которые использую для разработки и выступлений — с фоточками и списком оборудования.
Я использую MacBook Pro 14". Когда я работаю дома, ноутбук подключён к монитору LG UltraFine 4K прошлого поколения — кажется это единственный монитор с честной ретиной и нативным для мака DPI. Поколение монитора важно — подробнее см. обзор на «Вёрдже».
Я не использую два дисплея, поэтому ноутбук работает Clamshell mode. Единственное исключение — стримы: для них я открываю на ноутбуке Open Broadcaster Software.
Мой рабочий стол
В качестве органов управления я использую Happy Hacking Keyboard и Magic Trackpad. Мои пальцы не могут изогнуться, чтобы воспользоваться странной клавишей, которую засовывают в русских раскладках между левым шифтом и z, поэтому я всегда покупаю американские клавиатуры, вот — клавиатура ноутбука:
Монитор Apple Studio Display на кронштейне Ergotron LX Desk Monitor Arm
Клавиатура Happy Hacking Keyboard Pro Hybrid Type-S
Внешний тачпад Magic Trackpad 2
Веб-камера Razer Kiyo Pro
Микрофон Shure SM7B со штангой Blue Compass
Микрофонный предусилитель Art Tube PAC
Звуковая карта Focusrite Clarett+ 2Pre
Наушники Sony MDR-7506
Поскольку я работаю стоя, напишу пару слов про стол. Сначала я работал за обычным икеевским столом, собранным из самой дешёвой столешницы и регулируемых ножек, но в какой-то момент эта конструкция меня достала —из-за высоты стол сильно шатался. Задумав поменять стол, я посмотрел на рынок и сильно удивился — меньше, чем за 20 000 ₽ высокий стол не купить, причём даже самые дорогие экземпляры, судя по обзорам на ютубе, не отличаются надёжностью.
Большая стоимость обусловлена тем, что все высокие столы на рынке — регулируемые: у дешевых столешница поднимается вручную, у дорогих — с помощью электромоторов. Здраво рассудив, что регулировкой высоты я воспользуюсь ровно один раз — при установке стола — я просто пошёл на лайвмастер и заказал стол под свой рост. Получился красивый и надёжный предмет мебели (который до сих пор пахнет деревом!), по цене ниже икеи.
Софт
Я не люблю IDE, и в роли редактора кода использую neovim. Долгое время я сидел в Visual Studio Code, но конце 2021 года я устал бороться с увеличивающимся количеством скрепышей фич, плюнул и перешёл на neovim в терминале iTerm2:
Так выглядит экран во время разработки
Основные плагины:
coc для автодополнения, которое понимает язык (LSP)
fzf для быстрого открытия файлов
nerdcommenter, чтобы быстро комментировать куски кода
vim-vinegar, когда нужно походить по файловой системе
Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.
Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.
Права рута появились у каждого программиста, а сисадмины стали с умным видом делать гораздо меньше вещей.
Потом появился докер, и мы полностью абстрагировались от компьютеров — все крутится внутри легкого контейнера в абстрактном облаке. Самые прошаренные сисадмины стали девопсами, а у остальных осталось не так много дорог, отличных от условного электрика на заводе.
Если не хотите, чтобы в ближайшее время люди придумали абстракцию, которая вас заменит, остается два пути: или постоянно учить новое (и откладывать деньги на период, когда вы не сможете этого делать по физиологическим причинам), или учить софтскиллы, которые роботом пока не заменить: управление людьми, ответственность и результативность.
В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.
Почему-то внутри разработки такая практика обычно умирает. Какие бы странные задачи ни приходили, насколько бы очевидными упрощения в них ни были, программисты делают ровно то, что написано в требованиях. Это грустно, потому что часто программисты — самый большой центр затрат в компании. А что это за центр затрат, который не контролирует, куда он расходует ресурсы?
При этом программисты — прекрасные скептики: долгая работа с алгоритмами, которые описывают вещи из реального мира, приучает к критическому мышлению. Когда твои гениальные построения постоянно разбиваются о сложсочиненные системы в реальной жизни — скептиком становишься сам того не желая.
Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».
Начинающие программисты часто спрашивают в личке — как правильно выбирать технологии? Что учить, чтобы не отставать от прогресса? Это — плохой вопрос, учить надо вовсе не технологии.
Фреймворки, паттерны, методики разработки, языки программирования — это хард-скиллы. Навыки, которыми можно овладеть, просто изучив пару книг и немного попрактиковавшись. Если вы имеете за спиной базовые знания о том, как устроены инструменты программиста — вы легко приобретёте нужный хард-скилл в любом возрасте.
Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.
Когда умной компании нужно построить дом, она ищет не людей, которые умеют работать с молотком, а людей, которые умеют строить дома. Чем вы построите этот дом: шуруповёртом, подъёмным краном или нанятой командой монтажников — не так уж и важно. Важно ваше умение решать задачи, при необходимости включая в арсенал неизвестные инструменты.
Так что пофиг, на каком стеке технологий вы работаете — его всегда можно поменять. Важне ваше умение применять этот стек для решения прикладных задач. Так что просто берите что-нибудь популярное (кроме JS) — и фигачьте.
