Я занимаюсь 90% обслуживания и 10% развития, это нормально? [закрыто]

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

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

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

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

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

Я был идиотом, когда изначально ожидал, что все будет по-другому?

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

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

371 голос | спросил 6 revs, 6 users 49%
TiredProgrammer
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

28 ответов


217

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
119

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

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

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

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

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

Вероятно, вы хотите сохранить часть своего времени для входящих запросов на экстренную помощь, но все остальное можно планировать заранее. И вы также можете предпочесть организовать работу над различными проектами на отдельные «полосы», то есть работать над проектом A в понедельник, проектом B на Tueday-Wednesday, проектом C в четверг утром и D днем ​​и т. Д., Чтобы уменьшить переключение контекста.

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
107
  

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
35

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

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

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

  2. Связь . Четко сообщите о своей неспособности достичь нереалистичных ожиданий. По моему аналогичному опыту, архитектор (который делал наибольшую выгоду) сказал: «Вы должны управлять другими ожиданиями от вас».
  3. Burnout . Если вы не испытали выгорания, не искушайте судьбу. Это отвлекает вашу жизнь и душу от вашего ума. Несмотря на все ваши усилия, ваша рабочая задача становится серой, унылой и бессмысленной. Я передаю этот совет, потому что вы, во что бы то ни стало, избегаете выгорания.
  4. Обучение . Вот серебряная подкладка. Ваше обучение и опыт, несмотря на разочарование и, возможно, недоплату, на самом деле очень ценны для вашей карьеры. Это ваша спасительная благодать, чтобы понять это, потому что вы можете впитать как можно больше знаний и задержать неизбежный стеклянный потолок.

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
31

Здесь вы имеете дело с несколькими проблемами ... Начнем с очевидного ...

Является ли это нормальным?

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

Что касается разочарования в исправлении ошибок

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

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

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

Шум /туман в ваших журналах

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

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

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

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

Проект из ада

Код дерьма, стадо программистов, дублирование, архитектура хруста

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

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

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

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

Слишком много проектов и amp; Запросы, Недостаточные Руки & Время

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

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

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

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

  

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

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

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

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

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

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

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

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

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

«180-дегрессивные запросы на изменение», так как вы красиво и настойчиво называете их, являются ясным признаком того, что требования нечеткие от get go, и что никто не пытается достаточно усердно, чтобы их выточили и с течением времени.

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

Обычно я бы сказал, хватаю всех заинтересованных сторон, доставляющих их в комнату, прогоняю их по спорным вопросам и постепенно пытаюсь решить их - и получаю приоритеты, пока вы на нем. Однако в вашем случае это может быть не ваш призыв сделать уже. Но вы упомянули, что они действительно дали вам ответственность за проекты; так что если это действительно так, тогда возьмите ответственность и сделайте это. И НЕ УДАРАЙТЕ от , мы НЕ МОЖЕМ сделать это « или даже », мы НЕ сделаем этого «. Очень важно ограничить объем проекта.

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

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

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

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

E-Mail хорош для отслеживания, получения подтверждений, для отправки заметок.

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

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

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

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

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

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

  

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

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

  

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

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

  

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

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

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

Это просто:

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

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

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

  • вы можете измерить для себя , если вы эффективно сделали намного больше, чем ваши сверстники или нет,
  • вы можете оставить свою землю , если они скажут, что ваш запрос не оправдан.
ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
29

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

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
21

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

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

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

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

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

  • Нет переключения проекта в течение дня. Сегодня вы просто работаете над проектом 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.

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
16

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

  
  1. Получить, чтобы понравиться
  2.   

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
9

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
7

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
7

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
5

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

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.              |
|---------------------------------+----------------------------------|

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
4

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
3

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

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

  

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

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

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

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

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

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

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

Удачи.

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

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

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

Личный опыт

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

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

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

Доход

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

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

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

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

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

Все самое лучшее.

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
2

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
1

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

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
1

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
1

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
1

Ответ заключается в том, чтобы попытаться объяснить его в терминах, которые могут быть поняты;

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
0

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
0

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
0

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

a) Для работы вам нужно отставание элементов. Вы планируете улучшить код в отставании.

b) Все ошибки попадают в отставание

c) Недостаток имеет приоритет.

d) Вы делаете все это в порядке приоритета.

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
0

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132