50 вещей, которые я хотел бы знать на своей первой работе в качестве разработчика. Часть 2.

Перевод статьи «50 Things I Wish I’d Known at My First Developer Job (Part 2)».

Первую часть читайте здесь.

50 вещей, которые я хотел бы сказать себе в прошлом

26. Соответствие культуре опасно

Соответствие культуре может быть одной из самых опасных идей любой процедуры найма.

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

Идея подбора людей по степени соответствия культуре это, пожалуй, самый эффективный метод создания монокультуры. Если я стараюсь следить за тем, чтобы каждый отдельный человек соответствовал команде, я методично исключаю из нее всех людей, обладающих другим бэкграундом. Соответствие культуре это враг разнообразия.

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

27. Языки программирования не делают вас умнее

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

Я думал, что программисты, пишущие на Rust и Go, занимают самые топовые позиции в индустрии, а люди, пишущие на PHP, вероятно, застряли в этом языке и страдают от этого.

Это токсичные и ошибочные установки.

Люди используют те инструменты, которые работают, а сами эти инструменты не служат показателями ума или способностей. Есть программисты мирового класса, пишущие на PHP, Java и всякого рода других «нежелательных» языках.

28. Фреймворки отличаются гибкостью

На своей первой работе я попал в команду Ruby-on-Rails. Пока я учился, я воспринимал Rails как закон, как нечто, высеченное на камне.

Мне потребовалось много времени, чтобы осознать: фреймворк это просто код. А код можно изменить или даже обойти, если это необходимо.

Если бы я раньше понял, что фреймворки это нечто гибкое, я бы, может, намного раньше стал контрибутором Rails.

29. Ваш стек это не самое важное решение

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

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

30. Ваша сеть знакомств это ваш самый ценный актив

Сеть знакомств

Важно не то, что вы знаете, важно то, кого вы знаете. Это правда.

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

31. Вы ценный сотрудник

На своей первой работе я все время думал, что меня в любой момент могут запросто заменить.

На самом деле на рынке труда вы являетесь очень ценным кадром уже благодаря вашему умению создавать базовый UI при помощи HTML/CSS и вкраплений JavaScript.

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

32. Разработка программного обеспечения требует времени

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

Учитесь оценивать время и силы. И обязательно учитывайте закон Хофштадтера:

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера».

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

33. Ваше умение решать проблемы со временем возрастет

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

Но это пройдет.

Когда я начинал, меня очень беспокоило то, что я так плохо себя чувствую после работы. Я приходил домой в 5-30 и проваливался в сон на 12 часов. Я думал, что вся моя дальнейшая карьера будет просто чередованием сна и работы, до самой смерти.

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

Усталость

34. Whiteboarding токсичен

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

Менеджеры! Не заставляйте людей проходить через это!

Кандидаты! Отказывайтесь писать код на белой доске!

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

35. Написание плохого кода не делает вас тупицей

Когда мне случалось написать плохой код, я чувствовал себя очень плохо.

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

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

Помните: всегда следует исходить из того, что окружающие действуют из лучших побуждений.

36. Оставляйте какое-то время для себя

Сам я по-прежнему испытываю с этим сложности, но тем очевиднее эта проблема.

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

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

Не нужно работать по 90 часов в неделю в надежде, что это сделает вас более продуктивным. Могу судить по своему опыту: не сделает.

37. Читайте художественную литературу

Это идет рука об руку с резервированием времени для себя.

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

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

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

Чтение

38. Слушайте активно

Если вы еще не знакомы с идеей активного слушания, самое время познакомиться.

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

Кстати, сделайте себе одолжение и почитайте книгу «Как завоёвывать друзей и оказывать влияние на людей». Пригодится.

39. Ваше мнение имеет значение

Когда я был начинающим разработчиком, я был уверен, что мое мнение — наименее важное.

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

40. Тайтл сеньора это еще не все

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

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

Если бы я мог вернуться в прошлое, я бы посоветовал себе притормозить и использовать время в начале карьеры для учебы. А тайтл сеньора в будущем никуда не убежит.

41. В медленном усвоении информации нет ничего плохого

Я вообще учусь быстро (хотя по сравнению со многими, может, и медленно), но всегда переживал, чтобы люди не сочли, будто я слишком медленно усваиваю информацию.

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

42. Разработка программ требует выносливости

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

Для построения карьеры в сфере разработки нужно много времени. Умение сохранять трудоспособность в течение длительного периода времени в сфере разработки более важно, чем короткие вспышки активности.

Именно поэтому я не люблю термин «спринт».

Москва не сразу строилась.

Выносливость

43. Разработка программ это командный спорт

Фольклор из сферы разработки убеждает нас, что разработчики-одиночки создают отличное программное обеспечение. Мы постоянно слышим такие имена как Лавлейс, Возняк, Торвальдс, Тьюринг и Хоппер. Мы верим, что эти люди создали потрясающие вещи, но забываем обо всех тех, кто поддерживал их при создании этих проектов.

Все выдающиеся программы созданы командами людей, явно или неявно.

Когда я начинал программировать, я мечтал о Геркулесовых подвигах. Если бы я только мог уйти на недельку и вернуться с сотнями и тысячами гениальных строк кода… К сожалению для моего эго, так это не работает.

Построить Москву самостоятельно тоже нельзя.

44. Используйте свои любимые инструменты

Мало что так будоражит разработчиков, как тема инструментария.

Найдите какие-нибудь старые ветки форумов об Emacs и Vim или вступите в дискуссию относительно языков программирования. Вы быстро поймете, что разработчики отнюдь не безразлично относятся к своим инструментам.

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

Когда я понял, что мне нравится Emacs, я начал куда тщательнее изучать все, что касается моего рабочего окружения. Простая увлеченность инструментом очень способствовала моему профессиональному росту.

45. Используйте инструменты, которыми пользуется ваша команда

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

46. Оболочка — ваш лучший друг

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

Чтобы привыкнуть к работе в оболочке, у меня ушло много времени, но когда я с этим справился, я стал чувствовать большую близость с моей машиной. Это помогло мне понять свою ОС. Вместо того чтобы ограничиваться графическими интерфейсами инструментов, я чувствовал, что работаю бок о бок со своей машиной.

47. Гуглить это нормально

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

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

Гуглить это нормально

48. Сеньоры не всегда правы и они не все знают

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

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

49. Самый громкий человек в комнате не всегда прав

У людей, занятых в нашей индустрии, есть вредная привычка доверять ярким, выделяющимся но общем фоне личностям. Мне это очень помогло в карьере, поскольку, как однажды заметил мой товарищ, я довольно напыщенный человек.

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

50. Разнообразие идет на пользу всем

Я всегда заботился о разнообразии, но не видел его реальных преимуществ, пока не начал работать в Open Source.

Разношерстная группа людей принимает лучшие решения, чем однородная, причем всегда.

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

1 комментарий к “50 вещей, которые я хотел бы знать на своей первой работе в качестве разработчика. Часть 2.”

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх