Блог Хекслета

Это перевод статьи Ивана Зареа How I would explain a decade of web development to a time traveler from 2007.

Привет! Надеюсь, тебе нравится наш, новый для тебя мир. Он сильно отличается от мира 2007 года. Если ты только что взял ипотеку, вернись и закрой её. Поверь мне.

Я рад, что тебя всё ещё интересуют компьютеры! Сегодня у нас их гораздо больше, чем 10 лет назад, что принесло новые сложности. Мы носим компьютеры на руках и голове, держим их в карманах, они встроены в холодильники и чайники. Автомобили успешны в самоуправлении, а программы (чему мы их научили) играют лучше, чем люди, почти в каждую игру, за исключением наверно только алкогольных игр.

Привет, Хекслет.

Начну немного издалека.

С самого детства я болею биологией, болею сильно и не излечимо. Еще в детском саду я приносил с прогулки в карманах жаб и жуков, чем несказанно радовал воспитателей. В школе мне повезло попасть в энтомологический клуб на станции юннатов и школу я закончил имея публикацию в научном журнале и массу опыта полевых исследований. Высшее образование я естественно пошел получать биологическое. Потом была аспирантура. К защите диссертации суммарная длительность моих экспедиций достигла почти двух лет (за период с 2000 по 2013). Но к сожалению к концу аспирантуры, НИИ где я работал совсем обнищал, и моя зп скатилась до 6 тыс в месяц. Я подумал, что от такой науки можно “склеить ласты” и уволился.

Потом было 3 года в сети зоомагазинов, в которой я вырос с простого продавца до замдиректора, по всему, что связано с аквариумистикой - наем новых продавцов и их обучение, закупки товара и прочее. Попутно разводил дома рыбок и растения. В целом все было неплохо, за исключением того, что в магазине я официально был просто продавцом, а домашняя “ферма” сделала меня невыездным.

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

Одно из решений, которое вам нужно принять в строительстве карьеры разработчика - это выбор между:

1. Специалистом, экспертом в определённой области.
2. Многопрофильным работником, способным выполнять крупный спектр различных работ.

Микель Белтра считает, что правильный выбор — специализация:

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

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

Всем привет, меня зовут Илья. Я расскажу, как я нашел работу fullstack-разработчиком за примерно полгода по-настоящему интенсивного обучения.

Я закончил МИРЭА по радиотехнической специальности, два года проработал в отрасли инженером, впоследствии понял, что ловить там нечего и решил кардинально менять сферу своих профессиональных интересов. Взгляд упал на веб-программирование, так как перед глазами была саксесс-стори друга, который во времена руби-хайпа самостоятельно разобрался с языком и основным фреймворком (неожиданно RoR) и нашел работу в каком-то берлинском стартапе. Привлекло то, что можно без проблем самостоятельно освоить нужные технологии, и найти работу без жестких требований к образованию.

Изучать современный JavaScript — болезненно, если вы не знакомы с ним с самого его рождения. Экосистема разрастается и меняется с такой скоростью, что сложно разобраться с тем, какие проблемы пытаются решить разные инструменты. Я начал программировать в 1998 году, но к серьёзному изучению JavaScript приступил только в 2014. В то время я помню как анализировал Browserify и изумлённо смотрел на его слоган:

Browserify позволяет запрашивать (require) модули в браузере, объединяя все зависимости.

Можно сказать, я не понимал ни слова в этом предложении, и с трудом осознавал, насколько это может быть полезно мне, как разработчику.

Цель этой статьи — показать исторический контекст развития инструментов JavaScript до их уровня в 2017. Начнём с самых первых моментов и построим шаблон веб-сайта, как бы это сделали динозавры — без инструментов, чистый HTML и JavaScript. Затем мы будем пошагово вводить различные инструменты, чтобы на практике видеть, какие задачи они решают — поочерёдно. Благодаря историческому контексту у вас будет больше возможностей изучить и лучше адаптироваться к бесконечно меняющемуся JavaScript. Давайте начнём!

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source — в желании людей помогать друг другу.

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

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

Время от времени я натыкался сети на интересные посты от Hexlet и вебинары от Рахима и Кирилла, и решил снова пройтись по ранее пройденным курсам а затем оформить подписку. В процессе прохождения, становилось понятно, что тут я научусь именно тому, чего мне всё это время не хватало – именно программированию – сдвинуть мышление и начать думать в правильном направлении при решении задач и построении программы. Я вдруг понял, что до сих пор у меня вообще не было понимания такой вещи как абстракция...

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

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

Интернет, особенно в последнее время, полнится историями о том как бывший <профессия> стал программистом. Примеры очень разные, там и хирург, и системный администратор, и даже бездомный. Как ни странно, поисковик выдает даже примеры того, как кто-то программистом не стал. Вот еще одна история, на этот раз менеджера. В российском понимании этого слова.

Это перевод статьи Climbing the infinite ladder of abstraction от Алексис Кинг.

Я начала программировать ещё в начальной школе.

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

Это перевод статьи 7 Ways to Improve Your Code Reading Skills от A. N. M. Bazlur Rahman.

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

Чтение чужого кода — в описании должности инженера-разработчика. Однако, это не всегда самая приятная задача. Не каждому нравится читать чей-то код. Иногда это просто скучно, а иногда чужой код просто вызывает желание пойти напиться. Иногда у вас появляются неприятные ощущения от того, что вы не можете его понять или от того, что он просто недостаточно хорошо написан. Большинство разработчиков предпочитает писать код, а не читать, не осознавая того, что чтение — тоже важный навык.

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

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

Если сказать проще — навыки чтения кода совершенствуют навыки написания кода.