Комментарии 258
Что нужно знать, чтобы быть синьором?
Достаточно хорошо знать проект на котором работаешь
А что нужно знать, чтобы быть в состоянии понять проект?
А это зависит от проекта.
А можно ли выделить базовый набор навыков/знаний, чтобы зависимость от проекта минимизировать или вообще заменить зависимостью от предметной области? То есть не под каждый новый проект требования придумывать, а использовать одни и те же, которые закроют бОльшую часть случаев?
Проблема в том, что нельзя. У меня не то, что бы прям большой опыт (где-то 6 лет), но я уже успел побывать на разных проектах. Часть из них требовала просто несколько недель онбординга, что бы человек начинал писать код, часть из них была построена так, что серьезное знание предметной области требовалось только от одного человека, а часть их них содержала только знания предметной области.
Разумеется, если вы строете проект и у вас хватает возможности проконтроллировать все, то у вас может и получится. Но синьор вроде не строит проекты, он на них работает.
Я уже лет пять работаю вот примерно в таких же проектах, где нужно погружение в предметную область, но вот чем больше работаю, тем больше прихожу к мысли, что необходимость прям сииильного погружения в предметную область возникает, если либо процессы выстроены неправильно, либо собственно сама архитектура проекта построена так, что не понимая всего ты не можешь понять частности.
Правда как бороться с этим в состоянии вечных дедлайнов не особо понятно(
Ну это уж точно не ОСи, деревянные pid'ы и ключики к sed...
Достаточно долго на нем работать
Достаточно для чего? Для того, чтобы трястись за свое место, пока не придет "молодой и удалой" заместо тебя?)
Судя по количеству перечисленного, для того, чтобы одному выполнять функции целой команды.
А что в этом плохого? Нынче, много знать и уметь уже зазорно? Или обидно, что за такой широкий спектр работ не будут доплачивать? Кто же мешает отстаивать свои убеждения и привлекать упомянутого в тексте "продажника", чтобы труды за команду оплачивались сообразно результату, а не кол-ву человек, выполнявших работу?
Так и появляются синьоры и архитекторы "одного проекта", лиды и ПМы одного департамента.
Синьор 1 проекта, это вовсе не синьор в широком смысле. Если пройти весь проект с нуля то по твоему выходит целая команда синьоров получится.
Но по факту на других технологиях и других ЯП все они могут оказаться джунами.
вот поэтому и существует такое понятие как "матрица компетентности" (https://github.com/omreps/programmer-competency-matrix), чтобы понять кем твой коллега является
Ну это вы путаете сеньорность и ключевая позиция на проекте.
Сидя на одном проекте, можно не понять что может быть иначе. Потому что по верхам ты может быть и почитаешь но без нюансов - нет, а в нюансах весь смысл.
И при смене проекта или даже работы такой сениор автоматически снова становится джуном? Или как?
и не выгореть на этом проекте...
А что тогда нужно знать архитектору, если он еще круче чем сеньйор?
Просто не совсем понятно, зачем детально расписывать сети и настройки веб-серверов, но вот файловым системам указана лишь одна строчка. А как же знать форматы файловых систем, как работает форматирование и так далее. Чем файловые системы хуже сетей?
Вся статья похожа на небольшую суммаризацию автора на тему "что болит", чем на реальный разбор.
Ибо, например, после Си любой иной язык - это очень просто.
Ну и это да. Си простой язык, просто небезопасный.
По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления. У архитектора категории глобальнее, а у синьора-разработчика душа больше болит за реализацию и её нюансы. То есть один больше любит придумывать и задавать общую форму, а второй больше любит оживлять эту форму и додумывать детали.
В небезопасности же и есть вся суть. Если ты знаешь что там под капотом, почему оно сделано именно так и какова цена "небезопасности", то более разумно используешь все прочие инструменты.
В небезопасности же и есть вся суть. Если ты знаешь что там под капотом, почему оно сделано именно так и какова цена "небезопасности", то более разумно используешь все прочие инструменты.
И тут из-за угла выглядывает rust.
Это как говорить, что электрик, который долго прокладывает проводку без средств безопасности круче того, кто почему-то считает неплохой идеей соблюдать ТБ. Си такой не потому, что это самое крутое решение, это было просто самое крутое решение на тот момент.
К тому же Си очень разный. Человек может всю жизнь клепать микроконтролерры на Си и считать себя офигеть каким специалистом, а потом ему приходится сесть за какую-то Scala или Rust и оказывается, что прямое управление памятью это не сложно.
Ну и да, никто не умеет безопасно писать Си. История еще не знает таких случаев.
По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления. У архитектора категории глобальнее, а у синьора-разработчика душа больше болит за реализацию и её нюансы. То есть один больше любит придумывать и задавать общую форму, а второй больше любит оживлять эту форму и додумывать детали.
Тогда зачем синьору глобальные познания в архитектуре?
Ну и да, никто не умеет безопасно писать Си. История еще не знает таких случаев.
Boost нервно курит в сторонке...
Помимо того факта, что Boost это все-таки С++, не совсем ясно, почему он курит в сторонке.
Помимо того факта, что Boost это все-таки С++
Понятно, что C++ - отдельный ЯП, но обычно, когда говорят C, то подразумевают и C++. Зачм использовать в 2022г чистый C - мне не очень понятно.
не совсем ясно, почему он курит в сторонке.
Как мило. Ну в таком случае, история вообще не знает безопасной разработки софта. Вообще на любом ЯП. Под безопасной разработкой в контексте С подразумевается безопасная работа с указателями. Ну так Boost и решает эту проблему. Да, это не язык со сборщиком мусора, но тем не менее.
Понятно, что C++ - отдельный ЯП, но обычно, когда говорят C, то подразумевают и C++. Зачм использовать в 2022г чистый C - мне не очень понятно.
Абсолютно за те же, зачем использую С++ в 2022 году, когда есть куча более полезных языков. Ну и это очень странная позиция "говорят про одно, подразумевают другое", мы тут в сообществе программистов или HR?
Как мило. Ну в таком случае, история вообще не знает безопасной
разработки софта. Вообще на любом ЯП. Под безопасной разработкой в
контексте С подразумевается безопасная работа с указателями.
Boost "решает" эту проблему так же, как и любой другой способ навернуть умных указателей. То есть он закрывает довольно узкую прослойку проблем, а куча других остается. Ну и как бы, решение проблемы снаружи языка всегда решают проблему довольно фрагментировано. Приходится использовать либу, которая решила не подключать boost? Добро пожаловать в проблемы.
кстати, там есть мелкая ошибка в предложенном решении
неужели лишний constexpr ?
эээ .. почему именно он ? или почему лишний ?
хм, рискну предположить, что т.к. он вычисляется во время компиляции, то и результат будет храниться где-то отдельно от данных, вычисленных во время запуска.
Еще возможен вариант, что туда передадут вызов не constexpr функции, что тоже будет нехорошо ...
(и вообще на constexpr куча ограничений наложено)
И тут из-за угла выглядывает rust.
Давно уже активно машет клешнями))
--По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления.
Архитектор выше. Если это вкладывать в "круче" - то да, круче.
То, что описано в статье - это не синьор, даже образца 2008г в США. Это Expert \ Principal. Синьору достаточно уметь менторить и делать систему с нуля \ улучшать текущую в меру своих сил. В противовес миддлу, который просто не нуждается в контроле при работе в стриме, опредленном более опытными товарищами.
С - прозрачный, С++ - небезопасный.
Чем отличается архитектор сарая от строителя сарая? Да ничем, строитель плюс-минус сможет сараи и без архитектора возводить и даже импровизировать (безопасно для заказчика) для разных животных/инструментов. Может даже себя называть архитектор, или строитель-архитектор, и это без нотки иронии, ведь такой строитель может принимать заказы на сараи любой сложности через десяток лет.
Чем отличается архитектор Бурдж-Халифа от его строителя? Разница вполне очевидно, что пропасть. Строитель небоскреба не в состоянии спроектировать и построить небоскреб, даже если ему дать бесконечно денег при условии, что он будет самым умным на проекте. А если сможет и какая-то QA группа подтвердит, что небоскребы по качеству идентичны, значит строитель на самом деле известный архитектор, а кирпичи для души кладет =)
Для простых проектов никакой архитектор не нужен
Использовать наработки это не проблема, однако только настоящий архитектор обладает фундаментальными знаниями, чтобы перед началом строительства выбрать правильную наработку, надо изучить ветра, климат в общем, породу на которой небоскреб будет стоять, все коммуникациии и тд. Все это требует огромных знаний итподготовительных работ. И целой группы архитекторов. И только потом они возьмут и с заказчиком утвердят давно залежавшую со студенчиских времен проект.
Что должен знать и уметь старший разработчик-исполнитель? Кем он должен быть?
Он должен быть менеджером. (Управлять людьми, планировать(функция менеджмента по учебнику), уметь в риск менеджмент.)
Удобно, чё. И код пишет в промышленных масштабах и рулит-разруливает. А ЗП та же. Плюс еще с клиентом бухает как sales. Очень удобно.
А кто сказал что ЗП та же? Мне кажется, прокачка навыков должна вести к увеличению полезного выхлопа, а он, в свою очередь, к улучшению благосостояния и дохода. Если это не так, то надо бы подопнуть соответствующего дядю/тётю и обсудить условия труда. К работе за еду в условиях "денег нет, но вы держитесь" в статье ни коим образом не призывается.
Мне кажется, прокачка навыков должна вести к увеличению полезного выхлопа,
У позиции старшего работчика есть определенный потолок полезного выхлопа, который он на этой позиции перепрыгнуть не может (если ему не повезет с хорошим менеджментом). И очень часто этот потолок наступает до того, как будут все знания в статье усвоены.
Ну это всё равно что сказать, я тут сижу в деревне Гадюкино, у нас тут электричества нет, не то, что программисты какие-то требуются, а вы тут своей статьей 10к$ обещали. Просто это логично, если вы делаете сайт-визитку со 100 уников в день, то и расти не будете, да и платить вам не за что 10к$ Тут надо проявлять какую-то инициативу непосредственно самому разработчику, искать другую работу, попробовать перевестись в другую команду, поискать челенджевые задания, поинтересоваться бизнесом, возможно придумать как бизнесу заработать денег с помощью своей идеи. Сама статья - помощь, как вы можете стать эффективнее и продать себя подороже, а не туториал по получению 10к баксов.
Даже вне рамок сайтов-визиток, значительная часть того, что тут написана вполне может привести к overqualified для синьор позиции для большей части рынка.
Предлагаю решать проблемы по мере их поступления. Ни разу в жизни пока не сталкивался с overqualified "проблемой" на рынке… а очень хотелось бы!
хз OverQualified на мой взгляд может возникнуть только в ситуации, когда вы по деньгам не стыкуетесь. Причём чаще всего - платить хотите за одно, часть навыков задвинув, а потом по-тихому их тоже подключить, хотя раньше они не требовались.
А так мне кажется это больше красивое слово, когда вы по навыкам не стыкуетесь с командой/проектом
Так он на то и большой и главный, если где-то что-то вдруг, то может спокойненько копать и находить проблему, а не долго и муторно выяснять, что оказывается всего-то прав на файлике не хватило. Да и наличие кругозора больше нужно для какого-то понимания, а как это внутри работает, чтобы лучше связи видеть.
Ну это на мой взгляд)
А чем отличается "спокойно копать и находить" от "долго и муторно выяснять"?
наверное, я как-то слишком образно выразился, но суть в том, что сеньор может ограничить некий круг наиболее вероятных проблем, которые могли приветси к такому результату и их перебирать. Причём для каждой проблемы у него в голове может быть сценарий воспроизведения примерный.
Специалисты же имеющие меньший кругозор могут "долго и муторно" перебирать все возможные ситуации и сценарии, либо просто не суметь предположить ничего.
К уменьшению это приведет. К гадалке не ходи.
Как называется менеджер без прав на организацию, мотивацию, координацию, планирование и контроль?
Три буквы...
А когда обеденный перерыв, так и сеть настроит ))
В целом верно, только не пять, лет а скорее десять.
За это время разработчик уже успевает пережить одну смену основного языка/платформы и ко всем инструментам начинает относится гораздо спокойнее. В виде - хотите, например, Clickhouse/Mongo/... ? - давайте почитаем, может вам поможет. Появилась год-два назад? - подождем еще пару лет, пока отладят, допялят и остальные на ней шишки набьют. Очень хотите? - ну ладно давайте настроим, но вот так это скажется на бюжете разработки и развертывания. Все еще хотите? - ладно ищите человека который будет за это отвечать, а я пока попробую сам по мануалам развернуть и настроить.
В разработке он уже не боится легаси, т.к. знает, что после 2-3 лет работы на проекте - даже его код, для него же самого уже легаси. И чтобы этого избежать нужно либо работать над проектами, которые и не предполагается запускать - сделали отчитались -> выкинули, либо быстро напили и скипнули пока не догнали - работу же менять каждые год-два надо.. Поэтому он не прячется за модное слово техдолг, и как только он накапливается переходит к режиму скипнуть, а настаивает на непрекрашающеся переработке проекта по частям с самого начала.
А в используемых инструментах сеньор уже во многом знает как делать не надо не смотря на то, что так в нескольких умных книжках написано, а где не знает - там уже одним местом чувствует.
А менять работу он не горит желанием, потому что он уже нашел место, где ему интересно, его ценят, и денег ему хватает - не много-много, больше всех, плюс опционы, и майбах не парковке, что кажется целью джунам, а именно достаточно. Именно эти ощущения вместе его на месте и держат.
Мой дед работал начальником электромонтажного участка. Однажды я его спросил, сколько нужно времени, чтобы вырос зрелый специалист. Десять лет. Ответил не задумываясь.
По моему это описание больше похоже на сеньора, чем в статье :-)
Особенно "знает как делать не надо не смотря на то, что так в нескольких умных книжках написано".
А ещё иногда сделать, как надо, хотя в умных книжках написано так не делать. Например 3 нормальную форму нарушить.
вы по софт-скиллам не прошли
Дело не в религиозной ненавести. awk и sed довольно нишевые тулы, которые используются раз в столетие и очень быстро забываются. В добавок, они имеют довольно необычный синтаксис и в итоге, что бы понять, что делает команда написанная недели три назад тратится столько времени, что проще переписать на любой другой язык.
Если у вас в команде хотя бы несколько человек на постоянке используют awk, то ситуация конечно другая.
PS: Ну и да, bash-скриптов на продакшене существовать не должно, имхо.
И это давало мне очень хороший эффект, без всяких исключений — то есть, сколько переписал, столько раз эффект положительный. Сокращение размеров кода в два раза, например. В сочетании с лучшим пониманием кода коллегами — т.е. кроме меня после переписывания все видят, что он делает, и понимают почему. Причем порой еще и функциональность расширялась попутно.
Но вас я тоже вполне могу понять — потому что писать все же нужно на том, что ты хорошо знаешь. Ну и назначение кода конечно важно — потому что если вы вовсе не сопровождаете написанное, или делаете это один, это не такой же случай, как если в этих баш скриптах будет часто копаться еще кто-то (с другим набором знаний).
ненависть ни при чем. Табуреткой бить = плохие софт скилы
Ну вот решили мы кого-то демотивировать, не нравятся нам его методы по внедрению awk в проект. Стукнули его табуреткой (опустим на время вопрос, удобно ли именно табуретку с этой целью употреблять, или можно стулом), и он не просто выжил, но и стал сильным разработчиком. То есть это сработало. Это хороший софт скилл? Или надо сначала сравнить с другими методами демотивации, типа лишения премии?
:)
ну так и оцениваю. Мягко - значит софт. Нет - значит не софт. Вот обитая табуретка - наверное, софт. А простая деревянная - не софт. Все просто ж.
а по существу
не нравятся нам его методы по внедрению awk в проект
кому-то не нравятся ваши методы по внедрению $TECH_NAME в проект - все, файт табуретками. Потому и нужно софт
Если для решения задачи нужно иногда устроить конфликт (а потом успешно разрешить) — то чем умение это сделать не гибкий скилл? Не самый лучший и не самый широко используемый — но вполне себе инструмент для некоторых ситуаций.
не всякий конфликт можно разрешить, не всякий конфликт стоит устраивать. Он и сам собой прекрасно возникнет. По моему опыту, чаще достаточно определить свою(!) зону ответственности, и почвы для конфликта становится меньше.
Если взять приведенный пример "мне не нравится, как коллега (?) делает Х" - то если разобраться, почвы для конфликта тут нет. Мне может не нравиться, а начальство устраивать, тогда все ок. Начальство может не устраивать - тогда тоже все ок, так как это не мое дело. Мне может не нравиться вычищать баги в этом X - тогда тоже нет почвы для конфликта, просто обрисовываем начальству, начальство разбирается, так как по мнению начальства может быть все ок и еще может быть так, что чего-то не знаю я. Если мы и есть начальство, и нам не нравится, как подчиненный делает X и что подчиненный использует - ок, как один из вариантов, делаем как надо, убеждаемся, что так лучше, убеждаемся, что использованный инструмент разрешен к применению и не противоречит политикам, вводим как стандарт и ставим задачу на переделать как надо, конфликтовать тут тоже негде.
Ну да, в этом конкретном случае — нет конечно. Когда речь об инструментах, где эффект можно измерять, обычно проще убедить. И эффективнее тоже.
Я тут скорее о более общей теме — почему умение применять жесткие (но эффективные) меры не является софт скиллом? Причем понимание того, когда их стоит применять, а когда нет — тоже часть умения. Конфликт не по серьезному поводу реально устраивать не стоит — слишком быстро пропадет эффект, если применять сильные средства каждый день.
"Николай ненавидел все, что запускается из-под шелла. А все, что не запускается, он запускал из-под cygwin-а и нненавидел"
(c) (откуда-то)
Ненависти нет. Есть опыт хождения по собственноручно наделаным скриптам с регулярками, которые долго работали нормально, но потом перестали. Второй раз было интересно когда пачку старых заборов из sed нужно было объяснить ньюкамеру. Это хорошие инстументы чтобы раз от разу что-то сделать прямо сейчас на проекте где кроме автора больше никого нет.
Табуреткой - это hard-skill же.
По-моему, автор описал вещи, которые кажутся полезными лично ему, и описал своего личного "идеального специалиста в вакууме". А правда на самом деле простая: правды нет, лычка ничего не значит вне контекста компании, в которой вы работаете.
Бывают синьоры с 4.5-5 лет стажа, которые переходят потом в компанию поинтереснее джунами с повышением в зарплате.
А если по тексту статьи, то, гм, понты-то хорошие, но по сути я далеко не со всей конкретикой согласен.
Сети:
некоторые мысли про альтернативы вида ARP и далее разворачиваться в пышное повествование о сборке пакета, вложениях пакетиков один в другой, порты, фрагментацию, способы передачи на разных уровнях
Вы, конечно, извините, но человеку, занимающемуся прикладной веб-разработкой (и да, разработчик микроконтроллеров, низкоуровневый системный разработчик и просто веб-бэкэндер - это три очень разных человека, которым нужен очень разный набор знаний), это всё по большей части ни к чему - а я не думаю, что кто-то станет спорить с тем, что прикладная веб-разработка - одна из самых многочисленных сфер в коммерческой разработке ПО. TCP/IP-стэк с его соседями вроде UDP, модель OSI (и почему это дырявая абстракция, которая разваливается на ходу при внимательном рассмотрении даже самых популярных примеров)? Да, хорошо. Эзотерические альтернативы, которые не пригодятся 99,999% публики? Ну, я за вас рад, но не надо.
NAT<...> зачем он может пригодиться при организации внутренней сети. Как туда втиснуть туннели, как выборочно завернуть трафик в них
Опять же, не надо превращать прикладного разработчика в (хорошего) системного администратора, это разные люди. Если вы занимаетесь инфрой или системным программированием, вам эти знания нужны, да, но тут мы вернёмся к моему тезису выше: не надо искать универсальные ответы там, где их нет, скатываемся в абсурд.
Оси:
завимости разрулить, из исходников чего собрать без прямого make install, посмортеть какие либы к бинарю прилинкованы, быть в курсе про strace и wireshark, не бояться демонов во всём их многообразии,
Не надо в 2022 писать прикладной софт на языках, где make install - популярный инструмент сборки, пожалуйста, людям потом это поддерживать зачем-то придётся. Хочется чего-то простого и легковесного - хотя бы перейдите на Golang, он, конечно, отвратителен как язык, но хотя бы не придётся искать, кто забыл память освободить.
Разбираться (ну то есть прям разбираться, а не знать, что она в принципе происходит) в линковке библиотек к бинарникам в современных языках при деплоях примерно чего угодно в докер - тоже избыточность, если надо сделать это раз в 5 лет (а мне ни разу не надо было в диапазоне языков от го и джавы любой давности до тайпскрипта, например) - прекрасно заменяется умением гуглить.
Я бы сказал, что это мало. Тут ни пересборки ядра, ни процесса загрузки ОС, ни
awk+sed, ни всякихnspawnи прочих инструментов для виртуализации, ни узкоспециализированных бинарей.
awk+sed - как религия и половые органы: иметь и пользоваться можно, остальным рассказывать и тем более агитировать посмотреть не одобряется. :)
Остальное, опять же, нужно только в узких сферах, не проецируйте это на всех. Ваше "мало" - это слишком много в общем случае, а "не мало", видимо, было бы абсурдно много. :)
Хранилища:
На удивление, по большей части согласен - там в принципе общий кругозор, но
Знать SQL и хотя бы один его диалект, подозревать о иных языках запросов
Как бэкэндер говорю - если это не имеет отношения к вашей специализации - и я продолжаю утверждать, что специализация как минимум в сфере разработки (заметьте, не языке, а сфере) важна и игнорировать её в таких вопросах нельзя - забейте вы хер на этот SQL (и уж тем более думать о его диалектах). Мне совершенно плевать, будет ли фронтэндер или разработчик ядра ОС/прошивок микроконтроллеров знать SQL, это такая же ненужная конкретика, как бэкэндеру разбираться в реакте или фронтэндеру в AWS.
Программирование:
после Си любой иной язык - это очень просто
Очень смешное утверждение, спасибо.
На большинство си-подобных по синтаксису языков действительно просто начать писать после него, вот только если у вас освоение языка заканчивается на синтаксисе, то я не уверен, что такое отношение приемлемо даже для джуна, чего там говорить о каких-то гигасеньорах. А научиться писать идиоматичный и тем более продакшн-реди, будучи травмированным Си, скажем, на Котлине, Скале или там Расте, скорее всего только сложнее.
Дальше по большей части ок-норм, но без всякой там конкретики (которой уйма в хардскилловых пунктах), а в ней-то часто все проблемы. :)
Разве что
Кстати, если заметили, во всех вышеозначенных пунктах нет ничего про современные фреймворки, новомодные инструменты, библиотеки с переднего края науки и про прочие свежие и современные вещи. Всё относительно просто, базово и если отмотать лет на 10 назад, то мало что поменяется в повествовании.
Ох попробовали бы вы рассказать кому-нибудь в этакой провинции (не обязательно в прямом смысле, а в смысле подходов в разработке) 10 лет назад про CI/CD, обязательность тестирования и вот это всё. Думается, процентов 80-90 публики вас бы нафиг послало.
обязательность тестирования
Подтверждаю, не знаю как сейчас, но еще лет 7-8 назад я спрашивал у компаний-разработчиков в провинции, где думал работать, используют ли они тесты - отвечали, нет. Интересовался, как же они тогда могут быть уверены, что условная процедура doSomeMagic() делает именно то, что нужно - отвечали, что запускают ПО и смотрят, как работает.
Конечно, ничто не мешает свой код тестами оборачивать, а на чужой плевать, но это цирк будет, в командной разработке-то.
И сейчас много где так, потому что это требует существенных ресурсов, а их всегда не хватает, при этом результат, часто, весьма сомнителен.
Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует. Если вы аппелируете к списку требований, то когда он был настолько полный, чтобы действительно описывать все случаи и комбинации, которые стоит протестировать. А если считаете покрытие по методам/строкам, то цифра вообще перестает что-то значить. Идея про тесты по потоку управления... может быть, когда нибудь. Поэтому все как всегда зависит от разработчика и того, как он понимает достаточность процесса тестирования/отладки.
В чем тесты действительно помогают так это в регрессионке - потому что если отломать что-то двух летней давности, то незаметить это с ними довольно сложно.
Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует
Да, гарантирует что-то только формальная верификация программ, однако это оч сомнительный аргумент в пользу того, чтобы не стараться и улучшить качество кода, и применить инструменты, дающие какую-то оценку качества кода (тесты точно можно отнести ко второму, к первому - обсуждаемо). А не сидеть и ждать silver bullet. :)
Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
При виде того, что могут "серьезного" поймать статистические анализаторы у обычного мидла должны волосы дыбом вставать.Не один и не два раза прогонял один известный тут анализатор на своем коде, который говорил все ок. Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей - прочитайте комментарий ниже - меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Как бы мы не хотели жить в идеальном мире идеального кода приходится опираться на экономическую целесообразность. В начале карьеры, а это было почти 15 лет назад, я работал в конторе, которая писала ПО для банков - вот там тестили и автоматически и вручную вдоль и поперек, и у нас и при приемке очередного релиза уже в банке. Тестирование шло настолько тщательно, что от выполнения релиза до выкатки проходило до месяца (привет непрерывной интеграции и доставке). А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее, и иммитация борьбы за качество кода там не прокатывала.
P.S. И.... все равно иногда на проде косяки ловили
Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
А для улучшения аккуратности внешнего вида человека придумали расчёску, что ж теперь, рубашку не гладить (если вы их носите, конечно), если расчесались? :)
Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей
Если кому-то кажутся - ну, это их проблемы, совершенно очевидно, что ими они не являются в реальных случаях, кмк. Это просто ещё один (ну, точнее, два, если мы статический анализ и тестирование зачем-то в один ряд поставили) инструмент обеспечения качества кода.
меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Простите, что? Это какой-то произвольный набор слов. Ну то есть вы или в чём-то не разобрались, или очень плохо формулируете мысль.
А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее
Спасибо, я знаю, что такое банки (а также знаю, что процессы в них бывают очень и очень разными, это если по секрету).
и иммитация борьбы за качество кода там не прокатывала
Ну, не имитируйте, а боритесь. В том числе автотестами можно.
Я вот тоже не совсем понял предыдущего комментатора, такое ощущение что человек реально не пользовался статическими анализаторами и тестами, сам таким был в свое время, сейчас сижу на проекте с покрытием тестами домена на 100%, остальная ерунда вроде контроллеров не покрывается, да и незачем особо, на git push стоит pre-hook с запуском анализатора и тестов и знаете что? Да это прекрасно и дико удобно, плюс реально повышает читаемость кода и облегчает поддержку
Контроллеры может и да (хотя тоже зависит от, особенно если у вас есть сервисы-клиенты, внешние для вашей команды - я бы призадумался, возможно), но, например, поддерживать и тестировать то, что вы корректно (де)сериализуете объекты запросов-ответов, бывает крайне полезно.
Контроллеры? Что вы, например, не напортачили с тем, какие коды ответов отдаёте (да, это могут быть и примитивненькие сквозные функциональные тесты). Сериализацию? Что имена полей (если мы о джейсонах, например), формат сериализации (а бывает даже так, что сущности одного типа надо по-разному сериализовывать - грубо, где-то вам нужно 2 знака после запятой у числа оставить, а где-то 4) не перепутали. Что дата парсится именно в том формате, в котором надо, если речь о десериализации.
Я чуть ниже ответил, потому займусь самокопипастой (самому неловко так делать):
Я не предлагаю тестить логику библиотеки. Я предлагаю тестить, что вы не нарушили согласованную спецификацию (набор и нейминг полей, их формат), потому что в жизни такое происходит сильно чаще, чем хотелось бы. Особенно если у вас какие-то сложные ДТО.
Сериализация/десериализация делается готовой либой, которая давно покрыта тестами от самого разработчика, по поводу дат и нейминга полей в json - покрывать такое как минимум странно и не особо продуктивно, получается что мы пишем тесты ради тестов. Тесты должны покрывать бизнес-логику, а не парсить json и ругаться если где опечатка в проперти. Вопрос об опечатках решается просто и всего двумя вещами - первая, это апидока, которая автоматом генерируется по responseDto, вторая, это тесты на стороне клиента, сломали апи, у клиента упал функционал на тестах, все, приехали, фиксим. В теории можно конечно покрывать тестами все подряд, можно даже парсит файлы с классами и прогонять чтобы никто не запушил матерно обозванные переменные или методы, но всего один вопрос - а стоит ли оно потраченного времени? Тут главный посыл скорее в том, что надо отделять все же бизнес-логику от данных и контрактов, это немного разные вещи
P.S. Ну и насчет вашего кейса со временем - не надо ничего думать, оперируйте не datetime string, а таймстампами и используйте под капотом utc как на сервере, так и на клиентах, тем более что из utc перегнать в нужную timezone для отображения юзеру не то чтобы большая проблема
Я не предлагаю тестить логику библиотеки. Я предлагаю тестить, что вы не нарушили согласованную спецификацию (набор и нейминг полей, их формат), потому что в жизни такое происходит сильно чаще, чем хотелось бы. Особенно если у вас какие-то сложные ДТО.
И да, бизнес-логика - однозначно не единственное, что нужно тестировать. Потому что бизнес-логика не поможет, если вы начали отдавать не тот код ответа, который согласован в спецификации. :)
первая, это апидока, которая автоматом генерируется по responseDto
Хорошо, если у вас есть стек технологий разработки, который такое полностью бесшовно поддерживает, но это почти никогда не работает, как надо, если логика сериализации сложнее "вот набор полей, подставляй".
вторая, это тесты на стороне клиента, сломали апи, у клиента упал функционал на тестах, все, приехали, фиксим
То есть для того, чтобы вам узнать, что ваш код сломался, кто-то ещё должен увидеть, что сломался его код исключительно по вашей вине. Не много ли промежуточных шагов? :)
(вопрос со звёздочкой - теперь представьте, что ваш клиент - это команда бэкэнд-разработчиков другого сервиса, которые работают в другой стране и другом часовом поясе, и вы сломали им АПИ и пошли на новогодние каникулы, а у них рабочая неделя в это время)
Ну и насчет вашего кейса со временем - не надо ничего думать, оперируйте не datetime string, а таймстампами
Нет, таймстемпы - не серебряная пуля, потому что иногда в том числе клиенту нужно знать таймзону как "контекст" запроса (например, если ваш клиент - не фронтэнд, а другой сервис).
Ну а ещё если вам хоть когда-то приходится дебажить своё АПИ или читать его логи, таймстэмпы категорически хуже.
Ну не знаю, не знаю. Может, в Enterprise всё иначе, но на мелких проектах в один-два кодера.. когда я не ленился и писал тесты, которые проверяли, возвращает ли функция площади квадрата x*x, а периметра - 4*x, то всё было хорошо. А когда по неопытности налетал на заказчика, который требовал работу "вчера" -соответственно, откладывая тесты на завтра - уже через пару месяцев функция площади могла вернуть что угодно, включая бесконечность и Access Violation. И проект превращался в тыкву.
ИМХО, хуже от наличия тестов никогда не бывает, а вот лучше - вполне возможно.
хуже от наличия тестов никогда не бывает
Еще как бывает, тесты ВСЕГДА увеличивают время на обновление функционала. Условно возможно для того чтобы заменить одну строчку в коде — вам придется поправить сотню строчек кода в тестах.
Да, часто это окупается надежностью рефакторинга, но тесты не бесплатны и черзмерное увлечение тестами может приводить к еще более плохому коду, чем их отсутствие.
Вообще, unit test'ы это не про проверку текущего функционала, для разовой проверки, что все работает, можно пройтись с дебагером или просто вывести в консоль результаты работы разных функций.
Основная задача unit test'ов это облегчения добавления нового функционала и рефакторинг или обновление старого. Поэтому unit test'ы не очень нужны для прототипов, unit test'ов должно быть минимальное количество, которое гарантирует надежность рефакторинга, не нужно добавлять тесты на то, что потенциально не может сломаться в будущем или вы гарантировано не будете менять.
просто вывести в консоль результаты работы разных функций.
Я не очень понимаю, как это должно работать. У меня в проекте 10 классов, у каждого класса 10 методов, каждый метод может иметь 10 вариантов параметров - мне нужно просмотреть 1000 строк и сравнить с ожидаемым?
для того чтобы заменить одну строчку в коде — вам придется поправить сотню строчек кода в тестах.
Честно говоря, не могу представить себе эту ситуацию даже теоретически. Худшее, что может быть с кодом - это удаление методов или классов, но даже тут рекомендуется не удалять из кодовой базы, а помечать как устаревший.
потенциально не может сломаться в будущем
В программировании сломаться может всё, что угодно. Я недавно решил опробовать на небольшом учебном проекте VS2019 - и он поломал работу с сишными функциями работы со стандартным потоком. Ну то есть, зуб не дам, что именно поломал (может, напротив, починил) - но один и тот же простенький код в vs2012 и vs2019 работал по-разному.
Возможно, мы просто говорим о разных вещах или с позиций принципиально разного опыта, не буду наставить на своей точке зрения.
У меня в проекте 10 классов, у каждого класса 10 методов, каждый метод может иметь 10 вариантов параметров — мне нужно просмотреть 1000 строк и сравнить с ожидаемым?
А с unit-test''ами вам нужно не просто посмотреть 1000 строк, а заранее их подготовить и написать сравнения каждой строки. Что быстрее (для единоразовой проверки)?
Честно говоря, не могу представить себе эту ситуацию даже теоретически. Худшее, что может быть с кодом — это удаление методов или классов, но даже тут рекомендуется не удалять из кодовой базы, а помечать как устаревший.
Значит у вас классы и логика очень простая, иногда для покрытия одного метода приходится написать сотни строк кода — оберткой того что он принимает, сотни строк для те методы, которые он импортирует, и еще множество методов для проверки результата. Но суть не в этом — даже если не замечаете — исправление unit-test'ов отнимает время.
Худшее, что может быть с кодом — это удаление методов или классов
Худшее, что может быть с кодом это полное изменение всей его бизнес логики. Условно, вы сделали велосипед, потому что решили, что это нужно заказчику, а ему нужна подводная лодка.
В программировании сломаться может всё, что угодно.
Если у вас есть стандартные java геттеры и сеттеры, они, конечно, тоже могут сломаться, но только при таком пушистом и полном писце, что тесты вас уже не спасут. Но вы правы, всегда нужно найти место, где вы должны остановится, так как сломаться может, что угодно, вопрос только в вероятности и цене ошибки. Вы все равно не сможете покрыть тестами 100% весь свой код и все библиотеки, которые используете, и все особенности языка и операционной сиситемы, которые используете,
ничто не мешает свой код тестами оборачивать, а на чужой плевать
На самом деле, если ваш код хоть как-то зависит от чужого внутри, так разве что не хуже: вы не знаете, сломался ваш код как таковой, или какая-то его внутренняя зависимость, где Вася П. из соседней команды что-то напорол.
Понятно, что всё это в 99% случаев в высокоуровневой разработке не нужно, но понимание этих вещей по-хорошему необходимо. В первую очередь для того, чтобы легче поределять возможные узкие места в архитектуре "на глаз" и "пятой точкой". Ну, и в случае возникновении нетривиальной проблемы, чтобы не гуглить сутками на пролёт, а сразу отсекать пласты возможных источников этой проблемы. От себя добавлю, что ещё неплохо было бы иметь минимальный опыт написания програм для микроконтроллеров на языке ассемблера. Это нафиг не надо никому, кроме embedded-разработчиков, зато отлично помогает понять основные принципы работы процессора на практике, плюс скромное понимание того, как на смом деле под капотом может работать любимый метод в любимом фремворке под любимый язык программирования. А то вы тут сидите, и не знаете "где сейчас ваш указатель стека".
Да и в целом знания лишними не бывают, ибо чем больше знаешь, тем больше нейронных связей образуется в мозгу, и тем лучше соображалка соображает. При чём не так важно, из какой области, но для технического специалиста приоритет очевиден.
Ваш тезисы напоминили мне одно, некогда знаменитое, литературное произведение. Там ещё был персонаж, который говорил, что ему не надо знать географию потому, что есть извозчик, который довезёт куда надо.
Это нафиг не надо никому, кроме embedded-разработчиков, зато отлично помогает понять основные принципы работы процессора на практике, плюс скромное понимание того, как на смом деле под капотом может работать любимый метод в любимом фремворке под любимый язык программирования.
Мммм, не поможет. embedded процессор и реальный отличаются как небо и земля. Виртуализации, оптимизации и прочий мотлох
Понятно, что всё это в 99% случаев в высокоуровневой разработке не нужно, но понимание этих вещей по-хорошему необходимо. В первую очередь для того, чтобы легче поределять возможные узкие места в архитектуре "на глаз" и "пятой точкой".
Нет, вещи, которые я прокомментировал, как раз не нужны даже для понимания узких мест, если они для вас out of scope. Что на глаз, что пятой точкой, что любым другим органом чувств. :)
Ну, и в случае возникновении нетривиальной проблемы, чтобы не гуглить сутками на пролёт, а сразу отсекать пласты возможных источников этой проблемы.
Как правило, нетривиальные проблемы как раз-таки специфичны - имеют отношение к языку программирования/библиотеке/фреймворку/конкретной комбинации используемых технологий (как внутри программы самой по себе, так и какие-то внешние для неё системы, с которыми вы взаимодействуете, будь то, например, БД или что-то другое). Такой общий кругозор тут поможет меньше, чем умение читать, гуглить и ковырять исходники.
ещё неплохо было бы иметь минимальный опыт написания програм для микроконтроллеров на языке ассемблера
Опять же, как человек, который писал для микроконтроллеров и писал на ассемблере (правда, по отдельности - под микроконтроллеры писал я на C) - нет, нахер не надо, лучше пойдите Таненбаума почитайте (в т.ч. разделы про процессоры и вот это всё). Это как если я скажу системщикам "вам надо написать хотя бы парочку высоконагруженных веб-сервисов, чтобы понимать, нахрена вы свои сетевые драйверы вообще пишете".
Да и в целом знания лишними не бывают
Во многой мудрости много печали; и кто умножает познания, умножает скорбь. :)
А если чуть серьёзнее - да, наверное, знать больше полезно, но это не является обязательным или даже ожидаемым знанием от программиста, для которого "низкоуровневая" или системная разработка не является непосредственно сферой деятельности. Более того, если я нанимаю, допустим, фронтэндера, мне будет глубоко пофиг, пересобирал ли он ядро, знает ли про ARP-протокол и программировал ли микроконтроллеры - это бесконечно низко в списке того, что для меня является факторами при найме. Приоритет, как вы и говорите, очевиден, просто не в ту сторону, в которую очевиден для вас. :)
Ваш тезисы напоминили мне одно, некогда знаменитое, литературное произведение. Там ещё был персонаж, который говорил, что ему не надо знать географию потому, что есть извозчик, который довезёт куда надо.
А вот передёргивать нехорошо! Я не говорю, что это вообще бесполезные знания. Я говорю, что в статье с заголовком "Что нужно знать, чтобы быть синьором?", претендующей на то, что это применимо к любой сфере разработки ПО, этому совсем не место, потому что это очень узкоспецифичные знания.
А кстати, зачем нужно знать географию?
Это действительно сложно объяснить почему фундаментальные знания имеют положительное влияние на принятие решений по прикладным проблемам скажем на JS. Это сложно объяснить, но легко почувствовать на себе.
У вас неплохо получилось, может быть кто-нибудь даже задумается.
сложно объяснить, но легко почувствовать на себе.
Влияние гороскопов на то, что с тобой происходить тоже сложно объяснить, но легко почувствовать.
Увы, субъективные ощущения часто обманчивы, особенно если потратил много сил на фундаментальные знания, математику, олимпиадное программирование и т.п. вещи — то проще верить, что это все было не зря.
По-моему, автор описал вещи, которые кажутся полезными лично ему, и описал своего личного "идеального специалиста в вакууме".
Тащемта автор сказал об этом в самом начале статьи. Но я бы предположил, что автор описал самого себя.
> OSI (и почему это дырявая абстракция, которая разваливается на ходу при внимательном рассмотрении даже самых популярных примеров)
Вот тут можно поподробнее, почему?
Во-первых, это где такое? Насколько я знаю, в реализациях каждый слой всегда общается только с соседними
Во-вторых, есть ли модель лучше? Почему она не популярнее OSI тогда?
Насколько я знаю, в реализациях каждый слой всегда общается только с соседними
это не так - например, переход между L4 и L7.
есть ли модель лучше?
точно была :-) https://www.quora.com/Is-there-a-substitute-for-the-OSI-model Второй ответ смотрите.
Почему она не популярнее OSI тогда?
потому что OSI референс и очень плотно укоренился в языке, т.к. когда речь заходит о балансировке - всегда говорят либо о L4, либо о L7.
Проблема в том, что, судя по вакансиям на рынке, именно таких и ищут, но не понимают сколько они реально стоят и какой на них спрос. Или не хотят понимать?
Мне кажется, что ищут как правило "кодера за недорого", но в требованиях расписан именно "сеньор-помидор" в вашем изложении. На всякий случай. А вдруг прокатит? Потому и зарплата указана в объявлении чуть больше, чем просо для "кодера за недорого".
И, как следствие, мне кажется вы переоцениваете спрос на таких вот реальных товарищей. Но правы в том, что оные товарищи планомерно покидают родную гавань. Ровно также "придавлены" они к местам скорее не бонусами, а жизненными обстоятельствами.
Впрочем, я вашему описанию соответствую процетов но 85. С тестами, с CI/CD, да с управлением людьми не очень. За то остальное даже шире. ТАк что может подтянусь - мнение поменяю. Правда, если совсем честно, именно в этом направлении тянуться ну совсем не хочется. С техникой проще.
Лучше хороший инженер, чем плохой менеджер и наоборот. Но иногда стоит попробовать чтобы убедиться)
p.s. Синьоров-разработчиков соответствующих написанному в статье за последние 10 лет видел от силы пару раз, а в среднем по больнице это ребята просто глубоко погруженные в конкретные язык/стэк технологий/предметную область (админы, дба, сетевики). В целом статья скорее про senior/teamlead devops.
--Синьоров-разработчиков соответствующих написанному в статье за последние 10 лет видел от силы пару раз
потому что они почти все ушли в архитекторы. А те, кто не ушел, обзавелись лычками принципалов и экспертов.
Справедливости ради и спора для хотелось бы заметить, что архитекторы — это не панацея и что места без архитекторов/принципалов/экспертов вполне себе существуют и неплохо живут. Там вокруг просто инженеры без всех этих лычек. Сами придумывают архитектуру, сами же пилят придуманное и потом поддерживают напиленное в работоспособном виде. Если что, я не про стартапчики из 2.5 землекопов, а про автономные компании размером в сотни человек.
Спорить лень, а дисскуссию чего б и не поддержать? :)
А можно примеров таких компаний? Я к тому, что архитекторы бывают разные (ea, sa итд), и вот я как-то слабо себе представляю как возможно их отсутствие где-то, где основной бизнес завязан на IT. А лычки... При всей демократизации процессов в it, у кого-то все таки должно быть право последнего голоса, что впрочем обычно несет с собой и конечную ответственность за результат.
слабо себе представляю как возможно их отсутствие где-то, где основной бизнес завязан на IT
Роль архитектора, конечно, кто-нибудь должен исполнять, но с этим может справится старший/ведущий разработчик, тим.лид, тех.лид, СТО и т.д.
у кого-то все таки должно быть право последнего голоса, что впрочем обычно несет с собой и конечную ответственность за результат
Почему? Команда синьоров может решить архитектурные вопросы банальным голосованием (да и, как правило, у опытных специалистов редко возникают принципиально неразрешимые споры о архитектуре при которых нельзя придти к компроммису). Да и команда может нести конечную ответственность за результат тоже вместе.
А можно примеров таких компаний?
А что это вам даст? Можете посмотреть мой профиль на список мест, где я работал, выделенные архитекторы, которые имели право последнего голоса там скорее были исключением, чем правилом (если в одном проекте/команде — они были, то в другой команде/проекте той же работы — все решали сами программисты).
Вообще, agile, kaban и т.п. техники разработки не очень стыкуются с ролью выделенного архитектора с конечным голосом и конечной отвественностью. Архитектор с жесткой линией — «делай как я сказал» это больше про водопад. ИМХО.
По большей части, я SA имел в виду. Все эти бизнес/ентерпрайз сущности, называемые архитекторами — это отдельная песня. Касаемо примеров: с ходу вспоминается revolut (хз как щас, но несколько лет назад он под описанный кейс подпадал), поменьше — kikoff, поближе — в Минске была пара таких компаний, осталось напрячься и вспомнить названия. Вообще, тут в пору вспоминать Спотифай, плоские команды и вот это вот всё.
Право последнего голоса, обычно, за владельцами компании. В большинстве приличных айти компаний они вполне себе вовлечены в процесс разработки и могут развернуть всё на 180 градусов, ибо деньги и компания их. А ниже них, при правильной организации и подборе персонала, никому нафиг не надо иметь такое право.
Если же копнуть глубже, то большинство случаев строгой иерархии в компании/команде я видел исключительно из-за низкой квалификации и сложности в поиске кадров. То есть, условно, дешевле и быстрее взять пучок мидлов и погонщика, чем хотя бы парочку отцов. Плюс, отцы могут банально не согласиться на однообразную муть, которую хочет бизнес. Отсюда логично вытекают юзкейсы плоских и вертикальных команд. Таки да, про плоскую компанию я ничего не говорю кроме случаев стартапа на 10 человек, где 90% так или иначе код пишут. Посему, иерархия в компании — это норма. Так же как с определённого уровня команды норма — это плоская структура.
Изучить очередной js-фреймворк при наличии знаний в программировании? Да не вопрос! Освоить новую фишку очередного языка программирования? Позвольте, это же давно забытое старое и мы это уже знаем!
Начали за здравие, кончили про упокой...
Если человек говорит, что между языками нет разницы - значит он, по-хорошему, не знает ни один язык.
Плюс мой жизненный опыт показывает, что действительно профессионалы не употребляют слово легко в принципе. Потому что не раз и не два сталкивались с ситуацией, когда казалась бы элементарная задача или проблема оказывалась на практике невероятно сложной.
Между языками разница есть. Подчас она очень существенна. Но после нескольких языков уже сложно увидеть что-то радикально новое. Да, комбинации операторов и инструментов разнообразнейшие, подчас адаптированные под конкретную область (или даже аудиторию), но не более. И да, "80 на 20" автор так же не отрицает. Нюанс в том, что первые 80 могут быть освоены за пару недель-месяцев и этого хватит для большинства задач. А оставшиеся 20 да, довольно трудозатратны в освоении, наполнены очень необычными и красивыми вещами, но крайне редко применяются а боевых условиях, ибо поддерживать такое ну очень накладно.
Здесь я вообще вижу тренд, что как только появляется большАя потребность использовать те самые 20 процентов для реализации хотелок, то довольно быстро прокачивают язык, делают библиотеку или отдельный инструмент, дабы то же самое сделать быстро и просто. Посему да, можно сказать, что автор не знает ни одного языка программирования на достойном уровне.
Но после нескольких языков уже сложно увидеть что-то радикально новое.
И тут на поле боя выходит golang, rust, dlang и так далее. То есть нет, в каких-то маргинальных формах их основные фишки вполне себе существовали, но как основное мейнстримное течение явное не использовались.
Причем нельзя же сказать, что эти фишки входят в 20% языка, которые можно не осваивать.
И да, "80 на 20" автор так же не отрицает. Нюанс в том, что первые 80 могут быть освоены за пару недель-месяцев и этого хватит для большинства задач. А оставшиеся 20 да, довольно трудозатратны в освоении, наполнены очень необычными и красивыми вещами, но крайне редко применяются а боевых условиях, ибо поддерживать такое ну очень накладно.
Не знаю о каких 80 на 20 вы говорите. Я с php работаю с 2008 года, и считаю что значительная часть знания этого языка заключается в понимании какие фреймворки использовать не стоит (к слову, не только я отмечаю, что хороший специалист это не только тот, кто знает как и что работает, а тот, кто также знает что использовать не нужно). Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 - это будет тоже самое, что плыть против течения.
А вот чтобы понять, что в языке есть, но использовать не нужно - нужны годы опыта и наблюдений разных проектов и команд.
Хотя и такое понимание приходит только тогда, когда перестаешь довольствоваться тем, что код «просто работает».
Сейчас изучаю Go в свободое время, и то, что я что-то написал на нем, и оно как-то работает - вообще не показатель знания языка. В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте. Через месяц работы - рассказать о судьбе проекта в будущем (жду, когда научусь это делать сразу на собеседовании).
В общем, знать синтаксис и уметь написать что-то, чтобы оно работало - это вообще не говорит о каком-то знании языка. Другое дело, что к сожалению кто-то на таком уровне и остается на всю жизнь.
Кто-то и до него не доходит) Видел я веб-разработчиков, которым показывал консоль разработки в браузере и они делали круглые глаза. И это были не джуниоры, а люди, которые лет по 10 этим занимались минимум.
Но вот именно такой опыт и экспертную оценку очень полезно иметь и перенимать - жаль, что не всегда такое есть
Знания того или иного языка != умению применить их в реализации той или иной задачи, увы) В моей жизни встречались разработчики, которые так глубоко закапывались в нюансы разработки, что порой забывали что они на самом деле делают. А ведь бизнесу нужен не классный код с применением самых модных паттернов, а, всё-таки, продукт.
В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте.
Очень сомнительное заявление, особенно про уровень команды, не обессудьте :)
Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 — это будет тоже самое, что плыть против течения.
На текущем месте работы я работал на 2 проектах, на Yii2 и на Symfony. Не сказал бы, что на Symfony происходит сильно меньше багов. Потому что баги происходят не во фреймворке, а в коде самого проекта, который пишут разработчики.
А еще в проекте на Symfony где-то там рядом Highload, и все эти правильные инструменты типа Доктрины кое-где выкидываются в пользу сырого SQL. Причем как раз на Yii можно было бы в условиях возросшей нагрузки продолжать пользоваться ORM, так как там и оверхед на создание моделей меньше, и вызовы QueryBuilder-а практически 1-в-1 мапятся на SQL.
В итоге фактическую пользу приносит только DI-контейнер, который есть во всех фреймворках, а там где нет, можно поставить какой-нибудь пакет через composer.
И еще могу сказать, что по моему опыту с legacy на Symfony всегда было работать гораздо сложнее, чем с legacy на Yii и Laravel. Насколько бы ни был плохой код на Yii, там всегда можно было разобраться и переписать нормально, потому что там нет десятков интерфейсов фабрик декораторов, модифицирующих свое поведение аннотациями и магическими тегами в конфигах. И DI-контейнер не билдится по 3 минуты при каждом изменении конфига.
Да, комбинации операторов и инструментов разнообразнейшие, подчас адаптированные под конкретную область (или даже аудиторию), но не более.
Вот только вы почему-то считаете, что это "не более", хотя на самом деле это скорее "не менее": знание/понимание наиболее выгодных комбинаций и приемов применительно к целевой прикладной области — это как раз то, что на практике отличает тех людей, которым имеет смысл платить много денег от тех, кому не стоит.
Сама по себе энциклопедичная полнота знаний при этом мало что стоит, хоть там 80% есть, хоть все 100%. Важна именно способность эти знания применить, а для сеньора — не просто применить, а еще и применить наилучшее и не применять хреновое.
Ну и очень большая доля новых решений (новых, а не нескучных) — таки как раз имеет этот самый аспект новизны, не выражающийся в "комбинациях операторов и инструментов". Вам уже заметили про golang, rust, и прочие, а для прикладной веб-разработки есть typescript, который тоже можно "знать для решения большинства задач", но при этом напрочь игнорировать его основную концепцию, фигачить any везде, где типы выводить стало чёт сложно (видимо попало в 20%), и так далее. Это нихрена не сеньорский уровень, который выливается в продукты, развивающиеся потом исключительно силами мегасеньоров за N*крыло от боинга денег. Которые обычно лажают поменьше (или если лажают, то срочно чинят, пока никто не заметил), а потому хреновое качество кода уровня "годится для решения большинства задач" не превращается в проблему. Но при передаче в руки менее квалифицированного персонала это всё стремительно превращается в тыкву. Несмотря на то, что по сути производимых действий в них нет ничего сложного.
Сразу скажу, что титулы "синьор реакта", "синьор AWSа" и подобные - это какая-то хрень... Синьор - это про фундаментальные знания и успешный опыт множества серьёзных разработок с применением этих знаний
Сразу скажу, что чемпион мира по легкой атлетике или чемпион MotoGP и подобные - это какая-то хрень. Чемпион - это фундаментальные навыки в спорте и успешный опыт множества соревнований.
Вот так вот легко сбросить мишуру с вашего основного тезиса.
Стандарта нет. Вот например на протокол TCP есть стандарт, а на квалификацию кодера нет. Поэтому нельзя сказать "реальный TCP - это когда розовые пони летят по проводам". Потому что есть стандарт. А про "реального сеньора" можно словоблудить хоть каждый день - что мы и наблюдаем.
Короче, у вас в трудовой написано "старший" и вы получаете по рынку как "старший" - все, achievement unlocked, вы сеньор. И никаким словоблудием вы этого не достигнете, если данный конкретный работодатель вас оценит ниже.
Как мне кажется, вы путаете тёплое с мягким. Лёгкая атлетика и MotoGP - это не фреймворки, которые сегодня есть, а завтра нет (хотя на счёт MotoGP не уверен). Автор, опять же, как мне кажется, говорит о том, что набор фундаментальных знаний ценнее, нежели набор скилов, заточенных под конкретную технолонию.
Да нет, очень правильная аналогия. Вот в олимпиаде есть метание ядра, которое отлично можно сравнить с cobol, к примеру.
Общий подход в спорте очень часто одинаковый, но вам нужно задрачивать конкретные действия. Так же можно предположить, что какой-то мастер спорта в смежном виде вполне сделает стандартного разрядника. Но смысл тезиса это не меняет.
Тут ближе будет аналогия, что чемпион MotoGP на сузуки, а на ямахе уже нет )
Ибо, например, после Си любой иной язык — это очень просто
Императивный, разумеется
Стойкое чувство, что мой мозг садомизирован этой статьей.. пойду поработаю, вдруг синьором стану
А что нужно знать, чтобы быть staff/principal/distinguished?
А что это? Или кто эти люди?
Так обычно называют ступеньки выше Senior в некоторых компаниях.
Distinguished engineer - это высший грейд инженера в некоторых компаниях (например, Amazon)
Подробнее про грейды можно почитать вот здесь - https://www.levels.fyi/
В первую очередь уметь общаться с людьми, писать внятные, однозначно интерпретируемые тексты, уметь планировать и делать много полезного на уровне компании, а не только одного проекта. Staff Engineer: Leadership beyond the management track довольно хорошо это описывает. И, в общем случае, это уже не совсем разработчики в классическом понимании.
"СЕНЬО́Р, -а, м. В средние века в Западной Европе: земельный собственник, обладавший властью государя на принадлежавшей ему территории." - мы все умные люди, и нормально можем интерпритировать это приложение в наши реалии =.=
"Лидер — лицо в какой-либо группе, организации, команде, подразделении, пользующееся большим, признанным авторитетом, обладающее влиянием, которое проявляется как управляющие действия."
ПС. Зачем плодить сущности философствуя/размышляя - "а что это значит быть...". Как бы эти названия были не из воздуха взяты =.=
Насчёт запада - тут можно сказать - кто-то хочет за бугор, кому родные берёзки милее. Чисто идиологический спор. Хотя есть позывы власти все щели закрыть и чуть ли ни границу.
Насчёт зарплат по "двадцаточке" - ну тут с одной стороны хайп, с другой дикое обесценивание доллара и уж тем более других валют. Многогранная тема про разделение на богатых и бедных, вымывание среднего класса, можно спорить бесконечно, только те же машины уже по полтинику штук долларов стоят в штатах для машины средней паршивости, а дом за 400к по медиане стоит, у нас так же дома и квартиры дорожают.
Да локальное падение цен на программистов возможно, но оно не более чем локальное.
Запад, нынче, понятие растяжимое. Кому-то там хочется целиком находиться, а кому-то достаточно работы с ними из-под родных берёзок. Вирус и удалёнка это ещё пуще разбавили. Плюс, государство наше как обычно: с одной стороны щели конопатят, с другой стороны шикарные налоговые условия и любовь к входящей валюте. Поэтому, здесь поле для обсуждения и споров самое благодатное.
и дисперсией, не поддающейся никакой оценке
Прочитал как "и депрессией, не поддающейся никакой оценке". В общем то все равно по смыслу подошло.
За упоминание кардинальных чисел - отдельный плюс :)
А чем/почему именно они зацепили, если не секрет?
Для меня кардинальные (и ординальные числа) связаны с прогрессом в метаматематике и математической логике в части познания: а) с одной стороны - собственных границ; б) с другой стороны - того, как далеко от моделируемого физического "мирка" можно зайти, если строить аксиоматику и логику так-то. Встреча с "пограничными" монстрами, красивыми и беспощадными (не хочется писать бессмысленными - не бессмысленными, просто это артефакты мышления), и не просто встреча, а их каталогизация, систематизация, приручение и одомашнивание :). Как минимум три общепризнанно больших достижений математики 20 века: доказательство теоремы Гёделя о неполноте, доказательство независимости теорема выборы и изучение независимости континуум-гипотезы - связаны с кардинальными числами. А универсумы (включающие в себя как раз кардиналы; например - Гёделевский универсум L или Фон-неймановский L), возникающие при построении моделей теории множеств - это ли не красота сама по себе? Приятно видеть упоминание такого рода объектов из "большой" математики в прикладной и даже гуманитарной (в хорошем смысле, о людях) статье, пусть даже в ироническом смысле :)
<irony>
Есть хорошая старая копипаста "Теоретический минимум программиста", думаю можно использовать в качестве отправной точки
</irony>
Сеньоры и сеньориты, каждый месяц в конце месяца новенький спорткар под дверью. Главное требование - знание языка COBOL-XXX, никому не известный диалект применяемый в одном швейцарском банке специально для транзакций больше миллиарда долларов.
За годы успел повидать разное, и вот складывается впечатление, что на просторах СНГ (а если точнее - то конкретно для выходцев из СНГ, с таким вроди бы уже не СССР, но еще и несформировавшимся майндсетом) видение сениора - это про скилы и года опыта. Вот еще бы к каждому скилу - количество лет опыта с данной технологией приписать - вообще идеальный (анти-)пример получается. И ни слова про подход к решению проблем (тот же "майндсет"). И в то же время в западных кругах - с точностью до наоборот - сениором называют человека, умеющего решать проблеммы (именно что "проблеммы", а не "задачи"), а не накодить там чего, погрепать порты да понастроить сервера.
Но всё-таки, оба подходя тесно связаны и не могут существовать друг без друга. Крайне сложно знать кучу инструментов ни разу их не используя (кроме случаев каких-нибудь мнемонистов и фанатов запоминания всего подряд) так же как крайне подозрительно уметь решать широкий спектр проблем не понимая чем и как они решаются (Ванга?). Имхо, оба подхода равноправны с более-менее одинаковым количеством плюсов и минусов, которые, однако, у каждого из подходов свои.
Английский
Его бы стоит знать вообще всем, ну кроме работников завода.
Думаю, последним тоже не повредит. Да и вообще, есть мнение, что каждый новый изученный язык крайне позитивно влияет на мозг и мышление. Так что пару языков надо бы в обязательный человеческий минимум включить. А ещё сколько-нибудь — в качестве факультатива и развлечения ради (ну и пользы для).
Стоит добавить ссылочку на "Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com" https://habr.com/ru/company/htmlacademy/blog/254825/
итальянский язык надо знать, иначе синьорам никак.
Кстати, самая лучшая похвала в архитектуре, это когда на презентации результата тебе недоумённо говорят «и вот эти три квадратика вы два месяца рисовали?!» и больше никаких косяков найти не могут. То есть всё на столько просто получилось, что «очевидно же!» и не может туда быть закопано несколько сотен человекочасов.
В два-три квадратика любое решение можно врисовать) Так сказать «обобщённая схема». Я когда последнюю прошивку «рисовал» у меня ушло те же два месяца, но квадратиков было где-то три десятка и, самое главное, стрелочки с подписями обеспечивали «беспроблемные» связи квадратиков. Но про вопросы типа «чего тут два месяца рисовать» всё равно верно подмечено)
https://habr.com/ru/company/oleg-bunin/blog/501488/
https://slurm.io/from-middle-to-senior - видео выложены на ютуб, надеюсь, кому-то полезны будут
Настоящий сеньор должен иметь вассалов...
По-моему, это уже "шашечки", а не "ехать".
Джун - это когда человек не может без посторонней помощи сделать работу.
Миддл - это когда человек может сделать без посторонней помощи работу.
Сеньор - это когда человек может предложить сделать эту работу самым оптимальным способом, а заодно и подсказать "снизу" что-то по рискам проекта - по технической части, не по договору или надёжности клиента.
Соответственно, сети, файловые системы и инглиш - это инструменты выполнения работы, а не цель. И тогда непонятно, зачем мне, например, сети и файловые системы, если я, скажем, калькулятор калорий на андроид делаю? Или фронт на интернет-магазин.
Если душа не просит приключений и калькуляторы калорий клепать норм, то и проблемы нет. Но, обычно, во-первых, всегда хочется бОльшего, а во-вторых, сани хорошо бы готовить летом, иначе говоря, когда внезапно понадобилось понять что с сетью/осью или иной штукой, то курить мат.часть поздно.
Ну и в вашем определении сеньора часть про "делать эту работу самым оптимальным способом" очень сильно намекает на широкий кругозор. Слишком много раз я видел, когда заказчик не понимал что хочет на самом деле. Без кругозора и некоторого опыта просто делается что запросили, но это далеко не оптимальная штука. Точнее, это локальная оптимизация в рамках ограниченных познаний, а не глобальная оптимизация в рамках исходной проблемы.
Калькулятор калорий - это тоже работа, точно такая же, как ПО для ракет Маска или ГТА 5. Там тоже есть ТЗ, планы, бюджет, РП, программисты и т.п. И главное - там есть бизнес, который понятия не имеет ни о каких сетях и файловых системах и которому нужен только конечный продукт. Соответственно, каждый участник этого проекта должен быть максимально полезен для этой (единственной!) цели, иначе непонятно, зачем его нанимать и платить ему деньги.
Поэтому, если, например, я собеседую сеньора (или миддла, или архитектора, или РП) на этот проект, то мне важно только одно - насколько они будут полезны для выполнения этой задачи. И если этот сеньор, например, понятия не имеет о сетях, но знает и доходчиво объясняет, на чём мне писать этот калькулятор, а на чём не писать, быстро осваивает ТЗ, с вопросами-предложениями, и в целом понимает, как нам успешно сдать этот проект - он мне подходит. Не понимаю, зачем бы я вообще спрашивал о сетях, если у меня на проекте их нет?
То, что вы описываете, бонус, а не цель. Да, неплохо бы, чтобы этот сеньор знал сети, файловые системы, 5 иностранных языков и 25 ЯП, в т.ч. ассемблер, мог взломать пентагон с кнопочной нокии, умел красиво танцевать и петь, летать и жить на дне океана - мало ли что из этого теоретически может понадобиться на каком-то из проектов? Такие бонусы могут быть полезны, например, если человек идёт работать в Гугл. Там очередь из желающих, все они отлично знают всё о любом проекте и как его сделать, а выбрать как-то надо. Тут уже такая же система, как у богача в автосалоне - на его деньги можно купить любую машину, каждая из них будет ездить, поэтому надо выбирать по максимуму допов.
Но не Гуглом единым жив этот мир. Есть множество работы по "обжиганию горшков". И там тоже нужны кадры.
Статья, видимо, хорошая, но из-за излишка сюсей и пусей абсолютно нечитаемая. Автору спасибо за труд, однако.
Что бы стать синьором, достоаточно приехать в Мексику) И сразу станешь Señor
Потом попадаешь на собес к синьору с такими взглядами и руки опускаются. Про это тут много историй, когда джун приходит формочки на сайт клепать, а с него матан и нанэ технологии спрашивают.
Стремление к постоянному развитию и получению новых знаний, это очень хорошая штука. Но не нужно забывать о синдроме, когда те знания, на получение которых лично мы затрачиваем годы жизни, в дальнейшем нам почему-то начинают казаться элементарными и обязательными для всех и каждого.
Хорошо, когда самообучение и развитие это хобби. Плохо, когда начинаешь своё хобби навязывать всем и каждому.
Может быть отсюда и растут ноги у выгорания?
Имхо, это не есть следствие большого багажа знаний собеседующего, это, скорее, его личные тараканы из области воспитания/психологии (тут ещё детские травмы любят упоминать, но это на любителя). Когда выучил кучу всего, а потом начинаешь этим над головой махать перед каждым собеседуемым, повышая ЧСВ или свято веря что всё это надо знать и уметь. Навык интервью — это вообще отдельная сложная штука, о которой у нас никто не говорит. Хотя и стоило бы. У меня была пара статей по этому поводу. Но там слишком большая тема, чтобы хоть как-то её в тексте изложить. Поэтому за всех не скажу, кажу только за себя: исповедую подход, когда после интервью человек уходит в лёгкой задумчивости и со знанием чего-то нового. То есть интервью — это двусторонний процесс, а не допрос или способ закрытия личных потребностей в доминировании. Поэтому вести его приходится очень по-разному. Для этого хорошо бы иметь хороший багаж знаний, дабы к одной и той же теме была возможность подойти с разных сторон, чтобы кандидату было комфортнее, ибо интервью — это в любом случае стресс и первым делом надо найти такой путь, который будет наиболее удобен/приятен кандидату, чтобы он показал свои реальные знания и опыт, а не переживал за то как выглядит в глазах других и как бы удовлетворить ответами "экзаменатора". Ну и развлечь кандидата — тоже полезно, если есть время и возможность. Тогда, при любом исходе собеседования, тебя и компанию запомнят и либо порекомендуют знакомым, либо позже ещё раз зайдут.
А касаемо выгорания, тут могу прямо противоположный аргумент привести. Желание изучать всё подряд — это хороший путь прямо в противоположном направлении от выгорания. Когда изучаешь что-то вообще не из рабочей среды — это всегда отдых, любопытство, интерес и переключение на неизведанное, то есть отвлечение от основных дум и отдых для мозга. Кто-то резьбу по дереву в гараже практикует между митингами и кодописанием, кто-то в хоре поёт, на квадрокоптерах летает самосборных или психологию изучает. Опять же, могу пример из своей жизни привести: если заглянуть в профиль, то года полтора назад у меня несколько статей про биологию было. Просто интереса ради копал молекулярную биологию и иммунитет. Нахрен не нужные знания для разработчика… но потом случился коронавирус и пригодилось. Плюс, нашлись очень прикольные связи биологии и разработки, что помогло по-новому посмотреть на давно известный процесс. Так что никогда не знаешь что и где пригодится. Поэтому, имхо, лучше всегда искать что нравится и изучать это, чем верить в то, что знания могут быть лишними и бесполезными.
Полностью согласен, что человек должен от души желать развиваться в различных направлениях. Но тот перечень базовых знаний, что описан в статье, больно огромный. И как минимум, это функции совершенно разных отделов. Я бы сказал что знать все перечисленное хорошо бы, я работал с большинством вещей, но новые знания в части Linux администрирования сильно и на долго оторвали, от веб разработки. Как минимум непосредственно в фронтэнде я невероятно отстал. Но говорить что мне реально приходилось использовать все эти знания на одной должности, параллельно, нет не приходилось, даже не представляю как такое возможно. Знал людей которые десяток лет работали в веб разработке, романтики, пишущие на фронтэнд и бекэнд, в какой-то момент просто ушли в бекэнд. И точно не согласны с требованием разбираться в администрировании. Устоявшиеся задачи таких знакомых, по поддержке сайтов клиентов, не требуют внедрения новых инструментов, как бы совершенно не целесообразно. А уж тем более трата времени на то чтобы разбираться в множестве технологий которые каждый год появляются, и так же быстро отмирают, при том что поставленные задачи, особо не поменялись. Может быть для каких-то крупных проектов и нужно знать всё вдоль и поперёк (хотя все равно плохо представляю как всем этим одновременно пользоваться), но очень многие до сих пор решают тривиальные задачи, простых клиентов, с простыми задачами. То есть не имеет смысла выкатывать докер контейнеризацию или виртуализацию, писать на Реакт, для 5ти страничного сайта с таблицой из БД, или выводом списка товаров. Как бы мало в этом смысла. По этому Сеньер как на мой взгляд, даже на одном рынке, довольно размытое понятие, начиная с того что есть Сеньёры по отдельным технологиям, заканчивая, условно Сеньёр по простым проектам, или это Сеньёр на крупном проекте. Но ваше описание Сеньёра просто переплюнуло все фантазии, там знаний на 10 лет самообучения, и это после 10и лет обучения на программиста. К тому времени как человек обретёт все описанные вами знания, совершенно сменятся технологии и инструменты.
плохие аналогии. Сеньор ДОЛЖЕН знать как его код работает в продакшене. Если он не знает - какой же он сеньор? Скорее просто ремесленник, очень узкий специалист. Сейчас такие на рынке не ценятся, нужны Т-shaped персоны - т.е. люди, обладающие глубокими знаниями в конкретной технологии/области, и знающие смежные вещи, но не обязательно на экспертном уровне, но хотя бы имеющие представление о чем речь. А то приходят... джава разработчики... а про gc не в курсе. Что потом получается? Алгоритм маляра Шлемиэля на ровном месте и производительность как у современных веб-приложений
Но ваше описание Сеньёра просто переплюнуло все фантазии, там знаний на 10 лет самообучения, и это после 10и лет обучения на программиста.
да, профессия сложная и тут не нужны "синьоры c 3 годами опыта". Ну, во врачи же ведь тоже не сразу берут :-) Так и тут. Вся эта мишура с С++ за 21 день - это инфоцыгане, которые реально вводят в заблуждение желающих легких денег в айти. Здесь опять же с Вами согласен, что есть и студенты, которые за 50 к рублей работают, а есть и инженеры, которые по 10000 бачей в месяц получают. Но стремиться-то надо, наверное, на уровень вторых, а не первых? А первый и лучший путь для этого - самообразование
Как писал далее, в какой-то момент мне стало больно от вечно раздувающихся технологий. Я честно стремился в Веб разрабы, фронтэнд и бекэнд. У меня был друг тренер, веб разраб на то время 7 лет, который подбрасывал мне новые технологии, пока они были в рамках адекватности и осязаемости, как для самообучения. Писал почти стандартный функционал для своих сайтов, как интернет магазина. Но в какой то момент, новые технологии стали больно заоблачные, для каких-то невероятных проектов, которые в домашних условиях на коленках в одно рыло не напишешь, на одноядернике под Виндой, да и идеи из потолка не возьмутся. Не говоря про их окупаемость. Кроме того этот друг и остальные знакомые сами уже были не особо уверенны в какую сторону пойдут развиваться технологии, не знали куда направить. И сами говорили про новые требования на рынке труда, мол не разберёшся, не возьмут, а в чем конкретно разбираться и сами толком незнали, то есть тогда выкатили ряд новых фреймворков и библиотек, но никто не знал что будет актуально через год. То есть на то время, такое количество новых библиотек было не очень нормальное явление. Не говоря про то что сами незнали куда подует ветер, что перестанет поддерживаться, а что будет развиваться, что в корне поменяется и мн.др. По этому я ушел в админы. 3D в то время тоже как-то неоднозначно развивалось, на данный момент это невероятное многообразие направлений, но и инструменты появились совершенно разные, переучиваться уже не тянет. В Linux тоже всё постоянно меняется. Единственно стабильно и не изменно это Windows, но как же он стал раздражать после переезда на Linux, нет слов. Сейчас сижу на KDE, там есть всё из коробки, даже то про что не догадывался, система тебе любезно покажет и подскажет, как минимум даст намёк. А Винда это сплошная тайна покрытая мраком, конечно же утрирую, но когда админил около несколько сотен рабочих мест, меня просто поражало количество и многообразие глюков, как ПК так и Серверов (особенно глюки с фаерволом на серверах, это адское горе), тогда же по полной прокатилось вирусом Петя, у меня пол организации стало колом, всё это в первую же неделю работы в этой организации, целый месяц бегал по кабинетам, восстанавливал данные. После боролся с кольцами в локальной сети, любезно оставленными предыдущим админом. Короче мне фартит, как не один ад так другой. Весь мой опыт работ, как на себя, так и наемным рабочим, это крайние-крайности из километровых задач на целый месяц вперёд и горы просто адских косяков, всех аспектах такой деятельности. Сказать что все такие работы были мало прибыльными, это буквально ничего не сказать.
Сравнивая собственный опыт, в том числе работы с партнёрами, который заканчивался невероятно плачевно, в сравнении с вакансиями которые встречаются и тем более статьями про перечень просто нереальных знаний, даже не знаний, а перечня предполагаемых работ. Складывается впечатление, что мир катится в каком то неведомом направлении. Не знаешь что от тебя потребуется завтра, на что рассчитывать.
Больше всего не согласен с последней частью вашего комментария, поэтому про неё и напишу. Про устаревание инструментов типа фреймворков я согласен целиком и полностью. Но в статье речь идёт как раз про базовые знания и про то, на что опираются все эти инструменты. Я специально отметил, что если отмотать назад лет на 10, то около 90% статьи останется неизменной. То есть все эти инструменты и технологии уже были на тот момент, сейчас они стали ещё более устойчивыми и едва ли куда-то денутся ещё через 10 лет. Да, сверху них навалят ещё бОльший слой абстракций, но база всё равно будет та же самая. Именно про это и хочется напомнить: не надо гнаться за переднем краем технологий да за новыми фреймворками, потому что они меняются, но база остаётся. На неё и стоит обратить внимание. Тогда не будет жалко потраченного времени и полученные знания устаревать будут крайне медленно.
К тому же, пока я интересовался асемблером, С#, C, Qt, Bash, Shell, Python применительно к Blender, пока работал сис. амдином и монтажником сетей, видео серверов и БД, пока разбирался с сетями построенными на 2-3х провайдерах, заводил оптику, на 2-3 Mikrotik и Ubiquiti. При том что эти функции были довольно ограниченны упрощенными задачами и размыты. Самостоятельно переехал на Linux, перевожу всё домашнее железо на две OS (тупо с запасом). Я совершенно оторвался от веб разработки, настолько оторвался что нашел статью 2016 года, с тем перечнем знаний которые мне не снились, технологии которые знаю только по наслышке (читал в общих чертах). И возвращаться в Веб не представляю возможным, как не представляю возможным вообще использовать все знания одновременно, которые каждый день просто утекают из памяти. Это не говоря про то что приходится разбираться в новых растровых, 2D, 3D и видео редакторах. Только в Linux, за последние годы не раз поменялись пакетные менеджеры, фаерволы, управление демонами, файловые системы, протоколы и файлы конфигураций (это только из общего). Тоже самое с каждым из языков программирования, их фрейморки, систем контроля версий, не говоря про гору модулей для IDE. Всё отслеживать и успевать в этом разбираться, просто не возможно. Особенно JS, Node.js c npm. Я когда в первый год узнал про Node.js c npm и узнал что уже написано более 1000 пакетов, сразу подумал как в этом всё вообще возможно успевать разобраться, тоже самое когда узнал про Реакт, Вью, Ангулар. Мне стало понятно, что учить до потери пульса, не имеет никакого смысла. Только я изучал новую технологию, выкатывается ещё 10, а через пол года ещё по 10 производных, если не 1000. И это не говоря про CMS или API всяческих ресурсов. Это списки в несколько тысяч технологий. Я вот совсем не представляю молодого специалиста, которому показывают все эти списки технологий и инструментов, а он говорит, та фигня, стану веб разработчиком. Верните те времена когда был один JavaScript и PHP + зарплату тех времён 1000-2000$ за тот или иной участок работы, а то совсем оторвались от мира (естественно шучу).
Прошу меня простить, но складывается впечатление, что у вас в голове всё перепутано и в кучу свалено. Абстракции вместе с реализациями — это, как минимум, странно. Попробую парой примеров показать что имею в виду. Не надо быть в курсе про все возможные менеджеры пакетов. Надо просто знать что такое менеджер пакетов. Не важно apt/pacman/yum или rubygem/npm/yarn. Детали о любой реализации гуглятся на раз-два и, на самом деле, между ними никаких радикальных различий нет. То же самое касается ОС: юникс везде. Таки да, 100500 дистрибутивов, но порой ты даже не задумываешься что за дистрибутив на очередной виртуалке, в которую ты попал. Основные команды никуда не делись. Да и основная парадигма про "всё — файл" осталась на месте. А чуть менее основные штуки гуглятся, ибо есть понимание того, что хочешь. Например, информация о портах где-то через netstat, где-то через ss, но суть от этого не меняется. Порт — он и в Африке порт (как, в общем-то, и все остальные части сетей). А касаемо кучи сложных функций в вебе: так не используйте их, если знаете как сделать проще! У меня есть вполне красивые примеры, когда на 2 ядрах и 2 гигах крутится пяток веб-приложений и никто не жалуется. Там не просто статика, там руби/эликсир/пхп и ресурсов вполне хватает. Имхо, было бы желание… ну и понимание что важно, а что переходяще.
Я прекрасно понимаю что в Linux незначительные отличия в коммандах, как и их надстройках. Работал не с одной OS. Прекрасно понимаю что все стремятся перебирать лучший опыт, рано или поздно программы переносятся на всё разнообразие Linux-ов более менее равномерно, хоть и с другими названиями или параметрами (с поправкой на развивающиеся OS). Гуглить прекрасно умею, как и вести собственные заметки работающих способов настройки, читать man help info. Настраивал домашние клиент сервера для связи со всеми устройствами Nginx, NFS, Samba, TigerVNC с PulseAudio через SSH тунель и мн.др. Windows на Virtualbox c пробросом и перенаправлением запросов. Кажется я писал про то что раньше эти знания считались функциями системных администраторов, как настройка кеширующих серверов, почтовых, веб-серверов, файловых серверов, БД, принт сервера и мн.др. пробросы портов, построение структуры сети, скажем так везде где была командная строка, это сис. админ.
Отлично! теперь остался единственный вопрос: зачем себя ограничивать в знаниях и говорить что это не моё а <название специальности>? Каждая новая область знаний косвенно улучшает уровень знания в соседних. А раз так, то нет повода не изучать все эти штуку. Плюс, они мало устаревают и могу пригодиться в самых неожиданных местах. Это же то же самое, что отказываться от базового ориентирования на местности (это задача картографов/навигатора), от умения готовить что-то лучше яичницы (повора для этого есть) ну и далее по списку. Ведь нет призыва учить всё со всевозможными деталями и нюансами, есть призыв изучать базовые штуки и с их помощью расширять кругозор. Который пригодится не только в работе, но и просто по жизни.
Windows AD и Linux Server ковырял, настраивал. Времена меняются, на данный момент у меня много железа дома, от старых серверных плат и просты ПК (в сумме 6 шт. нашел для них 2х ядерные и 4х ядерные процы под 775 сокет), которые я собрал в компактную кустарную серверную стойку, на двух блоках питания, под узкие задачи (у меня было довольно долго туго с железом, до недавних пор. Но если есть цель, рано или поздно я собрал себе площадку для экспериментов. Да, очень поздно, но я к этому стремился всю жизнь, хоть и заносило меня всегда в какието дебри других специализаций). Включая рабочие ПК, 5 ноутбуков, 2 планшета и 3 смартфона, 5 IP камер, мыкрофоны, вебки, фотоапараты с режимом передачи видео потока, и даже один древний iMac 2006 года, из которого я выковырял вебку, припаял провод, воткнул в Linux, собрал его родные дрова и повесил за окном. Сейчас, по чуть чуть переношу смартфоны на Linux второй OS. Моя следующая мечта, ковырнуть ардуины и Расбери, для шаговых двигателей. Настраивал всяческое печатное оборудование. Железо ковыряю постоянно, с паяльником и паяльной станцией тоже дружу, хоть и по минимуму простых схем или задач. Я вообще вырос с бухгалтера, после в 3D дизайнера конструкторщика, до веб разработчика и админа. Мне не нужно навязывать что знания это круто. Разделяю ваши взгляды. Но опыт предпринимателя и бухгалтера-экономиста, подсказывает, что лепить все функции на одного сотрудника, это крайнее жлобство руководства (так называемых оптимизаторов бизнес процессов, оптимизаторов финансов), или просто отбитость от мира всего. По определению это знания совершенно различных профессий. Ну не способен один человек одновременно выполнять все функции, а когда он не справляется это только повод для штрафов, даже не смотря на то что такой огромный круг работ нельзя возлагать на одного человека. Просто по времени, один человек потратит в десятки раз больше времени на решение возникшей проблеммы, чем если бы этим занималась комманда из разных специалистов, параллельно выполняя поиск проблемы. Ну программисты любят асинхронность и многопоточность, так вот здесь тоже самое, неможет один человек выполнить многообразные задачи, с одного рабочего места, в один момент времени. Вот про что я.
Хорошо уметь танцевать, играть на музыкальных инструментах, быть художником или даже скульптором, вкусно готовить, уметь управлять различными видами транспорта. Но одновременно вы не сможете это делать. А знания и умения со временем стираются из памяти. Что особо критично в кризисных ситуациях, вам понадобится время но то что бы повторно погрузиться в детали, на что совершенно нет времени в случаях ЧП.
У меня отец как то спросил чем ограничена производительность любого компьютерного железа, даже самого топового. Я ему ответил, скоростью перемещения мышки по экрану и скоростью набора текста. Он удивился, видимо у него был припасён другой ответ, но он немного смутившись и сцепя зубы, сказал "правильн". Даже при высоком скиле скриптования, эти параметры и ограничения никуда не делись, там где сидит 20-30 человек специалистов, работа идёт в 10-20 раз быстрее, и как минимум качественнее, с меньшим количеством костылей и временных затычек.
Но опыт предпринимателя и бухгалтера-экономиста, подсказывает, что лепить все функции на одного сотрудника, это крайнее жлобство руководства (так называемых оптимизаторов бизнес процессов, оптимизаторов финансов), или просто отбитость от мира всего. По определению это знания совершенно различных профессий
хватит, пожалуйста. Мне уже, честно, надоело это читать в каждом Вашем комментарии. Еще раз - мир не черно-белый, и не все капиталисты прям настолько плохие (конечно, плохие, но Вы преувеличиваете в разы).
когда он не справляется это только повод для штрафов,
это тоже ложь. Ни в одной айти компании, где я работал - штрафов нет. Насколько я знаю, в компаниях типа FAANG их тоже нет.
Просто по времени, один человек потратит в десятки раз больше времени на решение возникшей проблеммы, чем если бы этим занималась комманда из разных специалистов, параллельно выполняя поиск проблемы.
есть такая методология - если сотрудники работают в команде, то строится т.н. STAR матрица И задача отдается не самому сильному сотруднику, а самому слабому, чтобы он прокачивал свой скилл на ней. Естественно, что это добровольно.
Ненравится? Повышенная чувствительность? Не читай! Я тебе ничего не навязываю. Я не знаю где ты работаешь, на каких условиях, твой трудовой путь, с чем ты осознанно миришся, выполняя возложенные функции, а про что ты впринцепе не подозреваешь. Я делюсь своим опытом и опытом которым делились со мной. Опять же я жил в такой реальности. Твоё дело, абстрагироваться от неё или принимать многообразие рынка труда. Но не нужно меня переубеждать, да есть много различных моделей управления, и даже есть честные работодатели и честные бизнес партнеры (я про таких слышал, но невстречал, но не вижу смысла оспаривать то что не встречал, в отличии от тебя). Как есть много сотрудников которых эксплуатируют за гроши и навязывают какие-то штрафы, увольняют после испытательног, специально держат должности для беспрерывной текучки и эксплуатации дешевого труда. Я работал в огромном количестве компаний, на совершенно различных должностях, не встречал ни одной компании в которой не было бы подводных камней на каждом уровне управления, отделов и должностей. Я довольно общителен, со мной делятся своими взглядами и происходящим почти все сотрудники, и благо я понимаю о чем они говорят, слава богу знаний хватает, что бы подобная информация не пролетала мимо ушей и собственного механизма оценки происходящего. Тебе ненравится что не у всех всё так же хорошо как у тебя? Я непонимаю. Чего ты привязался к моим комментариям, в попытках оскорбить или оспорить действительность, её часть, часть реальности в который мы живем, в которой живет большнство людей? Извени конечно но уже возникло желание сказать "Выдохни и иди почитай новые статьи." Хоть и не люблю оскорблять людей, но ты как банный лист, с едино верным ответом, который таким не является, который нельзя напялить на все бызнесы на рынке, ну неработают все прям идентично, смирись, и зарплаты по 6-10 тыс. долларов у единиц, смирись. Доказательство тому что даже в IT приходят с совершенно различными профессиями, знаниями, умениями и опытом работы, а связанно это с нестабильностью рынка труда, условий труда, различных управленческих моделей, моделей оптимизации бизнес процессов, что сильно сказывается на тех самых договорных условиях труда и отношениях в коллективе. Ты приводишь как пример лучшие модели, да они существуют, гдето там далеко, и никто не знает всё ли так сказочно за такими крассивыми вывесками их названий. И опять же лучшее, не значит что все лучшие практики используются буквально во всех компаниях, от мелкого и среднего IT, вплоть до крупного. Перестань свои абстрактные идеалы лепить буквально на всех, на всём рынке труда и многообразие бизнессов. Это ты выглядишь наивным, уверывавшим в сказку.
Ненравится?
не нравится
Повышенная чувствительность?
нет, я толстокожий лесной тролль
Не читай!
не тыкай мне (с) Мы на брудершафт, что ли, пили?
Я не знаю где ты работаешь, на каких условиях, твой трудовой путь, с чем ты осознанно миришся, выполняя возложенные функции, а про что ты впринцепе не подозреваешь
первое - информация не секретная, можно найти. Насчет второго - если интересно, могу рассказать (опять же ничего секретного нет).
Опять же я жил в такой реальности.
да, реальность бывает разная, в зависимости от точки зрения наблюдателя, от его опыта, через призму которого он смотрит на нее. В этом и дело - что поливать индустрию говном - не позитивистский сценарий. От этого ни себе, ни другим лучше не сделаешь. Позитивно - разобраться в том, что конкретно нужно Вам, поставить цели, наметить план развития и двигаться по нему. Например, я сейчас тяну одного девопса. Мы с ним обсудили план развития, но камнем преткновения внезапно стала необходимость английского. Ну, чего - пошел, записался на курсы, потихонечку качает навык, чтобы потом трудоустроиться в зарубежную компанию. А это совсем другие деньги и совсем другая ответственность, чем работать на низовых должностях.
Я работал в огромном количестве компаний, на совершенно различных должностях, не встречал ни одной компании в которой не было бы подводных камней на каждом уровне управления, отделов и должностей
несомненно есть подводные камни везде :-) С этим я не спорю. Но если ты приносишь пользу бизнесу, если твой набор умений уникален или трудно заменим - все будет хорошо. А если ты условный кассир в пятерочке, то, прости, ты пушечное мясо и расходный материал, но это твой выбор. Стань лучше/быстрее/умнее/сильнее - все в твоих руках. В крайнем случае попросту можно попробовать начать получать удовольствие или найти ту сферу, что приносит больше удовольствия.
. Как есть много сотрудников которых эксплуатируют за гроши и навязывают какие-то штрафы, увольняют после испытательног, специально держат должности для беспрерывной текучки и эксплуатации дешевого труда.
повторюсь, что такая ситуация есть не везде и что она более характерна для компаний с определенным стилем менеджмента и, что опять же важно, на низовых должностях.
и зарплаты по 6-10 тыс. долларов у единиц, смирись.
такие вакансии есть, их достаточно, пробиться на них реально, надо иметь хороший отличный технический бекграунд и хоть немножко подвешенный язык. Вот буквально на днях приходила рекрутер и предлагала 5k $ для разработки инфры (и это еще не потолок). И это в РФ. Я знаю, что есть много разработчиков и devops, кто получает очень достойные деньги.
И опять же лучшее, не значит что все лучшие практики используются буквально во всех компаниях, от мелкого и среднего IT, вплоть до крупного.
согласен, совершенно необязательно, что их применяют, но такие практики есть в ряде компаний, поэтому опять же мазать ВСЕ черным цветом не стоит.
Пишешь что ты человек невероятно позитывных взглядов. Но умудряешься всё воспринимать только как негатив, а не некий общий опыт. При этом неизменно бросаешь аргументами редких и мало встречающихся практик. Ты приводишь в пример только самые крупные компании и некоторые довольно отличные модели. С явлением которых я даже не мечтал спорить. Но ты преподсосишь всё так, будто я оспариваю какую-то конкретную модель, конкретной компании. Извени но я такого точно не делал. Не нужно забывать что кроме нескольких сотен крупнейших компаний, существуют миллиарды людей и компаний, малого и среднего бизнеса. Ты будто отрезаешь весь мир, ограничивая взгляд только крупнейшими игроками. Извени но называть весь мир пушечным мясом, звучит несколько социопатично.
И ненужно ставить дизлайки (для меня не проблемма создавать хоть сотню аккаунтов, общение затрудняется), мне казалось у нас всё же открытий диалог. А не цель нагадить друг другу. Лайки мне тоже не нужны. Просто люблю открытые разговоры, и выслушать позицию вторй стороны, даже если я не согласен с чем то, мне действительно интересен взгляд человека. И лично мне этого более чем достаточно.
И ненужно ставить дизлайки (для меня не проблемма создавать хоть сотню аккаунтов, общение затрудняется), мне казалось у нас всё же открытий диалог.
я не ставил, но кто ж мне поверит :-(
Прости что оклеветал.
И так же должен добавить, что ты приятный собеседник. Как по моим внутренним ощущениям. Все твои аргументы я принял, просто у меня есть некое определённое место в структуре моего видения. И естественно если есть место в структуре, они имеют право на свою отдельную жизнь. Я даже больше скажу, все твои примеры с финансовой точки зрения имеют более весомый вид. Но и там есть гора скрытых вещей, не отменяя факта большей денежной и корпоративной внушительности.
Так же писал это вам https://habr.com/ru/post/600131/#comment_23956879
Так ведь не противоречит! Нигде в статье нет про "одного увака, который всё решает". Честно говоря, в статье вообще нет про организацию работы и даже советов нет об этом. А так, я с вами полностью согласен, что решительно не следует вешать всё на одного. Нужно разделять обязанности и производительность каждого индивида не безгранична. Однако, хочу заметить, что если эти индивиды имеют широкий кругозор, то договориться им друг с другом проще так же как сообща, при необходимости, решить задачу. А это уже прямой профит для всех. Посредников в общении становится меньше, плотность знаний и навыков на единицу сотрудника возрастает и это открывает возможности для реализации более вундервафельных задач.
В качестве пруфов могу привести старую заезженную мантру "кадры решают всё". Буржуи сие взяли на вооружение и она шикарно работает.
Про штрафы/наказания так же не соглашусь. Это больше отечественная особенность. Вон, Гугл уж давненько анонсировал как правильно с фэйлами работать. Там идут прямо в противоположную сторону, дескать крайнего искать не надо и косяки — это нормально и даже хорошо!
И да, при таком обширном опыте у вас просто должна быть пара статей! Как руководить зоопарком из железок и как адаптировать разные девайсы под свои потребности. А то умный дом с Али заказать — это не штука, а собрать из "подручных" материалов что-то нетривиальное — это смекалка нужна и руки из правильного места.
Ну на счет умного дома, всё так или иначе заканчивается на али или на конструкторах Ардуино и Расбери, в самом сказочном случае, на схемах передранных с тех же китайских устройст, но контроллеры и чипы всё равно придется брать с Али. Статей на эту тему более чем достаточно. Я не особо вижу смысл описывать в сотый раз написанное другими авторами. Тем более меня не тянет в авторы, и даже в соц. сети. Редко почитываю некоторые интерестные статьи, к которой могу отнести вашу. Я её оцениваю в первую очередь, как ваш персональный опыт и незаурядныей набор знаний. Естественно с положительной стороны. У меня буквально нет знакомых которые интересовались бы всем вдоль и поперёк. Со временем это утомляет. Если где то показалость что я осуждаю, это совершенно не так. По крайней мере лично у меня не вызывает чувства оскорбления диалог с другой стороной, как и нет никакого желания оскорблять вторую сторону, это вызывает у меня чувство оскорбления самого себя.
Тут в самое время цитировать господина 0xd34df00d и статейку про гринкард. Там есть замечательная мысль про нетворкинг. Так вот, желаю вам найти интересных людей для общения, чтобы не скучать с таким богатым набором навыков и увлечений. Кстати, написание статьи может быть хорошим началом для таких поисков. Точнее, после статьи вас люди сами найдут :) И да, я ни коим образом не принуждаю, есть много иных не менее действенных способов. Было бы желание и понимание цели.
Как то нет желания переезжать в другую страну. Я считаю что в независемости от страны, её общества, условий труда, всё же стоит хотя бы стараться любить эту страну. По возможности что то менять, делать для неё. На эту тему я вообще довольно глубоко размышлял, про электронную систему управления страной, всех её аспектов, создал собственную структуру и пониманеи функционирования такой системы. Обломался на осознании того что даже если всё это реализовать на практике, большенству людей не будет до неё дела. Когда наблюдаешь каждый день в окно картину как различный народ бухает, с утра до глубокой ночи прямо на лавочке. Начинаешь понимать что у них совершенно другое отношение к жизни и окружающему их социуму. Тоже самое на работах в большинстве организаций, где большенстов сотрудников, до сихпор считает сложным освоение принтера, текстового редактора или почтовика, ищут любой повод что бы перебросить свои функции на других, по быстрее сбежать с работы. Опять же я не осуждаю и сам рад помогать людям. Но понимаю, что таким вообще ничего ненужно в жизни, у них увлечение это поездка заграницу или поход в магазин, ресторани или кинотеатр. У меня же совершенно иные увлечения и взгляды на жизнь. И что самое главное, у меня нет мысли осуждать их. Просто понимаю, что таким людям нужны все удобства до тех пор пока им лично не придется принимать участие в принятии решений. Это не позволяет впринцепе реализовывать мою задумку, просто не имеет смысла. Но я в некоторм смысле даже люблю своих сограждай, во многом есть и положительная сторона.
Я считаю что в независемости от страны, её общества, условий труда, всё же стоит хотя бы стараться любить эту страну.
"Некоторые страны и некоторых людей проще любить издалека"(с) кто-то ;)
Я приверженец того что "проще", это не мой путь. Я конечно же знаю про гору решений в том числе в программировании, где избыточность сложных реализаций, на практике не есть хорошо. Как и гору примеров, где простота решения, это полу костыль или временная затычка, которая в дальнейшем тянет куда больше проблем. По сему проще это слабое решение. Хотя бы некое средне удовлетворительное должно быть. Тем более, лучшие решения приходили в условиях адских страданий. Просто убежать в чужую страну или в глухой хутор или зашториться в кравтире, на мой взгляд не самые лучшие решения, как для общества и социума. Хотя персонально для себя, естествоенно такие варианты могут быть|казаться лучшим решением. Естественно это право каждого, каждый имеет полное право принимать любые решения в независемости от мнения общества. Потому как, это его жизнь и он у человека одна.
По сему проще это слабое решение.
Угу. Почему-то сразу впомнился анекдот:
Парень в противогазе косит траву. Идет тетка.
- Ты что, милай, такая жара, а ты в противогазе?
- Я комсомолец, не могу без трудностей.
- Пойдем лучше переспим.
- Ладно. Но только в гамаке и стоя.А как же "всё гениальное просто"? Я вот не могу наворачивать кучу всякого, когда чувствую, что можно сделать очень тупо и просто. Там же меньше элементов, меньше точек отказа, меньше штук поддерживать надо… короче, сплошные плюсы! Или у вас всё как в Демиане Гессе завещал?
Переезжать не обязательно. Да и статью я привёл только лишь из-за мысли о нетворкинге, а не ради отсылки о смене локации. Времена Ломоносова прошли и можно даже без покатушек на обозе пообщаться с куче интересных людей. Фактически, как сейчас любят говорить, можно сидя в трусах на диване этим заниматься. Было о чём общаться.
А касаемо электронного правительства сразу всплывает ассоциация с Альтингом из Гипериона. Ну и да, в Татарстане есть более-менее успешный опыт электронного правительства и принятия решений через опросы в телеграме. Правда в очень узком и специфичном сообществе, в Иннополисе. Но, в любом случае, даже в этой области есть какое-никакое движение. Не будьте так пессимистичны.
"Не будьте так пессимистичны" можно на ты. У меня нет надменности, да и 40 пока не стукнуло. Впрочем не думаю что в 40-50 лет для меня будет иметь значение возраст, как мой так и собеседника. Я не песимист, скорее эмоционально флегматик, мало эмоционален, впрочем восторгаюсь новому и интерестному. Плюс где-то реалист, не отбрасывю совсем и полностью все аспекты. В целом даже если кажется что я довольно однозначен в своих выводах, вполне легко меняю сторону и взгляды, если аргументы действительно весомы, в том числе как по отдельным вопроссам так и в целом. Меня не оскорбляют диалоги с людьми имеющими больше опыта, ни люди имеющие меньше опыта, тем более их позиции. Я могу оспаривать некие взгляды, но целиком и полностью принимаю право такого человека на собственное мнение и видение. То есть если человек имеех хоть какую-то позицию, в любом случае это хорошо.
Со всеми с кем по общался, лично мне было бы интерестно, по быть в роли подчиненного, сопартнёра, руководителя и клиента, возможно дружбы. Естественно так не бывает, просто было бы интересто взглянуть на людей с совершенно различных позиций взаимных отношений, абстрагируясь от прошлых опытов.
Тем самым хочу сказать спасибо за интерестный диалог. Желаю только успехов.
Ты вчера писал про умный дом. Нашел кое что вполне простое и удобное без лишних телодвижений. 1) Ставишь на Линукс, Винду и Андроид смартфон программу KDE Connect, 2) на ПК прописываешь наборы комманд и пользуешься как пультом.
Если за локальной сетью, лучше иметь роутер на ПК плате на каком небудь Debian или Mikrotik (возможно Juniper, Cisco не работал с ними), простой случай Netping. 1) Можно написать скрипт, для простукивания последовательности портов и автоматического открытия ssh порта на роутере. 2) После подключиться к роутеру и кинуть сигналы на пробуждения всех устройств в локальной сети. Ну или запихнуть это всё в тот же скрипт авто открытия ssh порта. Впринципие как минимум удаленное управление домашними ресурсами, не есть таким сложным решением. 3) Когда всё поднято, можно пробросить порты через ssh, запихнуть их в наборы команд или одной сточкой пробросить все нужные потры
ssh user@10.1.12.253 -L443:10.1.12.253:443 -L5900:10.1.12.253:5900 -L5901:10.1.12.253:5901 -L5120:10.1.12.253:5120 -L5123:10.1.12.253:5123 -Cи пользоваться хоть KDE Connect хоть VNC хоть гонять видео и аудио с системы видеонаблюдения, управлять всеми службами, демонами, серверами, файлами и мн.др.
Это уже какой-то тимлид а то и техдир получился, а не сеньор. Сеньор - старший разработчик, может руководить джуном, в вопросы бизнеса вообще не суется - его роль не прибыль максимизировать, а делать так, чтобы продукт качественно работал. Разбирается в технологиях на уровне "могу сделать что угодно сам, руководить джунами, а вот командой - пока ещё нет". Потому что если человек руководит командой, то он уже никакой не старший разработчик, он уже руководитель - а это на ступень повыше.
Справедливости ради, про руководство командой в тексте почти ничего не говорится. Там говорится про понимание принципов "управления", а не про фактическое руление командой. Тут можно провести аналогию с представлением о том, что в розетке 220В и с базовыми знаниями, связанными с этим фактом. То есть вы не электрик, но примерно понимаете, что 220В и 380В — это разное, что бывает 1/3 фазы и что если засунуть пальцы в розетку, то будет не очень приятно.
Касаемо навыков и знаний синьора хочется тоже аналогию привести: прочитайте хотя бы первые пару десятков страниц у Кернигана с Пайком как они описывают "пользователя" юникса. Там вы можете с удивлением обнаружить, что по современным меркам — это вполне себе админ/девопс, а не "юзер". Так вот, я за аналогичное представление о синьорах, и против понижение планки вкупе с придумывание новых титулов для удовлетворения тех же самых потребностей.
Мой небольшой опыт разработчика веб сайтов, растрового и 3D-разработчика/дизайнера, администрирования локальных сетей, Линксов и форточек. Плюс некоторое общение с разработчиками фронтэнд и бекэнд, говорит мне, что на данный момент, развитие области веб-разработки и мобильных приложений, стало больно быстрым и избыточно требовательным, как для большинства клиентов не особо то и нужных технологий, не из крупного IT (тоесть крупный IT безусловно требует огромного множества знаний и использования технологий). Это не говоря про самих специалистов которые приходят с огромным багажом знаний и умений в совершенно различных областях (не IT знаний). 6-7 лет назад было вполне достаточно знать пару скриптовых языков и пару фреймворков, пару CMS. Сейчас же это помесь программиста, веб-скриптования, системного скриптования, системного администратора (с горой способностей, ранее считающихся специалистами различных областей), архитектора от сложной виртуальной инфраструктуры, до архитектора связанных проиложений и баз данных, управленца контроля версий и мн.др., не говоря про сотни технологий и инструментов в каждой из этих областей (которые постепенно заменяются и дополняются новыми).
Если говорить про кадровый голод Сеньеров, как бы не удивительно. Многие специалисты просто не успевают за ростом технологий, которые на практике большинству были не особо нужны. Другая часть молодых специалистов, приходя на этот рынок, неспособна разобраться в этом множестве технологий, даже при большей доступности к ресурсам, компьютерам, серверам, обучающих программ и статей. Никуда не пропал фактор времени на самообучение, его нужно очень много (годы), как никуда не пропал фактор отмирания множества технологий и инструментов (а следовательно потраченного в пустую времени). Так или иначе знание всего вдоль и впоперёк, больше попахивает нежеланием собственников крупного бизнеса, содержать штат из 10-20 человек, если финансово выгоднее все головняки перебросить на одного сотрудника, это не говоря про моду оформлять сотрудников по гиг-контрактам. Где скрыт ещё один не мало важный фактор, уклонение от налогообложения такими крупными компаниями, перекладывание бухгалтерского учёта, амортизацию рабочего места и всего необходимого инструмента такого сотрудника, на самого сотрудника.
Безусловно считаю, что иметь множество знаний и умений это очень хорошо для человека, как личного роста и достижений. Но такое активное перекладывание всевозможных функций и обязанностей на одного человека, это почти рабская эксплуатация. Давно существует простая истина, уметь всё, не равнозначно успевать делать всё и одновременно (рассеивается внимание, допускается больше ошибок, сложнее проводить поиск неработоспособности на различных уровнях функционирования этой громоздкой системы, элементарно из-за ограниченности временем). Точно также как знания и умения в 20-30 областях, никак не перекрываются зарплатами которые платятся такому сотруднику. Да зарплаты внушительные на первый взгляд, но на деле далеки от реальных (которые должны были бы выплачиваться, с проговариванием всех тонкостей таких отношений с сотрудником). Это элементарная оптимизация расходов, со стороны крупных компаний, на содержание штата сотрудников и их рабочих мест, включая перечень знаний и умений. Элементарная математика подсказывает что человек выполняющий 10 функций, освобождает руководство от финансовых расходов на организации ещё 9-ти рабочих мест, включая хитрость, а именно гиг-контракты, которые вообще освобождают от главной головной боли крупных компаний, непосредственных обязанностей руководства компании, вести бухгалтерский и финансовый учет, зарплат, амортизации, модернизации рабочего мета сотрудника, мн. др. Вплоть до юридической ответственности за такого сотрудника, потому как с юридической точки зрения, это не сотрудник, а подрядчик по договору. Который сам отвечает за бухгалтерию, собственный штат, полное материальное обеспечение, амортизацию, модернизацию, включая всё налогообложение, учет зарплат и юридическую ответственность. Фактически гиг-контрактчик сам является бизнесом, берёт на себя весь перечень ответственности и функций за весь бизнес (если он этого не понимает, это его проблемы).
Так вот я подвел всё к тому, что в статье сказано далеко не всё, кроме того что вы берёте на себя знатный кусок работ и не до получаете за это приличные суммы денег, в нагрузку по гиг-контракту вы берёте на себя ещё гору функций и ответственности (просто не подозреваете про это). За что фактически не до получаете ещё гору денег. Опустим часть сколько не получает государство и что в старости будет в пенсии, да и с самим пенсионным.
Простите, Вы используете очень интересную формулировку - "гиг-контрактчик". Вы имеете в виду человека, который де-факто работает как сотрудник, но де-юре представляет собой ИП или ПБОЮЛ?
ПБОЮЛ, попалась очень забавная расшифровка ))) Да в целом так, не углубляясь в форму собственности. Это отдельное юр. лицо, выполняющее условие договора, на выполнение неких услуг. В буквальном смысле не имеющее прямого отношения к внутренней структуре компании и бухгалтерскому учету заказчика такой услуги. Смысл таких взаимоотношений в том, что заказчику достаточно вести бухгалтерский учёт договоров, что так же влияет на содержание бухгалтерского отдела, финансового учета, анализа и статистики, а именного уменьшения штата. Очень многие крупные компании, чаще всего именно те которые требуют безграничных знаний и способностей от такого сотрудника, подсовывают условия трудовых взаимоотношений, которые по факту не являются трудовыми отношениями, а отношениями между клиентом и подрядчиком. То есть вы экономите гору средств такому работодатель (точнее клиенту), после вы соглашаетесь на выполнение горы функций и ещё раз экономите гору средств такому клиенту, естественно вы не получаете премии, надбавки, не состоите в прав союзах, не владеете собственным временем, это не говоря что сейчас пишут в такие договора (чревато тем что вы вообще можете принудительно вылететь из IT на несколько лет по такому договору, строчка про не конкуренцию). В нагрузку огромные суммы неоплаченных налогов (я не любитель государства и его управления, но факт уклонения от налогообложения есть), это не говоря про гору уловок, к которым прибегают такие крупные компании, начиная от штрафов, заканчивая не соблюдением условий договора. Созданием клон компаний и дополнительных посредников, в своей же структуре компаний. Туда же налоговыми ямами и скрутки, махинациями с клиентами и банками (которые тоже тянут за собой налоговые ямы, скрутки и рефинансирование банков), вводом средств в страну под видом иностранного инвестора и мн.др. Я понимаю что многие горды считать себя сеньорами делающими всё вдоль и поперёк. Но учитывая реалии рынка и требования, как бы совершенно не удивительно что растёт нехватка кадров. Точнее растут требования к специалистам, в замен не отдавая ничего, ни обществу, ни самим сотрудникам. Не говоря про размытие рамок между персональными инструментами купленными за счет человека (сотрудника), заканчивая его персональным временем и личной жизнью, элементарным нежеланием разработчиков и программистов погружаться в новую технологию, тратить на неё гору времени, что бы уже через год-два ему сказали что это умение причисляется к способности маргинала открывать глазом бутылку пива.
Вы передергиваете.
Смотрите. Первый аспект. Вы говорите, что этот условный ИП или ПБОЮЛ проигрывает. На самом деле нет. Вы же сами в предыдущем сообщение показывали, что это win-win ситуация для обеих сторон - и для компании (которая находит высококвалифицированного спеца и получает от него услуги), и для самого ИП. На самом деле смотрите - очень много профессий, который предполагают ИП. Например, нотариусы. Или каждому нотариусу нужно открывать ООО? Не думаю. Или я могу начать производить какое-нибудь мелкосерийное производство. Тоже открывать ООО? Теоретически есть всякие биржи вроде upwork или аутстаффинговые компании, куда я мог бы наняться как полноценный сотрудник, а они уже перепродавали бы мой труд за небольшой процент заказчикам. А зачем оно мне надо, если я могу получать 100%?
С другой стороны, я с Вами полностью согласен, что часто через оформление по ГПХ или через ИП прикывают нежелание трудоустраивать в штат. И в этом смысле это, конечно, нарушение закона и уклонение от налогов со стороны "работодателя", но это надо рассматривать именно case-by-case. Потому что, предположим, что я реально крутой профи, которых на планете Земля всего 1000 человек. Почему я не могу продавать свои услуги через ИП? Почему Вы отказываете мне в этом праве? У нас так-то свобода договора, что на самом деле идет на пользу бизнесу и экономике.
после вы соглашаетесь на выполнение горы функций и ещё раз экономите гору средств такому клиенту, естественно вы не получаете премии, надбавки, не состоите в прав союза
чо-о-о-о? Работа стоит ровно столько сколько на стоит. Если я договорился выкопать яму за 100 рублей, а реально затрат там на 1000 - кто виноват? Меня никто не принуждал к подписанию договора - см. выше есть понятие о свободе договора.
Вы не особо погрузились в аспект расходов и учёта. Нет вы не выигрываете ни в коем случае. Вам так преподносят такие договора. Убеждают что так работают все во всём мире. На деле с годами так и случилось. Но по факту, вы берёте на себя функции, нескольких IT отделов. После вы берёте на себя функции учёта и юридической ответственности, лишая себя горы прав, включая часть конституционных прав. А именно строчка про не конкуренцию на протяжении пары лет после увольнения, может трактоваться как угодно, вплоть до любой IT деятельности. Допустим ситуация, человек подписал договор, а через месяц ему говорят вы нас не устраиваете (не погружаясь в предлог и причины, желание подгадить такому сотруднику). Вы лишаетесь конституционного права на честный труд (да как бы не лишаетесь, но по судам могут затаскать до дыр). В итоге вы не получили желаемый опыт, достойную оплату, как вишенка на торте, вообще возможности вести IT деятельность, незабываем что налоги по открытому ИП всё равно придется платить исправно. Вас загоняют в глубокое дно правовой, налоговой и финансовой системы, включая рынок труда.
То что вам в действительности не доплачивают три такие зарплаты, это никак не может быть плюсом. И то что вы помогаете такими действиями уклоняться от налогообложения, как бы тоже сложно назвать положительным фактором. Не говоря про то что вам неизвестно какая структура компаний, у такого клиента. Тем более на счет того что вы выигрываете, это совершенно не так, в лучшем случае вы получаете на 10% больше. Но работаете и берёте на себя ответственность как за 20-30 человек отдельной компании. В свою очередь такая компания заказчик, экономит в 3-5 раз больше средств на содержании IT штата (и это суммы в разы выше чем одна ваша зарплата), отделов учета, анализа, экономистов, аудиторов, кадровиков и юристов, включая обеспечение рабочими местами, площадями (если человек работает на удалёнке, на собственной жилой площади на собственной организации рабочим местом, инструментом, каналами связи и мн.др. вплоть до отопления, воды, сан узлов, канцелярии и т.д. и т.п.). И на завершение никакой ответственности перед вами как подрядчиком (вы же не его сотрудник и не его головная боль, не его фин. расходы, вам не полагаются страховые случаи, путёвки, законный отпуск, никакой 13й зарплаты и т.п.). Опять же совершенно не известна структура компаний такого заказчика, с какой целью она может быть использована, сколько теряет бюджет на недополученных налогах, на возмещениях и рефинансированиях.
Мне непонятно в чём вы увидели плюсы для такого ИП, в чём он выигрывает? Кроме как безгранично помогает такому псевдо-иностранному инвестору.
Это не говоря про излюбленную практику увольнять целыми отделами, что бы не делиться процентами от проекта.
Что касается самостоятельной работы через различные площадки, это совершенно иной разговор, как и работа на вторую организацию в лице преподавателя, как выше высказался другой комментатор. Чую, что с таким перечнем требований, сомневаюсь что вы вылазите из-за компьютера, не то что бы брать леваки и тем более заниматься личной жизнью. Нужно не забывать, что многие знания используются крайне редко, то есть приходится повторно тратить время, на то что бы разобраться в том что якобы знаете, но на практике давно забыли.
Но по факту, вы берёте на себя функции, нескольких IT отделов
чушь. Если я хочу - возьму, не хочу - не возьму
А именно строчка про не конкуренцию на протяжении пары лет после увольнения, может трактоваться как угодно, вплоть до любой IT деятельности.
такой пункт может быть в договоре, а может и не быть. Точно так же он может быть в договоре по трудовому праву в американском договоре. Какой вывод? Не подписывайтесь под любыми бумажками, а внимательно читайте договора
Вы лишаетесь конституционного права на честный труд (да как бы не лишаетесь, но по судам могут затаскать до дыр).
если я заключаю договор с американской компанией, а потом работаю в российской юрисдикции - удачи меня по судам затаскать. Для того, чтобы меня таскали по судам - я должен быть носителем какого-то уникального знания. Но если это так, то это точно за пределами сферы работы как наемного сотрудника. На минуточку, напомню, что как правило, наемный сотрудник не имеет НИКАКИХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ собственность, которую он произвел на оборудовании, предоставленном работодателем, или в рабочее время. Удачи. И это вполне себе согласуется с российским ТК.
@0xd34df00dможет рассказать про американские договора ...
В итоге вы не получили желаемый опыт, достойную оплату, как вишенка на торте, вообще возможности вести IT деятельность, незабываем что налоги по открытому ИП всё равно придется платить исправно.
чушь. Не налоги, а сборы в пенсионный и в ОМС. Сам наход на доход, который вы не получили, платить не надо. Более того - ИП можно достаточно легко закрыть (1). И (2) - если не хотите закрывать, то продолжать деятельность в той же сфере, но сместив акценты.
Вас загоняют в глубокое дно правовой, налоговой и финансовой системы, включая рынок труда.
извините, но Вы вообще не поняли что такое быть частным предпринимателем. Вообще. От слова совсем.
Не говоря про то что вам неизвестно какая структура компаний, у такого клиента.
нас-рать
о работаете и берёте на себя ответственность как за 20-30 человек отдельной компании.
это не так. Вы берете ответственности РОВНО СТОЛЬКО СКОЛЬКО НАПИСАНО В ДОГОВОРЕ. Не больше. Условно - если у меня рамочный договор на оказание консультационных услуг или услуг по разработке ПО, то меня привлечь на работы по уборке помещения никак не получится. + самому заказчику услуг выгоднее иметь четкий трекинг того, что я делаю, чтобы закрыться потом актами о приемке результата работ, иначе он заплатит, а потом в случае некачественно выполненных работ или их неоказания, не сможет привлечь меня к ответственности. Вот так то.
Мне непонятно в чём вы увидели плюсы для такого ИП, в чём он выигрывает? Кроме как безгранично помогает такому псевдо-иностранному инвестору.
Вы вбили себе в голову вообще какую-то дичайшую чушь. И за нее цепляетесь. Рекомендую попробовать все-таки снять шоры с глаз и подумать головой. Хоть чуть-чуть
Контекст моих слов про "работаете и берёте на себя ответственность как за 20-30 человек отдельной компании" туда же их содержание. В том что вы ровно на столько экономите бабла такому клиенту. А следовательно было бы неплохо что бы доля от такой оптимизации финансов, которую вы делаете, прилетала вам в карман, а не оставалась целиком у хитро деланного клиента-работодателя. Давайте не приплетать законодательство Америки, мы не в Америке и точка.
"Но по факту, вы берёте на себя функции, нескольких IT отделов
чушь. Если я хочу - возьму, не хочу - не возьму"
Как же не возьмёте, если к вам такие требования в вакансии, ну как не возьмёте? Скажете "да умею, да знаю, хочу указанную вами зарплату, но делать небуду!" Так я вас понял?
"извините, но Вы вообще не поняли что такое быть частным предпринимателем. Вообще. От слова совсем."
Бухгалтер-экономист по образованию, ЧП и ООО в прошлом, в 3х направлениях. Я то непонимаю? Я вам расписал глубины учета вашего клиента, налоговой оптимизации, уклонения и инвестиционных потоков, трудовых отношений. Вы хорошо подумали прежде чем написать это? Вы или сами не улавливаете контекст финаносвых выгод и методы оптимизации, кто и что выигрывает в результате. Или отстаиваете интересы как раз таки крупного бизнеса, любителей гиг-контрактов.
Как же не возьмёте, если к вам такие требования в вакансии, ну как не возьмёте?
еще раз - если меня не устраивают условия договора - такой "работодатель" идет лесом. Вне зависимости от з/п. Если поначалу (Ваше первое сообщение) я с Вами был плюс-минус согласен, то чем дальше, тем больше я не согласен. Еще раз повторю - мне ИП позволяет иметь больше гибкости с тем, с кем я хочу работать, с кем не хочу и на каких условиях. Как высококвалифицированному специалисту (по крайней мере я так надеюсь) - мне это выгодно, чтобы оказывать услуги неограниченному кругу потенциальных заказчиков. И это работает. Зачем мне прибегать к помощи каких-то прокладок? В частности, если эти заказчики НЕ ГОТОВЫ НАНИМАТЬ МЕНЯ В ШТАТ НА ФУЛЛТАЙМ.
Касательно Вашего опыта "Бухгалтер-экономист по образованию, ЧП и ООО в прошлом, в 3х направлениях. " - знаете, можно всю жизнь учиться и помереть дураком (и не заработать на будущее своих детей), и что?
Вы хорошо подумали прежде чем написать это?
я - да, а Вы? Есть множество разных ситуаций и различных отношений. Свобода договора и оказания услуг - это хорошо. Подмена трудового договора ИП - плохо. И не нужно все сваливать в одну корзину.
Ну то есть всё верно. По вашим же словам вы просто не станете брать такого клиента, в свою очередь такой клиент не возьмет вас как подрядчика. В свою очередь это или нереальные запросы к наёмному рабочему, или вы всё же автоматически обязаны подписаться под крайне идиотскими требованиями, в том числе договора. Тут или или, другого не может быть. Следовательно мои утверждения более чем верные. Рынок избыточно требователен и это опуская детали трудовых отношений, включая все подводные камни.
То что вы можете принимать для себя любое решение, я не спорю, можете и дальше принимать любые как на ваш взгляд правильные решения. Не все владеют таким опытом как вы, многие просто становятся жертвами якобы устоявшихся правил рынка труда и собственного незнания. Но именно на таких жертвах, строится весь рынок труда крупного IT бизнеса с иностранными инвестициями (в действительности всего рынка труда не только IT). На тотальном непонимании внутренних механизмов, учета, налоговой системы страны, бюджета и мн.др.
Я с первого вашего сообщения понял что вы убежденный, но при этом это ваше право. Вам проще поступать так что бы ненужно было думать и понимать все аспекты отношений, между клиентом, заказчиком и государством, включая все причинно следственные. Я конкретно вас не склонял к каким-то действиям. Описал всё как происходит в действительности. Лично ваш опыт и подходы не осуждаю. Принимать действительность как она есть или нет, это тоже ваше право. Опять же не осуждаю. Но ненужно меня оскорблять, не зашоренный. И ненужно переубеждать. По вашим же словам, Вы можете отказаться от работы по таким договорам. Так вот я отказался, что у вас вызывает диссонанс? Отвечать ненужно, вопрос риторический.
Сборная солянка какая-то, начал понимать что что-то пошло не так, когда узнал что ФП необходимо знать высококлассному инженеру, так как его завезли во все языки. Мне кажется что нельзя знать ФП хоть немного и знать что-то ещё, тут или или. Бросил читать после опуса про архитектуру, после изобилия карсивых технических терминов так обосраться с тем что не смочь описать архитектуру лучше чем веб-макака первогодка это да.. Хотя подозревать что что-то не то начал немного раньше, когда автор скзал что инженер програмист конечно же это не слесарь 6 разряда а что то намного более утончённое. А по мне это именно слесарь, просто есть хорошие слесари а есть плохие.
Если говорим про определение то слово придумали, чтобы классифицировать разрабов при найме, от этого и нужно плясать.
А при найме не пишут, «ищем синьора», пишут «ищем сеньора рекат», соответственно первый тезис в разделе «фундамент» уже мимо. Сеньора в вакуме не существует, есть спец по конкретной технологии, или технологиям на определенную должность.
И это норм человечество дано поняло, что разделение труда экономически выгодно.
Полностью согласен, что без разделения труда, это не специалист а раб который батрачит круглыми сутками на непонятных для него самого условиях. Знать всё невозможн, как невозможно помнить всё что изучал пол года назад и не применял на практике, невозможно одновременно выполнять все функции, я имею в виду все функции в один момент времени (это в случаях экстренных ситуаций, вообще невозможно), а тем более помнить изученное 2-3 года назад. На то чтобы получить такой список знаний, как указанно в статье, потребуются годы, а скорее десяток лет. И опять же не факт что через 10 лет не поменяются технологии (гарантирую что поменяются уже через год-два) (уже гора потраченного времени на изучение вникуда), а многое придется по новой переучивать, разбираться. Это просто нереальный список запроссов. Я по свим знакомим из веба знаю, что в какой-то момент они просто отказались от фронтэнда, остались на бекэнде, потому как слишком огромный поток технологий, уж тем более они нехотели сталкиваться с администрирование, докерами и тем более кубернетами. Им было более чем достаточно вагрант и гита, как доп. инструментов. Они объясняли это тем что у них своя оптимизированная структура разработки сайтов. Это позволяло писать им довольно быстро сайты. А остальные огороды городить, просто финансово не выгодно, затраты на обучение растут, на обновление железа, а выхлоп в денежном эквиваленте совершенно не растёт, скорее растёт время на разработку и внедрение, того что редко используется и требует горы подготовительных работ. Что особо ощутимо, если падает рабочая машина с IDE или серверная часть. И уж тем более они строго определяли, не желание разбираться в администрировании. Тем более со временем большинство задач сводится к поддержке сайтов клиентов, добавление простых элементов, банеров и т.п. Встраивать новые инструменты и фреймворки, ради простой задачи, вообще не имеет никакого смысла, а переписывать всё с нуля, им за это не платят. Большинству клиентов нужны или 5-ти страничники, или было модно одностраничный сайт, редко магазины и форумы на готовых ЦМС, ещё реже БД. При это я бы не сказал что эти люди небыли загруженны под завязку. Откуда брать время на изучение того что не востребованно, большей вопрос, не говоря про личную жизнь. То есть можно сказать что наш рынок не так требователен, хоть и вполне себе загружен. Изучение ещё горы технологий, нести затраты на обучение, ради 20-30 вакансий на рынке (не текучки), да ещё с непонятными договорами и отношениями, вообще не выгодно. Хоть и кажется что зарплаты выше, но расходы на такие переквалификации куда выше, как никто не гарантирует долгосрочных отношений, то есть многих лет работы, стабильной оплаты и мн.др.
По-моему Сеньор -- это человек, который может брать и реализовывать большие куски проекта или целые проекты при этом не задавая мелких вопросов на каждый чих. Если человеку можно дать работу и быть уверенным что всё будет сделано и результат будет вменяемый, то он сеньор.
Конечно проекты и задачи бывают разного размера и сложности и ожидания насчёт "всё вменяемо" в разных организациях разные. Что именно называется сеньором в разных организациях -- это их личное дело. Единственно правильного ответа тут нет.
На мой взгляд, нанять в проект сеньора с рынка в принципе нельзя. Можно нанять человека, который на прежней работе считался сеньором, например. И рассчитывать, что в нашем проекте он тоже сможет исполнять функции сеньора. Потому что градации "сеньорности" существуют не вообще, а применительно к конкретному проекту. Перечисленные в статье навыки, безусловно, способствуют этому и увеличивают вероятность занять сеньорскую позицию на большинстве проектов.
Как правильно писали некоторые комментаторы, существуют проекты и сеньоры на них, которым не нужны многие перечисленные навыки. Мне кажется, количество навыков - это не про конкретный проект, а про легкость перехода на другой проект.
Я не разработчик, а владелец продуктов, и для меня сеньор-разработчик это в первую очередь технологический партнер, ведущий инженер и проводник в мир разработки в рамках своего продукта или части продукта. "Сеньорность" определяется для меня двумя параметрами:
Насколько свободно человек может объясняться на понятном мне языке и выступать инструментом управления ходом разработки в части принятия правильных технических решений. Не лезть в них, а именно помогать команде принимать правильные решения путем трансляции нюансов из мира бизнеса. Чтобы пилить нужные фичи, выбирать нужные направления на развилках. На мой взгляд, сеньор это мидл, который умеет говорить понятно для бизнеса о том, чем занимается команда.
Сколько лишней работы позволил "не делать" опыт этого человека. В маленькой команде на большом проекте любой вариант что-то не делать на вес золотом. Технический кругозор сеньора дает возможность применять готовые решения, методики, фреймворки, не изобретать велосипеды там, где это возможно. Это еще одно ключевое отличие от мидла, который тоже офигенно хороший спец, но который комфортно живет в своем пузыре. Я очень люблю мидлов, они делают всю работу на самом деле. Но это их ограничение может дорого обойтись компании. Сеньор - это тот человек, который может залезть на самое высокое дерево и осмотреть окрестности.
Тут поминали некоего "архитектора" в комментариях. Для меня ИТ-архитектор - это всё же роль, а не человек. Что-то типа бизнес-аналитика, который специализируется на выявлении нефункциональных требований и планирует их реализацию. В маленьких компаниях роль архитектора берет на себя обычно сеньор по направлению в те моменты, когда это необходимо. Он же разруливает архитектурные вопросы в ходе проектирования, если они возникают.
Кто-то еще пользуется ssh для "раскатки" приложений? Позвольте поинтересоваться, сколько у вас датацентров, сколько миллионов DAU? Одного экземпляра обычно никогда не хватает.
Пользовался совсем недавно. Датацентров больше двух.
А что не так? ssh с выполнением одной команды на заранее созданной группе серверов это типовой способ быстрого решения проблем горящего прода. Даже просто моментально вывести их из под нагрузки через ssh обычно быстрее чем любой более продвинутой тулзой.
PS: Люблю всех у кого прод никогда не горит и ничего никогда не надо делать срочно.
Как говорил Сергей Палыч Королёв: "критикуешь — предлагай". Так вот, можно чуть подробнее о недостатках ssh, почему он в нашем стремительно развивающемся обществе больше не подлежит использованию и что, нынче, нужно использовать вместо него?
Это поклонники AnyDesk бунтуют. Впрочем сейчас не есть проблеммой, написать простую GUI программулину на том же C++ с Qt или C# + WTF, которая будет графически отображать вместо набора команд кнопочки для соединения с серверорм, перезагрузки сервера, отдельных служб и мн.др. Только это не так что бы самое быстрое решение, скорее прихоть тех кто не хочет знать Линукс команды. Ну как бы к этому идет весь мир, может кому то станет не влом писать такие графические оболочки, для казалось бы простых команд и задач.
В крайнем случае, если есть огромное желание ковырять kubernetes никто же не против, разбирайся, пользуйся. Какое тебе дело к людям что используют ssh. Который ко всмему прочему, сам по себе очень мощный инструмент, много составной, тунелирующий и шифрующий. Чуть выше как раз бросил комманду ssh для одновременного проброса множества портов, пользуйся себе локально чем хочешь.
И более того, никто не запрещает использовать хранилище паролей не по назначению. К примеру, создать отдельное хранилище, со списком всех локальных устройств, добавить туда ряд полей. вписать туда набор стандартных команд, клонировать записи. Быстро копировать и вставлять в коммандную строку, подключаться, перезагружать сервера, добавить любое количество полей, с нужными командами, а в поле дополнительно, прописать ряд вспомогательных команд. Быстро и удобно, да ещё зашифровано.
Просто я с 2019 года не видел ни одного прода не на основе оркестровщиков, и в повседневной работе гораздо чаще используешь kubectl. Конечно в контейнерах работает только код, БД, журналы, очереди и прочее живет на виртуалках, но по ssh к ним доступ только у SRE, сетевых инженеров и безопасников, разработчику на продовый сервер не попасть.
У меня ровно противоположная ситуация: кубер крайне редко где встречаю… может не там хожу, а может просто не шибко люблю его. Доступ к проду у всех разрабов. ssh чтобы быстро глянуть что как в проде — норма жизни. Посмотрел имя машины и тут же в неё ворвался. Будь то воркер, БД, балансер или что угодно ещё. Таки да, кубер — это необходимое зло с определённого масштаба, но до этого момента кубер больше вреда создаёт чем пользы приносит. Плюс, есть вполне жизнеспособные сценарии, когда какой-нибудь ansible+terraform раскатывают всё по голому железу без доп.прослойки виртуализации. А перед ансиблом и плейбуком, каждая новая штука раскатывается руками через ssh, потом твикается руками и уж затем автоматизируется. Ну и да, монолит — это тоже отличный юзкейс, который живее всех живых (хоть все хором и кричат, что это прошлый век и больше нельзя так делать) и крайне плохо ложится на кубер. Короче, мы с вами субъективны и надо бы статистику подвозить о кол-ве тех или иных конфигураций продов в мире. Лично моё мнение — монолиты пока в большинстве, а значит кубер с сотоварищами пока не всех поработил. Но тут никаких пруфов, могу сильно ошибаться.
Согласен, я был не прав. Я всегда за большую безопасность и ограничение доступа, насколько это возможно. Для меня Kubernetes и kubectl тёмный лес, но заставляет задуматься над скорым освоением.
Для меня Kubernetes и kubectl тёмный лес, но заставляет задуматься над скорым освоением.
кубер дает (сюрприз) бОльшую безопасность и бОльший контроль за инфрой, чем в классических сценариях инфры на железе + какой-то SCM.
Если надо - могу аргументировать.
Убедил. Согласен что как минимум поставить и по тыкат стоит, а лучше хорошо разобраться.
Подскажи, что можно развернуть на кластере, что бы можно было попробовать и погрузиться во всю мощь этого инструмента.
Есть ли готовые наборы разделённых ресурсов, как некая тестовая площадка
что можно развернуть на кластере,
? в смысле? Я бы рекомендовал начать с простого - взять пустой кластер, наполнить его ingress nginx (community), добавить cert-manager, потом задеплоить какое-то минимальное приложение, например, на фласк, потом его опубликовать, сделать автовыпуск сертификатов, и понеслась... мониторинг, логирование, безопасность, обновления, ci/cd и прочее
лДокер зачем привели? Как пример абсолютно незащищенного софта? Но в целом, Вы правы, докер дыряв, а кубер это закрывает за счет того, что в нем уже есть вменяемый RBAC. А далее есть куча тулинга, которого для докера нет, но для кубера есть и позволяет как проводить аудит, так и ставить ограничения. Пара примеров - OPA https://github.com/open-policy-agent/gatekeeper Позволяет писать вообще произвольные политики для применения. Falco - https://falco.org/ позволяет снимать с каждого узла поток выполнения и слать алерты, если происходит подозрительная деятельность. Да, можно на обычные узлы и Wazuh накатить, но кубер предоставляет единые механизмы и унифицирует архитектуру. Можно притащить какой-нибудь sysdig/stackrox и все такое. Обязательно - секурити контексты и рутлес контейнеры. Которые, в общем-то, можно и не использовать, но закручиваешь политики и разработчики как миленькие начинают их использовать. Становится явно безопаснее, чем крутить системди юниты под рутом. Что еще. Кубер предлагает 100% обзервабилити - трейсинги, нетфлоу (из сетевого плагина cilium) и все такое. На легаси инфре на железках это все как бы надо собирать самому по кусочкам и делать какое-то централизованное управление.
АПИ сервер защищен токенами и опять же - RBAC... в общем, минорные проблемы, конечно, есть, но сделать систему такого же уровня с НУЛЯ и из своих компонентов.... не нужно...
из виртуалки можно сбежать
из железки можно сбежать
и?
Вопрос же в том какие механизмы сама платформа предоставляет, чтобы это предотвратить или распознать, если уже случилось. И в случае докера - действительно все плохо, но на уровне кубера количество контролей уже достаточное...
Ну, если ваш вопрос таков - проще ли убежать из кубера, чем из голого докера, то ответ негативный. У кубера в конце-концов контейнерный рантайм может быть заменён на kata или gvisor, обладающими более высокой степенью изоляции, чем докер, да и доступа к контейнерному рантайму в кубере напрямую пользователю не предоставляется. Это уменьшает поверхность атаки. С другой стороны, кубер притаскивает пачку новых сущностей и способов работы с ним. Но это хотя бы хоть как-то продумано. И как я уже сказал - можно законтролить
. Плюс, есть вполне жизнеспособные сценарии, когда какой-нибудь ansible+terraform раскатывают всё по голому железу без доп.прослойки виртуализации. А перед ансиблом и плейбуком, каждая новая штука раскатывается руками через ssh, потом твикается руками и уж затем автоматизируется.
terraform на голое железо, это как? metal3? Но тогда нафига ансибл?
Или речь про образы пакером - тогда одобряю?
А вообще можно foreman + pxeboot + образа + puppet/chef/ansible/salt и все в домике
Лично моё мнение — монолиты пока в большинстве, а значит кубер с сотоварищами пока не всех поработил.
монолит прекрасно заезжает в кубер (да, приходится обмазаться немного костылями, но это приемлемо)
"Голое железо" не в смысле пучок серверов под столом, а в смысле AWS какой-нибудь. Там хоть тераформ, хоть клауд формэйшн… короче, любая тулза для заготовки 100500 инстансов, назначения секурити груп и подобного. В области железа я уже почти согласен, что крайне мало кейсов, когда нужно вот прямо своё железо, а не услуги хостера типа амазона, гугла и им подобных. Предполагаю, что такое же может случиться и с кубером… но пока не вижу явных предпосылок для этого, поэтому поживём — увидим.
Касаемо заезда монолита в кубер — это хорошая тема для холивара… и каждый останется при своём. Как мем про буханку и троллейбус. Да, есть кейсы когда оно оправдано, но мне пока попадались исключительно переносы монолита в кубер на хайпе. То есть ребята тащили потому что "круто!" а не потому что посчитали и поняли что профит будет. И получалась адовая хрень вида: у нас теперь монолит и… 150 микросервисов, которые мы вытащили из монолита, а он, зараза, не уменьшился и не исчез. Таки да, хороший кубер я тоже видел, но только там, где изначально был человек или группа людей, которые чётко понимали как готовить кубер и зачем он нужен.
В любом случае, существует масса вариантов сделать хорошо красиво и правильно как при помощи монолита, так и при помощи кубера. Вопрос в том, что регулярно выбирают то что более модно, а не то что лучше всего подходит под задачу. И это печалит. А оценить риски и подводные табуретки каждого из подходов — это крайне нетривиальный квест. И где такого специалиста найти — решительно не ясно. Тут выше в комментариях говорят, что синьор много знать не должен… что уж говорить о знатоке кубера и монолита, да ещё и с опытом в обеих областях.
В области железа я уже почти согласен, что крайне мало кейсов, когда нужно вот прямо своё железо, а не услуги хостера типа амазона, гугла и им подобных
их не так мало. Тот же дропбокс выехал из Амазона. Дорого. Букинг вроде на своих серверах. Всякий адтех с кучей трафика тоже очень любит свои железки (они попросту на трафике разорятся, если в облаке будут). Банки любят свое железо, по крайней мере в РФ, потому что регуляторка. Всякие кейсы бывают. Причем внутри может быть как бареметал, так и какая-нибудь виртуализация (например, вмварь). На самом деле, мое мнение, будущее за гибридными схемами. Зачем ограничивать себя в выборе, если можно получить лучшее от разных подходов? Другое дело, что любой гибрид - это всегда инженерно сложно. Каналы связи. Интеграция. Как пускать трафик. Ролевая модель. Как сделать прозрачный автоскейлинг (чтобы ресурсы из облака брать, когда нужно, а не абы когда). И все такое.
Да, ваша правда. Я сначала подумал про военку и им подобных в отечественном сегменте, которые исключительно на своём железе сидят. А потом решил, что их вклад не такой уж большой… а самых больших игроков рынка как-то продолбал.
С другой стороны, мне даже любопытно, а появится ли какое-нибудь подобие отечественного хостера, чтобы туда в приказном порядке пересадили банки/оборонку и их сотоварищей? Чтобы хостер православный, сертифицированный ФСТЭКом, ФСБ и прочими компетентными органами. Тогда и вопрос с хранением данных решится сам собой, и место для грандиозного попила образуется, и единая точка входа для всех маски-шоу по отъёму железа для экспертизы.
С другой стороны, мне даже любопытно, а появится ли какое-нибудь подобие отечественного хостера, чтобы туда в приказном порядке пересадили банки/оборонку и их сотоварищей? Чтобы хостер православный, сертифицированный ФСТЭКом, ФСБ и прочими компетентными органами. Тогда и вопрос с хранением данных решится сам собой, и место для грандиозного попила образуется, и единая точка входа для всех маски-шоу по отъёму железа для экспертизы.
Ростелеком? Или сбер-клауд? А еще глядишь сейчас всех обяжут переезжать на Эльбрус с Байкалом. И обязательно, чтоб постгрес. Сертифицированный. Отечественный. А операционка - астра линукс
Не, должна быть монополия. Даёшь ЦОДы от РЖД! И вирткалки с названиями "плацкар", "купе", "св" тд. Ну и для студентов, "сидячие" бесплатно.
Сбер же уже отклонил предложение переезда на Эльбрус… он им "чуть-чуть" по ТТХ не подошёл. А из всего остального я пока только за постгрес :)
Ну а астра… тот кто видел/помнит/юзал МСВС, тому астра вполне норм.
Как-то с областями ответственности у вас не работает, поэтому вместо специалиста сеньора (боюсь спросить, у вас лид тогда кто) у вас какой-то робот, владеющий фундаментальными знаниями о Вселенной, знающий кулинарную энциклопедию наизусть и секвенирующий геном во время перекура, решая в уме сложные задачи из криптографии, пока в мире решения не имеющие.
Доступ у всех = ответственные все = никто ни за что не ответственный.
Почему бы вам просто не назначить ответственных по областям. При этом все будут счастливо заниматься своими делами, применяя свои навыки там где они нужны. Не надо суперчеловека для этого искать, их все равно нет. Загрузку данных в голову пока не придумали, выучить все в мире невозможно. Лучше выучить что-то целенаправлено, но более глубоко, чем овладеть обширными энциклопедическими знаниями, которые никуда толком приложить нельзя.
Простите, но первое что в голову пришло — это цитата Дедпула: "капец ты мрачный, ты точно не из DC?". Я имею в виду, что не надо так негативно. Очень разные ситуации бывают и очень много вещей имеет право на жизнь и вполне себе хорошо живёт, даже если с этим кто-то не согласен.
А если серьёзно: во-первых, про вселенную, кулинарную книгу и криптографию в статье ничего нет. Сверхчеловека нарисовали вы в воображении и в комментарии, в статье он не описан и даже не подразумевался. Там всё банальнее: просто сообщается, что широкий кругозор имеет ощутимое преимущество и упрощает жизнь в лонгтерме в сравнении с набором навыков, имеющих перевес в сторону инструментально-прикладного знания конкретных библиотек/фреймворков/etc. Посему, я вполне согласен с вашим тезисом про тщетность поисков суперлюдей, ибо их не было и нет… да и не нужны они.
Касаемо выбора широта-глубина знаний — это личное дело каждого. В статье нет указания о том как широко и на сколько глубоко копать. Кому как нравится, тот так и копает. Главное понимать масштабы поля и основные ориентиры знать, чтобы, при необходимости, начать копать в нужном месте. Именно эта "разметка поля" в статье и содержится.
Ну и про круговую поруку, когда доступ у всех и ответственный, якобы, никто. It depends. Далеко не всем командам подходит такое и методику раздачи ключей от танка надо выбирать сообразно людям в команде. Лично мне нравится то что у меня сейчас. Да, ответственны все и все понимают плюсы и минусы такого решения. И да, все кто видит лежащих прод тут же бегут его чинить, организуется звонок, у всех развязаны руки для экспериментов и исследования пациента. В итоге конструктив и оперативное решение любой проблемы. Зачем нужны ответственные и поиск виноватого, когда можно сосредоточиться сначала на ремонте, а потом на улучшении проекта, чтобы конкретно эта причина больше не выстрелила и не положила всё?
Ничего негативного. Ваш прод, честно говоря, больше похож на небольшой стартап на деньги инвестора, которые ему возвращать никто не собирается. В любых серьезных организациях "круговая порука" и другие модные бирюзовые эксперименты быстро заканчиваются после первых факапов, а бизнес тотчас вспоминает про старый добрый ITIL, где все давным давно уже придумали и прописали натурально кровью и потом.
Узкие специалисты в лонгтерме в целом эффективнее, чем ходячая энциклопедия, которая все знает, но ничего не умеет. Поэтому всем по-большему счету все равно, знает ли сетевик про флаги айпитейблс или нет. От него требуется корректно настроенная сеть, если он ее обеспечивает, он хороший специалист. Если при этом директор сэкономил на других инженерах и сетевик сидит крутит правила айпитейблс для докера, то у него и сеть будет средненькая, и докер хреновенько будет работать. Крылов не зря же написал свою басню в 1813 году еще про щуку и кота. Не зря же нейрохихург всю жизнь учится выполнять только одно дело в своей жизни, но выполнять ювелирно и профессионально. И времени у нейрохирурга на детальное изучение и разработку ПО, которое ему помогает, совсем нет.
На работе в целом не за кругозор платят, а за выполнение рабочих обязанностей, четко прописанных в соответствующих документах. Человек, сконцентрированный на своих обязанностях выполняет работу лучше, чем абстрактный мастер на все руки. И чем сложнее обязанности, тем их будет меньше и меньше.
В целом все методики уже давно выработаны, что подходит командам, что не подходит, это все давно известно и опций там не особо много. Размытая ответственность - это антипаттерн, либо прихоть бизнеса, который может себе это позволить, их немного. Все остальное подчиняется четким законам давным давно известным, противиться этому глупо. Такие дела.
Кажется, у нас с вами просто разные миры и мы не сойдёмся. Моему текущему "стартапу" уж 9 годиков. Вполне норм живётся с плоской командой и с периодическими факапами на проде. Желания что-то серьёзно менять и закручивать гайки пока нет. Но, у каждого свой субъективный опыт и это ничем не перекрыть.
А ещё вы как-то очень бодро отрываете причину от следствия. Отчего же хороший кругозор и внушительный набор знаний должен быть не связан с хорошим результатом? Имхо, это очень взаимосвязанные вещи и нельзя глубоко копнуть не расширив кругозор по пути.
Да все просто, рабочих часов в неделю всего сорок. И если программист сидит и ковыряется там, где сэкономили на админе, он пишет меньше кода, чем тот, который только пишет код. "Плоские команды" и другой трешачок может и по-другому работают, но сейчас при всей перегретости рынка при выборе секта или вменяемый работодатель, люди выберут таки второй вариант. Мотивация сесть и обняться, а потом всю ночь обняться и дебажить прод, к счастью перестает работать. И все эти разговоры, что же должен уметь сеньор, да все он должен уметь, а еще он прод дебажит на горячую, это все неуклюжие попытки сэкономить на персонале, они обычно заканчиваются весьма плачевно для стейкхолдеров.
Уж не знаю, где вы берете таких сотрудников, сложно судить без каких-либо деталей. Так можно, но зачем, когда за вменяемые деньги сейчас без всяких усилий можно просто найти работу с нормальными процессами, спокойно там работать и спокойно зарабатывать на смузи и красный мотоцикл, без вот этого всего.
А эта статья точно в 2022 написана?
Ни слова про облака и контейнеризацию. Сейчас можно считаться сеньором без этих знаний?
Имхо, можно. Облака и контейнеры — не панацея. Да, они набирают обороты (ну или уже набрали?), но ничего принципиально нового там нет и далеко не все их используют. Разве что матчасть про виртуализацию подтянуть, начиная с chroot и продолжая nspawn и его сотоварищами. А дальше уж под конкретную задачу довольно оперативно можно подстроиться. Опять же, статья больше про фундамент и про его гибкость и широкие приспособительные возможности, а не про конкретные штуки, которые пользуют (или не пользуют) в нашей сфере.
"Карьера автора начиналась, когда руби 1.8.7 маячил на горизонте..." - лет пятнадцать назад, я прав?
В прошлом тысячелетии, мне как-то пришлось администрировать Vax VMS и поддерживать ПО в актуальном состоянии, написанное преимущественно на фортране... Никогда не пытался найти своё место в этом табеле о рангах, но внимательно пролистал статью и теперь думаю: "Может я уже - Бог?"
Что нужно знать, чтобы быть синьором?