Комментарии 281
А я легко нанимаю джунов :)
В мобильной разработке сложилась такая ситуация, что сеньоры стоят очень дорого, а мидлов не существует.
Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.
Забавно выглядит, когда человек, называющий себя Middle Android Developer, не может ответить на простой вопрос — «Когда лучше использовать Array List, а когда Linked List?».
Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?
В мобильной разработке сложилась такая ситуация, что сеньоры стоят очень дорого, а мидлов не существует.
Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.
Забавно выглядит, когда человек, называющий себя Middle Android Developer, не может ответить на простой вопрос — «Когда лучше использовать Array List, а когда Linked List?».
Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?
Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?
Легко, можно писать на Unity и C#. У нас успешная команда, которая так делает уже более пяти лет.
Хотя, это скорее шутка, конечно эти знания нужны.
Да вообще без вопросов :)
Мы со своим уставом в чужой монастырь не ходим.
Как только появится методика успешной интеграции Android-приложений написанных не на Java\Kotlin с VMWare AirWatch, так мы сразу и начнём рассматривать такие варианты.
Мы со своим уставом в чужой монастырь не ходим.
Как только появится методика успешной интеграции Android-приложений написанных не на Java\Kotlin с VMWare AirWatch, так мы сразу и начнём рассматривать такие варианты.
А что это меняет? Когда лучше использовать List, а когда LinkedList?
List лучше использовать примерно всегда.
Плохой ответ, потому что не показывает, действительно ли вы знаете разницу, или просто никогда не задумывались.
Я представляю разницу довольно хорошо. Я загимаюсь спортивным программированием, где концетрация алгоритмов и структур данных вроде как сильно выше. Но кейсов для связного списка ни разу не видел. Следует помнить, что этими 2 выбор не ограничен. Как уже писали где-то выше, прежде чем поработать с серединой ее нужно найти. Исходя их этого я вангую, что на практике полезны более хитрые вещи типа корневой или декартова дерева.
А вот это хороший ответ, хоть вы прямо ответ на вопрос и не озвучиваете :)
Аналогично. Думал что может я что-то упускаю, но оказывается мое мнение не единственное. Хотя может просто задач подходящих не было.
Если у тебя два листа/стека с использованием LinkedList, то ты можешь из замерджить в O(1), вместо того, чтобы создавать новый массив и копировать все данные туда O(n)
Ну и конечно, когда хочешь удалить элемент в O(1) имея handle/pointer. Например с помощью HashMap и LinkedList можно написать LRU Cache
Ну и конечно, когда хочешь удалить элемент в O(1) имея handle/pointer. Например с помощью HashMap и LinkedList можно написать LRU Cache
А можно использовать LinkedHashMap и не писать велосипедов. Это О(1) для связного списка разбивается об реальные данные.
Ну так LinkedHashMap уже использует LinkedList under the hood. Я не говорю писать костыли, я говорю где это может быть полезно. Хорошо что java имеет такие классы в стандартной библиотеке. Вопрос LinkedList или Array/Vector не ограничивается языком.
Например С++ не имеет LinkedHashMap.
Костыли есть костыли, а конценты есть концепты.
Ты на интервью также скажешь?
Например С++ не имеет LinkedHashMap.
Костыли есть костыли, а конценты есть концепты.
Ты на интервью также скажешь?
Ну так есть уже LRU класс в джаве, зачем думать
Например С++ не имеет LinkedHashMap.
а чем boost::multi_index не устраивает? конечно boost это не STL, но для плюсов уже практически стандартная библиотека если чистого STL вдруг начинает нехватать
Нет, LinkedHashMap не использует LinkedList. Там внутри особая реализация. Просто потому что LinkedList в том виде в котором представлен в стандартной библиотеке Java совершенно бесполезен.
Парсинг и push/pop в дерево в целях быстрого анализа.
в подавляющем большинстве случаев связные списки даже на «своих» задачах оказываются медленнее массивов из-за лишних аллокаций/деаллокаций и принципов работы кеша.
Это отличное утверждение и действительно часто так и бывает, с этого момента интервью перестает томным… И вам предстоит показать и доказать, почему же разные имплементации имеют теоретически разное время выполнения, а на практике это оказывается не так заметно.
Что, извините, за бред? Оба списка имеют конкретные сценарии применения и разница в скорости и нагрузке на память (особенно в присутсвии сборщика) могут различаться на порядок. Это не учитывая что у обоих разные интерфейсы.
Просто всегда употребляй ArrayList и не думай)))
Судя по всему, комментатор чуть выше так и делает :)
Только ситхи возводят все в абсолют.
Если профилирование покажет, что замена ArrayList на LinkedList дает выигрыш в производительности, то можно и заменить.
Но ситуации, когда применение LinkedList оправдано, крайне редки.
О том и речь, чтобы сделать выбор в пользу какого-то из листов, да даже чтобы понимать необходимость этого выбора, нужно осознавать наличие и различия вариантов.
А вот интересно, насколько много людей которые на java пишут не видят между ними разницы? Я хоть не джавист, но по идее даже по названию предположить можно что LinkedList это связный список, а ArrayList динамический массив, что за собой влечет разную асимптотику на одни и те же операции.
Да. Но эти случаи есть это раз, а два — лично я, например когда пишу на 1с, предпочитаю выбирать то что больше подходит (что конечно не отменяет последующего профилирования), если сценарии использования объекта заранее известны и выбор структуры можно сделать за несколько секунд. В итоге самому же приятнее от написанного кода.
Серьезно? Секунды выбора между двумя структурами это трата времени 90% которого уходит на разные согласования и выяснения бизнес-требований?
Ну вообще да, я скорее про это и говорю. Во первых по наитию примерно выбирать структуру данных + во вторых не пугаться почему вдруг кусок кода стал тормозить и знать на что ее можно поменять.
А вообще я вопрос то изначальный больше задал по причине того что неясно: ответить на вопрос люди не могут из за того что внутрях лежит то что названию не соответствует, или же просто не могут в принципе ответить? Во втором варианте это выглядит странно, уж если 1сник без образования программиста разницу между этими структурами знает…
А вообще я вопрос то изначальный больше задал по причине того что неясно: ответить на вопрос люди не могут из за того что внутрях лежит то что названию не соответствует, или же просто не могут в принципе ответить? Во втором варианте это выглядит странно, уж если 1сник без образования программиста разницу между этими структурами знает…
В описываемом случае, это как раз выбор.
Я полагаю, что разработчик знает, зачем создаёт список.
И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.
Я полагаю, что разработчик знает, зачем создаёт список.
И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.
И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.А смысл? Пока у нас список не стал очень длинным, ArrayList во всех этих кейсах будет эффективнее и по скорости, и по памяти
Пока у тебя не миллион этих листов, по миллиону операций с каждым в секунду.
Это называется «отсутствие понимания задачи» и отличать это от преждевременной оптимизации довольно важно. Считать любую оптимизацию «преджевременной» — явный признак недостатка опыта.
Так у нас тут все случаи вымышленные, мы же о чистой теории говорим.
А на практике я не раз и не два сталкивался с ситуацией когда система спроектирована не была, потому что «время потраченное на проектирование это время не потраченное на написание кода, а нам платят за код», и в итоге, внезапно, работала на тестовом наборе данных, и висла подумать на десяток секунд в реальном мире. И переписать это все стоило больше чем написать с нуля.
А на практике я не раз и не два сталкивался с ситуацией когда система спроектирована не была, потому что «время потраченное на проектирование это время не потраченное на написание кода, а нам платят за код», и в итоге, внезапно, работала на тестовом наборе данных, и висла подумать на десяток секунд в реальном мире. И переписать это все стоило больше чем написать с нуля.
Всего десяток секунд? Я видел случаи когда система на десятки минут зависала, а после переписывания буквально пары десятков строк работала за доли секунды над теми же задачами.
Вот хорошо когда можно переписать что-то одно и все хорошо. А когда ключевой момент системы построен по принципу «вроде не виснет при передаче hello world, а значит и многокилобайтные файлы схавает», это все только выкинуть, вместе с тем человеком который решил время на предварительную оптимизацию не тратить, а, условно, передавать каждую букву отдельным https пакетом (не, ну а чо, работает же).
А это у вас откуда такая статистика замечательная взялась?
Вот я открыл код, а там есть массивчик, который, в нормальное время, состоит из любого количества элементов от одного до пары миллионов. И поделать с этим что-то все-таки надо.
Вот я открыл код, а там есть массивчик, который, в нормальное время, состоит из любого количества элементов от одного до пары миллионов. И поделать с этим что-то все-таки надо.
Открыл проектик. Там сразу же рядом. Stack и Dictionary, на подходе Queue и все для того чтобы избежать решения в лоб, которое дает 2Gb съедаемой памяти на транзакцию, против 2Mb на решении, с использованием всех этих структур.
Как я понимаю, умение именовать коммиты и не фигачить в мастер тоже приходит, но попозже? https://github.com/surikov/riffshare/commits/master
Как я понимаю, вы работали всегда в небольших проектах. И тут у вас опыт, бесспорно есть. Однако не стоит говорить снисходительно о других людях, особенно, когда собственное резюме и код "не для гугла — у меня свой проект".
Ну давай рассмотрим ваши продукты и решим, есть ли у вас право быть экспертом про «качественные продукты».
Я посмотрел. Все продукты это «пишу сам для себя, но в github». Коммиты test-test-63-catalog-catalog. И так во всех проектах. Комиты не атомарны. Магические константы. Прикольная сложность функций:
Это ведь полностью ваш код. Без поддержки legacy и прочего. Но, как известно, некоторый код становится legacy сразу, как его написали.
На мой взгляд, у вас очень «местничковый» опыт. И мало, либо нет вовсе опыта работы в команде. Что для программиста критично. Можно, конечно, говорить о том, «зато у меня свой продукт и полный контроль!» Да, с чем вас и поздравляю.
Но это не мастерство программиста — это принятия себя в качестве «хочу тихо кодить и чтобы никто не мешал». То же путь.
Но тогда уж не судите других. Поверьте, тут, на Хабре, очень много людей, собеседование с которыми вы бы не выдержали, как программист или руководитель проекта.
Я посмотрел. Все продукты это «пишу сам для себя, но в github». Коммиты test-test-63-catalog-catalog. И так во всех проектах. Комиты не атомарны. Магические константы. Прикольная сложность функций:
if (slides) {
if (slides.length > 0) {
envelope.audioBufferSourceNode.playbackRate.setValueAtTime(playbackRate, when);
for (var i = 0; i < slides.length; i++) {
var newPlaybackRate = 1.0 * Math.pow(2, (100.0 * slides[i].pitch - baseDetune) / 1200.0);
var newWhen = when + slides[i].when;
envelope.audioBufferSourceNode.playbackRate.linearRampToValueAtTime(newPlaybackRate, newWhen);
}
}
}
Это ведь полностью ваш код. Без поддержки legacy и прочего. Но, как известно, некоторый код становится legacy сразу, как его написали.
На мой взгляд, у вас очень «местничковый» опыт. И мало, либо нет вовсе опыта работы в команде. Что для программиста критично. Можно, конечно, говорить о том, «зато у меня свой продукт и полный контроль!» Да, с чем вас и поздравляю.
Но это не мастерство программиста — это принятия себя в качестве «хочу тихо кодить и чтобы никто не мешал». То же путь.
Но тогда уж не судите других. Поверьте, тут, на Хабре, очень много людей, собеседование с которыми вы бы не выдержали, как программист или руководитель проекта.
Мои реальные проекты имеют отношение к распределенным базам данных. Поверьте, у меня всякие структуры данных и выбор их критичен. Нам приходится выбирать, в частности, между тем, какой именно вид Bloom filter нам подойдет лучше по API, ассимпротике на разных объемах данных.
Но все же. Вы тут судите, как эксперт. Позвольте уж и другим спецам высказаться, но уже насчет вашего опыта, кода и, соответственно, права судить и весомости вашего суждения.
Что код приведен выше ваш вы не отрицаете. Значит народ сможет посмотреть и сложить мнение.
Но все же. Вы тут судите, как эксперт. Позвольте уж и другим спецам высказаться, но уже насчет вашего опыта, кода и, соответственно, права судить и весомости вашего суждения.
Что код приведен выше ваш вы не отрицаете. Значит народ сможет посмотреть и сложить мнение.
Попробую медленно.
В проектах, в которых работаю я. Разница есть. Ее нет, если делать web странички — это да.
Например, от замены одного типа дерева на другое мы получили выигрыш в prune операции на порядок, что позволило начать меньше места жрать на диске пользователя, который бывает и мобильным в том числе. Реальный проект, реальный пример.
Поймите, вы судите только со своей колокольни и очень резко. Ваша резкость мало соотносится с реальным опытом программиста и качеством кода. Поэтому выглядит нелепо.
Разница очень существенна. С ней начинаешь понимать, что понятие «преждевременной оптимизации» относительное и для одного «преждевременная» — это давайте все делать в массивах, а после посмотрим, где окажется узко, и это сработает на многих проектах; а для других непреждевременной оптимизацией будет на минутку посидеть над новым методом и подумать, а как часто его будут дергать, сколько данных можно ожидать сразу, через год, через два и прикинуть подходящий тип данных, тоже без кропотливых исследований, но все же подумать и снизить вероятность критичной ошибки.
В проектах, в которых работаю я. Разница есть. Ее нет, если делать web странички — это да.
Например, от замены одного типа дерева на другое мы получили выигрыш в prune операции на порядок, что позволило начать меньше места жрать на диске пользователя, который бывает и мобильным в том числе. Реальный проект, реальный пример.
Поймите, вы судите только со своей колокольни и очень резко. Ваша резкость мало соотносится с реальным опытом программиста и качеством кода. Поэтому выглядит нелепо.
Разница очень существенна. С ней начинаешь понимать, что понятие «преждевременной оптимизации» относительное и для одного «преждевременная» — это давайте все делать в массивах, а после посмотрим, где окажется узко, и это сработает на многих проектах; а для других непреждевременной оптимизацией будет на минутку посидеть над новым методом и подумать, а как часто его будут дергать, сколько данных можно ожидать сразу, через год, через два и прикинуть подходящий тип данных, тоже без кропотливых исследований, но все же подумать и снизить вероятность критичной ошибки.
А на что вы мне предлагаете поменять Stack или Dictionary?
> Это приходит с опытом.
Разумеется.
> Это приходит с опытом.
Разумеется.
Или, вернее, безуспешно пытаются продать себя, как эксперта с весомым мнением.
хорошо. освежим вашу память.
вы заявили
> Нужно просто открыть код над которым он работал сегодня и
> посмотреть есть ли там миллионы списков.
> их нет.
я вам ответил
> Stack и Dictionary, на подходе Queue и все для того чтобы
> избежать решения в лоб
вы начали слегка подхамливать, но кроме того предложили их заменить:
>Насколько я понимаю, вы, как и предыдущий оратор, не
>можете изменить «свой» код и проверить как смена одного
>типа списка на другой влияет на конечный результат.
Я попросил вас уточнить на что же я должен поменять Stack и Dictionary
Вы предлагаете мне читать ваши мысли?
Вот вы всем тут про ваш опыт рассказывали. Не расскажите сколько лет стажа и какого размера комманды были, в которых вам довелось работать?
вы заявили
> Нужно просто открыть код над которым он работал сегодня и
> посмотреть есть ли там миллионы списков.
> их нет.
я вам ответил
> Stack и Dictionary, на подходе Queue и все для того чтобы
> избежать решения в лоб
вы начали слегка подхамливать, но кроме того предложили их заменить:
>Насколько я понимаю, вы, как и предыдущий оратор, не
>можете изменить «свой» код и проверить как смена одного
>типа списка на другой влияет на конечный результат.
Я попросил вас уточнить на что же я должен поменять Stack и Dictionary
Вы предлагаете мне читать ваши мысли?
Вот вы всем тут про ваш опыт рассказывали. Не расскажите сколько лет стажа и какого размера комманды были, в которых вам довелось работать?
Открыл. Вижу десятки деревьев разных видов, есть списки в каком-то кэше с ограничением длины в 100к, небольшой кэш, видимо.
Думаю, эти разные структуры данных тут неспроста. Оставлю, пожалуй.
Откуда этот вопрос? Вы спросили про структуры данных, вам дал ответ. А теперь вы делаете какой-то необоснованный вывод.
Как и у вас, все open source, и "все ориентированы на продукт" и прочая. Поменять код не проблема, только вот эти типы данных живут тут неспроста, уже были добрые люди "давайте сделаем сразу проще" и после все умирало или жило криво до безбожности в конкурентном коде. И вот уже или люди поумнели, или поменялись и сначала читаем умные статьи про наши кейсы и ищем подходящие структуры данных. Ибо менять все по многу раз — это довольно больно.
это называется «преждевременная оптимизация». Явный признак недостатка опыта.
Вы ещё скажите, что программист, который ради одной простой одноразовой функции, например, преобразования числа в hex, не подключает многомегабайтные фреймворки, а просто пишет эту функцию за минуту, тоже неопытен, потому что не умеет пользоваться чужим кодом.
Кстати, отличие опытного программиста от неопытного заключается в том, что опытный программист заранее знает, какие места могут быть узкими и могут быть соптимизированы, но сознательно реализовывает их более быстрым, но менее оптимальным образом.
А может это у вас «преждевременная пессимизация»?
Напишите на каждую из структур тест в котором сперва создаете список на 100,000 элементов арифметической прогрессии. И напишите тест который складывает эти числа с первого до последнего.
И сравните результат. После этого надеюсь вы перестанете писать чушь про сотые доли процента.
В сообщении, на которое вы отвечаете, есть пометка «в реальности». В реальности для подсчета суммы арифметической прогрессии нужно воспользоваться формулой, а человеку, который додумается сделать по вашему сценарию, нужно настучать клавиатурой по рукам. Больно.
Давайте не сумму а квадратичное отклонение. И не прогрессия а клиент присылает на сервер (дабы не было предположений о данных)
Но забавляет ваше желание сломать об ваше представление о реальном программировании мой сугубо академический пример придуманный чтобы показать что такое кеш мисы и как сильно может отличаться константа у алгоритмов (полный прямой обход) в структурах с одинаковой асимптотикой.
Но забавляет ваше желание сломать об ваше представление о реальном программировании мой сугубо академический пример придуманный чтобы показать что такое кеш мисы и как сильно может отличаться константа у алгоритмов (полный прямой обход) в структурах с одинаковой асимптотикой.
мой сугубо академический пример
Придти с
Так что в этом вся и суть — придумать можно очень много разных фантастических сценариев, но имхо на практике в большинстве случае вам либо побоку производительность списка, потому что её вклад в конечный результат исчезающе мал, либо вы не пользуетесь списками в принципе.
Япредлагаю отсортировать стандартным библиотечным способом LinkedList из 1000000 элементов и ArrayList с точно таким же контентом и почувствовать разницу по скорости.
В том-то и дело)
Процентов 40 собеседуемых, могут перевести название, но объяснить в каком случае какой лист надо использовать не могут.
Процентов 40 собеседуемых, могут перевести название, но объяснить в каком случае какой лист надо использовать не могут.
Увы, значительное количество не знает ответа на этот вопрос, даже если его поставить более прямолинейно: «Где быстрее поиск N-го элемента в массиве или односвязном списке»? Хотя по насчет разбивки по языкам спекулировать не буду.
Написал несколько проектов (эмуляторы игровых автоматов) под Android на Haxe. Java, впрочем, более-менее знаю (в основном J2ME и десктоп), но скорость не та, а Haxe компилируется в натив. На Middle Android Developer видимо не потяну, формального ответа не знаю.
Когда лучше использовать Array List, а когда Linked List?
Ответ «никогда не используйте LinkedList» принимается?
Нет. Потому что я вот лично встречал ситуации когда приходилось менять с аррайлиста на линкедлист. Там требовалось в памяти держать ооочень длинные массивы, при попытке добавить новый элемент в аррайлист рано или поздно происходило перевыделение массива и оно падало, так как не могло выделить непрерывный кусок памяти достаточно большого размера из-за фрагментации (при том что суммарно свободной памяти хватало, и линкедлист нужного размера там отлично умещался).
Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.
Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.
Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.
Разве что только вы использовали для этого итератор в случае LL что может быть эффективно только лишь если большая часть удалений происходит пакетами в примерно одном месте, а не в случайном порядке. Насколько я видел бенчмарки итерация через LL для того что бы удалить элемент будет все равно медленнее чем нативный arraycopy с рандомакссес.
Первый случай довольно редок и как по мне это попытка переложить проблему GC на логику приложения. Как костыль сойдет, как общая рекомендация ни в коем случае.
А не эффективнее ли было аллокатор инициализировать правильным значением, чем расходовать по указателю на каждый элемент? Я, конечно, не знаю какого размера у вас в списке структуры лежали.
Если лично я встречу подобную ситуацию — я не буду переписывать на LinkedList, а сделаю особый контейнер под задачу. LinkedList не позволяет быстро искать элемент списка по его значению (для той самой вставки в середину), и неэффективно расходует память.
У меня на практике был только один сценарий использования LinkedList — планировщик задач, а точнее, хранение очереди подписчиков на события, которых может быть довольно много, и которые подписывались-отписывались очень часто (практически при каждом событии).
А разве ArrayList заалоцированый с запасом не даст лучший результат?
А как вы их отписывали? Если каждый раз искать нужный обработчик в LinkedList — то удаление будет немногим быстрее чем удаление из ArrayList. Если отписывать только крайние обработчики, то лучше использовать ArrayDeque.
Если же отписывался обработчик по время выполнения — то не быстрее ли создать новый ArrayList, и добавлять туда те обработчики, которые забыли отписаться?
Если же отписывался обработчик по время выполнения — то не быстрее ли создать новый ArrayList, и добавлять туда те обработчики, которые забыли отписаться?
А если я пишу прогу с графическим интерфейсом и хочу сделать список кнопок, то какой из этих двух выбрать?
Зависит от того, что Вы с этим списком будете дальше делать.
javarush.ru/quests/lectures/questsyntax.level08.lecture05
javarush.ru/quests/lectures/questsyntax.level08.lecture05
Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.Как же приятно встретить адекватного человека на хабре, ваши слова просто бальзам на душу
Когда лучше использовать Array List, а когда Linked List?Тут полезно знать мнение автора LinkedList в Java
Вообще это кстати очень хороший вопрос, условные джун, мидл и синьер дадут на него сильно разные ответы
А как с вами связаться?:)
А сколько таких примеров возможно придумать в принципе, и не стоят ли они ломаного гроша, в плане что это можно объяснить любому достаточно быстро, главное иметь достаточную аргументацию, раз уж она накоплена опытом, нет? И это будет быстрее чем искать того самого ненаглядного сеньора, который теоретически вот вот должен прийти в эту замечательную компанию бросив все остальные, ведь в остальных ему так мало платят и он такой несчастный?.. )))
Есть мнение, что LinkedList надо использовать примерно никогда
Блин, ты меня описал, знаю именно эти паттерны(еще MVVM) и эти библиотеки(+ другие по мелочи вроде дагера, батернайфа и подобного), правда до сих пор не уверен дошел ли я хотя бы до джуна…
Особенно смешит когда ищут сеньоров с минимум 5 годами опыта работы с языком, который появился 5 лет назад) По Go видел вакансии только на сеньоров, при том что еще 3-4 года назад на том же хабре его обсуждали как некий экзотичный язык, игрушку, которая вряд ли будет когда то использоваться в продакшене)
пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости
Смелое заявление, к реальности не имеющее отношение к сожалению.
Не учтены такие вещи, как:
— Отвлечение сеньора на консультации
— Предварительное программирование на русском с переводом всего этого в программный код
— Готовность к нескольким этапам переделок.
В рамках статьи программисты воспринимаются, как некоторые черные ящики, которые на входе принимают кофе с тасками, а на выходе — код. Как бы вам не хотелось, это не так. Еще Брукс доказал, что введение даже равного специалиста в команду, сильно ее охлаждает. В статье же утверждается, что полтора программиста дадут выхлоп 150%, что противоречит Бруксу. В реальности эта цифра ближе к 110%, если вообще не ниже 100%, если джун совсем деревянный попался, или приходится менторить нескольких джунов.
Несмотря на некоторые спорные аргументы, в целом, с выводом статьи, согласен — в компаниях, которые не тратятся на развитие человеческого капитала, делать нечего — ни сеньорам, ни джунам.
Вывод вне контекста правильный, но вот делать его только из того что компания не хочет нанимать именно джунов — уже нет. Компания вполне может заморачиваться развитием разработчиков, но при этом нанимать разработчиков уже с опытом. Даже сеньорам есть куда развиваться обычно.
> Не учтены такие вещи, как:
да эти 75% — вообще цифра из головы, че тут рассуждать
как и все рассуждения автора
судя по разделу about на сайте оригинальной статьи:
> I’m a software developer, a family man, a B.A. in English, and a Mormon. My writing is motivated by all of these things.
автор похоже все исследования провел в голове, сделал свои выводы и написал статью
да эти 75% — вообще цифра из головы, че тут рассуждать
как и все рассуждения автора
судя по разделу about на сайте оригинальной статьи:
> I’m a software developer, a family man, a B.A. in English, and a Mormon. My writing is motivated by all of these things.
автор похоже все исследования провел в голове, сделал свои выводы и написал статью
Не вижу проблемы. Не нанимают джунов одни — наймут другие: сеньоров на всех не хватит, и кому-то придётся учить своих. Так что в целом по индустрии найм джунов никуда не денется, а требовать его от конкретной конторы и делать о ней какие-то выводы на основании отказа — глупо.
P.S. Imho, в первую очередь найм джунов — это «хочешь стать женой генерала — выйди замуж за лейтенанта». Только тут всё быстрее — видел, как люди всего за пару лет раскрываются, не сильно косяча в процессе. Но из скольких надо выбирать для этого?
P.S. Imho, в первую очередь найм джунов — это «хочешь стать женой генерала — выйди замуж за лейтенанта». Только тут всё быстрее — видел, как люди всего за пару лет раскрываются, не сильно косяча в процессе. Но из скольких надо выбирать для этого?
Так и не увидел какую ошибку совершил Нетфликс и как это им помешало.
Может он просто уволился, видя и картину происходящего
Судя по профилю на линкедине — автор сам еще порядочный «джуняра» (психологически), программировать начал менее 3-х лет назад, а до этого сидел в QA. Видимо, пока не пристроился в свою HealthCatalyst (а это не софтверная компания), пережил немало отказов из-за отсутствия практического опыта.
По моему, его первая работа многое объясняет — Демократическая партия США. Его Ильхан Омар укусила.
Возможно у Вас собеседовался разработчик не уровня «Middle»?
И столько компаний ищут разработчиков уровня «Middle», а оказывается, они не существуют в природе.
И столько компаний ищут разработчиков уровня «Middle», а оказывается, они не существуют в природе.
Все аргументы — философское бла-бла и натягивание совы на глобус.
Описанный подход очень логичен и имеет право на существование.
Что, конечно же, абсолютно не значит, что не может быть других подходов.
Описанный подход очень логичен и имеет право на существование.
Что, конечно же, абсолютно не значит, что не может быть других подходов.
Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.
Netflix может передумать в любой момент и начать джунов набирать и учить. Описанные же товарищи, если решат поменять ситуацию, потратят на разворот хорошо если год, по дороге растеряв половину набранных и худо-бедно разбирающихся в происходящем людей.
Netflix может передумать в любой момент и начать джунов набирать и учить. Описанные же товарищи, если решат поменять ситуацию, потратят на разворот хорошо если год, по дороге растеряв половину набранных и худо-бедно разбирающихся в происходящем людей.
Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.
Это уже особенности ведения бизнеса по-русски, где не считается нормальным, когда специалисты зарабатывают больше начальников.
Существует всего две причины нанимать джунов: хорошая и плохая.
Джунам можно платить меньше. Это плохая причина. Потому что важно не сколько вы платите, а сколько получаете на потраченный рубль. От синьора вы получите больше.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
Сеньоров не нанять. Это действительно причина. Если вам нужно много программистов, то может оказаться дешевле выучить их самим.
Если же вам нужно нанимать одного двух в год, то можно и подождать пока появится подходящий.
Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.
Джунам можно платить меньше. Это плохая причина. Потому что важно не сколько вы платите, а сколько получаете на потраченный рубль. От синьора вы получите больше.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
Сеньоров не нанять. Это действительно причина. Если вам нужно много программистов, то может оказаться дешевле выучить их самим.
Если же вам нужно нанимать одного двух в год, то можно и подождать пока появится подходящий.
Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.
Если джунам не дать в помощь никого, могут и вообще не справиться.
Джуны справятся, но стоить это будет дороже.
Это сильно зависит от области и конкретных задач. Условно говоря, шлепать однотипные формочки — это задача больше механическая, и может больше зависеть от скорости печати чем от квалификации.
Вы недооцениваете таланты, коими богата страна. Я иногда, глядя в чужой код, ловлю себя на мысли, что не смог бы придумать такую дичь даже нарочно.
Не, ну я же не предлагаю просто взять пачку джунов, дать им стопку задач и забыть про них на месяц. Код-ревью, разбиение на небольшие задачи. Первое время, естественно, обратная связь будет отнимать много времени, но если джуны толковые — эти затраты довольно быстро сократятся.
И повторюсь — такой подход подойдет не всем и не на каждом проекте.
И повторюсь — такой подход подойдет не всем и не на каждом проекте.
Т.е. все равно пока джуны не дорастут хотя-бы до мидлов на них будут тратить время сеньоры?
Конечно будут. И мидлы будут, и другие сеньоры (код-ревью и всё такое). Вопрос в пропорциях.
Чтобы говорить предметно: мы занимаемся мобильной разработкой. На приложение есть дизайн, спецификации на поведение и сеть. В самом приложении — куча типовых компонентов. Нужно сделать новый экран? Вот типовой класс, наследуйся, добавляй разметку и поведение. Персистентность? Вот типовой компонент, пропиши тип кеша, тип данных и используй. Запросы? Вот типовой… ну вы поняли. Это механическая работа, перемежаемая периодическими контактами с дизайнерами/аналитиками на предмет уточнить или добавить или поправить что-либо; для неё не нужно уметь проектировать высоконагруженные системы.
Можно ли вместо найма джуна написать суперфреймворк, который сам будет генерировать большую часть приложения по файлам с дизайном и документам со спецификациями? Мб можно, но джун дешевле. Можно ли посадить сеньора вписывать отступы и перебрасывать модели из одного компонента в другой? Можно, но джун дешевле, а сеньор может и сбежать от такой рутины.
Чтобы говорить предметно: мы занимаемся мобильной разработкой. На приложение есть дизайн, спецификации на поведение и сеть. В самом приложении — куча типовых компонентов. Нужно сделать новый экран? Вот типовой класс, наследуйся, добавляй разметку и поведение. Персистентность? Вот типовой компонент, пропиши тип кеша, тип данных и используй. Запросы? Вот типовой… ну вы поняли. Это механическая работа, перемежаемая периодическими контактами с дизайнерами/аналитиками на предмет уточнить или добавить или поправить что-либо; для неё не нужно уметь проектировать высоконагруженные системы.
Можно ли вместо найма джуна написать суперфреймворк, который сам будет генерировать большую часть приложения по файлам с дизайном и документам со спецификациями? Мб можно, но джун дешевле. Можно ли посадить сеньора вписывать отступы и перебрасывать модели из одного компонента в другой? Можно, но джун дешевле, а сеньор может и сбежать от такой рутины.
Вот тут и нужен опытный разработчик.
Чтобы написать скрипт/фреймворк и перестать шмалять однотипные формочки.
Чтобы написать скрипт/фреймворк и перестать шмалять однотипные формочки.
и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже
Почему? Написать вагон бойлерплейта или пофиксить какие-нибудь мелкие баги джун вполне может. Он потратит больше времени, но в итоге оно может оказаться все равно дешевле.
Тут впрочем опять непонимание что такое «джун», так как формальных критериев никаких нет и каждый трактует как хочет. Если считать что это человек с нулевым опытом и посредственным знанием синтаксиса языка — то да, там лиду придется больше объяснять ему, чем если бы он взял и сделал сам. Но если это человек хотя бы с годом опыта работы, то мелкие задачи он может делать сам, и даже более-менее качественно (особенно если в компании реально используют всякие автоматизированные метрики качества — статический анализ, тесты и т.п., которые позволяют отсекать совсем уж криворукий новичковый говнокод без участия сеньоров)
Дороже это может начать стоить, когда написанное понадобится расширить. По метрикам качества есть сомнения. Если сеньоров нет, то реализация этих метрик с большой долей вероятности будет такой же, что и код. Тем более, я лично не очень представляю автоматическую оценку расширяемости.
Написать вагон бойлерплейта
Не нужно писать вагоны бойлерплейта.
пофиксить какие-нибудь мелкие баги
Дешевле не будет, будет долше и все равно нужен синиор который отревьювит, объяснит как правильно. В конечном итоге потратив времени больше чем если бы сам фиксил баг.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.А сеньоры поделают некоторое время джуновские таски, потом развернутся и уйдут. Потому что им у вас будет уже неинтересно.
Не бывает джуновских тасков.
Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
>> Не бывает джуновских тасков.
У вас разработана структура БД и есть ORM. Задача перевести эту структуру в то, что получит на вход ORM — чем не джуновская? Или с теми же формами, написать валидатор для очередной формы или добавить поле — чем не джуновская задача?
>> Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
Либо «поточное производство»
У вас разработана структура БД и есть ORM. Задача перевести эту структуру в то, что получит на вход ORM — чем не джуновская? Или с теми же формами, написать валидатор для очередной формы или добавить поле — чем не джуновская задача?
>> Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
Либо «поточное производство»
Первую задачу я не понял.
Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.
Поточное производство напрашивается на автоматизацию.
Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.
Поточное производство напрашивается на автоматизацию.
>> Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.
Во-первых, BA может и не быть. Во-вторых, в конфиг легко выносятся простые случаи, если же поля зависимы, то этот конфиг может превратиться в тьюринг-полный редактор макросов, который надо поддерживать, который непонятно когда окупится и в которым не факт, что пользователи захотят разбираться (и в итоге будет такая же джуновская задача по вбиванию условий в этот редактор). Ну и, банально, стоимость времени BA на «поиграться» может легко превысить стоимость правки кода.
>> Поточное производство напрашивается на автоматизацию.
То же самое, в конечном итоге все упрется в окупаемость. На заводе тоже не все гайки закручивают роботы.
Во-первых, BA может и не быть. Во-вторых, в конфиг легко выносятся простые случаи, если же поля зависимы, то этот конфиг может превратиться в тьюринг-полный редактор макросов, который надо поддерживать, который непонятно когда окупится и в которым не факт, что пользователи захотят разбираться (и в итоге будет такая же джуновская задача по вбиванию условий в этот редактор). Ну и, банально, стоимость времени BA на «поиграться» может легко превысить стоимость правки кода.
>> Поточное производство напрашивается на автоматизацию.
То же самое, в конечном итоге все упрется в окупаемость. На заводе тоже не все гайки закручивают роботы.
Всегда есть кто-то кто ставит задачи. Если задачи тривиальные, то и ставить их можно в формальном виде и генерить из этого код.
Так мы и говорили про простые случаи. Если случаи не простые, то это задача для сениора. Он выполнит ее быстрее и надежнее.
Спорить не буду, но что-то мне подсказывает что профессиональная машинистка будет быстрее и дешевле.
Во-вторых, в конфиг легко выносятся простые случаи
Так мы и говорили про простые случаи. Если случаи не простые, то это задача для сениора. Он выполнит ее быстрее и надежнее.
упрется в окупаемостьт.е. ваш аргумент в том что джун это не только ценный мех, но еще и бесплатная машинистка?
Спорить не буду, но что-то мне подсказывает что профессиональная машинистка будет быстрее и дешевле.
Граница между сеньорами и джунами весьма расплывчат — внезапно.
Сеньоры весьма различны. Один может проработал 10 лет на легаси проекте и спрингов в глаза не видел и тут джун его уделает легко.
Проблема оферквалифаед никуда не девалась. Сеньор, выполняющий джуновские задачи — печальное зрелище.
Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?
Сеньоры весьма различны. Один может проработал 10 лет на легаси проекте и спрингов в глаза не видел и тут джун его уделает легко.
Проблема оферквалифаед никуда не девалась. Сеньор, выполняющий джуновские задачи — печальное зрелище.
Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?
Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?
По-моему, таким страдают именно джуны.
>> собенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка.
Это не сеньор, ИМХО. В моем понимании, сеньору можно дать задачу и быть уверенным, что он ее сделает так как нужно компании. Отсутствие перерасхода времени на оверинжениринг в это «как нужно» тоже входит.
>> Сеньор, выполняющий джуновские задачи — печальное зрелище.
Согласен. Но не в плане «лучше кодит». Тут, скорее, два момента. Первое, на задачах, где производительность упирается в скорость печати, он невыгоден. Второе, он может затосковать и потратить даже больше времени, чем джун.
Это не сеньор, ИМХО. В моем понимании, сеньору можно дать задачу и быть уверенным, что он ее сделает так как нужно компании. Отсутствие перерасхода времени на оверинжениринг в это «как нужно» тоже входит.
>> Сеньор, выполняющий джуновские задачи — печальное зрелище.
Согласен. Но не в плане «лучше кодит». Тут, скорее, два момента. Первое, на задачах, где производительность упирается в скорость печати, он невыгоден. Второе, он может затосковать и потратить даже больше времени, чем джун.
Сеньору неинтересно в какой то момент становится, он начинает извращаться. И не докопаешься: например у нас он нормализовал базу по последнему уровню, так что она становится абсолютно нечеловекочитаема и непонятно никому кроме него. Да любой сеньор замучится собирать юзера по 8 таблицам, а там отмазка надо лучше учиться, база нормализована по правилам.
Первое, на задачах, где производительность упирается в скорость печати, он невыгоден.
Простите, а что это за задачи такие? Я всегда считал рабочим правило про «80% времени разработчик читает». И прочитать и понять, где нужны изменения сениор сможет сильно быстрее, нет? Хотя в с этим и не спорили, вы говорили на задачах, где скорость печати важна. Так что собственно повторюсь: это где такие задачи бывают?
Тупые «обезьяньи» задачи типа «сделать тут так же, как там, но только поменять это и это». Или даже просто «поменять это на то». В веб-разработке этого навалом. В таких задачах нечего читать и не о чем думать.
Ну почему же, можно вынести компонент/пакет/… Копипаста ведь это не единственный способ решения задач.
Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.
Если проектов много, в режиме сделали-сдали-забыли, то версии компонента в них будут разные. Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.
Если проектов много, в режиме сделали-сдали-забыли, то версии компонента в них будут разные. Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.
Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.
У меня одна из первых задач на первой работе состяла в том, чтобы написать две сотни однотипных конфигов (ну, не совсем однотипных). На задачу дали месяц. Месяц я потратил на написание генератора этих конфигов (парсинг powershell-скрипта, определение структуры конфига, и собственно генерация). После чего за 2 часа сделал все эти конфиги. В последующем, этот генератор мне не раз пригождался, и задача на день-два решалась за 15 минут.
Менеджмент тоже не видел тут массовости, просто я понимал, что каждую неделю приходят однотипные задачи. А вот руководство — не очень.
Если проектов много, в режиме сделали-сдали-забыли
Звучит очень печально.
Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.
Ага, и потом регрессия, потому что баги чинят в одних компонентах, а скопипащенные куски продолжают жить со своими багами, где их уже никто не починит, «дорого, да и сдали проект уже».
Я не совсем программист, я QA, но тем не менее очень обидно когда на российском it рынке люди не удосуживают даже копипастным ответом отклик Джуниоров на вакансию. Когда я был Джуниором это просто убивало. Сейчас я понимаю почему так происходит и что не везде так, но все равно это неправильно.
Вообще, по отношению к джунам, можно очень хорошо судить про отношению в компании к людям.
Самые большие, умные и дальновидные берут не то что джунов, но и вообще интернов со студенческой скамьи
Ключевое слово здесь: «большие». На это нужны деньги, которые могут и не вернуться, а польза сильно неочевидна. Даже средние компании не всегда могут себе позволить и почти всегда могут найти области где эти деньги дадут больший выхлоп.
Около 100 человек из которых программистов хорошо если треть. Процентов 60 сотрудников были взяты стажерами (даже джунами назвать трудно многих было). Просто в провинции выбора особого нет.
Если нет выбора, то это не дальновидность и ум, а безысходность все же. Оно конечно не отрицает одно другого, но если убрать положительные качества то ситуация останется той же, а вот если убрать безысходность и предположить ситуацию когда выбор есть — я думаю такая компания взяла бы гораздо меньше студентов. Которые из этой провинции еще и сбегут большей частью когда опыта наберутся.
Как раз самый мобильный слой населения — это свежие выпускники. Если их нанимать неопытными, то шанс, что они останутся в регионе, будет выше, чем если ждать, пока им даст опыта кто-нибудь другой.
Программа стажировок — это вклад в местную айти-экосистему, и в долгосрочной перспективе он обязательно упростит найм опытных специалистов, хотя соотношение затрат и выхлопа предсказать невозможно.
Программа стажировок — это вклад в местную айти-экосистему, и в долгосрочной перспективе он обязательно упростит найм опытных специалистов, хотя соотношение затрат и выхлопа предсказать невозможно.
Во многом согласен. Де факто мы сталкиваемся с тем, что экономия денег сейчас, вырождается в последующие траты потом. Т.к. текучка не исключена, например. На мой взгляд, думать и делать на перспективу разучились почти все.
От себя могу добавить, что когда я был «джуном», меня никто также не хотел брать. Хотя я очень быстро обучался любой под-отрасли IT. Поэтому приходилось «шляться» по «помойкам». И через пару тройку лет, меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним. Ну и соответственно, работая на них, отношение к ним такое же. Я не буду думать о благе компании, я буду думать о своем благе поплевывая на их благо. И даже злонамеренно. Ну хотя бы потому, что я их ненавижу.
Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан. Это тоже правда. Возмущает сам факт циничности. Что только когда им надо. И дело не в том что мне должны. Дело в том, что им все должны.
Я и сейчас с этим сталкиваюсь, почему то я постоянно что-то должен. Я уже не говорю о том что отпуск в 2 недели, это не отпуск. 2 недели — это отходняк. И только потом ты начинаешь отдыхать. А объясняется это тем, что компании не выгодно…
От себя могу добавить, что когда я был «джуном», меня никто также не хотел брать. Хотя я очень быстро обучался любой под-отрасли IT. Поэтому приходилось «шляться» по «помойкам». И через пару тройку лет, меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним. Ну и соответственно, работая на них, отношение к ним такое же. Я не буду думать о благе компании, я буду думать о своем благе поплевывая на их благо. И даже злонамеренно. Ну хотя бы потому, что я их ненавижу.
Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан. Это тоже правда. Возмущает сам факт циничности. Что только когда им надо. И дело не в том что мне должны. Дело в том, что им все должны.
Я и сейчас с этим сталкиваюсь, почему то я постоянно что-то должен. Я уже не говорю о том что отпуск в 2 недели, это не отпуск. 2 недели — это отходняк. И только потом ты начинаешь отдыхать. А объясняется это тем, что компании не выгодно…
Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан.
Вообще-то обязан, при найме на работу, вы, наверняка говорили об обязательствах за которые тебе платят зарплату.
Сколько я себя помню, я всегда делал больше чем по договору. Я не помню чтобы меня за это хотя бы не упрекали. И что?
Назовите мне хотя бы одного добросовестного работника, который делал строго в соответствии с договором.
И не надо путать договор с текучкой. На практике, все не по договору.
Так что договорами можно причинное место вытирать. Они ничего не стоят. Потому что вас, все равно обманут.
Назовите мне хотя бы одного добросовестного работника, который делал строго в соответствии с договором.
И не надо путать договор с текучкой. На практике, все не по договору.
Так что договорами можно причинное место вытирать. Они ничего не стоят. Потому что вас, все равно обманут.
Я работаю по договору и на все попытки запрячь меня дополнительной работой четко и твердо ответил отказом. Это не сложно, если у вас с компанией чисто рабочие отношения, в случае прекращения которых вы без проблем найдете работу.
Проблемы начинаются тогда, когда вы боитесь работу потерять или у вас не хватает силы воли сказать "нет" — вот тогда на вас сядут и поедут
Вы описываете подход работника, который делает работу на «отвяжись». Если конечно деятельность у вас не творческая. Мешки таскать, нормальный подход.
В творческой деятельности, постоянно сталкиваешься с тем что надо что-то менять, по ходу разработки того или иного. Причем менять в областях за которые ты не отвечаешь, а сделать хочешь. Потому что хочешь сделать хорошо. Все эти разговоры можно не продолжать если вы мне скажете, что я должен собрать совещание, отправить запрос, и т.д. Так, ничего сделано не будет. В лучшем случае плохо. Проверено. Я уже не говорю о том, что в рабочем порядке решается 99% вопросов. Но во что оно выродилось, мы тоже знаем. А учитывая что, мне на пути люди с подобным, вашему подходу, попадались, я знаю, что с ними работать не возможно. Их хочется только бить. Много демагогии. О договорах и прочем. Однако дело стоит.
Причем тут сила воли и отказ?
В творческой деятельности, постоянно сталкиваешься с тем что надо что-то менять, по ходу разработки того или иного. Причем менять в областях за которые ты не отвечаешь, а сделать хочешь. Потому что хочешь сделать хорошо. Все эти разговоры можно не продолжать если вы мне скажете, что я должен собрать совещание, отправить запрос, и т.д. Так, ничего сделано не будет. В лучшем случае плохо. Проверено. Я уже не говорю о том, что в рабочем порядке решается 99% вопросов. Но во что оно выродилось, мы тоже знаем. А учитывая что, мне на пути люди с подобным, вашему подходу, попадались, я знаю, что с ними работать не возможно. Их хочется только бить. Много демагогии. О договорах и прочем. Однако дело стоит.
Причем тут сила воли и отказ?
Если у вас вся компания держится на "эх ребятушки, затянем пояса" и "ну что ты, ради проекта без выходных не поработаешь", то это проблема компании, нет?
Не понимаю каким боком это имеет отношение к качеству работы
Если у вас вся компания держится на «эх ребятушки, затянем пояса» и «ну что ты, ради проекта без выходных не поработаешь», то это проблема компании, нет?
Это вообще о чем и причем?
Не понимаю каким боком это имеет отношение к качеству работы
Прямое. Объяснять надо? Лично я, судя по утверждению, не вижу смысла.
Я только добавлю, что если бы я на все что не входит в мои обязанности давал отказ, технически как специалист я не вырос бы. Я напротив, придерживался иного подхода, если просят сделать задачу и сложную, я брался. Только ради того чтобы ее решить. Потому что она сложная. Хотя в обязанности она могла и не входить. В конце концов это и на перспективу мне работает.
Иной раз, когда начальник просил(а я не со всеми из них был в хороших отношениях), я не выпендривался и делал. И отношение ко мне тоже с их стороны было соответствующее.
А ваш подход мне знаком, сугубо буржуйский. Поэтому, что касается упомянутых вами ранее поисков работы, скорее меня попросят, чем вас.
Вам что так трудно понять, что лично мне хочется строить отношения не только на деньгах? И я не единственный в этом списке. Таких людей много.
Возможно мы вообще друг друга не поняли?
Решать задачи входит в обязанности разработчика — любой сложности. Не важна сложность, не важно в каких отношениях вы с начальником — это и есть профессиональный подход, о котором я говорю. Это все часть рабочего процесса. И этот рабочий процесс описан в договоре (как правило 40-часовой рабочей неделей)
Вы упомянули работу сверх договора — в моем понимании это ситуации, когда вам приходится работать больше времени, чем указано в договоре (переработки) или заниматься непрофильной работой (таскать шкафы например). Вот против таких вещей я и выступаю. Одно дело, если вас по-человечески попросили помочь разок, другое дело, когда этот "разок" потом превратился в данность.
Вы знаете, я сейчас выполняю сложную работу. И выхожу в выходные. Потому что если её не сделать быстро. Другой возможности не будет. Выходные мне никто не оплатит. Мой интерес — сделать её.
Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной. Если занять такую позицию.
Вот и скажите мне, чем мне договора помогут? Разве что у них нет законных оснований меня уволить. И все. Но цель которую я преследую, достигнута не будет. Я не боюсь потерять работу. Я боюсь её не закончить. Это важнее чем начать.
Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной. Если занять такую позицию.
Вот и скажите мне, чем мне договора помогут? Разве что у них нет законных оснований меня уволить. И все. Но цель которую я преследую, достигнута не будет. Я не боюсь потерять работу. Я боюсь её не закончить. Это важнее чем начать.
Так что договорами можно причинное место вытирать. Они ничего не стоят. Потому что вас, все равно обманут.
Так ведь и получается, что это ваш выбор — терпеть неудобства. Непонятно тогда к чему ваше недовольство
Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной
Так может она и не нужна бизнесу-то? В таком случае опять же непонятно, каким боком к этому всему относится договор и компания, если это по сути — ваша личная инициатива. Для сложных и интересных задач я лично использую pet-проекты, но тут уж каждый волен поступать как угодно
Так ведь и получается, что это ваш выбор — терпеть неудобства. Непонятно тогда к чему ваше недовольство
То что они потом этим пользуются у вас это возмущения не вызывает?
Они все понимают. Чего оно стоило. Можно хотя бы не хамить?
Так может она и не нужна бизнесу-то? В таком случае опять же непонятно, каким боком к этому всему относится договор и компания, если это по сути — ваша личная инициатива. Для сложных и интересных задач я лично использую pet-проекты, но тут уж каждый волен поступать как угодно
А это не моя задача, решать что нужно бизнесу. Меня интересует сама задача. Изначально же людям говоришь, чего и сколько надо. Потом, тобой начинают манипулировать, постепенно. Как минимум, это называется обман. Ну и как с договорами теперь?
То что они потом этим пользуются у вас это возмущения не вызывает?
Они все понимают. Чего оно стоило. Можно хотя бы не хамить?
Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть? У меня складывается ощущение, что вы слишком привязались к своему проекту и поэтому согласны на любые запросы начальства.
Изначально же людям говоришь, чего и сколько надо. Потом, тобой начинают манипулировать, постепенно. Как минимум, это называется обман. Ну и как с договорами теперь?
Зачем поддавались?
Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть?
Я уже отвечал. Меня интересует сложная задача.
У меня складывается ощущение, что вы слишком привязались к своему проекту и поэтому согласны на любые запросы начальства.
Это 4й сложный проект(мелочи считать не будем), который я выполняю. Начат он сравнительно недавно.
Зачем поддавались?
Где я обозначил что я поддался? Мне казалось, я явно указал, что изначально я говорил как есть. На что все дружно покивали. А потом за свое взялись. По-моему я написал, что имел место обман. Как вы это откомментируете я догадываюсь.
Вы знаете, работодатель может уволить любого. Если он того захочет. Это к слову о договорах. Как я уже утверждал, договоры не стоят ничего. Потому что их нарушают все стороны. Это практика.
Если у вас вся компания держится на «эх ребятушки, затянем пояса» и «ну что ты, ради проекта без выходных не поработаешь», то это проблема компании, нет?
Главное, чтобы это было взаимно.
Я за большее взаимодействие между работой и сотрудником. В моем случае это выражается в том, что я не против поработать в выходные иногда, а мои коллеги не возражают, если я пару недель или даже месяц поболею, работая из дома без больничного. В итоге все довольны, проект движется, денюжки заказчики платят.
А когда это коммерческих компаний обязали заниматься благотворительностью? Они же не ваши папа с мамой. У них есть задачи и они ищут людей, которые эти задачи решат, в обмен за вознаграждение. Вы им по какой-то причине не подходили. Через некоторое время стали подходить.
Ваша история звучит примерно так:
Зачем вообще кого-то ненавидеть? Или же они не просто отказывали на собеседовании, но еще и насмехались над вами?) Тогда да, есть причина.
Ваша история звучит примерно так:
Много лет назад я хотел устроиться дальнобойщиком на своей машине. У меня была легковушка, и меня нигде не принимали. Но через пару лет я наконец пересел за руль камаза и после этого меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним.
Зачем вообще кого-то ненавидеть? Или же они не просто отказывали на собеседовании, но еще и насмехались над вами?) Тогда да, есть причина.
А когда это коммерческих компаний обязали заниматься благотворительностью? Они же не ваши папа с мамой. У них есть задачи и они ищут людей, которые эти задачи решат, в обмен за вознаграждение. Вы им по какой-то причине не подходили. Через некоторое время стали подходить.
Никогда и что? Не мои папа с мамой и что? Вознаграждение? Вознаграждение дают за чрезмерное старание. Иначе это называется зарплата.
Много лет назад я хотел устроиться дальнобойщиком на своей машине. У меня была легковушка, и меня нигде не принимали. Но через пару лет я наконец пересел за руль камаза и после этого меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним.
Во-первых работа дальнобойщиком, не творческая деятельность. Во-вторых, вам не знакомо чувство когда вы тратили много сил, чтобы что-то поменять? Нет? Если делать все строго по упомянутому ранее договору, то ничего сделано не будет. Это еще называется Итальянская забастовка.
Зачем вообще кого-то ненавидеть? Или же они не просто отказывали на собеседовании, но еще и насмехались над вами?) Тогда да, есть причина.
Допустим насмехались, дальше что?
P.S. Вы просто бред несете. Сразу видно человека, который не умеет делать ничего сам, и даже не пытался. Вы случаем не владелец компании Х?
В чем циничность подхода «Нам нужен человек с навыками X,Y,Z». Если вы не ответили на вопросы на собеседовании, то вы тоже начинаете копанию ненавидеть? Особенно если вы через год-два подтянули эти пробелы и вам предлагают офер?
Как я уже где-то ниже утверждал, не важно сколько ты знаешь и сколько ты умеешь. Важно как быстро ты учишься. И в целом как голова работает.
Ну а HR это понять не способны.
Видимо объяснить это человеку — трудно. И суть цинизма вы не поняли.
Ну а HR это понять не способны.
Видимо объяснить это человеку — трудно. И суть цинизма вы не поняли.
Как я уже где-то ниже утверждал, не важно сколько ты знаешь и сколько ты умеешь. Важно как быстро ты учишься. И в целом как голова работает.
А если у компании нет времени ждать, пока вы всему научитесь? Можно выучить одно, другое, третье… Но если несовпадение идет сразу по куче пунктов, то давать месяцы на вход человека в коллектив многовато, не находите?
А у них никогда времени нет. Вы скорее всего с этим сталкивались.
Я неоднократно видел, когда HR ноют что не могут найти человека 2 года, когда за это время человека можно не плохо натаскать.
Вы все еще ждете ответа на ваш вопрос?
Я неоднократно видел, когда HR ноют что не могут найти человека 2 года, когда за это время человека можно не плохо натаскать.
Вы все еще ждете ответа на ваш вопрос?
Как вы предлагаете оценивать на собеседованиях, способен ли кандидат быстро обучаться и какое у него настроение будет завтра? Результат ведь нужен здесь и сейчас, по нему и оценивают. Я не hr если что (:
Как я Вас понимаю. Я 4 года назад менял работу будучи джуном+, пытался устроиться в одну серьезную (как мне тогда казалось) контору. Неплохо пройдя 2 собеса, попал на третий — к директору. На котором меня забрили с формулировкой: «Не считаем Вас перспективным, не видим в Вас желания развиваться».
После этого меня наняла другая компания, в которой за пару лет я докачался до тим лида, через еще пару лет попал под сокращение (проект закрылся). Когда я начал искать новую компанию, в числе прочих сходил на собесы в вышеобозначенную. Пообщался и с местным тим лидами, и с местным архитектором. И знаете что? Я не увидел в них ничего особенного. Технический уровень ребят был явно ниже моего, о процессах разработки представления не имеют, нам даже особо обсуждать было нечего.
Хотя быть может, здесь стоит говорить не о том, готова ли компания нанимать джунов, а о том, насколько руководители в состоянии оценить «перспективность» нового сотродника.
После этого меня наняла другая компания, в которой за пару лет я докачался до тим лида, через еще пару лет попал под сокращение (проект закрылся). Когда я начал искать новую компанию, в числе прочих сходил на собесы в вышеобозначенную. Пообщался и с местным тим лидами, и с местным архитектором. И знаете что? Я не увидел в них ничего особенного. Технический уровень ребят был явно ниже моего, о процессах разработки представления не имеют, нам даже особо обсуждать было нечего.
Хотя быть может, здесь стоит говорить не о том, готова ли компания нанимать джунов, а о том, насколько руководители в состоянии оценить «перспективность» нового сотродника.
Зачем ненавидеть-то? Пожалеть надо. Те, кто в вас поверил, выиграли, те, кто не поверил — проиграли.
С чисто капиталистической PoV* — точка зрения понятна и логична (простите за тавтологию) — всё на откуп прибыли, а далее по Даннингу.
Но вот с социальной действительно хочется "взять за грудки и потрясти". Никогда на самом деле не встречался с компаниями явно пропагандирующими идеалистические утопии вида: только сеньоры, только хардкор… Казалось бы — любая утопия априори нежизнеспособна, ан нет, оказывается — встречаются.
*Point of View
А можете меня, как не программиста просвятить, как отличить джуна/миддла/сеньора?
На примере python/c++?
И еще, как понять что ты джун/миддл/сеньор?
На примере python/c++?
И еще, как понять что ты джун/миддл/сеньор?
Легко, даем задачу, которую человек точно не решит. И смотрим на ход мысли. Далее даем подсказку для решения. Если подхватит, либо талант, либо опытный. Но для этого надо быть самому сеньором.
Скажу за крайние позиции, а мидл — что-то посередине:
Джун — в самый первый день работы во время знакомства с фичей предлагает переписать фичу… А лучше весь проект сразу… Под Ангулар… Ну или React… А сервер с легаси базой просто вырубить. Оценка задач у них хромает в принципе. Часто в коде отсутствуют казалось бы простейшие проверки, прозванные "защитой от дурака" — в ВУЗах главное сдать лабу/курсовик, а не освободить лишний раз память.
Сениор, при постановке задачи может уточнить — нужна скорость или качество? Не боится говнокода, но старается его не писать и честно предупреждает, что "вот тут могло бы бы и побыстрее работать, но сроки поджимали". Утечек памяти в его коде обычно не бывает. Обычно оценивает задачи более точно. Грамотно их разбивает. Легче входит продукт: зная общии принципы построяния коммерческого ПО и проработав в N компаниях — можно увидеть общие блоки, даже в ПО разных сфер и предназначений. Умеет ЧИТАТЬ код.
Понятное дело — список не полный.
Практически, я пришел к тому, что во-первых они не слушают. Если из-за этого увольнять всех подряд, один останешься. Надо дать человеку возможность облажаться. Ну и самому быть на высоте. Т.к. идут за личностью. Личным примером показывать. А не вынуждать. Это трудно. И затратно. Но, иначе мы в них породим только отторжение. Так мы ничего не добьемся.
«Облажаться» слишком дорого, чтобы позволять это сознательно. Когда случайно друпнул базу в гитлабе — да, бывает, это ценный опыт. Но специально дать человеку дропнуть её, зная, к чему это приведет, слишком дорогостоящее обучение.
На мой взгляд вы утверждаете даже не крайности.
У джуна есть лид, и именно лид отвечает за действия джуна. Не надо давать джуну красную кнопку. Пусть начинает с простого. У них на простых задачах то проблемы.
А на практике я много раз видел, когда лид говорил что это джун напартачил. Вместо того, чтобы разгребать. А ведь именно ты его взял. Зачем ты на него стрелы переводишь? Именно ты отвечаешь за его действия, и последствия.
У джуна есть лид, и именно лид отвечает за действия джуна. Не надо давать джуну красную кнопку. Пусть начинает с простого. У них на простых задачах то проблемы.
А на практике я много раз видел, когда лид говорил что это джун напартачил. Вместо того, чтобы разгребать. А ведь именно ты его взял. Зачем ты на него стрелы переводишь? Именно ты отвечаешь за его действия, и последствия.
Отвечает конечно лид, но зачастую случается, что платит на самом деле — именно джун.
«как понять что ты джун/миддл/сеньор?» — да просто проверяйте по списку навыков, требуемых для конкретной вакансии. Можете по итогам походить на собеседования. Если проходите на сеньорскую позицию, значит, вы — он самый и есть. «Практика — критерий истины».
Сеньор один может написать практически весь код проекта без особых трудностей (или, по крайней мере, ту часть, что в зоне его квалификации, если проект очень большой). Мидл требует консультаций, т.к. периодически испытывает трудности, но многие задачи решает сам, говнокод пишет от случая к случаю. Джун имеет очень узкие рамки для творчества, самостоятельно может решать только простые задачи, требует постоянный контроль за своим кодом.
На правах шутки:
Мид — тот, кто может сделать проект в одиночку. Джун — не может, сеньор — не хочет.
Мид — тот, кто может сделать проект в одиночку. Джун — не может, сеньор — не хочет.
Ко всему выше сказанному, добавлю:
1) Общепринятой метрики в индустрии нет, каждый трактует так, как хочет.
Что собственно видно из комментариев выше)
2) Градация по факту шире: интерн/джун/миддл/сеньор/тимлид/«гуру»
Применительно к python: интерн напишет «привет мир», гуру напишет питон.
3) Работа программиста декомпозируется на разные навыки и знания, в соответствии с обязанностями по роли специалиста.
Например,
«Простой» программист имеет такие знания и навыки:
Архитектор, в дополнение к основному стеку программистских обязанностей, должен уметь проектировать:
Тимлид, же в дополнение к основному стеку программистских обязанностей и стеку архитектора, еще и с людьми работает, тут еще одна ветка «талантов».
4) Каждый навык оценивается отдельно по шкале от интерна до гуру.
5) Конечная оценка программиста — средняя оценка по его знаниям и навыкам.
6) В реальной жизни роль Архитектора редко выделяют, и включают в градацию сеньора.
То есть реальная разница между джуном/мидлом и сеньором — это умение проектировать код.
Поэтому,
Пысы все вышесказанное IMHO.
1) Общепринятой метрики в индустрии нет, каждый трактует так, как хочет.
Что собственно видно из комментариев выше)
2) Градация по факту шире: интерн/джун/миддл/сеньор/тимлид/«гуру»
Применительно к python: интерн напишет «привет мир», гуру напишет питон.
3) Работа программиста декомпозируется на разные навыки и знания, в соответствии с обязанностями по роли специалиста.
Например,
«Простой» программист имеет такие знания и навыки:
- Знания из Computer Science/Информатики (которая зачастую сводится к алгоритмам, ну и немного математики)
- Планирование своего времени применительно к решению задач
- Навык написания кода на языке X
- Использование тулсета (IDE, консоль)
- Использование VCS(git, TFS, mercurrial)
Архитектор, в дополнение к основному стеку программистских обязанностей, должен уметь проектировать:
- Знать и уметь в шаблоны(применительно к ООП)
- Выбирать стек под проект(на уровне фреймворков и библиотек)
- Читать и писать UML (опционально ли?)
Тимлид, же в дополнение к основному стеку программистских обязанностей и стеку архитектора, еще и с людьми работает, тут еще одна ветка «талантов».
4) Каждый навык оценивается отдельно по шкале от интерна до гуру.
5) Конечная оценка программиста — средняя оценка по его знаниям и навыкам.
6) В реальной жизни роль Архитектора редко выделяют, и включают в градацию сеньора.
То есть реальная разница между джуном/мидлом и сеньором — это умение проектировать код.
Поэтому,
- Интерн — кто еще ничего не может.
- Джун — кто может, что-то реализовать хорошо под руководством тимлида. Потому что в проектирование еще не умеет.
- Мидл — кто может, что-то реализовать хорошо под присмотром тимлида. Потому что в проектирование только учиться.
- Сеньор — кто может и спроектировать и реализовать хорошо без внешней помощи, но либо не хочет, либо не может руководить младшими.
- Тимлид — кто может и спроектировать и реализовать хорошо без внешней помощи, и при этом присмотреть за младшими, чтобы они тоже сделали хорошо.
- Гуру — Гвидо Ван Россум, Андерс Хейлсберг и т.д.
Пысы все вышесказанное IMHO.
Проблема чрезмерной квалификации сеньоров также имеет место быть. Дело в том, что множество навыков соискателя и множество навыков, нужных работодателю, никогда не совпадают полностью. И чем выше позиция, тем больше список требуемых навыков, и тем сложнее найти кандидата на позицию. Приходится либо учить джуна, либо смириться с завышенными зарплатными ожиданиями сеньора (платить за невостребованные навыки).
Это всё конечно красиво, человеколюбиво, авангардно и либерально. И неверно для очень большого ряда случаев. Я перестал нанимать джунов и всем советую. Потому что
1) они входят в курс дел и в процесс разработки очень долго, в разы больше миддлов и тем более синьоров
2) очень быстро уходят из компании в поисках лучшей доли, и часто даже не из-за зарплаты или невозможности повышения (тут как раз все ок), а потому что хотят поиграться с другими технологиями
3) большинство джунов — молодые и у них ветер в голове и низкий уровень ответственности
Я высказываю непопулярную точку зрения, потому что она частная и потому что здесь просто больше разрабов чем собственников бизнеса или ИТ директоров. Но поверьте, вся эта розовая теория про милых джунов рассыпается о реальность, когда Джун, которого вы растили полгода и потратили на него кучу ресурсов других опытных разрабов, вдруг решает, что Го прикольнее чем Питон и надо переходить на работу в контору где юзают
Если твой джун решил что надо переходить из твоей конторы, значит ты не смог его удержать, и это твоя вина. И неважно почему он так решил, ты не барин чтобы Юрьев день вводить.
Если у тебя текучка такая, что работу работать невозможно, то у тебя явно что-то не так с конторой. А если ты жалуешься на обычную текучку, то ты неправильно воспринимаешь реальность.
Если у тебя текучка такая, что работу работать невозможно, то у тебя явно что-то не так с конторой. А если ты жалуешься на обычную текучку, то ты неправильно воспринимаешь реальность.
Он-то не барин. Но он как бы отвечает автору статьи, который вещает нам за низкий уровень социальной ответственности.
Сотрудник может уйти по миллиону причин — это его право.
Но точно также право другой стороны сказать — а нафига мне эти заботы? Зачем вкладываться несколько месяцев в людей, которые могут свинитить (и скорее всего свинтят) в любой момент? Первое время польза от джуна околонулевая, а то и даже отрицательная.
Сотрудник может уйти по миллиону причин — это его право.
Но точно также право другой стороны сказать — а нафига мне эти заботы? Зачем вкладываться несколько месяцев в людей, которые могут свинитить (и скорее всего свинтят) в любой момент? Первое время польза от джуна околонулевая, а то и даже отрицательная.
Ну я о том и говорю, что если в твоей конторе нормальная ситуация, когда ты берешь джуна, он вырастает и сваливает, значит для разрабов у тебя в конторе условия говно, иначе они хотели бы остаться именно у тебя. А если у тебя условия говно, то это только твоя вина.
А насчет социальной ответственности, даже если не обращать на нее внимание (что само по себе плохо), то в любом случае джун выращенный у тебя, на твоих практиках и продуктах, принесет тебе больше пользы чем джун выращенный кем-то другим, а стоить будет, статистически, меньше.
А насчет социальной ответственности, даже если не обращать на нее внимание (что само по себе плохо), то в любом случае джун выращенный у тебя, на твоих практиках и продуктах, принесет тебе больше пользы чем джун выращенный кем-то другим, а стоить будет, статистически, меньше.
Человек 20-и с небольшим лет свалит независимо от условий, просто потому что он ищет себя. Он хочет новых мест, задач, языков, знакомств, городов, стран и тд и тп.
Даже при з/п выше средней по городу, бесплатных печеньках и ежедневном поцелуе в попу всегда найдется условный заокеанский гугл, который поманит яркими огнями и ничего с этим не поделать. Сейчас популярны даже поверья типа «засиделся на одном месте 3 года = прекратил развитие и оброс мхом».
Хорошие условия лишь немного оттянут момент расставания.
Даже при з/п выше средней по городу, бесплатных печеньках и ежедневном поцелуе в попу всегда найдется условный заокеанский гугл, который поманит яркими огнями и ничего с этим не поделать. Сейчас популярны даже поверья типа «засиделся на одном месте 3 года = прекратил развитие и оброс мхом».
Хорошие условия лишь немного оттянут момент расставания.
А может и не свалит, если у вас реально хорошо. Вы всех мажете одной кистью, а люди-то разные, и если у вас единственная причина ухода джунов это заокеанский гугл, то у вас, в общем-то все хорошо, и потерю одного джуна из десяти вполне можно пережить. Или если у вас уходит половина, в общем-то, ничего страшного, не так уж и много вы на этом потеряли, а получили гораздо больше. А вот если у вас уходят все джуны, то это говорит только об одном — ваша контора говно, и работать у вас плохо.
Вы очень упорно давите на вами придуманный тезис, что "контора — говно". Поверьте, из говноконтор уходят не только джуны. Контора вполне хорошая. Но слишком многие джуны уходят действительно просто потому что им интересно поиграться в другие технологии. И здесь ничего невозможно сделать. Найдите мне способ понять, останется ли конкретный джун в компании в следующие три года, и я первый побегу их нанимать. А пока что — простите, нет.
Вообще вся эта история попахивает позитивной дискриминацией, когда под видом борьбы за права меньшинств, этих самых меньшинств пропихивают куда ни попадя, даже если они там неэффективны.
По моему вы из позитивной дискриминации — прыгаете в негативную.
Джуны неэффективны — это факт. Но это не причина, чтобы их не нанимать. Это досадный недостаток, который проходит с опытом и только от вас зависит — как быстро этот опыт прийдёт.
Но слишком многие джуны уходят действительно просто потому что им интересно поиграться в другие технологии.
Значит, им недоплачивают. Если в конторе используется более-менее востребованный на рынке стек — джуны не станут уходить чтобы поиграться с новыми технологиями, им эти технологии нафиг не нужны, они не хотят их изучать, им нужна зарплата и перспективы ее роста. Джун уйдет поиграться в новые технологии только если его позовут поиграться в новые технологии за не меньшие деньги. Но если джуну за малознакомые ему технологии предлагают не меньше, чем в текущей конторе за знакомые — то текущая контора говно и не доплачивает.
Но слишком многие джуны уходят действительно просто потому что им интересно поиграться в другие технологии. И здесь ничего невозможно сделать. Найдите мне способ понять, останется ли конкретный джун в компании в следующие три года, и я первый побегу их нанимать.
Видел в двух разных компаниях два интересных варианта: в одной «пряник», в другой «кнут».
1) Джунов в первый год четырежды переводят между разными проектами с разными используемыми технологиями, по три месяца на проект. Через год новый сотрудник совместно с четырьмя начальниками решают, в котором из этих проектов он останется.
2) Контракт с джунами предусматривает денежный штраф за уход в первые год-два.
денежный штраф за уходА это законно? Мне кажется, в России трудовой инспектор будет очень рад срубить палку на таком деле (про другие страны молчу, потому что вообще представления не имею).
С одной стороны, в России незаконно. (В других странах — по-разному.)
С другой стороны, есть обходные пути, как сделать это без формальных нарушений ТК, в том числе вышеупомянутая «компенсация стоимости обучения».
С третьей — много ли российских контор работает полностью по-белому и без нарушений ТК? Инспектора, казалось бы, могут рубить палки направо и налево, но в действительности этого не происходит.
С другой стороны, есть обходные пути, как сделать это без формальных нарушений ТК, в том числе вышеупомянутая «компенсация стоимости обучения».
С третьей — много ли российских контор работает полностью по-белому и без нарушений ТК? Инспектора, казалось бы, могут рубить палки направо и налево, но в действительности этого не происходит.
Но точно также право другой стороны сказать — а нафига мне эти заботы? Зачем вкладываться несколько месяцев в людей, которые могут свинитить (и скорее всего свинтят) в любой момент?
А не-джуны разве не могут свинтить в любой момент, как только работа им наскучит?
Принимать на работу только женатых с детьми и ипотекой, чтоб сидели и не рыпались?
Всё зависит от конкретного человека. Кому-то интересно пробовать новые технологии, кому-то интереснее развиваться в одной.
1 Да, но за пару лет талантливый Джун станет миддлом и будет так же быстро вникать в курс дел.
2 Зависит от человека. Я на первой своей работе работал 5 лет. И уйти пришлось из-за слабого роста зарплаты. Я был бы рад там работать и дальше, если бы там было нормальное повышение зарплаты.
3 опять же сильно зависит от человека. У кого-то всё серьёзно в 25 лет, а у кого-то пустая голова в 40
- Возможно, это дела так обстоят и процесс такой. Сеньоры просто имеют навык разбираться даже в лютом говнокоде и нелогичном процессе. Но виноваты джуны, да, что в реальности всё оказалось не так хорошо и понятно, как в книжках.
- Обычно никто даже не интересуется, чем человек хотел бы заниматься. Но тут проблема глубже, конечно. В вашем офисе могут сидеть люди, которые готовы не спать ночами, чтобы сделать крутой интерфейс на современном фрэймворке, что вывело бы проект на новый уровень, но у компании в приоритете интеграция с десятым по счёту API.
- А ещё энергия, жажда знаний, бескомпромиссность к плохим решениям и пока ещё не прагматичный подход к отношениям с работодателем.
Если вы не нанимаете джунов, то не заслуживаете сеньоров
А можно я без дебильных подсказок сам решу, заслуживаю я сеньоров или нет?
Иногда, когда компании говорят, что не нанимают младших программистов, мне хочется схватить их за грудки и закричать: а откуда, по-вашему, берутся старшие программисты?!Непонятно, почему это должно быть моей проблемой?
Откуда они берутся? Хм, «Ржевский, молчать!»
Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы.
Ниже текучка? То есть джуны долго никуда не уходят??
Выше разнообразие специалистов? А если мне не нужно такое разнообразие?
Меньше оверхеда? То есть обучение джуна снижает оверхерд? В каком месте?
Непонятно, почему это должно быть моей проблемой?
Это станет вашей проблемой тогда, когда вам внезапно надо закрыть важное направление, а необходимого сениора — под рукой не окажется. И я сейчас не про идиотизмы вроде "и что вы предлагаете закрывать дыру джуном?" — ни в коем случае… Просто подумай вы в какой-то момент сильно заранее иначе, чем думаете сейчас — у вас были бы собственные подготовленные мидлы, для одного из которых затыкание вашей критической дыры позволило бы вырасти над собой, а вам — не метаться судорожно по рынку труда пытаясь найти того, кто впряжётся за уже ваши проблемы, негодуя, что "сениоры зажрались".
Жаль, что такое осмысление сценариев обычно приходит постфактум.
А можно я без дебильных подсказок сам решу, заслуживаю я сеньоров или нет?
Никто читать не заставлял.
А то как вы считаете, кого вы заслуживаете, практически может отличатся. Решать будет практика. А не вы.
Очень похоже, что автор статьи из тех, у кого diversity головного мозга, пока ещё в начальной стадии.
Работодатель сам вправе решать, кого и какой квалификации ему нанимать. Все остальные доводы — это разговоры в пользу бедных, ненужное нытье и всякие левые домыслы.
Работодатель сам вправе решать, кого и какой квалификации ему нанимать. Все остальные доводы — это разговоры в пользу бедных, ненужное нытье и всякие левые домыслы.
Конечно вправе, а остальные вправе ему показывать, когда его практики наёма полное говно.
Вот такие практики, например, говно, неважно насколько ты считаешь себя холодным капиталистом нанимающим лучших из лучших, не оглядываясь на собственный bias
Вот такие практики, например, говно, неважно насколько ты считаешь себя холодным капиталистом нанимающим лучших из лучших, не оглядываясь на собственный bias
Может расскажите нам о своей личной практике найма в одной из ИТ-шных организаций, которая принадлежит вам? Ааа… вы еще не владелец и сами работаете на дядю? А знаете почему? Потому что как бизнесмен вы что? Правильно… :)
Обязательно есть фекалии чтобы понять что они невкусные? А чтобы человеку поедающему фекалии сказать что он делает что-то неправильное сколько фекалий самому обязательно съесть?
И не надо нам тут вот этой вот уже-даже-не-очень-пассивной агрессии, вы вот как собеседник сами знаете что, я же вам на это не указываю.
И не надо нам тут вот этой вот уже-даже-не-очень-пассивной агрессии, вы вот как собеседник сами знаете что, я же вам на это не указываю.
КАждый человек вправе решать, что ему делать, но судя по всему 80% россиян после сложных раздумий решили жить бедно. Автор просто сообщает работодателям, что часть решений неправильны и ведут не к тому результату, который они ожидают.
А меня вот удивляют эти лычки, все с ними вдруг забегали в последние года два-три.
Как вы их отличаете? Например, в команде два человека: у одного два года на С++, у другого — 10, кто из них «сеньор»? Или команда из «сеньоров», которые 10 лет пишут интерфейсы в каком-нибудь embedded платформе, используя jquery и php 5, к ним приходит человек с 2 годами в современном фронтенде — он кто?
Как вы их отличаете? Например, в команде два человека: у одного два года на С++, у другого — 10, кто из них «сеньор»? Или команда из «сеньоров», которые 10 лет пишут интерфейсы в каком-нибудь embedded платформе, используя jquery и php 5, к ним приходит человек с 2 годами в современном фронтенде — он кто?
У нас в компании нет джунов, да и миддлов не особо, в основном синиоры. И это лучшее место из всех, где я работал. Всегда есть с кем что обсудить. Сениор не значит, что он всё знает, я очень часто коллегам рассказываю какие-нибудь байки про особенности выравнивания памяти и последствия для производительности (для фронтов это очень неожиданная информация). В ответ я получаю интересные рассказы про докер, настройку CI, всякие фреймворки и т.п. То есть я и обучаю, и обучаюсь, хотя мы с людьми примерно на одном уровне, просто потому, что у нас разный уровень компетентности в разных сферах.
А теперь по пунктам:
А какие могут быть причины нанимать низкоквалифицированных сотрудников? В отличие от «Работы руками», где человек гайку может тесать без высшего образования, весь код взаимодействует друг с другом, равно как и закон брукса никто не отменял.
То есть то, как вы обращаетесь с мидлами и синиорами совсем не является показателем, верно?
Нет, это значит, что мы хотим сделать упор на качество. Массовые расстрелы автор выдумал на ровном месте. Прием «Strawman».
Мир это война, свобода это рабство, ошибки это возможности. Нет, ошибки это ошибки. Напоминает старую цитату Programming Defeatism: No technique will remove all bugs, so let's go with what worked in the 70s.
А что ж не сравнить джуна, который 5 лет на проекте работал, с только что пришедшим миддлом? Или наоборот, сениора который на проекте полгода отработал и только что пришедшего джуна?
Выше уже сказали, очередные цифры с потолка.
Мы про сениоров говорим или про чуваков с излишним самомнением? Позиция «джуны боятся даже своей тени, чтобы не вылететь из компании, поэтому согласны на все, давайте это используем». Ну, такое себе. У нас на проектах всегда разумное общение по любым вопросам, потому что есть желание сделать проект, а не продавить табы или пробелы. Что тут сказать, на любом проекте проводится один раз жаркий спор, настраивается gitattributes/editorconfig, куда заносятся автоматические правила форматирования, и больше проблем с этим не возникает. Споров другого характера на практике я не припомню.
Года 4 назад был на корпоративе Ланита, где люди получали медали за выслугу — 20, 25 лет… И тоже начинали интернами… У меня от этого скорее страх был, нежели трепет. Люди просто были полностью оторваны от того, как делаются процессы в других компаниях. Выдавать это за плюс по меньшей мере странно.
Оптимизм — это когда «Давайте все нафиг перепишем… Да не боись, не взорвется!»? В команде не оптимизм должен быть, а реализм. Не надо путать со здоровым духом и хорошим настроением в компании, это ортогональные вещи. Команда веселых реалистов максимально продуктивна, и не косячит в сроках оценки фич.
Тут возникает логичный вопрос «откуда эти сениоры возникнут?». К сожалению, у меня нет ответа на этот вопрос. Я в своё время устроился будучи студентом, когда я пообещал, что я в течение ближайших лет никуда не уйду. Своё обещание я сдержал, и получился достаточно выгодный обмен, меня по цене сотрудника Макдональдса, а мне за это опыт. Лично я не вижу ничего плохого в том, чтобы начинать с самого низа. Учитывая, сколько сейчас крутых открытых проектов на гитхабе можно вкатиться сразу мидлом в разработку, и избежать упомянутых проблем.
А теперь по пунктам:
Посыл состоит в том, что младшие программисты представляют собой риск, некий шаг, на который компания идёт либо из чувства общественного долга, либо из-за нехватки бюджета. Получается, что другие компании, должно быть, могут позволить себе корпоративную благотворительность и второсортные результаты, но уж точно не мы.
А какие могут быть причины нанимать низкоквалифицированных сотрудников? В отличие от «Работы руками», где человек гайку может тесать без высшего образования, весь код взаимодействует друг с другом, равно как и закон брукса никто не отменял.
То, как вы нанимаете и обращаетесь с младшими программистами — важный косвенный показатель здоровья вашей организации, вашей линейки продуктов и вашей внутренней культуры. Сеньоры обращают на это внимание. И если одно это не звучит достаточно убедительно, то найм взвешенного количества младших программистов также даёт финансовые преимущества.
То есть то, как вы обращаетесь с мидлами и синиорами совсем не является показателем, верно?
Если вы отказываете младшим программистам потому, что они «создают проблемы», то вы также машинально посылаете сотрудникам важное сообщение насчёт корпоративной культуры: ошибки недопустимы. Вы создаёте образ компании, которая увольняет кого-нибудь всякий раз, когда ложится сервер.
Нет, это значит, что мы хотим сделать упор на качество. Массовые расстрелы автор выдумал на ровном месте. Прием «Strawman».
А что насчёт ошибок, которые пробивают все установленные подстраховки? Думайте о них как о ценных возможностях укрепить вашу защиту.
Мир это война, свобода это рабство, ошибки это возможности. Нет, ошибки это ошибки. Напоминает старую цитату Programming Defeatism: No technique will remove all bugs, so let's go with what worked in the 70s.
Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $28 в час за написание этого кода — или вы можете заплатить $59 в час написание того же кода. Так или иначе, результат будет мало отличаться. Если вы нанимаете только сеньоров, то вы платите втридорога за существенный объём простой работы.
- Во-первых это не будет тот же код (скорее всего). А с этим кодом будут взаимодействовать куча других частей программы
- Во-вторых сколько времени уйдет на написание этого кода? Как не раз было сказано в блоге PVS studio, в коде часто не видно, сколько на самом времени потрачено было времени, чтобы написать этот кусок кода. И час работы сениора всё еще дешевле трех часов работы джуна, которые еще переписывать придется
Кроме того, кодовая база значительно разнится между приложениями, и знакомство с ней — ключевой фактор в продуктивности. В большинсте случаев младший программист, проработавший в команде полгода, будет эффективней справляться с задачами, чем только что нанятый старший программист — просто из-за степени знакомства с логикой проекта.
А что ж не сравнить джуна, который 5 лет на проекте работал, с только что пришедшим миддлом? Или наоборот, сениора который на проекте полгода отработал и только что пришедшего джуна?
Ввиду этого пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости. Если ваша цель — максимальная продуктивность с минимальными затратами, то такая пара джун+сеньор должна стать фундаментальной молекулой вашей организации.
Выше уже сказали, очередные цифры с потолка.
Стоит отметить ещё один, неизмеримый фактор: тенденцию старших программистов к постоянным спорам на темы, которые в конечном итоге ничтожны — про алгоритмы, микрооптимизации и стиль кода. Если компания нанимает только сеньоров и не имеет при этом жёсткого процесса принятия решений, то сотни рабочих часов могут уйти на подобные споры. Младшие разработчики обычно лишены такой проблемы.
Мы про сениоров говорим или про чуваков с излишним самомнением? Позиция «джуны боятся даже своей тени, чтобы не вылететь из компании, поэтому согласны на все, давайте это используем». Ну, такое себе. У нас на проектах всегда разумное общение по любым вопросам, потому что есть желание сделать проект, а не продавить табы или пробелы. Что тут сказать, на любом проекте проводится один раз жаркий спор, настраивается gitattributes/editorconfig, куда заносятся автоматические правила форматирования, и больше проблем с этим не возникает. Споров другого характера на практике я не припомню.
Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна».
Года 4 назад был на корпоративе Ланита, где люди получали медали за выслугу — 20, 25 лет… И тоже начинали интернами… У меня от этого скорее страх был, нежели трепет. Люди просто были полностью оторваны от того, как делаются процессы в других компаниях. Выдавать это за плюс по меньшей мере странно.
У младших программистов есть ряд уникальных черт, которые их более опытные коллеги обычно утратили. Одна из них — незамутнённый оптимизм. Другая — готовность идти за лидером.
Оптимизм — это когда «Давайте все нафиг перепишем… Да не боись, не взорвется!»? В команде не оптимизм должен быть, а реализм. Не надо путать со здоровым духом и хорошим настроением в компании, это ортогональные вещи. Команда веселых реалистов максимально продуктивна, и не косячит в сроках оценки фич.
Тут возникает логичный вопрос «откуда эти сениоры возникнут?». К сожалению, у меня нет ответа на этот вопрос. Я в своё время устроился будучи студентом, когда я пообещал, что я в течение ближайших лет никуда не уйду. Своё обещание я сдержал, и получился достаточно выгодный обмен, меня по цене сотрудника Макдональдса, а мне за это опыт. Лично я не вижу ничего плохого в том, чтобы начинать с самого низа. Учитывая, сколько сейчас крутых открытых проектов на гитхабе можно вкатиться сразу мидлом в разработку, и избежать упомянутых проблем.
Да спорная на самом деле статья. Все сильно зависит от того как построен бизнес, что за софт пишется, какова цена ошибки и вообще много всего. Например если вы не можете позволить себе CI (окружение изолированно) или у вас высокие требования по перфомансу — то джуны это только поддержка и багфикс. А если на фронте верстку крутить то там можно и джунами обойтись.
Опять таки бывают всякие галеры. где лучше взять самоуверенных джунов и «прокачивать их» и нескольких сеньеров.
Хотя конечно лучше вырастить сеньера из джуна. но это на самом деле признак очень хорошей компании когда. и стек технологий очень серьезный и обучение построенно хорошо и процесс ревью и тестирования (джуну не получится сильно накосячить)
Опять таки бывают всякие галеры. где лучше взять самоуверенных джунов и «прокачивать их» и нескольких сеньеров.
Хотя конечно лучше вырастить сеньера из джуна. но это на самом деле признак очень хорошей компании когда. и стек технологий очень серьезный и обучение построенно хорошо и процесс ревью и тестирования (джуну не получится сильно накосячить)
Я не верю, что в одной компании (даже самой крутой) можно вырасти до джуна. Просто потому, что больше 3 лет на одном месте проработать тяжело. Я больше верю в джун->год-другой работы->недовольство текущими задачами/уровнем зп->офер на мидла->смешной контрофер->трудоустройство миддлом->год-другой работы->недовольство текущими задачами/уровнем зп->офер на синиора->смешной контрофер->трудоустройство синиором.
вы сейчас говорите про так себе джуна в компании с одним однотипным продуктом и использующей типовой стек.
Достаточно крупная компания с несколькими сотнями разработчиков, ссобственным продуктом полного цикла. и типовая карьера: команда састейн, поддержка старой версии на проде, прокачка скилов до толкового джуна, замечают в отделе постарше внутренний перевод на уровень недомидла. там жесткий энтерпрайз и куча задач которые сеньерам не интересны но отличают настоящий продукт: разные хвосты к мониторингу, ci. Всякие написать unit файл сервиса, обвернуть утилиты тестирования в rpm пакеты. вообщем те задачи когда знаю что писать и учусь как писать. ну и плюс рост компании и рост отделов. да при этом стек хоть и широк, но в одной сфере и специфичен.
Хотя да определенные личные характеристики тоже важны.
Собственно я в текушей компании 11 лет и как раз прошел путь от джуна до руководителя группы и системного архитектора. есть еще человек 40 таких дедушек. Конечно все на позициях сеньеров, лидов и архитекторов давно.
Достаточно крупная компания с несколькими сотнями разработчиков, ссобственным продуктом полного цикла. и типовая карьера: команда састейн, поддержка старой версии на проде, прокачка скилов до толкового джуна, замечают в отделе постарше внутренний перевод на уровень недомидла. там жесткий энтерпрайз и куча задач которые сеньерам не интересны но отличают настоящий продукт: разные хвосты к мониторингу, ci. Всякие написать unit файл сервиса, обвернуть утилиты тестирования в rpm пакеты. вообщем те задачи когда знаю что писать и учусь как писать. ну и плюс рост компании и рост отделов. да при этом стек хоть и широк, но в одной сфере и специфичен.
Хотя да определенные личные характеристики тоже важны.
Собственно я в текушей компании 11 лет и как раз прошел путь от джуна до руководителя группы и системного архитектора. есть еще человек 40 таких дедушек. Конечно все на позициях сеньеров, лидов и архитекторов давно.
Я работал в компаниях до 7к человек, и везде наблюдал одну и ту же картину. Может я не там был, не спорю, но у меня сложилось такое мнение.
Например, на моей первой работе я работал джуном на полставки за 30 тысяч, совмещая с учебой, а вышел на полную ставку… 40 тысяч… После моего вопроса «Разве 30*2 это 40?» мне было сказано, что таковы у них вилки для джунов, а на мидла я не тяну.
Через неделю я принес офер сильно выше, чем «30*2», и тогда уже пошел разговор про нормальную ЗП, но я все же предпочел сменить рабочее место.
Например, на моей первой работе я работал джуном на полставки за 30 тысяч, совмещая с учебой, а вышел на полную ставку… 40 тысяч… После моего вопроса «Разве 30*2 это 40?» мне было сказано, что таковы у них вилки для джунов, а на мидла я не тяну.
Через неделю я принес офер сильно выше, чем «30*2», и тогда уже пошел разговор про нормальную ЗП, но я все же предпочел сменить рабочее место.
Э… Я своими глазами видел джунов, выраставших до синьора. Не в каких-то там супер-крутых компаниях. Когда нанятый студент со временем вырастал до главы отдела.
del
del
Ну в целом подход netflix понятен. Они считают, что их бренд достаточно привлекателен для того чтобы собирать сливки. Но сливки имеют тенденцию заканчиваться, а кроме того отсутствие градации скиллов — отсутствие возможности карьерно расти тем же самым сливкам. А значит те, кого привлекут в качестве сеньоров не будут оставаться в компании больше чем несколько лет и за повышением пойдут в другую компанию.
Это ни плохо и ни хорошо — это просто такая стратегия найма. Со своими плюсами и минусами.
Это ни плохо и ни хорошо — это просто такая стратегия найма. Со своими плюсами и минусами.
Почему-то никто не сказал, что есть «опыт работы вообще», а есть «опыт работы над данным проектом данной компании». И пока человек остаётся на одном проекте внутри одной компании — эти вещи взаимозаменяемы; но при смене работы — второй опыт обесценивается, и за него на новом месте платить не будут.
Так вот, набрав джуниоров — можно надеяться, что сложится команда людей, которые имеют опыт второго типа. Платить им можно по уровню опыта первого типа, ну или чуть больше; зато качество работы будет выше, чем у нанятых со стороны программистов на ту же зарплату.
(Надеюсь — я внятно выразился.)
Так вот, набрав джуниоров — можно надеяться, что сложится команда людей, которые имеют опыт второго типа. Платить им можно по уровню опыта первого типа, ну или чуть больше; зато качество работы будет выше, чем у нанятых со стороны программистов на ту же зарплату.
(Надеюсь — я внятно выразился.)
Оставив в стороне посыл статьи, хочется отметить прекрасный перевод. Особенно порадовало про щенков в начале.
На моем опыте джуны в команде бывают просто необходимы. Бывало много задач, которые для опытных программистов были неинтересными и рутинными. Для джуновже это был отличный опыт, и они с удовольствиям брались за работу. В общем всегда приятно иметь человека, на которого можно спихнуть левую задачу)
Предлагаю развить тему вглубь, выпустив цикл статей «Растим сеньора из ничего» на темы от «Откуда берутся джуны» до «Откуда берутся дети», дорожка от этой статьи вполне непрерывная видится.
Один из недооценённых навыков программиста — способность писать код, который средний или посредственный программист сможет легко прочесть, изменить и расширить.
И такой код как раз таки пишу сеньёры. А вот джуны как раз умеют написать так, что без поллитры не разберёшься. Я имею ввиду не заумный код, заумный код обычно пишут мидлы, а код, логика которого живёт только в голове автора. Умение писать просто и понятно — тот ещё сеньёрский навык.
Ох уж эти лозунги… Не во всех конторах 100500 программистов и не везде есть возможность безболезненно нанять десяток-дуругой джунов для тестов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если вы не нанимаете джунов, то не заслуживаете сеньоров