Как стать успешным программистом

1656645025 kak stat uspeshnym programmistom

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

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

1*czBnulToEp24YNhjnTTrqQ
Лучший совет по карьере и жизни, которую я получал

Короче говоря, мой лучший совет:

  • Недообещанный, перевыполненный
  • Идеальное – враг хорошего
  • Оставайтесь на пути
  • Заранее собирайте отзывы
  • Ищите, прежде чем спрашивать
  • Оптимизируйте для простоты

Если вы предпочитаете смотреть это в видеоформате, я сделал здесь видео на Youtube:

Недообещанный, перевыполненный

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

Если вы посмотрите на количество проектов, превышающих бюджет и/или выполняемых с опозданием, вы будете очень удивлены. Это сумасшедшая цифра, примерно 50%.

Давайте подумаем об этом на секунду: 50% всех проектов либо превышают бюджет, либо выполняются с опозданием.

Это означает, что из каждой 1000 проектов 500 или половина из них выполняются с опозданием или превышают расчетный бюджет. Меня это просто озадачило.

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

Будучи нетерпеливым, молодым инженером, каким я был, я сильно недооценен количество времени, необходимого выполнения задач. Что-то в размере 2-3 раза.

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

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

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

Достоинства:

  1. Дает вам достаточно времени для развития и рефакторинг при необходимости. Разработка функций – это всегда удачное время, чтобы вернуться назад и исправить некоторые технические долги, которые вы (или ваша команда к вам) накопили за эти годы.
  2. Дает время выяснить самый лучший дизайн, а не просто рабочий дизайн.
  3. Есть много вещей, которые могут пойти не столько при разработке функции. Коллега уходит в отпуск, вы болеете, встречи, ваш ребенок болеет, ваша машина сбивается, и список можно продолжать. Важно отдавать себе отчет, что все может пойти не так, и вы хотите убедиться, что в вашем расписании есть буфер.
  4. Способность постоянно выполнять высококачественную работу в результате выполнения задания №2 и способность каждый раз выполнять работу вовремя благодаря выполнению задания №3 теперь вас признают высокопроизводительный в компании кто знает, о чем вы говорите, и на него можно положиться. Беспроигрышный!

Вы можете возразить, что недостатком недообещаний является то, что другие сочтут, что вы ленивы, оценивая 10 недель работы над тем, что можно сделать за 2 недели.

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

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

Идеальное – враг хорошего

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

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

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

Если это звучит вам знакомо, то вы не одиноки.

Это случается со всеми – и это случается с лучшими из нас. Я считаю, что с детства нас приучают к работе «идеальный» или «полный». Однако в действительности идеального решения не существует.

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

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

Например, как специальность информатики, что вы должны сделать, чтобы получить первую работу после окончания колледжа? Кроме работы в стартапе или крупной технологической компании, вы также можете работать за границей как фрилансер, открыть канал на Youtube, выкладывать информатику на Udemy, создать блог или создать собственную компанию. Список вариантов неограничен, и решение, которое вы примете сегодня, будет основываться на нескольких ключевых критериях.

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

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

1*2F4wBkVOMWshNP7qVFJJMg
Вероятность неудачи

Я думаю об этом так: я назначаю вероятность худшего сценария и использую это для своего процесса принятия решений. Об этом я узнал из книги Рэя Далио «Принципы», которая является прекрасной книгой, которую я очень рекомендую.

Если вероятность того, что что-то пойдет ужасно не так, статистически значима, я:

  1. Ищите лучшее решение или
  2. Найдите способы снизить риски, чтобы они больше не были статистически значимыми.

Когда решение принято, я его выполняю и иду дальше.

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

1*haY65XZWvENvnYaLwHQHLQ
Структура принятия решений

Оставайтесь на пути

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

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

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

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

Преимущества двойные:

  1. Это уменьшает скольжение функций и заставляет вас сосредоточиться. Об этом написаны тома книг, и я не буду утомлять вас конкретными подробностями. Независимо от вашей позиции, важно оставаться в фокусе лазера.
  2. Мы люди люблю мгновенное удовольствие. Если вы можете выпустить что-то через 2 недели, то сделайте это! Заранее спланируйте, чего ваш проект сможет достичь через 2 недели, а затем отдайте его пользователям! Это очень приятное ощущение, и даже если оно испытывает полную неудачу, по крайней мере вы придерживаетесь своей цели, и теперь вы собрали ценные отзывы для повторения.

Это подводит меня к следующему пункту.

Заранее собирайте отзывы

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

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

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

1*D2CuccFu10dqpd3uL8NeFw
Цикл обратной связи для продукта

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

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

Вы должны определить и предложить минимально жизнеспособный продукт (MVP), что означает минимальный способ, которым ваш продукт должен работать, чтобы удовлетворить потребность.

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

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

Ищите, прежде чем спрашивать

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

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

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

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

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

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

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

Оптимизируйте для простоты

Стремитесь к простоте в своей работе и в своей жизни.

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

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

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

Здесь играет роль читабельность кода и организация кода.

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

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

Книги, которые я прочитал, и понравившиеся мне ресурсы

  • Принципы Рея Далио — ? Одна из самых лучших книг, которые я читал за последнее время. Автор рассказывает о принципах, которые мы можем использовать как в жизни, так и на работе. Я включил его схему решения проблем в свою повседневную жизнь
  • Как завоевывать друзей и влиять на людей — классическая книга о построении и управлении отношениями с людьми? Эта книга помогла мне понять, как управлять своими отношениями на работе.
  • Старший инженер-программист — ? Великолепная книга с действиями о том, как стать зрелым инженером-программистом. Здесь я научился Искать, прежде чем спросить.
  • Решающие разговоры — отличная книга о том, как обращаться с людьми в ситуации высоких ставок. Очень пригоден для разных аспектов жизни. Или это переговоры о более высокой оплате труда? или выяснить проблемы общения с вашим мужем?, в этой книге есть несколько хороших советов по решению этих проблем.
  • Lean Startup – хорошая книга о том, как использовать минимально жизнеспособный продукт (MVP), чтобы проверить идею перед дальнейшим инвестированием. Раньше я использовал это для проверки нескольких идей стартапа.
  • Фиолетовая корова -? Понравилась эта книга. В основном использовал это для тестирования различных идей стартапа, которые я имею в виду. В нем рассказывается о том, как продавать свой стартап и чем он выделяется среди других.
  • Evernote – лучшее приложение для ведения заметок? Я когда-нибудь использовал. Очень рекомендую!
  • Блокнот Moleskin – мне очень нравится. Качество его очень высокое. Цена немного выше, но поскольку я пользуюсь ею каждый день, я считаю это хорошей инвестицией. Держа в руках красивый блокнот каждый день, я испытываю большее желание писать новые заметки.
  • Pilot G2 (черный) – лучшие ручки, которые я когда-либо использовал, и только ручки, которыми я буду пользоваться. Я покупаю их оптом на Amazon и держу их всюду. Один у меня в рюкзаке, один в офисе, а другой в домашнем офисе, так что у меня всегда есть ручка. Он отлично пишет, чернила текут гладко, и мне просто нравится писать им. В сочетании с Moleskin иногда я просто хочу взять G2, чтобы записывать там случайные вещи, потому что эти два идеальны вместе.

Следите за мной в Twitter, Facebook и LinkedIn. Подпишитесь на мой список рассылки, куда я регулярно посылаю советы, подсказки и знания отрасли.

Если вам понравилась статья, прокомментируйте ее ниже: какой ваш лучший совет №1 инженеру-программисту?

Добавить комментарий

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