Comments 82
Объясню:
1. Разработчик грезит мыслью, что идея, которую он придумал успешна и принесёт миллионы
2. Разработчик ищет вокруг себя друзей, которые помогут с разработкой
3. Разработчик не находит друзей и одиноким вечером, когда всё надоело, принимается сделать прототип
4. Разработчик видит новый стек и мечтает, что он будет экспертом этого стека
5. Разработчик делает прототип на новой технологии, мечтая, что мол совмещает приятное с полезным, как говорится, «и прототипчик запилить, и новый стек освоить»
6. Разработчик выделяет себе каждую неделю около получаса, чтобы по чуть-чуть пилить приложение, либо выходные, либо отпуск, либо одинокие вечера
7. Разработчик доделывает прототип
8. Разработчик не становится миллионером, его проект не собирает звёзд на GitHub
9. Разработчик грустит и избивает себя синдромом самозвонца
10. Разработчик повторяет пункт 1
На выходе: базовое (среднее) понимание нового стека и новый проект в портфолио и новые грабли, на которые потом наступить будет сложнее
Именно вот эта идея делает разработчика опытнее, помимо кровавых энтерпрайзов
Скорее они мотивируют действия программиста.
Следуя этой метафоре — если это не инди-разработчик, или фрилансер — приходится выбирать удава по критериям — проект интересный/перспективный/комфортный/денежный. Как и в большинстве профессий — конвертация профессиональных навыков и потраченных усилий в средства существования — не прямолинейна и часто имеет эффективность (или соотношение) значительно меньше единицы. Приходится быть разборчивее в выборе удава и вовремя менять его.
Главная мысль тут заключается в следующем: что бы вы ни выбрали, лучше всего придерживаться этого выбора и довести до совершенства свои знания в соответствующей области. Не стоит становиться, так сказать, «подмастерьем всех ремёсел», разработчиком, который ни в чём конкретном не достиг мастерства.
По моим наблюдениям, всё ровно наоборот. Посредственные программисты сидят в одной области, не интересуясь и не изучая что происходит вокруг. А высококлассные специалисты свободно переключаются между несколькими языками/фреймворками/областями.
UPD: уточню. Наверняка существует все 4 группы: эксперт в одной области, эксперт со знанием нескольких областей, посредственный в одной области и посредственный в нескольких областях. Вот моё мнение что группы 2 и 3 больше чем группы 1 и 4 соответственно.
У меня также сомнения по поводу этого утверждения. Думаю, что в процессе освоения нужно регулярно переоценивать соотеошение усилий, результата и перспективности, чтобы небыло печально, когда достиг уровня мастера в чем-то, что уде можно сделать проще и дешевле другим способом (а то и вовсе уже не актуально).
А с заучиванием технологии до уровня мастера и ведет в категорию 1 и заставляет задумываться о том что Вы написали.
Есть такая модель — T shaped people. Кроме широкой палочки в букве Т, неплохо обладать ножкой, чтобы в случае чего иметь тотальное превосходство в какой-то отдельной теме. Ну хотя бы вот, пришел ты на фриланс-ру, хочешь взять заказ, а там уже миллион гастарбайтеров, каждый из которых делает работу из заказа лучше, чем ты, потому что специализируется на ней последние 146 лет.
высококлассные специалисты свободно переключаются между несколькими языками/фреймворками/областямиА какое количество языков/областей нормально для того, чтобы быть классным специалистом?
Вы подменяете. Я не утверждал что скилл определяется через количество языков.
Эрик Клэптон не играет такое же колво нот в секунду, как Ингви Мальмстин, но не стал от этого музыкантом хуже Ингви.
Все сказанное ниже мое имхо, но:
А где общение, консоли, субд, прокрастинация, гугл наконец? Вот это вот есть 60%, а из оставшихся 40% — 60% отладка и 40% программирование.
Поставьте себе таймтрекер автоматический, много интересного узнаете))
Интересно бы узнать — в какую из категорий автор причисляет юнит-тесты.
Просто есть категория разработчиков (не редкая, нужно заметить), считающих юнит-тесты отдельной разновидностью разработки, считающих отладку — альтернативой юнит-тестам (буквально: «зачем мне юнит-тесты, если я могу отладкой пользоваться»).
Во-вторых, код-ревью — это важная часть обязанностей сеньора, и тоже отнимает заметную часть времени. В статье идёт речь о разработке клиентской части приложения, зачастую это отдельный продукт (чтобы писать серверную часть нужны другие навыки, и обычно это тоже делает другая команда), так что да — здесь важно и написать код, и пройти QA (иначе откуда возьмутся баги, которые необходимо пофиксить?), и получить замечания на ревью от коллег и поправить их, и так до тех пор, пока не будет готова версия, которую не стыдно зарелизить (ну или пока не настанет дедлайн :)).
Если вы работаете в аутсорс конторе — то вас также будут всё время дёргать на оценку. Кроме того, кто-то должен собеседовать новых людей в команду, и при всём при этом в рабочем дне всего лишь 8 часов. Так что, если разработка у вас занимает 40% времени — это уже очень хорошо.
Я уже не говорю про то, что кто-то вместо работы играет в теннис и пьёт кофе на кухне :)
Все верно, некоторые дни время, потраченное непосредственно на разработку действительно удручающе небольшое, но все эти этапы цикла разработки важны для продукта (исключая бестолковые митинги и более, чем короткие «перекуры»).
Мне думается, что автор имеет ввиду процентные части именно времени разработки (если я правильно понял) — а не рабочего дня в целом (того самый «мифического человека-месяца).
Я, слушая их, поддакивала, и вела себя так, будто я хорошо разбираюсь в том, о чём идёт речь. А на самом деле это было не так.
Гм, а зачем это?
Как думают программисты-сеньоры?
Хочу привести тут одну рекомендацию, касающуюся образа мыслей программистов-сеньоров. Если вы безрезультатно бьётесь над одной и той же проблемой, скажем, в течение часа, попробуйте сделать перерыв.
Меня наверняка закидают тапками молодые "сеньоры", но упоминать в самом начале монго как базу для разработки это показать отсутствие опыта в больших и серьезных проектах.
Я видел много оптимистов которые начинали с монго. По мере роста проекта происходит вот что; или проект загибается или его переписывают под другую базу. Ни один настоящий "сеньор" такое выбирать не будет.
Так что и все что идёт дальше по тексту это фантазия такая. Кивание без понимания.
Каждой задаче свой инструмент, ваш пассаж против монго очень странный. Неужели нет никаких кейсов, где ее использовать можно и выгоднее, чем другие движки?
Отвечу тут, но сразу всем:
Монго с детства и до сих пор страдает очень простой болезнью её создатели не понимают различия между разработкой и продакшн.
Монго: теряет данные и запускается игнортруя это, или не запускается после рестарта хоста потому что по его мнению некорректно выключился ( остался пид файл с прошлого цикла), до сих пор имеет проблемы выбора мастера и вагон прочих бытовых проблем.
А настоящий опытный разработчик, а не "сеньор" будет думать об оперативных проблемах не меньше чем об удобстве разработки.
Ты пишешь код один раз, а работает он 24/7.
— создание правильной схемы базы данных (по mongo было в одно время много статей как лучше хранить вложенные данные)
— оптимизация запросов
— понимание как работает субд
На sql/базах данных можно тоже нагородить такое, что жуть берет.
Nosql-базы где-то даже более требовательны к уровню программиста, поэтому и косячат там сильнее (мое мнение)
И я не знаю ни одного человека с опытом который был бы доволен монго как базой.
Я на своих тестах показывал как монго падает и не восстанавливается на совсем скромных нагрузках в несколько десятков тысяч запросов при объеме базы в несколько миллионов. Выносишь одну машину из кластера — и все. Система рушится.
Я еще раз повторю — монго ужасен именно как продукт для продакшн систем.
Если кому-то интересно и выгодно бороться с его детскими болезнями в боевых системах — пожалуйста. На мой взгляд это поощрение дилетантства.
Не все что удобно для разработки надо тащить в реальные боевые системы.
Опытный разработчик понимает что пишет систему которую надо будет поддерживать и обслуживать. В большинстве случаев это будут делать другие люди, но очень часто этим «другим» окажешься ты сам.
Если есть сомнения в своей способности ее надежно использовать, всегда можно в облаке ее взять.
У меня есть сомнения в умении монго не терять данные и работать консистентно.
Я видел как эта прекрасная поделка теряет 500 гигабайт данных и даже не пишет предупреждения в лог. Я видел как оно падает, не поднимается и теряет данные.
Я видел как кластер рушится просто потому что один сервер упал а остальные не смогли договориться.
Я еще раз скажу — не вижу повода поощрять дилетантство.
Пусть чинят детские болезни, пусть улучшают, полируют, доделывают.
А я еще раз перепроверю и посмотрю подходит ли мне это для текущего таска.
Пока-что ни разу не проходило даже синтетические тесты.
Они думают очень профессионально и эффективно, не то что я.
Отладка должна занимать куда меньше (в большем числе случаев, всегда что-то может пойти не так). Даже если нет тестов. Если речь идёт о сеньере.
В остальном весьма дельно.
Я, слушая их, поддакивала, и вела себя так, будто я хорошо разбираюсь в том, о чём идёт речь. А на самом деле это было не так.
Ну так себе идея, честно. Я обычно если не понимаю, о чём речь, говорю прямо: я не понимаю, я не знаю, слышали-но-не-трогали и пр. Причём чёткое понимание, когда надо говорить «я не знаю», даже если есть какие-то смутные представления о теме разговора, пришло ещё в годы обучения в институте и работы на заводе (программировал-то я с детства, но вот устроиться по специальности удалось очень не сразу). Хотя мне ещё в магистратуре вешали лапшу про то, что нельзя говорить «я не знаю», особенно на конференциях, а «мы не работали над этим», «это не входило в сферу наших задач» и прочий бред. Это, конечно, даёт убедительно-весомый вид выступающему в научной сфере (хотя имхо является глупостью), но в реальной рабочей среде это провальная идея.
Не знаешь — честно и гордо скажи «да в душе не… ведаю!» (я вот так и делаю), уважения и то будет больше как к человеку, который честно может признать, что он не в курсе.
Я, конечно, могу предположить, что это либо «студенческое», либо у вас там в коллективе слишком ценится видимость знания, а не оно само (что снова же не гут), либо это… ну, свойственное некоторым людям, не сильно в себе уверенным (либо наоборот, слишком в себе уверенным). Причем первые обычно сидят кивают аки китайские болванчики, а вторые лезут со своим неавторитетным мнением в область, где вообще ни в зуб ногой. Как по мне, надо просто иметь смелость вовремя сделать вот так: ¯\_(ツ)_/¯ и сказать «чуваки, без понятия, о чём речь». Человек, вовремя и без паники признающий свои пробелы в знаниях, вызывает больше уважения (а если не вызывает, то это проблемы уже целевой аудитории).
Что до всего остального: ну, со многими пунктами можно поспорить, но мы все будем плеваться со своих колоколен :)
Автор материала, перевод которого мы публикуем сегодня, поддерживает идею Ральфа Уолдо Эмерсона о том, что мы становимся тем, о чём думаем.
Всё, что мы есть — это результат наших мыслей. /Гаутама Шакьямуни/
Я — разработчик-самоучка. В своём деле я преуспела благодаря комбинации тяжёлой работы, терпения, постоянства, сосредоточенности
Разработчик самоучка о том, как думают сеньйоры, учившиеся в университете. Не, ну ей лучше знать, конечно.
Выбор стеков — ОЧЕНЬ странный, особенно руби как «системный язык».
А кто это вообще такая? Беглый поиск выдает — 4 года опыта, Self-Taught Developer. Тоесть она работает столько же, сколько сеньйоры учаться в университете, а потом еще 7-10лет работают.
Беглый поиск выдает — 4 года опыта, Self-Taught Developer. Тоесть она работает столько же, сколько сеньйоры учаться в университете, а потом еще 7-10лет работают.И кстати, с каких это пор в опыт работы записывают годы обучения? Обычно свежий выпускник — это человек без опыта работы.
Ничего не настораживает?
А 4-5лет в универе это же тоже была подготовка, автор НАЧАЛА 4 года назад.
без ВО (тоесть узко-развитый)Очень мило вы ярлыки развешиваете.
В данном случае 4 года до сеньйора и «доскональное знание фреймворка», что говорит о отсутвии времени на изучение, например, теории информации или диф уравнений.
Ну я вот вспоминаю обязательные предметы во время моей вышки и ничего такого лишнего припомнить и не могу…
В данном случае 4 года до сеньйора и «доскональное знание фреймворка», что говорит о отсутвии времениТот же ангуляр, который приводят в пример в этой статье, я в свое время за пару месяцев в неспешном режиме весь исходный код просмотрел, чтобы лучше понимать, как это работает внутри. Нужно быть очень ленивым, чтобы растянуть это на несколько лет. А в большинстве случаев никто вообще исходники не читает, хватает знания публичных интерфейсов. Так что нехватка времени не может служить оправданием, четыре года — достаточный срок для формирования широкого кругозора и глубокой экспертизы в узкой области.
Ну да, за 4 года вы успеете изучить то, что читали в универе ПЛЮС то, что читали сеньйоры 10 лет своего стажа. Вообще не сомневаюсь.
Узкое — это один стэк и все.
Давайте, во-первых, сравнивать сравнимое. Старик, с общим стажем в 50 лет, вас в бараний рог уделает, с вашими 4 + 10 лет стажа. Значит ли это, что вам нельзя считаться сеньором, пока вы не будете самым опытным сеньором на всем восточном побережье?
Во вторых, давайте сравнивать сравнимое. Пока вы учитесь 4 года, весь остальной мир замирает на месте? Тогда почему вы даете фору одному, но не даете другому? Если вы 4 года учились и 4 года работали, то вам, условно, 26 лет. Если вы не учились и 4 года работали, то вам 22 года. Разумеется, очень легко сделать сравнение не в пользу последнего. А давайте наоборот — один человек 4 года просиживал штаты и по выпуску не умеет вообще ничего, а другой 8 лет активно занимался саморазвитием, как изучал отдельные дисциплины, так и практиковался — и в опен-сорсе, и в коммерческих фирмах.
Ну или грубо говоря что вам больше даст университет по сравнению с саморазвитием и что вам больше даст саморазвитие по сравнению с университетом.
И на мой взгляд университет обычно намного лучше даёт ту самую базу. То есть люди, которые занимаются саморазвитием обычно про эту базу вообще забывают или подучивают её безсистемно и не на особо хорошем уровне.
Саморазвитие с другой стороны обычно даёт больше практики и местами более актуальные ЯП/фреймворки/технологии.
Но на мой взгляд «добрать» практики иои выучить новый ЯП/фреймворк можно всегда без особых проблем. И этим всё равно придётся регулярно заниматься по ходу своей карьеры. А вот «базу донабрать» это пожалуй посложнее будет.
Но это к бы мой личный субъективный опыт. У кого-то может и по другому.
Вопрос скорее в том чем это самое «саморазвитие» в первые четыре-пять лет принципиально отличается от университета.Теория сложно идет, когда это только теория. Я помню немало случаев, когда какая-то информация мне казалась совершенно бесполезной ерундой. Но потом, после некоторого времени практики, заново открываешь для себя эту теорию и наконец приходит понимание — «так вот для чего это нужно!»
И на мой взгляд университет обычно намного лучше даёт ту самую базу.Я бы дополнил, что при условии неизменчивости этой базы и отсутствия коммерческого интереса. К примеру, математика идеально попадает под эти критерии — она не слишком изменчива, да и преподавателей никуда больше не возьмут, будь хоть они трижды математическими гениями. А вот с информатикой сложнее — кроме самых базовых вещей она меняется и развивается довольно динамично, вдобавок остаются в основном плохие преподаватели, которые больше нигде не нужны. Хотя исключения, конечно, есть.
Теория сложно идет, когда это только теория.
А практика без теории часто ведёт к неправильному пониманию предмета. И я бы сказал что это всё-таки похуже ситуация.
Кроме того неужели у вас в университете/институте была только теория и практики не было вообще?
А вот с информатикой сложнее
А что с ней сложнее? Что такого за последние годы сильно изменилось в математике, алгоритмике, теоритической информатике, базовом устройстве компьютеров? Появилось прямо куча новых концептов и парадигм?
А что там прявляются новые языки, фреймворки и технологии так это на мой взгляд для получения основ как-раз таки и ре особо важно.
Кроме того далеко не во всех университетах преподают по устаревшим технологиям. В некоторых наоборот скорее студенты получают беты/пререлизы новых вещей. У нас вон давали с С# поиграться ещё в конце 90-х.
Да и уровень преподавателей это проблема далеко не во всех университетах/странах.
А по тому, что вы спросили — ну бывают уникумы, которые могут понять все без обьяснений и вопросов лектору, без практических занятий и только по книгам. Но таких единицы на планету. Потому все же большинство учится в университетах и не рассказывает, что это все не нужно. Нет никакой форы. Просто если у человека диплом, вы можете предполагать, что общие темы он знает(базы данных, дискретку, теорию сложности и так далее). А если нет — все очень сложно. Обычно такой самоучка просто не понимает, где он косячит.
Да и разработчик-разработчику рознь. Кому-то это самое ВО действительно вообще не сдалось, а кому-то без него сложновато будет.
П.С. Ну и да, по моему опыту разработчики с ВО заметно чаще становятся сениорами чем разработчики после ПТУ/техникума. А вот сениора-самоучку я лично вообще ни одного не знаю. Но может это просто действительно просто мне так «повезло» и/или играют роль «региональные особенности»…
Ну и как бы страны они разные. Там где я живу ну вот вообще не обязательно получать ВО чтобы стать айтишником. Вполне хватает техникума. И поэтому среди айтишников получать ВО идёт гораздо меньше народа чем в России.
Ну а при необходимости его достаточно просто потом сделать заочно или комбинируя с работой по специальным программам. Особенно если ты айтишник.
Очень похоже на рассуждения о сеньорстве начинающего мидла вчерашнего джуна. Извините. По ходу дела, оно совсем не про то, чтобы досконально изучить Реакт. Доскональное изучение Реакта — вообще джуновая тема.
Того кто поставил на этой фразе свой копирайт ещё в проекте не было, когда техника уже была.
finally
или какие есть типы индексов в SQL.Теперь насчет пунктов:
1) Невозможно изучить абсолютно всё
Невозможно — да, но стараться нужно — должен быть широкий кругозор. Если знать только MERN и не учить ничего другого, то ты будешь везде пытаться его применить. Вспоминается шутка про молоток и гвозди. А ведь у каждой технологии есть свои ограничения и MERN не всегда является лучшим выбором. А человек, который знаком с несколькими технологиями, сможет оптимально подобрать технологию.
2) Все остальные пункты
Не знаю, какое отношение они имеют конкретно к образу мыслей синьора, по-хорошему все это должен понимать любой разработчик: учиться надо всегда, периодически обновлять документацию, не срывать дедлайны и т.д.
Статья не раскрывает заголовок. Мне стало жалко время и поэтому потрачу ещё немного. Интересен диалог, может быть как-то не так мыслю и будут аргументы.
Мне нравится, что сплошь и рядом из-за некачественного образования не в ведущих вузах стран предлагают не учиться в институтах, как говорится: «пусть продолжают в этом духе, зачем мне конкуренция». Да, каждый год прохожу 1-2 технических курса, чтобы оставаться в теме и видеть реальный опыт практикующих людей, но это в дополнения к полученным основам. Ну и на работе вкладываю в людей время и другие ресурсы, что даёт результаты в закрытии проектов практически в срок и если расстаёмся, то в кратном повышении их ЗП. Безусловно, по большей части это их заслуга, но и других не берём ;)
А по заданному вами вопросу — наставник. Желательно адекватный, замотивированный научить для своей разгрузки (делегирование задач). Другие пути тернисты и менее эффективны.
Если бы автор училась в институте, то ей бы рассказали о доступности знаний и она не тратила время на написание, осмысление и другие сотрясения воздуха ) К слову, знаю крутых самоучек, часто они выбирают одну-две области и становятся там хорошими специалистами.
Да, я тоже самоучка. Программистом нельзя стать, программиста можно в себе открыть.
Я открыл где-то в 1964 году на последнем курсе техникума, где программирование вообще не изучалось.
И вот за последние полвека я для себя сформулировал определение программирования:
«Программирование — это гармонизация окружающей реальности при помощи моделирования её на компьютере».
Тут нет ничего про технологии, поскольку они остаются за скобками. То есть, всегда какие-то технологии есть, всегда чем-то нужно пользоваться. Но для программиста они не столь важны. Их или навязывает руководство, либо используемое окружение, или дело вкуса.
Программист не столько программу пишет, сколько решает задачу. Имеющимися средствами-технологиями.
То, что для того чтобы стать разработчиком, необязательно оканчивать университет, не значит, что разработка — это просто.
Обязательно, обязательно заканчивать ВУЗ. Возможно, и получить научную степень. Это полезно для решения задач и вообще тренирует мозг — главный аппарат программиста.
А без образования — всегда будешь на подхвате и вечно — доказывать, что ты умный и достоин хорошей зарплаты.
А без образования — всегда будешь на подхвате и вечно — доказывать, что ты умный и достоин хорошей зарплаты.Нет. В моей практике никому не было дела до образования. Только джунам которые спрашивают друг друга кто где учился. И говорят «Вау» когда узнают что у меня нет программерского образования. (На самом деле было программирование… факультативом, 1 семестр, раз в 2 недели.)
Сеньор это не тот кто знает как надо, а тот, кто знает как не надо делать. Т.е. человек, наступивший в своей жизни на достаточное количество граблей (без этого, увы, никак — опыт это то, что мы получаем вместо того что ожидали получить) и сделавший из этого правильные выводы.
Сеньор это то, кто получив задачу и видя ее решение, прежде всего думает — а нет ли другого, более эффективного, решения?
Сеньор это то, кто знает какой кусок кода достаточно сделать лишь бы корректно работало (и потратить на это меньше сил и времени), а какой должен быть вылизан до блеска и работать с максимальной эффективностью т.к. он является критическим в плане общей производительности продукта.
Наверное, можно еще продолжать, но первое что пришло в голову со своей болотной кочки.
Как думают программисты-сеньоры?