company_banner

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

Автор оригинала: Ann Adaya
  • Перевод
Автор материала, перевод которого мы публикуем сегодня, поддерживает идею Ральфа Уолдо Эмерсона о том, что мы становимся тем, о чём думаем. Здесь пойдёт речь об образе мыслей программистов-сеньоров.



Невозможно изучить абсолютно всё


Существует огромное количество технологий. Невозможно изучить их все.

Найдите стек технологий, который лучше всего вам подходит. Выберите технологии, которые позволят вам создавать то, что вам нужно, и досконально изучите. Например, если вас интересует современная веб-разработка, хорошим выбором будет стек MERN. В него входят MongoDB, Express, React и Node.js. Эти технологии подойдут тем, кому нравится JavaScript.

Есть, конечно, и другие наборы технологий. Например — стек MEAN. Здесь, вместо React, для разработки фронтенда используется Angular. Среди других наборов технологий, которые можно освоить, стоить отметить, например, сочетание PHP, MySQL, HTML и CSS. Здесь для фронтенда используются чистые HTML и CSS. Если вас интересует серверная разработка — можете обратить внимание на Ruby и Ruby on Rails.

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

Разработчики — это не только люди, имеющие соответствующие документы об образовании


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

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

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

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

Наполеон Хилл

Освойте искусство поиска в интернете


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

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

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

Дедлайны имеют свойство срываться


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

Неважно то, насколько детально распланирован процесс разработки. В ходе работы всегда будут возникать какие-то препятствия. Неважно то, как хороши члены команды, от бизнес-аналитиков, до специалистов по качеству ПО. Дата крайнего срока завершения работы всегда будет неточна. Эту дату придётся передвигать. Дедлайны — это всегда лишь нечто приблизительное. В большинстве случаев, в крупных компаниях, при разработке корпоративных приложений, увеличение крайних сроков на пару месяцев, это нормально.

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

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

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


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

Я трачу большую часть времени на отладку. Последним проектом, который разработала моя команда, было Android-приложение для клиента из сферы здравоохранения. Мы использовали React Native. Я в этом проекте занималась фронтендом.

Предположим, что в течение месяца на создание клиентской части приложения ушло примерно 10 дней. Всё остальное время было потрачено на отладку, на борьбу с ошибками. Например — с ошибками, вызванными зависимостями и несовместимостью разных версий различных пакетов.

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

Создавать приложение — это интересно и приятно. А вот отладка — это тяжело, да ещё и очень долго. Но деваться некуда. Это — часть работы программиста.

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

Вы будете делать вид, что знаете много всего, хотя, на самом деле, вы этого не знаете


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

Существует огромное количество технологий. Нереально разбираться во всех этих технологиях.

Не запоминайте. Стремитесь понять


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

Поначалу обучение заключается в копировании кода из учебных руководств, из репозиториев, и из прочих мест. Это нормально, но до тех пор, пока тот, кто копирует код, понимает его. Если не понимать код — само по себе копирование ничему не научит.

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

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

Документация — это ваше спасение


Вы из будущего скажете спасибо себе сегодняшнему за хорошо документированный код.

Когда вы только начнёте заниматься программированием, вы будете медленно работать над парой проектов. Потом к ним добавится ещё несколько проектов. А потом вы собьётесь со счёта.

А дальше будет так. Вы работаете над проектом №11, а начальник, совершенно неожиданно, напоминает вам о проекте №2. Нужно, чтобы вы продолжили работу над этим проектом. Проект №2 — это теперь самое важное ваше дело. А раньше, год назад, проект №2 отложили на неопределённый срок.

Вам никто не говорил о том, что проект №2 может снова стать важным, поэтому вы не позаботились о том, чтобы создать документацию для этого проекта. В результате, когда вы вернётесь к своему коду, вы, весьма вероятно, забудете о каких-то важных деталях его реализации. А самое неприятное тут то, что вы говорили начальнику о том, что проект №2 на 60% готов. Поэтому вам на его завершение дадут всего пару недель.

Собственно, мораль сей басни такова: нужно выделять время на документирование всех создаваемых вами проектов. Документация спасает жизни.

Будьте готовы к тому, что вам придётся постоянно учиться


Это — очень важная мысль.

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

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

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

А как вы думаете, какие идеи помогают программистам в профессиональном росте?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                0
                Дело не в количестве. Дело в том, как быстро вы сможете освоиться на незнакомой доселе платформе с незнакомым доселе языком. Причем, платформа может быть построена на концепциях, совершенно непохожих на те, с которыми вы раньше имели дело.
              +8
              > Отладка — это 60% работы, а программирование — 40%

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

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

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

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

                  +4

                  Думаю, что ни к какой, с учетом отладки, занимающей 60% времени.

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

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

                        +4

                        «Зачем мне юнит-тесты, если я могу типами воспользоваться»

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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


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

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

                                        А как же ревью кода, томные вечера за вдумчивым чтением бизнес-требований, бесполезные митинги, корпоративные тренинги, переписки, размерам которых бы позавидовал Лев Николаевич Толстой и прочие радости коммерческой разработки?

                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            +2
                                            Я тоже считаю, что программа готова тогда, когда она скомпилировалась.
                                              +3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                      Ну как раз КА вполне ожидаемо-то пригождаются, это очень близкая к программированию абстракция.


                                                                      А вот мне диффуры не пригодились ни разу, урматы (это которые в частных производных) — так тем более.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое