Здравствуйте, LaptevVV, Вы писали:
LVV>которые с этим столкнулись и в итоге выбрали проект поинтереснее, с более маленькой зарплатой. LVV>Это правда?
пиз... пишут неправду! Есть правильная мысль: "Не жизнь — скучная, это ты — скучный!".
Мне программировать интересно, потому все задачи делятся на "простые и сложные", а не "скучно/интересно" — я чё, задрот что ли — искать в работе развлечение?
Есть задача — её и решаем. А вот КАК ты её решишь — в этом и есть вся соль! Можно решать долго и нудно, а можно поразмыслить и решить интересно (только чтобы потом тебя не проклинали ).
Даже в задаче создания отчётов (FastReport) я нашёл интересный момент — автогенерить шаблон из свойств объекта (вместо copy-paste и потом расставлять поля по странице).
А деньги... они всегда нужны. Пока "зумеры" думают о том, что "на кофе мне хватает", умные люди вкладывают в проперть, образование, инструменты и т.п. "Интересную" работу я и дома найду,
а вот хорошая зарплата — это источник вечного поиска.
Здравствуйте, Baiker, Вы писали:
B>пиз... пишут неправду! Есть правильная мысль: "Не жизнь — скучная, это ты — скучный!".
B>Мне программировать интересно, потому все задачи делятся на "простые и сложные", а не "скучно/интересно" — я чё, задрот что ли — искать в работе развлечение?
По себе не суди о всех. А от тебя зеленью несет за километр. Для хекеров вообще зашквар заниматься нудным примитивом. Подростешь, поймешь.
Есть в профессиональном программировании неприятная связь: чем больше зарплата, тем скучнее работа.
Это много где бывает, но в программировании это очень сильно проявляется.
В скучных проектах, где однотипная, скучная работа, там платят больше как раз, чтобы дополнительно привлекать хороших специалистов.
И для многих то, что я написал, выглядит как на картинке — но я знаю много разработчиков,
которые с этим столкнулись и в итоге выбрали проект поинтереснее, с более маленькой зарплатой.
Это правда?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Есть в профессиональном программировании неприятная связь: чем больше зарплата, тем скучнее работа.
LVV>Это правда?
Не заметил такого. Там где однотипно и скучно и платили не особо.
Платят хорошо там, где есть деньги. Иногда там попадаются сложные задачи. Ну а сложные задачи решать интересно.
_____________________
С уважением,
Stanislav V. Zudin
Отец обрaтился к дочери: «Ты зaкончилa обучение с отличием, вот тебе мaшинa, которую я приобрёл много лет нaзaд. Онa не новa. Но перед тем, кaк я тебе её отдaм, отвези её в место, где продaют подержaнные мaшины, и скaжи, что ты хочешь её продaть, чтобы понять, сколько они тебе предложaт зa неё». Дочь поехaлa тудa, вернулaсь к отцу и скaзaлa: «Они предложили мне 1000 долларов зa неё, поскольку онa не в лучшем состоянии». «Попробуй в ломбaрд» — предложил отец. Тaм предложили 100 долларов из-зa того, что онa былa слишком стaрой. Тогдa отец попросил дочь отвезти её в aвтоклуб и покaзaть тaм. Онa тaк и сделaлa, вернувшись говорит пaпе: «Некоторые люди в aвтоклубе предложили 100000 долларов зa мaшину, ведь это была культовая модель, которую много кто искaл. Нa что пaпa ответил: "В прaвильном месте тебя ценят определённым обрaзом, если тебя не ценят — не злись. Это знaчит, что ты не в том месте. Ценят тебя те, кто знaет твою цену. Никогдa не остaвaйся в том месте, где никто не зaмечaет твоей ценности.
В такой общей формулировке — вряд ли это правда, но если конкретизировать... Например, так:
Для большинства российских работодателей справедливо, что чем больше средняя для предприятия зарплата программиста, тем больше вероятность, что работа тесно связана с "кровавым энтерпрайзом" (корпоративными инфосистемами в их самом жестоком проявлении).
В типичных энтерпрайз-задачах слишком много неприятных черт:
1) Основная суть задач — в переложении бесконечно кудрявой бизнес-логики на ЯП. Чего только не выдумает этот "бизнес", и требования постоянно меняются и дополняются.
Иногда нужно доделывать часть работы за ленивых и недостаточно дотошных аналитиков (выяснять у них или у заказчиков все неясности), но если они разжевали задачу идеально — остаётся лишь тупой, но кропотливый перевод их писанины на ЯП, так что нет уверенности, что этот вариант лучше.
2) Не нужно ничего изобретать/исследовать, нужно лишь использовать методы/библиотеки/фреймворки/паттерны, давно уже придуманные/написанные или разрабатываемые и поддерживаемые в актуальном состоянии, но другими людьми.
3) Система давно написана и работает, так что доля поддержки/мелких доработок/багфиксинга сильно велика, а крупных новых задач мало.
4) Система ОЧЕНЬ давно написана и работает, так что приходится разгребать наслоения копролитов, оставленных поколениями программистов, давно нас покинувших. Пытаясь понять, как и куда нужно пристраивать новую часть, можно обнаружить, что никакой "единой архитектуры" нет, а есть черте-что и куча бантиков сбоку.
5) Система давно работает, и не стоит это трогать. Нет времени на рефакторинг и на апдейты библиотек/фреймворков — актуальных бизнес-задач и так навалом. В результате новое криво-косо пристраивается тоже сбоку и подпирается "костылями".
6) Новые модные технологии даже для новых частей системы привлекать нежелательно, чтобы не разводить "зоопарк". Шансов позаниматься чем-то актуальным — мало, а вероятность забить всю ёмкость своей памяти знаниями о прогнившем старье или о велобиблиотеках/велофреймворках местного разлива, только в этой единственной конторе и используемых — велика.
7) Даже минимальная проверка работоспособности своего кода или воспроизведение бага по описанному сценарию (о тестировании как таковом не говорю) часто требует побыть в роли пользователя разрабатываемой системы, а это бывает крайне скучно и муторно. И вряд ли программист сможет получить удовлетворение от своего труда, сам убедившись, что то, что он сделал — реально хорошо. Работает, тесты прошло — и ладно.
Конечно, в мире и даже в России есть много интересных работ с интересными зарплатами, но слишком велика масса программистов, шансы которых попасть туда малы и уменьшаются со временем. В общем, "не судьба".
И в самом "кровавом энтерпрайзе" исключения бывают по всем пунктам, но тенденция таки вырисовывается...
Т.е. если работа интересная, то кандидатов на вакансию больше, и, по законам рынка, зарплатные предложения "оптимизируются".
Здравствуйте, smeeld, Вы писали:
S>По себе не суди о всех. А от тебя зеленью несет за километр. Для хекеров вообще зашквар заниматься нудным примитивом. Подростешь, поймешь.
Любой нудный примитив можно превратить в ненудный непримитив, если вместо того, чтобы делать рутиную работу руками, написать программу, которая делает рутиную работу
В этом преимущество програмизьма над другими профессиями. Уборщица не напишет программу, которая будет вместо нее убираться
B>пиз... пишут неправду! Есть правильная мысль: "Не жизнь — скучная, это ты — скучный!".
B>Мне программировать интересно, потому все задачи делятся на "простые и сложные", а не "скучно/интересно" — я чё, задрот что ли — искать в работе развлечение? B>Есть задача — её и решаем. А вот КАК ты её решишь — в этом и есть вся соль! Можно решать долго и нудно, а можно поразмыслить и решить интересно (только чтобы потом тебя не проклинали ). B>Даже в задаче создания отчётов (FastReport) я нашёл интересный момент — автогенерить шаблон из свойств объекта (вместо copy-paste и потом расставлять поля по странице).
У меня всегда было так, что я в любой даже самой рутинной работе находил некий момент, который мне интересен.
Или я чего-то не знаю — интересно научиться.
И рутинная работа становилась совсем не рутинной.
Как у того работника на почте, который каждый день наклеивал марки на конверты — но дата же каждый раз новая!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Есть в профессиональном программировании неприятная связь: чем больше зарплата, тем скучнее работа.
LVV>Это много где бывает, но в программировании это очень сильно проявляется.
LVV>Это правда?
Конечно нет. Всегда же можно к скучному проекту взять нескучный и получать 2 зп!
L_G>2) Не нужно ничего изобретать/исследовать, нужно лишь использовать методы/библиотеки/фреймворки/паттерны, давно уже придуманные/написанные или разрабатываемые и поддерживаемые в актуальном состоянии, но другими людьми. L_G>3) Система давно написана и работает, так что доля поддержки/мелких доработок/багфиксинга сильно велика, а крупных новых задач мало. L_G>4) Система ОЧЕНЬ давно написана и работает, так что приходится разгребать наслоения копролитов, оставленных поколениями программистов, давно нас покинувших. Пытаясь понять, как и куда нужно пристраивать новую часть, можно обнаружить, что никакой "единой архитектуры" нет, а есть черте-что и куча бантиков сбоку. L_G>7) Даже минимальная проверка работоспособности своего кода или воспроизведение бага по описанному сценарию (о тестировании как таковом не говорю) часто требует побыть в роли пользователя разрабатываемой системы, а это бывает крайне скучно и муторно. И вряд ли программист сможет получить удовлетворение от своего труда, сам убедившись, что то, что он сделал — реально хорошо. Работает, тесты прошло — и ладно.
Это без ентерпрайза вполне бывает.
Вот просто в точности, что ты описал — я столкнулся... Пункт 2. Когда-то в мезозойскую эру программирования (до появления интернета) мы все писали сами, так как не было возможности найти чужую библиотеку и ее использовать. Например, в одном договоре мы придумали язык для разработки, скрестили PL-1 и Lisp, на этом написали интерпретатор нашего языка и на нем уже написали сам договор. От подписания договора до подписания акта приемки прошло 3 года.
Сейчас в инете по любой теме дофигища фремворков. Берут просто готовое. Это сокращает время на непосредственно разработку, но требует освоения сторонних библиотек, документация для которых частенько отсутствует. И о подводных камнях в чужих водах забывать никак не следует.
В этом плане мне очень нравится Go — у него в стандартной библиотеке есть почти все. А чего вдруг нет — легко написать и подключить свой пакет. Пункт 3. Абсолютно так и есть. Пункт 4. Все так, как ты описал. Я столкнулся с С++java+Go+Python+bash. И еще есть C#. Само собой и json, и xml, и yaml и т.д.
И еще есть части, куда я вообще не смотрел — не входит в обязанности.
И все это как-то собирается кучей разных инструментов и работает вместе. Пункт 7. И вот это — самое неприятное.
Так как для проверки даже небольшого рефакторинга нужно пересобрать новую версию измененной части и подключить ее к работающей системе.
Но мне все равно интересно, поскольку я давно не был в реальном промышленном программировании и многие вещи пришлось осваивать буквально с нуля.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Скажем так. В индустрии, когда задействована большая команда, и они пилят большой проект, очень много ролей как бы вроде и технических, но они непосредствено ничего нового не создают.
Т.е. есть пара-тройка человек, которые что-то интересное делают, какой-нибудь алгоритм выдумывают или какую-то хотрую оптимальную реализацию, а к ним куча кодеров, тестеров, интеграторов, архитекторов, и повер них всех куча лидов и менеджмента. Ну и вот, например, лид может сам ничего не разрабатывать, а только быть в курсе основных технических вопросов, но у него в подчинении, например, 5 человек, и он со множеством других отделов связан, координирует работу со своей командой, и поэтому на нем ответственность выше, чем на рядовом окопном программисте, и требуются соответствующие навыки коммуникации. И поэтому ему, конечно, платят больше. А уровень зарплат определяется не столько "интересностью", сколько прибылью от продажи услуг или продуктов.
Тот же автомобиль — условно говоря 10% исследований и интересных моментов разработки, и 90% условной "кладки кирпичей" и того, что уже десятилетиями отработано.
Здравствуйте, LaptevVV, Вы писали:
LVV>Нарыл на просторах инета LVV>
Есть в профессиональном программировании неприятная связь: чем больше зарплата, тем скучнее работа.
LVV>Это много где бывает, но в программировании это очень сильно проявляется.
LVV>В скучных проектах, где однотипная, скучная работа, там платят больше как раз, чтобы дополнительно привлекать хороших специалистов.
LVV>И для многих то, что я написал, выглядит как на картинке — но я знаю много разработчиков,
LVV>которые с этим столкнулись и в итоге выбрали проект поинтереснее, с более маленькой зарплатой.
LVV>Это правда?
Это правда. Причем по вполне понятным причинам: за скучную работу платят больше, ибо меньше людей хотят этим заниматься.
LVV>Это правда?
Удивляете, профессор. Конечно, правда.
Любая работа, если в ней нет вариативности реализации, скучна для профессионала т.к. делается механически.
Есть варианты, как разнообразить работу.
Можно делать работу нестандартными методами: избыточно усложнять архитектуру, начать писать код в другом стиле, абстрагировать реализацию до уровня "а вдруг пригодится", уговорить начальство согласовать переписку на другую технологию.
Так обычно делают относительно молодые разработчики. Люди с опытом находят сторонние проекты для интереса или обучения, или появляются интересы вне разработки, а рутину стремятся сделать минимальными усилиями.
Здравствуйте, LaptevVV, Вы писали:
LVV>Это правда?
Думаю, что правда, но для мидлов и ниже, где, действительно, полно работы по запиливанию уже написанных спецификаций в уже написанных фреймворках. Высокооплачиваемая работа не может быть скучной, т.к. скука = механическая работа = можно нанять кого-нибудь подешевле
Здравствуйте, LaptevVV, Вы писали:
LVV>Нарыл на просторах инета LVV>
Есть в профессиональном программировании неприятная связь: чем больше зарплата, тем скучнее работа.
LVV>Это много где бывает, но в программировании это очень сильно проявляется.
LVV>В скучных проектах, где однотипная, скучная работа, там платят больше как раз, чтобы дополнительно привлекать хороших специалистов.
LVV>И для многих то, что я написал, выглядит как на картинке — но я знаю много разработчиков,
LVV>которые с этим столкнулись и в итоге выбрали проект поинтереснее, с более маленькой зарплатой.
LVV>Это правда?
IMHO такая тенденция есть, но не факт, что она доминирующая.
).
