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

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

В первую очередь

Английский язык хотя бы на уровне чтения. Вся актуальная техническая информация на английском. Причем, в интернете. Он у тебя только начинает появляться местами, но знай — это отличный источник информации, если уметь им пользоваться и фильтровать. Тем более, его там, в твоем времени, еще так не загадили. Но сейчас не об интернете, а об английском. Переводные книги на русском устаревают к моменту выхода на два-четыре года. Даже печатные книги на английском устаревают на год. Дистрибьютеры микросхем, например, прямо на семинарах говорят, почему они перестали переводить документацию — бесполезно. Пока вышел перевод, уже серия устарела и вышла новая. Документация в электронном виде — наше всё. В институте у тебя были по английскому одни пятерки, ты был лучшим в группе и одним из лучших на курсе, так знай — этого мало. Знания твои на троечку от силы. Это только база для начала освоения английского. Надо больше читать. А еще лучше — смотреть и слушать, фильмы, лекции, записи конференций и семинаров. Когда интернет станет подешевле и побезлимитнее, у тебя появится такая возможность, не упусти ее.

Поиск и анализ информации в открытых источниках. Не только Ctrl-C Ctrl-V со StackOverflow (ах да, у тебя там его еще нету, но запомни это слово, после 2008 пригодится) но оценка полезности и применимости, способность выбрать из десятка книг лучшую, даже не особенно разбираясь в предмете. Надо сказать, это главное, чему тебя научил институт. Те учебники и справочники, которые ты выбрал в Доме книги на Вайнера, оказались в числе лучших, и лучшее из всего, что было на полке.

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

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

Учись вести переписку и переговоры. Не очень приятно, но придется — будешь и официальные письма писать, и в командировки ездить. Надо как владеть канцелярско-дипломатическим языком, так и быть в состоянии неформально (но не фамильярно) общаться по неофициальным каналам.

Было бы здорово, если бы ты участвовал в сообществах и OpenSource-проектах, но на это у тебя не будет хватать сил и будет жалко времени. Может, все-таки постараешься?

Насчет учебы

У тебя не получится обойтись одним языком программирования, иногда придется осваивать другие, и в довольно сжатые сроки. Так вот, лучший источник информации по языку — это его официальная документация. Учебники хороши, когда не умеешь программировать совсем. После того, как более-менее освоишь один язык, для перехода на другой не нужен учебник, нужен справочник, а лучший справочник по языку — его документация. Конечно, не стоит ограничиваться только справочником, есть какие-то стандартные подходы, best practice, описанные в отдельных книгах, типа "55 советов" Майерса.

Когда возьмешься за программирование всерьез, непременно напиши небольшой проект на ассемблере. Любом, хоть для ПК, хоть для микроконтроллера, благо есть куча дешевых отладочных плат или копеечных МК, которые можно лазерно-утюжным методом превратить в простое устройство (в общем-то, ты все это обязательно попробуешь). В проекте используй различные методы адресации и передачи параметров в подпрограммы, создай подпрограммы в полном соответствии с правилами: выделение стекового кадра, сохранение регистров в стеке, передача параметров и возврат значения. Опять же, поработай со стеком — выдели место для него в памяти и пробуй сохранять/восстанавливать данные, особенно интересно на рекурсивных подпрограммах. Это снимает кучу недопониманий: что такое указатели и указатели на указатели, что такое размещение на стеке и откуда берется переполнение стека, как работают локальные переменные и почему до инициализации в них мусор, вопросы про соглашение о вызове типа stdcall и всё такое прочее.

Непременно заведи шпаргалку. И не одну, а по каждому языку и инструменту, типа системы контроля версий или IDE. В любой программерской работе есть типовые решения. Они не сразу записываются "на подкорку", их сначала надо узнать, а потом к ним привыкнуть. Хорошо в этом помогают сборники собственных учебных проектов (ну, и не только учебных), откуда можно копировать удачные уже найденные решения. Но по своим проектам непросто искать, где что. Если наткнулся на задачку, которая явно должна иметь типовое решение, следует это решение найти — самому, или в документации (в рекомендованных вариантах использования библиотеки, например), или в поисковике (StackOverflow), а потом хорошо бы это решение переписать в отдельный файл-сборник и пометить текстовым тегом/заголовком, по которому его будет легко найти, ибо скорее всего это решение еще не раз понадобится. Однажды закончатся новые разработки с процессором 1806 и его ассемблер PDP-11 будет отложен и подзабыт. А потом внезапно, лет через пять, надо будет дополнить чужую программу, и на работу будет два дня. Так вот, без такой шпаргалки ты не справишься, а с ней — запросто.

Непременно освой систему контроля версий, чем раньше, тем лучше. После 2005 года выбирай GIT, он станет стандартом де-факто. Конечно, не обязательно его, но я-то знаю, что ты выберешь… Это действительно очень полезная штука даже в сугубо индивидуальной разработке. Для работы в одного плюсы:

• резко сокращает объем проекта. Сохранять промежуточные точки — версии — все равно придется, самый популярный метод без СКВ — копировать весь проект. Так накапливается куча огромных папок (со всеми служебными файлами) из-за изменений в паре строк пары файлов. Ты и займешься выбором СКВ, когда твой первый серьезный проект вырастет до десятка гигов. А я еще помню, что у тебя дома на компьютере винчестер всего на шесть. Так что начинай пораньше.
• улучшает возможность поиска по актуальности, особенно если папки с "как бы версиями" называются "новая", "последняя", "текущая", "самая новая". А у тебя в отделе было так принято, я помню. И ты внесешь свой вклад в то, чтобы это прекратить.
• упрощает слияние версий, позволяет создавать вместо копии проекта отдельную ветку, при неудачной попытке — грохнуть эту ветку, не трогая остальную работу, при удачной — легко влить изменения в основную средствами СКВ.
• обеспечивает ведение реальной хронологии проекта, позволяет увидеть затраты времени на свою работу над более-менее однотипными задачами для последующей оценки времени на похожие проекты — по времени коммитов. Это тебе тоже пригодится не раз, с тебя будут требовать планы с ориентировочными сроками, так не срывай их!
• упрощает переход на командную работу над проектом, если проект перерастет во что-то серьезное, с чем одному уже не справиться.
• уменьшает трудозатраты при необходимости разобраться в проекте, показывая последовательность разработки с комментариями, поясняющими что и зачем было сделано. Это может быть полезно не только при передаче в чужие руки, но и при открытии собственного проекта трехлетней, да что там, порой и двухмесячной давности.

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

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

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

О подходе к работе

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

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

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

Работай над контролем собственного времени. Здесь есть две крайности:

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

2. задача очень интересная, "цепляет", не отпускает. Погружаешься в нее с головой, отпинывая тех, кто пытается отвлекать. Чревато серьезной утомляемостью. Опять же, если впахивать не отрываясь, через некоторое время производительность падает, хотя субъективно кажется, что все в порядке, работа идет вроде бы так же.

   
   

   В обоих случаях надо себя заставить работать равномерно, делая перерывы, но не делая перерывы больше, чем периоды работы над задачей. Есть разные методики управления временем, гуглить аббревиатуру GTD (Getting Things Done) и метод помодоро. Тебе понравится, но не всегда получится использовать.

   
   

Занимайся декомпозицией и планированием. Принцип "ввязаться в бой, а там посмотрим" работает только на маленьких одноразовых задачках. Любую серьезную задачу можно разбить на подзадачи, определить их приоритеты, взаимное влияние результатов, отсюда — последовательность выполнения. Опять же, чем меньше задача, тем проще прикинуть время на ее выполнение. При качественной декомпозиции не очень трудно спланировать весь проект, и даже распараллелить при возможности (иногда у тебя будет на кого распараллелить). Хорошо, если задачи в результате декомпозиции укладываются в полчаса-час — так они отлично ложатся на практики управления временем, вроде помодоро. Неплохо, если задачи глобального плана хотя бы не больше одного рабочего дня, тогда имеет смысл проводить дополнительную декомпозицию каждое утро и планирование конкретного дня. Если работать размеренно — получается удобно и довольно производительно. Но тебе не всегда дадут. Будут авралы, и "тушения пожаров", и резкие смены приоритетов… Борись, иногда получится сделать правильно. Но в свои сроки закладывай коэффициент 1,5 на форс-мажоры, их будет навалом.

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

Выбирай инструменты под задачу. Если можно выбирать (редактор, IDE, утилиты, компиляторы и т. д.), следует подойти к выбору ответственно. А тебе выбирать придется, тебе никто не принесет готовых рецептов и не сделает принудительный выбор. Любой одноразовый отладочный проект может вырасти во что-то нужное и полезное, стать базой для серьезной работы. Соответственно, делать работу с использованием инструментов пиратских может быть не просто аморально, но и небезопасно с точки зрения закона (некоторые фирмы отслеживают появление результатов работ, сделанных с использованием их инструментов в открытой печати и проверяют, является ли автор работы зарегистрированным пользователем). Хорошо известные инструменты с бесплатной версией, например, Qt, могут привести к проблемам с лицензированием — а сейчас в ТЗ стали появляться требования соблюдения лицензионной чистоты программ и требования к сертификации. Так что старайся, чтобы тебе было удобно, но не шали.

Не относись к инструментам программирования слишком субъективно. Впрочем, у тебя с этим проблем и не было, но убеди в этом и коллег. Нельзя говорить "Дельфи — фуфло", просто потому, что твоим первым языком был С++, и все "гуру" уверяли, что он лучший. У любого используемого инструмента есть преимущества, недостатки и область применения — вполне объективные параметры. Это не статусная вещь, типа часов "Электроника" или "Ролекс".
Опять же, инструмент надо выбирать под задачу: для работы с железом, с драйверами бери что-то компилируемое, например, плюсы, для работы по сети — что-то с отлаженными библиотеками для этого, например, java, для математического моделировния — матлаб или python с соответствующими библиотеками. Впрочем, матлаб не бери — замучаешься добиваться, чтобы тебе дали лицензионный, а пиратить не стоит, я уже говорил.

Выбирая интерпретируемый язык, помни, что придется скорее всего брать на себя все хлопоты, связанные с версией интерпретатора на машинах пользователей. Потому что если не заработает — виноват будет разработчик. Так что на java или python пиши для себя, а то, что пойдет на чужие рабочие станции — Lazarus, если быстренько, или плюсы, если всё всерьез. А тот диск с Delphi 6, который ты купил на Вайнера возле ЦУМа — нет, это не лицензия, хотя в уважаемом магазине так сказали. Ты позже узнаешь, сколько стоит лицензия. А того магазина давно нет. Но пока делай на Delphi, у тебя все равно пока нет выбора.

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

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

Архитектура. Понятие сложное, толком не определенное. В твое время оно еще особо не звучит. Однако "всего лишь неделя отладки может сэкономить целый час обдумывания". Есть проверенные временем практики программирования, выраженные в принципах типа SOLID и паттернах проектирования. Вызубривать наизусть это все нет смысла, но прочитать необходимо, что-то отложится. Одно из самых важных правил — оставляй возможности для расширения. Чтобы при добавлении возможностей программу не пришлось переписывать заново. Это тебе пригодится не раз. Поэтому штудируй про интерфейсы (в смысле абстрактные классы), слабую связность (или зацепление?) и всё такое. Обнадежу, что получится у тебя неплохо — твой первый более-менее серьезный проект будут дорабатывать без тебя даже не задавая вопросов, потому что расширяемость заложена нормально.

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

Умей представить результаты своей работы. Полезно на митапах (которых у тебя не будет), на конференциях (я уже говорил — тебе еще выступать!), на защите выполненной работы (на НТС), на защите на категорию/грейд при повышении, при общении с заказчиком, при докладе начальству. Что важно:

• изложить языком, понятным неспециалисту. Брать пример с рекламы — не как сделано и почему так лучше, а показать положительные стороны результата и создать отличное впечатление о нем. Информацию о деталях реализации и подробности спросят, если надо.
• выделить главное, также понятное неспециалисту: божественно реализованный вариант сортировки пузырьком под капотом продукта никого особенно не заинтересует, а экономия времени вдвое при выполнении технологической операции с использованием представленного продукта — это действительно важно.
• иметь количественную оценку достижений. Не "стало быстрее", а "запускалось 15 секунд, а теперь 2,5".
• иметь планы рассказа как сжато, тезисно, так и развернуто по пунктам при необходимости. При этом надо знать, сколько времени у тебя занимает доклад, напечатанный, скажем, 14 шрифтом на одном листе, чтобы иметь возможность оценить время любого своего доклада и скорректировать при необходимости. После второго-третьего доклада запомнишь этот параметр, минуты три у тебя получается. Не части, помедленнее надо.
• иметь визуальные образцы работы — презентация, макет. Макет — это очень здорово, но обычно дорого, и на это не любят выделять деньги. Презентация должна быть с приличной инфографикой — те самые количественные оценки, о которых выше. Традиционно принятые у вас (ну да, у нас) схемы принципиальные электрические и экономические таблицы на 50 строк и 40 столбцов на слайде — чушь. Должно быть фото, простой рисунок, диаграмма из 5-7 элементов, график из 3-10 точек, таблицы 3х4, тезисы по 1-5 предложений. Хорошо заходят анимированные картинки (особенно графики) и коротенькие зацикленные видосики с процессом эксперимента. Но не всегда получится заснять. Презентация — это не телетекст, с которого читает диктор. Это иллюстрация и легкая подсказка, чтобы не сбиться с порядка изложения. Впрочем, на эту тему есть отдельные подборки рекомендаций, с ними хорошо бы ознакомиться. Существенная часть презентаций на конференциях нашего уровня ужасны, даже (особенно?) если они делаются уважаемыми специалистами в своей области. Например, это тупо вордовские листы с вставленными картинкой маткадовскими формулами без комментариев.
• уметь акцентировать внимание на собственных достижениях в проделанной работе и намекнуть (тонко!) на свой профессиональный рост.
• высший пилотаж при защите — оставить недосказанным и напроситься на вопрос по такой теме, о которой можешь наилучшим образом рассказать.
• нужно уметь ответить на вопросы, на которые нет ответа. Грамотно обосновать принципиальное отсутствие ответа, переадресовать вопрос специалисту в смежной области (желательно — коллеге, обязательно — чтоб он был рядом и в курсе, что его могут привлечь содокладчиком), иметь заготовки универсальных ответов, как вариант — сообщить, что заданный вопрос как раз сейчас прорабатывается, потому что мы о нем знаем, но ответ еще не нашли, ищем. Важно не оставить впечатления, что владеешь вопросом поверхностно, строго в границах доклада и ни на сантиметр шире. Очень плохо звучит ответ, что вопрос не по теме, и я, мол, имею право этого не знать, даже если это чистая правда.

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

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

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

Предметной областью не брезговать, разбирайся. Грубо говоря, если пишется бухгалтерский софт, а ты не знаешь, что такое дебет-кредит и проводки — тебе тут делать нечего. Надо знать язык конечного пользователя. Разрабатывая софт для авионики, мало знать в общих чертах схемотехнику приборов авионики, надо примерно понимать и принципы захода самолета на посадку и кто обжал шасси по команде "шасси обжато". Читай не только Шилдта и Александреску, листай и "Справочник летчика и штурмана", а то и "Взаимодействие пути и подвижного состава".

Составляй и используй чеклисты. При любой более-менее однотипной работе имеет смысл выделить основные пункты, которые непременно должны быть выполнены. Нечто вроде инструкции по настройке. Грамотно и кратко сформулированные в письменном виде, такие пункты позволят не забыть и не пропустить что-то достаточно важное: выполнил — отметил. Сюда же можно отнести и TODO-листы — список того, что надо сделать в случае нетиповой работы. Между прочим, есть работа, которая сейчас у вас передается от "наставника" к новичку из рук в руки месяца два-три. С твоим чеклистом она будет передаваться очень просто — "делай по списку и отмечай", за пару дней.

Ну и напоследок, еще несколько моментов

Есть два подхода к незаменимости:

1. все дела запутаны, документации не ведется, исполнитель держит все в голове, что приходится записывать — шифруется. Быстро передать кому-то его дела невозможно. Впрочем, невозможно и медленно, потому что он сопротивляется.

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

   
   

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

   
   

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

• Не врать.
• Быть пунктуальным, не опаздывать, но и не приходить на полчаса раньше.
• Не срывать обещанные сроки. Насчет установленных свыше — пытайся предупредить об их нереальности. Это никому не нравится, но хотя бы так.
• Составлять документы грамотно и технически, и в литературном смысле, без орфографических и пунктуационных ошибок, стараться и без стилистических. Доверие к человеку, который не может двух слов связать, ниже, чем к грамотному. Не раз в этом убедишься на своем опыте. Не стесняйся обращаться к Розенталю и Лопатину. Особенно при спорах с коллегами, которые уверяют, что "одеть" — это длинное, как чулок, а "надеть" — это короткое, как шапка, поэтому оплетку на провод одевают, а заглушку на разъем надевают.
• То же относится и к рабочей полуофициальной переписке, тоже проверено.
• Не рассказывать кому попало полученную информацию. "Фильтровать базар".
• Взятое на время у коллег (документы, оборудование) возвращать немедленно после использования. Никогда не забывать, что у кого взято. Никогда не задерживать у себя дольше оговоренного срока, если он был установлен. Благодаря этому тебе будут доверять забирать с собой на время то, что другим не дают совсем, не раз пригодится.
• Не допускать таких промахов, которые явно показывают на работу спустя рукава. Для этого не работай спустя рукава, а от глупых случайных ошибок хорошо помогают чеклисты и TODO.

Внешний вид. Не зря придумана пословица "по одежке встречают, по уму провожают". В тех случаях, когда есть время и возможности показать ум, можно к одежке отнестись проще. Однако на более-менее серьезных встречах, например, с заказчиком, или при сборе подписей под документом оценивать будут порой только по одежке и принимать решения соответственно. Ты еще не раз убедишься: заходишь в кабинет в костюме и при галстуке — получаешь автограф чаще всего сразу. Заходишь в потертых джинсах и футболке — в лучшем случае "оставь, почитаю", в худшем — "отнеси в комнату N, пусть сначала подпишет Такой-то", а это уже надолго. Срабатывает какая-то клановость — раз внешние признаки примерно совпадают, то, наверное, это "наш". Опять же, выбор "нормального" (или, если хотите, нормированного) внешнего вида соответственно представлениям тех, в чьем хорошем мнении ты заинтересован — это еще и показатель серьезного подхода, видно, что ты подготовился. Это не призыв всегда ходить в галстуке. Это намек, что имеет смысл выбирать "прикид" под обстоятельства: если предстоит долгая работа за клавиатурой или стендом, то стоит одеться поудобнее, а если серьезный разговор — то попредставительнее. Все-таки нормальные люди не ходят в оперу в энцефалитке, а в тайгу в лакированых туфлях. Ты это поймешь, я знаю. Но ни одного товарища-неформала убедить в этом не удастся. Ну и ладно.

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

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

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

Постараюсь отправить тебе это письмо при первой же оказии. Надеюсь на тебя. Пока,

Твой я (двадцать с лишним лет спустя).