LINUX.ORG.RU
ФорумTalks

Про карьерный рост JS-фронта (и похожего) погромиста

 , , , ,


0

4

По мотивам поста, как subwoofer решил из джава-сеньёров стать начинающим помощником JS-джуна

Когда ты юзаешь джаву или кресты, у тебя всегда есть куда расти. Ты можешь попробовать написать более эффективный алгоритм, и на это скорей всего выделят ресурсов. Можно кусок джавы переписать на С++, а кусок C++ - на ассемблере. Или наоборот джаву переписать в скалу в функциональном виде. Можно переосмыслить работу стандартных коллекций и выжать еще 5% производительности из ArrayList. Можно попробовать распараллелить последовательное, векторизовать невекторизованное, переложить что-то на GPU, итп. В конце концов, если очень ленивый, можно экспертно выучить какой-нибудль фреймворк типа Hibernate, чтобы мочь решить сложные моменты когда он тормозит.

Last but not least - с каждым дополнительным скиллом растёт твоя зарплата (если ты вовремя меняешь место работы на такое, где твои тайные знания могут потушить пожар или починить эпический факап).

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

Что касается серверной стороны, то почти никакой пограмист например на Ruby понятия не имеет как устроены внутри стандартные коллекции, а чтобы полезть внутрь и что-то затюнить и починить - погуглил сейчас в гугле, вакансий не ищется. Многопоточности нигде нету - в JS по дизайну языка, Руби и Пайтон это либо GIL, либо убогий однопоточный шедулинг. С сетью на нижнем уровне не поработаешь - как правило ты гвоздями прибит к уже оформленному хттп риквесту. Вообще ни с каким железом не поработаешь..

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

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

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 2)

Ответ на: комментарий от shahid
>> Жаль мне заказчика и будущий саппорт этого кода.

> Взгляд раба, беспокоящегося за своего хозяина.

Вот за такое надо из профессии выгонять.

alpha ★★★★★
()
Ответ на: комментарий от RazrFalcon

А потом у меня сайты тормозят...

Из-за чего на деле сайты тормозят — можно через Page speed посмотреть. Традиционно это всякие document.getElementsByClassName(), кучи tcp запросов из require/amd с десятками мелких js'ников без http/2, неудачное овладевание селекторами богомерзкой jquery умственно отсталыми web-обезьянами, анимированные прозрачности и блюры. Связь между размером js-файла и тормозами начинается только на *реально больших* объемах js-кода.

shahid ★★★★★
()
Ответ на: комментарий от alpha

карьера у разработчика означает переход а менеджеры. Должны быть другие пути.

какие? когда количественное знание переходит в качественное.

Rastafarra ★★★★
()
Ответ на: комментарий от shahid

Взгляд раба, беспокоящегося за своего хозяина.

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

Сейчас WASM — это ASM.js без жирного JS-кодирования исходного бинаря

Мы говорим о каких-то разных wasm-ах... Я говорю, об этом https://github.com/WebAssembly/design/blob/master/FAQ.md и вот об этом https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md

Разжевываю: когда WASM станет нужен (появится DOM, GC, остальное), то одни побегут всё переписывать, другие просто пересоберут.

Когда это завезут твою scala.js выкинут на мороз и забудут как страшный сон. И еще не известно будет ли кто-то поддерживать этот флаг актуальным релизу WASM стандарта. Флаг может и выставишь, но работать ничего не будет в новых браузерах.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от ixrws

или татарина

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

Loki13 ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

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

нужно просто перестать мыслить в терминах проектного управления (pmbook-like) и переосмыслить деятельность в терминах непрерывных интеграционных процессов

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от alpha

имхо это усугубление «проблемы троечников»

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

(поэтому есть хорошее правило: нанимать на роль движков нужно людей не глупее тебя самого.)

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

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

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

alpha ★★★★★
()
Ответ на: комментарий от stevejobs

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

очень мимо

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

То есть по agile очень нужны product owner и аналитики, которые будут бежать впереди команды и готовить спринты или беклог, по которому разработчики проходят катком. И разрабочику уже работать надо в режиме «баг плохо описан - выкидываем из спринта, аналитики разбираются», «таска зависит от несделаной ещё фичи - выкидываем, project manager пускай выравнивает дедлайны», то есть думать некогда, пишем.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

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

alpha ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от alpha

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

а никаких дедлайнов не нужно. Просто не нужно. И спринтов не нужно (спринт сам по себе очень походит на дедлайн). Канбан - и вечность реализации хотелок пользователей впереди

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

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

бэклог можно отдать наполнять пользователям этого продукта

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

Если работать по описанной тобой схеме это будет вечное топтание на месте, два шага вперед, три назад, разворот на 180 градусов.

alpha ★★★★★
()
Ответ на: комментарий от stevejobs

люди, и реализуют те фичи, которые им _хочется_ реализовывать

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

А команда разработчиков на зарплате так жить не может.

alpha ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Можно на raspberry pi посмотреть, вполне себе итерации когда девайс постепенно обрастает инфраструктурой, софтом, «аксессуарами» и т.п.

alpha ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

Vit ★★★★★
()
Ответ на: комментарий от alpha

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

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

Harald ★★★★★
()
Ответ на: комментарий от alpha

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

Vit ★★★★★
()
Ответ на: комментарий от Harald

почему бы не потратить чуть больше времени

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

Это в софте легко такие вещи творить, а выпускать по 100500 прототипов дорого

Harald ★★★★★
()
Ответ на: комментарий от alpha

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

Harald ★★★★★
()
Ответ на: комментарий от alpha

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

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

Vit ★★★★★
()
Последнее исправление: Vit (всего исправлений: 2)
Ответ на: комментарий от Vit

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

А это тут причем?

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

Vit ★★★★★
()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от alpha

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

Эволюционное прототипирование вполне себе работает.

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от alpha

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Vit

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

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

Но вообще девайс, который сложно/дорого/неудобно моделировать и прототипировать, при том, что его разработка занимает существенное время - это какой-то неправильный и рискованный девайс. И возможно стоит вложиться в инфраструктуру - освоить 3д-печать из reusable пластика, написать фреймворк для быстрого моделирования, разбить на модули, найти какие-то иные способы собрать и посмотреть.. Всё так же как с софтом.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Всё так же как с софтом.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

В железе просто деваться некуда. Да и требований там поменьше чем к софту.

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

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

Vit ★★★★★
()
Ответ на: комментарий от alpha

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

Welcome to real world. Выпустить штучно многослойную плату с масками займет пару недель при оптимистичном раскладе. Перед этим ее надо разработать, а потом еще набить детальками.

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

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

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

«программист понял не так» - это не критично для проекта. а вот если архитектор налажал - это жопа.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от foror

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

И снова никакой конкретики, только вскукареки из серверной. Хотя какая может быть конкретика в контексте обсуждения заношенной демки scalajs-react.

Мы говорим о каких-то разных wasm-ах...

По ссылкам написано что-то такое, что отличается от сути? Или ты хочешь продемонстрировать нам компиляцию js-кода в wasm? Ты давай конкретно, без козыряния ссылками.

выкинут
забудут
может
работать ничего не будет

Всё, ты слился. Иди сервера админь.

shahid ★★★★★
()

ты можешь попробовать написать более эффективный алгоритм, и на это скорей всего выделят ресурсов. Можно кусок джавы переписать на С++, а кусок C++ - на ассемблере.

и прстрелить себе ногу.

В чем тогда духовное совершенствование?

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

NextGenenration ★★
()

Вам же фуллстак завезли, пиши серверы на ноде. Далее можно смотреть на TypeScript, потихоньку осваиваться с дженерик-типами и прочим. Ничего не мешает на этом этапе вкатиться в 3й питон, с которого спижжен этот ваш ESnext почти полностью. Если угорел по статик тайпингу и ФП, стоит попробовать фуллстек-скалу (Akka, AkkaHTTP, ScalaJS, или, например Play+ScalaJS), короч путей море.

anon1984
()
Ответ на: комментарий от shahid

Разжевываю: когда WASM станет нужен (появится DOM, GC, остальное)

Таких планов нет, оно концептуально для кодеков, рейтрейсеров и прочей низкоуровневщины. Очень долго ждать придется :)

anon1984
()
Ответ на: комментарий от anon1984

Таких планов нет, оно концептуально для кодеков

Отлично, значит это полнейший оффтоп в рамках темы про js.

фуллстак завезли

+1, унификация клиента и сервера даёт много возможностей, решая кучу проблем, начиная от расшаренного кода между js и сервером, и заканчивая унификацией всех проггеров в конторе. И есть для этого ровно два с половиной решения среди всего необъятного зоопарка.

shahid ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.