Первый опыт совместного проектирования

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

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

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

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

Если надо вырастить разработчика

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

Понимание. Есть вещи, которые нужно понимать без объяснений. Код должен быть по общим шаблонам и правилам, но соответствовать текущим решениям. Инициатива наказуема. Если сомневаешься - спроси. Если задача не решается, то проси помощи. И т.д. Т.е. человек должен понимать основы работы в команде.

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

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

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

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

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

Приоритеты команды. У каждой команды есть свои наработанные паттерны общения и поведения. Нужно понять их и научиться применять. Это короткий путь стать частью команды.

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

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

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

Постановка задачи важна

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

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

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

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

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

Отношения в команде

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

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

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

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

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

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

Режим работы и отдыха

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

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

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

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

Собеседование как экзамен

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

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

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

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

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

P.S. На самом деле невозможно подготовиться на 100% и знать всё. Можно вообще ничего не знать, но подходить под требования. А можно знать всё, но не найти общий язык. Я навсегда останусь при своём мнении: если ты способен показать, что можешь решать задачи, для которых тебя хотят нанять, то тебя наймут, даже если ты "без рода и племени". Но готовиться всё равно надо.

Все должны делать ревью

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

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

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

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

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

Отпустить проблему, чтобы решить её быстрее

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

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

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

Незаменимых не бывает

Моя первая официальная работа продолжалась немногим более 3 месяцев. Это было в гос организации сразу же после университета. Тогда я чувствовал себя независимым и ещё плохо понимал, куда мне двигаться дальше. А ушёл то я по причине того, что меня забрали в армию. Только вот теперь я уже был с опытом.

Вторая работа была лучше первой. Меня взяли, потому что у меня был уже нужный опыт. И огромное желание развиваться и расти. Год за годом я рос и в итоге перерос свою должность. Дошло до того, что я мог совмещать две работы. Со временем вторая работа требовала всё больше занятости, и я решил работать на первой работе пол дня, а остальное время на второй. Ведь я же могу. Я же ценный специалист.

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

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

Книги нужно читать

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

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

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

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

Не переделывай всё под себя

"Со своим уставом в чужой монастырь не ходят"

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

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

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

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

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

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

Инструменты разработчика

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

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

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

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

Если предложили новую работу

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

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

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

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

Ещё предлагаю определить для себя принцип смены работы. Можно менять работу раз в несколько лет или при достижение какого-то предела. Если такого правила нет, то можно его завести.

И напоследок можно задать себе общую стратегию или карьерный путь. В этом случае нужно выстроить план и следовать ему. Если всё идёт по плану, то отлично. Так держать!

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

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

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

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

Научитесь писать по русски

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

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

Порой я не понимал текста, когда слово написано с ошибкой или имеет несколько смыслов. Приходилось уточнять, терять время. И тут задаёшься вопросом, а есть ли смысл торопиться, когда пишешь так безобразно? Нет смысла.

Будь моя воля я бы принудительно заставлял пройти курс повышения качества знания русского языка. Или как минимум заставил всех изучить популярные сокращения, чтобы у всех было общее понимание. Ведь мало просто говорить на одном языке, надо ещё уметь понимать сказанное без запинок. Учите русский язык!

Руководите как семьёй

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

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

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

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

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

Отвлекающие решения

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

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

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

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

Самый полезный сотрудник

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

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

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

Если представить, что первый сотрудник попадет на работу ко второму, то он просто не сможет даже близко показать такую же эффективность и на своем месте не задержится. В обратном случае второй сотрудник будет в недоумение, как же так можно неэффективно выполнять свою работу. Но каждый на своём месте вполне эффективен.

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

"Говорящая" система

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

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

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

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

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

Работа ради мечты

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

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

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

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

В итоге идеальной работы не бывает, но бывает максимально подходящая под текущие запросы. Кто ищет тот всегда найдёт.