Чому у нас не розповсдюджена практика найму розробників-генералістів та коли це зміниться?

Я писав в основному на Java але останнім часом частково пересів і на інші мови та платформи.

У світлі недавніх подій (описаних в треді «Як проводити співбесіди з сеньйорами», а саме моїх спроб невдалих влаштуватися Ruby або Python розробником) в мене виникла наступна думка:
На заході у компаніі FAANG (та і не тільки) дуже часто не шукають розробника на якусь конкретну технологію/мову а шукають просто хорошого розробника. Часто в компаніях різні шматки пишуть на різних мовах, та найбільш зручних інструментах і компаніям просто невигідно тримати, наприклад, тільки спеціалистів по Python для підтримки купки деплоймент скрптів ті одного фласк-аппу. Тому на інтерв’ю там дають завдання які можна реалізовувати на будь-чому ну а фактична робота може торкатися дуже великої кількості різних технологій. Про це ж говорять численні свідки роботи в цих компаніях—а саме, вам доведеться працювати з великим зоопарком технологій і нікого не цікавить чи ви знаєете Python aбо Java чи ні.

Натомість, у нас картина зворотня—всі шукають Spring 2.5 Hibernate 1.3 developer with IBM WebSphere experience.
Причина цього всім очевидна—аутсорс, замовник не хоче платити гроші за навчання спеціаліста а хоче прийти відразу на готове. Залишимо з боку думки щодо того що той самий замовник банально втрачає гроші на очікуванні найму кандидата і перейдемо до питання:

—ваші думки стосовно того чи добре бути генералістом, чи краще бути специалістом?
—доколє? доколє наші розробники будуть вважати себе вузькими спеціалістами та продовжувати сидіти в зоні комфорту?
—доколє? доколє компанії будуть наймати таких спеціалістів замість того щоб брати просто хороших інженерів здатних впоратися з новим стеком за короткий час?
—яка ситуація у вашій компанії? можливо, ви вже такий генераліст, розкажіть іншим про ваш досвід

Мої думки наступні
—чим далі тим більше буде зростати кількість інструментів та платформ.
—чим далі тим дільше буде зростати попит на інженерів-генералістів з широким досвідом роботи з багатьма інструментами
—просто зараз вже потрібно інвестувати в себе та вивчати додатково як мінімум +1 допоміжну мову (крім JavaScript який ви швидш за все і так з горем навпіл знаєте)

діскасс

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Я думаю ответ очевиден: универсальными девелоперы станут тогда, когда станут универсальными языки и библиотеки и сервера! Что бы зная стандарты, инженер мог одинаково свободно использовать разные технологии, не углубляясь в нюансы и тонкости.
На текущий момент я такого не вижу. Скорее наоборот: даже технологии, которым много лет, имеют массу «подводных камней», нюансов и «ложных путей». Да — ими можно пользоваться прочитав книжку и посмотрев примеры. Но как только объем проекта станет достаточно большим — скорее всего пролезут проблемы с перфомансом, с секьюрити, с утечками ресурсов, с несовместимостью. Потому что специалист во всем — это специалист ни в чем!
Я работал на огромных проектах и поэтому хорошо понимаю цену этим «нюансам». Например: SQL Server — на многих проектах все упирается в перфоманс базы. А в SQL даже порядок строк или не тот оператор могут увеличить время запроса в разы! Поэтому на больших проектах базу не пишут «генералисты», а опытные DBA, которые знают каждый нюанс внутреннего устройства SQL Server.
C С# и .Net то же не все просто. Без глубокого понимания как работают лямбды, асинхронность, очистка мусора и т.д. можно элементарно наступить на грабли в веб-приложении. До сих пор вспоминаю известную ловушку ASP.Net — если вызвать Wait у асинхронного метода — то получается дедлок на пустом месте. В .Net Core это починили — но не зная таких деталей можно легко завесить сайт с миллионом пользователей.
Про JavaScript и писать не хочу. Просто потому, что прекрасно понимаю насколько в нем больше нюансов и «граблей». И если в C# я могу считать себя специалистом, то написать большое приложение на JavaScript я бы не сел без серьезной подготовки. Хотя и считаюсь «фулстек».
Может ли синьор девелопер быть «генералистом»? — теоретически да. Я могу написать и на С++ и на Java и даже немного на Prolog (в институте изучали). Но будет ли такой код уровня синьора? Очевидно что — нет. Он будет уровня джуна!
Если хорошо подготовиться за несколько месяцев самообучения — я смогу выдать код на уровне мидла. Но все равно без нескольких лет «хождения по граблям» и набивания шишек в конкретной технологии — код на уровне синьора не написать.

Я недавно как раз думал на эту тему, что если пришел бы момент когда захотел бы вернуться в Украину, то, как Generalist, навряд бы прошел собеседования в местные «лидеры рынка», хотя проходил во многие FAANG и топ pre-IPO компаний. Почитал комменты и убедился в этом.

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

Моя теория, что одна из основных проблем это образование и менталитет.

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

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

В таком формате собеседований очень тяжело пройти собеседования как Generalist SWE, вот люди и позиционируют себя как «Python developer», «Java architect», «Drupal Engineer» и тд. Те кто способны решать проблемы на любом языке даже не пытаются подаваться туда где требуют другой язык.

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

— Бэрримор, что это за вой на болоте?
— Генералист, сэр
— Отчего он так вопит?
— Фреймворки, сэр

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если задачи детсадовские — зачем привлекать гуру, да за хороший рейт?

Натомість, у нас картина зворотня—всі шукають Spring 2.5 Hibernate 1.3 developer with IBM WebSphere experience.
Причина цього всім очевидна—аутсорс

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

— Бэрримор, что это за вой на болоте?
— Генералист, сэр
— Отчего он так вопит?
— Фреймворки, сэр

То архітектор называеться

Нет, это principal principal solution architect

Я бы провел параллель с консалтингом в Европе. Консультант — это всегда временный человек. Нет времени обучать консультанта если вы ему платить 100 евро в час. И нет смысла вкладывать в его обучения если контракт на 6 месяцев. Нужно чтобы консультант отлично знал технологию и нанимают консультанта всегда на решение конкретной проблемы, а не просто так «про запас». Поэтому даже в Европе требования к консультантам типа «MySQL 5.6, Java 8, Hibernate, Angular 1».

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

Я это уже писал много раз на форуме — в Швеции в большинстве компаний нет никаких DBA, QA, DevOps и прочей фигни. Есть Software Engineer — бывают фронтенд, бекенд и фулстек. Это и есть те самые генералисты

Насчёт консультантов — это далеко не всегда так. То что вы описали — это нехватка манки кодера которого нанимают как контрактора

Customer: I need a baby
Junior dev: With one pregnant woman we can deliver it in 2 years
Senior dev: Make it 4 years
Project manager: Can’t we just hire 9 pregnant women and deliver the baby tomorrow?
Consultant: My opinion is that your baby is ugly as hell, here’s my bill

це так жартують в нідерландах

На прошлой работе наняли коллегу — он писал сишарп код первый раз в жизни когда делал тестовое задание. Сам он джавист. Когда наняли — оказался одним из лучших инженеров с которыми я работал в своей жизни. Без проблем писал код на .net core еще и научил нас как все это крутить на линуксе и докере. Дело было в Швеции. Так что я верю в «генералистов». Единственное я не верю в термин fullstack developer — я считаю что бекенд и фронтенд далеко друг от друга ушли, так же как и Data Science/ML

клево наверное делать выводы опираясь на единственный случай, еще и оценив субъективно :)

Ну почему единственный случай — Амазоны и Гуглы там всякие нанимают генералистов и всем довольны. Это только в аутсорсе все по другому.

что это такие за аргументы?) везде все всем довольны

Опустил ты сейчас Швецию, в плане разработчиков..

Тут палка о двух концах. Наши галеры однозначно берут на проект и под проект. И им возможно класть на вас как актив, на ваше развитие и тд. Главное что бы вы сейчас приносили им деньги. Проект закончится — вас могут уволить а на новый проект нанять опять же готовенького. С другой стороны — галеры имеют свой гемор в связи с этим — разработчик так же может по 3-5 галер в год менять тупо из за +200 (ибо другой причины обычно работать в галере часто просто нет). В этом плане продуктовые компании часто лучше — вы там как актив, они заинтересованы в вашем развитии, в том, что бы вы проработали у них всю жизнь. И вы там действительно будете пробовать различные технологии и тд. И если надо — завтра вас посадят переписывать скрипты с вашего любимого питона на го.

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

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

вопрос именно о территориальном нахождении, а не места работы, именно это все и определяет

нет, просто хотел ответить почему вы можете себе позволить

Не люблю поклоніння і повинування

ну и прочие комментарии в этой «ветке» темы.
То что происходит в IT в Украине — это *больше экономическое исключение из правил экономики*. (говорю очевидные вещи, да). И мы пользуемся тем, что живем в нищей стране, работая на иностранные рынки (и еще пользуемся неадекватно смешными налогами для айтишников). Нынешнее состояние мировой экономики довольно сложное, и людям приходится работать, чтоб выживать. И у большинства просто не возможности психануть и уволится, не работать месяц, пока заняты поиском новой привлекательной работы. Это чисто у нас лайфхак IT в стране. Поэтому мы немножко прифигевшие такие ребята, можем перебирать конторами, взять себе неоплачиваемый отпуск на месяц и тд. Потому что месячной зп может хватить и на 2-3 месяца протянуть, не голодая всей семьей. Почти все мои знакомые, которые не в IT, вынуждены терпеть хамство начальников, и сложные условия труда, и нарушения законодательства со стороны руководства в конце концов. И будут терпеть — ибо не могут себе позволить уволится (за спиной оплата аренды, жены, дети и тд). И так же в Европе/США сколько жалоб на дискриминацию, на домогательства и тд — но все терпят, потому что жизнь в мире нынче такая, нужно пахать, и нельзя расслабляться. Сложилась бы у вас иная ситуация, были бы вы не в IT в Украине (жили бы в другой стране, или были бы не айтишником) — не бросались бы такими словами :) работали бы, периодически митинговали от профсоюза, но мыслей о спокойной смены работы в любое время у вас бы вообще не возникало :)
Еще примерчик — сейчас выполняем работы для одного крупнейшего европейского завода, так вот постепенно переносят все свои мощности в экономически не богатую европейскую скромную страну, потому что а) дешевле раб. сила, б) определенные страны слишком много бастуют, и их это достало. теперь это бастующие ребята потеряли просто напросто свои рабочие места в этом направлении, до выделывались.

Треба себе поважати, от і все. А не трястися над робочим місцем.

Опять же, говорите с позиции айтишника в Украине :) В остальном мире совсем другая ситуация, даже в айти. Это как быть владельцев завода и говорить «че вы вот на заводе работаете, как рабы, надо уважать себя и быть директором завода» :). Не все могут, а статистика она такая — обобщенная

мають високі умови праці і зарплатню.

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

Тому мають високі умови праці і зарплатню

Тi, хто мають.

(за спиной оплата аренды, жены, дети и тд)

А якщо не заводити дітей, дружину — також працювати, і не брати ніяких кредитів на айфони?

Ну сколько по (всей!) Украине фактически средняя зп? 10к где то? аренда и коммуналка (особенно зимой) съест 60-80% зарплаты. Продолжать не буду

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

С Киева отъедьте километров на 100, и о никаких средних 15к и речи не идет. Я родом с города Северодонецк, нынче областной центр Луганской области. Пойду порадую жителей, пусть узнают что у них там средн. зп у специалистов от 15к, а то бедные не знают, как за отопление заплатить. У нас в городе копы=мажорами считаются со своей ставкой 10+. И едут все с при великой радостью в Киев за 10к+ грн батрачить почему то...

Тому що немає технологічних компаній. Думаю це основна причина. Схема бізнесу диктує умови найму.

Генераліст, спеціаліст... — головне щоб програміст був хороший. Але, щоб бути дійсно хорошим генералістом — треба голова. Поганого «генераліста» видно майже зразу. В той же час, та ж сама людина може визубрити якийсь фреймворк, та так що розумні слова від зубів відскакують, а код на типових задачах — краса. Але в той же час — ніфіга той «спеціаліст» не розуміє як його код працює, для чого, чому так ітп. Нетипова задача — довго й погано.

Там, в першу чергу, дивлятся як людина думає (і чи думає взагалі). У нас — на те як просто буде втюхати цього чувака клієнту, і щоб він був не повне дно. Там є люди які розуміють твій код, і можуть зрозуміти, що краще два правильних рядка в день, аніж тисяча гарного, але непротрібного коду. Наш аутсорс — це втюхати чувака, який классно імітує роботу = купа гарного і непотрібного коду, мітинги і інші гарні слова. Клієнт на аутсорсі зазвичай не зовсім розуміє якість коду і роботи взагалі, йому треба дешево, й не повне дно. Від цього танцює все українське ІТ, і в результаті напрямок розвитку — не розуміти, що ти пишеш і чому, — а те як твій код і твоя робота виглядає на мітингах перед людьми, які нічого не розуміють. Там хочуть платити багато, бо гроші є і вони знають як іх правильно витратити. У нас — всі шукають середину між «найняв дешево — продав дорого», і саме це є основний мотиватор найму, а не якість роботи роботи кандидата. Най ви будете якнайкраще підходити під клієнта — наймуть того, хто принесе більші прибутки.

Це не у нас і у них, це аутсорс і продукт.

Клієнт на аутсорсі зазвичай не зовсім розуміє якість коду і роботи взагалі, йому треба дешево, й не повне дно. Від цього танцює все українське ІТ, і в результаті напрямок розвитку — не розуміти, що ти пишеш і чому, — а те як твій код і твоя робота виглядає на мітингах перед людьми, які нічого не розуміють.

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

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

Я недавно как раз думал на эту тему, что если пришел бы момент когда захотел бы вернуться в Украину, то, как Generalist, навряд бы прошел собеседования в местные «лидеры рынка», хотя проходил во многие FAANG и топ pre-IPO компаний. Почитал комменты и убедился в этом.

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

Моя теория, что одна из основных проблем это образование и менталитет.

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

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

В таком формате собеседований очень тяжело пройти собеседования как Generalist SWE, вот люди и позиционируют себя как «Python developer», «Java architect», «Drupal Engineer» и тд. Те кто способны решать проблемы на любом языке даже не пытаются подаваться туда где требуют другой язык.

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

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

Люто х2. Рідко побачиш девелопера який нормально вміє терміналом користуватися і баш знає мінімально.

только ребут, только хардкор

Є nano, який і простіше і сильніше. vim зараз , як на мене — чисто сисадмінська забавка, хоча він й справді могутній.

Є nano, який і простіше і сильніше.

Всегда его сносил и ставил взамен joe. Этот хоть в базе удобен.

8-)
Валентин, ну у каждого свой вкус.

А з vim вийти? Я вмію

А макро быстро записать?

sudo journalctl | grep -ой чого в мене жопа- | less — складно ?
Я теж багато чого гуглю. Просто треба знати ЩО шукати і ЯК застосувати.

Утиліти в лінуксі придумані не для людей а для червонооких задротів.

Ви здивуєтеся, мабуть, але командна лінійка складна у всіх сутностях — у ОС комп’ютерів, активного обладнання, SAN-накопичувачів, UPS, ба, навіть у мережевого принтера — але це насправді найдієвіший і найдешевший спосіб побудувати інтерфейс між інженером та машиною.

мінімум витрат на ресурси,задіяні на інтерфейс й мінімум витрат на програмування. Де-факто — безкінечний while True з очікуванням вводу.

SAN-пристроїв, так піде ?
Втім у NAS теж є command line

важко вивчити прості консольні команди

так это не админство совсем

Ну так это, скорее, уже к знанию конкретной операционки и её потрохов.
Так-то на уровне обезьяны и я умею в dmesg | tail или в lsmod | grep.

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

налаштований iTerm2 + oh my zsh і шорткати для часто використовуємих команд, мінімальне розуміння шо таке ls шо таке tail шо таке cat/bat шо таке head і шо таке grep і як можна пайпи будувати
вміння курлити з консолі
адвансед левел — jq + крул для тестів рест арі

Хм, а що таке

iTerm2

я все життя putty бігаю 8-)
Ща піду дивитися
Побачив.
Я мак бачив тільки один раз вжитті — в 1997 році у видавництві місцевому. Вразила миша з однією кнопкою і сідюк без кнопки.

курл с жкй — это децкий сад. Да и к тому же если что надо — гуглиться.

налаштований iTerm2

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

От ти здря про vim. Я поки що бачив лише адмінів,що його люблять, для розробників — це щось страшне.

Згоден !
А що я ще казав ,що брехня ?

У меня основной vim, уже лет 15.
В IDE заглядываю ради сложных рефакторингов и т.п. :)

Валентин, про настоящих титанов я молчу 8-)))

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

Хм, як на мене, то для пайтоніста баш має бути другою мовою. Або для тих хто на перлі пише .

Ну це вже кому що подобається. Мені С не подобається взагалі.

Це якийсь маразм, коли навколо айдішки.

Нічого не зрозумів, хоча зараз 99% в vim і >90% пітон :)
Що таке «коли навколо айдішки», на якій мові?

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

абсолютно нет, но это и не

Брехня. Базові адмінські здібності є у кожного норм дева.

Оксано, ти унікум. От чесно. Жінок-адмінів майже не буває.

хочу сказать — многие товарищи даже логи грепнуть в json не всегда умеют.

А принципалы в гуглоамазонах, что 650к имеют — могут жсон грепнуть? Или это оут оф скоуп для них ?

Базові адмінські здібності є у кожного норм дева.

Нет. Возможно, это так в вашем окружении, но не везде. Интереса ради, порасспрашивайте разработчиков о том, как работает NAT — очень удивитесь.

Так у «норм девов» написано

Ой, ЛОЛ. У нас пару років тмоу спецаліст з 10 річним досвідом на С++ перевіряв чи проходять HTTP запити на сервер викликаючи команду ping. Але в С++ він спеціаліст, да.

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

Мені теж не ок. Якщо брати суто плюси, то він їх знав можливо навіть найкраще в департаменті. У нас, наприклад, колись була проблема (не пам’ятаю що саме точно, але щось суто нюанси плюсів з коструктрами копій і управлінням пам’ятью в 10 річному legacy code який нам дістався), яку два інших сеньйори бралися але не вирішили, а він вирішив. Але такі задачі траплялись вкрай рідко, максимум 1-2 рази на рік, коли треба було щось дісйно знати по хардкору. Більшість задач — просто general problem solving, і там у нього було не все ок. З ними мідли розправлялись швидше.

Ні. Код в якому була помилка був 2nd party (форк бібліотеки яку розробляла та ж компанія), але жоден з нашої команди в його розробці участі не приймав. Один з сеньорів що не вирішив проблему на проекті був стільки ж, а в компанії на більше.

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

знання мережевих стеків і протоколів — це вже не базова комп’ютерна грамотність...

приплюснутим, напр. тре знати, що крім мережевого стека є ще мережевий хіп, і що на ньому тре виділяти мережеві об"єкти оператором new, і щоб інетернет не дійшов до out of memory тре вчасно викликати delele

є ще мережевий хіп

ты путаешь мэрэжевый хип с хипом интернета.

а є ще хоп .
-----------------------------
зроби мені хіп
зроби мені хоп
опусти інтерфейс
зміни на ньому некст хоп
йоу !

еще есть хайп

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

устройство сети врядли входит в базовую компьютерную грамотность

Більшість розробників працює на 5-7 рівнях моделі і їм та мережа й нахрін не впала.

Якщо не мережі то що?

адресная арифметика?
не забывать free()/delete после malloc()/new ?

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

мы изначально про плюсы говорили, мол если чел знает с++, то обязан знать все. с чем я не согласен — тут не от языка зависит а от уровня сеньорности скорее

Я маю на увазі тим хто пише на JS, Java, Python, Go (з натяжкою), Ruby, C#, etc.
Взагалі, пару циклів і наслідування за 21 день вивчив і агла.

с этими так и происходит

вручную рав-сокеты не крутил — не мужик

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

как это связано со знанием с++ в контексте знания модели OSI?

потому что с++ в вакууме возможен только в преподавании

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

оси модель входит в базовые компьютерные знания

А с чего ей не входить?

если туда входит нетворкинг, то да. а так — нет

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

Тогда уже пиши 19 летний джанго-архитектор, а то как-то не полная картина.

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

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

Во вторых зачем на джава позици. человек который джавы не знает, если не проблема найти человека который знает ?

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

У меня были очень положительные интервью в Украине, но к сожалению многие из них были «Как во фреймворке X сделать Y?», вместо более подходящего, с моей стороны, «Если есть проблема X то как бы Вы ее решили?»

Сори, я не понимаю что такое «джава позиция». Могли бы привести пример проблемы для конкретной «джава позиции» с которой например человек с C# опытом не справился бы? Я могу понять когда нужен человек с опытом компиляторов, чтобы писать компилятор с нуля, человек с опытом разработки игр чтобы создать игру, но человек с «опытом джава» чтобы «решать джава» я не понимаю.

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

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

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

маленьким компаниям и стартапам интереснее люди с конкретным стеком

ИБМ, Варайзон, Банк оф америка, и сотни других — стартапы ?

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

Насчет IBM и Verizon я не знаю. Хотя тоже выглядят как особый случай.

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

Большинство этих особых случаев — таки маленькие компании. Сопоставимых с Гуглом мало (в играх вообще есть ли такие?)

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

Сори, я не понимаю что такое «джава позиция». Могли бы привести пример проблемы для конкретной «джава позиции» с которой например человек с C# опытом не справился бы?

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

с# синьер решит проблему, на уровне java мидла

Вот Вам действительно не кажется что это как минимум звучит абсурдно?

Но вернемся к конкретике, привидите пример проблемы? Желательно пример проблемы с которой столкнулись конкретно Вы.

Вот Вам действительно не кажется что это как минимум звучит абсурдно?

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

Могли бы привести пример проблемы для конкретной «джава позиции» с которой например человек с C# опытом не справился бы?

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

аутсорсеры не захотят оплачивать 3 месяца переходного периода

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

Вот когда билд вне любимой IDE внушает суеверный ужас, тогда да.

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

Языаи одного поля аля досишарпа против джавы, или не одного вроде джавы и с++ ?

Если чел никогда с поинтерами и паматью не работал — как быстро он переключиться ?

Особенно, если рядом есть кого спросить и если надо писать не с нуля, а в духе существующего кода.

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

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

В Java куча своих приколов с настройкой application server, правильной конфигурацией того же Spring, это уже не говоря об отличиях в работе сборщика мусора и ещё кучи вещей.

Grez совершенно правильно выше ответил — проблема не в языке как таковом, проблема в знании платформы (именно в случае Java ИМХО требуется слишком много «сакральных знаний», чтобы работать эффективно)

В Java куча своих приколов с настройкой application server

1. В Java Enerprise.
2. Сколько раз в течении проекта это понадобиться?
3. Является ли это знанием чем-то эзотерическим или в полном объеме гуглится за три дня?

уже не говоря об отличиях в работе сборщика мусора

Ну не будет этот код идеально оптимальным, ну и что? Для Java по-моему смешно об этом говорить.

проблема не в языке как таковом, проблема в знании платформы (именно в случае Java ИМХО требуется слишком много «сакральных знаний», чтобы работать эффективно)

То что половина украинских «сеньоров» не сбилдит код без IDE — известный факт. Но мне казалось, что мы о нормальных инженерах говорим.

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

И вообще Spring это уже устаревшая технология =) Молодежь давно перешла на котлины, ноды и скалы всякие

Сначала надо определить критерии «справился».

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

охх, вот если бы меня волновало, в бытность мою собеседующим, как обо мне будут отзываться собеседуемые..

Согласна! Только я думаю, что здесь дело не в образовании и менталитете, а особенностях рынка. Аутсорс все-таки. Все творческое делается в Америке.

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

Ну так с волками жить — по-волчьи выть. Такой контекст... Основатели украинских продуктовых компаний ведь когда-то работали в аутсорсе. Я бы так объяснила

Разница в том, что у них ищут специалиста «в компанию», а у нас «на проект». Т.е. им важно найти инженера, который умеет думать, решать задачи, может даже изобретать новый подходы. Тут даже предпочтительнее какой-то молодой выпускник технического ВУЗа с хорошим знанием алгоритмов, но без глубокого опыта в Ангуляре, чем узкопрофильный специалист с 10 летним опытом в одном языке. Потому что человека берут в компанию с прицелом на годы и несколько месяцев что бы вникнуть или подучить — это не проблема.
В Украине глупо планировать на годы вперед — тут все меняется каждый день. Поэтому людей берут на проекты, которые уже идут или только стартовали но уже обещаны «на вчера». Даже если найдут гениальное молодое дарование — никто не будет ждать несколько месяцев, пока человек подучит язык и фремвоки. Ищут того, кто сможет сесть и работать прямо сразу.
«Генералисты» в украинском ИТ то же есть — это архитекты или даже СТО. Т.е. сотрудники, которые не педалят на конкретном проекте, а принимают «стратегические» решения. Для такого поверхностные знания достоинств и недостатков многих технологии нужнее, чем глубокие знания в одной. Но такой «генерал» нужен 1 на армию специалистов — солдат!
По опыту работы в аутстафе американских топ ИТ компаний я заметил интересную особенность: у нас менеджеры проектов — это часто гуманитарии (девочки с иньяза). А вот у них менеджеры проекта — часто как раз те самые «генералисты». Т.е. это инженеры, которые не пишут код сами, но имеют достаточные знания в разных языках что бы понимать что пишут их подчиненные специалисты! Т.е. такие себе «дирижеры», которые играют не на конкретном инструменте, а на «оркестре». И они «играют продукт» — т.е. управляют разработкой всех частей: и мобильным клиентом, и фронтом, и облаками, и ИИ, и датасаинсом. Естественно что для этого у них есть по команде специалистов на каждое направление.
Можно знать и понимать несколько технологий. Невозможно стать специалистом в каждой из них! Человеческий мозг все-таки ограничен. Иначе каждый доктор мог бы лечить всего человека, а не отдельный орган.

Как владелец компании, на Java проект с data pipelines вы бы наняли C# человека который работал с ними, или java специалиста который всю жизнь писал jsp?

Ок, с этим примером согласились, дальше.

бо за пару років все змінюється, доки ти сидиш на одному друге вже або виросло або померло

То есть Вы сами говорите, что технологии меняются. Следовательно если Java Developer приходит на новый проект, ему нужно смотреть как люди пишут на нем джаву (часто совсем иначе). К тому же: понимать тонкости бизнеса, какой процесс, как организовывать/подавать дизайн, как происходят билды, какой ревью, какой деплоймент, как следить за своими фичами(мерять impact все ли работает и тд), как работает oncall процесс и какие самые стандартные проблемы, наладить связь с новыми людьми и понять их особенности и тд.

Почему Вы думаете, что при всем этом «Java Developer» будет полезней? Мне повезло работать с многими людьми с разным опытом и скажу что опыт предыдущего языка мало корелирует с успешностью человека в компании. По моим наблюдениям более корелируещие свойства это толковость и заинтересованность в проекте/области.

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

Ох, я устал с Вами спорить. Я вообще сожалею, что сюда влез. Моя позиция, что я и большинство людей с кем я работал в последнее время были наняты как Generalist SWE. Проблем с этим не испытывали и запускали достаточно успешные проекты. Имея опыт обоих моделей я считаю, что нанимать Generalist SWE лучше, но тоже имеет недостатки.
Спасибо за Ваше мнение.

Они только по ключевым словам идентичны

«У них» это где?
Netflix, Amazon, Apple, Uber, Lyft к примеру берет конкретно в команду.
В Google уже как 2 года сначала подбирают команду потом идут со всем пакетом и решают нанимать человека или нет.
В Facebook еще есть bootcamp но с определенного уровня предпочитают преопределить тебе команду перед наймом.
И тд по списку.

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

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

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

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

Везде есть политики, если думаете, что нету, то Вы их просто не видите.

Естественно что для этого у них есть по команде специалистов на каждое направление.

Тоже не правда.

Похоже Вам там виднее, чем мне работая удаленно. Удаленно ищут только специалистов с минимум 5 лет опыта в конкретном стеке.

Везде все нужно на вчера, у всех есть конкретный стек.

Т.е., например, у меня опыт в C# много лет, знание алгоритмов, практика решения разных задач — но Java а знаю на уровне курсача в институте. Плюс я знаю С++, Visual Basic, SQL, Java Script... Т..е можно сказать что я если не «генералист» — то «Т-shaped». И вы хотите сказать что меня могут взять в команду их проекта на Java? Из соображений что лучше синьора переучить с C# на Java, чем взять Java мидла?
Предположим — берут, и что потом? Сколько времени дают на дообучение? Оплачивают ли это время? Ждут пока разберешься или говорят «лепи быстрее как умеешь, а учись по ночам»?

Тоже не правда.

Если у них нет специализации — то это значит что мобильный клиент, фронт и облачные сервисы пишет одна и та же команда? Т.е. нужно одновременно работать на разных 3-4 стеках?

Удаленно ищут только специалистов с минимум 5 лет опыта в конкретном стеке.

Вот проблема в том, что я не уверен, что это «они» ищут. Им без разницы вы себе идентифицируете как Java ninja или Drupal architect, с каким полом ассоциируете, пьете ли пиво и тд. Главное чтобы работа была сделана. Я действительно думаю, что это диктует нанимающая сторона.

не «генералист» — то «Т-shaped». И вы хотите сказать что меня могут взять в команду их проекта на Java? Из соображений что лучше синьора переучить с C# на Java, чем взять Java мидла?

Хоть ∑ шейпд, я не знаю как сейчас модно себя называть. Главное чтобы работа была сделана. Толковость оценят по тому как вы будете решать задачи, уровень определят больше по Вашим личным качествам и насколько Вы понимаете дизайн систем.

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

Если у них нет специализации — то это значит что мобильный клиент, фронт и облачные сервисы пишет одна и та же команда?

Зависит от конкретной компании и команды. В предыдущей команде писали и сервисы и фронт и деплоили сами и оптимизировали обе стороны. В текущей компании прибавились еще и мобильный клиенты. Иногда нужно самим же писать и pipelines. Для одного проекта написали и задеплоили сами ML модель, которая сейчас используются для 2 миллиардов человек каждый день.
Нас всего 9 человек, все Generalistы.

Сколько времени дают на дообучение? Оплачивают ли это время? Ждут пока разберешься или говорят «лепи быстрее как умеешь, а учись по ночам»?

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

Очень жаль, что его проектировал Jeff Dean и его команда, а не Viktor.
Если есть что-то по делу, то github.com/...​sorflow/tensorflow/issues

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

А о чем с тобой говорить по сути, если ты ни о TF или о С++ ни бумбум.

Хорошо когда можно определить что человек знает чисто по их должности, правда?

который не раз здесь упоминали, когда ученые-теоретики код пишут

Не скажу про все библиотеки, но конкретно tensorflow и pytorch пишут программисты в сотрудничестве с «учеными-теоретиками». Ученые-теоретики редко пишут production код. Иногда эти программисты называют себя «Applied Machine Learning Developer» или схожими терминами, но до теоретиков им далеко.

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

Пол-года?! Прямо коммунизм какой-то у них! Можно спокойно разобраться в задаче, изучить нужные технологии... За полгода я и правда на любом языке смогу написать!
У нас на проект берут минимум с 5 годами опыта C#, собеседуем очень подробно по всем нюансам .Net, берем только самых толковых... Половине кандидатов за месяц не удается проект даже правильно поднять у себя! Это же «кровавый энтерпрайз» — ворох солюшинов, подпроектиков, сервисов, скриптов, тулов... документацию никто не пишет — она устареет на следующий день. Банально не зная правильных настоек Visual Studio — можно днями пробовать билдить и ничего не получится. А вы говорите — генералист...
Так что выходит что просто у нас более жесткие условия работы — отсюда и требования выше!

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

Пол-года?! Прямо коммунизм какой-то у них!

Я ответил через сколько уволят, а не через сколько ждут прогресса.

У нас на проект берут минимум с 5 годами опыта C#, собеседуем очень подробно по всем нюансам .Net, берем только самых толковых...

5 лет опыта бывают разные. Если для Вашей компании/команды это работает, то это хорошо.

Половине кандидатов за месяц не удается проект даже правильно поднять у себя!

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

У нас на проект берут минимум с 5 годами опыта C#, собеседуем очень подробно по всем нюансам .Net, берем только самых толковых... Половине кандидатов за месяц не удается проект даже правильно поднять у себя!

что-то самые толковые настолько все усрать смогли что я начинаю сомневаться в адекватности оценки толковости

Нормальный такой «кровавый ынтырпрайз» )) а что такого?

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

А ну ок.

Осталось только а) выделить финансирование на этот годик рефакторинга б) отложить все бизнес задач имплементации снова же ж на этот же ж годик.

А так всё ок всё правильно написал.

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

«Фоновой режим» — нет не слышал?

а точно недочитал да тогда ты 146% прав всё правильно написал!

ЗЫ: а то я в фоновом режиме только доу и фейсбук и котиков читаю ((

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

О да точно всё так и есть особенно в мире сурового копроратива открываешь вот чейнж в каком должно быть всё просто вот по описанию а там какая-то туева хуча каких-то изменений спрашиваешь чувака «чозана!?» а он такой «ну я тут почистил там добавил написал пару строчек и код понятнее и очевиднее...» правда по чейнжу понять чозана происходит уже нельзя но то такое кому эти коммиты вообще интересны и задачи все эти и вот эта вся бурократия включая «а чем чуваки занимались целый год?» «а ну вот же ж коммиты какие-то ворнинги почистили строчки написали...» «и что на всё это ушло хПи времени (и читай соотв. денег з.п. фонда)!? нах. всех на мороз!»

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

Та же ж история и проекты стали писаться вместо 2-х лет 5 лет и даже уволить никого виноватых не успели потому что проект вылетел по финансовым показателям хотя по KPI «работа крутится баблишко мутится» (к) (тм)

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

Но ведь я уже написал что ты всё правильно пишешь что ты 146% прав чего же ж ты хочешь от меня?

покааааааййййссяяяяяя!

открываешь вот чейнж в каком должно быть всё просто вот по описанию а там какая-то туева хуча каких-то изменений спрашиваешь чувака «чозана!?» а он такой "ну я тут почистил там добавил написал пару строчек и код понятнее и очевиднее...

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

Половине кандидатов за месяц не удается проект даже правильно поднять у себя!

Ну это же просто лютый звиздец. Такое надо фиксать, и не в фоновом режиме.

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

Одной из лучших практик, которая лечила такие ситуации была следующая — в куске кода уходящего на ревью не должно было быть следующих вещей:
1. Ворнингов — прежде всего неиспользуемых переменных и лихих приведений типов.
2. Закомментированного и неиспользуемого кода.
3. Дебажного кода. Если место сомнительное — изволь оформить нормальный вывод в лог.
4. Magic numbers.
5. TODOшек. Если невозможно сделать нормально здесь и сейчас — открывается отельный тикет.
6. Кода не соответствующего coding convention.

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

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

Половине кандидатов за месяц не удается проект даже правильно поднять у себя!

Тут явно нужна целенаправленная работа как минимум над тем, что у нас называется «инжениринг систем». А может и над архитектурой системы. Одной правкой код-конвеншенов тут никак не отделаешся.

в куске кода уходящего на ревью не должно было быть следующих вещей:

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

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

Всякая хорошая работа начинается с уборки на рабочем месте.
Когда из кода убирается минорная шваль случается две вещи:
1. Он становится реально читаемым и понятным свежему человеку.
2. Настоящие проблемы становятся отчетливо видны, а в случае TODOшек попадают в общедоступный список багов.
3. Большая часть багов сложна именно отысканием root cause, а не самим фиксом.

Вот есть у меня файс на пару тысяч строк кода, я допустим дописла и поправил там строк 50, к чему должны предьявлятся те самые требования, ко всему файлу или к тому что я в нем потрогал?

К тому, что потрогал.
Остальное — в расчистной тикет.

правильного ответа на этот вопрос я не знаю.

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

К тому, что потрогал.
Остальное — в расчистной тикет

Ага.. Ну вот есть у меня скажем файл написанный в очень странном стиле, с говняным код конвеншеном. Я потрогал в нем пару-тройку методов и переписал их в нормальной код конвенции.. Теперь у меня файл с кодом использующим разные код конвенции. Внимание вопрос знатокам: Стал ли он от этого лучше?

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

По-моему это бред сивой кобылы. Во-первых либо чистить все, либо ничего.

Внимание вопрос знатокам: Стал ли он от этого лучше?

да

По-моему это бред сивой кобылы. Во-первых либо чистить все, либо ничего.

чистить все, но поэтапно

Внимание вопрос знатокам: Стал ли он от этого лучше?
да

От того что в нем теперь стало 2 разных стиля? Точно лучше? Я честно говоря готов поспорить.

чистить все, но поэтапно

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

Ну ок.. развиваем ситуацию дальше. Взяли и почистили 20%, после этого чистка поэтапно несколько затянулас — такое бывает, допустим на пару годиков... Допустим что за это время принятый вами конвеншен успел поменяться... Так ведь тоже бывает? Особенно в аутсорсе, правда? Вот Вы возвращаетесь к правкам этого файла и... и что вы там сделаете? ещё раз перерефакторите 20%, и в результате получите файл с уже с тремя конвенциями?

Я честно говоря готов поспорить.

Спорь. Но практика говорит, что от этого получается реальное улучшение.

и в результате получите файл с уже с тремя конвенциями?

Любой вопрос можно довести до абсурда, и этот не исключение.
Но в общем, даже если в нём 150 конвенций, он будет работать. А устранять лучше с наиболее неадекватной.

Любой вопрос можно довести до абсурда

При чем на практике тоже. Видел такой случай на практике, потому и пишу.

Но в общем, даже если в нём 150 конвенций, он будет работать.

Так он точно так же и с одной, наиболее неадекватной конвенцией будет работать. Как-то.. не факт, что хуже чем сто 150 разными.

Читаться будет явно хуже.

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

Если это 150 в основном хорошие — да, именно так.

Из чего следует, что в такой ситуации они будут хорошими то? Это во первых, во-вторых то, что для кого-то хорошая конвенция бывает раздражает других. в С++ мире к примеру оно так. Чего стоит батл между m_ префиксом и _ постфиксом для членов класса....

нет батлов. каждый проект выбирает свой код стайл и все

В смысле ты их не видел?
А что если у тебя несколько компонентов и каждый из них выбрал другой стайл? А что если в одном компоненте используется несколько кодстайлов?

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

Выбирают оставшиеся в живых после батла ))

И позже отрицают сам факт наличия батла :)

не батл, а так — возюканье. потом приходит лесники все делают как он скажет

для кого-то хорошая конвенция бывает раздражает других

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

Ну конеретно в моем случае это была смена состава тех, кто работает над проектом. Ну и ключевое слово о том как они работали это «как-то».

От того что в нем теперь стало 2 разных стиля? Точно лучше? Я честно говоря готов поспорить.

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

По-моему чистить все поэтапно это отдельный таск и нечего его мешать с текущей работой.

ну и не зайдет он в спринт никогда, кому нужен большой таск с нулоевым велью на сейчас? — никому

опустим что за это время принятый вами конвеншен успел поменяться... Так ведь тоже бывает? Особенно в аутсорсе, правда? Вот Вы возвращаетесь к правкам этого файла и... и что вы там сделаете? ещё раз перерефакторите 20%, и в результате получите файл с уже с тремя конвенциями?

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

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

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

Команда приняла такое решение исходя из своих предпочтений или того как написанны её компоненты

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

или сверху спустили

так возразить, а если сидели молча, то страдания вполне заслуженные и все равно переводить то что в процессе

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

Ну а вот как это можно учесть. Вот моя жизненная ситуация: есть легаси кодбез который «в говне» и уже «в процессе» и возможно не один раз, как минимум в плане конвеншенов (уже имеется дикое смешение диких стилей), но вообщем к его «дизайну» тоже есть вопросы. При этом большой, при этом далеко не тривиальный. При этом его дальнейшая судьба не до конца понятна, менеджмент поговаривает о том, что его хорошо бы ретаерить, но сам не понмает пока как. Есть небольшая команда, со своим приоритетами, нагрузкой. Команда занимается в том числе и поддержкой этого кодбейза. Вот что она может учесть и какое хорошее решение можно принять в этой ситуации? А.. забыл сказать, в команде тоже есть разные мысли на тему того каким код конвеншеном стоит пользоваться. При этом проект ещё и прошол через смену технологий — появился новый стандарт С++, новые фичи языка и новые веяния в написании кода. Дальше продолжать?

Договориться про конвеншен, который удовлетворит всех, существующий код объявить плохим, все что дальше этих двух событий — новый код, который должен быть написан по-новому, весь старый код (1) нельзя трогать без переписывания по новому в пределах метода/класса/приложения/чегоУгодно, весь переписанный старый код (1) цепляющий другой старый код (2), не обязывает переписывать старый код (2)

кому нужен большой таск с нулоевым велью на сейчас? — никому

1. Рубить на маленькие, да хоть по одному файлу.
2. Всё равно какой-то хвост выделять.

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

Тогда накладывается вето на такое руководство.

Нет. У меня таких было меньшинство.

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

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

«а чем чуваки занимались целый год?»

Некорректно. Если ты вообще сидишь пытаешься врубиться в «чозана? делает этот код», то потом записать внятным языком свой результат раскопок в виде doxygen/etc. — малая часть времени и тонна пользы.
А время таки надо писать на раскопки. «Отработка взятого папэрэдныками технического кредита».

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

Это довольно сложный вопрос чаще всего получается «тут описание есть тут описание нет чтозана тут что-то задумано!?» хотя бы б потому что «задумано» например просто «чистокод» какого-то API безо всяких «описаний» ну так задумано так бывает. И тут появляется описание...

А время таки надо писать на раскопки. «Отработка взятого папэрэдныками технического кредита».

Это довольно сложный вопрос чаще всего получается «тут делали фичу и немного потратили +20% на рефакториенг и раскопки и отработку технического долга» только эти +20% явно не озвучиваются и оплачиваются только неявно потому как явно протащить их через бухгалтерию никогда не получается.

Там даже интереснее вот скажем универсальная история «от сих мы на всё будем писать юнит-тесты!» (к) (тм) ок говорю это будет стоить вот стоимость тестируемой архитектуры вот стоимость тестов готово ли руководство выделящее деньги на которые мы и покупаем ресурсы для кодописания выделить деньги вот конкретно на это «на всё писать юнит-тесты?» (к) (тм) и тут начинаются такие заминки «ну как бы б да...» но ещё ни разу чётко выделенного бюджета на это я не видел хотя всякий раз в расчётку эту строку подробно вписываю когда в ТЗ такие требования «на всё писать юнит-тесты» ))

С «техническим долгом» та же ж история и даже более того такими «партизанскими методами» (к) (тм) ну типа

добавляешь, например, аргумент к функции, но заодно добавляешь описание всех аргументов

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

Он только множится

С чего это?
Было 0% документировано, стало, условно говоря, 90%.

а на код-ревью смотрели только те кто смотрел чтобы скобки с пробелами шли в правильном порядке

Ну так надо тщательне́е смотреть.
А ещё есть автоматизированные проверки на неухудшение.

А ещё есть автоматизированные проверки на неухудшение.

ничосси!!! да у вас круто там!

а автоматических писалок на улучшение нет? ^_^

Было 0% документировано, стало, условно говоря, 90%.

на самом деле «было 0% документировано стало −5% документировано» (к) (тм) ))

ЗЫ: я сам такие «документирования» апдейтил когда мне их выдавали как «вот у нас записано пошагово что нужно сделать чтобы вотЪ» а по ходу там ни модулей ни людей ни отделов ни процедур которых перечислено давно (год-два это «давно» или «совсем недавно»?) уже нет здесь проблема именно в процессах плюс планомерном подходе нет такого «лучше хоть какая-то документация чем никакой» в этом месте происходит классическая ошибка выжившего потому как люди помнят только те прецеденты когда документация а) более или менее актуальна б) более или менее внятно написано в) как следствие вообще полезна. Более же ж общий опыт говорит об том что даже прямо поставленная задача якобы «изучить и написать документацию» в 90-99% случаев результатом выдаёт то «чё за х. это вообще ок всё это выбросить от сих до сих выновных премировать и далее тщательно следить чтобы не пускать их вообще что-либо писать» вот как это работает в более реальной практике и более реальной статистике.

Просто потому как главный вопрос «а зачем?» (к) (тм)

Вот добавил человек 1 (один) параметр в функцию и написал какую-то документацию вот только вопрос «а зачем?» (к) (тм)

пожалуй, неактуальная документация действительно во вред, но я уверен есть способы держать ее актуальной, а еще я видел одного программиста, которому нравилось документацию писать — просто находка для проекта :)

а еще я видел одного программиста, которому нравилось документацию писать — просто находка для проекта :)

а ещё я видел не одного программиста которому нравилось код писать просто после этого кода надо было бегать по столу и кричать «о мои глаза мои глаза а-а-а!!!» (к) (тм)

Потому я и ввёл и начал везде совать простое правило «а зачем?» (к) (тм) это работает я проверял ))

ЗЫ: вот скажем сидел сидел программист что-то там «делал рефакторинг» ну ок суть евонного правда неясна и вообще там бред сивой кобылы ну ок пусть будет хотя я сразу спросил «а зачем?» (к) (тм) но потом этот же ж программист приходит и говорит «а вот тут вот вставить новое трудно и раньше такое не предусмотрели и вообще» а я такой «эй стой чувак а ты помнишь ты типа рефакторинг делал а зачем?» так что конечно пока что на чисто локальной опыте но 146% работает и если вопрос «а зачем?» (к) (тм) это «ну (рефакторинг же ж типа вообще нужный) пусть будет» то правильный ответ на это сразу в сад. Я проверял.

а зачем ты это написал?

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

а не выделить 5 минут прибрать очевидное говно.

мне не разрешают валить программеров ((

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

Один аргумент к одной функции это вообще не вопрос о котором стоит что-то там думать. А вот если ты добавляешь одну-две функции к паре сот или тысяч старых?

Вопрос, тратиться ли на документирование старых?
Я отвечу — если пришлось в них копаться, то да. Именно в тех, в которых копался.
Остальные — таки на плановую чистку.

Я отвечу — если пришлось в них копаться, то да. Именно в тех, в которых копался.

американцы отвечают что нет )) но это секрет.

американцы отвечают что нет )) но это секрет.

ну тупыыыые ©

Если подумать то оказывается что как бы б и нет вместо того чтобы мешать советскому джуну наступить на все те грабли на которые ты уже наступил сам и в которые советский джун не верит гораздо проще дать ему самому наступить на все те грабли включая чистый полный про.б по копроративной линии вместе с вылетанием в жопу сад просто потому что #оказывается убедить джуна что ты йопта со своими 20+ лет опыта уже 100500 раз наступал на эти же ж грабли и ты сам просто не можешь это объяснить а тебе проще забить чем с джуном спорить вот в этом и есть основная проблема чисто технически непостижимая джуну включая «вечных посредственностей джунов».

Я проверял. Это работает! Йопта это работает!!!

американцы отвечают что нет

Кто именно?

Что если пришлось в них копаться то не оставлено следа кроме непосредственного результата а сам процесс каждому новому падавану придётся начинать сначала на свой страх и риск.

ЗЫ: и что самое занимательное и будь прокляты проклятые американцы это работает! я проверял!

Поток мысли не расшифрован.
Повторите пробу другими словами.

Кто именно?

а уточняющий ответ все ))

Не подтверждается практикой.

если ты добавляешь, например, аргумент к функции, но заодно добавляешь описание всех аргументов — это не «чозана»

Это вам, видимо, не попадались заказчики, которые, увидев такой коммит, сразу начинают писать гневные письма из серии «я вам бабки плачу не за то, чтобы вы мне комментарии в коде писали»

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

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

«неплохие» деньги это не тот мотиватор, который дает безграничное терпение, то ли дело «очень хорошие»

А что если я Rider использую? Вообще не смогу скомпилить? =)

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

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

Есть определенные правила конечно же.
— Желательно чтобы твой код прошел дизайн этап, где ты описываешь свою систему и приглашаешь людей кто уже решал подобные проблемы посмотреть его (это далаешь с того момента как ты «джун»)
— Нужно чтобы твой код прошел все (достаточно жесткие) линт правила. Например C++ в Google очень сильно отличается от внешнего и в нем значительно тяжелее выстрелить себе в ногу.
— В некоторых компаниях есть обязательное ревью людей кто более опытные в определенной технологии, не «специалист». В моем случае я например делал ревью Java, Javascript и Typescript для других команд/оргов в том числе.
— Перед тем как запускаешь проект нужно убедится что legal и privacy дают ок, что есть всегда killswitch который уберет твои изменения из продакшина без редеплоя и о нем знает oncall
— Убедится что есть мониторинг всех важных этапов

Стоит отметить, что специалисты тоже есть, когда я нашел проблему в Angular которая блокировала наш релиз, я работал напрямую с Angular командой и фиксали вместе. Или когда была проблема с релизом системы которая использовала раннюю версию google cloud endpoint, нам помогали ребята напрямую кто разрабатывали ее. Так же если нужно было спросить совет по java или отзыв по твоему стилю мог спросить директора напрямую, который есть автором многих известных java книжек. Но чаще всего это cross functional работа и шерится по всей компании. По моей субьективной статистике таких специалистов процентов 20 от общего колличества.

Главное чтобы решение было в рамках SLA и стабильное. А дальше если это все проходит, то не важно сколько вложенных Factory ты написал, главное чтобы работало. Качество кода при этом лучше чем во многих командах «специалистов».

Уверен, что многие тут пишут Crudы с разными оттенками серого, и рассуждают что разница между их экосистемой и другими как между NLP и Quantum computing.

Например C++ в Google очень сильно отличается от внешнего

wat?!?

Так, він в них доволі кончений. Див. напр. google.github.io/...​/cppguide.html#Exceptions

Эти правила порождены ещё лет 15-20 назад. Тогда C++ был, мягко говоря, другой.
Сейчас же, да, они гонят много кода на Go.

20 років назад зарелізили Visual C++ 6 яка в принципі нормально собі бігала із ексепшенами, а для гурманів вже існувала, наскільки пам’ятаю, STLPort, кому Dinkumware STL не подобалася.

20 років назад зарелізили Visual C++ 6

І як в неї було писати під NetBSD? :crash:

Я думаю це синдром гуглевої пиндючності, який призводить до пошуків фатального недоліку в інструментаріях. Гуглу це минається бо він великий і гроші робить не на програмних продуктах, а на рекламі. Наслідувати його я б нікому не радив.

Пам’ятаю, як стикався із їхніми геніями за доби ранніх Андроїдів. Спочатку вони розповідали, що, мовляв, native нікому не потрібен, всі можуть писати на нашій кастрованій яві, яка і не зовсім ява — що вони в суді з Ораклом потім доводили. Потім таки дозволили native, бо щось ніхто не поспішав переписувати свої сішні/плюсові проєкти на яву (тут варто згадати, що головний конкурент, iOS, iPhoneOS тоді ще, дозволяв безшовну інтеграцію C/C++ кода із своїм Objective-C) але задля «економії» (!) місця вирубили ексепшени й стандартну плюсову бібліотеку. В результаті всі крос-платформені проєкти вимушені були перезбирати тулчейн і тягнути на систему кожен власну копію стандартної бібліотеки. Апотеозом цієї «економії» для мене стало те, як їх bionic недороблений на виклик setlocale() повертав нульовий вказівник замість вказівника на пустий рядок чи на «С», що призводило до крешу при спробі вивести float (бо воно лізе в локалі щоб взнати як форматувати число).

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

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

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

Уже лет 15 код, который их не генерирует, ничего не теряет.
Хотя некоторые и мышей едят сидят на SJLJ-exceptions... бывает...

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

Потому что человека берут в компанию с прицелом на годы и несколько месяцев что бы вникнуть или подучить — это не проблема.

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

Кстати да, я советовал бы глянуть среднюю продолжительность работы людей по компаниям (она публичная). В среднем сидят 2 года.

Ну, таке. Питання що саме ви шукаєте і на які позиції подаєтесь. На галєрах це дуже часто чітко окреслені вакансії за які буде платити клієнт і якщо він вирішив платити за шевця, то пропозицію заплатити за кравця він може й не зрозуміти. А швидше до пропозиції навіть не дійде, бо перед цим клієнту розповіли що кваліфікованої робочої сили в Україні як в Долині й проблеми знайти будь-кого взагалі немає.

З іншого боку, коли я востаннє шість років назад шукав роботу, то невеликі фірми (місцеві офіси продуктових) в різноплановому досвіді були дуже навіть зацікавлені й вакансії, на відміну від галєр, виходили цікавими в т. ч. й в фінансовому сенсі, не кажу вже про задачі.

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

Обычно бизнес не рассчитывает на «проблемы», а больше, знаете-ли, на налаженный пототк компонентов языка-фреймворка «Х»: где тот, кто на єто научен, будет выдавать более оптимальные решения (они у него уже в голове на большинство вариантов данных и воркфлоу), чем тот, кто недавно выучил соделжание апи. Єто не специфика образования тут играет главную роль (хотя о нем Вы все правильно написали), а та роль, которую себе определила украинская ИТ отрасль. Быстро выдавать, то, что от нее требуют БА заказчиков. Без рассуждений генералистов по полдня на тему «а как оно ложится на современную концепцию цифрового поколения?». В Украину такие проекты не приходят.
Ну, и, наверное, генералистов не берут, чтобы не завел зоопарк технологий на проекте. ))) Конечно, если выбирать все самое оптимальное, то зоопарк и получится, но єто _очень_ дорого в перспективе.

На самом деле это очень сложный вопрос потому как лично у меня всё больше складывается впечатление что в тех же ж штатах «профессия программист» это как в СССР было «и принтер заправлять» только разве что принтер теперь отдан на сторонний аутсорс (внутри штатов понятно потому что физически должен приезжать мальчик получающий $15 в час и менять картридж) а вот всё остальное это как бы б вот это всё и всякие мегамонстрики «а тут у нас дельфи а тут у нас джава а туту жаба скрипт поверх дотнета а тут сайтик ещё на старинном варианте ASP (без дотнета) работает...» (к) это как бы обычная ситуация для «среднепродуктовой американской компании» т.е. казалось бы б наоборот раньше нам советским инженерам рассказывали якобы «оттуда» все такие узкоспециализированные а вот мы советские мы наоборот мыслим широко но в результате по практическому уже непосредственному опыту получается скорее наоборот а какую реальную узкую специализацию то тут используется 2 варианта либо нанять (временно и почасово и за баппки реальные) специально обученного эксперта например архитектора который бы б на писать как выгнать дельфи и в квадратиках нарисовал бы б как запилить вместо него кошерный дотнет либо передать в какую-нибудь страну третьего мира где узкая точечная экспертиза и глубше (ойли) и дешевше (именно потому и «ойли»).

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

Вот как-то так такая вот коррекция реальности по непосредственному опыту. Я проверял.

в результате они пишут аццкий яростный говнокод

братішка проснісь, ВСІ ПИШУТЬ АЦЦКИЙ ГОВНОКОД, ВСІ!!!!111

Могу добавить, что ищут уже не просто C++ или Python, а C++ 11/14/17 и Python 3 с таким апломбом, вроде там полностью вся парадигма поменялась.

В случае C++ — да, это оправданно. До-2011 там стройная система аццких костылей и взрывающихся подпорок.
С питоном — запросы на 3ку идут для asyncio. Там действительно писать надо совсем иначе, и особый набор местных грабель.

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

Тем, что C++98 это кривой инвалид, писать на котором значит постоянно изобретать ржавые подпорки. Такой ответ пойдёт? Если нет — извини, формулируй так, чтобы тебя можно было понять, а мне надоело гадать.

Т.е. или С++98 или С++11/14/17 и ничего посередине?

А посредине стандарта не было. Был полуофициальный C++03, который совпадает в основе с 11-м, но недовылизан, и очень долго и тяжело продвигался. Я его считаю 11-м, для данной темы.
Это как раз большая проблема C++ — что они 8 лет потеряли впустую, и только с выходом 11-го возобновился нормальный рабочий процесс.

Но и С++98 жить можно было, просто не юзать убогие его части.

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

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

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

Именно поэтому сейчас опыт до-2011 варианта это что-то откровенно нелепое.

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

И какая альтернатива?

легко — меняй архитектуру компьютеров

уши архитектуры осей торчат из архитектуры хардвари

И я считаю это лучшим вариантом юзания С++. Иначе таких уродцев рождают, что в дрожь бросает.

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

Аналогично, мы или урезаем шаблонизацию до уровня cfront 2, или вынуждены делать её полноценной (хотя бы как в 11-м, но не в 98-м).

Какие именно «уродцы» тебя бросают в дрожь — не знаю, примеров не было.

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

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

Вот на днях прошёл саммит по C++20, где достаточно новых фишек были приняты за основу, теперь их начнут реализовывать и уточнять конфигурацию грабельных полей. И до финала (ещё почти два года) могут успеть это отработать.

Кстати, там принято р-р-революционное решение отказаться от поддержки платформ, которые не twoʼs complement, и соответствующие уточнения операций с числами. И рекомендовано о том же подумать комитету WG14, который C.

И как исключения мешают в С с классами?

Foo* foo = new Foo(1);
... тут что-то сделали, вылетело исключение
delete foo; // сюда не дошли, память потеряна.

Можно оборачивать в комплект catchʼей каждый такой кусок, но зверски неудобно.

Мне никак не мешают.

Или ты на нём серьёзно не писал, или троллишь.

Но, есть и плюс, наконец-то задумались об UB со знаковыми и беззнаковыми.

Ты плохо понял.
UdB в случае операций со знаковыми никто, увы, отменять не будет. По крайней мере в 20-м.

Сделано (предварительно) следующее:
1. Постановлено, что кроме дополнительного кода ничего не бывает.
2. Убрали норму, что битность знаковых может быть меньше парных им беззнаковых.
3. Конверсия между беззнаковым и парным ему знаковым тупо сохраняет все биты.
В результате получается гарантия, что, например, (int)((unsigned)a + (unsigned)b)) работает как сложение с усечением.
4. Сдвиг влево для знаковых работает гарантированно как усечение (по-моему, это диверсия, и могут отменить).
5. Сдвиг вправо для знаковых работает гарантированно как F-деление.
6. Пообещали подумать (когда — неизвестно) про более внятные варианты (типа ввода аналогов __builtin_xxx_overflow в стандарт). Но это именно как отдельные операции. Контекст, боюсь, введут где-то к 2040-му.

Foo foo; решает.

Как только ты выходишь за пределы песочницы — перестаёт решать.

Например, когда можешь не создавать объект в зависимости от входных данных.

Или когда у тебя таких неопределённое количество, и нужно делать вектор указателей.

В том-то и дело, что не плохо :)
Я спокойно могу сделать vector<unique_ptr<foo>> и оно будет корректно хранить, что надо, и освобождать по любому выходу (или по деструкции, если это в объекте).

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

правда оверхед нехилый на больших обьёмах данных

У unique_ptr? Нулевой.

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

Согласен, кроме «как в русте». Потому что он не единственный и не первый, ну и полных аналогов его подхода в C++ что-то ещё не видно.

У unique_ptr? Нулевой.

в

vector>

?
что будет хранить вектор?

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

указателя на куда?

снимаю вопрос. протупил

. тут что-то сделали, вылетело исключение
delete foo; // сюда не дошли, память потеряна.

що саме?
це критично?
програма далі має зміст?
в секті Rust пишуть,. що мемлік і надійність, це перпендикулярні напрями.

з.і.
куй з СОЛЫДом, але але RAII забили болт?

це критично?

Ыт дэпэндз он.
Помню, как некий проект зарезили, когда средняя скорость потери памяти упала до 1KB/s. Это ещё в 96-м, лишний мегабайт был заметен :)

в секті Rust пишуть,. що мемлік і надійність, це перпендикулярні напрями.

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

куй з СОЛЫДом, але але RAII забили болт?

Вы опять выражаетесь как-то стрёмно, но очень непонятно.

Лучше попрошу расшифровать.

чому не використати Resource Acquisition Is Initialization: в пійманому екзепшені гріх викликати деструктор, який звільнить ресурси захоплені в конструкторі?

Вы паршиво читаете. Я как раз объяснил, что с unique_ptr и аналогами всё само работает. А это и есть воплощения RAII.

. тут что-то сделали, вылетело исключение
delete foo; // сюда не дошли, память потеряна.

де RAII ?

Я ж говорю — читать не умеете, не хотите. тут:

Я спокойно могу сделать vector<unique_ptr<foo>> и оно будет корректно хранить, что надо, и освобождать по любому выходу (или по деструкции, если это в объекте).

В следующий раз старайтесь хоть немного ловить контекст.

Щось ви плутаєте, який ще C++98? C++03 був базовим стандартом вже багато років і через сповільнення розвитку мови й стандартної бібліотеки всі апгрейди відбувалися в boost’і й були доступні з коробки одразу ж. Вихід c++11 тільки затвердив частину boost’а як стандарт й подарував нам синтаксичний цукор у вигляді auto й людських лямбд.

Щось ви плутаєте, який ще C++98? C++03 був базовим стандартом вже багато років

Так, тут сплутав. C++03 важливого не приніс, тому в основі це залишилось 98-м.
Був проміжний напівстандарт C++0x, ось саме замість нього згадав про нікчемний 03.

і через сповільнення розвитку мови й стандартної бібліотеки

Ось і підтверждення.

всі апгрейди відбувалися в boost’і

Так.

й були доступні з коробки одразу ж

Ні. Постійні проблеми з сумістністю його версій, потребами мати декілька версій паралельно — вбивали всю зручність.

Знаю декілька місць, де саме через це відмовлялись від рис 0x і 11 аж до 13-14-15 року. Одне з них — моя попередня робота, я частково брав участь в перекладі коду з 98/03 на 11.

Ні. Постійні проблеми з сумісністю його версій, потребами мати декілька версій паралельно — вбивали всю зручність

Не помітив такого. Неодноразово мав зоопарк бустів через те, що на різних платформах різні команди його апдейтили з різною швидкістю, а на лінухах часто взагалі трималися апстріму, і ніколи через це не мав проблем. Найбільш вживані бібліотеки, зокрема й ті, що увійшли до C++11 завжди були доволі консервативними: Bind, Lambda, Thread, не кажу вже про shared_ptr. Ото єдине що Filesystem регулярно щось там смикають.

я частково брав участь в перекладі коду з 98/03 на 11.

мартигшкін трут у ЦППників — переписувать овнокот при зміні версій ЦПП

з.і.
достало «перекладі», це тіпа з опщепанятнаха на мунспік?

мартигшкін трут у ЦППників — переписувать овнокот при зміні версій ЦПП

Якщо з кожним разом можна щось спростити, чому б і ні?

достало «перекладі», це тіпа з опщепанятнаха на мунспік?

Дядьку, я вас не розумію.

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

на скільки я в курсі, в Rust можна версії прибивати цвяхами, і це на вічність

И грамотный инженер не освоит это за пару недель?

Но мы-то обсуждаем это в контексте поиска тех, кто уже всё это умеет?
Ну и в данном конкретном случае «грамотный инженер» уже должен был лет 5 как это уметь и это хотеть (C++98 откровенно связывает по рукам и ногам).

C++98 откровенно связывает по рукам и ногам

Шо серьезно? Я второй месяц копаясь в здоровенной софтине только позавчера обнаружил у вектора непривычный метод, полез в мейкфайл и обнаружил, что мы таки собираемся под 14-й.
PS C++ как ту стюардессу пора уже закопать по второму разу.

Не выйдет закопать — замены нет.

Java/Python/POC/Go

Java/Python/POC/Go

Шутите? раст может где то рядом, но не эти «ребята».

Смотря для каких задач.
Один из моих текущих проектов взлетел впервые, когда был судорожно перегнан с C++ на Python. Так и развивается.
20-кратный провал по производительности оказался менее важен, чем то, что оно вообще не падало.
Это в 2003-м. Сейчас, конечно, смотрели бы на Go, Java и т.п., а тогда нормального выбора не было.

так может для вашего проекта не нужно было c++ использовать? это как реализовать веб приложение на плюсах, потом переписать на php и сказать что php может заменить плюсы :)
по факту, там где пишут на плюсах — никакой (к примеру) golang не взлетит, у него своя очень ограниченная ниша, где он успешно себя проявляет.

так может для вашего проекта не нужно было c++ использовать?

Да, не нужно. Если б его сейчас начинали с нуля, я бы однозначно взял Java.

Но тогда были аналоги перед глазами и готовые библиотеки.

по факту, там где пишут на плюсах — никакой (к примеру) golang не взлетит,

Это сейчас с тем, как он (golang) более-менее развился.

Это сейчас с тем, как он (golang) более-менее развился.

это вопрос?) не понял что хотели сказать

Это утверждение. О том, что раньше при его отсутствии было больше причин делать на C++.

Сейчас технологии позволяют написать тяжеловесный сервер на Java, драйвера к нему на С, CLI на Go и glue-logic ко всему этому зоопарку на Python. Используя сильные стороны каждого из перечисленных языков.
Что возвращает нас к первоначальной дискуссии о генерализации.

RUST такой же больноголовый оверинжиниринг, как и современные кресты.

C для ловлевел,
Rust для бізнеслогіки, якщо тре надійність і швидкість
GC мови для всього іншого.

якщо тре швидкість

30% performance degradation :(

ти про відносно С?
чи хрестів ?
якдо до ЦПП, то деградації не видно, а дажє навпаки

відносно чого деградація перформанса?

не С/С++.
а тільки до С, без плюсів

Згадалося, як розробники iOS розповідали, чому на макє GC давно вже є, а на iOS треба руками в Objective-C референси рахувати: вони порахували й вирішили, що надто повільно буде на мобілці це робити.

В той же час на іншій конфі чи-то в групі розробники Android ображено розповідали, коли їх запитали, чого в них скролінг гальмує, а в iOS — ні, що, мовляв, це в iOS мухлюють, нечесно дали треду, що гуй відмальовує, підвищений пріоритет, а от Android чесно гальмує в таких випадках.

Я це до чого. Що магії не існує. Користуєшся GC — платиш за GC. Фішка плюсів, від перших ще прототипів, що чим не користуєшся, за те можеш не платити.

розробники Android ображено розповідали, коли їх запитали, чого в них скролінг гальмує, а в iOS — ні, що, мовляв, це в iOS мухлюють, нечесно дали треду, що гуй відмальовує, підвищений пріоритет, а от Android чесно гальмує в таких випадках.

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

На айпадах скроллинг тоже прекрасно тормозил

Rust прийде, порядок наведе

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

А до этого какую предполагал?

PS C++ как ту стюардессу пора уже закопать по второму разу.

Это к Валялкину.

А до этого какую предполагал?

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

Это к Валялкину.

Я с ним 100% процентов солидарен. Динозавры должны уступить место млекопитающим.

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

Ну вот и пойдут к 11-му, или даже к 17-му, когда руки дойдут.

Я с ним 100% процентов солидарен. Динозавры должны уступить место млекопитающим.

Это пока что не млекопитающие, это в лучшем случае ехидна какая-то.
До млекопитающих ему ещё лет 20 расти.

Ну вот и пойдут к 11-му, или даже к 17-му, когда руки дойдут.

Плохой дизайн навороченными фичами не лечится.
А сам проект потихоньку мигрирует с C++ на Go.

что за проект, если не секрет? с технической стороны

Якщо людина вміє всі ці тріки старих плюсів, то на 11-й вона перейде з величезним полегшенням й з великим ентузіазмом всі ці відмінності вивчить, їх, насправді, не так щоб вже й багато.

Якщо зараз в 18-м році C++ розробник не знає C++11 хоча б в головних рисах, то він не C++ розробник :) тому що покращення надто радикальне.

їх, насправді, не так щоб вже й багато.

Їх достатньо, щоб це була інша мова.

Тоді ми в слово «знає» різний сенс вкладаємо. Для мене знання — це знання закріплені практичним досвідом, а не прочитав три статті й скомпілював два приклади — «знати в головних рисах»

Їх достатньо, щоб це була інша мова.

Прошу пана, але це тухта. Половину тієї «іншої мови» використовують завдяки бусту вже багато років й перехід на c++11 у великій мірі складається із заміни бустових хидерів на неймспейсів на стандартні та викиданні непотрібних shared_ptr там, де тепер можна move заюзати.

Тоді ми в слово «знає» різний сенс вкладаємо. Для мене знання — це знання закріплені практичним досвідом, а не прочитав три статті й скомпілював два приклади — «знати в головних рисах»

У випадку C++11 навіть знання про лямбди, unique_ptr, emplace* і т.д. — достатньо, щоб не намагатись писати як 20 років тому.
А практичний досвід у цьому випадку набирається дуже легко — легше, ніж знати фокуси типу «приватний конструктор копіювання, щоб не дозволити його стороннім».

Прошу пана, але це тухта. Половину тієї «іншої мови» використовують завдяки бусту вже багато років

От саме це і є тухта — коли той буст в 20 версіях і якщо не сидиш на якійсь конкретній, то все ламається.
Я саме цей гємор оминув, але розгрібав наслідки.

про лямбди

Boost.Lambda існує вже багато років, в простих випадках взагалі вистачало Boost.Bind. Стандартні лямбди — це неймовірне спрощення того, що раніше було нормальним таким собі гемороєм і не більше.

unique_ptr

scoped_ptr також існує вже багато років, щоправда, в нього немає делітера, для делітера використовували shared_ptr, мали оверхед в зайві атомарні операції, але працювало воно один в один.

emplace*

Всі пов’язані з сучасним move проблеми завжди вирішувались shared_ptr. Так, це оверхед на атомарні операції, в більшості випадків — некритичний. Для програмістів можливість передачі володіння засобами мови — це чергове спрощення і не більше.

А практичний досвід у цьому випадку набирається дуже легко

От і я ж кажу, немає жодної проблеми писати на C++11 тому, хто C++03 використовував у повній мірі.

фокуси типу «приватний конструктор копіювання, щоб не дозволити його стороннім»

Це не фокуси, а фундаментальне розуміння того, як все це працює. Так само як і знання таких речей як vtable чи особливостей реалізації атомарних операцій в залізі. Адже плюси на відміну від якихось там Python2/3 робиться нашаруваннями нових фіч на старий фундамент й втримують тяглість ще зі старим plain C.

Я саме цей гємор оминув, але розгрібав наслідки

А давайте щось конкретне. Апдейт буста, трапляється, щось і ламає, але як правило його збирати довше, ніж воно фікситься.

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

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

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

и никогда из профильных кодерков.

Валом таких, просто не в Украине...

В принципі під своїм терміном я певне все-таки мав наувазі T-shaped або Ш-shaped людину. В одній області треба по-любасу бути кабаном.

До речі коли я на інтерв’ю казав що я Т-shaped тіп, то мене майже ніхто не розумів (((

Стартапери по ідеї мають розуміти, і такі (T-shaped) люди їм потрібні, якщо команда невелика і немає по окремому вузькому спеціалісту на кожен напрямок.

До речі коли я на інтерв’ю казав що я Т-shaped тіп, то мене майже ніхто не розумів (((

Первый раз слышу такой термин.

Лайк, если я не один такой.

Одичал в Техасе совсем)

я вже років три тому про це писав, термін знайомий.
Де «дизлайк»?

Какойто очередной хипстерский баллшит.

Вообще T-shaped это почти обязательно в scrum который типа везде используется...

У нас Т-shaped называют модным словом «фулстек». Например я, как специалист с большим опытом в C# и .Net, так же могу фиксить баги на фронте. Знаю Ангуляр и Реакт — на уровне мидла, в лучшем случае. В итоге у меня получается фронтенд код уровня мидла по цене C# кода синьора.
Разумеется, со временем (годик-другой) у меня станет больше опыта, например в Ангуляре, но к тому времени Ангуляр уже станет не модным и все будут писать фронт на каком-нибудь новом фреймвоке.
Вся эта неэффективность — исключительно от дефицита кадров и жадности! Если бы фронт делал один синьор, а бэк — другой то все было бы сделано качественно и вовремя. Но где найти на галеру 2х синьоров (желательно на зарплату мидлов) если даже одного найти не могут месяцами? Поэтому рождаются идеи делать из специалистов «фулстек» или даже «генералистов».
Каждый врач теоретически — Т-shaped. В медицинском институте каждый проходит практику по всем отделениям: от онкологии до акушерства. Т.е. теоретически любой врач может лечить любую болезнь. НО разница как раз между «теоретически» и «практически». Мало кто захочет идти на операцию к кардиохирургу, если у него нету хотя бы несколько лет опыта.
Поэтому идея заставить кардиохирурга с 10 летним опытом еще и роды принимать, потому что акушер-гинеколог уволился — это как раз и будет «фулстек».

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

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

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

это вот в мраморе сейчас отлил как Церетели просто

чиню двигун на ходу

через выхлопную трубу

прогрессивный метод — уринотерапия

Для слесаря все верно.
С инженера спрос другой.

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

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

Ща будешь ржать.
С мотоциклами, даже современными (которые конструктивно нифига не проще автомобилей — водяное охлаждение, АБС, круиз контроль, инжектор, датчики давления в покрышках, etc.) вполне себе занимаются механики-генералисты. Которые могут и двигатель перебрать, и резину поменять (а на мотоцикле эта операция нифига не тривиальна, как на авто и требует зачастую и***бнуться так изысканно), и пластик спаять и проводку сделать, и подвеску перебрать. Я уже молчу про банальные масло-фильтра-колодки-цепи-звезды).
Не знаю, почему с авто такое не распространено. Наверное, объемы рынка позволяют держать на СТО овер9000 разных лоботрясов, каждый из которых специализируется на конкретной гайке конкретной машины конкретного года.

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

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

Лично я всегда думал слесарь по автомобилям именно так всё и делает т.е. так и задумано ))

«Пишу программы любой сложности на любом языке программирования на уровне блок-схем алгоритмов» ©

Лично занимался ремонтом/реставрацией своего автомобиля! Не просто возил по мастерским и искал кто что сделает, а именно сам разобрал и собрал в гараже! И на удивление многим комментаторам сделал многое намного лучше чем во многих мастерских! И уверяю вас нет там никаких инопланетных технологий которые бы не смог постигнуть человек! Да, согласен некоторые моменты требуют «набитой руки», например то умение равномерно, на одном расстоянии и с одной скоростью двигать руку с краскопультом вдоль кузова, и корректировать угол в зависимости от изменения поверхности. Или опыта и спец оборудования как то расточка цилиндров после гильзования или проточка коленвала. По этому такие операции отдавал мастерам с опытом. И всегда это были люди которые занимались именно этой процедурой, но могли сделать и все остальные. Но, им не нужно было этого делать, работы хватает и так. И даже после когда уже на свои забавы с авто времени уже не было. Те два-три мастера кому я в Киеве мог доверить свое авто, могли слегкостью поменять и выжимной ролик сцепления, и подшипник ступицы, так и прошить «мозги».

На даний момент розробка ПЗ поставлена на рельси бібліотек/фреймворків/...
Знаєш патерни та англійську мову — створюєш програми з базовим функціоналом на любій мові.(+stackoverflow.com)
А кожна поважаюча себе ІТ компанія має одного вузькокваліфікованого спеціаліста в кожній мові, який і допомагає «фаст кодерам» з ускладненнями які супроводжують реальні проекти.

Дик відповідь у запитанні знаходиться. Яка бізнес-модель компаній, такі й вимоги до кандидатів. Для галєр генералісти нафіг не потрібні, а продуктових компаній в нас вкрай мало

а продуктових компаній в нас вкрай мало

Є багато аутстаф проектів де ви досить часто будете працювати типу як продуктовій компанії. В циклума таких проектів багато, в когніанса і тд.

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

Тут просто тонка межа між «Я обираю технології та несу відповідальність за свій вибір» та «Вони обирають технології, а я лише реалізовую забаганки»

я думаю там требования все таки тоже спускают сверху

Маю наувазі що там команда може бути маленька і нашому генералісту буде де розвернутись.

Щодо трєбованій то так, я вже два рази стикався з ситуацією коли на проекті повна дічь була просто тому шо так захотів СТО колись.

Маю наувазі що там команда може бути маленька і нашому генералісту буде де розвернутись.

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

П.С. спросила знакомых, которые так работают с командами из Украины — для них они все на одно лицо и нужно чтобы просто код писали, инициативы не требуется

хотя я неправа. Команды бывают разные

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

да, я это и имела ввиду. Просто вспомнила, что у меня пара знакомых стартаперов, у которых полностью распределенные команды. И то, СТО и архитекты тут сидят

но вообще я с трудом себе представляю, чо в Украине могут наархитектить, судя по соседнему топику про собеседование сеньоров

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

Местами архитектят, и очень даже хорошо. Просто этот вариант хорошо работает тогда, когда заказчик адекватный и понимает, что хорошего архитектора / acting CTO за три копейки не наймёшь.

Может ли синьор девелопер быть «генералистом»? — теоретически да. Я могу написать и на С++ и на Java и даже немного на Prolog (в институте изучали). Но будет ли такой код уровня синьора? Очевидно что — нет. Он будет уровня джуна!
Если хорошо подготовиться за несколько месяцев самообучения — я смогу выдать код на уровне мидла. Но все равно без нескольких лет «хождения по граблям» и набивания шишек в конкретной технологии — код на уровне синьора не написать.

Асолютно не согласен.
Правильный процесс код/дизайн ревью + правильные инженеры = стабильный production ready код с минимумым языковых и технологических замечаний максимум через полгода работы с новым языком-технологией. Многие значительно быстрее справляются.

Я когда-то уже писал про этот парадокс и снова повторю: синьоры нужны прежде всего на старых проектах!
Когда пишет новый проект «с нуля» — могут и мидлы по книжкам написать. В первой версии обычно мало граблей, мало пользователей, мало данных... Но если продукт пользуется спросом — то за следующие пару лет данных становится очень много (особенно если никогда ничего не удалять из базы), одновременно лезет много пользователей (а про масштабирование на старте мало кто думает), запросы на новые фичи сыпятся со скоростью пулемета и имплементятся так же быстро, технический долг растет, тесты давно заброшены...
И вот тогда наступает время специалистов! Начинают срочно искать DBA — чудотворца, который одним движение руки решит все проблемы перегруженной базы. Ищут фронтенд — гуру, который найдет где-же в 50 мегабайтах джаваскрипта течет память, ищут серверного бобра, который сможет распараллелить монолитное приложение или наоборот — навести дисциплину среди расплодившихся микросервисов.
Разумеется, таких проблем бы не было, если бы синьор, а лучше архитект были на проекте с самого начала. Но когда проект стартует — все обычно хотят побыстрее и подешевле. Поэтому ищут не просто «фулстек», а уже «генералистов» по принципу «человек — оркестр», который за одну зарплату поработает за троих.
Так что все зависит от того, что считать

production ready code

: сейчас это все чаще как только первый раз прошел без багов happy path — значит готово на прод! Для такого и правда достаточно полгода работы и 23х летних синьоров.
А для настоящих спецов есть «Правило 10000 часов»:
www.forbes.ru/...​7255-pravilo-10000-chasov

где-же в 50 мегабайтах джаваскрипта течет память

везде?

Не течет там ничего, это он так память использует :-)

использование памяти по технологии ватерфол

Ну, є певні особливості, які не очевидні та можуть призводити до шаленої текучості. Одна з таких — видалення ноди з DOM дерева, в чайлда якої було посилання на якесь замикання. Цей фрагмент залишиться висіти в пам’яті до кінця.

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

Мой тезис другой — сеньорити это далеко не знание того, что в версии 2.843.12.3 спринга надо не забыть поставить аннотацию donotcache иначе будет мемори лик (полностью придуманный пример), а знание и понимание архитектурных подходов, дизайн подходов, командных динамик + хорошие практические скиллы (языки, либы и т.д.). Именно этот запас (+ хороший надзор, см поинт про код и дизайн ревью из моего прошлого поста) дает человеку возможность быстро влиться в новые проекты на более-менее любых языках.

Чем дальше, тем я больше уверен что сеньорность чувака определяется уровнем, на котором он может дизайнить и кодить соблюдая
en.wikipedia.org/...​ple_of_least_astonishment

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

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

А для настоящих спецов есть «Правило 10000 часов»:

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

www.smithsonianmag.com/...​-rule-not-real-180952410
www.inc.com/...​ote-the-original-stu.html

«Говорят, что мудрость приходит с годами. Но часто годы приходят одни»

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

це ти про себе?

Сам не похвалиш—ніхто не похвалить.


—доколє? доколє компанії будуть наймати таких спеціалістів замість того щоб брати просто хороших інженерів здатних впоратися з новим стеком за короткий час?

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

—яка ситуація у вашій компанії? можливо, ви вже такий генераліст, розкажіть іншим про ваш досвід

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

Тому що у нас більшість компаній аутсор. А аутсорсу треба продати людину замовнику якій треба Spring 2.5 а не генераліста.

На заході у компаніі FAANG (та і не тільки) дуже часто не шукають розробника на якусь конкретну технологію/мову а шукають просто хорошого розробника.

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

Если ты способен решать сложные алгоритмические задачи на доске в кратчайшее время — им всё равно на каком языке ты это делаешь.

Взагалі-то ви не праві. В роботі ті алгоритми та структури даних в них не потрібні нікому (так само, як і у нас), про це вже тисячу разів писали. Просто там не вміють інакше проводити тех інтерв’ю, от і все. Найкращим канидадтом до FAANG буде свіжий випускних місцевого тех. вузу який ще пам’ятає всі ті алгоритми.

Вы написали «вы не правы», после чего вместо опровергнуть мои слова, просто дополнили их.

Ви не праві в тому що в роботі алгоритми потрібні і ними займаються їх співробітники в той час як для рутини винаймаються контрактори.
Насправді що в гуглі шо в нетфліксі якщо ви не в команді яка займається кор-сервісом (рекламою), то ви будете займатися таким самим формошльопством як і 80% тут.

Вы читать умеете или только писать? В ответ на ваше

На заході у компаніі FAANG (та і не тільки) дуже часто не шукають розробника на якусь конкретну технологію/мову а шукають просто хорошого розробника

я написал

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

Вы говорили и я отвечал про собеседования FAANG и о том, что на этих собеведованиях FAANG спрашивают то, что я перечислил выше. И я объяснил чем они мотивируют такой подход с собеседованиям. Вы же говорите «вы не правы» и начинаете рассказывать, чем занимаются в FAANG ПОСЛЕ собеседования.

Вы читать умеете или только писать?

Сорян, в основному писати ))) Я ж генераліст, писати швидко вмію, але часто фігня виходить )))

Ви праві, все так.

Вы тоже правы — у хорошего студента вменяемого ВУЗа после полугода подготовки шансы попасть в FAANG выше чем у сеньёров с 10 годами опыта, которые давно забыли как сортировать пузырьком :)

Вы будете писать хуже, а денег захотите больше ) Зачем оно надо?

Це стара пісня, я таке чую протягом свого життя -
«Таких як ти оно на руп пучок за воротями»
Реалії пост-СРСР

Дуже часто команді генералістів, як Ви їх назвали, потрібен знавець певної технології, бо всі сидять і туплять, бо генералісти)

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

1. ваші думки стосовно того чи добре бути генералістом, чи краще бути специалістом?
2. доколє? доколє наші розробники будуть вважати себе вузькими спеціалістами та продовжувати сидіти в зоні комфорту?
3. доколє? доколє компанії будуть наймати таких спеціалістів замість того щоб брати просто хороших інженерів здатних впоратися з новим стеком за короткий час?
4. яка ситуація у вашій компанії? можливо, ви вже такий генераліст, розкажіть іншим про ваш досвід

1. На вкус и цвет. Как по мне, спецом стать невозможно, если варишься в одном болоте.
2. Ранок такого хочет — это раз. Два — дык всем впадлу. Беда в том, что часть кандидатов уровня миддл и выше массив проитерировать не могут. А вы хотите высокого.
3. Есть и компании, которым интересно второе. Их меньше, в виду особенностей рынка.
4. Пишу на том, что лучше всего подходит под задачи. Me gusto и не скучно. Своих ребят настраиваю на такой же подход. Хочу, чтобы они были таки инженерами, а не токарями.

4. Пишу на том, что лучше всего подходит под задачи.

Троллинга ради, с++ все еще наилучше подходит под вообще любые задачи, или уже нет? :-)

Як на мене правильно написаний проєкт на C мало чим відрізняється від такого самого на C++. Інша справа, що правильно на C писати вміють не всі, як серед аксакалів, які просто не знають як це, писати правильно, так і серед тих, що вимушено перемкнулися з C++, які C не люблять, не поважають і зверхньо вважають, що як плюсовики вони вище за все це.

Звісно, стандартна бібліотека та Boost на C++ покривають купу всього, що на C доводиться робити руками, але чогось такого принципового, що не мапиться на C і що не можливо було б ізолювати в окремі модулі я не бачу.

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

а я чим більше впрягаюсь в Rust, тим більша відраза до СРР

Для затравки:
Сомпілений код тупо працює хоч на віртуалці ПК хоч на живому АРМ девайсі.
Єдине, що тре мати\зібрати правильний кростулчейн із «потрібним» компілятором та версією стандартної бібліотеки. і ВСЕ!
Ніяких залежностей від файлів заголовків, які хер зна де лежать, чи бібліотек які те лінкувати, і які тре ще теж перекроскомпілити і розкласти на відповідні полички і які на девайсі теж мають лежати в певному місці.

Бінарник сам по собі роздутий, 2МБ проти 50КБ.
Я не міряв, на скільки тормознутіше, на око може 20%...30%, а може менше, хз, але
код пропрацював без сегфолтів 3 доби, без мемліків, в той час, як подібний сервіс на С вилітав по сегфолту через пару хвилин, і щоб відслідкувати причину, тре було би ще довго її шукати. В той же час аналогічний сервіс на rust з методом де був unwrap() і на якому ішла паніка (в консолі rust виводить підказку де була проблема і можливу причину), переписався за 15 хв. з обробкою помилки (це при тому, що я rust використовую кілька тижнів переписуючи С проект із мікросервісами)

Як для надійних та стабільних мікросервісів, як на мене, не погана штука.
Цікаво подивитися за проектом далі, коли перейде в стадію підтримки, наскільки виникатиме менше проблем із кодом на rust.
Я думаю, що час відладки та затрати на підтримку мають бути меншими. Поживем-побачим.

як подібний сервіс на С вилітав по сегфолту через пару хвилин, і щоб відслідкувати причину, тре було би ще довго її шукати.

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

Виктор, вы сегодня ко мне неравнодушны, и меня это напрягает

нет означает нет

т.е. у вас просто не было необходимых скиллзов и-или инструментов?

біда з тулзами і Сями, і можна лапи відстрілити... ой бида

лапы и рустом можно отстрелить при желании
и в плюсах тоже можно использовать смартпоинтеры и иметь иллюзию контроля

следующий шаг на пути к успеху — переписать все на жабоскрипте

Вначале на Го.

Сомпілений код тупо працює хоч на віртуалці ПК хоч на живому АРМ девайсі.
. і ВСЕ!

и как же я собираю один и тот же код и под пц и под андроид, к примеру?
ах да:

Єдине, що тре мати\зібрати правильний кростулчейн із «потрібним» компілятором та версією стандартної бібліотеки.
і ВСЕ!

так я так и делаю: в кьюткреаторе добавил таргет и всьо

а єслі нєма КуКласа? то шо, шукать С сорси, і\або С++ врапери, кумейки править і молиться шоп взлетіло на ембедед девайсі?

там тот же тулчейн что и у тебя. правишь CC, AR и прочее под другой тулчейн и собираешь. или ищешь тузлу вроде

github.com/japaric/rust-cross

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

у руста есть какаято уличная магия, которая позволяет компилировать мультиплатформенные приложения сама собой?

ДА!
крім штатної установки по дефолту для таргетів
arm-unknown-linux-gnueabi та
arm-unknown-linux-gnueabihf , я наприклад «прикручував» готові кроскомпілери від раніше зібраних тулчейнів YOCTO і PTXdistr, а також будував власні кастомні зборки від crosstool-ng для побудови довільної комбінації: версія ядра лінукса + версія glibc + версія cross GCC.
При правильній зборці, rust код взлітав з півоборота, і політ був скрізь нормальний (одного разу правда були мемліки на новійшому ядрі лінукса в програмі із багатопотчністю, але потім при модифікації кода зник, але растамани кажуть, що сафеті і мемліки — це перпендикулярні поняття).
До речі, реалізація багатопоточності теж сподобалася, не така карява я на Сях та хрестах.

крім штатної установки по дефолту для таргетів
arm-unknown-linux-gnueabi

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

вы сами себе противоречите.

чим саме?
я спробував запустити rust на древній коробці з Linux та glibc зібраними на якомусь древньому debiani 14го року розлива, давнім компілятором armgcc4.7 тому конфігурив і збирав

crosstool-ng для побудови довільної комбінації: версія ядра лінукса + версія glibc + версія cross GCC.

щоб зібране не конфліктувало із таргет системою.
в самому Rust коді нічого не міняв, тільки поміняв в конфігураційному файлі шлях до компілятора да ключі GCС тіпа «ось тут лежить sysroot для АРМ»

тільки поміняв в конфігураційному файлі шлях до компілятора да ключі GCС тіпа «ось тут лежить sysroot для АРМ»

dou.ua/...​rums/topic/25541/#1455675

при чем тут межтредная коммуникация?

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

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

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

пффф — есть такая штука refinement где как раз думается, просто некоторые конторы это игнорят

некоторые

практически все

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

бизнес-аналитик не обязательный элемент — хотя не уверен о том как там на галлерах

строго наебоврот

Хорошая фраза, в мемориз

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

Причому хороших людей багато. Зарплату їм підіймати не варіянт, доводиться плодити лідів, щоб на якійсь час вгамувалися з амбіціями.

Так что в наших реалиях нет никакого аджайла а просто какое-то чудовище франкенштейна.

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

В чудовій книжці по SCRUM, яку мав щастя прочитати, значна частина книги присвячена тому, як психологічно ізолювати, а далі або розчавити, або вичавити скептиків з компанії. Дуже корисна книга, як зберусь заснувати секту чи партійний осередок, обов’язково перечитаю.

вичавити скептиків з компанії

А там часом не було написано, хто після цього працювати буде? :)

Ті, хто вирішать, що вони може й не в’їхали, але будуть демонструвати налаштованість на позитив і відсутність внутрішніх конфліктів.

все так и делают. «вслух — да, в урну — нет» ©

А что за книжка? Интересно было бы почитать.

Від Mike Cohn. Але радити не буду, бо англійською читати — зайві витрати часу та натхнення, а російською — не хочу рекламувати ворожий продукт.

Увидел, что в книге более 500 страниц, и желание читать пропало. Хотя, наверное, в первую очередь надо прочитать Главу 6 «Overcoming Resistance» (чтобы знать врага в лицо).

Лучше бы они писали про overcoming resistance чуваков, делающих вид, что хаос — это и есть аджайл.

Хм, картинка на обложке вызывает определённые ассоциации.

хочу быть генераллисимусом, но пока берут только на сеньора

все кто пишут что не может быть фуллстеков/программистов без привязки к технологии — просто не пробовали такими быть, или не просто не потянули.

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

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

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

Так, але ж і профіту буде більше! Ну не вірю я що треба роками писати на чомусь конкретно, щоб стати там нормальним спеціалістом якщо в тебе вже є хороша база. Я би навіть сказав що код—це чиба не останнє зі всього що потрібно добре робити. Код писати це найпростіше. Насйкладніше—це придумати як вирішити задачу оптимально, донести свою думку до інших людей і потім все зробити.

Наведу приклад—мене на інтерв’ю запитали що таке блоки на рубі. Я, на свій сором не знав точне визначення (хоча як виявилося, користувався цим). Люди з якими я говорив стверждували що вони цю штуку постійно використовують, хоча я просто не міг придумати нашо воно треба було б в моїх проектах. В принципі, можна обійтися і без неї, але код тоді буде не таким елегантним. Елегантність коду в нашому випадку ніяк не впливала б на його швидкодію або коректність роботи. Якщо б я прийшов до їх команди до досить швидко навчився би цим трюкам, буквально після перших двох мердж реквестів.
Чи додало б мені знання конкретної функціональності конкретної мови плюсиків при вирішенні бізнес задачі? Сумніваюсь. Звісно потрібно знати базу мови, але не думаю що розробники які пишуть цикли через for значно гірші тих що користуються лямбдами на та .each

Код—це найменша і найпростіша частка розробки.

Нижче там писали про людей які тюнять запити, я вам скажу що в одній з компаній де я працював був цілий відділ людей, 50, може більше, які фуллтайм займалися тим що фіксили запити, які писали звичайні девелопери. Так, коли ти працюєш on the edge то тобі потрібне глибоке знання інструментарію, але у 80% випадків твоя робота буде надто загальною.

Я глибоко переконаний що, наприклад, людину яка більш менш ок кодить на Java але не знає жодного DI фреймворку можна навчити якомусь спрінгу буквально за пару тижнів.
Людину, яка шарить Python за пару днів можна пересадити на Ruby і через пару тижнів вона буде видавати нормальний код.

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

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

та ну не згоден.
можливо в якихось спец рішеннях де є хайлоади і тд це актуально, але на 80% проектів ви цього ніколи не побачите.

Приклад—за всю мою кар’єру мені жодного разу не доводилося тюнити JVM. Чому так? Та просто тому що ті проекти де я працював не вимагали цього і їм вистачало дефолтних налаштувань. Чи значить це що не існує проектів де треба тюнити JVM? Не значить. Чи значить це що у 80% випадків девелопер може не дуже й здогадуватися які там є опції? Значить. Чи значить це що не потрібно взагалі знати як працює JVM? Не значить. Чи значить це що кожен потрібен знати як працює JVM? Теж не значить.
Знань про різні системи дуже багато, в голові все не вмістиш, для цього є здоровий глузд та документація а також інтернет де за вас вже все розписали.

Давайте свої кейси, бо я не вірю.

LRU cache в Java и эвристика алгоритмов освобождения памяти; (хотя это как раз общая проблема)
Node.js — UV thread pool и как он может застопить цело приложение
MySQL — innodb pool cache size; индексы которые не влазят в RAM
Java — object locking и кеширование strings
за фронт я вообще молчу, там просто уйма приколов

LRU cache в Java

Та ну фігня. Де ви бачили самопальні кеші? Розстріляти хто таке робить коли люди з Терракоти за нас вже все зробили.

MySQL — innodb pool cache size; индексы которые не влазят в RAM

ще один едж кейс.

Java — object locking

wtf, хто зараз напряму з конкаренсі працює?

кеширование strings

щоб це афектило перформенс (і взагалі хоча щось афектило) взагалі два рази в житті бачив, 7 років тому останній раз.

Ви тут про N+1 проблему не написали )))

Коротше кажучи моя думка така—для 80% проектів стопудово вам потрібні роботяги а не знавці кешування рядків.
Для рідких випадків проблем з перформансом наймаються специ по тюнингу іннодб кешів на погодинну ставку і відпускаються після того як все пофіксять.

Ці всі проблеми—це одиничні штуки які мають мало відношення до розробки аплікейшену і фіксяться точковим ударом за короткий проміжок часу.

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

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

твой порог это не тот что у тебя, а тот что ты назвал — 60 часов, этого объективно мало, возьми исключительно бекенд или фронтенд и выпиши самые популярные технологии/абревиатуры, копни в каждую на средний уровень и получишь непреодалимый ком информации, если его попытаться монотонно осилить, то к концу окажется что это уже все старое и вот новый ком, а тут в два раза больше (на самом деле больше, чем в 2) вот и чтобы успеть и там и там начинаются фильтрования, получился фильтрованный мидл фулстек

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

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

о тех 60 часах что я написал это объективно в 2,5 раза больше (самое распространенное кол-во часов это 20 в неделю) чем у среднестатистического разработчика. спокойно можно сидеть в нескольких технологиях одновременно — типичный бекенд — это фреймворк + язык с окружением + 1 БД. типичный фронт — рендеринг (цсс + хмтл + понимание что с этим делает браузер) + джс + фреймворк. фронт к примеру не очень то динамичный, только фреймворки много шуму делают но по своей сути они очень простые (так что более чем реально освоить бекенд в паралели). это более чем реально поддерживать на хорошем уровне. конечно если у вас бекенд на руби а завтра вы собрались переписать на котлин + ктор, то время это таки немного съест но не очень то и много — о чем написал изначально

Среднестатистический украинский синьор не тянет на свою должность, если цель обогнать такого, то ее достигнуть можно и даже легко

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

генералист это врач общей практики ?:-) по моему медицинская терминология. или имелся в виду фуллстек?

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

или имелся в виду фуллстек?

ні

по моему медицинская терминология

взяв з топіків на hackernews. В них це поширена термінологія

Недавно была статья на эту тему — фулстек это вечный мидл.

Поясню як це відбувається.

Менеджер придумує «геніальну ідую», яку треба реалізувати вже. Всі бекенд розробники зайняті. Але прям зараз є вільний iOSсник, який колись кодив на nodejs. Він швидко робить прототип, запускає, ідея спрацьовує. Мікросервіс починає приносити гроші.
Вітаю, у компанії тепер 2 бекенд стека. Тепер є 3 шляхи вирішення — переписати мікросервіс або найняти nodejs або найняти генераліста.

З моєї точки зору — самий правильний варіант переписати мікросервіс поки не пізно. Я теж не вірю в генералістів.

P. S. Чув ще про випадки в аутсорсі:

Розробники: Ми вивчили котлін, давайте напишем бекенд на ньому?
Менеджер: а давайте!

no comments :).

Розробники: Ми вивчили котлін, давайте напишем бекенд на ньому?

Resume-driven development завжди буде актуальним.

Я теж не вірю в генералістів

Очікувати, що «генераліст» буде писати код із такою ж продуктивністю та вийде на повну потужність на проєкті з такою ж швидкістю, як людина, яка ще вчора працювала із заданим стеком просто в іншій конторі, мабуть, дійсно не варто. В той же час доводити це до абсурду, як це роблять нижче в коментах, мовляв, «це буде код джуна» — це вже явне перебільшення. Джун просто не здатний виконати достатньо складний і великий проєкт, щоб воно не розвалилося. Або буде писати його стільки, що встигне перерости мідла. З іншого боку, вузькопрофільні спеціялісти не виходять звідкись готовими майстрами того чи іншого інструментарію, а також вчаться в процесі на якихось проєктах, в умовах постійно оновлюваного середовища. При тому ще й можуть мати обмеженіший круговид. Тож головне, як на мене, це завжди розуміти, що жоден код і жоден розробник не є ідеальними, й тримати в голові певні витрати на виплату технічних боргів «бойового навчання». Причому це навчання доводиться безупинно проходити всім, хоч спеціялістам, хоч генералістам, адже в IT доводиться бігти щоб залишатися на місці.

Буквально сегодня попалась такая статья habr.com/post/429612

Фулстек це фулстек, і генераліст—не обов’язково фулстек. Я вже нижче писав що одна справа знати багато мов і платформ для бекенду де все ± однакове, інша справа—сувати ніс в клієнтську розробку де ад і котли з чортами різних деривативів джаваскріпту.

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

А теперь представь в какой наилютейший пздс начнется когда генерализм будет мейнстримом.

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

Я думал генералист должен знать больше фуллстека, а это типа жирный бекендщик.

Ні, не обов’язково.

Наприклад, я добре знаю бекенд і добре знаю sre/devops штуки (реально достатньо добре щоб пройти інтерв’ю на чистого девопса та отримати офер на ті самі 5к, trust me, вже перевіряв).

Хтось може добе знати бекенд та ML наприклад.

Хтось може писати ізоморфні аппи на кложурі.

Ще хтось може норм знати бекенд і наприклад бази даних на рівні достатньому щоб тюнити параметри.

Всі ці люди, як мені здається, можуть на ізічах перейти на іншу мову та іншу платформу (базу даних, фреймворк, клауд провайдера) залишаючись в приблизних рамках свої експертизи. Натомість, це видається не дуже розповсюдженим та на роботу схильні шукати «сіньор ангуляр девелоперів» та «спрінг мвц девелоперів» а не просто «фронтенд девелоперів» та «бекенд девелоперів».

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

Так а для чого шукати бекендера на будь-якій мові, коли тобі потрібен саме спрінг бекендер?

Тому що попит на ринку більший ніж є спрінг бекендерів.

І який сенс спрінг девелоперу йти на рубіста?

О, тут я напевне окрему доповідь зробив би. Зміст є однозначний, перевірив на собі :)

Якщо попит більший — для чого вам конкуренти?

Ніколи про це не думав. Навіщо компанії роблять опенсорс? Вони ж конкурентам дають свій продукт в руки. Маячня якась.

Рівняєте всіх по собі?

Так :)

Баби стільки не нарожають щоб закрити всі вакансії. Переконаний, що на найближчі років 20 ми без шматка хліба з ікрою не залишимося.

А якщо всі стануть генералістами то і замінити людину буде легше, а значить примхи показувати свої їй не дадуть

ну в принципі всі погодилися що якщо пишеш серйозну штуку то рано чи пізно треба буде розуміти як вона працює в деталях і як би нам не хотілося вузьких спеціалістів будуть вимагати.

Мені просто цікаво для чого ви ведете пропаганду цієї ідеї

Я не веду пропаганду, а якби й вів то ви сильно перебільшуєте можливості мого впливу на індустрію )))

Працюйте собі, яка вам різниця які там ще деви існують?

Люблю побазарить, філософію порозводити, тільки не кухонну про політику, або трактори, або скандали в тіндері, а про методологію, індустрію та професію.

Працюйте собі, яка вам різниця шо тут пише на доу окремо взятий фрік?)))

І як я вже казав—от в FAANG беруть генералістів. І між іншим FAANG—це дуже серйозна частка роботодавців. Так, в нас вони не скоро відкриються, але по світу такий тренд йде.

І то не думаю що там лише дженералістів наймають?

А я й не писав що лише. Просто в них це дуже явно видно.

Ну так це не конкретно по мові, але по близькій мові і одній парадигмі.

Я про це в принципі всюди і писав. Звісно що людина яка реально добре шарить і серверну і клієнтську розробку—рідкий звір.

Strong Computer Science fundamentals (data structures & algorithms).

Про це забув написати, звичайно компутер саєнс це мастхев.

Ні, ви писали що треба брати людину взагалі без привязки до мови.

Я нижче вже коментив що мав наувазі більше роботу в рамках однієї парадигми, хоча знання суміжної буде супер плюсом, як на мене.

А то лише нервуєте кодерків ото)

та я бачу шо ви шось трігернулись :) спокійно, я веду конструктивний діскач на тему. можливо, мої думки абсолютно хибні, вон прийшов наш старий знайомий Богдан і розніс мене в пух і прах.
у спорі народжується істина, чому б і не посперечатися?

А в статтів та форумних тредів були лайки? Раніше здається були а потім їх забрали, так?

Давайте ви будете фулстьокером?

Я і так практично Rails fullstack :) Залишилося верстку підтягнути та реакти-шреакти і буду повноцінним.

Прийміть пілюль, може пройде.

Я думаю ответ очевиден: универсальными девелоперы станут тогда, когда станут универсальными языки и библиотеки и сервера! Что бы зная стандарты, инженер мог одинаково свободно использовать разные технологии, не углубляясь в нюансы и тонкости.
На текущий момент я такого не вижу. Скорее наоборот: даже технологии, которым много лет, имеют массу «подводных камней», нюансов и «ложных путей». Да — ими можно пользоваться прочитав книжку и посмотрев примеры. Но как только объем проекта станет достаточно большим — скорее всего пролезут проблемы с перфомансом, с секьюрити, с утечками ресурсов, с несовместимостью. Потому что специалист во всем — это специалист ни в чем!
Я работал на огромных проектах и поэтому хорошо понимаю цену этим «нюансам». Например: SQL Server — на многих проектах все упирается в перфоманс базы. А в SQL даже порядок строк или не тот оператор могут увеличить время запроса в разы! Поэтому на больших проектах базу не пишут «генералисты», а опытные DBA, которые знают каждый нюанс внутреннего устройства SQL Server.
C С# и .Net то же не все просто. Без глубокого понимания как работают лямбды, асинхронность, очистка мусора и т.д. можно элементарно наступить на грабли в веб-приложении. До сих пор вспоминаю известную ловушку ASP.Net — если вызвать Wait у асинхронного метода — то получается дедлок на пустом месте. В .Net Core это починили — но не зная таких деталей можно легко завесить сайт с миллионом пользователей.
Про JavaScript и писать не хочу. Просто потому, что прекрасно понимаю насколько в нем больше нюансов и «граблей». И если в C# я могу считать себя специалистом, то написать большое приложение на JavaScript я бы не сел без серьезной подготовки. Хотя и считаюсь «фулстек».
Может ли синьор девелопер быть «генералистом»? — теоретически да. Я могу написать и на С++ и на Java и даже немного на Prolog (в институте изучали). Но будет ли такой код уровня синьора? Очевидно что — нет. Он будет уровня джуна!
Если хорошо подготовиться за несколько месяцев самообучения — я смогу выдать код на уровне мидла. Но все равно без нескольких лет «хождения по граблям» и набивания шишек в конкретной технологии — код на уровне синьора не написать.

Я работал на огромных проектах и поэтому хорошо понимаю цену этим «нюансам». Например: SQL Server — на многих проектах все упирается в перфоманс базы. А в SQL даже порядок строк или не тот оператор могут увеличить время запроса в разы! Поэтому на больших проектах базу не пишут «генералисты», а опытные DBA, которые знают каждый нюанс внутреннего устройства SQL Server.

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

Аутсорс бывает разный. Если ты работаешь, например, на одном проекте от Гугла много лет, то шансов стать спецом в Гугл — технологиях намного выше, чем сделав 10 разных проектов.
Проблема недосиньорности — она как раз характерна для фрилансеров — «генералистов». Т.е. человек вроде бы имеет массу опыта и много успешных проектов, но ни в одной из технологий он глубоко не копал. Для стартапов и мелких проектов такой «человек-оркестр» это находка. Но для серьезных энтерпрайз проектов его скилов не хватит что бы вникнуть в тонны сложного кода.

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

И почему это? Вопрос только во времени вхождения.

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

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

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

С этим утверждением я немного не согласен, ибо во первых "ентерпрайзы уже не тe"©; во вторых за время пока ентерпрайзы намитингуют таску, намитингуют рефайнсент, намитенгуют митенг на эстимейт, и заапрувят апрув на впрув чтобы включить митинг в следующий спринт — можно хорошенько подтянуть пробельную технологию до уровня мидла.

на многих проектах все упирается в перфоманс базы

Чаще оно упирается в бездумно заюзанный хибернейт

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

strong consistency считали единственно возможным вариантом для состояния хранящихся на диске данных

Без единой доли сарказма: мне правда интересно, в каких реалистичных бизнес-сценариях eventual consistency может быть оправдана именно для enterprise (а, точнее, для OLTP систем, коими и являются довольно большая часть так называемых «ентерпрайз» проектов)

без сарказма, как вы думаете, среди больших компаний типа убера, тветера, линкедина, форсквера, airbnb и так далее — как много среди них для своих основніх продуктов использует sql базу и strong consistency? Или єто недостаточно ентерпрайзно-большие?

На самом деле, можно и в NoSQL, если грамотно и со знанием дела наворотить вокруг этого саги с compensating actions.

Нюанс в другом.

Компании «типа убера, тветера, линкедина, форсквера, airbnb» вынуждены заниматься подобными плясками с бубном с NoSQL и «закатом солнца вручную» по той простой причине, что при их нагрузках и объёмах данных стандартные реляционные базы упираются в пределы масштабирования «вверх» — а в масштабирование «вширь», до недавнего времени, реляционные БД умели, мягко говоря, не очень хорошо. Это уже не говоря о том, что распределённые транзакции — сами по себе зло с точки зрения производительности.

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

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

и сча дают

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

nosql слишком широкое понятие, и key-value, и графовые и документные.

конечно если из nosql дёргать по ключу, а в sql выполнять кучу джойнов без индексов, или «задушить» реляционку дефолтными настройками (размеры кеша, запись с подтверждением), то условия несколько не равны.

бенефиты nosql больше не в скорости, а в горизонтальном масштабировании из коробки и отсутствию схемы (имхо, это как раз минус, но у sql баз есть проблемы быстро добавить/удалить колонку в таблице на сотни гиг).

p.s. ничего не имею против no-sql решений, в проектах используются как sql, так и nosql продукты.

«Отсутствие схемы» в приличных реляционках уже несколько лет как решено JSON/JSONB полями, разве нет?

да, решено, просто по привычке редко используется )

А ще нормальні СУБД навчилися індексувати структури та контент документів...

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

Потому что подавляющее большинство реляционных из коробки умеют в транзакции, затрагивающие несколько таблиц, и в foreign key constraints. Из NoSQL в такое умеют единицы.

А проектировать приложение так, чтобы одна транзакция всегда затрагивала только одну коллекцию (а то и одну запись) в NoSQL базе — это, потенциально, привносить ненужную и неоправданную бизнес-целями сложность. Равно как и наворачивать проверки на foreign keys в application layer — не говоря уже о том, что это попутно и нарушение SRP.

ИМХО JSON/JSONB поля в современных реляционных базах покрывают навскидку 90% случаев, где тулят NoSQL.

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

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

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

проблема больше в том что хоть скл, хоть ноускл, ты все равно хочешь пользоваться ею как скл

Скорее, не так. Проблема в том, что далеко не каждая модель данных хорошо укладывается в прокрустово ложе key-value storage. По крайней мере, так, чтобы с этой моделью данных было возможно удобно и без лишних плясок с бубном работать в парадигме strong consistency.

А так-то проходили и CQRS, и Event Sourcing — но практика показала, что, в большинстве случаев enterprise OLTP приложений, это только ненужное усложнение архитектуры без явных реальных преимуществ. Максимум, что хорошо показало себя в бою в этом классе задач — это максимально облегчённый вариант CQRS, где вычитка данных производится в обход ORM хорошо оптимизированными SQL запросами.

P.S. Я в курсе, что NoSQL не ограничивается key-value; есть и колоночные базы, и графовые — но у них уж очень специфические ниши применения, и они, как правило, не позиционируются как «убийцы SQL».

Ноускл не убийца скл, он просто другой, это как называть джаву убийцей пхп

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

в другой бы формулировке не то что хайпа, никто не видивший такого ранее не обратил бы внимание

Не, ну, конечно, провокативный ПР — тоже ПР...

Но кто мешал рекламировать NoSQL в духе «вот смотрите, посоны — есть такие-то и такие-то задачи, и если вы их решали с помощью реляционной БД — то наверняка испытывали попоболь. А теперь смотрите, как красиво и просто это решается на NoSQL» ?

Ну если вам для общего развития — то купите билет на самолет МАУ куданить. Когда будете лететь в воздухе — купить у них покушать и заплатите карточкой. А потом расскажите нам на доу был ли у вас strong consistency или eventual consistency и есть ли сиквел база на карточном терминале.

Вот именно. Consistency на уровне хранилища данных и occasionally connected clients — это две большие разницы. Но ваш оппонент их, почему-то, считает равнозначными понятиями.

Если бы ещё рассказали почему им DynamoDB не подошло. Всё равно весь стек на Амазоне, а у dynamo заявлен и multimaster, и multiregion. Какие там подводные камни, не верю не рассматривали этот вариант, вместо своего велосипеда.

Слышал, что OSS Netflix приростал там, где Amazon не тянул такие нагрузки. В частности, Eureka и Ribbon. Мож та же история и с DynamoDB. У нас тут есть прокатчики DVD, мож смогут больше сказать без влезания в NDA

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

использует sql базу

а что тогда?

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

щоб стати розробником-генераліссімусом треба спочатку стати розробником-маршалом :)

А якщо по ділу, то мені так виглядає, що людство постійно розвивається в сторону спеціалізації і фахівці широкого профілю в сучасному світі майже непотрібні. Ну може хіба десь є якісь окремі керівні посади, пов’язані з управлінням чи координацією кількох вузькоспеціалізованих працівників.

Е, слабак 8-)
От де цирк, так це в нас.
Реальний пост з групи «Системный администратор» з ФБ

------------------------------------------------------------------------------------------------------------------------------

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

1. Обслуживание компьютеров: чистка, замена термопасты, подбор и замена комплектующих. Подбор и закупка компьютерной техники. Подключение/отключение/переключение переферийных устройств к ПК (мышки, клавиатуры, гарнитуры)
2. Установка ОС и ПО. Установка переустановка Windows, восстановление информации, установка офисных программ, установка обновлений, установка специализированного ПО (cryptoplugin, galileo, sabre, belavia, СамоТур)
3. Подключение оргтехники. Разрешение вопросов по работе с оргтехникой: устранение замятий бумаги; замена картриджей; разбирательство почему не печатает с компьютера, почему не сканирует и т.п. Контроль заправки картриджей (все офисы). Ведение списка и контроль организаций обслуживающих нашу оргтехнику.
4. Помощь пользователям в вопросах работы почтовых клиентов и работы почты: создание и добавление подписей к эл.сообщениям; трудности с отправкой/получением писем. Помощь в работе с офисными программами (MS Office — Word, Excel, ...): настройка фильтров; разбирательство почему не открывается документ, почему не печатает; и д.р. помощь.
5. Установка/удаление программ на компьютерах (Skype, Viber, WhatsApp, обновления).
6. Проверка на наличие вирусов и восстановление после вирусной атаки.
7. Подключение SIP-телефонов. Помощь в использовании стационарных sip-телефонов (как пользоваться, как разблокировать). Подборка и подключение стартовых пакетов Vodafone, Life.
8. Инвентаризация ПК, оргтехники, сетевого оборудования и комплектующих (память, диски, БП, сетевые/видео/материн./др. платы, колонки, клавиатуры, мыши, ...)
9. Сопровождение системы видеонаблюдения.
10. Обеспечение бесперебойной работы подключений Интернет и телефонии. Общение с провайдерами и операторами связи.
11. Поддержка, установка бухгалтерских программ (MEDoc, 1C, клиентбанки, ...)

Отдельно ит-шник еще занимался (по просьбе сотрудников):
— смартфоны/планшеты: перепрошивка, сброс настроек, установка программ
— активация windows; ремонт ноутбуков, компьютеров, программный и аппаратный ремонт телефонов, планшетов; помощь в подборе техники (бытовой в том числе)

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

Например:
Требуется установить во всех офисах и аэропортовых кассах камеры видеонаблюдения; есть уже в некоторых местах, но морально устарели или не соответствуют требованиям к качеству; требуется съемка в хорошем качестве, архив записи за пару месяцев, доступ к записям через интернет из любой точки мира (в двух словах примерно так).
Купить камеры и др. и сделать все своими силами — отбрасываем.
Требуется найти подрядчиков (через интернет, через знакомых и т.п.), получить варианты, выбрать. Учесть командировки в другие офисы.
Но в процессе разворачивания могут всплыть особенности каждого конкретного офиса. Допустим подрядчики решили настроить запись с камеры в облако, а в офисе интернет АДСЛ, т.е. исходящая скорость до 1Мбита, а 3-5Мегапиксельной камере нужно 5Мбит --- нужно решать вопрос с интернетом. И тому подобные моменты. Конечно, желательно все это участь на этапе проектирования.

UPD:
1. Где территориально находятся офисы?
-Харьков два офиса + Киев + Запорожье + Львов (ит-шников в других городах нет)
2. Количество серверов?
— 5-7, я специально не указывал сервера, все обслуживать не придется
3. Количество ПК?
— 50-60 (требуется инвентаризация и рисование схем размещения)
4. Есть-ли лицензии на (Windows, Office, MEDoc, 1C)?
— Работаем только с лицензионным ПО (никакой самодеятельности)
5. Должность непосредственного руководителя
— ген.директор
6. Наличие «бумагомарательства» (отчеты про выполненную работу и т.д)?
— отчетность руководство любит
7. Насколько проблематично получить финансирование на модернизацию?
— 50/50 Допустим, циску сложно будет обосновать купить (по всем решениям нужно писать, — на словах не прокатит)
8. Наличие отдельного кабинета?
— Совместно с контент менеджером сидеть в одном кабинете
9. Компенсации за работу в выходные дни и после 19 часов?
— Нужно обсуждать
10. Компенсация за поездки в удаленные точки и командировки?
— Оплачивают.
11. Официальное трудоустройство?
— Да.
12. Есть-ли надежда на оплачиваемый отпуск?
— Оплачиваемый.
13. Какую предлагаете ЗП?
— Оговаривается с руководством. Спросят — сколько хочет. (предлагают 10-12к). Ваши пожелания?

Вот такие вопрос-ответ! Ну так что, коллеги? Сколько «пожелать» чтоб наверняка?

о, у меня был точно такой список задач лет назад + физическая прокладка сети (до сих пор помню в каком порядке должны идти цвета в витой паре), сборка, настройка и конфигурация серваков (1с, впн, почта, роутеры). Рабочее место было в конце коридора за шкафом и зп 3к грн. Шарили один стол напополам с коллегой.

Нормальный такой эникейщик с легким налетом сисадмина.

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

джва© стандарта

О БО БЗ С БС З БК К
З БЗ БО С БС О БК К

О! вот я вторым пользовался по-моему.
ЗЫ: И что, реально есть люди, которые то, что там выше написанно за 12К гривен делают? Я вот помню админу пришедшему мне на смену то ли 300 то ли 500 бакинских обещали, а у нас работы было на порядок меньше.

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

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

Саме так. Ну нічо, треба ще трохи почекати. 8-)

Да, мой фейл.
Последний раз клещи обжимные прошлой зимой в руках держал.

в обоих случаях перепутаны первые два провода. Начинать нужно с Б?

коллеги :) у меня тоже была похожая работа, правда в рамках одного офиса))

Что-то непонятное очень. Десять-двенадцать штук баксов конечно цифра интересная, но ИМХО, тут вместо одного человека на такие деньги лучше взять отряд их эникеев на баксов 800-900 и еще останется бюджет.

Бггг, 😂😂😂😂😂🤣🤣🤣🤣🤣😁😁😁

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

Ну, вимог для добротного енікейщіка з досвідом 7-10 років, з зачатками сисадміна і/або програміста — тут більше упор на його комунікабельність і широту кругозору (зараз модне слово — софт скіли), а також відповідальність.
Враховуючи власне відповідальність, з/п має бути від 25к-30к і з перспективою росту або преміями. Проф росту не світить, хіба з такого чувака виросте непоганий ПМ, якщо звьоздну хворобоу не вхопить.

Мінуси: така людина сильно ризикує стати «незамінною» — це как би і плюс, тебе всі люблять і бояться з тобою сваритись, але у відпустку реально з ноутом треба їхати.

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

Харьков продолжает радовать.

Тут все ще дуже сильно й від конкретної галузі залежить. Коли я починав працювати, з трьох платформ з якими я мав справу на першій роботі, одна вже вмирала (PalmOS), інші дві також наближалися до свого кінця, хоч ще й не знали про це (Symbian та WinMobile), iPhoneOS тільки-но народжувався, а про Android я тоді й не чув. До Blackberry якось не дійшли тоді руки. Якби я продовжив із мобільною розробкою, то мав би щоденний гемор відслідковувати постійні зміни Android API та версій iOS й тримати руку на пульсі, щоб не залишитись раптом із мертвою технологією. З іншого боку, з часом мене почало затягувати на backend в Linux. Звісно, тут також є певні зміни, але власне Linux існує вже довше ніж Україна, а скільки років таким штукам як UNIX, C/C++ — мені взагалі лячно думати.

Чому у нас не розповсдюджена практика найму розробників-генералістів та коли це зміниться?

На этот вопрос вы сами и ответили — аутсорс. Тут нужны узкие специалисты. И чем дальше, тем уже.

ваші думки стосовно того чи добре бути генералістом, чи краще бути специалістом?

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

Как-то работал в компании. У них в норме было работать на нескольких языках. Я отработал у них и на Salesforce, и на .Net. И никто мне не рубил з/п из-за того, что я .Net не знал на ту з/п, на которую меня брали как Salesforce разработчика. Такая практика была, что товарищи пилили iOS приложения и, одновременно, backend на Salesforce или .Net (смотря какое приложение). Когда звали перебираться в США, то предупреждали, что не факт, что останусь заниматься Salesforce. Может случиться, что и вообще не будет задач по Salesforce.
Лично мне такое разнообразие нравится. Не надоедает то, в чем ты хорош. Покодил на .Net, сделал задачу, понял, что ты никто и звать тебя никак в .Net, и дальше кайфуешь от Salesforce :-)

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

Быть подобными дженералистами в любой профессии могу единицы. Тем более в IT. Даже если ты закончил КПИ с отличием (или Гарвард, или Оксфорд), то это ещё не гарантирует прежде всего тебе самому что ты вытянишь быструю смену технологии, парадигмы или подхода. Да, многие вещи в айти похожи (на абстрактном уровне), но посади энтерпрайз джавера за разработку андроид приложения и он с большой долей вероятности напишет г****о, а если таких спецов не много, то и просить они будут дофига и больше. Почему? Потому что могут и потому что они одни со своими финансовыми замашками будут обходится клиенту дешевле, чем отдельные спецы.

но посади энтерпрайз джавера за разработку андроид приложения

Но-но-но, давайте не мішати бекенд і фронтенд (веб та мобільний).

Я більше мав наувазі роботу на різних платформах в рамках одного напрямку—бекенд на джаві, на го, на пістоні, на рубі, на похапе і тд. Фронт на js, на тайпскріпті, на кложурі, на елмі, реакт, преакт, ванілла, ангуляр, вує і тд.
З фронтендом все складно але і зараз шукають реакт девелоперів хоча в принципі адекватний мен який шарить js та верстку спокійно розбереться з мільоном ліб для фронта.

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

Фронт на js, на тайпскріпті, на кложурі, на елмі, реакт, преакт, ванілла, ангуляр, вує

сейчас это примерные требования на джуниор фронтент

Я значно частіше стикався з лайном в коді від людей, які працювали в одному стеку роками (якщо бути точним, 7-10 років). Просто тому що вони з року в рік вирішували проблеми одним єдиним чином. Так, вони знали нутрощі свого стеку на 100%. Але потім приходив нормальний дженераліст, спрощував архітектуру так, що частина проблем, які спеціаліст героїчно вирішував доскональними знаннями свого стеку, не виникали by design. Просто генераліст десь на іншому стеку бачив як вирішується схожа проблема і запозичив адаптоване рішення для поточного стеку. Спеціалісти в даному випадку були як стара собака, яку новим трюкам вже не навчиш. І в long term з точки зору проекту це була набагато більша проблема ніж дитячі помилки при переході людини на новий стек. Звісно, це працює не в усіх галузях: тут десь згадували DBA де дійсно багато нюансів.
До речі, з бекенд-мобайл розробкою в одній людині теж цікаво. Я не кажу, що варто саджати бекендщика писати мобайл. Але я вам гарантую, що сіньйор бекендщик, який хоча б трохи нюхав мобільну розробку буде набагато краще працювати у зв’язці з мобільщиками ніж той, що не нюхав. Просто тому, що розуміє хоча б поверхнево нюанси, які важливі користувачами його API і враховує їх при проектуванні систем. Працювати в команді з людиною, яка без слів розуміє, що тобі від неї потрібно і у вас є спільні точки дотику — це priceless.

Що саме? :)

Хіба ти не про це говорив?

Не тільки, але і про це в тому числі :)

ЄЖБ 3.1

перехрестився

—ваші думки стосовно того чи добре бути генералістом, чи краще бути специалістом?

— Лоторея! На 100 сіві зі стеком дженераліста, 99 будуть зі знаннями рівня хеловорд по більшості слів в стеку. Навпаки та ж хрінь: шукаєш вакансію дженераліста, в описі мільйон базвордів/крутих технологій, на практиці ж гівно мамонта розгрібати. Зі свого досвіду можу сказати що є компанії які наймають вузькоспеціалізованого розробника але дозволяют сувати свого носа в інші технології на проекті, отже по факту можеш бути дженералістом, за умови що твоя частка роботи виконується якісно і швидко.

99 будуть зі знаннями рівня хеловорд по більшості слів в стеку

Та ладно, якщо мен вже 10 років працює і встиг по 3-4 роки приділити кожній технології?
До того ж думаю ви погодитеся що якщо знаєш дві платформи/екосистеми, то третя з того ж напрямку дається простіше, а четверта взагалі на халяву.

Приклад—знаете java, шарите бекенд, вчите Django там у вас вже є розуміння як працюють динамічні мови та MVC на них, Rails для вас буде вже значно простіший а Laravel після того взагалі видасться дитсадком. Хоча це все різні мови, але концепції в них схожі.

Приклад—знаете java, шарите бекенд, вчите Django там у вас вже є розуміння як працюють динамічні мови та MVC на них, Rails для вас буде вже значно простіший а Laravel після того взагалі видасться дитсадком.

Зачем учить Джанго? Знаете джава, шарите БЕ, читаете вменяемое овервью по рейлс и вперед.
Если работа заключается в организации скейлинга, или реализации сложной бизнес-логики, или интеграции с определенного рода внешними системами, то тут вреймворк для КРУД особого значения не имеет.
Если же работа состоит в использовании фремворка (например делать КРУД), то вы будете менее эффективны чем человек который плотно работает работает с фреймворком в последнее время. Это произойдет просто потому что у вас будет меньше актуального опыта с определенным тулом.

Та ладно, якщо мен вже 10 років працює і встиг по 3-4 роки приділити кожній технології?

А не окажется ли потом что ваши знания полученые 6-8 лет назад уже не актуальны? Как бы вы посмотрели на человека который спринг конфигурит через ХМЛ?

Как бы вы посмотрели на человека который спринг конфигурит через ХМЛ?

Потиснув би йому руку. Стара школа. До речі, на мою думку, конфігурація через XML не є великим злом, натомість має свої переваги.

До речі, на мою думку, конфігурація через XML не є великим злом, натомість має свої переваги.

В теории да, на практике бывает стандатрное решение с одной стороны и гемор от выбора нестандартного решения с другой. А конфигурация — это не то место где гемор оправдан или даже допустим.

якщо мен вже 10 років

ну це радше отой 1 відсоток, та й то не факт.

Приклад—знаете java

я не заперечую що це можливо. Я скоріш акцентую увагу на тому, що чим більше фулстекових базвордів в сіві кандидата чи опису вакансії, тим важче провести метч хотєлок кандидата і його вмінь до хотєлок компанії і реальних проектів які будуть йому запропоновані. Я думаю шо якщо випаде такий метч то це щастя для кандидата і для компанії, але ж ми знаємо що це трапляється раз на мільйон! Інакше ви би не створювали цей топік))

Років десять тому я звів спеціалізацію до одної CMS — я знав її вздовж та впоперек. Але за 10 років вона трошка набридла... Я витратив свій час і почав практикувати ще кілька мов, змінив спеціалізацію з розробника на операції. Вивчив (але маю визнати не дотягуючи до рівня інтермідіейт) нової специфіки — але розумію що людям таки для аутсорса потрібні ті хто знає їх стек (ну все як в писали). Що далі? Звужую те що знаю, наразі, до інтермідіейта (лише CI — Jenkins, деплой Kubernetes, serverless AWS lambda та кублесс Kubeless). І я не сиджу в зоні комфорту — це аж ніяк... Чи знайду я нову роботу, як девопс з таким стеком? Ну, час покаже. Вакансії на цікаві місця, де можна розвиватись — вони не тільки в Україні є.

З.И.
я два тижня тому проходив інтервю в одній компанії, після чого надибав відео людини (head of devops) що мене інтервювавла — про те — що сенйорний девопс має знати як мінімум 3 клодних оточення (саме «клодних» — він так клауд/cloud вимовляє). Я досі, не маю фідбека з того інтервю — але знати 3 клауда (на пристойному рівні це треба паралельно на вісх трьох клаудах працювати — що є нонсенсом дл я 99% devops’ів (ну хіба вам пофігу на свій work/life balance)) — анріал. З іншої строни я трошка попрацював з AWS на пристойном рівні і пройшов ще курс з CGP (overview), але я наврядчи можу стверджувати що ЗНАЮ 2 клауда, ба навіть 1. Вимоги, кароче, у людей різні — і залежать. не тільки від замовника аутсорса, але і від тараканів в їх головах.

Я досі, не маю фідбука з того інтервю

Ахаха, «мы вам перезвоним», класика.

ну мені перезвонили. фідбека не дали, але перезвонили.

Тю блін, так то й був фідбек, ні? «Ви нам не підходите».

Я прийшов з стеком клаудних технологій на позицію людини що працює з AWS, на співбесіді виявилось що їм потбрібен білд інженер з знанням шефа і все буде on-premise. Коли почалась співбесіда, я звернув увагу на це — але мого співрозмовника то мало хвилювало, я розслабився і просто розказував що знаю. Пізніше до нас приєднався ще один інтервюєр і вже він по мому стеку задавав питання, що він робив на тому інтервю я хз, але його фідбек про мене як спеціаліста — був цікавий. Позиція сама по собі, мені була мало цікава без клауда.

Я тобі можу сказати, що

що сенйорний девопс має знати як мінімум 3 клодних оточення (саме «клодних» — він так клауд/cloud вимовляє).

є х.ньою рідкісною, оскільки кожне з цих паблік клаудів має такий банч всіляких опцій, що всі їх пам’ятати неможливо.Фізично неможливо. От до них, до речі, повністю підходить дженералізм, як такий.Знаєш принципи праці — вивчиш те, що треба. А ще є гарна опція побудови хайбрід клауд — це коли приватну хмарку сполучаєш з пабліком — от цікаво, чи той хєр працював з тими опціями ?
Реально там таргани.

Вони ж ще й змінюються ці «клоди» з часом. Який це бардак має бути на попередньому місці роботи людини, щоб вона «знала» три різних оточення водночас?

Та й мені дивно. Значить там такі «архітектурні» рішення були,що за них руки повідбивати треба.

На галерах — люди можуть міняти клауд в залежності від проекту, це цілком можливо. Але поглиблені знаня навіть в такому варіанті — це на рівні фантастики, ІМХО.

Саме поглиблені. Досконально знати 3 постійно змінюючихся велетенські продукти...

Клауд-інженер — це вже нині зовсім окрема спеціальність. Вона дещо нагадує сисадмінство, але в потужному вендор-локінгу. Свого часу мав справу з AWS але потім вискочив з того чисто з естетичних міркувань. Можливо, років через 10 AWS/CGP мутують у щось осмислене, але поки що навіть у гугла всі потуги звести сисадмінство до мишкування по вебморді закінчилися веб-консоллю з куцою командною строчкою. Ніякого бажання вивчати вінегрет з /bin та /sbin, що його запхнули у `gcloud`, нема.

Хм, я мав справу з vmware тобто я розумію нижній рівень того,з чого зібрані ті всі паблік клауди, а от більш-менш вивчати я зараз можу лише AWS, бо воно найлогічніше. Гугл — щось страшне. Опенстек — то теж. DO та А — тільки як треба буде з ними працювати.

Найсмішніше те, що в клаудах нема нічогісінько нового. В тому чи іншому вигляді парадигма існує ще з часів IBM/360. І все зводиться або до паравіртуалізації заліза, або до ізоляції оточення в певному середовищі. Перший варіаант клаудний бізнес мало цікавить, бо не дозволяє вендорлочити клієнта — залізо має бути стандартним всюди. А другий варіант доводиться робити максимально екзотичним та помороченим, аби міграція до конкурентів була неможливою. Так що всі проблеми викликані не об’єктивними складнощами реалізації клаудів, а виключно намаганнями взяти клієнта на кукан. Тому, власне, я з тим зав’язав.

В контексті того виступу «три клода» це була вимога до Senior позиції. Але такі люди бувають (проекти міняються і людина розширює свої знання) — єдине що, як на мене це рідкість і для Lead’ів, не кажучи про Senior’ські позиції.

Як на мене воно ніяк не пов’язане із senior / lead -істістю. Продукти постійно змінюються, голова постійно заповнюється чимось новим і якщо ти кілька років назад працював із чимось й припинив, то знання продукту будуть на рівні «в загальних рисах». Мультиплатформені проєкти і міграції хоча й існують, але в цілому мати кілька різних публічних клавдів на одному проєкті це щось нетипове й в більшості випадків ненормальне.

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

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

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

-Официант!! Что вы мне принесли?!?! Это кофе или чай?
— А вы отличить не можете?
-Нет!!!
— Тогда какая вам разница??

Хочете покращити рівень програмістів — запропонуйте їм підтягти математику

Ну так я про це і кажу, але чомусь перевіряють навпаки, знання конкретно взятого Спрінг Буту версії 2.0.3.

Сеньорний чувак буде писати більш менш норм код і на пістоні і на всьому іншому. Принципи хорошого коду, вони приблизно на всіх мовах однакової парадигми схожі.
Звісно що складно буде сходу пересісти з процідурного пістону на функціональщину, тут вже треба буде витратити більше часу.

От технологии зависит, чтобы выйти на senior level в:
Go, Python, Ruby, PHP — нужно где-то полгода.
Java/C# - год
C++ — целой жизни не хватит.
Scala — примерно столько же сколько ждать тепловую смерть вселенной.
Haskell — примерно столько же, как время возврата Пуанкаре для массы видимой Вселенной.

совпаденіє?

не думаю ©

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

Може то просто програмісти погані були? Не дуже досвічені, наприклад.

Seniorus Vulgaris.

Та в тому й річ, що ступінь тяжкості болячки під назвою «я могу на любом языке программирования писать как на ФОРТРАНЕ» ©[А.Голуб] залежить не стільки від рівня загального розвитку та широти світогляду, скільки від набутих під конкретну технологію звичок, набитості руки, якщо завгодно, та від банального бажання переналаштовуватися, якого з досвідом та часом у більшості розробників все менше й менше.

То ж тільки у рожево-ванільних фантазіях багатьох викладачів наших ВНЗ, головне — «осягнути фундаментальні знання» та «навчитися вчитися», а «на чому писати — діло десяте». Воно і так, але й ні; коли навчені із використанням такого підходу «генії» починають строчити лінійно-макаронний буллщіт з got’ами та щиро не розуміють, — «а шо не так?!», — стає лячно і смішно водночас.