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


Карьера — это марафон, состоящий из бесчисленных связанных забегов


В начальной школе мы точно знали, что окончим её через 5 лет (я тогда учился по пятилетней системе; похоже, в некоторых местах она всё ещё есть). Как бы сильно ты ни ненавидел своих учителей, одноклассников или школу, ты знал, что это закончится максимум через 5 лет. То же со средней и старшей школой: за три-четыре года всё проходит быстро, и вся радость и печаль вскоре угасают. С колледжем ещё больше — с того дня, как ты ступаешь в кампус, начинается обратный отсчёт, и ты знаешь, что однажды через четыре года уйдёшь. Как бы ты ни дорожил этим или ни растрачивал это, время всё равно течёт в одном направлении с его вечной, неизменной скоростью.



Но как же работа? Спустя 5 лет ты всё ещё работаешь, и тебе приходится продолжать работать. Спустя 10 лет, 20 лет, 30 лет, даже 40 лет нам всё ещё приходится работать. Даже если ты уволишься, придётся устроиться в другую компанию, а новая работа по сути ничем не отличается от предыдущей. Как только ты поймёшь, что карьера — это 40-летний цикл, ты осознаешь, что это сверхдлинный марафон — не спринт средней школы, не спринт перед поступлением в вуз и уж точно не «поступишь в хороший университет, а потом можно просто валять дурака». Нет смысла бежать спринт очертя голову; всё равно это не принесёт пользы. Важнее непрерывное обучение — да, десятилетия непрерывного обучения.


Единственный способ стать мастером или большой шишкой (da niu) — постоянное обучение


Не мечтай, что попадание в большую компанию, вступление в крутую команду, сидение рядом с большой шишкой или посещение множества офлайн-мероприятий сделает тебя большой шишкой. Это всё «слишком молод, слишком наивен». Зачем ты нужен большой компании? Зачем ты нужен крутой команде? Во-первых, тебе нужны настоящие навыки. Что касается подсказок от большой шишки — это удача. Может, ты насмотрелся слишком много телесериалов: ты падаешь в долину и встречаешь белую обезьяну, у которой в животе спрятано «Священное писание девяти ян»? Или скатываешься с обрыва, видишь гигантского орла и учишь «Девять мечей Дугу»? Когда по всей стране миллионы код-обезьян, как думаешь, каковы шансы наткнуться на мастера? И насколько вероятно, что мастер захочет с тобой разговаривать? Мечтаешь, что мастер будет учить тебя лично? Если только ты не его секс-партнёр.


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


У больших компаний действительно много ресурсов и материалов, а также больше возможностей для обучения, но вам всё равно нужно самому смотреть, слушать и учиться. Что касается различных офлайн-мероприятий, большинство из них — просто реклама. Остальные доклады в основном скользят по поверхности — получить настоящую конкретику («полезный материал») невозможно. Сколько они могут сказать за несколько десятков минут? И сколько вы сможете усвоить? Так что офлайн-мероприятия — это хорошие возможности для продвижения, расширения кругозора (можно услышать много концепций) и расширения сети контактов (вы действительно можете познакомиться со многими людьми — большими шишками и людьми вашего уровня) — но не для обучения.


Одним словом: если хочешь стать мастером, всё равно нужно учиться основательно — проглатывать книги, читать код, писать код. Другого пути нет. По этому поводу можно обратиться к статье одного гуру (Пишешь бизнес-код каждый день — как стать техническим гуру?), и, по-моему, в этом много смысла.


Выберите отрасль или технологию, а затем углубляйтесь


Хотя я не сторонник составления пятилетних планов, как некоторые, — потому что наша отрасль, компании, проекты и кадры меняются слишком быстро, и эти неопределённые факторы сорвут все планы, особенно долгосрочные, — цели всё равно нужны. Я считаю, что для большинства людей конечная цель — не что иное, как финансовая свобода. Как её достичь? Удача тоже играет роль, но важнее реальная сила. Что такое реальная сила? Это способность решать проблемы, которые другие решить не могут. Например, начальник хочет развивать определённое направление бизнеса, а вы знаете бизнес-правила досконально и можете повести команду и довести дело до конца. Или когда возникает техническая проблема, вы можете её решить. Без реальной силы одна лишь удача не поможет — даже если вы стали свидетелем взлёта Taobao, сегодня вы всё равно можете не иметь финансовой свободы.


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


Что такое отрасль? Автомобилестроение — это отрасль, финансы — отрасль, одежда — отрасль, путешествия и транспорт — отрасль, и так далее. А что такое технология? Безопасность, аудио, WebKit, графика, глубокое обучение — всё это технологии. Находясь в отрасли, технология может быть несложной; возможно, всё это довольно заурядно. Но если вы сможете глубоко понять отрасль — её правила игры, её подводные камни, её политику и нормативные акты, её риски, как получить максимальную отдачу — этим вещам вы учитесь только после того, как проведёте время в отрасли. Технологию понять проще: использовать готовую технологию легко. Например, WebView очень удобно использовать, но его базовая техническая реализация — WebKit — чрезвычайно сложна, и вы не разберётесь в ней всего за несколько лет.


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


Ответственность важнее технологии


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


Наоборот, те, кто плохо справляется с работой, не обязательно плохи в технике. В глазах людей они неизбежно будут «безответственными». Как говорится, отношение определяет всё, а плод отношения — ответственность. Даже если ваш технический уровень средний, но отношение серьёзное и вы ответственны, вы отличный сотрудник — и более ценны для компании. Что же до тех, кто технически силён, но имеет плохое отношение и уклоняется от ответственности, — это типы, которые просто плывут по течению, едят и пьют, ждут смерти — опухоли, которые рано или поздно вырежут.


Как стать профессиональной код-обезьяной


«Профессиональный» здесь скорее относится к форме и методу — способу ведения дел. Прежде чем объяснять, что значит «профессиональный», давайте посмотрим на несколько примеров того, что непрофессионально:


  • Во время телефонного интервью, не спросив, хорошо ли вас слышит собеседник, вы начинаете бла-бла-бла. Примерно через десять минут собеседник вздыхает и говорит: «Извините, плохая связь, я не расслышал...»
  • Например, во время телефонного интервью кандидат говорит: «Дайте-ка я сначала найду удобное место». Найдя его, он звонит вам и говорит, что нашёл, — и после этого начинается телефонное интервью... с исходящего звонка кандидата...
  • Например, опоздания на встречи или пустая болтовня во время встреч...
  • Делать поспешные выводы, не разобравшись в полной картине, — особенно вспыльчивым — и даже начинать ругать людей...

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


Обратное — это профессионально:


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


«В обучении есть порядок, и у каждого ремесла есть своя специализация». Вот и всё.


Знания бесконечны. Всегда найдутся вещи, которых вы не знаете, и вещи, которые вы не умеете делать. Даже если вы десятилетиями работаете код-обезьяной, известны как человек, который знает всё, и прозваны «Мистером Всезнайкой», поставить вас в тупик несложно — даже школьник знает то, чего не знаете вы. Индустрия программного обеспечения делится на множество областей. Говорят, каждое ремесло — отдельный мир, но разные области внутри одного ремесла тоже имеют разрывы — например, клиентская часть, бэкенд, фронтенд, драйверы, игровые движки, графика и обработка изображений, безопасность и так далее. Поэтому нужно сохранять жажду знаний и скромность. Даже если вы фронтенд-звезда, столкнувшись с проблемой драйвера, вы новичок — придётся смиренно учиться и просить других о помощи.


Кроме того, проводя собеседование, как интервьюер, обладающий властью решать судьбу кандидата, вы должны проявлять к кандидатам уважение. Не стоит намеренно усложнять жизнь или «для галочки проводить собеседование для начальника, хотя вам явно не нужен этот человек» по нетехническим причинам, таким как бэкграунд кандидата (диплом не по профессиональному направлению или среднее специальное образование), его опыт (небольшие компании, аутсорсинговые фирмы), недостаток опыта (мало лет, нет выдающихся проектов) или несоответствие (вам нужна клиентская часть, а большая часть его опыта — фронтенд), а также не смотреть свысока на кандидатов по другим причинам (я однажды встречал человека из иностранной компании, который смотрел свысока на людей из отечественных компаний, говоря, что отечественные компании только копируют иностранные). Как гласит старая пословица: «Никогда не нанимай того, в ком сомневаешься; никогда не сомневайся в том, кого нанял». Как интервьюер, вы можете отказать человеку — это ваше право — но вы обязаны уважать его, даже если его способности действительно слабы. У каждого бывают времена, когда приходится склонять голову. Неужели иностранная компания так хороша? Разве иностранные компании в Китае — не просто аутсорсинговые подразделения головного офиса, выполняющие всю чёрную работу? Motorola была такой классной тогда — высокая зарплата, суперпридирчивый наём — а теперь дерево упало, и обезьяны разбежались! Как гласит старая пословица, не выпендривайся, а то рано или поздно молния ударит!


Как остановить растерянные глаза и успокоить беспокойное сердце


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


Это всё ещё немного расплывчато, немного похоже на мотивационную воду. Позвольте рассказать, как делать это конкретно:


  • Во-первых, разберитесь, чем именно вы занимаетесь. Верно, код-обезьяна, который просто пишет код. Код какого слоя? Android? Apple? Приложений? Фреймворков? Драйверов? Какая область? Графика и обработка изображений? WebKit? Сети? Bluetooth? Финансы? Безопасность? Как — вы не пишете код, а только сопровождаете и исправляете баги (довольно многие, например те, кто работает с готовыми Android-решениями «под ключ», только сопровождают и исправляют баги)? То же самое — разберитесь, какой слой, какая область.
  • Затем, когда вы разобрались, чем занимаетесь, всё просто: хорошо делайте то, что должны, досконально в этом разберитесь, пока вам не понадобится всего полдня, чтобы выполнить дневной объём работы.
    Написание кода требует учиться писать код, который одновременно хорош и быстр, — то есть уметь быстро выполнять заданные требования с малым числом багов. На более высоком уровне это также означает писать чистый, понятный код с разумной структурой и ясным именованием. Это развитие фундаментальных навыков, и его долго упускали из виду, потому что почти ни в каких KPI компаний не учитывается, хорош код или плох; в лучшем случае они охватывают количество багов, частоту падений, производительность и стабильность. Это метрики программного обеспечения, а не качества кода. Лучший способ измерить качество кода — посмотреть на реакцию человека, который примет ваш код, — на то, сколько раз он вас выругает. Для улучшения навыков написания кода можно читать такие книги, как «Code Complete» и «Clean Code», но важнее читать превосходный открытый исходный код.
  • Другое — освоиться с существующей кодовой базой, стремясь знать, какие классы нужно изменить и куда добавить новый код, когда приходит новое требование. При исправлении багов вы должны уметь подумать и приблизительно определить, где находится баг, какой класс или метод вызывает проблему.
  • Также будьте знакомы с бизнес-логикой. Любое программное обеспечение создаётся для реализации бизнеса. Чтобы понять бизнес-логику, сначала поймите логику небольшого модуля, за который вы отвечаете, а затем бизнес-логику всего программного обеспечения. Это очень полезно для оценки новых требований и исправления багов, поскольку вы будете думать с целостной точки зрения. Есть конкретные показатели, например организация документов с требованиями, и на их основе вы можете генерировать различные тест-кейсы и сценарии, что помогает проверять корректность вашего кода.
  • После этого подготовьте и сделайте резервные копии типовых тестовых сред, тестовых данных и тест-кейсов. После новых требований и исправления багов вы также должны систематизировать и добавлять их в тестовый репозиторий для самопроверки и регрессионного тестирования. Хотя QA обеспечивает качество программного обеспечения, наше ПО должно, по крайней мере, работать и соответствовать требованиям до того, как попадёт к QA. Короче говоря, профессиональные программисты должны сами проводить достаточное тестирование. Однако тестирование иногда не так удобно. Например, на стороне клиента часто бывает, что данные с бэкенда ещё не готовы, поэтому нужно мокировать данные; некоторые данные появляются только в редких сценариях, и их тоже нужно мокировать для тестирования; перед релизом нужно тестировать в тестовой среде с тестовым сервером; и т. д. Это означает, что если вам часто нужны такие вещи — как мок-данные, прокси и т. п. — вам стоит вложить немного усилий в их организацию и резервное копирование и даже найти способы — написав код или используя библиотеки с открытым исходным кодом — настроить удобную тестовую среду. Это очень помогает в разработке. Вы, возможно, помните, что баг может быть легко исправить, но сложно проверить: могут потребоваться прокси, мок-данные, имитация особых сценариев, настройка сетевого окружения и так далее.
  • Также делайте резервные копии общих конфигураций окружения. Например, если в вашем коде есть разные настройки для разных сценариев, лучше всего сделать копию для каждого сценария, полностью настроенную, а не использовать разные ветки, хотя это тоже возможно. Есть две причины:
    После нескольких лет работы в отрасли мы хорошо знаем, что конфигурация окружения — тоже часть разработки, и обычно она очень хлопотная. Она может превратить то, что выглядит как десятиминутная задача, в два дня работы, и всё ещё может остаться незавершённым. Современный код очень сложен, и сложность заключается не в самом коде, а в чрезвычайно сложных зависимостях. Те, кто часто возится с софтом с открытым исходным кодом, должны знать, что сама библиотека может быть и не сложной, но чтобы её использовать, нужно установить и настроить целую кучу зависимостей. Представьте: если не использовать менеджер пакетов (например, apt-get, brew, pip и т. д.), попробуйте вручную установить OpenCV или напрямую скомпилировать его исходный код.
    • Хотя ветки кода позволяют различать разный код, конфигурации зависимостей окружения часто не хранятся в репозитории. Это означает, что после переключения веток вам всё равно придётся заниматься конфигурацией окружения и зависимостями.
    • Ещё одна причина — вопрос параллелизма. Предположим, вы разрабатываете новую функцию в ветке для версии A, и в это время версия B (предположим, A и B для разных клиентов, и эти две ветки различаются) требует исправления ошибки. Как вы думаете, что удобнее: переключать ветки или работать в другом каталоге? Я считаю, что подход с физической изоляцией лучше.
  • После достижения всего вышеперечисленного, я уверен, задачи в рамках вашей ответственности больше не будут для вас проблемой. На этом этапе вам нужно глубоко изучать и понимать то, от чего вы зависите. Например, вы используете сетевые библиотеки вроде OkHttp и Retrofit — почему они лучше нативных? Каковы их основные принципы? Какова их философия инкапсуляции? Аналогично, для библиотек загрузки изображений вроде UIL и Picasso — каковы их принципы? Лежащие в их основе библиотеки очень хорошо инкапсулированы и просты в использовании. Таких библиотек всё больше, и если вы умеете только пользоваться ими, то вам конец. Ведь даже тот, кто никогда их не использовал, сможет разобраться, как ими пользоваться, прочитав руководство за несколько минут. Только глубоко разобравшись в деталях реализации и изучив продвинутое использование, вы сможете по-настоящему сказать, что не зря пользовались этими превосходными библиотеками.
  • Кроме того, в любой области и на любом уровне оптимизация производительности — это отличительный признак эксперта. Работой по оптимизации производительности в проекте обычно занимаются эксперты. Поэтому, если вы изучали и практиковали оптимизацию производительности, это определённо огромный плюс к вашим навыкам и большой плюс на собеседованиях.
  • И напоследок: будьте преданы делу и относитесь к своей работе серьёзно. Относитесь серьёзно к каждой строке кода и каждому багу. Даже если вам не нравится ваша нынешняя работа, даже если вы чувствуете, что впустую тратите время и жизнь, каждый день без радости исправляя баги, вы всё равно должны относиться к этому серьёзно и хорошо выполнять свою работу. Как говорится: «Бери деньги и устраняй беды за других». Раз уж вы получаете зарплату от компании, вы должны хорошо выполнять свою работу. Если в будущем вы сможете устроиться на лучшую работу — это другое дело, на потом. Сегодня, пока вы здесь, вы должны делать то, что нужно. Если вы слишком импульсивны, у вас большие амбиции, но мало способностей, и вы всегда халтурите, то вы думаете, что сможете получить лучшую работу? Доверит ли начальник вам более важные задачи? Хотя мир — странное место, и действительно некоторые люди получают более высокие зарплаты и лучшие работы не благодаря своим навыкам, я считаю, что в большинстве случаев это пропорционально. У людей с лучшими условиями, чем у вас, есть законные причины. Если вы с этим не согласны, то должны работать ещё усерднее. Когда в будущем вы устроитесь на лучшую работу, докажите другим: «Я лучше всех вас!»

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


К чёрту карьерное планирование и долгосрочные планы.


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


Почему всё это бесполезно? Потому что в реальной жизни всё меняется очень быстро. Проекты могут закрыться через пару месяцев. Что касается людей — сегодня Чжан Сань увольняется, а завтра Ли Сы переводится на другую должность. Не успеешь закончить — требования меняются, или эта операционная деятельность отменяется, потому что начальник не утвердит бюджет...


Приведу конкретный пример из своего окружения: в прошлом году в команду пришёл новый стажёр. Его взяли разработчиком Android-клиента. После того как он пришёл, в первую неделю ему поручили задачи по Android. На второй неделе появилось новое крупное требование, для которого нужен был H5 (Mobile HTML5), так что этому парню пришлось заниматься H5 (ему пришлось учить JavaScript с нуля). Примерно через три месяца политика компании изменилась, и они не могли больше держать столько стажёров, поэтому парню пришлось вернуться в школу. Если бы вы были этим парнем, вы не смогли бы выполнить даже месячный план учёбы, потому что не знаете, что случится на следующей неделе или даже завтра.


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


Стоит ли идти в крупную компанию или в маленькую — это можно перечислить как бессмертную тему наравне с дебатами C против C++, GNOME против KDE и Vim против Emacs. Я считаю, что на раннем этапе карьеры, например сразу после выпуска или в течение двух-трёх лет после выпуска, крупная компания, несомненно, очень хороший выбор. Здесь под «крупной компанией» подразумеваются ведущие отечественные компании, такие как BAT, NetEase и другие известные крупные отечественные компании, а также крупные иностранные компании, такие как Intel, Microsoft, Facebook, Google и так далее.


Далее позвольте мне рассказать о причинах. Компании нанимают нас, чтобы работа была выполнена, чтобы создавать ценность и помогать компании зарабатывать деньги. Вас нанимают не для того, чтобы вы учились, расширяли кругозор, приближались к известным людям или обсуждали проблемы. Большая компания, поскольку она большая, имеет стабильный источник дохода и прибыльность, поэтому её темп регулярный и относительно расслабленный. Её проекты либо зрелые и стабильные, либо не выполняются ради краткосрочной прибыли. Поэтому она осмотрительна в развитии талантов. Иными словами, она может терпеть, что вы учитесь или даже немного замедляете свои рабочие задачи (я имею в виду немного замедляете), потому что компания также ожидает, что вы будете учиться и совершенствовать свои навыки и способности. У компании будет пространство, чтобы вместить лучшую версию вас. Проще говоря, у вас достаточно возможностей для роста и продвижения, и есть время и терпение, чтобы позволить вам завершить этот процесс. Может ли маленькая компания иметь такое пространство? Может ли она позволить вам сказать: «Я сначала поучусь несколько месяцев»? Возможно, через несколько месяцев, когда вы вернётесь с учёбы, компания уже могла обанкротиться.


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


Словом, когда вы находитесь в фазе быстрого обучения в своей карьере, большая компания — лучший выбор. Когда вы почувствуете, что узнали достаточно или достигли нового узкого места, то небольшая компания — отличное место, чтобы в полной мере применить свои навыки. Вот видите, у людей, вышедших из BAT, будь то собственное дело или присоединение к стартапу, очень хороший результат. Это беспроигрышный вариант. Для нас небольшая компания даёт больше пространства, меньше людей, но больше дел, и это большая сцена для демонстрации ваших способностей. А небольшим компаниям как раз нужны такие универсалы, которые могут работать за десятерых: быть одновременно и CTO, и кодером, и разработчиком, и ops-специалистом.


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


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


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


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


Как говорится: «Когда ты сыт и в тепле, в голову лезут похотливые мысли». Когда тебе даже на следующую еду не хватает, как можно думать о том, чтобы подкатывать к девушкам? Когда ты не освоил досконально ни одного навыка, ни одного языка программирования, ни одной платформы, зачем думать о кроссплатформенной разработке или о широте технологий? Всё это чушь. Если копать колодцы повсюду, ни один из них не будет глубоким, и в конце концов ты за всю жизнь так и не докопаешься до воды. Это всё равно что сказать, будто десять раз по 10% не равны одному 100%.


Другой пример — команда: каждый релиз превращается в хаос. Как можно говорить об XP или технических инновациях в таких обстоятельствах? Займитесь тем, чтобы освоить технологии, которые действительно нужны вашему бизнесу, и освойте их досконально. Сначала хорошо делайте свою работу и делайте её без напряжения. Когда вы сможете без усилий справляться с каждым релизом или даже когда работу 10 человек смогут выполнять 5, вот тогда — и только тогда — наступает время заниматься техническими инновациями, модульным тестированием, XP, культурой, движимой технологиями, или культурой, ориентированной на инженеров.


На уровне компании, когда вы ещё даже не закрепили стабильную долю рынка в своей текущей сфере, вы копируете чужие грандиозные стратегии: они идут в финансы — и вы туда же; они идут в автомобили — и вы туда же; они идут в кино — и вы туда же. Это рано или поздно вас погубит. Возьмите господина Цзя (Цзя Юэтина) сегодня — из телевизоров, телефонов и спортивного подразделения LeEco у какого из них стабильная доля рынка? Какое из них может нести ответственность за прокорм семьи? А он уходит играть в стратегические игры и строить автомобили? Это называется «No zuo, no die». Господин Ма (Джек Ма) хорошо умеет выстраивать стратегию, но он делал это только тогда, когда имел монополию в одной сфере: когда он запускал Taobao, это было потому, что B2B уже прочно встал на ноги и мог прокормить семью. Иными словами, B2B уже был хорошо налажен, занимал большую часть рынка и был прибыльным, так что даже если бы Taobao провалился и приносил убытки, это не было бы большой проблемой. Позже он запустил Alibaba Cloud, а теперь кинонаправление, Cainiao, Double H — все они требуют постоянных денежных вливаний. Почему? Потому что Taobao и Tmall могут поддерживать весь Alibaba, и даже если все они будут убыточными, он может позволить себе эти потери.


То же самое применимо на уровне страны: когда люди всё ещё не могут досыта наесться или одеться, как можно говорить о духовной цивилизации или технологических инновациях? Например, Китай в 1970-х и 1980-х годах или Юго-Восточная Азия около десяти лет назад (более слабые страны, а не «четыре тигра»), и охрана окружающей среды — когда человечество стоит перед выбором между собственным выживанием и охраной окружающей среды, оно может выбрать только первое. Поэтому когда менее развитая страна движется к умеренно развитой, экономическое развитие всегда стоит на первом месте. Процесс человеческого развития везде одинаков: сначала загрязнять, затем стремиться к развитию, потом очищать.


На этом этапе, я полагаю, вы понимаете, что я имею в виду.


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


Что такое конкурентоспособность? Я думаю, это означает развитие способности решать проблемы, которые нельзя решить простым поиском в Google. Проще говоря, это система знаний. Проблема, которую может решить Google, обязательно является отдельной точкой. Будь то StackOverflow или пост в блоге, они всегда рассматривают точечную проблему — она не может быть слишком большой, ведь как иначе одна статья объяснит её ясно? Несколько точек, соединённых со временем, образуют систему. Это происходит из многократного поиска в Google на протяжении долгого времени плюс размышлений и обобщения. Вот это и есть конкурентоспособность. Это также ценность опытного ветерана.


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


На мой взгляд, самая важная причина этой неловкой ситуации — неспособность продолжать учиться и накопить достаточную конкурентоспособность. Даже если вы не становитесь менеджером или топ-экспертом (в реальной жизни невозможно, чтобы все старше 30 становились менеджерами или мастерами), если вы продолжаете учиться и постоянно повышаете свою конкурентоспособность, ваша ценность всегда будет расти — даже если компания даёт вам лишь стандартные ежегодные повышения.


Когда дело доходит до зарплаты, её следует рассчитывать в пересчёте на единицу времени. Предположим, ваша месячная зарплата — 2,150 yuan; она получается из 21.5 × 100. Если вы возьмёте один выходной, вычтут 100 yuan. Пересчитаем дальше: 8 × 12.5 = 100, значит, ваша почасовая зарплата — 12.5 yuan. Допустим, у двух человек одинаковая месячная зарплата 2,150, но у одного уровень навыков выше: дневная работа выполняется за 2 часа, а месячная — за одну неделю. Другому приходится каждый день работать сверхурочно, только чтобы всё закончить. У кого зарплата выше? Конечно, это упрощённый сценарий; в реальной жизни всё сложнее. Хотя у каждого есть период быстрого роста, и у компаний тоже бывают периоды быстрого расширения, в конечном итоге всё достигает стабильного состояния. Стабильность означает упереться в потолок. Возьмём, например, большинство людей в больших компаниях вроде BAT — на примере Alibaba: подавляющее большинство людей останавливается после достижения P7. Получить повышение до P8, не будучи менеджером, очень трудно, и дальше становится только труднее. Поэтому такие люди могут получить только стандартные ежегодные повышения. Чтобы поднять свой уровень дохода, они могут повысить свою ценность только за счёт улучшения собственной эффективности работы.


Некоторые могут сказать, что это нереалистично — работа не обязательно распределяется равномерно, и ветеранам могут поручать больше задач. На самом деле это решение зависит от вас самих. Если вы уже ветеран без надежды на продвижение, зачем делать больше? Это эпоха, когда зад определяет голову — то есть эпоха, когда зарплата определяет ответственность. Сколько усилий вкладывают сотрудники, зависит от того, сколько им платят. Говоря прямо: они платят зарплату выпускника, но ожидают, что вы будете выполнять работу архитектора и нести ответственность CTO. Люди делают так только на раннем этапе карьеры, когда быстро учатся и растут, — и как только они чувствуют, что узнали достаточно, сразу перескакивают на лучшую должность.


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


Важные дела не обязательно должны выполняться в первую очередь.


Когда перед вами несколько крупных задач — например, новая функция, несколько ошибок в уже выпущенной версии и техническое предложение для операционной кампании на следующий месяц — и все три на повестке, вы можете выбрать только самую важную, чтобы сделать её первой. Это действительно требует применения принципа «важные дела — в первую очередь».


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


Разграничивающий принцип таков: если мелкую задачу можно выполнить за 10 минут, делайте её сразу. Понимайте, что чем короче ваш список дел, тем лучше. Что касается задач, которые занимают полдня или целый день, их, конечно, всё равно следует выполнять по принципу «важные дела — в первую очередь».


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


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


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


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


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


Учитесь работать с умом.


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


Речь не о том, чтобы призывать всех к оппортунизму и перекладывать свои задачи на других — конечно, если у вас есть способность перекладывать задачи и другой человек готов их взять, это тоже нормально. Скорее, речь о том, чтобы работать с умом и не тратить силы на то, что должно быть чужой ответственностью. Например, программные зависимости сейчас довольно сложны, и проблемы обычно проявляются на верхнем уровне. Если вы обнаружите, что проблема вызвана нижележащим слоем, то не углубляйтесь в неё (если только у вас нет достаточно времени на изучение и исследование) — пусть вместо этого разбирается ответственный за это человек. Он лучше с этим знаком. То, на что у вас может уйти целый день, он решит с первого взгляда.


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


Научитесь использовать преимущества того, что вы программист.


Программное обеспечение больше не является той загадочной, труднопостижимой вещью из университетских лабораторий. Оно вошло в жизнь людей — даже пожилые люди, танцующие на площади, пользуются смартфонами, WeChat и Taobao. Я считаю, что всё меньше и меньше людей будут просить инженеров-программистов починить их компьютеры. Это означает, что мы имеем дело с программным обеспечением каждый день и не можем без него жить. Как люди, умеющие писать программное обеспечение, мы должны хорошо использовать свои преимущества. Приведу несколько примеров:


  • Умейте распознавать всевозможные фишинговые текстовые сообщения и мошеннические звонки/сообщения. Если программист попадётся на удочку телефонных мошенников, то придётся признать, что этот программист — полный неудачник.
  • Для различного программного обеспечения умейте определять, какое из них подлинное, какое — подделка, какое — фальшивка, какое может содержать вирус, а какое — троян. Что ещё важнее, будьте осведомлены в вопросах безопасности. Утечка личной информации в мобильных приложениях и на сайтах сегодня очень серьёзна, поэтому уделяйте особое внимание управлению разрешениями приложений и регистрируйтесь как можно меньше на сайтах. Кроме того, следите не только за собственной информационной безопасностью, но и напоминайте об этом окружающим.
  • Ещё пример: обычные люди получают информацию, посещая сайты и используя поисковые системы, но разве программисты (猿媛) не должны использовать краулеры?
  • Ещё один пример — хватать красные конверты, скупать билеты, флеш-распродажи (не гонитесь за лунными пряниками, ха-ха), накручивать голоса, накручивать комментарии и так далее. Обычные люди полагаются на ручной труд, ручную работу и посты в Моменты. Мы, программисты, определённо должны полагаться на технологии — написать скрипт, написать кусок кода, чтобы помочь нам делать эти вещи. Это также преимущество, которое даёт наша профессия.

Источник: Странник по звёздному небу
Автор: alexhilton
Ссылка: http://blog.csdn.net/hitlion2008/article/details/54089376