Комментарии 107
Технологии бегут, просто летят и меняются с огромной скоростью. То, что было актуально вчера — сегодня уже bad practice, завтра — deprecated, послезавтра — история
Тут есть два замечания:
- Это далеко не всегда так. Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?
- Аналогично, есть архитектурные подходы, которые сформировались где-то лет 40 назад и которые только переизобретаются и уточняются. Но ничего кардинально нового не приходит.
Microservices, SOA — из той же серии, правда, не такие уж незаменимые, но модные.
Docker — туда же.
Так что в разработке очень-очень часто все обновляется!
SPA — не так давно внедряются в мир
до этого народ писал десктопный софт, где были те же компоненты в UI (виджеты), те же mvvm и т.д. Ну и как же не вспомнить ужасный extjs, mootols и прочие фреймворки. А еще помните flash/flex?
модные нынче flux это просто ребрендинг smalltalk mvc и т.д. подслащенный отсутствием ограничений по оперативке присущие концу 70-ых.
Microservices, SOA — из той же серии
Микросервисы — это soa good parts. А сколько лет SOA, это ух прям. А до были actor model. И до этого тоже были интересные похожие идеи. Ничего нового. Просто хорошо забытое старое.
Docker — туда же.
LXC появился 9 лет назад. Докер просто сделал это удобным. Ну и до докера тоже как-то инфраструктуру надо было налаживать.
Так что в разработке очень-очень часто все обновляется!
На самом деле не очень. Качество инструментов растет — это да. А вот "координально нового", того что прям ставит под сомнение 10 лет опыта, такого я лично не знаю. У людей проблемы с простыми концепциями которые придумали лет 40 назад и которые никуда не исчезли, все еще best practice и т.д. Большинство просто даже не знают о их существовании (всякие там structured design и подобные раритетные штуки).
Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.
Но вот технологии меняются.
принципы не меняются.
а сейчас уже новые гриды подплывают
мы сейчас говорим о штуках которые изучаются за вечерок. Более того, чем больше опыта — тем проще изучается так как все базируется на более общих идеях.
Но теперь анимацию делают на голом CSS.
Это что-то что надо как-то переосмыслять или чем-то принципиально отличается от анимаций на JS с точки зрения понимания того как работают все эти переходы и как их описать?
если парадигма ООП меняется. Верней понятие этой парадигмы.
А вот тут мне даже интересно, что именно вы имеете ввиду. Начнем с того что есть 2 разных трактовки ООП (а то и больше), одна — просто надстройка над структурным программированием, а вторая — которую никто не понимает (под вдохновением от которой родилась концепция actor model).
Ну и в любом случае, если мы возьмем все популярные "парадигмы" и концепции, идеи там старые. Очень старые. Просто многие из этих идей хоть и были озвучены еще в 60-х, 70-х, в силу ограничений по железу небыли реализуемы.
Технологии, которым удивился коллега, были новыми только для него.
Чуть выше, в другой ветке написали про это:
У людей проблемы с простыми концепциями которые придумали лет 40 назад и которые никуда не исчезли, все еще best practice и т.д. Большинство просто даже не знают о их существовании (всякие там structured design и подобные раритетные штуки).
Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.
И в 2016м году он был искренне удивлен о том, как работают байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM.
А может и к лучшему?
К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси…
А если говорить о неплохих идеях, заложенных в нем (но либо плохо воплощенных, либо так и не воплощенных), так все равно к 2k16 в современном фронте значительно все поменялось — от идей до их реализации.
В том смысле — что если ваш коллега все это проскочил, то и ок, а то бы может там и застрял посильнее, чем в винформах.
P.S. С WPF довелось познакомиться и плотно поработать (с теми самыми "байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM").
К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси
А что сейчас лучше по вашему для Desktop GUI применять?
Что делать, если разработку дестопных UI-технологий забросили в угоду вебу?
Видимо, разрабатывать на том, что есть — на том же WPF или винформах.
Есть еще вариант разрабатывать десктопые приложение с вебовским UI — кажется, клиент Slack так разработан?
Когда то в пору Windows 8 Microsoft вроде так и планировали — чтобы писать декстопные формы на HTML5.
Есть, конечно QtSharp, но это просто обёртка над Qt, позволяющая пользовать его функционал в C# .Net и Mono.
Какая разница над чем обёртка и вообще обёртка или полноценный продукт, если API для использовани из .Net/Mono имеется?
Классический .Net на винде вполне может обходиьтся WPF`ом.
"может обходиться" != "единственный доступный вариант"
К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси…
Десктопные решения, представьте себе, еще дорабатываются и разрабатываются новые. На сколько я понимаю, Xamarin.Forms в принципе опирается на WPF. Разработка под Windows Store, так называемые UWP — тоже.
Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?
Да. Особенно, если вам придётся работать с 10-й версией.
Использовать только старые при современных требованиях? Вы это серьёзно?
Вот пройдитесь по описанию команды CREATE INDEX хотя бы. Настоятельно рекомендую.
И ещё неплохо было бы понимать, что Btree (balanced tree) — это логика. А вот физическая реализация может существенно различаться от версии к версии, что приводит к различиям в планах выполнения запросов и, соответственно, различном времени выполнения этих запросов на разных версиях ПГ. На соответствующих ресурсах неоднократно такие вопросы задаются.
Желание решать проблемы в проде — оно сейчас более востребовано, да. Только вот я предпочитаю не создавать этих проблем бездумным внедрением обновлений, когда обновление может существенно повлиять на работу существующего приложения, и/или разведением зоопарка из дикого количества различных ключ-значение решений, когда нужная функуциональность появляется в используемой СУБД.
А для этого надо не гуглить по несколько раз за день, а внимательно изучать, что появилось/изменилось в новой версии. Вот как-то так. Гуглить — это когда возникла конкретная проблема. Для уточнения конкретной возможности используемого ПО надо пользоваться официальной документацией. Тем более, что у постгреса поиск по документации весьма годный.
А для этого надо не гуглить по несколько раз за день, а внимательно изучать, что появилось/изменилось в новой версии.Надо в какой момент? Нет не надо.
Когда появится необходимость — тогда и изучай, за счет времени оплачиваемого работодателем. (Если нет личного чистого интереса.)
Вот я с PG в проде работал мало. Но в случае надобности работодатель наймет меня и заплатит за мое обучение. (за то что я в рабочее время подтягиваю то что нужно работодателю)
По крайней мере если другие мои скилы подойдут работодателю.
Для уточнения конкретной возможности используемого ПО надо пользоваться официальной документацией.Перед выбором БД и во время эксплуатации.
Любые знания которые не применяются забываются. Так что заранее учить подряд все нюансы нет никакого смысла, разве что ради интереса. Старые знания легко подтянуть до 10й версии. И то, далеко не всё понадобится в проде.
Предмет спора что основные идеи не поменялись с прошлых версий.
Всё это мелочи которые легко и достаточно быстро учатся, особенно если есть опыт с другими БД или есть понимание о чем идет речь.
есть мнение что нужно всё-таки знать немного заранее — иначе трудно проектировать
вот не знаешь, допустим, что в pg10 есть xmltable, а он бы может как раз очень подошел вместо второй СУБД умеющей xml
вы когда вдруг решаете хранить xml в базе данных, даже если вы никогда не использовали постгрес до этого, можете хотя бы поинтересоваться умеет ли он это. Вроде ж не сложно, и ничего не надо сильно заранее штудировать и изучать.
Я вот постгрес использую последние года 4, ждал релиз 10-ки но про xmltable вот не знаю. И не особо переживаю по этому поводу. Как никак, плюшка довольно редко используемая.
С другой стороны незнание о таких вещах может подтолкнуть к более сложным решениям в духе конвертации xml в другую модель данных, хотя по факту хватило бы просто xpath.
Рекомендую изучить (на русском, если что):
https://postgrespro.ru/docs/postgresql/10/release.html
https://postgrespro.ru/docs/postgresql/10/release-10-1.html
Я лучше всё равно не скажу.
В случае ПГ более корректным термином является "доучиваться". Ибо от версии к версии возможности по работе со всякими JSON-ами всё улучшаются и улучшаются. Это для разработчиков приложений. Для эксплуататоров и АБД — перелопачиваются хранилища, что влияет на планы запросов и, соответственно, на производительность.
лучше ответте на простой вопрос. Допустим 10 лет назад человек знал postgresql. Никаких jsonb небыло, другие СУБД по возможностям были примерно там же… Предположим что волею судьбы мы на 10 лет отстранились от psql. А теперь вопрос — мы вообще на 10 лет ушли от баз данных и SQL? Версткой начали заниматься? Ну так тут тогда нет 10-ти лет опыта.
А если мы все же занимались разработкой и так или иначе юзали ораклы, ms sql, мускули и т.д. читали статьи и новости то если через 10 лет мы вдруг решили "а сделаю я проект с postgres 10" — я не думаю что у челвоека уйдет больше недели на то что бы восстановить знания и ознакомиться с новыми плюшками.
Я лучше всё равно не скажуЧто по вашему мнению там ключевого?
а вам нужны всякие брин индексы? Вряд ли зная постгрес 10 лет назад и сейчас вы не сможете почитать вики или в целом были в информационном вакууме и вообще ничего не знали про psql.
radio-t.com/p/2017/12/02/podcast-574
Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?
Нет, переучивать не нужно, нужно учить Монгу, если вы этого еще не сделали!
По поводу актуальности Psql хорошо сказано в подкасте радиота, выпуск 574, начиная с 1:28:00
radio-t.com/p/2017/12/02/podcast-574
Не могу послушать, у этих ребят кривой сайт и не мотается подкаст.
Нет, переучивать не нужно, нужно учить Монгу, если вы этого еще не сделали!
Там кластер уже не разваливается с пол-пинка? В любом случае, каждому делу свой инструмент.
нужно учить Монгу, если вы этого еще не сделали!
мне казалось мода на монгу уже давно канула в лету. jsonb в постгресе покрывает 90% юзкейсов для которых люди брали монгу. Возможность быстро на монге делать шарды и реплики перекрывается отсутствием реальной необходимости у тех же 90% в этом. Да и есть более интересные решения вроде тех же orientdb или arangodb.
То что сегодня надо уметь не только в реляционную модель но и понимать зачем нужны document/column/key value модели, это факт. Но это не обязательно должна быть монга и это никак не говорит что пора выкидывать любимый постгрес.
Я бы не стал инвестировать свое время в монгу (в 13-ом году пол годика побаловались и хватит), да и с точки зрения управления данными есть куча прикольных концептов вроде aws dynamodb в купе с хайповыми нынче serverless решениями.
Но с чем я точно соглашусь, так это с дебильными вакансиями, в которых перечисляют все что нашли в гугле.
Напомнило древний, но по-прежнему актуальный баян.
Вакансия: водитель.
Требования:
Профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны.
Опыт управления болидами “Формулы 1” – приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей.
Опыт проведения кузовных и окрасочных работ – приветствуется.
Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.
Зарплата: определяется по результатам собеседования.
Действительно, самостоятельность — это отличительное качество сеньора. Но принимать решения он должен только в вопросах архитектуры и кода.Так ли это? Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться? Вдруг найдется то решение о котором я не подумал.
Вообще, как в команде можно думать об вопросах архитектуры в одиночку…
Скорее и архитектору неплохо бы обсуждать архитектуру с другими разработчиками, что-бы договорится что это решение сделать достаточно просто и всем понятно как, зачем и почему именно так.
Тут сильно зависит от отношений в команде. Есть команды, где все более-менее значимые решения принимаются коллегиально или в стиле "мы посовещались и я решил", а есть те, куда квалифицированных специалистов берут как раз для того, чтобы они других не отвлекали по каждому чиху.
Разработчик взял и сделал молча как захотел, добавив костыли и новые сторонние библиотеки и завязав проект на парочку типов приложений вроде RabbitMQ и Redis, ведь другие разработчики и архитекторы не для того что бы я их дергал или они меня дергали.
Или наоборот, приходит задача разработчику, разработчик думает об архитектуре, а потом такой «СТОП! У нас же есть архитектор, вот ему таска пусть подумает, а потом скажет мне какая будет архитектура». Не странно ли?
Может я чего то не понимаю. Масса рабочего времени уходит на обсуждение / согласование, как требований так и способов решений, часто бОльшая часть времени.
Какие-то моменты в обсуждениях и согласовании нуждаются по-любому, да. Но уровень необходимых согласований сильно зависит от команды и компании. Скажем, где-то создание нового класса надо согласовывать, а где-то можно в рамках задачи новый "стэндэлон" сервис запилить на одном из десятка языков ни с кем не советуясь.
Снижение эффективности во втором подходе буквально вгоняет меня в депрессию.
Не рекомендую такой подход в геймдеве. Моя старая команда в 6 человек на порядок (именно в десять раз, судя по джире) эффективнее текущей команды в 14 человек по количеству фич в месяц, более того, многие фичи вообще не достижимы в новой команде в разумный срок. Дальше становится только хуже, и я не могу исправить ситуацию.
Более того, чужие решения начинают ломать твои фичи, что превращает линейную разработку в поддержку старых систем.
Вот так страшно жить.
Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться?Более того, обычно в компаниях вообще запрещено коммитить что-либо, не посоветовавшись с остальными разработчиками в виде code review.
Ну, за "открывать в переговорку дверь с ноги" можно многое отдать
По моему опыту, senior разработчик — это просто категория для отдела кадров и бухгалтерии. Никогда не встречал специалиста, называющего себя таким титулом при знакомстве, например.
Ценится не багаж знаний, а умение быстро накапливать нужные навыки.
Знания, как раз, позволяют не только быстро приобретать нужные навыки, но, что важнее — осознанно выбирать, которые из них стоят приобретения.
В нашей профессии мы не накапливаем знания, мы их просто одалживаем на время, заменяя на более современные и полезные.
Я бы уточнил — знания накапливаем (это чтобы одно на другом строить, или, наоборот — держаться подальше), а некоторые навыки (локальные) приобретаем на время.
Ожидал увидеть другие качества senior'a в заметке: "senior developer is expensive, bored and opinionated"
Ведущий разработчик для меня это уже lead. Team lead, tech lead, может lead developer (редкая официальная позиция в целом). От старшего (senior) разработчика отличается прежде всего развитыми, как говорится, soft skills, прежде всего упомянутые как ненужные коммуникабельность, самостоятельность, способность обучать (ну, или, хотя бы способность грамотно и понятно донести свою техническую мысль до менее технически квалифицированных разработчиков, а не просто направлять джунов по принципу "делай так, а то руки оторву твой код моё ревью не пройдёт").
Представьте пишет кто-то вакансию. Допустим, HR. Или даже кто-то реально компетентный. Но проходит мимо большой босс и говорит: «Добавь-ка там Гарвард и Нобелевскую премию. Я такие деньги плачу! Да за них можно пятерых гениев нанять, блин!». Окей. Подбегает маркетолог. Говорит: «Глубокие знания бизнес-процессов обязательны! Нам нужны умные понимающие люди!». Ну окей. Пробегает девочка-бухгалтер: «Ой, а давайте напишем, чтобы был спортивного телосложения...». Уборщица кивает и поддакивает: «Во-во! И чтобы бачок в унитазе починил!». Ну и так далее.
Много хотеть и искать идеал — это нормально. И вопреки стереотипам, тексты вакансий не всегда годятся для оценки рынка. Мы же не журналисты, чтобы по трем цифрам зарплат с доски объявлений Урюпинска «исследовать» медианные заработки в IT «во всем цивилизованнном мире» :)
Поясню на еще одном примере. Если спросить у какой-нибудь подруги, какие качества обязательно должны быть у ее мужчины, почти любая на гора выдаст вам список из нескольких десятков пунктов. Порой взаимоисключающих. Если эти хотелки воспринимать всерьёз, человечество просто перестанет размножаться и вымрет :) А на практике для успешного прохождения чек-листа из ста сложных пунктов порой достаточно легкой самоуверенности и задрипанной ромашки, честно стыренной с ближайшей клумбы. Это позиционные игры, не более.
Работодатель имеет право хотеть чего угодно. Но вы, в свою очередь, не обязаны оправдывать все эти хотелки и быть идеальным. Реальное положение дел определяется только конкуренцией между соискателями. И если на вакансию супермена в течение долгого времени откликнутся только косой, хромой и горбатый, то одному из них вскоре выдадут синюю плюшевую майку и красный плащ. И тот полетит. А если не полетит, то пойдет или похромает. И все смирятся с этим и будут работать с тем, что есть, пока не найдется альтернатива.
Вывод? Не грустите :)
Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал.
Ха, если бы это было так! Для специалистов уровня сеньйоров и выше под «самостоятельностью» подразумевается не только выполнение задачи, а и её формулирование, аргументация её практической пользы для проекта и чуть ли не план повышения продаж продукта и роста прибыли после реализации фичи.
или выпускником, с горящими глазами
Честно, такое читать в реалиях смешно. От всех только и слышишь, что опыта мало.
Ага, теперь ждите следующей остановки — когда будет опыт и знания текущих актуальных технологий, и при этом останутся горящие глаза и желание изучать новые технологии,
то вдруг оказывается, что вот это вот все не особо то и нужно.
В основном все работают с легаси.
Суть в том, что когда нанимают человека, в конечном итоге решает психологическая совместимость, или вообще какие-то отвлеченные факторы.
Если в конкретном случае что-то в фазе Марса не совпало, то тогда и начинается "мало опыта"/"много опыта, но легаси", "не хочешь изучать новое"/"слишком хочешь изучать новое, а нам надо баги пилить".
Ведущие разработчики, они же Senior developers
И сходу самая распространенная ошибка в обсуждениях Titles разработчиков.
Ведущий != Senior, очень даже не равно.
Senior это просто старший опытный разработчик, который все знает, как лучше всего сделать, к чему это приведет, если сделать так-то и так то, как обойти то-то, когда нужен микроскоп, а когда молоток, которые знает не только конкретные технологии, но и общие принципы, etc — за счет знаний и/или опыта.
Который может сам сделать задачу, и его не нужно особой контролировать.
Ведущий (Lead) — на то и ведущий, что он ведет других за собой.
Это может быть или Team Lead — ведущий за собой команду в разрезе процесса разработки, либо Tech Lead — ведущий команду в плане выбора и соблюдения технологий.
Причем, Senior вполне может быть Team Lead'ом (здесь больше нужны организационные навыки), а вот до Teach Lead'а сеньору нужно дорасти одну ступеньки строго по вертикали.
www.quora.com/What-is-the-difference-between-a-principal-developer-and-a-senior-developer
У нас в компании все Principal Developer.
Знание конкретного языка не имеет значения.
Все работают одновременно с C/C++/Java/TSQL/C# в 2-3 фреймворках.
Кто -то в чем-то лучше кто-то меньше.
У каждого свой фронт работ и полная отвественность за результат.
С написанием юнит тестов, функциональных и нагрузочных.
Документациим спецификаций и прочая.
Если что отряд не заметит
Изучение конкретных технологий и узких приемов в конкретном языке инструменте — не выгодно.
Приходится работать с джуниорами, ошибки в технологиях тоже есть, но главная проблема не в этом. Вроде бы всем объясняли про архитектуру, но юноша с горящими глазами забивает бизнес-логику в presentation layer, прогоняет один раз, вроде работает, ура, коммитит. И если это не заметили на ревью (юнош много), то к тому моменту, когда всё развалится, переделывать придётся очень много.
Или, работают с коллекциями, LINQ в .NET, прекрасная вещь, написал строчку и всё готово. Что там под капотом никого не волнует, а там полноценная итерация. Итерация, поверх итерации и ещё условие — O(N^3) как с куста. И всё в порядке с технологиями.
А у сениора когда он такое видит сразу глаза кровью наливаются :-)
"Если у меня будет выбор между уставшим от технологий ветераном или выпускником, с горящими глазами рассуждающим об особенностях новой технологии — я бы предпочел последнего." — должны быть оба, ветеран контролирует новичка, ибо новичок наломает дров и получится как последний запуск с Восточного.
И каждый раз, когда от меня требуют быть дружелюбным или учить джуниоров — мне становится немного грустно.
Быть дружелюбным — это требование применимо к любому сотрутнику, а не только к сеньору. Смысл нанимать того, кто будет третьим в команде из лебедя, рака и щуки?
Уж лучше обучать, чем перепроверять
Может у меня только была такая выборка. Не знаю. Но чаще всего дружелюбные, экстраверты, общительные ребята отлично знают своё дело и очень хорошо шарят в теме и делают реально крутые вещи.
Исходя из своего опыта, я готов несогласится с автором.
10+ лет опыта
Нужно посмотреть, в чем этот самый опыт заключается. Не исключено, что опыта решения именно специфичных для вашей конторы задач у чела может и не оказаться.
Самостоятельный
Бывал в ситуации, когда разработчик решал не ту задачу, которую перед ним ставили. Например: требовалось написать примитивный скрипт на php, который автоматизирует мелкий процесс в жизни заказчика, и этот скрипт следующие лет 5 точно не поменяется, а вместо этого получил полуготовую CMS с ворохом ненужного кода.
Незаменим
Отделимость проекта от его создателя — это прежде всего в интересах работодателя. Как минимум должны быть критерии достаточности документирования: коментарии в коде, переписка в задаче, wiki, что — то еще, и хотя бы формальный надзор за их исполнением.
Коммуникабельный
Коммуникабельность, как способность внятно излагать свои мысли и готовность учитывать, что твой собеседник не всегда программист, это да.
Способность не быть угрюмым молчуном и поддерживать нормальную беседу с коллегами, тоже да.
Корпоративный дух и общие мероприятия, официальные, вроде нового года и других праздников, и неофициальные, вроде выхода на природу или похода в сауну, это, скорее нет, чем да. Общение через нехочу — это точно не мое.
А если не смерился и пытается хотя бы локально улучшить "все плохо"?
Совершенный код, Макконнелл 33.2
Не путайте принятие и смирение. Я могу принять что мир несовершенен, что все плохо, но это ни коем образом не обязывает меня с этим мириться. Я просто могу это учитывать, но продолжать экспериментировать с целью хоть что-то улучшить.
p.s. цитату вы привели тоже не к месту. Про уровень интеллекта никто вообще не говорил. А так выходит что синьер это застой и тупость (я утрирую конечно).
Отриньте гордыню и поймите уже вы не совершены, ваши мысли не совершены, а ваш код… Апеллируйте уже не философским понятиями, а математическим.
Но ничто не мешает стараться стать самому более совершенным, писать более совершенный код и, даже, делать код написанный другими более совершенным.
более совершенный = более эффективный, понятный, гибкий, менее подверженный рискам или с более предсказуемыми рисками. Эдакий компромис между всеми составляющими которые в конечном итога можно пересчитать как профит для бизнеса (он должен быть, иначе нет смысла).
И да, речь не только о коде, а скорее о том как в целом вы за задачи беретесь, как происходит сбор и анализ требований, весь пайплайн от "хочу" до продакшена можно улучшать. Все же разработка это в меньшей степени код. А если мы только на коде будем зацикливаться — тогда будет как у всех — нет времени что-то улучшать.
Мелкие совершенствования кода типа минимального использования невнятных сокращений или выделений кусков кода в отдельные методы/функции с говорящими именами, даже если повторного использования нет и не предвидится, практически не влияют на затраченное на начальную разработку время, с одной стороны, а, с другой, должны сокращать время на доработки/исправления/развитие. То есть в целом, стремление писать более соврешенный код не противоречит интересам работодателя, если не ставить себе самоцелью писать совершенный код.
Если бы мне предложили срочно делать проект на Хаскеле или на React (которых я не знаю), глаза у меня горели бы не меньше, чем в 25. Проблема в том, что кроме того, постоянно приходится изучать вроде-бы новые технологии, в которых 90% по сути старое, но другое.
У меня в голове полно места для новых идей, но совсем нет места для простых навыков, которые у меня уже есть и которые нужно заместить новыми. Лет до 40 это не было для меня проблемой.
10+ лет опыта
То есть, вы бы предпочли одноразового разработчика, у которого постоянно горят глаза.
Ибо через год появится новый Vue и этот разработчик забудет о старом и будет изучать новое, ему будет не до вашего проекта.
Зато глаза горят.
Самостоятельный
Всё зависит от написанного ТЗ.
Если его нет и работа ведётся гибким методом (смотрим коммуникабельность), то да — разработчики на работе только и делают, что разговаривают, а не работают.
Если есть четкое ТЗ, которое написал профессиональный менеджер, то от профессионального разработчика максимум возникают минимальные уточнения по нему, ибо 10 лет опыта — это именно опыт, который позволяет разработчику даже угадывать то, что хотел сказать клиент.
Обучает начинающих
Здесь всё правильно написано. Дорогу одолеет идущий.
Незаменим
Всё так. На последнем месте работы мне «повезло» встретить такого гения. На проекте нет документации, гения боготворят, все решения идут через него. Аж противно.
Коммуникабельный
Не вижу проблем в шашлыке и общении на природе, если это происходит в оплачиваемый раб-день чисто в рабочие часы.
5 мифов о ведущих разработчиках, от которых мне становится грустно