«Плохо написанный код – не всегда проблема». 28 мудростей от программиста-блогера Димы Малеева

1. Мы вообще не производим инновации

Инновации до нас сделали ребята в университетах, а мы просто используем то, что они создали. Это так не всегда, но в большинстве случаев. Большинство всего айти — это как играть в карты: найти самую эффективную комбинацию человек-позиция.

2. IT в каждой стране разное. И очень зависит от того, какая направленность айти в стране

К примеру — в Украине аутсорс — и здесь можно найти крутых специалистов по одной технологии, реже — двум. Средний программист на Python у нас — на голову круче, чем средний дев в США, но дев в США будет крутить билды, фиксировать руби и е*аться с конфигурациями «Амазона» по вайтлистенингу.

3. Отсюда и совершенно разные собеседования

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

4. Архитектор как позиция вообще не нужна

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

5. Аутсорс для программиста — путь в никуда

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

6. Токсичные эксперты — дороже по времени и головной боли, чем команда айтишников

Если ты зайдешь в митинг рум, а там два стула: один из норм программист с превосходной эмпатией, а на другом суперэксперт, но мудак — работай с нормальным программистом.

7. Х10-программист — это миф, о котором сказали на какой-то конференции

Любой х10-программист начинает выгорать через 2 месяца, но что неинтересно, и не знает, что делать дальше. Программирование, как и жизнь, — это марафон, а не спринт.

8. Зачастую программисты решают инженерную задачу, не думая, что они работают на бизнес

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

9. Я всегда думал, что работа менеджера — это легко по сравнению с программированием

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

10. Интервью должно быть сложным.

Если делать интервью простым, люди очень часто мигрируют по компаниям. Если оно сложно — люди будут думать: «да я не хочу готовиться за +500 к этой ***».

11. Продуктовое мышление и проектное мышление — это две максимально разные идеи

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

12. Продуктовая разработка в разы более интересна, чем проектная. Но проектная гораздо более разнообразна

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

13. Надо читать старые книги по тому, как делать продукты или проекты

Технологии изменились, а методы нет, а люди тем более. Новые книги очень часто покрыты каким-то культом карго: мы так делаем, потому что Нетфликс так делает. В старых книгах аргументация: мы так поступаем, потому что программиста может сбить автобус. И вроде бы сразу поняли риски, и почему оно так решается.

14. Мои любимые интервью — system design

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

15. Индусы ну очень крутые программисты

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

16. Код чаще читают, чем пишут. Просто подумайте об этом.

17. В жизни все циклично, и мода в айте тоже

На самом деле многое в айте — культ карго. К примеру микросервисы. Когда-то вышел Нетфликс и сказал, что это за***сь. И все начали делать микро- и даже наносервисы. А потом оказалось, что во многих случаях это не нужно. Ибо ваш стартап не «Нетфликс». Гораздо лучше и дешевле сделать все в монолите, посмотреть, кому это нужно, вместо того, чтобы мучиться с CI/CD, потому что у вас на метод по сервису. Еще стоит много. И вместо того, чтобы проверить продукт, вы делаете космолит. Без космоса.

18. Знания джунов по политеху, УКУ и курсам фронтенд за 3 месяца разные в первые пол года

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

19. Академическое образование CS в Украине переоценено

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

20. Зарплата — это на*бка

На самом деле, если вы работаете за часть компании (как в Штатах с акциями), то вы можете заработать в разы больше. Я видел десятки программистов миллионеров в Калифорнии, и не видел ни одного программиста-миллионера, который остался бы просто программистом.

21. Матрицы компетенции — тоже на*бка

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

22. Плохо написанный код — не всегда проблема

С модой — любой код, который написали — в какой-то момент станет плохо написанным. Но если он работает — нужно ли его переписывать? У меня было много проектов, где в какой-то кусок кода не возвращались десятки лет. И он был страшен как Сара Джессика Паркер, но делал свою работу, зарабатывал деньги, и не ломался. Поэтому нужно ли его переписывать, даже как технический долг, это вопрос на миллион.

23. Почему-то айтишники очень привязаны к технологиям

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

24. В моей практике я встречал только два типа менеджеров.

Менеджер-эксель (это плохо), для которого люди — это просто строчка в табличке экселя, и все, что его волнует — чтобы инвойс генерился. Это менеджеры, которые называют людей ресурсами.

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

25. Наверное, самая большая проблема, когда нанимаешь аутсорс-партнера, — именно программисты

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

Иногда оно не облегчит таск, но всегда, делая такую таску, ты будешь понимать, что она будет использована живым человеком, и сделает чью-то жизнь легче. Это мотивирует.

28. Если вы не получаете удовольствия именно от программирования, то лучше выберите что-то другое.

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

Если в программисты — то только так.

«Очень много вещей и в армии нуждаются в программистах. Мы нескоро потеряем работу». Исповедь мобилизованного разработчика об обучении, еде, настроении и ценностях в ВСУ

По теме

«Очень много вещей и в армии нуждаются в программистах. Мы нескоро потеряем работу». Исповедь мобилизованного разработчика об обучении, еде, настроении и ценностях в ВСУ

200 девушек из Украины могут получить стипендии от эстонской школы-программирования

По теме

200 девушек из Украины могут получить стипендии от эстонской школы-программирования

В украинских школах обновят преподавание и программу предмета «Информатика». Уже ищут преподавателе

По теме

В украинских школах обновят преподавание и программу предмета «Информатика». Уже ищут преподавателе