Автор материала, перевод которого мы публикуем сегодня, поддерживает идею Ральфа Уолдо Эмерсона о том, что мы становимся тем, о чём думаем. Здесь пойдёт речь об образе мыслей программистов-сеньоров.
Существует огромное количество технологий. Невозможно изучить их все.
Найдите стек технологий, который лучше всего вам подходит. Выберите технологии, которые позволят вам создавать то, что вам нужно, и досконально изучите. Например, если вас интересует современная веб-разработка, хорошим выбором будет стек MERN. В него входят MongoDB, Express, React и Node.js. Эти технологии подойдут тем, кому нравится JavaScript.
Есть, конечно, и другие наборы технологий. Например — стек MEAN. Здесь, вместо React, для разработки фронтенда используется Angular. Среди других наборов технологий, которые можно освоить, стоить отметить, например, сочетание PHP, MySQL, HTML и CSS. Здесь для фронтенда используются чистые HTML и CSS. Если вас интересует серверная разработка — можете обратить внимание на Ruby и Ruby on Rails.
Главная мысль тут заключается в следующем: что бы вы ни выбрали, лучше всего придерживаться этого выбора и довести до совершенства свои знания в соответствующей области. Не стоит становиться, так сказать, «подмастерьем всех ремёсел», разработчиком, который ни в чём конкретном не достиг мастерства. Подобное приводит к хождению по кругу, а это явно не то, что вам нужно.
Я — разработчик-самоучка. В своём деле я преуспела благодаря комбинации тяжёлой работы, терпения, постоянства, сосредоточенности.
То, что для того чтобы стать разработчиком, необязательно оканчивать университет, не значит, что разработка — это просто. Стать разработчиком нелегко. И в движении к цели не стоит позволять себе считать концом всего небольшое поражение в чём бы то ни было. Всё дело в стремлении к цели.
Если, столкнувшись со сложностями, вызванными недостатком базового образования, просто сдаться, то, конечно, ничего достичь не удастся. Секрет в том, чтобы после того, как что-то пойдёт не так, попробовать ещё раз. В том, чтобы сделать ещё одну попытку, и в том, чтобы держаться своей линии всегда, каждый день, каждый раз, когда кажется, что всё уже потеряно. Когда возникает подобное ощущение, когда кажется, что вот оно — дно, нужно помнить о том, что это — обычно знак того, что цель почти достигнута, что осталось совсем немного. В таких случаях надо просто предложить себе попробовать ещё раз и превратить препятствия в возможности.
Наполеон Хилл
Теперь, когда вы начали заниматься программированием, вам стоит знать о том, что у вас будет такое ощущение, будто всё, что вы делаете, бессмысленно. Вполне нормально — не знать ответов на все вопросы, особенно тогда, когда вы только начинаете свой путь. Важно знать о том, где искать ответы.
Программирование — это решение проблем. Если вы не можете додуматься до того, как решить стоящую перед вами проблему — найдите способ её решения в Сети. Поищите в интернете того, кто знает о том, как решать стоящую перед вами проблему и поучитесь у него. Именно это — лучший способ изучения программирования.
Вот вам ценный совет: все задачи из сферы программирования, которые встают перед вами сегодня, вероятно, уже вставали перед программистами и раньше. Не стоит изобретать колесо. Лучше взять это колесо, уже кем-то изобретённое, и воспользоваться им.
Каким бы хорошим ни был план, оценивать сроки — это всегда очень непросто. Существует несколько стратегий, используемых компаниями в деле управления проектами. Я полагаю, что самая популярная из таких стратегий — это Agile.
Неважно то, насколько детально распланирован процесс разработки. В ходе работы всегда будут возникать какие-то препятствия. Неважно то, как хороши члены команды, от бизнес-аналитиков, до специалистов по качеству ПО. Дата крайнего срока завершения работы всегда будет неточна. Эту дату придётся передвигать. Дедлайны — это всегда лишь нечто приблизительное. В большинстве случаев, в крупных компаниях, при разработке корпоративных приложений, увеличение крайних сроков на пару месяцев, это нормально.
А вот если речь идёт о маленьких проектах, которые делают для небольших компаний, к срокам сдачи таких проектов уже относятся строже. Если вы планируете заняться сторонним проектом, то, клиенты, в ходе переговоров, чаще всего задают вопрос о том, когда всё будет готово. Некоторые представители бизнеса не интересуются тем, как будет сделано дело. Им важно знать лишь срок сдачи проекта.
Поэтому проявляйте осторожность, называя даты и устанавливая дедлайны. Обычно те, с кем вы будете разговаривать, считают эти дедлайны чем-то неизменным. Лучше всего рассчитывать на то, что на работу понадобится больше времени, чем планировалось. Речь идёт о решении неожиданных проблем, об отладке и о прочем подобном. Лучше удивить клиента сдачей проекта раньше срока, чем расстроить, сорвав дедлайн. В общем, как говорится, держите марку.
Пожалуй, идея, вынесенная в заголовок, представляет собой самую точную оценку распределения времени программиста, которую мне доводилось встречать.
Я трачу большую часть времени на отладку. Последним проектом, который разработала моя команда, было Android-приложение для клиента из сферы здравоохранения. Мы использовали React Native. Я в этом проекте занималась фронтендом.
Предположим, что в течение месяца на создание клиентской части приложения ушло примерно 10 дней. Всё остальное время было потрачено на отладку, на борьбу с ошибками. Например — с ошибками, вызванными зависимостями и несовместимостью разных версий различных пакетов.
Это был мой первый проект для платформы Android. Недели ушли только на то, чтобы отладить некоторые части приложения, и на проверку того, что они устроены именно так, как нужно, включая использование в них определённых версий зависимостей.
Создавать приложение — это интересно и приятно. А вот отладка — это тяжело, да ещё и очень долго. Но деваться некуда. Это — часть работы программиста.
Хочу привести тут одну рекомендацию, касающуюся образа мыслей программистов-сеньоров. Если вы безрезультатно бьётесь над одной и той же проблемой, скажем, в течение часа, попробуйте сделать перерыв. Займитесь чем-нибудь другим, освободите свой разум… Иногда мы сами являемся источником проблем, с которыми сталкиваемся.
Я тоже так поступала. Например, несколько коллег обсуждали какие-то технологии, которые они использовали, или новые технологии, которые им интересны. Я, слушая их, поддакивала, и вела себя так, будто я хорошо разбираюсь в том, о чём идёт речь. А на самом деле это было не так. Собственно говоря, я хочу донести до вас мысль о том, что это нормально, и о том, что вы в этом не одиноки.
Существует огромное количество технологий. Нереально разбираться во всех этих технологиях.
Я уделяла и уделяю большое внимание важности изучения основ программирования.
Поначалу обучение заключается в копировании кода из учебных руководств, из репозиториев, и из прочих мест. Это нормально, но до тех пор, пока тот, кто копирует код, понимает его. Если не понимать код — само по себе копирование ничему не научит.
После нескольких месяцев такой учёбы начнёт приходить более глубокое понимание происходящего. А именно, человек начнёт усваивать синтаксические конструкции кода и некоторые принципы программирования. Потом должен настать момент, когда будет получаться, без подсказок, решать какие-то задачи самостоятельно. Тут нужны сознательные усилия того, кто учится программировать. А именно, нужно решать задачи, создавая код самостоятельно, используя собственный подход к решению задач, собственный стиль, собственные идеи.
Смысл тут заключается в том, чтобы не тратить слишком много времени на «копипастинг» кода. Не стоит бояться самостоятельно решать различные задачи. Путь проб и ошибок научит большему, чем «копипаста», поэтому стоит брать задачи и работать над ними до тех пор, пока то, что казалось сложным, не начнёт казаться простым и понятным. На это, конечно, понадобится время, но это и есть программирование.
Вы из будущего скажете спасибо себе сегодняшнему за хорошо документированный код.
Когда вы только начнёте заниматься программированием, вы будете медленно работать над парой проектов. Потом к ним добавится ещё несколько проектов. А потом вы собьётесь со счёта.
А дальше будет так. Вы работаете над проектом №11, а начальник, совершенно неожиданно, напоминает вам о проекте №2. Нужно, чтобы вы продолжили работу над этим проектом. Проект №2 — это теперь самое важное ваше дело. А раньше, год назад, проект №2 отложили на неопределённый срок.
Вам никто не говорил о том, что проект №2 может снова стать важным, поэтому вы не позаботились о том, чтобы создать документацию для этого проекта. В результате, когда вы вернётесь к своему коду, вы, весьма вероятно, забудете о каких-то важных деталях его реализации. А самое неприятное тут то, что вы говорили начальнику о том, что проект №2 на 60% готов. Поэтому вам на его завершение дадут всего пару недель.
Собственно, мораль сей басни такова: нужно выделять время на документирование всех создаваемых вами проектов. Документация спасает жизни.
Это — очень важная мысль.
То, что вы в совершенстве изучили несколько языков или некий используемый вами стек технологий, не значит, что учиться вам уже нечему. Вокруг очень много такого, что вам нужно будет изучить. Технологии развиваются, а вам нужно от них не отставать. Не становитесь жертвой заблуждения, в соответствии с которым то, что вы знаете сегодня, будет актуальным и через десять лет. Этого не будет.
Продолжайте учиться, стремитесь к тому, чтобы узнать больше, чтобы стать лучше. Дело в том, что веб-разработка — это непрерывная учёба. Думаю, что тут кроется вся прелесть этого дела, когда стараешься не упускать шанса изучить что-то новое и интересное.
Возможности приходят и уходят. Они могут появляться на мгновение, и за мгновение же их можно упустить. Поэтому будьте готовы действовать. Будьте готовы к тому, чтобы, когда возможность постучится в вашу дверь, достойно её встретить.
А как вы думаете, какие идеи помогают программистам в профессиональном росте?
Невозможно изучить абсолютно всё
Существует огромное количество технологий. Невозможно изучить их все.
Найдите стек технологий, который лучше всего вам подходит. Выберите технологии, которые позволят вам создавать то, что вам нужно, и досконально изучите. Например, если вас интересует современная веб-разработка, хорошим выбором будет стек 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% готов. Поэтому вам на его завершение дадут всего пару недель.
Собственно, мораль сей басни такова: нужно выделять время на документирование всех создаваемых вами проектов. Документация спасает жизни.
Будьте готовы к тому, что вам придётся постоянно учиться
Это — очень важная мысль.
То, что вы в совершенстве изучили несколько языков или некий используемый вами стек технологий, не значит, что учиться вам уже нечему. Вокруг очень много такого, что вам нужно будет изучить. Технологии развиваются, а вам нужно от них не отставать. Не становитесь жертвой заблуждения, в соответствии с которым то, что вы знаете сегодня, будет актуальным и через десять лет. Этого не будет.
Продолжайте учиться, стремитесь к тому, чтобы узнать больше, чтобы стать лучше. Дело в том, что веб-разработка — это непрерывная учёба. Думаю, что тут кроется вся прелесть этого дела, когда стараешься не упускать шанса изучить что-то новое и интересное.
Возможности приходят и уходят. Они могут появляться на мгновение, и за мгновение же их можно упустить. Поэтому будьте готовы действовать. Будьте готовы к тому, чтобы, когда возможность постучится в вашу дверь, достойно её встретить.
А как вы думаете, какие идеи помогают программистам в профессиональном росте?
