Как стать автором
Обновить

Комментарии 82

По моему скромному мнению, умение контролируемой мечты по Agile
Объясню:

1. Разработчик грезит мыслью, что идея, которую он придумал успешна и принесёт миллионы
2. Разработчик ищет вокруг себя друзей, которые помогут с разработкой
3. Разработчик не находит друзей и одиноким вечером, когда всё надоело, принимается сделать прототип
4. Разработчик видит новый стек и мечтает, что он будет экспертом этого стека
5. Разработчик делает прототип на новой технологии, мечтая, что мол совмещает приятное с полезным, как говорится, «и прототипчик запилить, и новый стек освоить»
6. Разработчик выделяет себе каждую неделю около получаса, чтобы по чуть-чуть пилить приложение, либо выходные, либо отпуск, либо одинокие вечера
7. Разработчик доделывает прототип
8. Разработчик не становится миллионером, его проект не собирает звёзд на GitHub
9. Разработчик грустит и избивает себя синдромом самозвонца
10. Разработчик повторяет пункт 1

На выходе: базовое (среднее) понимание нового стека и новый проект в портфолио и новые грабли, на которые потом наступить будет сложнее

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

Скорее они мотивируют действия программиста.

Главное, чтобы морковкой управлял не удав — для него мотивированный кролик вкуснее

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

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

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

UPD: уточню. Наверняка существует все 4 группы: эксперт в одной области, эксперт со знанием нескольких областей, посредственный в одной области и посредственный в нескольких областях. Вот моё мнение что группы 2 и 3 больше чем группы 1 и 4 соответственно.

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

Я думаю шкала slonopotamus больше коррелирует с пониманием принципов работы. Условный пример: не нужно наизусть знать все настройки Postgres и как они прописываются, достаточно знать что они бывают и как они влияют на работу, а еще лучше знать как проходит запрос со всем парсингом, оптимизацией и выбором стратегии, и знать что можно посмотреть explain и при необходимости каждый этап можно потюнить. Понимание принципов работы избавляет от необходимости запоминать все на свете и при этом позволяет решать задачу примерно так же хорошо как и решение «мастера». Соответственно если человек понимает одну технологию, то и другие ему даются более-менее легко. И наоборот.

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

Есть такая модель — T shaped people. Кроме широкой палочки в букве Т, неплохо обладать ножкой, чтобы в случае чего иметь тотальное превосходство в какой-то отдельной теме. Ну хотя бы вот, пришел ты на фриланс-ру, хочешь взять заказ, а там уже миллион гастарбайтеров, каждый из которых делает работу из заказа лучше, чем ты, потому что специализируется на ней последние 146 лет.

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

Вы подменяете. Я не утверждал что скилл определяется через количество языков.

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

Эрик Клэптон не играет такое же колво нот в секунду, как Ингви Мальмстин, но не стал от этого музыкантом хуже Ингви.

> Отладка — это 60% работы, а программирование — 40%

Все сказанное ниже мое имхо, но:

А где общение, консоли, субд, прокрастинация, гугл наконец? Вот это вот есть 60%, а из оставшихся 40% — 60% отладка и 40% программирование.

Поставьте себе таймтрекер автоматический, много интересного узнаете))

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

НЛО прилетело и опубликовало эту надпись здесь
За автора не скажу, но как по мне так юнит-тесты — это тоже разработка. Хотя с учетом 60% на отладку, то и часть отладки возможно. Хотя вот OnYourLips в комментарии выше думает по другому)

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

НЛО прилетело и опубликовало эту надпись здесь
Ждал этого комментария)
Код-ревью тоже незаслуженно обошли стороной.
Вероятно имелась ввиду непосредственно работа программиста над определенной функциональности, иначе нужно учесть и остальные составляющие цикла разработки — QA, DevOps, последующие рефакторинг и багфигсинг и т.д. Они все важны, если мы говорим о продукте, а не просто о программе или одной конкретной функциональности (к последней я и отношу юнит-тесты).
Ну я позволю себе с вами не согласиться. Во-первых, по-хорошему, QA и DevOps — это отдельные люди (и даже отделы). Рефакторинг и багфиксинг сводится к тому, чтобы разобраться и написать код. Юнит-тесты — тоже код. Лично я замечаю, что чем дальше — тем меньше времени отнимает именно написание кода.
Во-вторых, код-ревью — это важная часть обязанностей сеньора, и тоже отнимает заметную часть времени. В статье идёт речь о разработке клиентской части приложения, зачастую это отдельный продукт (чтобы писать серверную часть нужны другие навыки, и обычно это тоже делает другая команда), так что да — здесь важно и написать код, и пройти QA (иначе откуда возьмутся баги, которые необходимо пофиксить?), и получить замечания на ревью от коллег и поправить их, и так до тех пор, пока не будет готова версия, которую не стыдно зарелизить (ну или пока не настанет дедлайн :)).
Если вы работаете в аутсорс конторе — то вас также будут всё время дёргать на оценку. Кроме того, кто-то должен собеседовать новых людей в команду, и при всём при этом в рабочем дне всего лишь 8 часов. Так что, если разработка у вас занимает 40% времени — это уже очень хорошо.
Я уже не говорю про то, что кто-то вместо работы играет в теннис и пьёт кофе на кухне :)

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

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

Гм, а зачем это?

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

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

Как думают программисты-сеньоры?

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

Откуда же копирайтеру с апворка знать, как думают сеньоры?

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


Так что и все что идёт дальше по тексту это фантазия такая. Кивание без понимания.

НЛО прилетело и опубликовало эту надпись здесь
Я извиняюсь уж, но я никогда не жил в россии и не живу сейчас, с сервисом этим незнаком.
Так что я полез смотреть что это такое.
Так это маил.ру — компания известная далеко за пределами некачественными продуктами и покупанием + убиванием того что работало.
Так что нет.
Не серьезный проект.
НЛО прилетело и опубликовало эту надпись здесь
Согласен с DesolatoR. Имел опыт работы в большом и серьёзном проекте, стоящем недалеко от Юлы в топе интернет-проектов. MongoDB там идеально вписывалась как основная БД. Вопрос специфики использования.

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

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

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


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


А настоящий опытный разработчик, а не "сеньор" будет думать об оперативных проблемах не меньше чем об удобстве разработки.
Ты пишешь код один раз, а работает он 24/7.

Это зависит от знаний программиста:
— создание правильной схемы базы данных (по mongo было в одно время много статей как лучше хранить вложенные данные)
— оптимизация запросов
— понимание как работает субд
На sql/базах данных можно тоже нагородить такое, что жуть берет.
Nosql-базы где-то даже более требовательны к уровню программиста, поэтому и косячат там сильнее (мое мнение)
Все зависит от уровня программиста, но мы же говорим об опытных людях, да?

И я не знаю ни одного человека с опытом который был бы доволен монго как базой.
Я на своих тестах показывал как монго падает и не восстанавливается на совсем скромных нагрузках в несколько десятков тысяч запросов при объеме базы в несколько миллионов. Выносишь одну машину из кластера — и все. Система рушится.

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

У меня есть сомнения в умении монго не терять данные и работать консистентно.

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

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

Пока-что ни разу не проходило даже синтетические тесты.
> Как думают программисты-сеньоры?
Они думают очень профессионально и эффективно, не то что я.

Отладка должна занимать куда меньше (в большем числе случаев, всегда что-то может пойти не так). Даже если нет тестов. Если речь идёт о сеньере.


В остальном весьма дельно.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я тоже считаю, что программа готова тогда, когда она скомпилировалась.
НЛО прилетело и опубликовало эту надпись здесь
Изучать стек досконально это утопия. Его срок жизни порядка 10 лет. Потом придется либо стареть, теряя себя на рынке труда, либо становиться «юниором» и начинать все сначала, что непросто по возрасту и по зарплатным ожиданиям. Поэтому совет вредный. В нашем климате как раз-таки удобнее всего знать много разного понемногу, но ничего не знать хорошо. Потому что к моменту, когда ты узнаешь это всесторонне, оно уже будет почти никому не надо, а там где надо — будет высокая конкуренция и/или сомнительные перспективы. Жизнь программиста это бесконечное верчение в погоне за своим хвостом без достижения какого-либо долговременного результата.
В ее случае досканально — 4 года.
Я, слушая их, поддакивала, и вела себя так, будто я хорошо разбираюсь в том, о чём идёт речь. А на самом деле это было не так.

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

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

Я, конечно, могу предположить, что это либо «студенческое», либо у вас там в коллективе слишком ценится видимость знания, а не оно само (что снова же не гут), либо это… ну, свойственное некоторым людям, не сильно в себе уверенным (либо наоборот, слишком в себе уверенным). Причем первые обычно сидят кивают аки китайские болванчики, а вторые лезут со своим неавторитетным мнением в область, где вообще ни в зуб ногой. Как по мне, надо просто иметь смелость вовремя сделать вот так: ¯\_(ツ)_/¯ и сказать «чуваки, без понятия, о чём речь». Человек, вовремя и без паники признающий свои пробелы в знаниях, вызывает больше уважения (а если не вызывает, то это проблемы уже целевой аудитории).

Что до всего остального: ну, со многими пунктами можно поспорить, но мы все будем плеваться со своих колоколен :)
ну вот да, спросила, а чо оно такое в общем, потом прибежала домой, открыла книжку или там ютуб, прочла, составила представление, запилила хелловорлд, спросила знакомых аксакалов, может быть, кто работал с этим зверем. А вот это кивание — кому оно вообще выгодно?
Автор материала, перевод которого мы публикуем сегодня, поддерживает идею Ральфа Уолдо Эмерсона о том, что мы становимся тем, о чём думаем.

Всё, что мы есть — это результат наших мыслей. /Гаутама Шакьямуни/

Я — разработчик-самоучка. В своём деле я преуспела благодаря комбинации тяжёлой работы, терпения, постоянства, сосредоточенности

Разработчик самоучка о том, как думают сеньйоры, учившиеся в университете. Не, ну ей лучше знать, конечно.
Выбор стеков — ОЧЕНЬ странный, особенно руби как «системный язык».

А кто это вообще такая? Беглый поиск выдает — 4 года опыта, Self-Taught Developer. Тоесть она работает столько же, сколько сеньйоры учаться в университете, а потом еще 7-10лет работают.
Не то, чтобы я был с вами в чем-то не согласен по её поводу, но вы слишком уж переоцениваете значение государственного образования для разработчика. Зачастую самостоятельно прочитанная книжка и самостоятельная же практика даст гораздо больше, чем просиживание штанов на лекциях. Математике — да, научат, а вот программированию — совершенно точно нет. Как минимум потому, что хороший программист не пойдет работать за зарплату в пять раз меньше, чем у него сейчас, и нервотрепкой в десять раз больше.

Беглый поиск выдает — 4 года опыта, Self-Taught Developer. Тоесть она работает столько же, сколько сеньйоры учаться в университете, а потом еще 7-10лет работают.
И кстати, с каких это пор в опыт работы записывают годы обучения? Обычно свежий выпускник — это человек без опыта работы.
Ну не записывайте. Человек с 4мя годами опыта без ВО(тоесть узко-развитый)рассказывает вам, как думают люди с 7-10 годами опыта.
Ничего не настораживает?
А 4-5лет в универе это же тоже была подготовка, автор НАЧАЛА 4 года назад.
без ВО (тоесть узко-развитый)
Очень мило вы ярлыки развешиваете.
ВО дает кроме предметов, которые хочет изучать конкретно этот человек, еще и обязательные.
В данном случае 4 года до сеньйора и «доскональное знание фреймворка», что говорит о отсутвии времени на изучение, например, теории информации или диф уравнений.
А какие «обязательные предметы», которые даёт ВО, по вашему не нужны программисту? Немного математики? Алгоритмика и теоретическая информатика? Немного электротехники? Базовые знания по базам данных и коммуникациям?

Ну я вот вспоминаю обязательные предметы во время моей вышки и ничего такого лишнего припомнить и не могу…
А зачем вы мне это пишете? Я как бы не ставлю под сомнение полезность ВО, у меня на предметах, который я вообще бы не стал изучать самостоятельно вся карьера построена.
Похоже неправильно интерпретировал ваш комментарий. Mea culpa.
И часто вам диф уравнения пригождались в карьере веб-разработчика?) К слову, под широким кругозором обычно понимают широкий кругозор, а не узкий. Математика с программированиям — соседи, живущие в одной коммуналке.

В данном случае 4 года до сеньйора и «доскональное знание фреймворка», что говорит о отсутвии времени
Тот же ангуляр, который приводят в пример в этой статье, я в свое время за пару месяцев в неспешном режиме весь исходный код просмотрел, чтобы лучше понимать, как это работает внутри. Нужно быть очень ленивым, чтобы растянуть это на несколько лет. А в большинстве случаев никто вообще исходники не читает, хватает знания публичных интерфейсов. Так что нехватка времени не может служить оправданием, четыре года — достаточный срок для формирования широкого кругозора и глубокой экспертизы в узкой области.
Да, мне пару раз пригодилися дифуры. А также, как ни странно, конечные автоматы(вот уж вообще никогда бы не подумал).
Ну да, за 4 года вы успеете изучить то, что читали в универе ПЛЮС то, что читали сеньйоры 10 лет своего стажа. Вообще не сомневаюсь.

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

Давайте, во-первых, сравнивать сравнимое. Старик, с общим стажем в 50 лет, вас в бараний рог уделает, с вашими 4 + 10 лет стажа. Значит ли это, что вам нельзя считаться сеньором, пока вы не будете самым опытным сеньором на всем восточном побережье?

Во вторых, давайте сравнивать сравнимое. Пока вы учитесь 4 года, весь остальной мир замирает на месте? Тогда почему вы даете фору одному, но не даете другому? Если вы 4 года учились и 4 года работали, то вам, условно, 26 лет. Если вы не учились и 4 года работали, то вам 22 года. Разумеется, очень легко сделать сравнение не в пользу последнего. А давайте наоборот — один человек 4 года просиживал штаты и по выпуску не умеет вообще ничего, а другой 8 лет активно занимался саморазвитием, как изучал отдельные дисциплины, так и практиковался — и в опен-сорсе, и в коммерческих фирмах.
Вопрос скорее в том чем это самое «саморазвитие» в первые четыре-пять лет принципиально отличается от университета.

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

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

Саморазвитие с другой стороны обычно даёт больше практики и местами более актуальные ЯП/фреймворки/технологии.

Но на мой взгляд «добрать» практики иои выучить новый ЯП/фреймворк можно всегда без особых проблем. И этим всё равно придётся регулярно заниматься по ходу своей карьеры. А вот «базу донабрать» это пожалуй посложнее будет.

Но это к бы мой личный субъективный опыт. У кого-то может и по другому.
Вопрос скорее в том чем это самое «саморазвитие» в первые четыре-пять лет принципиально отличается от университета.
Теория сложно идет, когда это только теория. Я помню немало случаев, когда какая-то информация мне казалась совершенно бесполезной ерундой. Но потом, после некоторого времени практики, заново открываешь для себя эту теорию и наконец приходит понимание — «так вот для чего это нужно!»

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

А практика без теории часто ведёт к неправильному пониманию предмета. И я бы сказал что это всё-таки похуже ситуация.

Кроме того неужели у вас в университете/институте была только теория и практики не было вообще?

А вот с информатикой сложнее

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

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

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

А по тому, что вы спросили — ну бывают уникумы, которые могут понять все без обьяснений и вопросов лектору, без практических занятий и только по книгам. Но таких единицы на планету. Потому все же большинство учится в университетах и не рассказывает, что это все не нужно. Нет никакой форы. Просто если у человека диплом, вы можете предполагать, что общие темы он знает(базы данных, дискретку, теорию сложности и так далее). А если нет — все очень сложно. Обычно такой самоучка просто не понимает, где он косячит.
НЛО прилетело и опубликовало эту надпись здесь
Дифуры нужны для понимания других разделов, которые могут пригодится.
Дифуры, матан и дискретка — без вариантов нужны, без них половину программы нереально осилить.
Высшее образование оно ведь очень разное бывает. Даже в пределах одной страны. А уж если смотреть что в мире творится… И кстати во многих странах можно очень по разному учится на программиста. Например в отдельных странах программистов в том числе учат и в ПТУ/Техникумах.

Да и разработчик-разработчику рознь. Кому-то это самое ВО действительно вообще не сдалось, а кому-то без него сложновато будет.

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

Ну и как бы страны они разные. Там где я живу ну вот вообще не обязательно получать ВО чтобы стать айтишником. Вполне хватает техникума. И поэтому среди айтишников получать ВО идёт гораздо меньше народа чем в России.
Ну а при необходимости его достаточно просто потом сделать заочно или комбинируя с работой по специальным программам. Особенно если ты айтишник.
Боюсь, что про другие страны не могу ничего сказать, не сталкивался лично. Скорее всего, вы правы.
Ну товарищ, когда у вас было 4 года опыта, вы тоже все на свете знали!

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

Мы становимся тем, о чём думаем — это одна из ступеней Йоги.
Того кто поставил на этой фразе свой копирайт ещё в проекте не было, когда техника уже была.
НЛО прилетело и опубликовало эту надпись здесь
Лучше избегать категоризации «джун», «мидл», «синьор», потому что во многих компаниях эти звания раздают всем подряд и они сильно девальвировались. Так на некоторых собеседованиях почтенные «синьоры» и «лиды» не могли объяснить что означает ключевое слово finally или какие есть типы индексов в SQL.

Теперь насчет пунктов:
1) Невозможно изучить абсолютно всё
Невозможно — да, но стараться нужно — должен быть широкий кругозор. Если знать только MERN и не учить ничего другого, то ты будешь везде пытаться его применить. Вспоминается шутка про молоток и гвозди. А ведь у каждой технологии есть свои ограничения и MERN не всегда является лучшим выбором. А человек, который знаком с несколькими технологиями, сможет оптимально подобрать технологию.

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

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

Мне нравится, что сплошь и рядом из-за некачественного образования не в ведущих вузах стран предлагают не учиться в институтах, как говорится: «пусть продолжают в этом духе, зачем мне конкуренция». Да, каждый год прохожу 1-2 технических курса, чтобы оставаться в теме и видеть реальный опыт практикующих людей, но это в дополнения к полученным основам. Ну и на работе вкладываю в людей время и другие ресурсы, что даёт результаты в закрытии проектов практически в срок и если расстаёмся, то в кратном повышении их ЗП. Безусловно, по большей части это их заслуга, но и других не берём ;)

А по заданному вами вопросу — наставник. Желательно адекватный, замотивированный научить для своей разгрузки (делегирование задач). Другие пути тернисты и менее эффективны.
Если бы автор училась в институте, то ей бы рассказали о доступности знаний и она не тратила время на написание, осмысление и другие сотрясения воздуха ) К слову, знаю крутых самоучек, часто они выбирают одну-две области и становятся там хорошими специалистами.
Я — разработчик-самоучка. В своём деле я преуспела благодаря комбинации тяжёлой работы, терпения, постоянства, сосредоточенности.

Да, я тоже самоучка. Программистом нельзя стать, программиста можно в себе открыть.
Я открыл где-то в 1964 году на последнем курсе техникума, где программирование вообще не изучалось.
И вот за последние полвека я для себя сформулировал определение программирования:
«Программирование — это гармонизация окружающей реальности при помощи моделирования её на компьютере».

Тут нет ничего про технологии, поскольку они остаются за скобками. То есть, всегда какие-то технологии есть, всегда чем-то нужно пользоваться. Но для программиста они не столь важны. Их или навязывает руководство, либо используемое окружение, или дело вкуса.
Программист не столько программу пишет, сколько решает задачу. Имеющимися средствами-технологиями.
То, что для того чтобы стать разработчиком, необязательно оканчивать университет, не значит, что разработка — это просто.
Обязательно, обязательно заканчивать ВУЗ. Возможно, и получить научную степень. Это полезно для решения задач и вообще тренирует мозг — главный аппарат программиста.
А без образования — всегда будешь на подхвате и вечно — доказывать, что ты умный и достоин хорошей зарплаты.
А без образования — всегда будешь на подхвате и вечно — доказывать, что ты умный и достоин хорошей зарплаты.
Нет. В моей практике никому не было дела до образования. Только джунам которые спрашивают друг друга кто где учился. И говорят «Вау» когда узнают что у меня нет программерского образования. (На самом деле было программирование… факультативом, 1 семестр, раз в 2 недели.)
На мой скромный взгляд сеньорство определяется не количеством стеков и фреймворков, которые человек знает и умеет, а прежде всего опытом и подходом.

Сеньор это не тот кто знает как надо, а тот, кто знает как не надо делать. Т.е. человек, наступивший в своей жизни на достаточное количество граблей (без этого, увы, никак — опыт это то, что мы получаем вместо того что ожидали получить) и сделавший из этого правильные выводы.

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

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

Наверное, можно еще продолжать, но первое что пришло в голову со своей болотной кочки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий