Pull to refresh

Comments 633

Ну а что могут 20 летние зумеры в таком случае?
Ну так у зумеров много сил и рвения) Все старые программисты когда-то были молодыми зумерами в своё время
О да, молодых любят :-) Но совсем по другим причинам.

1. Кранчи и Work-life balance. Это молодому «зумеру» легко навешать на уши лапши, что «ах клиент хочет вчера и надо напрячься». Опытный коллега сразу спросит про компенсацию и «почему я теперь должен спасать факап менеджмента бесплатно, не я же обещал что завтра будет готово».

В итоге — 40-летние+ спокойно коммитят код с 9 до 6, прекрасно зная по опыту, что «breach the contract» это весьма часто — лишь способ манипуляции линейным персоналом, чтобы менеджмент получил больше бонусов.

А вот 25+ — воспринимают это за чистую монету и живут в офисе. Да и молодежь обычно еще не обременена семьей / детьми, и только у них есть физическая возможность жить в офисе.

2. Нематериальные плюшки. Молодежи важна трех-долларовая маечка с надписью «лучшему кодеру полумесяца в макдональдсе». Старый аксакал собирает деньги на учебу детей в Гарвард, и ему лучше еще немножечко презренных дензнаков. Что сильно дороже сумки с логотипом компании.

3. Амбиции и Чувство вины. Молодежь оптимистична, часто на себя берет «повышенные соцобязательства». Как результат — становится объектом манипуляций нечистоплотных менеджеров, которые вызывают чувство вины и прилив энтузазизьма, просто регулярно напоминая как «пообещал но не сделал». Это опытному быдлокодеру такие заходы знакомы и вызывают только ехидную ухмылку. Аксакал обычно себе уже все доказал, а вот молодой и горячий — строит карьеру.

4. Численность бьет класс. Ну и самое главное, в огромном числе проектов выбирается экстенсивный путь развития. Надо больше vespen gas рабочих рук, которые 3/4 времени будут сидеть на митингах, писать мало-осмысленные юнит-тесты и ревьюить код друг друга. Аксакалы с их опытом и видением разложенных граблей — просто не нужны в таких количествах.

А то что молодежь при этом соберет все возможные грабли — так смотри первых три пункта, при минимальной аккуратности эффективных — ошибки и переделки пойдут в счет (само)обучения той же самой молодежи «и без дополнительных капиталовложений» (С).

:-)

Опытный коллега сразу спросит про компенсацию

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

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

Уже годам к 30 все учатся соблюдать график. Если где-то ушел раньше раньше или пришел позже (случаи разные бывают), то без напоминаний поработаешь в другой день побольше.
Легко сорвать срок, если узнаёшь, что он был, когда он уже сорван. Ну и классическое:
— У нас срок до воскресенья, потому что в понедельник показываем заказчику
— Не успеем, слишком много нужно сделать
— Надо успеть
— Вряд ли

— Вы не успели в срок, что будем с вами делать?

Есть немного другая концовка:
— Успеем только если будем забивать на мелочи и делать хоть как-нибудь, лишь бы было
— Делайте так

— Заказчик очень недоволен, ругается, потому что всё еле-еле работает и не соответствует дизайну, у нас есть 700 правок, срок до пятницы, но учтите, что вы уже поставили компанию в неудобное положение

Всё остальное тоже может иметь нюансы.

У вас срок до воскресенья? ладно, выкатываем MVP. Уметь будет вот это и вот это и более ничего. Не забудьте сообщить заказчику, чтобы он не сильно удивлялся на показе. А если ещё раз подпишетесь на такое без предварительного получения оценки от разработки, я буду вынужден поставить проблему перед руководством.

но учтите, что вы уже поставили компанию в неудобное положение

это работает против молодого разработчика, который строит карьеру.


Аксакал в этот момент улыбается и делает ручкой "пока-пока".


И менеджмент остается у разбитого корыта, заваленного говнокодом.

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

Какой же он тогда аксакал, если не имеет? :) Если он не имеет опыта смены работы, если он 10 лет сидит в компании на той же должности — значит на него все еще действуют все те же паразитные программы менеджемента. И он, в общем, не аксакал, а засидевшийся на одном месте джун.


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

Дык, если работа устраивает, чего ж её менять? Это стресс, собеседования, новые технологии, в которые чуть ли не с нуля вникать, новые коллеги, которых по именам запоминать, отставания на первых порах из-за непривычных методик. А если делать всё по уму, то сперва месяц-два поизучать новое, посидеть это время без работы, а уже потом устраиваться. Каждый год так по месяцу без работы сидеть, это не каждому по карману. Хотя я понимаю, что сейчас высказал нехарактерную для IT позицию.
но учтите, что вы уже поставили компанию в неудобное положение
Не навсегда же, а только в одной ситуации :)
если работа устраивает, чего ж её менять?
Лучшее — враг хорошего. И в этой войне важно правильно выбрать сторону.

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

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

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

А ходить по собеседованиям чтобы «узнать свою стоимость» мне психологически некомфортно.
Ну вот я пришёл на конферению/митап, пообщался с народом и кто-то из них сказал что-то вроде «а давай ты лучше к нам, у нас печеньки слаще». Мне теперь к ним не идти на собеседование и не узнавать слаще ли они на самом деле?
Вы можете сходить, конечно.

А мне было бы некомфортно, и если на текущем месте всё устраивает, то я им скорее всего скажу «Спасибо за предложение, но в данный момент не интересует».
Но «всё устраивает» это же достаточно субъективное и «относительное» состояние.

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

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

Но как узнать если не узнавать? :)
Повторюсь, я понимаю о чём речь, но чувствую дискомфорт от обсуждения потенциального трудоустройства, если реально никуда не собирался и не собираюсь.

Такое вот субъективное и «относительное» состояние. И уверен, что не один такой уникальный.

Вот соберусь уходить, тогда и пойду посмотрю, что и где предлагают.

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

tommyangelo27 понял, о чём я писал.

От себя добавлю, что если я узнаю, что в другой компании платят в два раза больше на той же должности, то у меня закрадётся подозрение, что так гоняют в два раза сильнее, и если я уже сейчас выматываюсь, то там вообще не вывезу.
У этого даже название есть — «синдром самозванца». Достаточно серьезная проблема, между прочим.
А вдруг я и в самом деле работаю в расслабленной компании или и правда начал сдавать из-за возраста и не поспеваю за темпами работы?
Расслабленность компании плохо коррелирует с зарплатой и с возрастом. К примеру взять амазон — одна из самых не расслабленных больших компаний, но с отнюдь не максимальными зарплатами. Или там взять многочисленные конторы, которые работают на фрс — они, в целом, достаточно на расслабоне работают, но иногда там имеют всех (причем реально всех, и начальство и всех кто ниже), одновременно, и разнообразно.
Ну и как бы, расслабон понятие такое, растяжимое. Я вот собираюсь валить с текущей конторы именно из-за него. Бо еще годик другой, и уже окончательно разучусь делать хоть что-то кроме красивого письмописания…

И кстати, многие ходят на собеседования именно что б ответить на вопрос: «правда начал сдавать из-за возраста ». И айчары в курсе )
Вы сейчас на тему расслабона, про dev или про qa? Т.к. dev и qa это очень разная работа.
Расслабон — он на проекте. А не у dev/qa/ect. Если у вас только кто-то один пашет а остальные смотрят — то что-то у вас явно не так…
но учтите, что вы уже поставили компанию в неудобное положение

Мораль: всё общение по части сроков, объёмов, переработок, обещания премии — только письменно!

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

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

Переработки к релизу и большому запуску с пусть даже неформальными отгулами потом это нормально. Не стоит из-за них переживать. Главное чтобы это в норму не превращалось.

Если коллектив сложившийся — то да, человеческие отношения рулят. Но есть же вариант свежего менеджера, который вторгается в это тёпленькое болотце и сходу рвётся руководить :)
Таких можно и нужно осаживать: "Братиш, я по всё понимаю, НАМ ВСЕМ (ну т.е. тебе) ЭТО ОЧЕНЬ НАДО!!!1 Но вот есть регламент, большим начальством писаный. Так что давайте соблюдать… " :)

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

Зачем в таких местах работать?

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

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

Договариваться с разработкой да. Согласовывать да. Но не руководить.

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

Менеджер может быть играющим тренером.

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

Если вам нравится работать в болотцах — это, конечно, ваш выбор.

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

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

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

Вы настаиваете на первых
Нет, не настаиваю. Может, вы меня путаете с кем-то
Как показала практика, если руководство что то решило, то записи не помогут.
С теми, кому недостаточно напоминания, о чем договаривались, не нужно работать
Однозначно! Полностью согласен.
— Заказчик очень недоволен, ругается, потому что всё еле-еле работает и не соответствует дизайну, у нас есть 700 правок, срок до пятницы, но учтите, что вы уже поставили компанию в неудобное положение

Ну классическая же манипуляция. Это чисто проеб менеджмента.
Ну так собственно говоря, это и есть классические не чистоплотные манипуляции.
" У нас срок до воскресенья...."

«Вы не успели в срок...»
Срок у «нас», не успели «Вы». Это манипуляция.

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

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

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

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

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

Как говорится, на работе Ж рвут не там, где много платят, а где у начальника большие амбиции.
В статье упоминается постоянная необходимость переобучения, если призадуматься это окажется большой проблемой. Т.к. вместо профессионального использования капитала знаний человеку приходится его выбрасывать. Т.е. ты копил полжизни интеллектуальный багаж, а он устаревает вместе с технологиями. Такого (почти нет) в других специальностях, например врачу не нужно изучать анатомию человека, она не меняется. Возможно, меняются подходы к лечению и выпускаются новые препараты, но это несравнимо с устареванием знаний у айтишников.
Не соглашусь. У меня жена врач, в течении года посещает множество конференций, всяческих вебинаров с экзаменом в конце и т.д., за которые дают какие-то баллы, без которых сертификат просто не продлят. Да анатомия не меняется, но появляются новые знания, технологии, препараты, опыт и т.д. В IT основы так же не меняются — регистры, логические элементы, память…
Я считаю, что там смена технологий и методик лечения происходит не настолько стремительно как в ИТ. Даже внутри ИТ есть очень разные по скорости перемен ниши.
А зачем считать, как говорится? Можно просто учесть одну тонкую разницу. Если программист пишет на каком-то старом языке, и всеми забытом фреймворке, то над ним посмеются. Если же врач вдруг начнет выписывать рецепты по устаревшим стандартам, то ему светит вполне увольнение и даже уголовная ответственность. Насчет того, как часто это приходится менять врачам, вопрос интересный. Но это тема большого исследования. Раз в 5 лет кардинальное переобучение у врачей вполне возможно.

www.youtube.com/watch?v=JVTWoPeMWSQ&ab_channel=VJLECOMIXVJLECOMIX — это будет здесь в тему.
>Если же врач вдруг начнет выписывать рецепты по устаревшим стандартам, то ему светит вполне увольнение и даже уголовная ответственность.

Спасибо, посмеялся, если имеется в виду РФ. Консультирую родных, которым выписывают гомеопатию, «фуфломицины» и антибиотики «на всякий случай пропить».
врач вдруг начнет выписывать рецепты по устаревшим стандартам, то ему светит вполне увольнение и даже уголовная ответственность


Мда, вам ещё и минус влепили. Правило 95% работает и для хабра )

Хотя про ИТ не соглашусь… у веб-макак может быть все знания и устаревают за 3 года. На backend время жизни технологий 10-30 лет точно, меняется только шелуха — виртуалочки, докер, шмокер, облака…
Как автор статьи habr.com/ru/company/yandex/blog/455080 — про тех же программистов за 35, хочу возразить. Скорее наоборот, у врачей наиболее шустро устаревают знания из всех имеющихся профессий. Я не знаю, откуда взялось мнение, что именно айтишники устаревают быстрее всего по знаниям — возможно, сами айтишники его и распространяют в интернете).
медицина начала очень быстро меняться последние 20 лет. С развитием доказательной медицины и развитием интернета среди медработников так сказать.
А мнение про айтишников возникло еще в годах девяностых))
Тогда появилось много новых популярных языков и айтишных сфер.
В девяностых чего только не было. Предсказывали даже скорое вымирание профессии программиста из-за распространения генераторов программ и технологий визуального «программирования без программирования».
Предсказывали даже скорое вымирание профессии программиста из-за распространения генераторов программ и технологий визуального «программирования без программирования».

Вы не поверите что в 2021 году происходит…
Программисты вовремя просекли этот тренд и нанесли жесткий удар по технологиям визуального программирования. Теперь все опять мучаются с консольками, как в 80е. :(
Вы о чём? Какие программисты и самое главное каким образом что-то там «пресекли»? Большинство известных мне программистов даже наоборот сами с удовольствием пользуются IDE и прочим тулингом для облегчения работы.

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

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

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

Ничего не устаревает. Как условную рекурсию или циклы придумали, так они и актуальны по сей день. Как и у врачей, к базовой «анатомии», просто периодически что-то добавляется.
Устаревают языки. Например, сейчас ведь новые проекты на Visual FoxPro ни кто не начнёт. Устаревают технологии.
Технологии да, устаревают… Были супер компы, к которым были подключены тонкие клиенты, потом пошла эра персоналок, потом персоналки становились все мощнее, мощнее, мощнее… И оппа. Сижу я на девайсике, в котором единственное чего много — это оперативки (спасибо веб разработчикам), офис — на серверах майрософта, игрушки — на серверах гугла, видосики — у нетфликса, рабочий софт — вообще много где, а локально — броузер, впн, цитриск и ремоут десктоп. Ах да, сама ось тоже локально, хотя в офисе кстати, локальной оси уже нет )
Ну или там с разработкой — то мы все пишем в один файлик, то мы разделяем данные и код (ног в передах одного ехе файлика), то мы разделяем бизнес логику и код и данные, то мы разделяем каждую функцию на отдельный сервис с отдельными данными внутри, то опять все вместе…
Так что технологии не столько устаревают, сколько переосмысливаются и переделываются по спирали.
А если там поскрести под фреймворками то что там принципиально нового?.. Низкий порог вхождения? Его заявляют начиная от первого появления ассемблера (ну, не двоичный же код — любой школьник осилит). Универсальность под все системы? Ну так опять таки — компилирование из сорсов придумали уже сто лет как, и если сильно подпрыгнуть — оно универсально.

Новый проект на FoxPro начали бы со свистом, если б смогли его продать. Но там чисто юридические нюансы. Которые, кстати, лихо обходятся при достаточно высокоуровневом вмешательстве. К примеру — одна широко известная контора не шибко дорогих видеокарточек, в свое время решила закопать стюардессу и выключить в своих видео драйверах поддержку винХП. А потом резко включила ее обратно, бо китай и сказал человеческим голосом — у нас тут несколько миллионов карточек надо, что б народ в геймклубах веселить, и там по плану винХП будет стоять. Так нам как, у вас брать, или у конкурентов? И чудо, все технологии резко перестали быть устаревшими ;)
Т.к. вместо профессионального использования капитала знаний человеку приходится его выбрасывать. Т.е. ты копил полжизни интеллектуальный багаж, а он устаревает вместе с технологиями.

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

Сравните, например с багажом знаний скульпторов и художников, столяров, сантехников, музыкантов. Какой % их знаний становятся «чемоданом без ручки»?
Аналог «анатомии» у программистов — это алгоритмы, структуры данных, базовые всякие вещи, они тоже не меняются. Quicksort как 50 лет назад был, так и остался. А в медицине столько всего поменялось с тех пор, почитать и ужаснуться — и горчичники, оказывается, не нужны, и банки, и корвалол не обладает доказанной эффективностью, и от зеленки вообще вред (но это не точно)… И зубные врачи уже не ставят пломбы из серого цемента, как было, казалось бы, совсем недавно.
Quicksort как 50 лет назад был, так и остался.

Только, скажем, за последние 20 лет появился timsort, introsort (ладно, этому 23 года), block sort (а вот этому вообще всего лет десять-двенадцать), и ещё с полдюжины чуть более узкоспециализированных сортировок.

В анатомии тоже, бывает, что-то меняется
block sort (а вот этому вообще всего лет десять-двенадцать)

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


Ну и да — это же все гибридные алгоритмы, т.е. базисно в них ничего нового нет.

Кучи разнообразного легаси требующего поддержки по идее никуда не деваются, поэтому проблема необходимости постоянного (пере)обучения хоть и присутствует, но имхо не всегда такая уж страшная.
Автор зря за возраст цепляется. Статистика его, может, и верна, но вот выводы он неверные делает. Молодежи много потому, что условно говоря, 20 лет назад программировал 1 из 1000, 10 лет назад 5 на 1000, а сегодня уже 20 на 1000, например. Конечно, в таких условиях условно молодых программистов будет больше, но это не значит, что старики, которым по 40, идут мести улицы или выходят на пенсию.
могут кодить — но не программировать

Посмотрите документальные фильмы про разработчиков Unix и тд - там большинству программистов явно за 40. А к 30 человек только начинает сносно разбираться в матчасти

Могу сказать 30 лет в матчасти до уровня сносно ещё пилить и пилить.(

Это зависит от того, когда человек начал. Если один начал писать код в 21, а другой — в 11 лет, то к 25-30 у них будет довольно разный опыт.
И от интенсивности оно тоже зависит. Если один ограничился лабами в вузе и кодом по работе, а другой все свободное время на это тратит — опыт тоже будет разный.

Важен всегда опыт, основанный на реальных задачах. Вряд-ли 11 летнему доверят энтерпрайз задачи. Максимум медиаплеер напишет. Я в 11 лет писал программы на Бейсике для Спектрума. Совершенно не имеющие реальной ценности. Зато могу этот момент описать в резюме и у меня 25+ лет знания Бейсика...

Будто бы 90 процентов энтерпрайза это что-то более сложное, чем какой-нибудь vk плеер. В 11 лет можно прекрасно себе в удовольствие лепить моды к игрушкам и получать вполне себе хороший опыт.

Я в 14 лет писал архиватор на алгоритмах, которые я сам придумал, я писал свою GUI-библиотеку. В 33 года мои энтерпрайз задачи из рода "при нажатии кнопки Save заменить по тексту определённые ключевые слова на ссылки". Причём мне сейчас за 4 часа работы платят столько же, сколько в 20 лет платили за месяц (ну тут лукавлю с инфляцией и прочим, конечно, но всё же забавно). Я уверен на 100%, что с подобными задачами в 14 лет я бы справился влёт.

Или стало бы скучно и просто забил на задачу.

Хороший опыт у Вас. У меня не очень. И да, в 14 трудно поверить что могут за это заплатить много.

В 11 лет я, конечно, совсем ерундой всякой занимался, но и начинающий в 21 писать код не начинает с энтерпрайз-задач.


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


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

а другой — в 11 лет
Ага, писали бы уже с 5-ти лет.

Зачем? Я ж по своему опыту пишу, а свой первый код я написал лет в 10 (по крайней мере, на моем первом сайте была строка «в $monthname 2002-го года мне будет 11 лет»). Конкретно на плюсах — лет в 11 или 12, лень восстанавливать точно хронологию.

Я на калькуляторе МК-52 свой первый цикл написал лет в 9, а к 11 мог уже там программы для вычисления на уровне моего тогдашнего знания математики писать. Отдельным развлечением было закодить что-то типа полета к Луне. Типа есть у нас число 8000000003 и мы делаем мультик, когда поочередно меняем нули на восьмерку и при исполнении программы кажется, что что-то летит. Конечно, это не было что-то сверх выдающееся, но вполне было программирование. Кстати, по сути на ассемблере. А еще там обратная польская запись, что отдельно доставляет — приносил как-то в школу, одноклассников троллил, потому что они банально не могли сложить два числа :).

в 11 лет вполне нормально.
Я на ассемблере писал маленькие процедурки, и на бейсике доделывать логику для простых вещей. Написал редактор уровней для Laser Squad на спектруме. Работало.
Ну, Вы были просто гениальным ребенком.
Сейчас вы уже взрослый и каковы результаты?
Вы достигли успеха на мировом рынке со своим продуктом?

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


Сейчас вы уже взрослый и каковы результаты?

Оффер в 22 года на синиорскую позицию с релокацией в США и очень неплохой (особенно для выпускника вуза) зарплатой.


Правда, лет в 26-27 я сломался и понял, что мне по-настоящему интересны те аспекты программирования, за которые не платят, но это другая история.


Вы достигли успеха на мировом рынке со своим продуктом?

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

Правда, лет в 26-27 я сломался и понял, что мне по-настоящему интересны те аспекты программирования, за которые не платят, но это другая история.

Это у многих так.
Спасибо за ответ.
Долго думал, что написать, чтобы не обидеть кого либо.
Читаю Хабр и думаю, сколько же много умнейших ребят!
А где их программы?

Для многих тысяч программистов попасть в США на хороший проект — это несомненно успех.
А дальше что?
Что будет после 60 лет.
Программирование не требует больших усилий. Можно код клепать и до 100 лет.
А где их программы?

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


Что будет после 60 лет.

А что там должно такого интересного быть?

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

Так интереснее становится и до 60 лет, а выглядело так, будто вы установили некий порог в 60 лет.

Программирование не требует больших усилий. Можно код клепать и до 100 лет.

Эм… кто это вас обманул?
Код клепать без усилий — это домашний комп почистить, видяшки с камеры конвертнуть скриптиком.
А писать большой продукт — это большие усилия, и прежде всего организаторские.

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

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

-Эм… кто это вас обманул?

Да, Вы правы. Спасибо за уточнение.
Я ошибся. Хотел написать физических усилий.
Мне кажется что профессия программиста самая сложная.

Вы кроме программирования чем-либо в жизни увлекаетесь?
-фотография
-авиамоделизм
-чтение
-садоводство
-3D моделирование
-акварель
Тогда какие проблемы? У вас и кроме программирования достаточно увлечений, чтобы хватило до конца жизни. Не одним кодом все живут. У меня тоже достаточно увлечений, чтобы не думать о ИТ после работы.
Тогда какие проблемы? У вас и кроме программирования достаточно увлечений, чтобы хватило до конца жизни. Не одним кодом все живут.

И на что жить, на пенсию?
Мой однокашник работал примерно 20 лет программистом в Харькове.
Сейчас внуков нянчит. И подрабатывал каким то сторожем или еще кем то, не помню.
Написал очень интересную книгу «Космический султан».

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

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

А кто сказал, что это легко?
Я однажды привлек к своему проекту очень талантливого программиста Юру Наконечного. Он поработал несколько месяцев и отказался.
Ребята хотят по быстрому срубить бабла.
Разве плохо, если одна из моих программ принесет мне более миллиона продаж?
Сейчас, когда половина населения земли имеет интернет, это уже не выглядит не реальным.

20 лет назад я мечтал, чтобы мой проект проглотила фирма MS.
Сейчас я не продамся и за 10 миллионов баксов.
А кто сказал, что это легко?

На мой взгляд это не из категории легко/сложно, а скорее из категории повезло/не повезло. То есть грубо говоря ваша идея должна выстрелить примерно как какой-нибудь фэйсбук, твитер, инстаграм.

Разве плохо, если одна из моих программ принесет мне более миллиона продаж?

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

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

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

То есть много денег за программу вам будут платить скорее в бизнес-сегменте. Но там и спрос ниже и конкуренция обычно достаточно высока.

То есть удачи конечно. Но на мой взгляд это не то чтобы железобетонный план для обеспечения старости :)
Но на мой взгляд это не то чтобы железобетонный план для обеспечения старости :)

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

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

10 лет назад я подумал, почему я должен выбросить на мусорку свой проект, на который потратил 10 лет жизни.
Ребята сделали один ящик и продают программу-клон мебельной Pro100.
А у меня функционала в 10 раз больше и я лох даже не пытался продавать. Хе-хе.
Там что легко зарабатывать?
Смотря сколько и при каких рисках зарабатывать. Иметь условные 10% годовых в валюте (без учета инфляции и налогов) с разбросом типа «до 40% отдельных годов могут закончиться чистым убытком, но в среднем за 15 лет доходность будет от 1% до 20% годовых (а если сгладить на более длинный промежуток, то и еще стабильнее)» — вполне легко, достаточно купить ETF на индекс акций широкого рынка
Я думаю, что железобетонный план для обеспечения старости вам никто не предоставит.

Мне хватит и более-менее реалистичного.

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

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

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

Мыши, станьте ежиками!
Где вы возьмете миллион стратега не волнует.
На мой взгляд сейчас в куче стран айтишники зарабатывают достаточно чтобы можно было ещё и откладывать денег на старость.
Ну так-то в масштабах жизни и зарплат программиста на мировом рынке миллион долларов скопить вполне реально. 1 млн долларов за 47 лет — это по $1'773 в месяц
Легко выполнимая задача, если нет жены.
В 1989 году я открыл сверхсрочный вклад в размере пары тысяч рублей под 3% годовых, предполагая что лет через 50 за счет сложных процентов я буду обладателем солидной суммы в самой твердой валюте мира — советском рубле.
Увы, долгосрочное планирование не всегда работает.

Да, экономика США пока выглядит стабильней. Но что-то они там с левыми идеями стали заигрываться.

И даже если без «черных лебедей»… Просто найти такой банк, который через 50 лет гарантирует возврат депозита в полном объеме не так уж и легко.
Ну так первая заповедь — все нужно диверсифицировать. Если погибнут банки во всех странах мира, то у вас явно будут проблемы поважнее, чем «куда делся мой миллион»
Разве плохо, если одна из моих программ принесет мне более миллиона продаж?

Вы просто пишете программы, а потом думаете что их кто-то купит?

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

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

Вы угадали.
Я просто пишу софт, который надеюсь продавать.
И люди уже покупают, пока мало. Нужно графику улучшить.
У меня она 20-летней давности.
И люди уже покупают, пока мало. Нужно графику улучшить.
У меня она 20-летней давности.


Вы уверены, что как только улучшите графику сразу поползут продажи?

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

Так и у вас. Дело не в графике, дело в маркетинге.
А в этом плане довольно сложно программисту, который в основном кодил, а не продавал, стать внезапно хорошим продажником.

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

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

убогие —
Практически любой софт для работы с бесперебойниками, много софта для работы с фотоаппаратами и камерами — они монструозные, непонятные, проблемы с совместимостью. Внутренний софт роутеров, даже брендовых — глючность совершенно не вызывает желания докупать платные фичи. Если же посмотреть какие деньги платятся под кастомный ентерпрайз и в каком виде его сдают, про него лучше ничего не говорить.
Winrar как раз монетизировали, и видимо Евгению оказалось достаточно — он пошел его монетизировать дальше, а FAR отдал в свободные руки fargroup, как опенсорс.
— Я например, хочу добиться, чтобы продажи моей программы приносили мне существенный ($5 тыс в месяц) доход.
И с годами только росли.

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

А вложить можно в детей, которые будут помогать. В недвижимость. Отложить в принципе в более-менее твердой валюте.
Программу вам может уже кто угодно написать, за деньги.

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

Да ладно, вполне норм.

Но мозги ведь надо разгружать, хоть иногда)))
Я думаю saboteur_kiev был нормальным умным ребенком как 95% здесь собравшихся. Дети очень сильны в задачах имеющих четкие правила и не требующих жизненного опыта — видимо за счет высокой концентрации если есть интерес. Не знаю как в киберспорте, а в шахматах — заметно. В математике тоже такое часто встречается (или скорее встречалось — математика стала очень объемной и развесистой). В музыке — там правда физиология влияет, но также много очень приличных музыкантов.
Ну, конечно!
95% здесь собравшихся программировали на ассемблере в 10 лет.

Я как то попробовал и даже купил книгу про ассемблер. Круто же.
Каждый программист должен же на ассемблере писать.

И не помню на 2-й день или 3-й забыл про свое желание.
Возможно звезды не сложились. Не нашлось задачи, не нашлось среды, не нашлось наставника, отвлеклись на что-то другое, и т.п… Т.е. это вопрос не о способностях, а о мотивации и условиях.
Я как-то пошел на курсы по асму (ну правда мне было уже лет 20), и понял, что это очень просто. Но я с 1-го курса института (с 18 лет) работал в программисткой фирме. А комп увидел вживую в 15 лет только — БК-001. Т.е. время было чуть другое, и да — я не компьютерный гик.
Не в ассемблере дело.
Я считаю, что на C++ проще код писать чем на ассемблере.

Если бы мне этот ассемблер нужен был, то освоил бы. Не такой уж я и тупой.

А C++ и ассемблер вообще как-то нужно сравнивать?

Когда у тебя на всем компьютере всего 32Кб ОЗУ, и компиляторы с языков высокого уровня не очень умеют в оптимизацию, и к тому-же отсутствуют хоть какие-то библиотеки кроме стандартной, то как-то сложно написать что-то более менее приличное не на ассемблере.
Это я про реальность ~30 лет назад, если не совсем понятно…
Ну, Вы были просто гениальным ребенком.

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

Сейчас вы уже взрослый и каковы результаты?

Результаты чего?
Ну неплохо понимаю как все работает в ИТ.
Собственно работаю в этой сфере, все нравится.

Вы достигли успеха на мировом рынке со своим продуктом?

Если вы обратили внимание чем именно я занимался — я работал с компьютером, а не с рынком. Достигать успеха на мировом рынке со своим продуктом — это больше к бизнесу, а не к коду.
Ну а с компьютером — ко-создатель первой интернет-аптеки в стране, запустил первый в городе ММОRPG, админил несколько серверов с онлайном до 100к. Также принимал участие в некоторых проектах мирового уровня, например NDA1, NDA2 и еще NDA3, но там уже не игры, поэтому вы можете в почти любом магазине техники видеть только то, где я был в NDA1.
И это я еще вообще не программистом стал…

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

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

При чем здесь футбол? Тема о программистах, которые должны быть готовы, что в 60 лет они могут не найти себе работу.
Что для этого времени у них есть 30 лет, чтобы хорошо подготовиться.
У Вас много достижений, снимаю шляпу. Вы гораздо круче выглядите на собеседовании, чем я.
Я так понял, что Вы работали не на себя а на дядю.
Ибо, я так понял Ваши слова — Достигать успеха на мировом рынке со своим продуктом — это больше к бизнесу, а не к коду.
Тема о программистах, которые должны быть готовы, что в 60 лет они могут не найти себе работу.

А они должны?

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

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

То есть я знаю что парочка таких «пенсионеров» у нас на фирме время от времени делают там что-то для легаси проектов на почасовой оплате. Но как я понимаю с финансовой точки зрения они и без этого могут обойтись.
При чем здесь футбол? Тема о программистах, которые должны быть готовы, что в 60 лет они могут не найти себе работу.


Эм, если человек — специалист, то он найдет работу.

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

Не будете ли так любезны, кинуть ссыль на докфильмы?

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

что это значит? "… много опыта… нет рабочего опыта"

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

GitHub это прежде всего репозиторий для рабочего инструмента, а не витрина товара или себя-любимого. Разумные причины хранить что-то в публичном репозитории это проект с открытым исходным кодом и/или общественные проекты. Ни один работодатель или заказчик в здравом уме и трезвой памяти не разрешат выкладывать в открытом виде туда ничего, даже фрилансер подписывает кучу бумаг, включая NDA.
Что же касается счетчиков_калорий, магазинов_петов, калькуляторов и другого бесполезного хлама — честно я не знаю для кого это все. Ни я сам и ни один из моих коллег за все время работы на это никогда не смотрели. Это даже для большинства HR и рекрутеров просто мусор т.к. даже они понимают, что это вообще не показатель ничего. Более того, последние 3 года я встречаю такое явление как черезчур хитро… кхм умников которые меняют пару строк туда сюда каждый день для имитации активной деятельности зеленых квадратиков. Среди вайтишников ходят легенды, что это дает + 100 очков на интервью. Почему? Не знаю.

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

Пропустить даже не рекрутера, HRа или предварительный отсев, а именно техническое интервью с техническим специалистом? Очаровательная фирма, у Тим Лида каждый рабочий день — праздник)

Да не, нормальные фирмы, вы даже о некоторых из них наверняка слышали. Вы как-то слишком скептически настроены :]

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

Не, какой гений. У меня не то что топовые какие-то вещи там. Не реакт, не гхц, даже не буст.хана.

Мне тоже порой рекрутеры пишут, что «посмотрели мой гитхаб, он заинтересовал, давайте общаться». Вот только есть нюанс — у меня на гитхабе нет ничего :)
А мне прямо в самом интерфейсе Гитхаба рекрутёрша писала (через механизм Follow). Активность тоже на уровне 7 коммитов за 2 года.

Интервью-то скипают? :]


Приглашают, кстати, просто так, или более-менее по вашему настоящему стеку?

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

… кроме тех, что целенаправленно скажут что пишем опенсурс. Да, за зарплату. Да, в открытый доступ. Да, корпоративно. Да, заказчик в здравом уме.

Да, именно это я написал на моменте "это проект с открытым исходным кодом". Да, так переводится с английского. Да, именно это оно и есть. Да, да

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

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

Да и не в этом же дело. Вопрос изначально про кандидатов с "гитхабом". Если у человека в публичном репозитории не его личный проект с открытым кодом, то толку от гитхаба на собеседовании нет. Любые другие варианты никак не подтверждают ни навыков, ни опыта, а огромное количество умников таскающих чужие проекты для "витрины" и накручивающих звездочки давно скомпрометировали любые крохи доверия к просто участникам открытых проектов. Будет ли в таких условиях условный Тим Лид или тех. специалист на собеседовании тратить своё время на разбор полетов на "настоящий ли это проект и действительно ли Вася Пупкин принимал в нём участие и действительно ли вносил вклад и действительно ли вклад этот по озвученным в резюме навыкам"? Думаю нет

Я честно говоря не понимаю вообще о чем речь. Какой смысл показывать гитхаб аккаунт, если там не ваш код? У меня на гитхаб аккаунте исключительно мои проекты, либо проекты в которые я контрибьютил(мне тупо нужно было сделать форк, чтобы создать пулл реквест), либо мантейнером которых я являюсь.
Да и без гитхаба были случаи, когда на собеседовании выяснялось что собеседующий пользуется кодом, который я когда-то написал.
Я тоже смысла не вижу, но частенько попадаются люди которые в гитхаб натаскали с миру по нитке проектов и пытаются «козырять» на собеседовании. Более ленивые просто пушат каждый день по строчке чтобы казалось, что у них работа кипит. А еще «проектов» от всяких инфоцыган навалом. Видел как-то в одном аккаунте около десятка таких + тестовые задания от разных фирм. Рекрутерам нравится, даже HR, бывает, очаровываются подобным.
Никогда не было проблем убедить начальство что что-то открыть — выгодно.


Удачи сделать это в каком-нибудь банке, хотя бы в МКБ для начала.
Зачем работать в таком месте? Я работал в закрытом НИИ при роскосмосе и даже там начальство было не против, хотя там была масса бюрократии и всяких юридических ньюаесов. Потому что они тоже инженеры и понимали что такое open source и какие преимущества это дает.
А в вашем банке скорее всего какие-то идиоты, которые надеются что их спасет security through obscurity. Впрочем вряд ли там какой-то код, который можно переиспользовать, там же формошлепство.
Не считая алгоритмов трейдинга (которых там хорошо если доли процента от общего кода), банки меньше всего на свете волнует вопрос переиспользования кода. А вот нюансы организации внутренних сетей, или там проценты за обслуживание захадкоженые для разных кастомеров для разных случаев, или вообще факт наличия каких-то проектов с конкретно взятым кастомером их волнует очень сильно. И по понятным причинам, выдать инструкцию в стиле «не шарить код в котором упоминается контора %name%» — они не могут, могут только запретить шаринг вообще, для всех.
Кроме пары специально для этого сделанных рекламных/обучающих/набирающихкадры проектов.
Каждый предприниматель мечтает изменить мир в какую-то положительную сторону продать свой стартап техногигантам подороже.
Почему мы не наблюдаем вокруг большого количества седоволосых разработчиков ПО?

A «мы» действительно их не наблюдаем? потому что я вполне себе их наблюдаю. Их может быть не так уж и много, но они есть. А немного их по одной простой причине, которая почему-то очень слабо рассмотрена в статье: относительно молодая отрасль.

То есть банально количество программистов постоянно растёт. И 20-30-40-50 лет назад программистов ббыло заметно меньше чем сейчас. Где-то вроде бы даже проскакивала инфа что до последнего времени количество программистов удваивалось каждые пять лет. Сейчас рост замедлился, но не прекратился.

И поэтому сейчас эти программисты естественно «теряются» в массе молодых программистов. Но это не значит что программистов 40+ не берут на работу. Их просто в принципе мало и всё.
Совершенно верно. А в условной Индии, может, 30 лет назад вообще не было программистов, поэтому и нет сейчас там 50-60-летних.
Тем более незнай как щас, а раньше они старались свалить в более развитые страны при первой возможности…
Видел похожую мысль в выступлении Роберта Мартина про удвоение числа программистов каждые 5 лет:
www.youtube.com/watch?v=zHiWqnTWsn4&t=765s.
Откуда следует интересный вывод, что половина программистов в мире имеет опыт менее 5-ти лет, и это соотношение всегда соблюдалось.
Собственно, в статье это упоминается, но как-то очень уж вскользь.
количество разработчиков ПО в возрасте 55-64 года увеличилось в США с 87 000 (8,3%) в 2011 году до 195 000 (10,7%) в 2019 году.

Увеличение на 124% привело к увеличению доли только на 29%.
Поэтому скорее нужно сравнивать количество программистов в возрасте 55-64 в 2019 году с количеством программистов возрастом 47-56 в 2011 году. Чтобы понять, сколько выпало

Всё так. И при этом, даже несмотря на огромный приток молодёжи, средний возраст всё равно увеличивается.
В 2015 по данным SO до 30 лет было 61.8%, а в 2020 — уже всего 52.7%. А среди профессиональных программистов уже в 2019-м каждый второй был старше 30 лет.

Для стандартных бизнес-задач в $ИЗВЕСТНАЯ_КОМПАНИЯ на $ХАЙПОВЫЙ_ЯЗЫК_ПРОГРАММИРОВАНИЯ достаточно и молодых программистов — обучение основам занимает максимум несколько лет, а большего и не требуется.
Молодые готовы работать сверхурочно и полностью увлечены проектами, над которыми они работают — опять же таки, отсутствие обязательств, все дела.
Молодые часто не понимают, когда их обманывают/используют, просто по причине нехватки подобного опыта на собственной шкуре.
Короче, с точки зрения бизнеса, молодой программист — полезный расходный ресурс, которым можно попользоваться и извлечь куда большую выгоду одними и теми же ресурсозатратами чем из старого программиста.
В качестве примера можно посмотреть практики геймдева с их бесконечными кранчами.
Короче, с точки зрения бизнеса, молодой программист — полезный расходный ресурс, которым можно попользоваться и извлечь куда большую выгоду одними и теми же ресурсозатратами чем из старого программиста.

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

Пройдёт ещё лет пять и вы сами первым будете агитировать за повышение бас фактора. Басфактор один это ужас полный. Такого никогда не должно быть.

Человек написал код. Молодец. Вот зарплата, премия возможно. А код принадлежит бизнесу и все доходы с него тоже принадлежат бизнесу.

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

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

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

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

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

Я со стороны разработчика уже приходил на проекты где были куски легаси кода с басфактором 0. Был 1, но его уже нет. Оживить их и втащить назад в разработку это правда сложно. И непонятно зачем, когда можно заранее позаботится чтобы такого не было.

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

С моей точки зрения разработчика басфактор тоже нужно увеличивать (ликвидировать?). Мне для того и платят зарплату, чтобы я привносил хорошие решения, которые будет удобно поддерживать, в том числе и без меня и более дешёвым специалистам.


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

Если вам некомфортно в компании, то определённо стоит уходить. Чем раньше — тем лучше, всем.


В противном случае тебя лет через 10 просто уволят за ненадобностью.

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


А бояться, что через 10 лет уволят — зачем так жить? Если уволят потому что "ты свою задачу выполнил, мы теперь наймём дешёвых специалистов" — ну пожалуйста. Я рад, что моя работа принесла пользу компании. На дворе 2021 год, хороший специалист через неделю будет уже в другой компании повторять свои подвиги, поэтому всего хорошего и спасибо за ЗП.


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

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

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

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

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

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

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

Не удивительно, что молодёжи нормально применять подход тяп-ляп и готово, т.к. понимание отдалённых последствий и технического долга, умение видеть на перспективу и мыслить системно приходит с опытом.

Но не ко всем.

Человек, он ведь по-молодости и самого себя точно так же эксплуатирует, а потом в старости страдает от этого.
как говорил старик Гётте «мудрость приходит не с годами, а со страданиями»

Это был Соломон. Это было выбито на его кольце. Умножающий знание, умножает печаль.

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

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

А считать затраты памяти и процессора очень важно.

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

Недавно интернет-магазин переделывал. Да-да я кроме ассемблера и других крутых инструментов, знаю и такие простые вещи как php и java, jquery и т.п., а так же совсем детские css и html. Обратились ко мне переделать сайт, т.к. тормозит добавление товара в корзину. Делали сайт изначально три студента на последнем курсе. Страницы по минуте открывались, товар в корзину не всегда добавлялся. Крутит колесико, но не добавляет. Полез смотреть, они использовали движок вордпресс и к нему привязали корзину каким-то плагином. Так вот корзина у них хранилась на стороне пользователя в оперативке в виде огромного (больше чем 5 Мб) html файла в который каждый раз добавлялась информация целиком как должна выглядеть страничка корзины, т.е. уже готово для показа на стороне пользователя со скриптами, стилями, фото и т.п… При каждом добавлении нового товара все это редактировалось на java и рос размер страницы очень сильно. Переделал, корзина стала занимать несколько байт и товар добавлялся мгновенно. Делал на php, т.к. лежало это все на стороннем хостинге

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

Но винда-то (ядро) не пишется с помощью «модных библиотек», там вроде как раз С++. Вот, кстати, с Виндой — отличный пример, как очень сложный и большой проект может вести себя непредсказуемо, если использовать небезопасную среду исполнения: одно обновление крашит службу печати, другое — системы на определенной аппаратной платформе, и т.п. И всё это пишется грамотными и опытными разработчиками в течение многих лет.
Вот и получается, что вы на разработчиков интернет-магазинов ругаетесь, которым главное — сделать побыстрее, но почему-то авторы Гугл Хрома или MS Windows, которые как раз разрабатывают, как вам нравится — на С++, со своими собственными либами, с байтолюбством и т.п., но при этом в их софте находятся тысячи ошибок, вас не смущают.
Как обычно, двойные стандарты? «Это вам не это»?
Так винда не сама падает, ей обязательно что-то помогает. А вообще у нас к ВЦ, где я учился была вывеска «чем сложнее софт, тем больше в нем глюков».

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

Когда её «помогают» падать обновления системы, это кто виноват? Веб-разработчики на новых фреймворках? Нет, это опытные и грамотные разработчики MS, пишущие на С++. Когда драйверы принтеров вылетают, вешают службу печати, удаляют задания и т.п., это jvm-разработчики виноваты? Нет, это вина грамотных и опытных системных программистов, пишущих драйверы для принтеров на С++ (как правило).
Всякое бывает, но вы уже просто к словам цепляетесь. Но приложения написанные с фреймворками и библиотекам всегда излишне раздутые, т.к. часто она целиком в программу пишется. Это еще в DOSе было, а сейчас это еще заметнее стало, т.к. библиотеки потяжелели. Глюки часто из-за ошибок их в любой программе допустить можно, но опять же в раздутой эта вероятность выше.
Всякое бывает, но вы уже просто к словам цепляетесь.

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

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

И опять же — где выше вероятность ошибки, в проекте, 90% которого — какой-то большой и сложный фреймворк, написанный большой компанией, протестированный и отлаженный, или в том, где кода в целом меньше, но зато он почти весь самописанный, с бОльшей вероятностью ошибок (как правило), не покрытый тестами, не проверенный на разном железе, и т.п.?
И опять же — где выше вероятность ошибки, в проекте, 90% которого — какой-то большой и сложный фреймворк, написанный большой компанией, протестированный и отлаженный, или в том, где кода в целом меньше, но зато он почти весь самописанный, с бОльшей вероятностью ошибок (как правило), не покрытый тестами, не проверенный на разном железе, и т.п.?


Как по мне — тема отдельного неформального исследования. «большой и сложный фреймворк, написанный большой компанией» запросто может быть заточен под их маркетоложество и точно также не проверенным на разном железе, а только на том, у вендоров которого и этой самой компании хороший такой вась-вась и банька с гольфом.
Делал на php, т.к. лежало это все на стороннем хостинге

А иначе на ассемблере бы это делали?

Неа, это как-то совсем извращение. Хотя можно технически. Можно и воду в решете носить, если извратиться, но зачем, ведь есть ведро. Инструмент подбираю под задачу.
> Почему мы не наблюдаем вокруг большого количества седоволосых разработчиков ПО?

Вообще-то, в Европе — наблюдаем. Мне 44, на позициях сениоров в крупном европейском банке, где у меня был проект, был я, мой ровестник из США и серб 62 лет. Все, включая меня (смею надеяться) — неплохие специалисты.

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

Стресс от того, что могут уволить? — Да нет, не особо, и уж точно не по причине возраста. В IT дефицит рабочих рук, если человек соображает, то всегда рады.

Уход в руководство — ну, может быть да. Но техническое руководство обычно плотно связано с разработкой. Что-то типа «играющий тренер».
В IT дефицит рабочих рук, если человек соображает, то всегда рады.


На чем основана уверенность, что дефицит будет сохраняться и далее, и что мировая экономика не сожмется на долго, прихлопнув кучу бизнесов, а вместе с ними и их ИТ службы?
Разве я говорил что-то про уверенность? Все под богом ходим. Но, глядя на состояние рынка, можно с известной долей вероятности предположить, что сжатие мировой экономики начнётся с сокращени\ зарплат, а голодать начнём ещё не сразу. Ну понижу слегка свой daily rate, неприятно, но переживу.
Ну такой аргумент можно к любой отрасли применить.
В чем уверенность что завтра не изобретут квантовую телепортацию, которая убьет весь транспорт и логистику?

Если нужна строгая надёжность и уверенность — то похоронный бизнес ждёт. Спрос стабилен и даже постоянно растёт, потребность повсеместна, аутсорснуть не то что "в Индию", даже в соседний город не особо выйдет. Изобретения бессмертия пока даже на горизонте не наблюдается, максимум оттягивание наступления потребности в услуге у штучных человеков(из почти восьми миллиардов).


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

В IT дефицит рабочих рук, если человек соображает, то всегда рады.
На чем основана уверенность, что дефицит будет сохраняться и далее, и что мировая экономика не сожмется на долго, прихлопнув кучу бизнесов, а вместе с ними и их ИТ службы?
На словах “человек соображает”. Это понятие меняется со временем.
Если случится кризис, то старички с опытом перейдут на зарплату, которую сейчас платят джуниорам, а джуниоров, косячащих всегда и везде — выставят за дверь.
Так всегда бывает во всех отраслях — почему программирование должно быть исключением?
то старички с опытом перейдут на зарплату, которую сейчас платят джуниорам, а джуниоров, косячащих всегда и везде — выставят за дверь.


Мне как-то чаще приходилось видеть что сперва выставляют старичков, потому как дорогие они. А за джунов невменяемых берутся только когда уже просрали все полимеры. Деньги здесь и сейчас, они поважнее всякой перспективы в кризисы оказываются.
Это две стадии того же процесса. Вменяемые компании, в результате, набирают вменяемых людей, благо они, после этого, готовы на меньшую зарплату, компании “просравшие все полимеры” — в кризис выгоняют джунов просто потому, что закрываются.

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

Даже если они — друзья детсва и вам их тяжело “послать”. Есть разные способы как выкрутится.

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

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

Хотя опыт сильно помогает — раньше те же даташиты приходилось дотошно изучать со словарём, а сейчас сразу знаю, что надо смотреть в таблице, что — на графиках, какие нюансы поискать в тексте, и на какой схеме или аппноте посмотреть требования к конденсаторам питания…

Мне 45 и обучатся наоборот гораздо легче. Потому что все это уже где-то было

Именно, не понимаю с чего вдруг людям после 30, 40, 50, резко становится «сложнее» обучиться чем более молодым? Если человек себя прекрасно чувствует и имеет желание, у него правда может быть куча схожего опыта за плечами и виденье мира в целом уже сформировано лучше, что поможет в обучении, чем у вчерашнего студента. Конечно есть отвлекающие факторы — жена, дети, дом, но кто-то и в 20 женился и уже имеет все это. Складывается ощущение что у некоторых людей альцгеймер или маразм наступает сильно раньше срока.
Один мой друг сказал мне однажды такую фразу «Каждый год я оглядываюсь назад на несколько лет назад, смотрю и анализирую на свои дела и решения. Каждый раз мысль одна — какой дурак я был, ведь можно было сделать лучше».

Опыт - это умение избегать ситуаций, которые не повторятся.

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

Изучать надо то что либо уже нужно/вот-вот-будет-нужно, либо интересно тебе самому и тогда никаких проблем не будет. Изучение «чего-то нового» ради изучения/галочки — ну это такое себе…
Нет, в молодости как раз нужно изучать всё подряд, по венчурной схеме. 9 из 10 направлений окажутся безуспешными, а десятое внезапно выстрелит и будет кормить до пенсии. Только когда уже есть багаж знаний, можно сосредоточиться на рабочем направлении.
Вот-вот, молодежь так код и пишет — лишь бабки быстро сорвать, а нам потом исправлять всю эту лепнину, что бы наконец-то без глюков и тормозов заработало.
Вот только молодой за день на Питоне напишет, отладит и испытает в железе то, что 40-летний на плюсах будет только писать неделю. И если к 40-летнему подкатить с предложением «а попробуй изучить Питон» — ответит, что это чушь, он много жрёт ресурсов и нет полного контроля над приложением, лучше по-старинке, как он привык…
Вот только молодой за день на Питоне напишет, отладит и испытает в железе то, что 40-летний на плюсах будет только писать неделю.
Ага. Только в случае с 40-летним можно будет через две недели отдать изделие на тиражирование, а в с лучае с поделкой на Питоне через месяц только придёт понимание, что надо бы, наконец, нанять нормального специалиста, а то мы в 4K, которые имеются в согласовнной с руководством железке, никак не уложимся.
Современные технологии, на самом деле, заточены не на порождение результата, а не “эффективных менеджеров” и разнообразные KPI.
Пока вопрос эффективности не стоит и любые убытки покрываются печатным станком — вся эта деятельность востребована (так как позволяет набрасывать лапшу на уши “инвесторам”, то есть спекулянтам, которых не волнует как и на чём вы собрались зарабатывать деньги), когда эта вакханалия, так или иначе, остановится — деньги таки начнут считать, а не только KPI.
P.S. А Python нужно применять по назначению: для решения разовых проблем непрограммистами. Такой себе “новый BASIC”. Недаром он сейчас на калькуляторах появился и ему в школах на уроках математики (а не программирования!) учат. Вот там — ему самое место.
Я тоже раньше так думал, пока не увидел, какую магию творит студент, посидев в компьютере с утра до обеда. Теперь с бОльшим уважением отношусь к всяким фреймворкам и интерпретируемым языкам и не воспринимаю их сходу в штыки.

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

И библиотеки питоновские уже давно оттестированы сообществом, в отличие от самописного кода, ошибки в которых не один год будут вылазить. «Через 2 недели на тиражирование» — это только если проект на младшей АТмеге…
Теперь с бОльшим уважением отношусь к всяким фреймворкам и интерпретируемым языкам и не воспринимаю их сходу в штыки.
Всему своё время и место. У нас на Python (и, с недавних пор, на Go) — генераторы кода. Там — этому языку самое место, благо работают оные генераторы на рабочей станции программиста и скорость их работы не критична (хотя на то, что один мой тестик переписали с C++ на Python и теперь он работает не 10 секунд, а 10 минут я до сих пор ворчу).

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

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

иногда дешевле взять процессор постарше, на 600 МГц вместо 500, и памяти побольше, но получить продукт раньше и заняться разработкой следующего продукта.
Вот только Python требует не «600 МГц вместо 500 МГц», а на два порядка больше CPU и на порядок больше памяти. MicroPython/CircutPython столько памяти не требуют, но многие решения из “большого” Python'а там неприменимы.

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

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

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

При этом у нас вполне себе есть клиенты у которых их собственные айти-отделы пишут на «старых-добрых ЯП» вроде С/С++, паскаля, ассемблера, кобола и так далее. И всё равно имеют проблемы с простоями и убытками из-за устранения косяков.
На Коболе еще пишут? Ух ты, совсем бородатые дядьки?
Я где-то здесь уже писал, что инструменты подбираются под задачу, а программист который знает только 1-2 языка и пару фреймворков — начинающий и на серьезные задачи лучше такого не ставить. Пусть участвует под жестким контролем «взрослых».
На Коболе еще пишут? Ух ты, совсем бородатые дядьки?

Ещё как пишут.

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

То есть я правильно понимаю что если кто-то знает только С/С++ и ассемблер и не знает «новомодных языков и фреймворков», то на серьезные задачи такого лучше не ставить? :)
а программист который знает только 1-2 языка и пару фреймворков — начинающий и на серьезные задачи лучше такого не ставить

Как же мне теперь быть-то. Пойду, наверное, верну зарплату за последние сколько-то там лет — зря мне как синиору платили. У меня-то два языка едва наберётся (ну, плюсы, насколько совести хватит сказать, что я их знаю, и хаскель), а фреймворков я вообще никаких не знаю.

Наверное, Boost можно назвать фреймворком в контексте c++

Ну это ИМХО всё же коллекция библиотек. Фреймворк — это скорее какое-нибудь Qt, где оно оказывает довольно сильное влияние на структуру приложения. Использование boost.spirit или boost.fusion или ещё чего на структуру приложения особого влияния не оказывает, это просто, ну, библиотеки.

Если это сайт или интернет-магазин, который через раз будет глючить и тормозить, зато красивый, то да соглашусь. А если это что-то военное, атомная станция или производство, то вы не правы.
Поймите, что программист, который знает только pyton или фреймворки на яве — это как литературная обезьяна, после которой надо или переделывать или это бульварное чтиво, а не шедевр. Это не пойдет в промышленности и военной сфере. Даже в нормальном большом бизнесе не пойдет, только для мелких предпринимателей. Это временные костыли, а не полностью решенная задача.
Но зачем какому-нибудь датчику, например, определяющему по видеокамере уровень заполненности мусором строительного контейнера, надёжность как у атомной станции? Вот скинут вам небольшой заказ на пол-тысячи датчиков с чистой прибылью долларов 5 с каждого датчика, и что вы сделаете — откажетесь от такого заказа, засадите команду программистов на неделю фуллтайм, или поручите Лёше-студенту покопаться в интернете и к вечеру собрать тестовый макет, неделю с помощником у заказчика подбирать коэффициенты в реальных условиях и в продакшн?

Да, я понимаю, что надо делать хорошо и чтобы была гордость за свои изделия, но чтобы заработать — надо делать быстро, балансируя на грани цена/качество из ТЗ. Иначе зарплата программиста с двумя высшими и профильной магистратурой будет на уровне охранника банка с базовым образованием и спецназом в армии…
Было похожее задание. На одном заводе огромная емкость 25 метров высотой и несколько метров в диаметре, в которую засыпается шихта из составного цеха. Там три датчика: снизу (мало) в середине (нормально пока) и верхний (за два метра до крышки). Чехи накосячили (хваленое европейское качество) и софт не всегда нормально датчики воспринимал. Вы не представляете что было, в соседней деревне Сайлент хилл снимать можно было без декораций и компьютерной графики.
Студентов можно и нужно натаскивать на простых задачах. Многие из них это понимают и в большие задачи не лезут без этого опыта. Но есть барыги, а не программисты, которые пришли бабки рубить не имея достаточного опыта. Вот таким барыгам иногда хочется руки вырвать и этими руками по морде надавать.
А то что вы описали вообще легко даже для ребенка. Самое то руку набивать. Подобные простые вещи я своим знакомым начинающим мальчишкам и девчонкам скидываю. Иногда беру в нормальный проект, но под жесткий контроль с условием «делать как я говорю иначе вали за дверь».
Только программист (даже скорее инженер) с опытом подберет нужный язык под задачу и выполнит ее хорошо, а лепить все на одном только питоне и яве с фреймворками — это не про программистов, а про барыг, которые к 40 годам точно вылетят из профессии.
датчику, например, определяющему по видеокамере уровень заполненности мусором строительного контейнера

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

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


Город Нью Йорк, склады порта в районе нижнего Манхэттена. Строились изначально под открытие второго фронта в 1944 году и рассчитывались на 60-90 дней существования. 2010 год, август-месяц… Стоят подновленные там же :) Как Вам такой временный костыль?
Ну и хрущевки с брежневками на 20 лет как временное жилье строились, типа «потом хорошее построим». Это обосновано выделенными средствами и экономическим интересом. Кто-то придумал как еще использовать, после обновления опять же.
Ну и хрущевки с брежневками на 20 лет как временное жилье строились, типа «потом хорошее построим».

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

Это уже устаревший документ. Сейчас, например, оценщики используют совсем другие нормы. Сейчас в оценке Ко-инвест рулит, а если по этим нормам документы, то такой отчет об оценке завернут в миг. Я точно не помню как это было, но по партийной линии в СССР решили, что надо строить и это временное жилье на 20 лет, а потом мы постоем лучшее. Позже все переиграли. Конечно и ежу понятно, что старый кирпич и старый бетон по тем нормам за такой срок, теоретически, не развалится, это сейчас все тяп-ляп, главное быстро кэш срубить. Раньше бетонную плиту после формования и схватывания помещали во влажную среду на 30 дней, а сейчас еще тепленькой уже продают и как результат более быстрое разрушение, нет в них ничего крепкого. Посмотрите на reformagk все новые дома конца 90-х и начало 90-х лет постройки износ аж за 30 процентов бывает переваливает, а старые хрущевки и даже сталинки износ редко до этой цифры доходят.
Это уже устаревший документ.

Разумеется, что это устаревший документ, который опровергает это утверждение: "Ну и хрущевки с брежневками на 20 лет как временное жилье строились, типа «потом хорошее построим»".


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

А причём здесь "сейчас"?

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

Питон против плюсов в этом случае — действительно плохой пример.


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

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

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

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

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


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


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


Были и другие проекты, вроде DSL для всяких трейдерско-торговых вещей, но там ещё сильно меньше можно всякого разного интересного написать.

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

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


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

Знаете, “молодого вас”, не знающего нифига ни про то, как работает процессор, ни про то — какая математика лежит за всеми этим модными языками — я не верю.
А насчёт “пары месяце вместо трёх лет”… я такое видел только, когда удавалось использовать кодогенерацию — а это скорее разница в подходах.
Можно сделать генератор кода на Haskell, а можно — программу на Python, порождающую программу на C++, котоая строит другую программу на C++.
Да, возможно на Haskell будет быстрее, но зато возникнут проблемы с поиском персонала в будущем.
А насчёт “пары месяце вместо трёх лет”… я такое видел только, когда удавалось использовать кодогенерацию — а это скорее разница в подходах.

Это вопрос пригодности и удобства инструментов, от мелочей до крупного.


В мелочах — это вот всё то, что происходит, когда я пишу deriving (Eq, Ord, Show, Generic, Hashable), сколько кода при этом за меня делает компилятор, и сколько времени я экономлю. Если у вас полсотни типов определяет ваш AST, то писать руками функции для дебаговой распечатки, или специализации std::hash и тому подобные вещи вы очень быстро задолбаетесь.


А если вы захотите аналог derive (Functor, Foldable, Traversable), чтобы таскать рядом с каждой AST-нодой какую-то дополнительную информацию (например, её выведенный тип, или данные для статаналаза или оптимизации, или ещё что) и иметь функции, поднимающие функции на этих дополнительных данных до функций на всём AST (просто рекурсивно применяя их к каждой аннотации), или делающие какие-то свёртки по этим дополнительным данным (тоже рекурсивно), то это будет очень больно. Теперь у вас все ваши типы параметризованы дополнительным шаблонным типом


template<typename T>
struct AdditionNode
{
    Expr<T> lhs;
    Expr<T> rhs;
    T extraData;
};

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


Дальше, ладно, настрочили вы типы для AST. Теперь вы хотите сделать их парсер. Что вы делаете в плюсах? Либо берёте внешний генератор вроде всяких яков-бизонов (но там semantic actions прикручиваются очень сбоку), либо берёте boost.spirit, и либо это x2, и время компиляции вырастает ещё в два раза, либо это x3, по которому около нуля документации, и в любом случае поддерживаемость вашего кода устремляется куда-то вниз. К коду на спирите через год мне приближаться не хотелось бы.
Что вы делаете в хаскеле? Вы берёте attoparsec, если надо парсить много и быстро, либо megaparsec, если надо парсить человеческий ввод с хорошими сообщениями об ошибках, просто описываете парсеры без спиритических приседаний нормальным языком и из коробки получаете нормальные сообщения об ошибках:


Хорошо, распарсили, теперь хотите протайпчекать, скажем. Стандартная задача — пройтись по дереву и заменить каждую переменную, упомянутую в типе, на некоторый терм. Что вы делаете в хаскеле?


substPi :: VarName -> Term -> Ty -> Ty
substPi srcName with = transformBi f
  where
    f (TName _ name) | name == srcName = with
    f arg = arg

transformBi :: (a -> a) -> b -> b — это такая библиотечная магия, которая берёт функцию a -> a и применяет её к каждому элементу типа a среди всех (транзитивных) полей типа b.
Что вы делаете в плюсах? Правильно, вы пишете целую функцию отдельно под это дело. Если очень хочется поупарываться — пытаетесь её обобщить, но у вас этого не получится, потому что никакой рефлексии нет.


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


А учитывая, что вы не перепечатываете спеку в компьютер (у вас и спеки-то нет), а экспериментируете, меняете код, меняете структуру AST, рефакторите… Это всё начинает ролять сильно больше чисто из-за психологических причин.

1. Вот про это я и писал. Молодой за день сделает, а потом заказчик пойдет к 40-летнему переделывать.
2. Питон после ассемблера выглядит как легкотня для неокрепших детей и слабаков, которые не могу выучить сначала ассемблер. Нужно знать как железо работает, а потом только инструмент для создания софта под конкретную задачу подбирать.
Если вы работаете на application processor, а не на микроконтроллере, то на уровень железа вас и не пустят — банально нет или обрезанная документация. Ассемблер конечно крут, но на нём уже на уровне Кортекс-М практически невозможно написать программу надёжней И компактней, чем на Си. Знать его важно только для пошаговой отладки.
Так я тут где-то и написал, что инструменты надо сначала учить, а потом выбирать нужный под задачу, а не тупо выучив питон, яву и пару фреймворков бить себя в грудь и называться программистом. Иначе это как лопатой гвозди забивать — можно, но глупо, не надежно и т.п. Нормальному программисту плевать на чем и для чего писать, он много знает и выберет оптимальный инструмент (язык) учитывая все, включая надежность решения, а не лепит что быстрее что бы бабки получить, но это приходит со временем и выполненными проектами. Есть ребята и молодые, но мало, т.к большинство все-таки только бабки на первое место ставят и к 40 годам такие точно из профессии вылетят.
инструменты надо сначала учить…
… не тупо выучив питон, яву и пару фреймворков бить себя в грудь и называться программистом

И чем же именно описанный человек не программист? Инструменов то аж два выучил, да ещё и с фреймворками.

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

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

Понимаете, "jurion programmer" всё равно уже программист. Просто "джун", ну так мы все с уровня ниже этого начинали.
Я, например, даже джуном не был, а уже игру писал(Дворец Пионеров города Ленинграда, компьютерный "кружок", Yamaha MSX-1 и Basic с сохранением на дискетку через учительский IBM PC).


И нет, одни только задачи "сиди смотри" ему пользы дадут немного. Ему надо ещё и выдавать задачи, на которых он сможет расти. С помощью и кодревью. И чтобы отношение имела к деятельности команды/проекта/конторы, то есть втаскивала в рабочий контекст.
Моей первой работой было вообще "вот винда, вот железка-осциллограф в PCI-слот, вот документация. Подружить, снять с неё данные, через месяц нужно.", то есть "кинуть в контролируемую воду, сам выплывет" ибо я в MS-DOS'е писал до того. Результат через месяц взяли, разобрали на составляющие и встроили в общий комплекс. Сам бы я в тут асинхронщину и межпрограммное взаимодействие точно не встроил бы. Так что и так можно.


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

Ну перегнул. Есть такое. Все там были. Сорри и спасибо за поправку.

Черт. Я пишу только на C и на C#. Фреймворков не знаю. Разрабатываем электронику, которая продаётся по всему миру, сидя в Волгограде. Отныне будем шутить в коллективе при случае в духе: «ну, а чего ж вы хотели? Мы ж не программисты!»

Ну вы-то как раз программисты. Вы и без фрейворков знаете как что сделать, что бы работало.
Это что за шарп-одиночка такой без дотнета?(=
Простите, а какой программист «не начинающий»? Тот, который знает больше двух языков программирования? А почему именно двух, может тогда трех? Или тот, который на асемблере пишет?
Программист это тот, кто старается программировать так, что бы потом не пришлось за ним переделывать. А тот, который пришел в профессию только ради денег и перевоспитываться не желает — барыга, который однажды вылетит.
Если человек выходит из учебного заведения после нескольких лет учебы со знанием всего 1-2-3 языков и пары фреймворков, то он даже и не стремился стать программистом. Это не программист, а барыга, т.к. программист и без универа будет программы писать.
Это так в любой профессии. Нужно идти за призванием, а не только за деньгами. Нужно стараться быть лучшим в своей профессии, тогда и деньги будут сами предлагать, за рукав тянуть. А без интереса человек не будет развиваться и даже попав в поток вылетит, как листик упавший в реку выносит на берег.
Программист это тот, кто старается программировать так, что бы потом не пришлось за ним переделывать
Это не всегда правильный подход
а ваша версия? Разве он не должен стараться? Я может где и перегнул, тогда поправьте.
Стараться — должен. И да, в большинстве случаев это означает «делать работу так, чтобы потом не пришлось переделывать». Но, во-первых, это не единственное направление, куда надо стараться, а во-вторых, бывают исключения.
Например, стартап привлек инвестиции, которых хватит на условные полгода нормальной работы и делает продукт. Сделать хороший продукт — за полгода не успеем, продаж не будет, новых инвестиций не будет, на этом история закончится. Сделать плохой продукт — появятся хотя бы в небольшом количестве продажи, можно будет получить новые инвестиции и сделать уже хороший продукт
Ну так я и написал стараться надо в любой профессии.
Так же в своих комментариях я пишу что сейчас все под бабки затачивается, а не под совесть, хотя исключения бывают.
Ну вот а я пишу о том, что есть много случаев, когда затачивать под бабки, а не под совесть — это правильно. И неочевидно, существуют ли обратные случаи
Всякое бывает. Это как на экзамене, все умные студенты делают сначала простые задачи, но большим количеством. Вы, наверное, об этом?
Не уверен, что я понял вашу аналогию про студентов.
Если «затачивать под бабки» и «делать на совесть» совпадают, то и делают так. Если же не совпадают — например, как в примере со стартапом выше: если «делать на совесть», то компания не будет существовать — то лучше «затачивать под бабки»
Кто как делает. Я не компания — я ИП. Меня нанимают обычно для решения проблем после тяп-ляпов, ну и поддержку всего разного после неудачного опыта с тяп-ляпами, бывает сразу нанимают для решения задачи, после неудачного опыта с тяп-ляпами. Я обычно слушаю заказчика и выдвигаю свои доводы, если не сходимся, то я отказываюсь от заказа, т.к. для меня репутация дороже. За заказ не переживаю, т.к. обычно если с заказчиком не сойдемся и он выберет тяп-ляпа, то он потом придет ко мне переделывать. Если приходят переделывать, то обычно готовы предложить больше чем обговаривали изначально.
бывает сразу нанимают для решения задачи, после неудачного опыта с тяп-ляпами
А был ли этот опыт неудачным? Быстро и дешево проверить гипотезу — это тоже важно. Если у вас сто гипотез, из которых одна окажется рабочей, сделать продукт тяп-ляп для проверки стоит Х денег, а сделать хорошо — 10Х денег, то выгоднее будет сделать сто продуктов тяп-ляп, а потом один хорошо, чем сделать все сто хорошо. Это даже не учитывая потерь времени
А у вас в практике разве не было, что бы за кем-то переделывать надо? Ни за кем не разгребали?
Было. И либо оно было следствием ошибок предшественников (или меня самого) — то есть, старались сделать хорошо, но не получилось. Либо, что было чаще, оно было осознанным решением: сначала сделать дешевле, а потом, когда ситуация изменится (появятся инвестиции, будет лучше понимание рынка, еще что-то), сделать лучше и дороже (не только в смысле денег, в смысле разных ресурсов). То есть, тоже старались, но в другом направлении — не «сделать хорошо», а «сделать дешево»
Недавно один заказчик меня просто вывел. Он хотел сделать хорошую задумку плохим способом, я ему объяснил почему это будет плохо и как надо сделать хорошо. Он согласился, а на подписании договора он тормознулся, нанял тяп-ляпов. Заплатил им почти в два раза больше чем я просил. Через два месяца он пришел сам ко мне аж домой в гости. Покаялся и попросил переделать как изначально договаривались. В момент подписания договора опять начались прения. Я психанул послал грубо. Опять названивает и опять просит сделать как договаривались изначально. Вывел до предела. Вот может поэтому я и тут был слишком категоричен, еще не отпустило.
Ну похоже, что он ошибся. Такое бывает, но не слишком часто, потому что за ошибки такие люди платят своими деньгами

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

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

вот в этом, имхо, одна из основных проблем современности.
Девелопер пишет код что б выкинуть, его краем глаза видит манагер — и все, го в продакшн, потом (никогда) техдолг пофиксим надо быстрее…

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

да, про это я забыл как-то. Спасибо.
В целом это всё выглядит правильно, но вы по-моему как-то сильно привязываетесь к количеству языков программирования. Знающий поверхностно 10 языков вовсе не обязательно больший программист, чем знающий все тонкости одного.
Вы правы, спасибо. Но знать после универа 2 языка программирования должно быть стыдно.
А что вы понимаете под «знать»? Я вот помню, что после университета имел опыт написания программ на Бейсике, Фокале, Фортране, ассемблере, С/С++ и Паскале. Но знал ли я их на коммерческом уровне? Не уверен.

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

Ваша задача как программиста создавать, а не продавать.

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

Ну и вы так и не ответили на любопытный вопрос — что вы подразумеваете под понятием «знать ЯП».
А как еще можно понять фразу «знать ЯП» кроме как «знать ЯП»? В нашем с вами случае, наверное, правильно применять. Алгоритмы и математика к языку не сильно привязаны. Языки по-большей части синтаксис, кроме совсем экзотических. Сами знаете, что синтаксис С, java и php имеет общие черты. Ну есть еще деление на компиляторы/интерпретаторы, но это уже вторично. Есть круг каких-то задач, он как-то решается и тут бац — новый язык и эти задачи решает удобнее предыдущих. Например, на C или на asm можно и сайт написать, а можно на php роботом управлять. Но на C и asm роботом управлять лучше, а на php сайт написать быстрее и переписывать под изменившиеся хотелки удобнее.
Я бы не ставил знак равенства между знанием синтаксиса и знанием ЯП. Многие ЯП подразумевают также определенный подход к программированию.

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

Кроме того в разработку с применением некоторых ЯП без знания определенных библиотек и/или фреймворков лучше не соваться.

Плюс IDE, теория тестирования, системы контроля версий, СУБД, infrastructure as code, облачные сервисы… тысячи их.
В общем не только и не столько синтаксис делает программиста программистом.
А я и не писал, что знание синтаксиса делает программиста программистом. В самом начале комментария я писал «правильно применять».

Ну вот ещё раз, у меня в резюме ровно два языка:


  1. C++ — я на нём писал ещё до универа, и его я, наверное, как-то знаю (хотя чем больше я на нём пишу, тем больше понимаю, что знать его невозможно).
  2. Хаскель — ну там проще всё.

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


Почему мне должно быть стыдно?

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

А почему не надо ещё знать, как работает математическая теория, лежащая в основе всего вот этого вот, и не изучить сначала на пару с ассемблером типизированное лямбда-исчисление вплоть до, не знаю, хотя бы зависимых типов?


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

Ну почему же не даст. В свое время переход с графического режима в текстовый и обратно выглядел только так:
mov ax,…
int 10h
И писать в видеопамять как попиксельно, так и целыми банками приходилось похожим же способом, прежде делая все расчеты, а без знания железа это невозможно. Так же делали запись в файлы, чтение файлов, любые операции с файлами и регистрами процессора.
В программировании любой железки важна как математика, но и знание железа. На их основе строятся эффективные алгоритмы, а вот на каком языке они будут реализованы — это уже вторично.
Такие языки как ява и питон, это как бейсик в наше время, т.е. для простых задач и детских проектов. Даже если они могут быть монетизированны.