«Код чаще читают, чем пишут» и еще 27 ІТ-мудростей от Димы Малеева

Читать на UA

Украинский программист и блогер Дима Малеев, живущий в Калифорнии, в честь 16 лет опыта работы в ІТ поделился в Twitter-треде важными наблюдениями и выводами, которые он сделал за эти годы. AIN.UA собрал все в одном материале.

Дима Малеев, Facebook

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. Наверное, самая большая проблема, когда нанимаешь аутсорс-партнера – именно программисты. Программисты в аутсорсе очень часто не понимают, что цель – не закрыть джира-таск, а сделать то, что нужно. К примеру, в трех последних компаниях, где я работал, совсем не было тестировщиков. Все, все покрывалось тестами, и это были успешные проекты. В аутсорсе программисты часто ожидают, что они напишут базовый код, а затем тестировщик напильником пройдется, чтобы посмотреть, где пацаны не обосрались. Иногда лучше дольше делать таск, чем трижды мучаться с багом.

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

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

Оставить комментарий

Комментарии | 0

Поиск