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

Часть вторая: гибкость

Иногда это просто должно работать

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

Принимайте идеи (и замыслы) других

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

Выйдите из своей зоны комфорта

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

У всех бывают плохие дни (включая тебя)

Это еще одно, что я не мог решить, отнести ли его к командной работе или гибкости, но в любом случае это правда. Тот факт, что кто-то не может понять концепцию, которую вы пытаетесь объяснить, не делает его глупым. Возможно, они устали или весь день работали над сложными задачами и выгорели. Будьте добры, ведь у вас тоже будут выходные. Кроме того, не будьте слишком строги к себе. Легко чувствовать себя неадекватным, когда вы новичок в команде (во многих сообщениях в блогах говорится о синдроме самозванца). Не корите себя, вы просто больше устанете и потеряете уверенность. Просто смиритесь с тем, что у всех нас бывают плохие дни, но вы хороший программист, вам просто нужно продолжать работать над этим.

Неожиданные проблемы

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

Не просто код-обезьяна

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

Не просто парень/девушка Java

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

Это вторая часть, вернитесь на следующей неделе к третьей части: Планирование! (редактирование: третья часть уже доступна и ее можно найти здесь)

-Майк Джи