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

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

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

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

Во всяком случае, это нормально? По моему мнению, я делаю работу, эквивалентную целой команде разработчиков.

Был ли я идиотом, когда изначально ожидал, что все будет иначе?

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

PS Моя зарплата почти равна, если не ниже, чем у кассира в супермаркете.

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

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

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

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

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

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

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

В идеале все входящие запросы следует вводить в систему отслеживания проблем, такую ​​как JIRA или Mantis . Или, по крайней мере, отправлено по почте владельцу продукта, а не вам. И он / она должен также рассмотреть все жалобы пользователей на «почему мой запрос еще не готов ?!», что позволит вам сосредоточиться на работе по разработке. Если это недостижимо, вам следует, по крайней мере, договориться о некоторых временных окнах, когда вы просматриваете входящие запросы и обрабатываете их, резервируя непрерывную часть своего времени исключительно для разработки.

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

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

Таким образом, у вас есть приблизительное представление о том, что вы будете делать в ближайшие одну или несколько недель. Более того, это дает дорожную карту и вашим клиентам: они могут видеть, когда они получают, какой запрос реализован. Вы можете или не хотите упоминать слово «agile» своему менеджеру здесь - это в основном гибкая разработка , но некоторые люди выступают против agile, даже не зная, что это такое :-)

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

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

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

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

PS Моя зарплата почти равна, если не ниже, чем у кассира в супермаркете.

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

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

Есть несколько дополнительных мыслей по этой теме.

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

2. Связь. Четко сообщайте о своей неспособности оправдать нереальные ожидания. В моем подобном опыте архитектор (который сделал больше всего лопатой) сказал: «Вы должны управлять другими ожиданиями от себя».

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

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

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

Вы имеете дело с несколькими проблемами здесь ... Давайте начнем с очевидного ...

Это нормально?

Конечно нет. Но ... это распространено? К сожалению, да.

Относительно исправления ошибок

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

Поверхность для большего количества ошибок и затрат

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

Шум / туман в ваших логах

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

Так что, будучи новым наемным работником, еще более разумно попросить вас воздержаться от рефакторинга и / или усовершенствования программного обеспечения, и вполне нормально, чтобы я был настолько «хирургическим», насколько это возможно с вашими исправлениями ошибок. Это просто держит головные боли в страхе.

Можете ли вы сделать что-нибудь об этом?

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

Проект из ада

Дерьмовый код, Стадо программистов, Дублирование, Дерьмовая архитектура

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

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

Добро пожаловать в промышленную разработку программного обеспечения!

И ты знаешь, что весело? Это часто намного хуже в мире веб-разработки. Наслаждайтесь! :)

Слишком много проектов и запросов, не хватает рук и времени

Проблема заключается здесь, вероятно, в:

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

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

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

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

• что ты можешь сделать ,
• что ты хочешь сделать ,
• и что вы готовы сделать .

Так что это также частично ваша вина, что вы позволили этому стать таким. Но это нормально, это урок, который должен выучить каждый. Это имеет место в двух букв: N - O .

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

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

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

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

Запросы на изменение на 180 градусов

Это еще одна большая проблема. Они, вероятно, не ваша вина, но вы можете попытаться помочь им решить эту проблему.

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

Обычно, когда кому-то нужно позвонить (или, что лучше, встать на ноги), схватить заинтересованных лиц за руку и четко сказать им: «Это то, где мы находимся, это то, куда вы хотите, чтобы мы пошли, подтверждаете ли вы, что мы движется в правильном направлении? Можно не получать четких ответов в начале, но чем больше времени проходит, тем яснее они должны стать, или этот проект - катастрофа, ожидающая своего появления.

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

Если нет места, нет четких требований в конце обсуждения.

Перегрузка электронной почты

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

• разговаривать с людьми лицом к лицу ,
• разговаривать с людьми по телефону,
• разговаривать с людьми через IM,
• разговаривать с людьми по электронной почте.

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

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

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

Выполнение команды стоит

Вы делаете эквивалент работы команды? Может быть.

Вы делаете эквивалент работы вашей команды? Возможно нет.

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

Был ли я идиотом, когда изначально ожидал, что все будет иначе?

Нет; просто новичок в вечеринке. Это как первое похмелье или отношения. Вы преодолеете это.

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

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

PS Моя зарплата почти равна, если не ниже, чем у кассира в супермаркете.

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

При этом, если вам сильно недоплачивают, вы слишком много работаете и не совсем младше, попросите повышение или получите новую работу!

Это просто:

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

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

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

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

В дополнение к комментариям других людей:

1. Да, это нормально, когда сотруднику начального уровня дают работу, которую никто другой не хочет делать.

2. Вы должны увидеть это как строительный блок для вашей будущей карьеры.

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

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

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

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

Ваша ситуация немного острая, но все же нормальная. Но то, как вы справляетесь с этим, очень плохо. Вот что вам нужно сделать:

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

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

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

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

• Нет переключения проекта в течение дня. Сегодня вы просто работаете над проектом X, и завтра вы начнете выполнять другое задание для Y.

• Выделите один час в день на содержание ворот. Это означает небольшие задачи, которые тривиально сделать. Если эта задача занимает более 10 минут (неважно, в чем причина), она уходит в отставание, и вы уведомляете менеджера, что она будет отложена.

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

Итак, давайте сделаем несколько простых ролевых игр. Есть три менеджера и проекта (Xavier с проектом X, Yvonne с проектом Y и Zed с проектом Z). У вас есть задержка на две недели, 5 дней для X и 5 дней для Y.

• Z просит вас выполнить какое-то задание (1 день)
• Вы отвечаете, что это будет сделано за 11 дней.
• Z отвечает, что это простая задача, и она не должна занимать более одного дня (обратите внимание, что Z оказывает небольшое давление).
• Вы отвечаете, что в настоящее время работаете на X, а на Z - позже. После этого вы можете выполнять ее работу.
• Z отвечает, что вы должны выполнить его задачу немедленно в любом случае (повышенное давление, прямое нарушение X и Y территории).
• Вы отвечаете, что выполнение ее задачи задержит работу для X и Y. Он должен сначала спросить их. Вы также CC X и Y.

Теперь есть два конца:

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

• Ничего не произойдет, Z спросит вас через два дня, где его задача. Вы отвечаете, что в настоящее время работаете на X, а он ничего не упомянул о проекте Z. Снова CC X.

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

Семь лет назад я какое-то время выполнял почти 100% техобслуживание и написал об этом статью «Искусство программирования сопровождения» . Одна часть, которую вы можете найти полезной:

1. Получить, как это

Как кто-то может любить программирование обслуживания? Разработчики мечтают стать главными архитекторами в своих командах, и когда они заканчивают обслуживанием существующего программного обеспечения, это выглядит почти как наказание. Это не должно быть так: программирование обслуживания имеет свои собственные проблемы и требует большой креативности, адаптивности, терпения, дисциплины и хорошего общения. Это может быть полезно и для вашей карьеры: наличие в вашем резюме напыщенных записей типа «Архитектурное корпоративное приложение n-уровня 24/7» выглядит неплохо, но работодатели действительно ценят людей, которые решают проблемы; и программирование технического обслуживания может быть хорошим шансом продемонстрировать свои навыки решения проблем.

Ваша проблема звучит как что-то, о чем вы слышите чаще. Похоже, это работа, которая может легко поместиться в The Daily WTF .

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

Вы также можете прочитать Стив Макконнелл о технических долгах . У него есть несколько интересных моментов. В Google Tech Talk Кен Свабер рассказывает о гибкой разработке программного обеспечения . Хорошая часть рассказывает об истории, похожей на вашу. Он рассказывает о программном проекте, который стал «мозговой смертью» после 10 лет программирования различными программистами без какого-либо рефакторинга . Я думаю, что если вы посмотрите это видео, вы увидите много общего с тем, что вы описываете.

Любая система программного обеспечения будет ухудшаться по качеству при расширении. На самом деле для того, чтобы обслуживать его, придется. В Леман законы объясняют этот принцип достаточно хорошо. В конечном итоге все сводится к следующему вопросу: «Как мне убедить вашего босса провести рефакторинг?» ,

Как я подошел к аналогичной проблеме:

• Я столкнулся с моим боссом и объяснил, что качество кода ухудшается, когда мы продолжаем разрабатывать ( Lehman Laws ).
• Я попытался объяснить своему боссу понятие технического долга . И то, как он позволяет вам работать, - это способ, который в конечном итоге будет стоить ему денег.
• Чтобы показать ему, насколько серьезной была проблема, я (в свое время) провел статический анализ кода. Боссы не понимают программного обеспечения, но они понимают цифры. Хотя у метрик кода есть свои недостатки, хорошо иметь что-то измеримое, о чем вы можете поговорить. Попытайтесь выяснить, каковы нормальные показания для этих метрик, и вы будете удивлены, когда вы сравните это со своей собственной кодовой базой.
• Если ничего не помогает и ничего не меняется, единственное, что вы можете сделать, - это объяснить, что определенная новая функция потребует некоторой переделки других частей вашей кодовой базы. Объясните: если у вас есть дублирующийся код, и они хотят что-то изменить, то дублируются и затраты на изменение.
• Распространенным ответом на предыдущий вопрос будет то, что никто не спросил и, следовательно, не заплатил за эту переделку. Это «возможно», эта переделка излишня. Вам придется объяснить, что программное обеспечение всегда будет меняться. Как говорят законы Лемана ; это должно будет измениться, чтобы остаться в использовании. Если нет, другие программы, которые изменились, всегда будут жить. Выживут те, кто ожидает перемен и может адаптироваться к ним. Вот что такое гибкая разработка программного обеспечения . ( Википедия )

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

Ситуация, с которой вы сталкиваетесь, почти (если не полностью) одинакова для многих новичков.

Это происходит на начальных этапах карьеры. Здесь есть одна загвоздка: мы должны преодолеть эту проблему и доказать нашу ценность для компании (будь то средние или MNC ). Мы должны иметь возможность принимать решения о том, что обстоятельства требуют от нас. Таким образом, нет ничего плохого в том, чтобы прилагать усилия в работе, при условии, что вас заметят за это и вы станете личностью для своей работы. Если вы стоите, компания заметит! Адиос и удачи.

На мой взгляд, на компанию, которая запрещает рефакторинг, работать не стоит. Рефакторинг - важный навык разработки программного обеспечения, а инструменты контроля версий позволяют очень легко разрабатывать изменения изолированно, не повреждая «ствол» (в случае, если рефакторинг действительно что- то ломает). Как говорит дядя Боб (перефразируя): «Вам не нужно просить быть профессионалом и делать свою работу правильно».

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

Я получил это письмо пять лет назад от одного из моих друзей.

Email body:    

Вновь вступивший в должность инженер-стажер спрашивает своего босса "в чем смысл оценки?"

Босс: "Вы знаете смысл отставки?"

Стажер: «Да, я делаю»

Босс: «Итак, позвольте мне дать вам понять, что такое оценка, сравнивая ее с отставкой»

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Стажер: «Да, босс, хватит, теперь я понял свое будущее. Для оценки мне придется уйти в отставку ... !!!»

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

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

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

Я думаю, что в вашем вопросе есть тонкий намек на недостаток в вашем подходе. То есть исправление ошибок не требует улучшения кода.

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

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

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

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

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

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

NB: я чувствую, что некоторая атрибуция для этого ответа должна пойти Джеффу Этвуду, видя, как я связал 3 из его статей.

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

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

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

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

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

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

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

2. Вести точный журнал, чтобы записывать, сколько времени вы тратите на кодирование, встречи и ответы на электронные письма. Это защитит вас, если вы отстанете от графика.

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

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

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

Удачи.

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

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

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

Удачи, и я надеюсь, что и вы, и ваши коллеги понимают серьезность ваших усилий!

Личный опыт

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

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

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

Зарплата

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

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

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

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

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

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

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

4) Если вы не счастливы, уходите! Жизнь слишком коротка, чтобы иметь дело с глупыми людьми.

Всего наилучшего.

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

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

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

Единственный способ разорвать эту цепочку - это разработать новую инфраструктуру, разработанную для обеспечения гибкости и полностью протестированную на единицу + интеграцию.

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

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

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

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

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

Что касается ваших условий работы, попросите возглавить новую инфраструктурную группу, которая занимается этими проблемами (на основе ваших определений и дизайна), и привлекать новых разработчиков для поддержки старых вещей, пока вы помогаете им в случае необходимости (до 10-20% время). Если руководство соглашается с этой идеей, вы можете попросить пересмотреть условия. Будьте готовы найти другую работу, если они откажутся. (Помните, что ваша работа требует навыков, знаний и опыта, вас не так легко заменить, как платят, чтобы вы поверили.)

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

Мне кажется, что ваш первый порт захода - положить все это на стол вашего менеджера. Никто не должен приходить к вам напрямую. Проблемы должны поступать через тех, у кого такие поля - обычно это команда поддержки. Это нормально, что вы поддерживаете свой код в течение короткого периода передачи - обычно недели или около того. Изменения должны стоить и начисляться (трансфертная зарядка) в любой компании, которая классифицирует себя как «среднего размера», и это кажется обойденным (неудивительно, что они затопляют вас - вы как шлюха на выпускном вечере).

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

Если ваша компания не предлагает ничего из этого и ожидает, что вы справитесь с этой несметной массой случайных запросов и будете нести ответственность за нее, тогда серьезно стоит подумать о том, чтобы двигаться дальше. Плата всегда низка - на моей первой работе по программированию (почти 25 лет назад) я потратил 8 лет на одну и ту же компанию, и моя зарплата немного выросла (хотя она всегда была намного выше, чем у кассира!). Через 2 года после ухода я удвоил его - и через два года я забрал домой в десять раз больше, чем начал (но тогда был независимым подрядчиком). Как всегда, зарабатывайте себе шпоры, изучайте свою профессию и прыгайте с корабля в теплое окружение.

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

Я делаю слишком много вещей с A, B и C. Я не могу поддерживать это. Честно говоря, и без обид, я собираюсь выйти из этой комнаты с этим либо исправленным, либо с моим письмом об отставке, оставленным с вами. Теперь, когда все это в воздухе, как мы можем работать вместе, чтобы сделать это правильно? "

Ответ состоит в том, чтобы попытаться объяснить это в терминах, которые можно понять;

• Это как замена масла. Они не срочные .... но должны выполняться регулярно, тем не менее
• закрасьте ржавчину, и она будет отлично смотреться. Пока не истечет кровью
• построить новый стол на крыше патио без крепежных опор. Это может работать некоторое время, может быть. Тогда это рухнет и повредит людям, и вы будете нести ответственность.
• кондиционер отличный. Оконный блок отлично подходит для одной или двух комнат. Попытка установить 146 оконных блоков в многоквартирном доме, и у вас будут ... проблемы.
• Обучение 5 детей в порядке. 10 не так уж плохо. Но есть ограничения. Попробуйте неформально обучать 75 детей, и вы увидите это.

Если это не резонирует. Оставьте - ДЕНЬ, КОТОРЫЙ ВЫ ПОЛУЧАЕТЕ ПРЕДЛОЖЕНИЕ ПО ПИСЬМУ, а не на следующий день! После того, как вы получили новую работу, оставьте с нулевым уведомлением. Буквально просто не приходи в тот день. Но убедитесь, что у вас есть коллега или два, которые знают, что вы сделали. Это на самом деле поможет компании, если она может помочь, показав им, что их неуважение и высокомерие имеют свою цену. Последняя компания, в которой я был на ТРИ ИЗ ЧЕТЫРЕХ ТЕКА, ОСТАЛАСЬ ЗА 6 МЕСЯЦЕВ, БЕЗ РАБОТЫ. По крайней мере, он сделал заявление и дал уходящему человеку хороший шанс сказать: «Да, хорошо, что вы говорите каждый день, но вы так переполнены, что я даже не удовлетворяю ваше замечание.

Наконец, знайте, что это положение дел было NORM и стандартом 20 лет назад, прежде чем agile, tdd, bdd и рефакторинг стали более чем нормой. Возможно, вы разговариваете с высокопоставленными людьми, которые сразу же отвечают: «Ну, я сделал это сам, и это сработало, бла, бла, бла». Ну, лошади и кареты хорошо работали 150 лет назад. В области технологий техника 20 лет назад так же устарела, как и транспорт 150 лет назад. Если они отклонят это нормально. Просто знайте, что они никогда не будут нанимать приличных разработчиков современных технологий, которые останутся без дела. Они получат худшее из худшего, и это ужасно повредит их бизнесу. Если они зависят от технологий и не могут адаптироваться, они потерпят неудачу, и в конечном итоге это может стать для вас лучшей наградой. Это'

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

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

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

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

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

Быть героем в команде из одного человека может только выгнать вас.

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

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

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

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

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

а) Для работы необходимо отставание от предметов. Вы поместили свой план по улучшению кода в отставание.

б) все ошибки уходят в отставание

в) Отставание становится приоритетным.

г) Вы делаете все в приоритетном порядке.

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

Проще всего, если вы просто делаете рефакторинг улучшений постепенно, когда вы пропускаете разделы, в которых есть проблемы / ошибки, которые нужно исправить. Тогда вы можете сказать руководству: «Я должен был исправить A, но B был принципиально сломан, и мне пришлось делать решение C, чтобы все это исправить, чтобы в будущем D было легче / дешевле», где A = ошибка, B = анти-паттерн, C = решение, D = будущие выгоды

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

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

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

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