куда расти техническим специалистам / 1cloud.ru corporate blog / Habr
Мы в 1cloud постоянно анализируем опыт экспертов в сфере ИТ. Например, совсем недавно мы рассказывали о том, что сделает работу начинающего программиста эффективнее и даже обсудили тему отпускных бонусов.Сегодня мы решили затронуть тему карьеры. Один из общепринятых вариантов движения программиста по карьерной лестнице — стать тим-лидом, а затем менеджером.
Но далеко не все готовы управлять людьми. И если у руководителя группы есть более практические обязанности, то вот работа менеджера может быть очень слабо связана с программированием.
Что делать, если хочется вертикального роста, или если так думает ваш начальник? Постараемся разобраться в статье.
/ Flickr/ m1try / CC-BY
Специалисты говорят, что нежелание становиться менеджером может быть временным явлением: в 20 лет программист еще полон энтузиазма и получает удовольствие от работы, а вот после 40 может захотеть смены вида деятельности. Это, конечно, происходит не всегда, но зарекаться никогда не стоит.
По данным Glassdoor, стандартный путь для программистов выглядит примерно так: младший разработчик –> старший разработчик –> ведущий разработчик или архитектор –> менеджер по разработке, менеджер по продукту и менеджер проекта –> и, наконец, вице-президент, технический или генеральный директор.
Если вы знаете, что менеджмент точно не ваше, то, согласно этой схеме, потолок развития — быть архитектором. Конечно, никто не отменял горизонтальный рост, повышение квалификации в определенной сфере, да и регулярное повышение зарплаты на текущей должности, мы уже писали о том, сколько может получать программист. Но сейчас речь идет именно о росте вверх.
Быть или не быть
Многих программистов вполне устраивает горизонтальный рост, но тут и заключается сложность: HR-ы или руководители в силу определенных причин (непонимания специфики работ или невозможности поднять зарплату конкретному специалисту в текущей должности) верят, что продвижение вверх — благо. И не всегда спрашивают работника, хочет ли он такого роста. Для работника это определенная дилемма: отказаться от продвижения и испортить отношения или согласиться. Хорошо, если отношения с начальником позволяют поговорить начистоту и объяснить нежелание такого роста: больше бумажной работы, обязанностей и ответственности за работу других, необходимость нанимать и увольнять сотрудников и нехватка времени на то, чтобы оставаться хорошим техническим специалистом.
Но в любом случае не стоит просто говорить нет, необходимо объяснить, что текущая работа и так приносит удовольствие, или вы не видите себя на роли менеджера. И обязательное условие — предложить кого-то вместо себя. Если работник знает, что у него есть лидерские качества, то можно попросить о другом повышении — стать старшей версией своей должности.
Президент аналитической компании Uncommon Clarity Энн Лэтэм (Ann Latham) предлагает задать себе 10 вопросов, прежде чем отказаться от повышения или принять предложение. И еще информация к размышлению — руководители, которые не хотели повышения, увольняются в два раза чаще, чем те, кто изначально имел цель дорасти до руководящих должностей.
Менеджером быть
Раз предложение о повышении поступило, начальство могло заметить задатки управленца, которые проявлялись и на текущем месте работы. Например, ответственность, авторитет среди остальных членов команды или выстраивание правильных отношений с руководителями. Мы уже писали о том, что чем заметнее сотрудник, тем больше у него шансов получить продвижение по службе.
Рик Хатли (Rick Hutley), бывший вице-президент по инновационному развитию в Cisco Systems, говорит, что сотруднику, решившему стать менеджером необходимо убедиться, насколько толстокожим он может быть и как относится к риску и критике, направленной не только в его сторону. Ведь ему придется критиковать своих подчиненных и принимать неприятные решения, поэтому круг друзей может заметно сузиться.
Но может возникнуть и обратная ситуация. Дженифер Селби Лонг (Jennifer Selby Long), коуч по достижению карьерного роста в Кремниевой долине, отмечает, что там все знают, что разработчики хотят остаться разработчиками и предложений о повышении до менеджера в крупных ИТ-компаниях почти не бывает. Поэтому если человек ощущает такую потребность, то он должен сам просить об этом.
Эту возможность следует обсудить с менеджером или начальником и заручиться их поддержкой. Эксперты считают, что в случае повышения получать профильное образование совсем не обязательно, лучше сразу учиться опытным путем, например, брать пример с менеджера, стиль управления которого нравится самому новоявленному управленцу.
Ну и, конечно, следует всегда помнить, с каким менеджером вы хотели работать, когда сами были на месте своих подчиненных, и стремиться к этому идеалу. Как вариант, можно лишь направлять команду в нужном направлении, а не контролировать каждый шаг каждого сотрудника.
Мы рассказывали о том, должен ли генеральный директор технической компании обладать навыками программирования. Но вот с экономической точки зрения написание кода CEO не выгодно и не оправдано — время директора стоит гораздо дороже, а его обязанности включают более важные для развития компании вещи, поэтому такую задачу, как написание кода, даже основателю ИТ-стартапа со временем придется делегировать.
Необходимо учиться мыслить шире и воспринимать проекты с более глобальной и бизнес-ориентированной точки зрения. Нет единого рецепта, как стать успешным менеджером. Нужно показывать результаты работы, стремиться улучшить рабочие процессы, а главное — заслужить уважение коллег. Для этого можно стать наставником, например, для младших разработчиков: на первых этапах управленческой карьеры это поможет не забыть практические навыки.
Альтернативные варианты
Кто-то все же решает попробовать себя в роли менеджера. Ведь кажется, что всегда можно вернуться, если поймешь, что управление большой командой — не твое призвание.
Однако и тут есть сложность — возвращение к прежней работе не всегда возможно. Некоторые программисты уверены: вероятность того, что первоклассный технический специалист станет таким же первоклассным менеджером, очень мала. А посредственному менеджеру вряд ли светят большие карьерные перспективы в будущем. Через 2-3 года, когда зарплата менеджера среднего звена перестанет устраивать, практические навыки программирования могут быть утеряны, и в результате можно будет остаться у разбитого корыта.
Другой вариант — совмещать. Есть выхода нет, то можно выкраивать какое-то время на работу с кодом, которой в команде пока никто не занимается. Объяснить своим подчиненным, что вам необходимо проводить какое-то время за тихой и спокойной работой, где есть только вы и компьютер, вполне реально. Да и им работать с менеджером, довольным работой, будет намного приятнее.
Еще одна возможность избежать необходимости выполнять функции менеджера — уйти в свободное плавание. Фриланс и контрактная работа дают отличную возможность развивать свои навыки, профессионально расти и получать больше денег с каждого нового проекта без необходимости выпрашивать у начальника повышения зарплаты.
Но тут есть свои очевидные минусы: длительная наработка клиентской базы, отсутствие стабильности, частая смена проектов, коллег и клиентов, с которыми приходится заново выстраивать отношения, а также ненормированный доход и необходимость самому заботиться об отчислениях на пенсию или запасе денег на время больничного. Да и никаких бонусов, которые могут предложить компании, при такой работе тоже нет.
P.S. А в наших последних постах мы собрали дайджест и рассказали новости по теме облачных технологий:
Куда расти программисту? — Web-automation.ru
Сейчас мы поговорим о перспективах программиста. Т.е. по сути вы остаетесь программистом, не меняя сферы.
Менеджер проекта / лид программист
Первое, и самое простое – стать менеджером проектов. Это можно совмещать с функциями лид-программиста. Вы принимаете все ответственные решения в техническом плане на проекте, решаете самые сложные участки проекта. По сути, вы берете на себя весь проект, а вам помогает пара дополнительных программистов
Есть такое мнение, что сделав из хорошего программиста менеджера, вы получаете плохого менеджера, и плохого программиста. Тут зависит скорее от личных качеств. Далеко не каждому хорошему программисту под силу стать хорошим менеджером.
Автоматизатор тестирования
Сложно назвать это ростом, это скорее ответвление в сфере разработки. Вы создаете не конечный продукт, а создаете вспомогательные инструменты для автоматизации тестирования. Т.е. по сути вы тот же программист, просто задачи носят довольно узкий характер и не связаны напрямую с новыми функциями разрабатываемого продукта.
Репетиторство и обучение
Как я говорил ранее, потребность в программистах будет только расти. Появляется куча обучающих курсов и центров по разработке ПО. Появляются новые факультеты. Больше студентов необходимо обучать. И здесь возникают репетиторство. По-хорошему, это гораздо важнее и полезнее для будущего программиста, чем проходить репетиторство по физике или химии.
Также плюс этого варианта в том, что вы учите людей зарабатывать. Причем не в отдаленном будущем, а уже через 3 месяца такого репетиторства человек может начать зарабатывать какие-то деньги.
Мы свои курсы предлагаем бесплатно, т.к. это не является нашим основным приоритетом в сфере обучения. Мы скорее рассматриваем курсы как способ помочь начать карьеру способным трудолюбивым людям. Почему именно таким способом – тема отдельного разговора.
Свой бизнес по разработке ПО
Вы можете пойти дальше и создать свою команду разработки и начать делать софт для клиентов.
По сути вы можете начать как фрилансер, а потом уже собирать постепенно команду. Но тут хотелось бы вас предупредить – вы даже не представляете сколько всего дополнительного надо делать помимо операционной деятельности, т.е. непосредственно разработки.
- Маркетинг – как донести до потребителя свой продукт. Как сделать так, чтобы он поверил вам? Как упаковать свой продукт? Частично вам в этом помогут популярные курсы по маркетингу, но в большинстве случаев они советуют, на мой взгляд, очень сомнительные вещи.
- Продажи. У вас должен быть свой четкий процесс обработки потенциального клиента. Вы должны знать все его возражения и ответы на них.
- HR. Это тоже большая область, где есть что делать.
- И последнее – все остальное, финансы, юридические вопросы. документооборот, менеджмент, система обучения и т.д.
В общем как видите, сам процесс разработки хоть и занимает главное место, но сам по себе жить не может.
И еще момент – если вы планируете масштабирование такого бизнеса, то вероятно для личного программирования у вас будет совсем немного времени. Т.е. постепенно вы превратитесь из программиста в управленцы. Для некоторых это может быть серьезным стоп-фактором.
Развитие своего продукта – коробочное решение или SaaS сервис.
Мне этот вариант нравится больше всего. У вас есть какой-то продукт, который вы развиваете и продаете. Все ваши производственные ресурсы направлены на увеличение ценности продукта (заметьте, не увеличение функций, а ценности – это разные вещи!), а продаете вы просто готовый продукт за фиксированную цену.
Большой плюс – упрощение продажи и относительно спокойные процессы – нет никаких новых сложностей, нетиповых ситуаций, не надо каждый раз писать ТЗ, новые договора и т.д. Гигантский плюс – у вас есть готовое сформированное предложение клиенту, которое довольно просто понять и оценить.
Из минусов – коробку все равно приходится дорабатывать под клиента (не бывает идеально подходящих коробок). Также заказчик не так привязан к вам, как в случае разработки на заказ.
Saas – это какой-то сервис, который обычно берет деньги за платную подписку. Т.е. коробку вы ставите клиенту, а Saas сервис стоит на вашем сервере, а клиент просто использует этот сервис на платной основе.
В чем тут сложность? Если идея на массмаркет, то вероятно ее уже реализовал гигант. Если идея на очень узкий рынок – возможно вы не сможете достаточно зарабатывать на нем.
Но это все ерунда по сравнению с тем, что зачастую проект делается непонятно для кого и непонятно зачем. Мой здесь совет – сначала попробуйте продать будущий товар хоть одному человеку из целевой аудитории, а потом уже начинайте делать.
У нас, у программистов, очень часто чешутся руки что-то начать кодить. В случае продукта – это путь в никуда. Да, вы что-то сделаете, но в 99,999% случаев это будет никому не нужно. Неплохой вариант – делайте великий продукт для себя. Тогда минимум 1 человек на земле будет его использовать.
Более подробно про создание своего продукта читайте в книге Стивена Бланка StartUp.
Как может развиваться карьера программиста
Для программиста рост от junior до senior – естественное развитие в профессии, связанное с улучшением навыков. Однако очень сложно выбрать стратегию, как дорасти до высшей ступени: в IT нет универсальных критериев, что должен уметь разработчик на каждой позиции. А как развивать карьеру, когда уровень senior уже пройден?
В сфере IT карьера программиста развивается постепенно. Невозможно перескочить несколько ступеней карьерной лестницы сразу. При этом каждый движется в своем темпе: кто-то добивается повышения за год, кому-то на это понадобится больше времени. Но профессиональное развитие может выражаться не только в более высокой по статусу должности, но и в новых знаниях и навыках. В зависимости от этого карьерный рост называют вертикальным или горизонтальным.
Вертикальный рост
Когда мы говорим про карьерную лестницу, то имеем в виду вертикальный рост. Повышение в должности обычно сопровождается увеличением зарплаты, но при этом у специалиста появляются новые обязанности и расширяется зона ответственности.
Время перехода на каждую позицию, от junior к senior, зависит не только от самого разработчика, но и от компании, в которой он работает. Например, программист может 5 лет проработать в небольшой компании и стать senior-разработчиком. При переходе в другую организацию он будет претендовать на ту же позицию, но на собеседовании может оказаться, что для нового работодателя его знаний не хватает. Возможен и другой сюжет, когда программист надолго застревает в статусе middle: выполняет одни и те же задачи и самостоятельно не принимает важные решения на проекте. Это может произойти не только с теми, кто не стремится улучшать свои профессиональные навыки, но и с программистами, у которых мало возможностей для роста в пределах своей компании.
Рост из junior в middle
Каждый программист начинает карьеру с позиции junior. Это отправная точка вашего маршрута, с которой будет отсчитываться профессиональный опыт. Когда junior приходит в компанию, часто за ним закрепляют ментора. Он курирует новичка, может проверять его работу. Как правило, уже через 1-2 года junior повышает свой уровень до middle-разработчика.
В отличие от junior, middle-программист – самостоятельный специалист в команде разработки, который не нуждается в контроле более опытных коллег. Middle-разработчик понимает, какие фреймворки и библиотеки лучше подходят для каждой задачи. На проекте он уже может отвечать за отдельные модули и функции приложения. Достигнув уровня middle, программист сосредоточен не только на своем коде, но и начинает интересоваться архитектурой решений.
Чтобы junior-программисту быстрее вырасти до middle, стоит искать место работы, где налажен процесс обучения кадров и обмена опытом. Лучше выбрать компанию с меньшей зарплатой, но где для сотрудников предусмотрено рабочее время на тренинги, изучение новых технологий. На этом этапе карьеры важно не только активно учиться, но и закреплять знания на практике. Можно выучить множество технологий в теории, но это будет бесполезно, если не опробовать их на реальных задачах.
Рост из middle в senior
Senior-программист – основной специалист в команде разработки. Как правило, помимо своего стека технологий, он интересуется архитектурой программного обеспечения, проектирует отдельные части системы. Senior-разработчик уже не просто исполнитель, а скорее, соавтор технических идей. С опытом он накопил достаточно знаний, чтобы оценивать риски и предупреждать ошибки в разработке.
Обычно вакансии для senior-программистов предполагают от 3 до 7 лет опыта, но переход на этот уровень может занять и больше времени. Все зависит от того, насколько насыщенной и сложной была работа программиста за это время.
Чтобы middle-разработчику стать senior, важно научиться мыслить не в рамках своего кода, а на уровне всего технологического решения. Важно постоянно осваивать актуальные технологии и инструменты, вроде микросервисов и контейнеров, и стараться, чтобы ваши задачи на проекте усложнялись. Если понимаете, что занимаетесь лишь рутинной работой, попросите руководство разрешить вам сменить проект или несколько часов в день работать с другой командой. Чтобы проверить, какие задачи доверяют senior-программистам, можете зарегистрироваться на бирже фриланса (например, Upwork), заодно потренируете английский язык, без которого точно нельзя претендовать на эту позицию.
Senior-разработчики ценятся на рынке труда, и за их знания компании готовы платить не меньше, чем менеджерам. По данным портала dev.by за март 2019 года, у senior-программиста и менеджера проектов одинаковая средняя зарплата – 3 тысячи долларов. Таким образом, при переходе на другие позиции стимулом должно быть не столько повышение дохода, сколько реализация интереса, либо к проектированию программ, либо к управлению командой.
Вершиной технологического роста для программистов считается роль архитектора ПО (Software Architect). Он проектирует программные решения, во многом определяя задачи остальных разработчиков в команде. Архитектор продумывает сценарии взаимодействия компонентов системы и выбирает технологии для каждого модуля.
Обычно архитекторами становятся разработчики, проработавшие несколько лет на позиции senior, ведь на пути к этой должности нужно накопить богатый опыт и широкий технический кругозор. Чтобы понять, подходит ли вам это направление, можно выбрать подходящие онлайн-курсы.
Должность lead-разработчика (Team Lead) может стать переходным этапом из программирования в менеджмент, так как уже включает в себя управление командой. Team Lead организует процесс работы во время проекта, делегирует задачи другим разработчикам. Также он может проводить собеседования с новыми специалистами, отвечать за их адаптацию и обучение. На этой позиции нужно оценивать работу коллег, разбирать чужой код. Эта роль подойдет тем, кто готов к ответственности за команду. В некоторых компаниях Team Lead может выполнять и обязанности менеджера проекта, то есть активно взаимодействовать с заказчиком.
Роль менеджера проектов (Project Manager) станет новым профессиональным опытом для разработчика. Однако такой переход будет комфортным не для каждого программиста – вместо часов наедине с компьютером и кодом, большую часть рабочего времени придется проводить в коммуникации с коллегами и клиентами. Чтобы senior-программисту вырасти в успешного менеджера, нужно развивать компетенции по модели T (T-shaped skills), то есть дополнять свою специализацию навыками из других сфер (управление командой, делегирование задач, риск-менеджмент, знания различных индустрий). Потенциальных менеджеров проектов среди разработчиков обычно выделяет отношение к проекту как к личному делу. Им важно не только закончить свою часть работы, но и увидеть результат всей команды.
Если хотите не только управлять проектом, но и решать технические проблемы, то роль Delivery Manager подойдет вам больше, чем работа менеджера проектов. Это новая роль в IT, и пока такую вакансию можно встретить только в крупных компаниях, где в проекте задействованы десятки человек. Delivery Manager отвечает за все аспекты проекта, включая архитектуру приложения и другие технические вопросы.
Горизонтальный рост
Можно развиваться в профессии, формально занимая одну и ту же должность. Это и называется горизонтальным ростом, когда специалист расширяет компетенции и стремится к статусу эксперта в своей сфере. Такая возможность актуальна для senior-разработчиков, которых не привлекает менеджмент или архитектура ПО. Хотя горизонтальный рост не предполагает повышение, он может способствовать увеличению доходов.
Эксперт
Чтобы опытному программисту выделиться среди таких же профессионалов, нужно в чем-то разбираться лучше других, стать экспертом в определенной области. Обычно этот статус неразделим с солидным практическим опытом. Чтобы позиционировать себя как эксперта, нужно накапливать редкие знания, которыми обладает небольшое число специалистов. Проще это сделать, если вы занимаетесь перспективными направлениями, в которых идет активный поиск новых методов решения проблем, например, большие данные, кибербезопасность, машинное и глубокое обучение.
IT-евангелист
Оставаясь senior-разработчиком, можно попробовать себя в роли IT-евангелиста, если вам нравится обучать и мотивировать коллег. IT-евангелист – тоже эксперт в какой-либо сфере, но его основная задача – популяризировать технологии и делиться опытом с другими.
Путь в этом направлении можно начать со своей компании – организовывать митапы, хакатоны, представлять организацию на отраслевых конференциях. Все это повысит значимость вашего опыта и профессиональных результатов. В крупных зарубежных компаниях IT-евангелист – это отдельная должность, а для нашей страны, скорее, неформальное звание.
IT-консультант
В сервисной IT-компании, где клиентам предлагают не только разработку ПО, но и комплекс связанных с ней услуг, senior-разработчик может совмещать карьеру программиста и роль IT-консультанта. Это дополнительная возможность монетизировать свои знания технологий и разных отраслей. Но для работы консультантом нужно научиться выбирать оптимальное решение, исходя из интересов бизнеса, а не самое современное с точки зрения технологий.
Чаще всего программисты меняют место работы, когда не видят перспектив роста в своей компании. Например, менеджером проще стать в растущей компании, где расширяется штат и появляются новые позиции. Еще одним ориентиром может быть тип компании: сервисная или продуктовая. Стоит выбирать продуктовые компании, когда вы определились, в каких технологиях хотите развиваться. Здесь вы сможете сосредоточиться на одном направлении, но будет труднее практиковаться в чем-то новом. Сервисные компании лучше подойдут тем, кто хочет работать над разнообразными проектами, не ограничиваясь ни стеком технологий, ни одной сферой бизнеса.
«Начинающим разработчикам лучше выбирать крупные сервисные компании, где будет возможность поработать в разных проектах и командах, – считает Сергей Голубенко, Software Architect в ScienceSoft. – Программист всегда учится у более опытных коллег, и если в команде мало специалистов, то ограничен и трансфер знаний. А проработав 5-7 лет в IT-компании, где сотни сотрудников, программист получит профессиональный капитал, с которым будет проще реализоваться в любой компании, как сервисной, так и продуктовой, или развивать свой стартап».
Выбирая место работы, уточняйте, как в организации происходит повышение сотрудников и есть ли критерии, по которым оценивают зрелость специалиста для более высокой должности. Зная требования работодателя к уровню программистов, вам будет проще планировать свою карьеру. Также важно, чтобы ваши профессиональные цели соотносились с планами развития компании.
Помимо зарплаты, работа должна приносить дивиденды в виде повышения квалификации и профессионального мастерства. Выбирая компанию, обращайте внимание, какие возможности для роста там предлагают. Более перспективной будет компания, где карьера программиста не заканчивается на статусе senior, и можно попробовать себя и в других ролях.
Как вырасти из верстальщика в JS-программиста? — Хабр Q&A
Думаю для этого Вам стоит изучить модель работы браузера и протокола HTTP, понять какое место в этой модели занимает JavaScript (а также HTML и CSS) и, собственно, изучить стандарт языка и окружение, в котором JavaScript работает в браузере (DOM и т.п.).Модель работы HTTP и браузера можно представлять в виде процессов, которые преобразуют одни данные в другие и каждый из которых протекает в рамках других, более глобальных процессов (существующих в конечном итоге в рамках физических процессов, происходящих в окружающем нас мире).
В общем грубую модель работы HTTP и браузера можно описать нижеследующим образом.
Один компьютер (сервер) посылает другому компьютеру (клиенту), в ответ на его запрос, набор данных (HTTP заголовки ответа и тело HTTP ответа: HTML, CSS, JavaScript код). Все эти данные могут быть сгенерированы динамически (например, с помощью PHP), но на работу браузера это не влияет (т.к. он получает лишь сгенерированный, статический набор данных).
Далее клиент (браузер), получив набор данных от сервера, начинает последовательно просматривать эти данные (для того, чтобы вывести их пользователю на экран в графическом виде).
Сначала он просматривает заголовки HTTP ответа, а затем приступает к просмотру и выводу тела HTTP ответа (в заголовках ответа содержится, в частности, указание на то, какие данные находятся в теле запроса и, соответственно, как их выводить).
В случае, если тип данных будет «text/plain» (т.е. обычный текст), то браузер выведет его на экран как обычный текст (без всякого форматирования и анализа: не будет искать в нём HTML теги, не будет искать участки JavaScript кода и затем исполнять их и т.п.).
В случае же, если тип данных будет «text/html» (т.е. HTML страница), то браузер не просто выведет на экран тело ответа и исходном виде, а будет искать в нём специальные символы, которые сами выводиться не будут, а будут изменять формат вывода связанного с ними текста.
Например.
Если браузер встречает в просматриваемом тексте HTML тег, то на экран будет выведен содержащийся в теге текст, выделенный в соответствии с договорённостью (между разработчиками браузера и разработчиками HTML страниц) о форме вывода данного тега.
Если браузер встречает участок с CSS кодом (тег , например), то он переключается в режим разбора CSS кода и сохраняет результат разбора у себя в памяти, чтобы затем выделять текст во встречающихся тегах уже в соответствии с правилами, содержащимися в этом участке CSS кода.
Если браузер встречает участок JavaScript кода, то он переключается в режим разбора JavaScript кода и действует уже в соответствии с новыми правилами (правилами разбора JavaScript, а не HTML кода). Например, если в JavaScript коде встречается инструкция, для вывода текста прямо сейчас («document.write»), то на экран пользователя выведется результат выполнения этой инструкции. А, если встречается инструкция для объявления функции, то браузер прямо сейчас ничего на экран выводить не будет, а сохранит эту функцию для дальнейшего использования (например, эта функция может быть вызвана, когда произойдёт какое-либо событие).
Т.е. браузер является бесконечно работающим процессом, который выводит что-то на экран пользователя (т.к. именно отобразить страницу пользователю является его целью) как при первой загрузке страницы так и при возникновении каких-либо событий уже после загрузки страницы (клик мыши, исполнение JavaScript кода, который содержался в функции, которая вызывалась при первой загрузке и продолжала бесконечно вызывать сама себя через определённый промежуток времени и т.п.).
Как развиваться программисту быстрее — Mad Devs
Общайся! Но общайся качественно.
Даниель Манасов на прошлом митапе фронтендеров, рассказывал о том, как сделать себе имя. Был в его докладе простой путь:
- Ебашить
- Помогать и просвещать (выступать на митапах, стримить как ты кодишь на twitch/livecoding, открыть ютюп канал)
- Писать книги и писать в опенсорс
Считаю, что весь доклад просто о том, что нужно общаться. В программировании есть куча всего, что не связано с кодом. Как ни странно, программист в течение рабочего дня пишет код около 3–4 часов в день. Остальное время у него уходит на обсуждение задач, планирование, поиск решения, подумать, покурить и т.д.
В итоге решил написать пост, который поможет начинающим расти быстрее.
Все боятся задавать вопросы. Все боятся показаться глупыми. “Ой, а что он подумает? Вдруг он скажет, как можно этого не знать?” — все джуны и не джуны задают себе этот вопрос, когда думают обратиться к профессионалу. Но, вы не поверите, все опытные люди любят помогать по двум причинам:
- Ностальгия — воспоминания о собственных ошибках и пути, который человек уже прошел всегда приятен. Помогать в этом случае доставляет удовольствие, потому что человек чувствует пользу, которую он принесет.
- Я стану лучше это понимать. Ведь истинное понимание предмета приходит только тогда, когда ты объясняешь его другому человеку, который может и не понять. Тут приходится делать аналогии, искать пути дать объяснение как можно проще и, как итог, — вы делаете лучше того человека, который вам помогает.
Процесс задавания вопросов может быть сложен, но в интернете куча информации о том, как задавать вопросы, чтобы на них отвечали. Например у stack overflow есть рекомендации как это делать.
Если вы все еще очкуете задавать вопросы человеку — попробуйте договориться о расписании. Например, задавайте вопросы в определенное окно с 10 до 11, как вариант. Это сотрет границы и сделает этот процесс более предсказуемым и позитивным. Моя практика со стажерами показывает хорошие и качественные результаты этого подхода. Люди перестают бояться задавать вопросы, а опытные люди будут меньше беситься, если вопрос был задан не вовремя.
Знаниями нужно делиться. Хотя бы по причинам, которые я написал выше. Помимо этого, всем будет интересен ваш опыт. Ваша реальная история.
Почему люди ездят на конференции, если все уже и так написано? По двум причинам: послушать истории и познакомиться с интересными людьми.
На конференциях и митапах завязываются интересные разговоры, которые могут быть интереснее самого доклада. Ведь не публично можно позволить рассказать себе больше и без цензуры.
Всем интересен ваш опыт. Ваши грабли, ваши шишки. А интересны они по тем же двум пунктам: ностальгия и лучшее понимание. Ну и бонусом может быть предостережение о возможных граблях на пути.
Пиши код, пиши больше кода. Пиши код везде, когда едешь в маршрутке или троллейбусе, когда кушаешь, всегда пиши код. Начни решать задачи на хакерранке или присоединись к какому-нибудь опенсорс проекту. Все заканчивается одним. Пиши код.
Молодому мозгу читать вредно. Не нужно читать много книг, когда ты еще ничего не попробовал. Пиши код, а книги нужны, чтобы проверить знания, которые ты получил в процессе написания кода и общения. Книги нужны будут уже тогда, когда ты — хороший джун. А на раннем этапе нужно набивать как можно больше шишек.
Думаю это очевидно. Чем быстрее ты набираешь текст, тем меньше мозговых ресурсов используется. Если умеешь набирать текст очень быстро, то поток мысли не спотыкается о клавиатуру. Не нужно смотреть на нее и искать нужную клавишу. Поэтому слепая печать — мастхэв скилл для любого программиста. А еще круче — это десятипальцевый метод набора.
Всегда проверяй реальность. Есть два ментальных искажения, которые могут тормозить развитие. Например, стажер ходит весь крутой из себя и считает, что он уже готов войти в штат, он все знает и готов взяться за реальный проект. Но часто это бывает не так.
Эту ситуацию хорошо описали два чувака. Дэвид Даннинг и Джастин Крюгер. Подробнее можно почитать вот тут. Я часто кратко излагаю этот эффект так. Чтобы человеку понять, что он долбоеб — ему еще нужно сэволюционировать. У человека в этот период еще очень мало опыта, чтобы понять свои границы незнания и ему еще нужно набраться опыта, чтобы понять, сколько еще он не знает.
Обратное искажение — синдром самозванца. Даниель Вартанов, Олег Пузанов и Миша Иващенко рассказали об этом очень подробно в своем видео . Также об этом можно почитать в вики.
Чтобы держать баланс — нужно общаться и как можно больше. Ходить на митапы, ездить на конференции и общаться с людьми за пределами нашей страны. Чем больше вы общаетесь, тем больше фидбека от реальности вы получите.
Нет ничего страшного в общении. Чаще всего хорошие и опытные люди открыты. А если человек закрыт и не любит вопросов — значит он не профессионал и мудак. У таких нечему научиться.
Пишите код, задавайте вопросы, делитесь знаниями и тогда ваш рост пойдет быстрее. И это еще не полный список того, что вам может помочь
Кривые развития программиста и немного об эффекте Даннинга — Крюгера
Существует два основных пути становления топ-менеджмента в IT-компаниях:
- Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
- Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.
Первый путь является более естественным, поскольку, подразумевает развитие основных качеств менеджера по мере его роста. По сути менеджер остается менеджером, только становится специалистом более высокого звена.
Второй путь является более долгим и не гарантирует успеха, так как является противоречащим сути интроверта-программиста. Однако, на этом пути я бы хотел заострить внимание и поделиться опытом и знаниями.
Внимание, спойлер.
- Все имена — вымышленные
- Повествование относится в большей степени к заказной разработке
- Скилы, а в особенности софт скилы, сложно оценить формально, все графики в этой статье являются условными и отражают мое личное мнение
Начало пути программиста
Итак, мы в самом начале пути программиста.
Знакомьтесь: Николай (имя изменено). Николай — молодой программист, он хорошо учится в универе и уже пробовал писать простенькие сайты. Он устроился в студию на должность джуна-фронтендера, его посадили на проект, который уже пишется два года с использованием современного фреймворка Angular версии 1.5. Мальчик Коля не работал с ним, но он увидел знакомый знак доллара, а он уже успел написать пару плагинов для jQuery. Этот факт ободрил Николая, но потом старшие товарищи рассказали ему, что это — совсем не jQuery, и, вообще, тут надо директиву написать, а вот тут два фильтра надо сделать. Николай подавлен, но твердо намерен влиться в этот проект.
И вот уже пролетел год, Николай мастерски пишет директивы и не проходит и дня без нового модуля. Коля на коне, оптимизма ему прибавляет тот факт, что полгода назад к нему на проект подсадили молодого джуна, а тот даже не знает, что такое директива. Щенок! Николай подружился со старшими товарищами, и только 30-летний старик в углу вечно чем-то недоволен.
Собственно, на графиках мы видим технические навыки для проекта и все скилы Николая, что у него есть. Поскольку это его первый проект, то по факту это все, что знает Николай. Через некоторое время он идет к начальству и просит два мешка денег — ведь он мастерски создаёт директивы на проекте, и вообще, он посчитал, что в два раза больше оставляет комментариев в MR, чем тот 30-летний старик. Очевидно, что он — лучше своего тимлида. На это получает вполне резонный отказ и начинает искать новую работу, возможно задумывается о переходе на другой проект или в другую команду. В любом случае он сталкивается с ситуацией, когда только что полученные знания становятся уже неактуальными и ему надо учиться дальше.
Это — первый кризис Николая «Эффект первого проекта».
На новом месте Николаю дают проект на Ангуляре 5, ну он же мастерски пишет директивы! Но там он видит какую-то дичь! Какой ещё TypeScript? Какой RxJs и потоки? Старшие товарищи смеются над ним, а 30-летний старик кидает недобрые взгляды. Я видел огромное количество таких звёздочек и очень много звездопада, когда разработчик понимал, что оказывается-то он ничего ещё не знает! И чем раньше это произойдет, тем лучше. Это называется Эффектом Даннинга — Крюгера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации.
Джун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:
- Объективно оценивает свои знания и навыки
- Постоянно развивается
- Больше общается в коллективе
- Больше понимает цену ошибки, потому что он видел больше дедлайнов и релизов
Коллегам, которые оказались на этом этапе, хочется пожелать следующего:
- Не унывать при неудачах
- Постоянно учиться и осваивать новые библиотеки и технологии
- Не звездиться
Junior → Middle → Senior
Ну вот прошло еще пару лет и что же мы видим?
Николай уже освоил несколько фреймворков и понял, что фреймворки — это только инструмент для решения конкретных задач. Он смирился с тем, что знает не все, но при этом старается все время развиваться. В какой-то момент он подходит к молодому 33—летнему тимлиду и говорит: слушай, Петя (имя изменено), вон к нам пришло несколько джунов, они ничего не знают и медленно делают задачи на проекте. Давай я им проведу несколько лекций или мастер-классов для того, чтобы они быстрее влились в нашу работу. И именно в этот момент Николай переходит на следующий уровень.
Сейчас существует разделение на Junior, Middle, Senior. Мидл думает, что для того чтобы стать Синьором, ему надо освоить новый язык программирования и подтянуть матчасть. Это не совсем так. На заре отечественной разработки была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив. Без соответствующих софт скиллз Синьором не стать.
Николай научился находить подходы ко всем членам команды, он постоянно развивается и развивает остальных. Он повидал уже «звездунов первого проекта», но ему гораздо комфортнее работать с такими же профессионалами, как и он сам. Ведь они понимают, что успех проекта — это успех каждого, а прокол одного члена команды в конечном счете сказывается на всех его участниках.
На этом этапе возможно два пути: быть простым исполнителем, не напрягаться и решать поставленные задачи; второй — развиваться в направлении ведущего программиста, брать на себя ответственность и инициативу.
На этом этапе развития программиста команда и руководство ценят такие его качества:
- Ответственность
- Надежность
- Коммуникабельность
- Проактивность
Куда стоит развиваться?
- Углубленное понимание технологий, которые он использует
- Расширение кругозора
- Брать на себя ответственность за проекты и людей
Причем, скилы из последнего пункта надо обязательно прокачивать, если он хочет развиваться по кривой до руководителя. Если же ему это не интересно, то можно сконцентрироваться именно на умениях технического специалиста.
Кризис технологии
В какой-то момент Николай с ужасом осознает, что уже никто не пишет на JS, а большинство его знаний никому не нужны. Вот так наступает кризис технологии. Я застал такой кризис с десктоп-приложениями. Чуть позже просто верстальщики стали никому не нужны — везде стали требоваться фронтендеры. Потом PHP стал резко не моден, и на рынке стали нужны JS-разработчики.
Тут есть три выхода:
- Переучиваться под новый стек
- Становиться лучше в старом и хвататься за последние заказы. Тот же Delphi все ещё востребован в узких кругах с огромным количеством legacy кода
- Уходить в менеджмент при наличии соответствующих навыков
Сильные специалисты нужны будут всегда, но, при снижении спроса на определенную технологию, увеличивается конкуренция между соискателями. Заказная разработка страдает в этой степени больше, нежели продуктовая. Освоившись в крупной продуктовой компании, разработчик может не бояться возраста или устаревания его стека технологий — он будет востребован, пока живет продукт. По моей статистике, средний возраст разработчиков в продуктовых компаниях выше, нежели в студиях.
TeamLead. Кризис возраста
Ну вот, Николай сменил стек технологий, и вроде бы все хорошо, но мы видим, что новые навыки даются все медленнее, а подрастающее поколение схватывает все быстрее.
Вот тут наступает последний кризис — кризис возраста.
Николай стал одним из тех тимлидов, на которых он смотрел несколько лет назад, как на стариков, вечно ворчащих и недовольных, но вот он стал писать меньше.
Можно подумать, что если ты пишешь меньше кода, то ты медленней развиваешься, а ребята, которые его пишут больше — соответственно и развиваются быстрее, и они скоро тебя догонят. Я встречал и такую фобию у молодых специалистов.
Какие тут могут быть варианты:
- Если ты работаешь в продуктовой компании, то, наверное, это для тебя не так критично, и можно оставить все как есть
- Уйти в обучение, например, стать консультантом, архитектором и т.д.
- Таки уйти в менеджмент
Перейдем к кривым
Удовлетворенность. Она не может быть всегда на высоте, качественные проекты попадаются не всегда, а идеальную команду сложно подобрать и воспитать.
Я уверен, что, несмотря на падение удовлетворенности, надо всегда оставаться человеком. Я говорю о том, что если горят сроки на проекте и все бегают в мыле, то лишняя нервозность делу не поможет. Команде будет намного комфортней работать с людьми, которые не подведут в критические моменты.
Технические скилы относительно быстро приобретаются и ещё быстрее забываются и устаревают, если посмотреть со стороны.
Получается, что программист имеет свой пик развития, а потом начинает «стареть», и в какой-то момент ему пора уходить на пенсию?
И да и нет. На самом деле, вместо одного графика можно нарисовать 3 (опять же IMHO, как и значения).
- tech skills — это знания именно в технологии, языке программирования, фреймворке. Вы помните, что я ранее писал о том, что тимлид начинает меньше писать код и больше управлять? Эти скилы имеют свой пик именно в момент наибольшей востребованности специалиста в роли кодера.
- hard skills — это совокупность знаний и опыта разработчика, со временем рост их снижается по той причине, что старые знания уже устаревают и становятся не востребованы, но остается полезен из них именно сухой остаток.
- soft skills — это именно те личностные качества, которые нельзя посчитать, но которые надо развивать. Это качества, которые важны всегда, но в разной степени даны всем от рождения.
Но давайте добавим еще один график
value = (0,5*tech + 1*hard + 1,5*soft)/3
В третий раз повторюсь, что это лично моя формула, а коэффициенты я вывел за более чем 10 лет профессиональной деятельности в области разработки.
Зеленый график отражает совокупность всех качеств специалиста, и это является его итоговой ценностью.
Почему технические скиллы ценятся в три раза меньше, чем софт скилз? Вспомните фразу «как специалист он хороший, а как человек — не очень» и тех, к кому она применялась. Руководитель более охотно выберет соискателя, на которого всегда можно положиться, чем соискателя, который пригоден только для одного единственного проекта, и то над ним нужен глаз да глаз. Даже джуну легче работать и быстрее развиваться в команде, где ему помогут и направят, а не будут стремиться подставить при первом удобном случае.
Поэтому же HR-ы в компаниях проводят отсев кандидатов в том числе по софт скилам еще до проведения технического собеседования. Токсичный сотрудник может принести больше вреда компании, нежели технически слабый. Да и если технически слабый сотрудник принес вред, то это скорее вина его руководителя. Есть золотое правило: давай задачи по силам, а если хочешь, чтобы человек подрос, то немного сложнее (именно немного, а не в виде неподъемной ноши).
2 варианта развития программиста
Я описывал вариант, когда разработчик двигается по следующему пути:
Junior → Middle → Senior → TeamLead? → Project manager? → Head Of * → Chief * Officer
Но что делать если это не получается или не надо?
Та же самая формула работает и в случае, если вы хотите развивать свои софт скиллз и становиться менеджером: можно развивать технические скиллы и быть востребованным специалистом без необходимости двигаться в сторону менеджмента. Но тут надо понимать, что технические скилы имеют свойство устаревания: сегодня ты отличный программист на Фортране, а завтра ты уже никому не нужен.
TechLead vs TeamLead
В связи с укором со стороны читателей за то, что эта тема была не раскрыта в статье (соглашусь, что стоило бы добавить материал), то я дополню отличиями двух видов лидов.
TeamLead (вариант 1 из предыдущей главы) — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин:
- Он ближе к разработчикам и может их адекватно оценивать
- Разработчики к нему относятся лучше, чем к проектному менеджеру
- Можно убрать из проекта или снизить участие проектного менеджера (а он не приносит прямого дохода)
- Он может общаться с клиентом с точки зрения бизнеса, а не технологий.
- Совмещает в себе роли TechLead и PM
TechLead (вариант 2 из предыдущей главы) — технический специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли.
Почему конкретный человек — именно TechLead, а не TeamLead:
- Он может быть технически очень сильным, и отвлекать его не стоит, например, может участвовать в большем количестве проектов
- Он — интроверт или мизантроп, ему очень сложно общаться с людьми, а им — с ним
- Он очень сильно любит программировать, и управленческие задачи ему не интересны
- PM не хочет делиться с ним обязанностями
- В компании нет необходимости в TeamLead, и больше требуются технические специалисты
Грамотный руководитель, при наличии необходимости как в тимлидах, так и техлидах, выберет правильную должность конкретному сотруднику (ну или постарается), тем самым сделав взаимовыгодное сотрудничество более качественным для обеих сторон.
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца, и об этом будет сказано дальше, однако при отсутствии очень сложных проектов, он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за его универсальности.
Заключение
Софт скилы очень важны для специалиста, они позволяют ему быть востребованным в те моменты, когда его технологический уровень не очень высок, например, при переходе между проектами, компаниями или технологиями. При прочих равных, руководитель отдаст предпочтение специалисту с более развитыми софт скилами.
Переход от разработчика в менеджеры (под менеджером я подразумеваю скорее не продуктового менеджера, а руководителя, тот же тимлид сочетает в себе менеджерские и технические роли) стоит делать, если софт скилы превосходят технические, и если инициатива исходит от самого разработчика.
Плохие варианты, которые не дадут хороших результатов:
- Я хочу стать ПМом, потому что люблю власть, да и они ничего не делают
- Я хочу стать ПМом, потому что я не востребован в качестве разработчика, а есть вакансия ПМа
- Я не хочу быть ПМом, но руководство заставляет
- Я мастерски пишу директивы и готов уже руководить командой разработчиков
Если вам не нравится или не получается менеджерить, но вас заставляет руководитель, то лучше сразу ему об этом сказать, а не пересиливать себя, а потом в какой-то момент сорваться и «улететь кодить на Бали». Помните: если вам нравится писать код, а не руководить, то и пишите его.
Если же вы не можете/не хотите уйти в менеджеры, но при этом просто программировать вам уже не интересно, то можно рассмотреть вариант перехода в коучи: продавать свои услуги архитектора, вести свои курсы и т.д.
Если же вам хочется и нравится руководить командой разработчиков, то стоит двигаться в этом направлении и стремиться искоренять из себя разработчика — это самое сложное. Надо стараться делегировать задачи, а не делать их самому. Кстати, рекомендую отличную книгу Как пасти котов, в которой собраны советы программистам, которые хотят стать руководителями.
Как вырастить айтишника / Mail.ru Group corporate blog / Habr
Как недавно признался Цукерберг, «я никогда не стал бы программистом, если бы не играл ребёнком в компьютерные игры». Не станем утверждать, что путь к успеху в IT лежит через геймерство. Но всё же без тесного знакомства с самыми разными программами и гаджетами программисту не обойтись. И в наши дни знакомство это начинается с достаточно раннего детства. Информационные технологии уже давно проникли в нашу жизнь. Современные программисты, в детстве игравшие на приставках и компьютерах, зачастую сталкивались с непониманием родителей, в чьей молодости не было подобных вещей. Зато теперь эти самые программеры сами обзавелись детьми и гораздо лучше понимают их увлечения. Зачастую даже становятся этакими наставниками по хайтек-развлечениями, обучая детей премудростям комбо-ударов, постройки юнитов и частой отправки врагов на респаун. Как волки обучают волчат азам охоты. И нам стало любопытно, во что же программисты сегодня могут поиграть со своими детьми? И не просто поиграть, а с пользой для молодого ума.
Это любопытный продукт, разработанный не где-нибудь, а в MIT Media Lab. Scratch представляет собой визуальный язык программирования для детей от 6 лет. Отличный способ развлечь ребёнка и одновременно научить его мыслить «как программер». Сейчас на сайте зарегистрировано уже более 6,7 млн человек, загрузивших 9,6 млн проектов, от анимаций до простеньких игр. Здесь вообще большую роль играет социальная составляющая. Все проекты выкладываются под лицензией Creative Commons, подразумевающей возможность использования чужого «кода». Короче, визуальный Github для самых маленьких. Язык доступен в версиях под Windows, Linux и Mac.
Интересный проект, разработанный в Институте Карнеги Меллона, предназначенный для школьников и студентов. Выстраивая в трёхмерном пространстве цепочки взаимодействия между разными предметами, молодые люди учатся объектному событийно-управляемому программированию. В демо-ролике можно посмотреть интерфейс Alice, примеры взаимодействий и получающегося программного кода. Подход сам по себе достаточно развлекательный, но можно внести дополнительный элемент игры: с помощью встроенного языка программирования воссоздавать какие-то сценки из жизни, с фотографий и картин.
Ozobot — это маленький робот, смахивающий на футуристический шлем космонавта, который движется по нарисованным траекториям. При этом его можно запрограммировать на разное поведение в зависимости от цвета линии, по которой он движется. Отличный способ поиграть «в роботов» и преподать ребёнку концепцию программирования. Можно играть с Ozobot на экране планшета, для этого есть специальные приложения под Android и iOS.
Детский робо-хайтек. MindStorms — это продвинутый конструктор, с помощью которого можно создавать весьма сложных программируемых, дистанционно-управляемых роботов. Ещё не факт, кому это больше понравится — отцу или сыну. Клиентские приложения доступны в версиях для Windows и Mac. В комплекте идёт управляющий модуль, являющийся «сердцем» робота, три вида датчиков, два вида моторов и россыпь конструкционных деталей.
Это коллекция из 27 обучающих мобильных приложений, выполненных в оригинальной стилистике. Не стоит ожидать от них глубокого проникновения в материал. Эти игры не столько обучают чему-то, сколько знакомят малышей с разными профессиями. Ну, не одному же программированию учиться ребёнку программиста. Среди прочих игр, есть там и аркада, посвящённая роботам.
Если ваш отпрыск без ума от MMORPG, то направить его на путь истинный можно с помощью Code Combat (13+). Эта игра мимикрирует под ролевуху, но все действия выполняются только после ввода команд на одном из выбранных для обучения языков программирования. Отличный способ оставить в голове сорванца побольше полезной информации, обернув её в привычную игровую форму.
Кстати, там даже есть кланы со своими лидерами.
Это настольная игра для всей семьи. Несмотря на то, что упор тут делается именно на развлечение, ребёнок всё же знакомится с такой штукой, как булева логика. А без неё в программировании никуда. Через эту игру можно привить дитяте мысль, что учиться программированию можно весело и интересно.
Милая браузерная игрушка (Lightbot Jr. для 4-8 лет и Lightbot — 9+), доступная и в мобильных вариантах, которая позволяет дать ребёнку азы алгоритмирования. Цель игры — довести робота до синей платформы и «подсветить» её. Для этого нужно составить и выполнить программу движения, со всем поворотами, прыжками и прочими действиями. На более поздних уровнях игра становится вовсе не так примитивна, здесь вводится понятия процедур и циклов.
В этой игре есть и экшен, и головоломки. Изюминка в том, что здесь нужно «хакать» объекты и персонажей, «перепрограммируя» их свойства, поведение, меняя правила самой игры.
P.S. Не обращайте внимание на специфичность трейлера.
В игре объединена аркада с псевдопрограммированием «на лету». Ваша задача — провести через препятствия странных роботообразных существ. Они могут прыгать и отскакивать от объектов, во время полёта вы можете остановить время и ввести команду, создающую какой-нибудь объект, чтобы помочь своему питомцу попасть в нужное место.
Отличная игра для iPad, в которой нужно задать программу движений грузового захвата, чтобы составить ящики в нужном порядке. Помогает развивать у ребёнка навыки планирования и алгоритмирования, как раз то, что нужно каждому программисту. К сожалению, версии для Android нет, но наверняка там есть другие, не менее достойные игры подобного рода. Если знаете — поделитесь информацией.
В общем, игр и развлечений для детей, которые познакомят их с информационными технологиями, можно найти немало. Причём для всех возрастов. Старшим можно уже в качестве «игрушек» предложить Raspberry Pi, Arduino, BeagleBone и прочие подобные микрокомпьютеры. А во что вы играете со своими детьми?