Старая школа против новых школьных программистов Проблемы и/или преимущества

Ответ 1

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

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

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

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

Ответ 2

Я был по обе стороны забора, так сказать.

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

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

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

Ответ 3

Отличный вопрос. Я занимаюсь этим бизнесом почти 50 лет, и я все еще изучаю вещи.

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

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

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

Ответ 4

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

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

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

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

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

Что касается ваших конкретных проблем до сих пор, здесь можно посмотреть еще один способ:

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

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

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

Ответ 5

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

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

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

Ответ 6

Вам нужно вписаться в группу, они не изменятся в соответствии с вами, но это не значит, что вы не можете постепенно вносить изменения.

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

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

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

Ответ 7

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

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

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

Удачи!

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

• Шаблон с проточным итерационным водопадом (Anti-)
• Модель разработки водопада считается вредной
• Не рисуйте диаграммы неправильных практик - или: почему люди все еще верят в модель Waterfall
• Управление разработкой крупных программных систем (PDF)

Обратите внимание, что последняя - оригинальная бумага Royce.

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Язык. Я имею в виду не только COBOL vs С#, но и слова, используемые для описания проблем и решений. Я часто сталкивался с трудностями в разговорах с более старыми программистами COBOL, потому что нам не хватает общего языка ABENDS, рабочего хранилища (старой школы), методов, автоматизированного модульного тестирования (новая школа) и многого другого. Как и во многих других проблемах в жизни, "знание - это половина битвы"; как только вы распознаете проблему, вы можете ее преодолеть.

Ответ 11

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

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

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

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

Ответ 12

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

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

• Разработчики, которые считают, что они достаточно хороши и просто "выполняют свою работу", и не заинтересованы в росте в качестве разработчика.

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

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