Comments 102
Моя теория нехватки хороших старших разработчиков — их не слишком много, так как я много раз видел, как люди из хороших разработчиков превращались в плохих менеджеров из-за желания увеличить влияние, зарплату или по еще каким-то причинам. Очень рад за компании, где у старших разработчиков нет, по крайней мере, финансовых причин делать такой, часто неудачный, вираж в карьере.
Еще с сожалением отмечу. что «дерзких умных» молодых ребят все меньше. Из университетов все чаще стали приходить просто «дерзкие».
Это все личная практика, не хочу никого обидеть.
Еще с сожалением отмечу. что «дерзких умных» молодых ребят все меньше. Из университетов все чаще стали приходить просто «дерзкие».
Это все личная практика, не хочу никого обидеть.
Проблема скорее в том, что умные постоянно участвую в разного рода олимпиадах. Задачи из реального мира и некоторые приемы при их решении ставят выпускников в тупик. А те, кто может их решить быстро — скорее всего уже имеют неплохую работу.
Умные постоянно участвую в разного рода олимпиадах
Мне это в свое время надоело.
Я люблю решать сложные задачи, но мне не нравится постоянно находиться в состоянии цейтнота.
Поэтому я не участвую в олимпиадах, но регулярно решаю разные интересные задачки на логику.
При этом часто даже нет смысла писать код — если алгоритм понятен, и его сложность можно оценить без кодинга, я на этом останавливаюсь. Тратить время на кодинг в данном случае является нецелесообразным — лучше закодить какойн-ть полезный инструмент, который позволит убыстрить написание или анализ кода, от этого куда больше пользы.
В одной книжке по менеджменту автор рассказывал, что многие его подчинённые зарабатывали гораздо больше него. Почему он платил им так много? Во-первых, чтобы они не пытались занять его место, а во-вторых, чтобы удержать их в фирме. К сожалению, в России только высокая должность может гарантировать высокий доход, профессиональные навыки часто уходят на второй план.
К сожалению, во многих компаниях рост возможен только из разработки в менеджмент, типа разработчик -> старший разработчик -> ведущий разработчик aka руководитель группы/отдела.
Если человек — прирожденный разработчик и в менеджменте ему делать нечего — то и вырасти он не сможет. А расти на позиции разработчика зарплата не позволяет, такие уж рамки заданы свыше. Вот и получается, что человек ради роста вынужден заниматься не своим делом, хотя вот решение-то на поверхности: плати больше и пусть человек делает то дело, которое он умеет делать, и все будет хорошо.
Если человек — прирожденный разработчик и в менеджменте ему делать нечего — то и вырасти он не сможет. А расти на позиции разработчика зарплата не позволяет, такие уж рамки заданы свыше. Вот и получается, что человек ради роста вынужден заниматься не своим делом, хотя вот решение-то на поверхности: плати больше и пусть человек делает то дело, которое он умеет делать, и все будет хорошо.
Кстати, в подтверждение пример с небезызвестным Марком Руссиновичем, который долгое время был в Майкрософте на должности Technical Fellow и только через 9 лет (в сентябре прошлого года) сменил должность на CTO. Что-то мне подсказывает, что все это время дело у него было интересное и платили ему не мало.
Дело не только в конкретных компаниях и дело не только в конкретной профессии. Недавно проскальзывала статейка, в которой автор говорил (в том числе и) о том, что с развалом СССР был поломан и институт специалистов.
Поэтому «у них там» с сеньорами плохо, а «у нас тут» (в Росиии) ещё хуже, есть дополнительные факторы.
Обратите внимание, что в социальном плане изменилось, причем радикально, по отношению к СССР: у нас вообще исчезла понятие социальной группы специалистов.
В СССР на уровне и социального, и государственного вопроса для специалистов была специальная вертикаль, иерархия.
Были менеджеры – руководители, партхозактив в советское время, а были специалисты, у которых была своя вертикаль, начинавшаяся с отраслевых отделов ЦК, с госкомитетов по науке и технике, дальше располагались соответствующие министерства, при них были отраслевые институты, параллельно с ними была академическая наука, конструкторские бюро и подобные вещи.
Так можно делать карьеру начальника – становились начальниками по производственной линии: участок, цех, завод, главк, министерство, ведомство.
Можно было по партийной линии, а можно было расти по линии специалиста.
Стать инженером, главным инженером, главным инженером проекта, руководителем проектного института, руководителем конструкторского бюро, и по этой линии дорасти практически до начальника крупного КБ, это были, по сути, люди в ранге министра. То есть по этой линии можно было дорасти до высших ступеней в социально-общественной иерархии.
А сейчас такого понятия просто не существует.
Сейчас человек или начальник, или не начальник, никаких специалистов даже по формальной лесенке роста не существует в природе.
Это одно из радикальных последствий повреждения социальной ткани, потому что механизм был разрушен, а нового просто не создано.
Поэтому «у них там» с сеньорами плохо, а «у нас тут» (в Росиии) ещё хуже, есть дополнительные факторы.
«разработчик -> старший разработчик -> ведущий разработчик» — это классический рост (вертикальный). А вот из программиста в менеджера — это горизонтальное перемещение, потому как технический трек и менеджерский трек — это отдельные вещи, и нельзя сказать, что один находится ниже другого.
Так может искать не в университетах?
Из университетов все чаще стали приходить просто «дерзкие».
истину глаголите!
Скорее всего, такие же, какие и были. Просто с возрастом многие бывшие студенты все больше отдаляются от нынешних и смотрят на них свысока. Они подрастут, будут тоже самое говорить о следующем поколении. Поколение, предшествующее вам, также утверждает, что их поколение было лучше.
У многих родители говорили подобное «вот в мои времена все были такими-то ..., не то что в нынешние». Сейчас их выросшие дети тоже самое говорят своим детям. Если подобные утверждения были бы правдой, то самыми идеальными людьми были первобытные)
У многих родители говорили подобное «вот в мои времена все были такими-то ..., не то что в нынешние». Сейчас их выросшие дети тоже самое говорят своим детям. Если подобные утверждения были бы правдой, то самыми идеальными людьми были первобытные)
Может и так, но только частично. Когда человек не может даже сказать что он делал, но при этом «крутой» программист. У меня к концу первого семестра была (а я инженер-электрик) хорошо продуманная платформа на VB для наших курсовых, в результате курсовики штамповались… Быстро. Да, приходлось время от времени делать какие-то мутации, что бы совсем уж преподов не раздражать, но из-за непрофильности — закрывали глаза (информатика была только 1 семестр). Система работала на меня два года, потом отошёл от дел и был удивлён, когда на 4 курсе меня цепляет препод и выдаёт: «вы надоели уж нас своими глистами кормить!» Глисты — там таблица главная называлась gList, и, пожалуй, единственное место, которое не подвергалось мутации :) Так вот, оказывается платформа стала работать на других людей, прожила почти до окончания учёбы. Сейчас улыбку умиления вызывает, да и скажи соискатель такое — я бы тоже улыбнулся, но не снисходительно, а по доброму — он как минимум продумал над унификацией задачи, сделал платформу легко, такой человек даже если что не знает — научится: главное придумать решение, а неэффективность кодирования можно на ревью обсудить (многие, наверное, прохидили через передачу std::vector по значению в функции...).
Дальше, после 3 курса я уже постигал «мягкий» embedded в лице RTOS ОС2000, спеки Posix, XLib, набивал первые шишки в многопоточном программировании. Повезло, подвернулась работка? Может, но обычно везёт тем, кто хочет. Плюс, считаю, что студенчество это огромная возможность для набора опыта, как никак поддержка от семьи ещё есть, можно браться за более интересную работу, нежели за более оплачиваемую, где можно что-то делать от и до, набивая свои шишки. К концу 4 курса такой бекграунд уже позволил устроиться в достаточно серьёзную контору в нашем городе (тот момент когда стало нужно больше денег, хотя интерсность работы снизилась разительно), да, багофикс, рутина, но: первый опыт работы в большой распределённой команде, первые понятия о качестве кода, первое знакомство с системами контроля версий, процесса ревью, тикетов и т.п.
Сейчас же и интернет копейки стоит и проектов куча, где-бы не помешало, что допилить, доделать и всегда можно ткнуть в свою фамилию в логе коммитов :) Или на свои проекты в сети. Тут кстати, минус некоторым собеседователям, которые резюме читают прямо на собеседовании и задают вопросы, ответы на которые там есть. Как полиция проверяет, твой ли паспорт: дата рождения, прописка :)
Дальше, после 3 курса я уже постигал «мягкий» embedded в лице RTOS ОС2000, спеки Posix, XLib, набивал первые шишки в многопоточном программировании. Повезло, подвернулась работка? Может, но обычно везёт тем, кто хочет. Плюс, считаю, что студенчество это огромная возможность для набора опыта, как никак поддержка от семьи ещё есть, можно браться за более интересную работу, нежели за более оплачиваемую, где можно что-то делать от и до, набивая свои шишки. К концу 4 курса такой бекграунд уже позволил устроиться в достаточно серьёзную контору в нашем городе (тот момент когда стало нужно больше денег, хотя интерсность работы снизилась разительно), да, багофикс, рутина, но: первый опыт работы в большой распределённой команде, первые понятия о качестве кода, первое знакомство с системами контроля версий, процесса ревью, тикетов и т.п.
Сейчас же и интернет копейки стоит и проектов куча, где-бы не помешало, что допилить, доделать и всегда можно ткнуть в свою фамилию в логе коммитов :) Или на свои проекты в сети. Тут кстати, минус некоторым собеседователям, которые резюме читают прямо на собеседовании и задают вопросы, ответы на которые там есть. Как полиция проверяет, твой ли паспорт: дата рождения, прописка :)
Сейчас же и интернет копейки стоит и проектов куча, где-бы не помешало, что допилить, доделать и всегда можно ткнуть в свою фамилию в логе коммитов :) Или на свои проекты в сети.Из моего опыта прохождения собеседований, подавляющее большинство интервьюеров не заморачиваются чтением публикаций, исходников и прочего. В плане получение плюсов на собеседованиях толк от всего этого близок к нуля. Что не смог рассказать, то вранье.
Некоторые вообще бред требуют — сделайте наше тестовые задание, чтобы мы могли понять, что вы умеете программировать. Тестовое задание частенько уровня «сделать поиск строки в файле и посчитать хэш файла». А по исходникам готового проекта на гитхабе они значит не могут понять, может ли человек программировать или нет.
То же самое и на собеседованиях. Не сделал на бумажке во время собеседования по каким-то причинам, всё, ты в их глазах не программист. Неважно, что ты проекты успешно делал на 100k строк и можешь показать исходники.
Тут кстати, минус некоторым собеседователям, которые резюме читают прямо на собеседовании и задают вопросы, ответы на которые там естьБыла у меня мысль перед собеседованиях задавать вопрос, аналогичный вопросу «расскажите, что вы знаете о нашей компании»: «расскажите, что вы узнали обо мне».
Вы путаете базовый смысл в сказанном.
Речь не об общечеловеческих понятиях лучше/хуже. Речь о понтах.
В поколении моих родителей, большинство прекрасно знало, что надо закончить институт, потом пойти (условно) на завод, там проработать пару лет младшим помощником, потом стать инженером и т.д. и т.п.
Они понимали, что после института они, в общем-то, пока никто.
В моем поколении, большинство так же понимало, что надо пахать. Устраивались на любую работу лишь набрать опыта по своей специальности.
Текущее поколение, с которым приходится общаться, они начитались про всяких цукербергов и считают что им должен весь мир. (для тех кто на бронетехнике напомню, речь идет о большинстве, а не об абсолютно всех).
Они не могут толком двух слов столкнуть на собеседовании, не могут объяснить чем занимались. Не могут толком ничего. Но хотят ЗП «отстатыщьбаксов», отдельный кабинет, бентли и секретаршу.
Это чистой воды понты. Ничем не подкрепленные.
Вот об этом и речь. А не о том, кто лучше/хуже.
Речь не об общечеловеческих понятиях лучше/хуже. Речь о понтах.
В поколении моих родителей, большинство прекрасно знало, что надо закончить институт, потом пойти (условно) на завод, там проработать пару лет младшим помощником, потом стать инженером и т.д. и т.п.
Они понимали, что после института они, в общем-то, пока никто.
В моем поколении, большинство так же понимало, что надо пахать. Устраивались на любую работу лишь набрать опыта по своей специальности.
Текущее поколение, с которым приходится общаться, они начитались про всяких цукербергов и считают что им должен весь мир. (для тех кто на бронетехнике напомню, речь идет о большинстве, а не об абсолютно всех).
Они не могут толком двух слов столкнуть на собеседовании, не могут объяснить чем занимались. Не могут толком ничего. Но хотят ЗП «отстатыщьбаксов», отдельный кабинет, бентли и секретаршу.
Это чистой воды понты. Ничем не подкрепленные.
Вот об этом и речь. А не о том, кто лучше/хуже.
Еще с сожалением отмечу. что «дерзких умных» молодых ребят все меньше. Из университетов все чаще стали приходить просто «дерзкие».
Они (подростки) сегодня обожают роскошь, у них плохие манеры и нет никакого уважения к авторитетам, они выказывают неуважение к старшим, слоняются без дела и постоянно сплетничают. Они всё время спорят с родителями, они постоянно вмешиваются в разговоры и привлекают к себе внимание, они прожорливы и тиранят учителей…Сократ
Ненавижу, когда начинают говорить такими категориями, как «поколение», «раса», «класс». Это недостойно красивого ума, я Вам гарантирую. Университеты в нашем делем непричем, вы, как связаный с IT человек должны прекрасно понимать, что мы живем в удивительную эпоху открытой информации. Я могу прослушать лекции лучших университетов мира(MIT, например), провести качественный контроль знаний и не получить «высшего образования».
и не получить «высшего образования».
тут слово университет не ключевое. Я хоть и закончил его, но по образованию — инженер-электрирк. У нас информатика один семестр была. На вышке «забыли» теорию вероятности пройти. Зато на глаз могу определить на какое напряжение ЛЭП, где какое РУ на подстанции, где трансформаторы, где выключатели, а где размыкатели или сборные шины :) У меня коллега был без вышки — толковый малый. Короче, тут больше, ключ — «молодых ребят».
А самообразование это просто ахиважное и необходимое явление в нашей отрасли. Вышка сейчас, больше рудимент нашего трудового законодательства. Хотя и не везде: лечь под нож хирургу-самоучке я бы не решился. Хотя вероятность попасть на хирурга с образованием, но методом — тут срастили, там срастили, всё равно остаётся.
"… как люди из хороших разработчиков превращались в плохих менеджеров из-за желания увеличить влияние, зарплату или по еще каким-то причинам."
Не всегда это их желание, часто это давление со стороны начальства и семьи.
Не всегда это их желание, часто это давление со стороны начальства и семьи.
UFO just landed and posted this here
Поразительно, но как раз к 35 воля и подводит некоторых. Семья становится больше, работа ответственнее, первые проблемы со здоровьем появляются. Груз такой большой, что никакой воли не хватит, что-то изменить. Да и зачем? Ведь ты так долго к этому шел.
Именно, мы говорим не о сферическом мужике из Болливудского блокбастера.
Да полно таких случаев, когда людям предлагают повышение, а отказаться они не могут, хотя и не готовы к новым требованиям.
Да полно таких случаев, когда людям предлагают повышение, а отказаться они не могут, хотя и не готовы к новым требованиям.
Разработчик на то и разработчик, чтобы разобраться в проблеме.
Что мешает интерполировать процесс разработки системы на жизненные ситуации?
Системный анализ работает не только с автоматическими системами.
Старшие разработчики также хорошо работают с автоматизированными системами (человек-машина).
Что мешает заранее начать разбираться с системами типа «человек-человек», т.е. с принципами работы организаций?
Тем более что ситуация по развитию организаций всем более-менее известна, и освещается на множестве ресурсов.
И если разработчик не разбирается в этом, это говорит о том, что есму это не интересно — а в этом случае не нужно туда и лезть. А раз уж полез — будь добр, разберись в правилах игры, и построй стратегию.
И если разработчик этого не может — у него либо особенности характера, несовместимые с этим видом деятельности (опять же — тогда не стоит и лезть), либо банальная лень.
Что мешает интерполировать процесс разработки системы на жизненные ситуации?
Системный анализ работает не только с автоматическими системами.
Старшие разработчики также хорошо работают с автоматизированными системами (человек-машина).
Что мешает заранее начать разбираться с системами типа «человек-человек», т.е. с принципами работы организаций?
Тем более что ситуация по развитию организаций всем более-менее известна, и освещается на множестве ресурсов.
И если разработчик не разбирается в этом, это говорит о том, что есму это не интересно — а в этом случае не нужно туда и лезть. А раз уж полез — будь добр, разберись в правилах игры, и построй стратегию.
И если разработчик этого не может — у него либо особенности характера, несовместимые с этим видом деятельности (опять же — тогда не стоит и лезть), либо банальная лень.
Хуже, когда учиться и набираться опыта попросту не у кого. То есть приходишь в организацию, и видишь тех же студентов, с которыми учился, и при этом я сам еще мог им что-то рассказать.
Наверно надо быть совсем экстравертом, чтобы «не у кого» было учиться в эпоху интернета, гитхаба и стековерфлоу.
Нет, ну если считать за обучение стековерфлоу и полезные статьи на хабре, то так учатся все.
Вот только я не сказал бы, что это так же эффективно, как иметь «семпая», который бы вовремя вправлял мозги в правильном направлении.
Вот только я не сказал бы, что это так же эффективно, как иметь «семпая», который бы вовремя вправлял мозги в правильном направлении.
Я имею ввиду статьи специалистов и исходники рабочих проектов. Тратить на каждого ленивого джуниора время опытного разработчика — вот это точно не эффективно.
> Тратить на каждого ленивого джуниора время опытного разработчика — вот это точно не эффективно.
Это смотря как тратить.
Стоять за их спиной и смотреть, что они пишут (в режиме реального времени) — неэффективно.
А выделить 30 минут в день на «полистать коммиты новичков», по замеченной кривизне и костылям отправляя им email «вот тут сделал криво, попробуй по-другому, например так» — вполне эффективно.
Это смотря как тратить.
Стоять за их спиной и смотреть, что они пишут (в режиме реального времени) — неэффективно.
А выделить 30 минут в день на «полистать коммиты новичков», по замеченной кривизне и костылям отправляя им email «вот тут сделал криво, попробуй по-другому, например так» — вполне эффективно.
Мне на первом проекте по методологии «scrum» «повезло» встретить «семпая» в виде scrum-мастера, который в критический для меня момент немного «вправил» мозги в неправильном направлении — чисто из желания возразить…
Учиться нужно не только у кого-то, а и самому! набивая шишки, делая всё методом проб и ошибок и чаще 2-ое заводит нас намного дальше, чем просто учение у кого-либо.
Последние пару лет только «а и самому» и происходит…
И иногда понимаешь, что далеко не все системные/архитектурные решения, принятые в проекте, были правильными
И иногда понимаешь, что далеко не все системные/архитектурные решения, принятые в проекте, были правильными
Учиться у кого-то можно только если разница уровней превышает определённую величину. Можно ещё учиться самому, используя кого-то в качестве наиболее частого учебного пособия, но это несколько другое, даже результат может быть противоположный. Но это надо хорошо уметь учиться самому.
Гороздо хуже, когда приходишь в организацию, и видишь вроде умных ребят и постарше лет на 5-10 и при этом сам еще можешь им что-то рассказать…
Ага. Ты им рассказываешь, они вроде бы слушают, а делают всё равно по старинке. Ты говоришь, что «так пишет всё прогрессивное человечество», а завтра обнаруживаешь, что «прогрессивное человечество» стало новым ругательным термином :)
Одногруппник работал 1.5 года в одной фирме в отделе программистов, которые писали и обслуживали какие-то внутренние программы. Где-то через месяц работы у него случилось полное помешательство, т.к. тамошний тимлид утверждал что все паттерны и гибкие методологии зло и они только замедляют процесс разработки. На аргументы о техническом долге отмахивался. Системы контроля версий там не было. Тестирование всего проводили самым наивным методом: запускали и тыкали кнопки. На первые юнит-тесты, написанные одногруппником смотрели как на волшебство. ТЗ ни на одну задачу никогда не было. О Continuous Integration слышали что-то мельком. И чуть ли не главным принципом фирмы было то, что один человек отвечает за одну задачу и если он увольняется, то код проще переписать, т.к. он без тестов, комментариев, истории изменений и т.д. Зато у тимлида была гордая надпись в трудовой «Технический директор» и ещё у двоих была надпись «Ведущий программист», которыми они очень гордились.
И чуть ли не главным принципом фирмы было то, что один человек отвечает за одну задачу и если он увольняется, то код проще переписатьДовольно частый паттерн организации разработки ПО.
У меня вот тоже запись: ведущий. Что только значит — понять не могу: кого и куда веду? :)
> Системы контроля версий там не было. Тестирование всего проводили самым наивным методом: запускали и тыкали кнопки. На первые юнит-тесты, написанные одногруппником смотрели как на волшебство. ТЗ ни на одну задачу никогда не было. О Continuous Integration слышали что-то мельком.
Вот вы перечисляете всё это как что-то, без чего нельзя создать нормальный продукт.
А ведь именно таким образом был создан варкрафт. И еретик. И дум. И первые версии винды.
Вот лохи те ребята, наверное, были, да? Никудышные программисты, поди, да?
Вот вы перечисляете всё это как что-то, без чего нельзя создать нормальный продукт.
А ведь именно таким образом был создан варкрафт. И еретик. И дум. И первые версии винды.
Вот лохи те ребята, наверное, были, да? Никудышные программисты, поди, да?
Вы либо очень жирный тролль, либо…
В 2015 году работать и писать код как в 1985 (первые версии винды), или даже как в 1993 (DOOM) будут только морально и технически отсталые идиоты, которых надо гнать из профессии на мороз палками.
В 2015 году работать и писать код как в 1985 (первые версии винды), или даже как в 1993 (DOOM) будут только морально и технически отсталые идиоты, которых надо гнать из профессии на мороз палками.
Что-то мне подсказывает, что методы написания Windows и Doom были довольно продвинутыми. Иначе, почему они получили оглушительный успех? А если успех не зависит от методов работы, то может и идиотов не надо гнать из профессии.
Windows 1.0 был унылым тормозным отстоем, которому далеко до МакОси (прошло 30 лет и ничего не изменилось :) ). Это несмотря на 24 программиста и 110 000 человеко-часов работы (или 55-человеко-лет). Кстати к релизу Windows 1.01 большая часть системы была не протестирована.
Что касается Doom, то им занимался крутейший программист всех времен и народов. Очень сомневаюсь, что ему понадобилось писать юнит-тесты.
Что касается Doom, то им занимался крутейший программист всех времен и народов. Очень сомневаюсь, что ему понадобилось писать юнит-тесты.
Если дальше продолжать вашу логику, то машины и самлеты нахрен надо убрать. Раньше на лошадях ездили и через океан месяц на корабле плыли.
А что, популярностью же корабли пользовались? Пользовались.
Люди попадали в конечную точку своего пути? Попадали.
Значит эти подходы идеальны. Значит все ОК с тами подходами.
А что, популярностью же корабли пользовались? Пользовались.
Люди попадали в конечную точку своего пути? Попадали.
Значит эти подходы идеальны. Значит все ОК с тами подходами.
Думаю, тут разница не только между 1985 и 2015, но и между а) оффшорным программированием либо разработкой системы для конкретного заказчика б) разработкой «коробочного» софта и в) разработкой системного и embedded софта. Между 1985 и 2005 много поменялось в части (а), меньше — в части (б) и ещё меньше — в части (в). В сфере «отделов программистов, которые пишут и обслуживают внутренние программы» поменялось ещё меньше.
Может быть, всё же причина была в том, что тогда не было тех инструментов, что есть сейчас? На нынешнем рынке ПО совершенно другие требования, чем были в то время, поэтому и подходы 20-30 летней давности сейчас уже не работают.
Хотя, инструменты, конечно, должны оставаться инструментами, а не становиться самоцелью.
Хотя, инструменты, конечно, должны оставаться инструментами, а не становиться самоцелью.
Грубо говоря, тогда «не было интернета». Т.е. теоретически он в каком-то виде был, но сетевые технологии, на которых сегодня построены все перечисленные вами «фишки», использовались мало или вообще никак. Тем более, что для того, чтоб разрабатывать «в одно лицо», все эти вещи не критичны.
С чего это вы взяли, что у тех ребят не было нормального ТЗ и организации работы?
Насколько я читал интервью сотрудников ID-software, там наоборот говорят что успех маленькой компании во многом получился благодаря тому, что каждый точно знал что ему делать, и организовано все было с запасом. IDSoft всегда славилась именно тем, что эти ребята кладут свою лыжню, и мгновенно осваивают все самое новое.
В то время, как в вышеуказанной компании, даже не пытаются освоить уже проверенные и рабочие методы, признанные в мире удобными инструментами.
Пусть не нужно пользоваться тестами, системами контроля версий, билд серверами, но тогда покажите ваше собственное рабочее решение, которое будет лучше этого?
Насколько я читал интервью сотрудников ID-software, там наоборот говорят что успех маленькой компании во многом получился благодаря тому, что каждый точно знал что ему делать, и организовано все было с запасом. IDSoft всегда славилась именно тем, что эти ребята кладут свою лыжню, и мгновенно осваивают все самое новое.
В то время, как в вышеуказанной компании, даже не пытаются освоить уже проверенные и рабочие методы, признанные в мире удобными инструментами.
Пусть не нужно пользоваться тестами, системами контроля версий, билд серверами, но тогда покажите ваше собственное рабочее решение, которое будет лучше этого?
Вы мешаете в одну кучу «традиционное» ТЗ и «гибкие» систему контроля версий и сервер сборки. Хотя тогда «не было интернета» и, соответственно, не было серверов сборки и сетевых репозиториев, но ТЗ как «инструмент управления разработкой» уже давно существовало и использовалось.
Ваш одногруппник надеялся найти в Калуге scrum-команду или оффшорных разработчиков ПО?
У нас в Калуге достаточно хороших фирм (DevExpress, CorePartners, ...). Вообще-то мой комментарий был про другое. Про то, что люди величают себя тимлидами и ведущими разработчиками, в то время когда они им не являются по сути в общем виде. Самый долго работающий программист != самый опытный. Собственно об этом я и писал.
Потребность в разработчиках здесь значительно выше, чем кадровое предложение. Эта проблема существует многие годы, и со временем она становится острее.
Я как программист никакой проблемы в этом не вижу. Классики тему спроса и предложения на рынке труда раскрыли полностью.
Постоянная промышленная резервная армия, как называл её Энгельс, позволяет капиталу всегда располагать доступным для эксплуатации человеческим материалом независимо от границ естественного прироста населения. Без этого капитализм не мог бы существовать, ибо потребности самовозрастания капитала подвержены большим изменениям. Конвульсивное и скачкообразное расширение производства в период подъёма (столь же характерное для капиталистического машинного производства, как и конвульсивное сокращение производства в периоды кризиса) непременно предполагает существование промышленной резервной армии, всегда готовой к услугам капитала. Из армии безработных капитал, в случае нужды, черпает добавочную рабочую силу, и в эту же армию он выбрасывает пролетариев, как только они становятся излишними. Следовательно, безработица порождается не извечным законом природы, как это изображают буржуазные идеологи, а общественными условиями определённой исторической формации; она порождается капитализмом, капиталистическими производственными отношениями.
Дальнейшее распространение в капиталистических странах процесса механизации и автоматизации производства создает серьёзную угрозу ещё большего увеличения масштабов массовой безработицы. Вместе с тем усиливается борьба рабочего класса за сокращение продолжительности рабочего дня без сокращения заработной платы, за снижение пенсионного возраста, за увеличение пособий по безработице и выплату их в течение всего периода безработицы, за использование государственных средств не на производство всё более разрушительных видов вооружения, а на стимулирование экономического роста, строительство школ, больниц, жилых домов. Если бы трудящимся удалось добиться осуществления подобных мер, это могло бы уменьшить масштабы безработицы и смягчить её тяжелые последствия. Однако никакие меры не могут полностью ликвидировать безработицу при капитализме. Окончательно избавиться от неё можно лишь путём уничтожения самого капитализма.
Промахнулся
«Дальнейшее распространение в капиталистических странах процесса механизации и автоматизации производства создает серьёзную угрозу ещё большего увеличения масштабов массовой безработицы»
— лет 200 как всё механизируется и автоматизируется, но роста процента безработицы не наблюдается, а наблюдается переход рабочей силы в новые рынки труда, которые создаются этими самыми механизацией, автоматизацией, компьютеризацией. Вывод: утверждение ложное.
«Вместе с тем усиливается борьба рабочего класса за сокращение продолжительности рабочего дня без сокращения заработной платы, за снижение пенсионного возраста, за увеличение пособий по безработице и выплату их в течение всего периода безработицы, за использование государственных средств не на производство всё более разрушительных видов вооружения, а на стимулирование экономического роста, строительство школ, больниц, жилых домов»
— дадада, вся Россия «в демонстрациях и стачках» потому что: рабочий день не сокращают, пенсионный возраст не сокращают, а увеличивают (!), пособия не только не увеличивают, но и не платят вообще (!), военный бюджет не сокращается, а увеличивается (!), бюджет на образование, медицину и прочее не увеличивается, а резко сокращается (!). Так где же стачки и демонстрации? Наоборот, рейтинг 89% — за последние 50 лет выше был только у Брежнева.
Вывод: то ли все, написанное в посте выше, полная лажа, то ли Россия не подчиняется этим законам.
— лет 200 как всё механизируется и автоматизируется, но роста процента безработицы не наблюдается, а наблюдается переход рабочей силы в новые рынки труда, которые создаются этими самыми механизацией, автоматизацией, компьютеризацией. Вывод: утверждение ложное.
«Вместе с тем усиливается борьба рабочего класса за сокращение продолжительности рабочего дня без сокращения заработной платы, за снижение пенсионного возраста, за увеличение пособий по безработице и выплату их в течение всего периода безработицы, за использование государственных средств не на производство всё более разрушительных видов вооружения, а на стимулирование экономического роста, строительство школ, больниц, жилых домов»
— дадада, вся Россия «в демонстрациях и стачках» потому что: рабочий день не сокращают, пенсионный возраст не сокращают, а увеличивают (!), пособия не только не увеличивают, но и не платят вообще (!), военный бюджет не сокращается, а увеличивается (!), бюджет на образование, медицину и прочее не увеличивается, а резко сокращается (!). Так где же стачки и демонстрации? Наоборот, рейтинг 89% — за последние 50 лет выше был только у Брежнева.
Вывод: то ли все, написанное в посте выше, полная лажа, то ли Россия не подчиняется этим законам.
— лет 200 как всё механизируется и автоматизируется, но роста процента безработицы не наблюдается, а наблюдается переход рабочей силы в новые рынки труда, которые создаются этими самыми механизацией, автоматизацией, компьютеризацией. Вывод: утверждение ложное.Мы видимо на разных планетах живем.
— дадада, вся Россия «в демонстрациях и стачках» потому что: рабочий день не сокращают, пенсионный возраст не сокращают, а увеличивают (!), пособия не только не увеличивают, но и не платят вообще (!), военный бюджет не сокращается, а увеличивается (!), бюджет на образование, медицину и прочее не увеличивается, а резко сокращается (!). Так где же стачки и демонстрации? Наоборот, рейтинг 89% — за последние 50 лет выше был только у Брежнева.Если вы не следите за борьбой рабочего класса, это не значит что её нет. Итальянская забастовка медиков, 5 открытых забастовок на Форде, забастовки авиадиспетчеров, забастовки докеров… я могу очень долго этот список продолжать вплоть до того как на тачке выкатили директора Выборгского ЦБК. Вы что хотите доказать? Собственную безграмотность?
Вывод: то ли все, написанное в посте выше, полная лажа, то ли Россия не подчиняется этим законам.
Я не хочу уходить из разработки в управление, мне нравится моя работа и мое дело. К сожалению расти в таком случае очень трудно, уже начали задавать вопросы, вам столько лет и вы не «менеджер», а почему так, вы наверное очень плохой разработчик, раз не выбились в управленцы. Ответ «не хочу», до 99% оппонентов не доходит :)
Успех! Заработок! Власть! Ссаные ценности, продиктованные современным миром. Конечно до них не дойдет.
Такие доводы часто не доходят даже до близких людей, что куда плачевнее
«Не всем же быть начальниками и директорами.» Гоша. Фильм «Москва слезам не верит»
Это точно, бывшая жена регулярно пилила на тему, «становись начальником» :)
бывшая
Всё правильно сделал! Человек должен заниматься своим делом, тогда и получаться у него это будет лучше. И на человеческие отношения будет больше сил, времени и желания. А погоня за мнимым статусами: стресс, бутылка, скандалы и дальше по кругу.
С этой точки зрения мне у военных подход нравится.
Х***ый майор может получать меньше чем п***ый капитан или ох***ый прапор. Причем в случае конфликта такого прапора с майором — у майора есть большой риск замененным. Ибо толкового спеца на любом уровне искать проблематично от низшего до высшего, например наблюдал принципиально незаменимых тестеров, а бестолковый сотрудник даже высшего звена — это просто расходник, который выпнут при первом же сокращении или обнаружении более достойного кандидата.
Наблюдал несколько подполов уходивших с полковничьих должностей на майорские не только из соображений снижения ответственности, но и с точки зрения повышения добычи денюжков на карман. Да и комотд (сержант) при налиции хорошей классности может обходить свежевыпущенного лейтенанта, что вдвойне для последнего обидно.
Другое дело что зачастую сотрудников двигают вверх до достижения ими уровня полной некомпетентности, а назад двигать это уже считается некомильфо. Хотя тут сказывается тот факт что высшая ступенька гарантированно дает повышенную оплату, то есть мегаклассный программист (имея максимум по программистской зарплатной вилке) переходя в тим лиды обычно имеет в тим лидах больше чем в программистах. И обычно минимум вилки тим лида (а тем более РП) больше максимума вилки программиста. В результате имеем погоню за деньгами и некомпетентного РП или лида вместо отличного и полностью компетентного программиста. В очень редких компания сталкивался с тем что компетентный специалист мог обойти своего шефа по зарплате (это не значит что шеф некомпетентный, а скорее то что замена такого сотрудника компании не может обойтись любым кандидатом и потребуется вместо заполнения одной вакансии открывать еще две-три).
Х***ый майор может получать меньше чем п***ый капитан или ох***ый прапор. Причем в случае конфликта такого прапора с майором — у майора есть большой риск замененным. Ибо толкового спеца на любом уровне искать проблематично от низшего до высшего, например наблюдал принципиально незаменимых тестеров, а бестолковый сотрудник даже высшего звена — это просто расходник, который выпнут при первом же сокращении или обнаружении более достойного кандидата.
Наблюдал несколько подполов уходивших с полковничьих должностей на майорские не только из соображений снижения ответственности, но и с точки зрения повышения добычи денюжков на карман. Да и комотд (сержант) при налиции хорошей классности может обходить свежевыпущенного лейтенанта, что вдвойне для последнего обидно.
Другое дело что зачастую сотрудников двигают вверх до достижения ими уровня полной некомпетентности, а назад двигать это уже считается некомильфо. Хотя тут сказывается тот факт что высшая ступенька гарантированно дает повышенную оплату, то есть мегаклассный программист (имея максимум по программистской зарплатной вилке) переходя в тим лиды обычно имеет в тим лидах больше чем в программистах. И обычно минимум вилки тим лида (а тем более РП) больше максимума вилки программиста. В результате имеем погоню за деньгами и некомпетентного РП или лида вместо отличного и полностью компетентного программиста. В очень редких компания сталкивался с тем что компетентный специалист мог обойти своего шефа по зарплате (это не значит что шеф некомпетентный, а скорее то что замена такого сотрудника компании не может обойтись любым кандидатом и потребуется вместо заполнения одной вакансии открывать еще две-три).
Года через 3-5 вам перестанут задавать такие вопросы. Люди, их задающие, просто самоотфильтруются на дальних подступах к вашему кругу профессионального общения.
Значит, с 99 процентами вам не по пути. Ищите 1% лучших.
Сильные разработчики имеют очень большое влияние на коллектив. Да они могут не заниматься административной рутиной, но разработкой они управляют, и в некотором смысле являются менеджерами. Много сильных разработчиков вместе могут порвать команду в клочья и надо искать баланс между лидерами сильными программистами и ведомым молодыми дарованиями. С опытом лидерские навыки редко развиваются, они либо есть, либо их нет, возможно, поэтому способность стать сильным разработчиком не зависит от лет опыта.
«Много сильных разработчиков вместе могут порвать команду в клочья» — мне кажется, это может быть только при плохом/слабом менеджере. У меня была обратная проблема — меня, как опытного сеньерного программиста, в одной фирме в конце первого года работы побранили: «что же ты влияешь на проект, не учишь молодежь, не выступаешь с инициативами?»
А у меня:
1. Своей работы выше крыши и на полгода вперед и все «надо вчера».
2. Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди». А что будет, если я подойду к колеге и скажу: «я тут посмотрел твой кусок и, честно говоря, хреново он написан (или более мягкий вариант „его можно написать лучше“)? А будет то, что джуниор меня, может быть, и послушает, хотя не факт, а уже середнячок просто пошлет подальше — и правильно сделает, потому что мне никто не делегировал таких полномочий, а для него я такой же коллега. Да и не было времени смотреть код других, потому что см. пункт 1.
То есть, для меня часто ситуация выглядит так. В конце года:
— почему ты грядку не копал?
— а вы мне сказали ее копать? а вы лопату мне дали?
— нет, не сказали и не дали, но почему ты ее не копал??
А у меня:
1. Своей работы выше крыши и на полгода вперед и все «надо вчера».
2. Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди». А что будет, если я подойду к колеге и скажу: «я тут посмотрел твой кусок и, честно говоря, хреново он написан (или более мягкий вариант „его можно написать лучше“)? А будет то, что джуниор меня, может быть, и послушает, хотя не факт, а уже середнячок просто пошлет подальше — и правильно сделает, потому что мне никто не делегировал таких полномочий, а для него я такой же коллега. Да и не было времени смотреть код других, потому что см. пункт 1.
То есть, для меня часто ситуация выглядит так. В конце года:
— почему ты грядку не копал?
— а вы мне сказали ее копать? а вы лопату мне дали?
— нет, не сказали и не дали, но почему ты ее не копал??
Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди». А что будет, если я подойду к колеге и скажу: «я тут посмотрел твой кусок и, честно говоря, хреново он написан (или более мягкий вариант „его можно написать лучше“)? А будет то, что джуниор меня, может быть, и послушает, хотя не факт, а уже середнячок просто пошлет подальше — и правильно сделает, потому что мне никто не делегировал таких полномочий, а для него я такой же коллега. Да и не было времени смотреть код других, потому что см. пункт 1.
Отчасти для этого скрамы и прочие аджайлы нужны. В аджайл-команде это норма вещей.
Я малость пытался, как стало почти до конфликтов доходить (момент вашего высказывания «просто пошлёт подальше») — забил. Сейчас процентов 20% времени у меня уходит на разного рода консультации (в т.ч. и на смежных проектах) — я своими знаниями помогаю коллегам, могу указать на ошибки, если увижу, но дальнейшая судьба оных мне не интересна: хотите повторно наступать на грабли — пожалуйста, лоб ваш, а не мой. Но на своём проекте, в своей компоненте в хвост и гриву за косяки, без купюр, хотя, формально, я не лид (просто разработчик, хоть и имею запись — ведущий /я даже не понимаю до конца что это значит — кого веду, куда веду? никто не объяснил/), но так бывает, что какую-то законченную функционально часть выходит разрабатывать самому, с архитектуры, до реализации (хотя бы изначальной) — тут работает «право первой ночи» (речь идёт о том, когда проект/компонент передают другому или расширяют первоначальную команду). При этом я просто в восторге когда кто-то находит ошибки, предлагает красивые решения или чётко обосновывает какое-то решение с которым я /ошибочно/ не согласен! Особенно в архитектурном плане.
ЗЫ я не сеньор :)
ЗЫ я не сеньор :)
Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди».
Это просто означает, что вы не лид. Лидер берет, делает, потому что это его трогает и к нему в итоге прислушиваются. Ну вот скажут «прислушивайтесь к замечаниям и идеям дяди» мидлам, а они как не считали вас достойным давать советы — так и будут считать. И будут саботировать. Вы, конечно, скажете опять, что «ну и все-равно, это их проблемы, что не слушают советы опытного дяди», но опять же это от того, что вы не лид в душе.
Это просто означает, что я люблю порядок, не люблю анархии, привык подчиняться правилам и соблюдать законы. И кроме того, я не хочу тратить свое личное свободное время и оставаться сверхурочно, чтобы смотреть по сторонам, проверять качество кода и решений других, а уж тем более переделывать что-то. Тот же самый начальник, которой побранил меня в конце года, в течение самого года постоянно наседал только с одним требованием: «это важный клиент, он ждет, почему так медленно??»
я тут посмотрел твой кусок и, честно говоря, хреново он написанТут нужны формализованные критерии качества кода и процедуры code review (не говоря уже о том, что с точки зрения «дефолтной» (хотя и обычно неправильной) прошитой в мозгах разработчика парадигмы «каждый отвечает за свой собственный код» право таких претензий на существование вообще сомнительно). И говорить лучше не абстрактно «твой код хреново написан», и тем более не «честно говоря» и не «можно написать лучше» — такие ослабленные варианты скорее воспримутся как придирки к несерьёзным мелочам — а конкретно «твой код написан так, что он мешает делать то-то».
Я вот лично, что такое «качество кода», зачем оно нужно, и как его обеспечивать парой нажатий на клавиши, понял только через десять лет после написания своей первой программы на Java — никто никогда не объяснял, только на последнем месте молча слегка подталкивали, и то, зачем это надо, я понял только после того, как ушёл оттуда.
Какие нужны критерии и какая лучше парадигма — это не к сеньерному программисту, а к начальнику проекта. Если вы работали в больших фирмах, т должны знать, что изменить как правило ничего нельзя. В лучшем случае тебе назовут десяток важных ппичин, почему не надо ничего менять. В худшем просто скажут — нет.
И то, что лучше сказать коллеге, тоже не важно, потому что прежде, чем что-то сказать, надо проанализировать его код, а на это нет времени (скорость и корректность алгоритма или правильность иерархии классов не оценят никакие автопроверялки).
И то, что лучше сказать коллеге, тоже не важно, потому что прежде, чем что-то сказать, надо проанализировать его код, а на это нет времени (скорость и корректность алгоритма или правильность иерархии классов не оценят никакие автопроверялки).
не к сеньерному программисту, а к начальнику проектаЯ это и подразумевал, говоря про формализованные критерии и процедуры. Конечно, они должны исходить от начальства и, лучше бы, быть частью внутрифирменного стандарта.
Если вы работали в больших фирмах, т должны знать, что изменить как правило ничего нельзя.
Я работал. Было бы желание.
Мне вот очень понравилась табличка из статьи «More Than Coding» в одном блоге:
(https://habrastorage.org/files/1c0/293/d3a/1c0293d3a3674655a7bfd609ff10e2e5.JPG)
Которая оценивает не собственно годы, а степень влияния и ответственности это куда важнее.
(https://habrastorage.org/files/1c0/293/d3a/1c0293d3a3674655a7bfd609ff10e2e5.JPG)
Которая оценивает не собственно годы, а степень влияния и ответственности это куда важнее.
Это не одна статья, это целый блог: morethancoding.com Спасибо за наводку.
На самом деле, попытка оценивать людей временными интервалами – слишком упрощенный способ для таких тонких материй, как знание и профессиональный опыт.
Это правда, но и крутым разработчиком не стать за 2 недели. Для того, чтобы стать кем-то очень успешным нужно потратить тонну времени, перечитать кучу книг, поняв, что там написано и применив это в деле, а также самому изобретать и строить. Старое, доброе правило 10 000 часов.
И в корне не согласен с этим вот обзацем:
Если у вас нет ни одного старшего разработчика на руководящих позициях, то проект обречен. Команда отличных «середнячков» может завести вас довольно далеко, но дни продукта все равно сочтены. И в финале вас ждет либо сворачивание лавочки, либо рискованные и дорогостоящие переделки. Единственный, кто способен выбрать правильную технологию и платформу – это старший разработчик. Поэтому его отсутствие в проекте с первых дней серьезно вам повредит.
Если нет старшего разработчика, проект еще не обречен. Важно, чтобы кто-то из членов команды стремился им стать!
Печально, но факт: абсолютное большинство не только старших разработчиков, но и тимлидов, являются обычными «средними» программистами.То же самое можно сказать и про большинство компаний, менеджеров и т.д. Большинство компаний не выше среднего уровня и с такими же проектами. Откуда в них будут толпы крутых программистов?
Это конечно интересно беседовать на тему идеальных сеньоров, но кто бы взялся за решение проблемы? Откуда появятся крутые разработчики, если все их обучение пущено на самотек?
Институты плохо учат? Ну, так почему бы компаниям не замутить свой университет? То, на что в институтах тратиться 5 лет, можно за год научить при правильном подходе. Стажировки тому подтверждение.
Есть в некоторых компаниях короткое обучение на джуниора — «стажировка», так почему бы не пойти дальше и не ввести «дообучение на сеньора»?
Еще становлению истинными сеньорами мешает то факт, что и пожить хочется, а не угробить всю жизнь на развитие ради того, чтобы другие больше зарабатывали. Все хотят, чтобы сотрудник и работать и учиться успевал, а вот выделить время и деньги на это – далеко не каждый захочет.
Начало статьи вроде об одном, а сама статья вовсе о другом.
Реальность такова, что руководителем группы\отдела становится тупо тот, кто дольше проработал. Особенно интересно бывает наблюдать картину, когда руководителем становится человек, проработавший 10 лет на одном месте, совершенно не знающий людей, рынка, технологий и вообще не видевший ничего за пределами организации.
Но основная идея статьи о другом — «не надо оценивать разработчиков по годам опыта». Как ни странно я очень редко встречался с ситуацией когда программистов оценивали по годам опыта. Все прекрасно понимают, что годов может быть много, в релевантного опыта мало.
Если посмотреть на форумах обсуждения собеседований программистов, то я не видел претензий чтобы кого-либо отфильтровали по количеству лет.
ИМХО статья скорее для HR, которые обычно не понимают специфики инженерной и творческой работы.
Реальность такова, что под «старшим разработчиком» понимается человек, который ваяет код более 3 лет. Его ставят на руководящую позицию, и обычно все заканчивается ожидаемо плачевно.
Реальность такова, что руководителем группы\отдела становится тупо тот, кто дольше проработал. Особенно интересно бывает наблюдать картину, когда руководителем становится человек, проработавший 10 лет на одном месте, совершенно не знающий людей, рынка, технологий и вообще не видевший ничего за пределами организации.
Но основная идея статьи о другом — «не надо оценивать разработчиков по годам опыта». Как ни странно я очень редко встречался с ситуацией когда программистов оценивали по годам опыта. Все прекрасно понимают, что годов может быть много, в релевантного опыта мало.
Если посмотреть на форумах обсуждения собеседований программистов, то я не видел претензий чтобы кого-либо отфильтровали по количеству лет.
ИМХО статья скорее для HR, которые обычно не понимают специфики инженерной и творческой работы.
«Одни с годами умнеют, другие становятся старше» — ©, из подписи одного из модераторов форума «Исходники».
Пост полезный, спасибо; замечу только, что Страуструп сказал об этом уже давно, написав, что «кодировщик» — кодирует в рамках поставленной задачи с поставленными условиями, а «программист» — решает проблему.
И, кстати, это уместно в абсолютно любой профессии. Хороший средний специалист работает в каких-то условиях и рамках, высокого уровня специалист — либо сам создаёт себе условия, либо решает проблему «с центра поля», либо то и другое.
И, кстати, это уместно в абсолютно любой профессии. Хороший средний специалист работает в каких-то условиях и рамках, высокого уровня специалист — либо сам создаёт себе условия, либо решает проблему «с центра поля», либо то и другое.
Возникает ощущение, что у Старшего Разработчика вообще нет недостатков. Зрит в корень, трезво оценивает, решает проблемы, ищет оптимальное решение… Просто идеал какой-то.
Хорошая статья, которая реально отображает положение вещей. Как по мне, так проблема роста еще часто заключается в отсутствии возможности у кого-то учиться.
Не всегда рядом будет «правильный» более старший разработчик, который сможет указать на твои недочёты или помочь с дальнейшим ростом. Это же касается и менеджмента, который в большинстве случаев страдает на нехватку технической подкованности и это мешает строить правильные команды и делать правильные выборы в пользу того или другого программиста.
Не всегда рядом будет «правильный» более старший разработчик, который сможет указать на твои недочёты или помочь с дальнейшим ростом. Это же касается и менеджмента, который в большинстве случаев страдает на нехватку технической подкованности и это мешает строить правильные команды и делать правильные выборы в пользу того или другого программиста.
Описаний уровней разработчиков очень много. Но прочитав эту статью и немного поразмыслив я бы сказал, так:
Джуниор — человек без опыта и понимания реального положения вещей. Он либо вообще не знает о том как можно разрабатывать, либо видит всего один правильный путь.
Мидл — человек который знает за чем все это происходит, знает в чем причина. Он знает, что важен факт решения проблемы, а не код. Он знает о проблеме поддержки проекта/ кода и знает как это упростить при проектировании и разработке. Он знает многие различные методики для различных стадий проекта (он знает что этих стадий много). Знает, что нет серебренной пули, и нужно выбирать инструмент/методику для каждого проекта в отдельности.
Сеньер — человек который знает все, что знает мидл, но у него есть опыт и он знает как все это применять. Человек который прочитав ТЗ может четко сказать, что и по какой причине лучше использовать. Какие подводные камни будут в этом проекте и скорее всего, он даже назовет точные сроки разработки проекта, потому что он «видит» весь жизненный цикл будущего проекта.
Джуниор — человек без опыта и понимания реального положения вещей. Он либо вообще не знает о том как можно разрабатывать, либо видит всего один правильный путь.
Мидл — человек который знает за чем все это происходит, знает в чем причина. Он знает, что важен факт решения проблемы, а не код. Он знает о проблеме поддержки проекта/ кода и знает как это упростить при проектировании и разработке. Он знает многие различные методики для различных стадий проекта (он знает что этих стадий много). Знает, что нет серебренной пули, и нужно выбирать инструмент/методику для каждого проекта в отдельности.
Сеньер — человек который знает все, что знает мидл, но у него есть опыт и он знает как все это применять. Человек который прочитав ТЗ может четко сказать, что и по какой причине лучше использовать. Какие подводные камни будут в этом проекте и скорее всего, он даже назовет точные сроки разработки проекта, потому что он «видит» весь жизненный цикл будущего проекта.
В любой работе, связанной с решением практических задач и работы с клиентами помогает социализация и знание человеческой психологии.
Статья — ниочём, вода водная. Это настолько всё индивидулаьно, что тут правил и шаблонов не подогнать. Писать такие статьи — пустая трата времени, читать — пустая в квадрате.
Sign up to leave a comment.
Ненастоящие сеньор-девелоперы, или почему годы опыта ни о чем не говорят