Pull to refresh

Comments 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% программирование.

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

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

UFO just landed and posted this here
За автора не скажу, но как по мне так юнит-тесты — это тоже разработка. Хотя с учетом 60% на отладку, то и часть отладки возможно. Хотя вот OnYourLips в комментарии выше думает по другому)

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

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

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

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

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

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

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

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

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

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

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


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

UFO just landed and posted this here
Я извиняюсь уж, но я никогда не жил в россии и не живу сейчас, с сервисом этим незнаком.
Так что я полез смотреть что это такое.
Так это маил.ру — компания известная далеко за пределами некачественными продуктами и покупанием + убиванием того что работало.
Так что нет.
Не серьезный проект.
UFO just landed and posted this here

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

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

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


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


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

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

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

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

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

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

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

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

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


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

UFO just landed and posted this here
UFO just landed and posted this here
Я тоже считаю, что программа готова тогда, когда она скомпилировалась.
UFO just landed and posted this here
Изучать стек досконально это утопия. Его срок жизни порядка 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мя годами опыта ВСЕГО который к тому же рассказывает о том, как другие думают(без курса общей психологии, похоже).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверное, можно еще продолжать, но первое что пришло в голову со своей болотной кочки.
Sign up to leave a comment.