Русский
Русский
English
Статистика
Реклама

Карьера в it-индустрии

За что IT-компании платят экономистам и сколько стоит человеческая жизнь

21.02.2021 20:17:01 | Автор: admin

ЗАВТРА, в 20:00 в наших соцсетях выступит Евгений Канашевский, экономист из Zalando, Economics Phd университета Штата Пенсильвания.

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

Многие из нас наверняка помнят кривые спроса и предложения из вводных курсов экономики. Но вряд ли в этих курсах нам рассказывали о том, что современная экономическая наука находит ответы на сложные вопросы. Почему одни страны богатые, а другие бедные? Как легализация абортов влияет на уровень преступности? Сколько стоит человеческая жизнь?

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

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




Тезисы выступления


  • Как современная экономическая наука отличается от массового представления о ней
  • Почему экономисты отвечают на самые разные вопросы о поведении людей
  • 4 типа задач, над которыми работают экономисты в онлайн-бизнесе.
  • Путешествия по параллельным вселенным или чем экономисты отличаются от нормальных data scientists
  • Почему большие компании нанимают и скорее всего продолжат нанимать все больше экономистов
  • Что делать, если я хочу узнать больше о задачах экономистов в IT-компаниях


До встречи в эфире!



Подробнее..

Pet-проект для джуна. Или зачем и как выбрать pet project. (личный опыт)

23.02.2021 14:15:47 | Автор: admin

Предисловие

Привет Хабр! Эта публикация написана джуном для джунов (но возможно и специалисты более высокого уровня что-то найдут для себя / своих падаванов).

Зачем нужны pet проекты?

Для саморазвития как разработчика и закрепления изученного материала.

Если Вы днями на пролёт "штурмуете" теорию: читаете посты, смотрите туториалы, но при этом не применяете изученное на практике, то времени на освоение выбранной Вами темы понадобится в разы больше.

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

Для джуна без постоянного места работы, pet проект заменяет тут самую работу (со стороны разработки). Вы ставите себе задачу/цель и делаете всё возможное что бы её выполнить. При разработке Вы ещё глубже погружаетесь в тему, а иногда находите новые объекты для изучения.

Суммируя pet проекты нам нужны для:

  • изучения / закрепления нового материала;

  • получения удовольствия от разработки чего-то интересного лично Вам;

  • пополнения своего портфолио;

  • (bonus) есть шанс что Ваш pet проект может кому-то приглянуться и тогда из этого можно получить финансовую выгоду.

Как выбрать и на что обратить внимание?

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

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

Технологии

Раз Вы выбрали определенные технологии для своего домашнего проекта, то скорее всего они Вас интересуют и проблема приведенная выше Вас не касается. (Или же Вас заставляют писать на том что Вам отвратно?)

Дизайн

Тут все зависит от человека и ситуации. Есть два варианта:

  1. Запариться и сделать крутейший дизайн.

    Плюсы:

    • lvl up как дизайнера;

    • обычно свой дизайн очень приятен;

    • так как это собственный макет Вы в нём хорошо ориентируетесь и ещё на этапе дизайна продумываете некоторые фичи.

    Минусы:

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

  2. Найти готовый дизайн и работать с ним.

    Плюсы:

    • быстро (хотя поиск может затянуться, об этом ниже);

    • не нужно отвлекаться на дизайн.

    Минусы:

    • не всегда можно найти дизайн для Вашей задумки, особенно если она не типичная;

    • готовые бесплатные макеты не всегда красивые.

Идея

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

Вот пару вечно актуальных примеров:

  • список задач;

  • список задач;

  • менеджер покупок;

  • сайт портфолио;

  • кино сайт;

  • калькулятор;

  • блог;

  • магазин чего-либо.

Личный опыт

В этом блоке я раcскажу как придумывались / создавались мои pet проекты.

Начало (AniList)

Шёл июль 2020 года. Спустя семестр изучения JavaScript'а в колледже я решил изучить какой-то фреймворк. Выбор пал на React. Через пару дней ознакомления с фреймворком я наткнулся на серию видеороликов по разработке веб-приложения пиццерии на ютуб канале Archakov Blog. И решил сразу же применять изученное в видео на реальном проекте, но просто переписывать код из видео в IDE было не интересно. По этому я решил делать аниме список.

Выше я писал про два варианта получения дизайна для проекта. Какой же из вариантов выбрал я при создании макета? Оба. Для начала я зашёл на уже существующие сайты с такой-же тематикой потом пролистал Behance и собрал своего "франкенштейна" из собственных идей и кусков уже готовых дизайнов.

Скриншот проекта из FigmaСкриншот проекта из Figma

По готовому макету я понял что мне нужно будет где-то брать информацию об аниме (API, AJAX), где-то хранить её (Redux), а также как-то организовать авторизацию и хранение информации о пользователях (Firebase) + работа с версиями файлов(GIT, GitHub). В итоге мне предстояло ознакомиться как минимум с 5 новыми технологиями помимо React.

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

ToDo list

Дизайн ToDo appДизайн ToDo app

Следующим проектом должен был стать todo list. Мой одногруппник (тоже начинающий фронтендер) должен был делать frontend на Angular, а я (неожиданно) backend. Тут мне пристояло погрузиться в мир backend'а и может не изучить, но хорошо так ознакомиться с NodeJS, Express, MongoDB, mongoose, cors, dotenv, способами авторизации, деплоем на Heroku и ещё глубже понять работу API.

По итогу вышло так что и я и мой товарищ каждый для себя писали back и front end.

Остальное

Потом было ещё пару проектов. Вкратце напишу что для себя я вынес из них.

Приложение погоды:

  • рисование на canvas'е;

  • работа с геолокацией;

  • анимация React компонентов.

Shedaily (front & back end) - приложение которое парсило расписание из сайта колледжа где я учусь и приводило его в приятный вид:

  • парсинг информации из сайта;

  • работа с Excel таблицами в NodeJS.

Terminal website - вдохновившись сайтом dodo.dev создал сайт с контактами:

  • SCSS;

  • Gulp.

Менеджер подписок:

  • MobX;

  • переключение темы.

Магазин аксесcуаров (backend) (в разработке):

  • более глубоко познал MongoDB + mongoose;

  • GraphQL.

Портфолио (на стадии дизайна):

  • JAM stack;

  • Gatsby;

  • создание кастомного курсора.

Заключение

Недавно меня постигла идея переписать свой первый pet project (Аниме список), но теперь с новыми навыками: backend на NodeJS, Express, GraphQl вместо Firebase, и frontend React + Apollo Client, ну и дизайн по красивше сделать. Эта мысль является результатом моего прогресcа который я постиг благодаря pet проектам.

Всякое дело совершенствуется овладением техники. Всякий навык достигается упражнением. - Гиппократ

Подробнее..

Кому давно пора обучиться IT пять сфер, где не хватает специалистов

25.02.2021 10:21:06 | Автор: admin

Казалось бы, в 2020 году каждая индустрия должна быть тесно связана с технологиями. Но пока остается много сфер, в которых не хватает и IT-стартапов, и взгляда IT-специалистов. Этим отраслям, может быть, и не страшна технологическая революция они просто никуда не денутся. Но им и тем, кто в них работает, давно пора меняться.

1. Образование

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

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

Но эта проблема касается не только преподавателей информатики, она затрагивает все аспекты работы школ: их сайты, безопасность Wi-Fi сетей, планы перехода на дистанционку и обратно и так далее. А надеяться на массовое внедрение совсем интересных вещей вроде AR и VR-технологий пока стоит скорее в сферах обучения специалистов и в платном образовании, чем в школах. Школа, с которой я сотрудничаю, получила грант в рамках нацпроекта Цифровая экономика, и теперь они сами создают контент для школьников, например, экскурсии и 3D-модели комплектующих компьютера. Но в целом пока в русском сегменте мало образовательного контента под AR и VR, - говорит Сергей.

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

2. Сельское хозяйство и пищевая промышленность

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

Средний и малый бизнес не может позволить себе такие дорогостоящие технологии. К тому же сама отрасль достаточно консервативна: не все аграрии в курсе, как IT-решения могут помочь им увеличить производительность. Они пока не видят в этом большого смысла и не очень хотят вкладываться в рискованные, с них точки зрения, инновации, - говорит Юлия Фурсова, старший консультант направления Chemicals в Hays.

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

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

3. Медицина

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

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

Недостаток понимания работает в обе стороны: yедостаток понимания работает вобе стороны: например, втех телемедицинских проектах, которые сейчас активно развивают IT-сервисы (отСбербанка доЯндекса), совсем непомешалобы уделять больше внимания реалиям работы врачей ипсихологическим тонкости работы спациентами наприемах, считает хирург и сооснователь сервиса ПроДокторов Сергей Федосов. Это бы позволило сделать такие сервисы гораздо более полезными и удобными для врачей и пациентов.

4. Журналистика

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

Компетенции в сфере IT могут серьезно изменить эту ситуацию. Умение и рассказывать истории, и использовать IT-инструменты позволяет журналистам делать свою работу гораздо точнее и эффективнее. В XXI веке умение писать код для журналиста не менее важно, чем умение писать текст, - рассказывает Роман Анин из Важных историй. Раньше я часто старался проверять крупнейшие госконтракты и их получателей, чтобы выявить из них фирмы-однодневки и фирмы, связанные с чиновниками. На это тратилась куча времени и это не получалось сделать систематически, а значит, я постоянно что-то упускал. Но после того, как я написал код, который делает анализ за меня, я не упускаю ничего и трачу на это в тысячу раз меньше времени.

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

5. Ритейл

2020 год показал, что электронная торговля не просто удобна для покупателей - иногда она бывает буквально жизненно важна. В первом полугодии доля интернет-торговли на российском рынке впервые составила почти 11%, приблизившись к показателям, например, США (где она составила около 14%). Ритейл-сети, интернет-магазины и сервисы доставки столкнулись с необходимостью обрабатывать гораздо большие объемы заказов, чем раньше, и не все оказались к этому готовы. У крупных компаний возрос спрос на специалистов практически всех специальностей, связанных с IT.

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

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

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

А как вы считаете, в каких сферах серьезно не хватает руководителей и сотрудников, которые разбирались бы в IT?

Подробнее..

Свидетели DevOps мифы и байки про девопсов и тех, кто их нанимает

25.02.2021 10:21:06 | Автор: admin

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

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

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

Трудности перевода

Справедливости ради оговорюсь, что DevOps это не название профессии, а методология. Она описывает набор подходов и практик, которые помогают командной разработке. Но штампы преследуют нас повсюду. И вот уже не режет слух, когда уважаемый заказчик, представляя свою команду на установочном звонке, говорит: А это Антон, наш девопс. Знакомьтесь, DevOps. Человек и пароход.

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

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

Однако, девопс девопсу рознь. И кажется, что девопс стал эдаким расхожим понятием, которое подменило нынче массу остальных профессий.

Байка про хромого девопса

Недавно нас позвали на помощь в один проект, где стояла, на первый взгляд, простая задача. Web-приложение работало через web-сокеты, но было развернуто внутри периметра, а на фронте стоял ISPManager, который в качестве reverse proxy использовал apache. Юный девопс, работавший в этом проекте, перепробовал все примеры конфига апача, которые нашел в Гугле, и вконец разочаровавшись в его поисковых способностях, перешел уже было к Яндексу, но тут менеджер проекта забил тревогу. На задачу к тому моменту было потрачено 72 часа. 72 часа, Карл! Кто вам сказал, что методология DevOps ускоряет разработку и сокращает time-to-market? ;)

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

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

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

Про технологии

DevOps это про культуру и философию совместной работы, но с этим понятием также сопряжен определенный технологический стек. Скорее всего я не ошибусь, если скажу, что какие-нибудь NetApp, Cisco, AIX или MS SQL воспринимаются как старый добрый олдскул (хотя это не совсем так, и классические вендоры делают гигантские шаги в новом направлении), а вот, скажем, Docker, Ansible, Jenkins и Prometheus в нашем сознании прочно ассоциируются с DevOps, SRE и новыми веяниями.

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

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

И отдельная боль это сеть. В сети надо разбираться, владеть инструментами диагностики. Сеть не зависит от платформы, она есть везде и напрямую (а порой больно) влияет на работоспособность и производительность всего остального. Когда человек, грезящий себя девопсом, наивно полагает, что надо установить свежую версию Kibana, потому что она умеет конвертировать адреса IPv6 в IPv4 это звучит как анекдот. Но потом он, например, берет и орудует с сетью вот так:

или вот так:

Дальше хочу немного заострить внимание на двух технологиях, которые почти стали синонимами DevOps.

А давайте-ка все распилим на микросервисы, засунем в Docker и запустим в Kubernetes

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

Но не все следует доводить до маразма, даже если это увлекательно. Недавно моей команде на попечение был передан проект разработки мобильного приложения, в котором до нас один одаренный девопс настроил деплой бэкэнда на тестинг и продакшн, а затем от греха подальше уволился. Бэкэнд, по сути, представлял собой приложение на python, упакованное в один единственный контейнер. И этот одинокий контейнер исполнятся на одном физическом хосте. Мы читали путанный многоэтажный Dockerfile и искренне недоумевали, зачем все это надо было вообще совать в контейнер. Точнее, в контейнере ему и место, но не в этом.

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

Вот, кстати, символичный фрагмент одного из скриптов по деплою:

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

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

А про кубер вспоминается недавно гулявший ролик, где старый фильм озвучили новыми словами:

- А у вас есть kubernetes?

- Да, конечно, ну как у всех! Как полагается.

- А зачем?

- Ну как это зачем? Это же

Дальше следует немая сцена, гримаса ужаса и спустя некоторое время человек, вероятно, идет топиться.

Я считаю себя евангелистом подхода Infrastructure as Code (IaC). Мне спокойно только тогда, когда продукт не просто освоен, а когда его развертывание и настройка автоматизированы. Специально не добавляю слово документированы, потому что декларативный характер инструментов IaC что приятно во много порождает автодокументируемый код.

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

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

Просто через docker run:

docker run

docker run -d \

-e 'ALERTMANAGER_URL=http://alertmanager:9093' \

-e 'BOLT_PATH=/data/bot.db' \

-e 'STORE=bolt' \

-e 'TELEGRAM_ADMIN=1234567' \

-e 'TELEGRAM_TOKEN=XXX' \

-v '/srv/monitoring/alertmanager-bot:/data' \

--name alertmanager-bot \

metalmatze/alertmanager-bot:0.4.3

С помощью docker-compose

docker-compose

networks:

alertmanager-bot: {}

services:

alertmanager-bot:

command:

- --alertmanager.url=http://localhost:9093

- --log.level=info

- --store=bolt

- --bolt.path=/data/bot.db

environment:

TELEGRAM_ADMIN: "1234"

TELEGRAM_TOKEN: XXXXXXX

image: metalmatze/alertmanager-bot:0.4.3

networks:

- alertmanager-bot

ports:

- 8080:8080

restart: always

volumes:

- ./data:/data

version: "3"

А вот тот же сервис в Kubernetes

кубер

apiVersion: v1

items:

- apiVersion: v1

data:

admin: MTIzNA==

token: WFhYWFhYWA==

kind: Secret

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

type: Opaque

- apiVersion: v1

kind: Service

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

ports:

- name: http

port: 8080

targetPort: 8080

selector:

app.kubernetes.io/name: alertmanager-bot

- apiVersion: apps/v1

kind: StatefulSet

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

podManagementPolicy: OrderedReady

replicas: 1

selector:

matchLabels:

app.kubernetes.io/name: alertmanager-bot

serviceName: alertmanager-bot

template:

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

containers:

- args:

- --alertmanager.url=http://localhost:9093

- --log.level=info

- --store=bolt

- --bolt.path=/data/bot.db

env:

- name: TELEGRAM_ADMIN

valueFrom:

secretKeyRef:

key: admin

name: alertmanager-bot

- name: TELEGRAM_TOKEN

valueFrom:

secretKeyRef:

key: token

name: alertmanager-bot

image: metalmatze/alertmanager-bot:0.4.3

imagePullPolicy: IfNotPresent

name: alertmanager-bot

ports:

- containerPort: 8080

name: http

resources:

limits:

cpu: 100m

memory: 128Mi

requests:

cpu: 25m

memory: 64Mi

volumeMounts:

- mountPath: /data

name: data

restartPolicy: Always

volumes:

- name: data

persistentVolumeClaim:

claimName: data

volumeClaimTemplates:

- apiVersion: v1

kind: PersistentVolumeClaim

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 1Gi

storageClassName: standard

kind: List

Если решение все же принято, вам предстоит перелопатить горы документации, написать тонны yaml-a, мучительно искать, где пропущен отступ, по 10 раз пересобирать контейнеры. И в этом момент вы еще и не знаете, что через пару недель пройдете новый круг ада, подстраивая ваш деплоймент под Pod Security Policy и разные энтерпрайзные фичи. Конечно, когда вы это дотащите до конца, вы получите красивый сервис, который легко скейлится, автоматически перезапускается при сбоях, который можно обновлять, используя, например, канареечные релизы или какой-нибудь blue-green deployment.

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

Автоматизация как истинный путь джедая

Наши бэкапшики помнят один случай, как сотрудник заказчика собирался в консоли что-то удалить то ли ненужный симлинк, то ли копию конфига. А его то и дело дергали. По воле случая в один момент так сошлось, что товарищ успел набрать rm -rf /oradata, работая от рута, потом чихнул, что в свою очередь пробудило в его организме рута позывы на исход жидкости, а по дороге обратно он зацепился языками с товарищами. Когда он вернулся на рабочее месте, его экран спал. Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter. В общем, когда все делаешь руками, нелепые вещи случаются сплошь и рядом.

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

Самое плохое в автоматизации это время, которое надо на нее потратить. И самое хорошее в ней тоже время, которое она впоследствие высвобождает. Например, пару лет назад нам потребовалось в нашем облаке IaaS развернуть инфраструктуру под нового e-commerce заказчика. Архитектура проекта: кластер БД, пул серверов приложений, распределенное хранилище, слой кэширования, сетевые балансировщики, WAF, ну и стандартная обвязка в виде телеметрии, СРК и сбора логов с визуализацией. Конечно, виртуальные машины мы давно создавали при помощи terraform, благо под наше облако можно использовать AWS-провайдер, так как мы по API совместимы. Программные компоненты и раньше ставили через ansible, и опыт настройки всего по отдельности, в общем, был. Но мы задались целью описать инфраструктуру проекта в виде единого пайплайна. На это ушло время, ну и до сих пор части этой автоматизации совершенствуются, так как еще много где были нами после переиспользованы.

Когда нам позже подвернулся аналогичный проект, различия описывались на уровне файла ответов. Мы развернули проект за 2 дня, причем большую часть времени занял перенос данных. В Gitlab CI запускался pipeline, который заполнял переменные для terraform, который затем запускался runner-ом. Тот создавал в облаке сети, диски и ВМ. ВМ запускались с cloud-init, который ставил внутрь puppet agent, который после старта связывался с foreman, забирал настройки для своей роли и деплоил все ПО. Через service discovery подключался мониторинг всех служб, везде встал и настроился filebeat, а бакап полился в S3. Voila! Все быстро и четко, без ошибок и ручных тестов на каждом шаге.

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

Вместе с тем, выполнение следующих правил способно практически нивелировать эффект самозагнивания (когда ломается само по себе с течением времени). Для этого нужно:

  • осмысленный сайзинг ресурсов;

  • отдельные точки монтирования (отдельный диск/раздел) под данные приложений и все, что может быстро пухнуть;

  • синхронизацию времени по ntp;

  • переход на использование ключей вместо паролей в ssh;

  • настроить ротацию всех логов;

  • иметь автоматический механизм обновления протухающих SSL-сертификатов

  • покрыть мониторингом все ключевые показатели жизнеспособности системы и не забыть про алерты;

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

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

Эти простые меры по принципу Парето составляют не более 20% действий по первичной настройке, но дают 80% вклада в стабильную и автономную их работу в будущем.

Если у вас уже есть provision-система, то следом можно подключить инструмент IaC, и накатывать все эти настройки всегда по умолчанию, через какой-нибудь базовый профиль. Я в такой профиль еще включаю набор обязательных утилит, чтобы, к примеру, в экстренной ситуации не оказалось, что в системе нет lsof, tcpdump и т. п.

Время и внимание хорошего девопса такие проблемы не отнимают, потому что он их еще в самом начале решил.

Как не стать героем баек

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

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

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

И напоследок завет работодателям

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

Если вам понадобился девопс, у вас вероятно уже есть разработка. Задачи, которые выполняет девопс это та же разработка, только инфраструктуры и процессов, поэтому к ней в целом применимы те же правила. Над девопсом должен быть senior или тимлид, который через систему контроля версий делает code review, проверяет и одобряет PR/MR. И совершенно точно не стоит доверять архитектурные вопросы человеку без подтвержденного архитектурного опыта. Лучше поищите стороннюю экспертизу для подстраховки.

Мне также нравится концепция, когда отдельно от специалистов DevOps позиционируется еще одна команда - платформенных инженеров (Platform engineer). Она не работает непосредственно с девелоперами, но именно она снабжает девопса готовыми, отлаженными рычагами к этой платформе и уже настроенному инструментарию. Именно такой подход позволяет снизить планку требований к девопсу, позволяя ему спокойнее учиться и снижая риск его ошибок.

В этом месте ставлю не точку, а многоточие, так как тема неисчерпаемая и весьма холиварная. Комментарии, как говорится, покажут :)

Подробнее..

Идеальное резюме для разработчика

23.02.2021 14:15:47 | Автор: admin

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

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

Также, стандарты резюме отличаются от страны к стране, от рынка к рынку. В странах где развит аутсорс больше смотрят на конкретные технологии, а не на достижения. В разработке игр могут быть важны фундаментальные знания (например, математика, физика). В Германии допускается фотография в резюме, а в США нет. Отталкивайтесь от специфик индустрии когда подаете резюме, чтобы увеличить шансы, что вас заметят.

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

Общие советы

  • Размер. Идеальный размер резюме 1 страница. Вы можете позволить себе 2 страницы, но только когда это действительно важная информация, например, достижения на работе или вклад в Open Source.

  • Стиль. Резюме должно быть в едином стиле. Не перебарщивайте с тем, чтобы в резюме был одновременно курсив, выделение жирным, разный шрифт, размер и цвет.

  • Одна колонка. Не разбивайте ваше резюме на две колонки, вторая колонка, расположенная справа, заберет внимание читателя на менее ценную информацию с самого начала.

  • Название файла. Название должно отображать роль, на которую вы подаетесь, и идентифицировать вас resume_dmytro_striletskyi_software_engineer, можно пойти от большего к меньшему resume_software_engineer_dmytro_striletskyi. Можно сократить software_engineer до se.

  • Формат. Признанным форматом резюме является PDF. Возможно, в каких-то компаниях корпоративным стандартом будет другой формат, но вы об этом точно узнаете.

  • Личная информация. Уберите из резюме фото, пол, возраст, семейный статус, это связано с дискриминацией, почитать можно здесь.

  • Ссылки. Есть два варианта: Github (или ваш никнейм) либо https://github.com/dmytrostriletskyi (или сокращенный вариант, например, через bit.ly). В первом варианте вы зашиваете ссылку в текст и по нажатию на него страница откроется в браузере. Во втором варианте вы указываете полную ссылку на случай если резюме будут распечатывать.

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

  • Иностранные языки. Если вы подаете резюме в компанию, где говорят на английском, то нет смысла указывать его в резюме. Ваше резюме уже предполагает что вы знаете его на необходимом для работы и жизни уровне (это проверят на собеседованиях). Знания других иностранных языков можно указывать когда: это пригодится по работе (например, заказчик в вашей будущей компании из Китая и вы знаете китайский) либо это язык страны, куда вы хотите переехать и национальный язык там не английский (немецкий, французский) тогда это точно оценят. Родные языки просто так нет смысла указывать, если в вакансии нет таких требований.

  • Грамматика. Проверяйте текст в резюме на грамматику (например, Grammarly, есть бесплатный режим). Советую взять полчаса у носителя языка на любой популярной платформе (например, Preply, это будет стоить меньше $10), он также проверит, звучит ли текст.

  • Композиция. Текст должен быть выровнен по левому краю. Так ваше резюме будет приятно читать (как статью или книгу).

Структура

Описывать структуру буду в порядке очередности сверху вниз. В общем, нужно отталкиваться от принятых стандартов и что самая важная информация должна быть в самом начале.

Заголовок

В нем нужно указать:

  • Имя и фамилия. Если ваше имя трудно произнести человеку из другой страны, рассмотрите вариант либо сократить его (например, из Alexey сделать Alex), либо переделать (например, из Ekaterina сделать Kate).

  • Желаемая должность. Может быть непонятно, из предыдущего опыта, на какую должность вы претендуете. Например, вы хотите попробоваться на позицию Senior, а в резюме такого опыта не было. Или у вас в резюме есть роли где вы руководите командой, но в новой компании вам делать этого не хочется.

  • Почта. Лично мне нравится, когда название почтового адреса более или менее стандартное (имя и фамилия), а не какой-то dark.knight13@gmail.com, хотя не могу сказать что это вообще влияет на что-то.

  • Номер телефона. По моему опыту, рекрутеры из определённых стран больше любят звонить, а не общаться по почте (например, из Великобритании и Германии). Наличие номера страны в которую ты подаешься, в моем случае, было не обязательным, все равно звонили на украинский.

  • Текущая локация. Ограничьтесь городом и страной, не надо указывать улицу и номер дома.

  • Виза. Если у вас нет легального права работать в стране, в которую вы подаетесь, вам нужно об этом написать словам вроде Willing to relocate, Ready to relocate, или Visa sponsorship required. Если у вас есть легальное право работать в стране, то укажите словами вроде H1B visa holder или UK Global Talent visa holder, это конкурентное преимущество.

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

О себе

Расскажите работодателю о себе, своих достижениях и опыте в профессиональном плане за весь карьерный путь. Здесь можно упомянуть количество лет в индустрии, сферы в которых вы работали (например, FinTech), предпочитаемые типы компаний (например, стартапы и продуктовые), ваши ключевые навыки (например, опыт в distributed systems и/или NLP), вклад в Open Source, наличие блога, статей, канала на YouTube, ценности в инженерии (например, про культуру разработки).

Добавьте ссылки на ваши ресурсы: Github, LinkedIn, Stack Overflow, Medium, Habr, YouTube, персональный блог.

Указывайте личные увлечения и хобби только если они как-то связаны с будущей работой. Например, в компании делают приложение для велосипедистов, а вы мастер спорта по велоспорту. Не описывайте себя банальными словами, которые не несут полезной информации, типа творческий и стрессоустойчивый, если их нельзя подкрепить вашим опытом и достижениями.

Опыт работы

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

Описание должности и компании состоит из:

  • Название должности. Если вы росли в компании по разным должностям, я рекомендую подробно описывать это на таких площадках, как LinkedIn, а в резюме указывать либо подходящую должность для вакансии, либо комбинацию из нескольких (например, Software Engineer & Tech Lead).

  • Название компании. Зашейте ссылку на сайт компании в ее название.

  • Город и страна. Указывайте где вы находились во время работы, а не месторасположение компании.

  • Дата начала и конца работы. В случае если вы еще работаете в компании, пишите Present вместо даты конца. Формат даты состоит из месяца и года.

  • Персональные достижения за время работы.

О персональных достижениях подробнее:

  • Они должны быть оформлены как список (ненумерованный).

  • Каждый пункт описывает ваше (не команды и не компании) достижение. Поэтому слова участвовал или помогал здесь неприменимы.

  • Указывайте конкретные цифры.

  • Не пишите про дефолтные вещи вроде участия в код-ревью, митингах, написании тестов, починке багов.

Примеры достижений:

  • Ускорил алгоритм поиска свободной машины такси на 25%, что увеличило количество поездок в месяц на ~300 тысяч.

  • Объединил два экрана в мобильном приложении в один, что увеличило конверсию на 2.3%.

  • Управлял командой из 5 разработчиков.

Также полезно знать:

  • Это нормально, если у вас нет особых достижений, или они есть, но их трудно выразить в цифрах. Попробуйте сконцентрироваться на том, что вы сделали, и написать как есть. Например, сделал распределенную копию Google Drive.

  • Уберите нерелевантный опыт. Например, вы были разработчиком в первой компании, потом стали СТО во второй и подаетесь в третью компанию на позицию разработчика. Если в вакансии не указаны требования к опыту на высоких должностях, то лучше поменять СТО на что-то вроде Senior Software Engineer или Tech Lead, убрав нерелевантные достижения вроде управлял бюджетом на найм сотрудников. Лучше сфокусироваться на ваших знаниях и опыте, которые будут наиболее применимы к работе разработчиком.

Технологии и навыки

Укажите несколько строк про технологии и навыки, которыми вы владеете. Начните с основных (например, Python), продолжите стандартами в индустрии (например, Docker, Kubernetes), закончите специфическим (например, ELK). Указывайте технологии в которых вы либо хорошо разбираетесь, либо у вас был ценный опыт. Не указывайте то, с чем вы почти не работали, либо работали давно и ничего не сможете рассказать вас обязательно спросят.

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

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

Проекты

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

Образование

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

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

Другое

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

Заключение

Советы выше не новы. Я хотел поделиться своим мнением и привести в пример свое резюме. Читайте комментарии на случай если сообщество найдет какие-то советы вредными. Также рекомендую посмотреть еще это:

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

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

Подробнее..

Чемпионаты по программированию развлечение для студентов или способ устроиться на работу мечты?

19.02.2021 16:11:01 | Автор: admin

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


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


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





Кто изачем проводит чемпионаты попрограммированию


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




Геннадий Короткевич. Источник

Получается, что для компаний такой способ поиска кандидатов очень удобен. Для него даже придумали название Hiring event. Явление это нередкое, довольно популярное укрупных компаний истартапов:


  • В2019 юникорн-стартап Bolt проводил чемпионат, накотором предлагали денежные призы ирелокейт вЭстонию.
  • ВGoogle Code Jam победитель получает 15000$, акучастникам присматриваются для найма.
  • Facebook регулярно проводит международный конкурс попрограммированию там можно выиграть 500000$.
  • Huawei тоже проводят чемпионат снесколькими номинациями иденежными призами.


Николай Будин, призер чемпионата юникорн-стартапа Bolt:


Ясошколы много участвовал вчемпионатах попрограммированию, ипосле выпуска продолжил этим заниматься. Когда узнал очемпионате отBolt, решил поучаствовать, чтобы попрактиковаться иможет быть выиграть приз. Задания были стандартные написать программу, которая повходным данным выдаст определенный результат. Для меня оказались несложными видимо, сказался опыт. Витоге занял второе место иполучил приглашение насобеседование вМоскву. Янепоехал, так как неинтересовался работой, нопредложение действительно поступало.

ВРоссии тоже неотстают:


  • Яндекс в2020 проводил Яндекс Cup там были иденежные призы, иупрощенное собеседование для 20лучших.
  • УВконтакте есть VKCup, сденежными призами. Онайме впризах ничего несказано, нопобедители рассказывали, что импришло письмо отHR.
  • Похожий наолимпиаду ивент проводила компания FunCorp там было тестовое вформате олимпиадной задачи исобеседование заодин день, после которого приглашали наработу.
  • Mail.Ru постоянно проводят разные чемпионаты свнушительными призами иобещаниями офферов.

В2020 из-за пандемии счемпионатами было похуже часть перенесли вонлайн, часть вообще отменили. Надеемся, что в2021 все потихоньку наладится.




Победители Facebook hacker cup

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



Зачем участвовать вчемпионатах попрограммированию


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


Для программиста сопытом это возможность за12 дня запрыгнуть вЯндекс, Mail.Ru или даже Google. Быстрее, чем пытаться самому пройти все этапы собеседования инаконец дойти донайма.


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


Кстати, иногда про оффер иинтервью вусловиях чемпионата неговорят обещают только денежный приз. Нопобедителям все равно приходит заветное письмо отHR. Поэтому если чемпионат проводит крупная компания, нообоффере впризах нислова, все равно стоит попробовать поучаствовать победителей наверняка пригласят насобеседование.


Проверить навыки иоценить себя. Даже если пока непланируете менять работу, сможете посмотреть, справитесьли высосложными задачами открупных компаний. Кстати, примерно такие задачки вас ждут нареальных собеседованиях: мырассказывали обэтом встатьях обустройстве вFacebook, Reddit, Spotify или Google. Так что вчемпионатах стоит поучаствовать хотябы ради практики.


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


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




Чего ждать отчемпионата икак кнему подготовиться


Конкретные условия иформаты учемпионатов всегда разные. Нообычно схема такая: Регистрируетесь проходите простой отбор решаете сложные задачи получаете приз или оффер. Иногда решать задачи можно как угодно, иногда требуют конкретные языки или технологии, например, JavaScript.


Задачи обычно такие, которые можно решить быстро, занесколько часов. Есть набор входных данных, ихнужно как-то обработать, чтобы получить навыходе конкретный результат. Участникам предлагают самим выбрать алгоритм инаписать работающий код. Качество кода тоже проверяют смотрят, кто справился чище всех.


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



НаLeetcode многое непонятно, ноесть туториал попорядку прохождения задач итабличка посложности.


Еще такие задачи ссобеседований иолимпиад часто разбирают навидео. Вот несколько интересных:




Заинтересовались чемпионатами ихотите попробовать свои силы или сменить работу? Если пишете наJavaScript, можно прямо сейчас поучаствовать вчемпионате отЯндекса через g-mate. Ивместо длинного сложного трудоустройства длиной несколько месяцев получить оффер отЯндекса заодин день.
Подробнее..

Перевод Пол Грэм Над чем я работал

20.02.2021 20:08:41 | Автор: admin
Февраль 2021

image

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

Первые свои программы я пытался писать на IBM 1401, его у нас в округе использовали для того, что тогда называли обработкой данных. Это было в 9 классе, так что мне было 13 или 14 лет. Этот 1401 стоял в подвале средней школы, мы с моим другом Ричем Дрейвсом получили разрешение использовать его. Тот подвал был похож на логово бондовского злодея, в котором хранится куча инопланетных устройств процессоры, жесткие диски, принтер, устройство для чтения карт, и все это под яркими флуоресцентными лампами.

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


image

IBM 1401

Тот 1401 был для меня загадкой. Я не понимал что с ним можно делать, Оглядываясь назад, ясно, что я особо ничего и не мог. Единственной формой передачи входных данных были перфокарты, а я на них ничего не хранил. В качестве альтернативы можно было писать программы, не полагающиеся на входные данные (вроде приближенных вычислений числа пи), но я не очень хорошо знал математику для этого. Именно поэтому я не удивлен, что не могу вспомнить ни одной своей программы из того времени потому что они мало чего умели. Лучше всего мне запомнился тот момент, когда я узнал, что программы могут и не завершаться (когда одна из моих не завершилась). Учитывая, что у того компьютера не было ограничений по времени использования, это была не только техническая, но и социальная ошибка об этом мне сообщил менеджер центра обработки данных.

Все изменилось с появлением микрокомпьютеров. У нас появились компьютеры, стоящие на столе прямо перед нами, они реагировали на нажатия кнопок прямо во время работы, а не перебирали стопку перфокарт и отключались. [1]

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

image


Heathkit H8 Digital Computer Kits

Компьютеры тогда стоили дорого, мне пришлось годами уламывать отца, прежде чем он купил TRS-80 примерно в 1980 году. Золотым стандартом тогда был Apple II, но TRS-80 тоже был довольно хорош.

image

TRS-80

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

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

Я не мог выразить это словами, когда мне было 18 лет. Я продолжал ходить на курсы по философии, и они были скучны. Именно поэтому я начал заниматься ИИ.

Об ИИ много говорили в 1980-ых, но мне особую мотивацию придали две вещи: роман Хайнлайна под названием Луна суровая хозяйка, в котором использовался умный компьютер по имени Майк, и документальный фильм от PBS, в котором Терри Виноград использовал SHRDLU.

image

SHRDLU

Я не пытался перечитывать роман Хайнлайна, потому что понимаю, что он устарел, но в те годы я погрузился в мир этой книги. Казалось, что появление Майка лишь вопрос времени, и когда я увидел как Виноград использует SHRDLU, мне показалось, что на его создание уйдет несколько лет. Казалось, что нужно лишь обучить SHRDLU большему количеству слов.

Тогда в Корнелле не было курсов по ИИ, так что мне пришлось учиться самому. Это значило, что мне нужно было выучить Lisp, потому что тогда он был языком ИИ. В то время большинство языков программирования были примитивными, а значит идеи программистов были такими же. По умолчанию в Корнелле все писали на паскалеподобном языке PL/I, он использовался почти повсеместно. Изучение Lisp настолько расширило мое понимание концепции программ, что ограничения я начал понимать лишь спустя годы. Именно этого я и ожидал от колледжа. Этого эффекта не было от занятий в классах, но это нормально. Следующие пару лет я был в ударе. Я понимал что собираюсь делать.

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

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

Я подал документы в 3 аспирантуры: Массачусетского Технологического, Йеля, который тогда славился в области ИИ, и Гарварда его я посетил поскольку туда пошел Рич Дрейвз, а также там жил Билл Вудс, разработавший парсер для моего клона SHRDLU. Меня приняли только в Гарвард, так что туда я и пошел.

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

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

Я стал думать, что из обломков моих планов можно спасти, и вспомнил про Lisp. По своему опыту работы с ним я знал, что этот язык интересен сам по себе, даже в отрыве от ИИ (хотя в то время люди занимались им только в этом контексте). Именно поэтому я решил сосредоточиться на Lisp. Я решил написать книгу о хакерстве на Lisp. Страшно подумать насколько мало я об этом знал, когда начинал писать книгу. Впрочем, нет ничего лучше написания книги, чтобы разобраться в какой-либо теме. Книга о Lisp была опубликована в 1993, но большую ее часть я написал в аспирантуре.

Computer Science это непростой союз теории и систем. Теории позволяют строить доказательства, а с помощью систем люди строили и создавали. Я хотел создавать. Я с большим уважением относился к теории (на самом деле, подозреваю, что эта половина более прекрасна), но казалось, что создавать что-то будет интереснее.

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

image


Xerox Star 8010 Dandelion

В какой-то момент в лаборатории появились несколько лишних компьютеров Xerox Dandelion. Любой желающий поиграться с ним мог его взять. Я сам ненадолго соблазнился, но по нынешним стандартам они были очень медленными, так что какой смысл? Никому они были не нужны, а потому и исчезли. Именно так все и происходило с системами.

Я хотел не просто что-то создавать, а создавать что-то, что будет служить долго.

Будучи неудовлетворенным, я поехал к Ричу Дрейвзу в Институт Карнеги-Меллона, он там учился в аспирантуре. Однажды я заходил в Институт Карнеги, в детстве я там проводил много времени. Я рассматривал картину и до меня дошла мысль, которая кажется очевидной, хотя тогда она меня удивила. Прямо там на стенах висели вещи, которые делались надолго. Картины не устаревали. Возраст некоторых из лучших составлял сотни лет.

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

Мне всегда нравилось смотреть на картины. Мог ли я сам их писать? Тогда я понятия не имел. Я даже представить себе не мог, что это возможно. Умом я понимал, что искусство творят люди что оно не возникало само по себе, но эти творцы будто принадлежали к другому виду. Они либо жили давно, либо это загадочные гении, о чудачествах которых пишут в Life. Мысль о том, чтобы заняться искусством, казалась невероятной.

Той осенью я начал посещать уроки творчества в Гарварде. Аспиранты могли посещать занятия всех факультетов, а мой научный руководитель Том Читэм был очень спокойным и простым человеком. Даже если он и знал о странных курсах, которые я посещал, они никогда и ничего не говорил.

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

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

Однажды в апреле 1990 года все сдвинулось с места. Я столкнулся с профессором Читэмом он спросил смогу ли я выпуститься в июне. К тому моменту я не написал ни слова, но в тот момент я принял самое быстрое решение в жизни я решил написать диссертацию примерно за 5 недель до крайнего срока, по возможности переиспользуя фрагменты своей книги On Lisp. Именно поэтому я без промедления ответил Думаю, да. Я дам вам материалы для прочтения через несколько дней.

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

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

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

Только страньери (иностранцы) должны были сдавать вступительные экзамены. Оглядываясь назад, я понимаю, что видимо это был способ отсеивать иностранцев, потому что в противном случае итальянцы были бы в меньшинстве. В то лето я был в хорошей форме в плане рисования и живописи, но не понимал как сдавать письменный экзамен, Я помню, что ответил на вопрос в эссе, написав о Сезанне я вытянул интеллектуальный уровень на максимум, который позволял мой ограниченный словарный запас. [2]

Мне было всего 25, и в моей жизни уже проявились интересные закономерности. Я снова стремился поступить в престижное учебное заведение с целью изучить какой-нибудь престижный придет, и я снова был разочарован. Студенты и преподаватели в академии были замечательными, но у них было негласное соглашение студенты не требовали, чтобы их учили, а академия не требовала, чтобы студенты что-либо изучали. При этом все происходило с условностями ателье из XIX века. У нас действительно стояла печка, которая топилась дровами, и обнаженная модель, которая сидела к ней максимально близко, чтобы не обжечься. Кроме меня почти никто ее не рисовал. Остальные студенты болтали или пытались подражать тому, что видели в американских журналах об искусстве.

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

Во время учебы в академии, по ночам в своей комнате я рисовал натюрморты. Эти картины были маленькими: во-первых, сама комната была маленькой, а во-вторых, я рисовал их на обрывках холста большего я себе не мог позволить. Рисование натюрмортов отличается от рисования людей (потому что как следует из названия, объекты двигаться не могут). Люди не могут сидеть неподвижно больше 15 минут, и даже в это время они не замирают полностью. Стандартный метод рисования людей знать как рисовать типичного человека, а затем подстраивать эти знания под того человека, которого вы рисуете. Натюрморт же можно пиксель за пикселем копировать с того, что вы видите. Конечно, не хочется останавливаться на достигнутом, иначе вы получите фотографическую точность натюрморты интересны именно тем, что они проходят через голову художника. Вам захочется подчеркивать визуальные особенности, которые, например, сообщают о том, что резкая смена цвета в точке описывает край объекта. Тонко подчеркивая такие моменты, вы можете создавать картины, которые будут более реалистичными, чем фотографии не только в метафорическом, но и в строгом теоретико-информационном смысле. [5]

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

Это не единственный способ рисования. Я не уверен на 100%, что он вообще хорош. Впрочем, мне он казался стоящим, а значит нужно было попробовать.

Наш учитель, профессор Уливи, был хорошим человеком. Он видел, что я много работал, и ставил мне хорошие оценки в дневник, который был у каждого студента. Впрочем, академия не учила меня ничему кроме итальянского, а также у меня стали заканчиваться деньги, так что в конце первого года я вернулся в США.

Я хотел вернуться в Род-Айлендскую школу дизайна, но я был разорен, а учиться там было дорого. Из-за этого я решил устроиться на работу на год, а затем продолжить обучение следующей осенью. Я устроился в Interleaf, эта компания занималась разработкой ПО для создания документов. Вроде Microsoft Word? Да, именно. Именно тогда я понял, что дешевое ПО может поглощать ПО высокого уровня. Впрочем, Interleaf оставалось жить еще несколько лет. [5]

Порой в Interleaf делали смелые вещи. Компания была вдохновлена Emacs и создала свой язык для написания сценариев это был диалект Lisp. Компании нужен был хакер на Lisp, который писал бы на этом языке. То, чем я там занимался, наиболее похоже на нормальную работу из всего, чем я занимался (прошу прощения у своего начальника и коллег я был плохим сотрудником). Их Lisp представлял собой тонкий слой глазури на огромном торте из Си, а поскольку я его не знал и учить не хотел, большую часть ПО компании я не понимал. К тому же я был ужасно безответственным. Тогда работа программистом подразумевала приход на рабочее место в определенное время. Мне это казалось противоестественным, и сейчас весь мир сходится к моему образу мышления, но тогда из-за этого возникало немало конфликтов. Ближе к концу года большую часть времени я тайком писал On Lisp книга получила контракт на публикацию.

К счастью, мне платили огромные деньги, особенно по меркам студентов-художников. Во Флоренции, после оплаты аренды, мой бюджет составлял 7 долларов на день. Теперь же мне платили в 4 раза больше, даже если я просто сидел на собрании. Живя экономно, мне удалось не только накопить на возвращение в Род-Айлендскую школу дизайна, но и рассчитаться по ссудам на учебу.

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

Но самый важный, урок который я усвоил (он пригодился мне как в Viaweb, так и в Y Combinator) заключается в том, что нет ничего плохого в том, чтобы работать на начальном уровне, даже если это не так престижно. В противном случае кто-то может просто вдавить вас в потолок. Все это значит, что престиж может быть опасен.

Следующей осенью я возвращался в Род-Айлендскую школу дизайна, и я договорился о внештатной работе в конторе, занимавшейся разработкой различных проектов для клиентов именно на этом я и выживал следующие несколько лет. Когда я вернулся к одному из проектов, кто-то рассказал мне о новом языке, HTML вроде как он был производной от SGML. Энтузиазм к языкам разметки был издержками профессии в Interleaf, и я их игнорировал, хотя позже этот самый HTML стал важной частью моей жизни.

Осенью 1992 года я вернулся в Провиденс, чтобы продолжить учебу в Школе дизайна. Я только начал вникать в основы, а учеба в академии была просто смешной. Теперь я собирался увидеть на что похожа настоящая художественная школа. Увы, она была скорее похожа на Венецианскую Академию. Конечно, все было куда более организованно (и куда дороже), но стало ясно, что художественная школе не имеет того же отношения к искусству, как медицинская к медицине. По крайней мере, на факультете художников. У модельеров (на него учился мой сосед), кажется, все было куда строже. То же самое касалось иллюстраторов и архитекторов. Но в живописи все было не очень строго. Студенты-художники должны были самовыражаться, что для простых людей означало поиски собственного стиля.

Фирменный стиль это визуальный эквивалент того, что в бизнесе называют фишкой: именно благодаря нему люди могут понять, что эта работа принадлежит вам, а не кому-то другому. Например, когда вы видите картину в мультяшном стиле, вы понимаете, что ее написал Рой Лихтенштейн. Если вы увидите такую картину в квартире менеджера хедж-фонда, то будет ясно, что он заплатил за нее миллионы долларов. Не у всех художников есть свой фирменный стиль, хотя обычно клиенты платят именно за него. [6]

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

Я многому научился на уроках колористики, но в остальном я самостоятельно учился рисовать, и я мог делать это бесплатно. В 1993 я бросил учебу. Я немного погулял по Провиденсу, а потом моя подруга по колледжу Нэнси Пармет оказала мне большую услугу. Квартира с умеренной арендной платой в доме, которым владела ее мать в Нью-Йорке, пустовала. Хотел ли я туда заехать? Она была ненамного больше моей собственной квартиры, а в Нью-Йорке было много художников. Так что да, я хотел! [7]

Комиксы об Астериксе начинаются в крошечном уголке Галлии, который, как оказывается, не контролируется римлянами. Что-то похожее есть и в Нью-Йорке: если вы приблизите карту Верхнего Ист-Сайда, то увидите крошечный небогатый район (по крайней мере, он был таким в 1993). Он называется Йорквилл, это был мой новый дом. Я стал Нью-Йоркским художником (чисто технически я рисовал и жил в Нью-Йорке).

Я нервничал из-за денег потому что чувствовал, что Interleaf идет ко дну. Фриланс на Lisp попадался редко, и я не хотел писать на другом языке в те дни это был бы С++, если бы мне повезло. У меня был безошибочный нюх на финансовые возможности, так что я решил написать еще одну книгу о Lisp. Это была более простая и популярная книга, которую можно использовать как учебник. Я представлял себе как экономно живу на гонорары и провожу все свое время за рисованием (рисунок для обложки этой книги, ANSI Common Lisp, я нарисовал примерно в то время).

image


Больше всего мне в Нью-Йорке нравилось, что там жили Идель и Джулианна Вебер. Идель Вебер была художницей, одной из первых начала работать в стиле фотореализма, я посещал ее занятия в Гарварде. Я никогда не видел, чтобы учителя так любили ученики. С ней поддерживали связь большинство бывших студентов, в том числе и я. После переезда в Нью-Йорк я стал де-факто ее студийным ассистентом.

Ей нравилось писать на больших квадратных холстах, шириной от 4 до 5 футов. Однажды в конце 1994 года, когда я растягивал одного из этих монстров, по радио рассказывали что-то об одном известном фондовом менеджере. Он был ненамного старше меня и был очень богат. Мне вдруг пришла в голову мысль: почему бы мне не стать богатым? Тогда я смогу работать над чем захочу.

Попутно я все больше узнавал о недавно появившейся всемирной паутине. Роберт Моррис показал мне ее в Кембридже, потом он перешел в аспирантуру Гарварда. Мне казалось, что интернет будет очень важен. Я видел что графические пользовательские интерфейсы сделали для популярности компьютеров. Казалось, что сеть сделает то же самое для интернета.

Если я хотел разбогатеть, то это был поезд, подходящий к станции. Я был прав в сути, но ошибся с идеей. Я решил, что нужно создать компанию для размещения художественных галерей в интернете. Прочитав множество заявок в Y Combinator, я могу сказать, что это худшая идея для стартапа. Художественные галереи не хотели выходить в интернет и до сих пор не хотят, даже самые модные. Их продажи работают иначе. Я написал ПО для создания сайтов для галерей, а Роберт написал несколько программ для изменения размеров изображения и настройки HTTP-сервера, отдававшего страницы. Потом мы пытались заключить договоры с галереями. Сказать, что это было сложно ничего не сказать. Даже раздавать наш продукт было сложно. Несколько галерей разрешили нам сделать для них сайты бесплатно, но никто нам не платил.

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

Итак, летом 1995 года, после того как я передал издателям готовую рукопись ANSI Common Lisp, мы начали пытаться писать ПО для создания интернет-магазинов. Сначала это должно быть ПО для настольных компьютеров, а значит для Windows. Это была тревожная перспектива мы не умели писать программы для Windows и не хотели учиться. Мы жили в мире Unix. Но мы все же решили написать прототип конструктора магазина под Unix. Роберт написал корзину, а я написал генератор сайтов конечно, на Lisp.

Мы работали в квартире Роберта в Кембридже. Его соседа там подолгу не было, я в это время спал на его месте. Почему-то не было ни корпуса кровати, ни простыней, только матрас на полу. Однажды утром, когда я лежал на этом матрасе, меня посетила идея, из-за которой я свернулся буквой Г. Что если мы будем запускать ПО на сервере и позволим пользователям управлять им, нажимая на ссылки? Тогда нам не нужно было бы ничего писать для клиентских компьютеров. Мы могли бы создавать сайты на том же сервере, с которого они отдавались. Пользователям не понадобится ничего, кроме браузера.

Такое ПО сейчас называется веб-приложением и распространено повсеместно, но тогда было непонятно возможно ли это вообще. Чтобы выяснить, мы решили создать версию нашего конструктора интернет-магазинов, которой можно было бы управлять через браузер. Пару дней спустя, 12 августа, у нас появилась рабочая версия. Пользовательский интерфейс был ужасен, но стало ясно, что можно создать магазин через браузер без клиентского ПО или ввода команд в терминале сервера.

Мы почувствовали, что у нас что-то получается. У нас было видение ПО нового поколения, которое должно было работать таким образом. Больше не были нужны версии, порты и все такое. В Interleaf была целая команда релиз-инженеров, и они работали не меньше разработчиков. Теперь же ПО можно было обновлять прямо на сервере.

Когда нам удалось развернуть свое ПО в сети, мы основали компанию. Она называлась Viaweb и мы получили свое первое официальное финансирование 10 000 долларов от Джулианна, мужа Идель. В обмен на деньги, помощь с юридическими вопросами и советы по ведению бизнеса, мы передали ему 10% компании. Десять лет спустя эта сделка стала образцом для Y Combinator. Мы знали, что основателям нужно нечто подобное, потому что сами нуждались в этом.

В то время мой баланс был отрицательным, поскольку имевшаяся у меня тысяча (или около того) долларов уравновешивалась моими долгами по налогам (откладывал ли я деньги, которые зарабатывал за консультации Interleaf? Нет, не откладывал). Итак, несмотря на то, что Роберт получал стипендию для аспирантов, мне нужно было начальное финансирование на жизнь.

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

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

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

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

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

Мы открылись с 6 магазинами в январе 1996. Хорошо, что мы выждали несколько месяцев, потому что хоть тогда мы и боялись, что опаздываем, на самом деле было слишком рано. Тогда в прессе много писали об электронной коммерции, но не многие хотели заводить свои интернет-магазины. [8]

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

Во второй половине 90-ых было много стартапов, занимавшихся разработкой ПО для электронной коммерции. Мы были полны решимости создать Microsoft Word, а не Interleaf. Для этого наш продукт должен был быть простым в использовании и недорогим. Нам повезло, что мы сами были бедными, это заставило нас удешевить Viaweb еще сильнее. Мы брали 100 долларов в месяц за небольшой магазин и 300 за большой. Эта низкая цены была одновременно соблазном и бременем для конкурентов, но мы установили ее не из-за разумных соображений. Мы понятия не имели какие бизнесы нам платят и как они это делают. 300 долларов в месяц казались нам большими деньгами.

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

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

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

Была и другая вещь, которую я тогда не понял. Я не осознавал, что темп роста главное испытание для стартапа. У нас было около 70 магазинов в конце 1996 года и около 500 в конце 1997. Я ошибочно думал, что решает абсолютное количество пользователей. Это важно с точки зрения ваших доходов если их не будет хватать, вы можете выйти из бизнеса. Но в долгосрочной перспективе темп роста выправляет абсолютное число пользователей. Если бы мы были стартапом, который я консультировал в YCombinator, я бы сказал так: хватит нервничать, у вас все хорошо. У вас семикратный прирост каждый год, Просто не нанимайте слишком много людей, тогда ваш бизнес станет прибыльным, а вы сможете контролировать свою судьбу.

Увы, я нанял много людей. Отчасти из-за того, что таким было желание наших инвесторов, а отчасти из-за того, что во времена интернет-пузыря многие так делали. Таким образом, мы не достигли безубыточности вплоть до сделки с Yahoo в 1998 году. Это, в свою очередь, означало, что мы были во власти инвесторов на протяжении всего срока жизни компании. А поскольку и мы, и наши инвесторы, были новичками в стартапах, в результате творился беспорядок даже по меркам стартапов.

Когда мы ушли под Yahoo, пришло большое облегчение. В целом, акции Viaweb были ценными. Они представляли собой долю в быстрорастущем бизнесе. Но для меня все это было не слишком ценно. Я понятия не имел как оценивать бизнес, но я слишком хорошо чувствовал околосмертные переживания, которые, кажется, наступали каждые несколько месяцев. С тех пор, как мы начали, я не изменил существенно свой аспирантский стиль жизни. Поэтому когда нас купила Yahoo, это был переход из грязи в князи. Поскольку мы переезжали в Калифорнию, я купил желтый VW GTI 1998 года выпуска. Думаю, кожаные сидения этой машины были моим наиболее роскошным имущуством.

В следующем году, с лета 1998 по лето 1999, наверное выдался наименее продуктивный отрезок моей жизни. Тогда я этого не осознавал, но я очень устал от усилий и стрессов, связанных с запуском Viaweb. Какое-то время после переезда в Калифорнию я пытался действовать по-прежнему. Я программировал до трех часов ночи, но усталость вместе с преждевременно состарившейся корпоративной культурой Yahoo и мрачным офисом в Санта-Кларе постепенно меня добили. Через несколько месяцев мне стало очень неприятно, как во времена работы в Interleaf.

Yahoo раздали нам много опционов после покупки. Тогда я думал, что Yahoo очень переоценена, так что я удивился когда узнал, что цена акций к следующему году выросла в 5 раз. Я продержался до получения первых опционов и ушел летом 1999 года. Я так давно ничего не рисовал, что почти забыл, зачем я все это делал. 4 года мой мозг был забит разработкой ПО и рубашками. Я напомнил себе, что делал все это, чтобы разбогатеть и иметь возможность рисовать. Я разбогател, а значит нужно было заняться рисованием.

Когда я сказал, что ухожу, мой босс в Yahoo долго беседовал со мной о моих планах. Я рассказал ему о том, какие картины хочу нарисовать. Тогда я был тронут его интересом. Теперь я понимаю, что ему просто казалось, что я лгу. Тогда мои опционы стоили примерно 2 миллиона долларов. Если бы я просто оставил эти деньги, их хватило бы для основания нового стартапа, а для этого мог бы взять с собой других людей. В те годы интернет-пузырь был на пике, и Yahoo была эпицентром той эпохи. Мой босс на тот момент был миллиардером. Уход из Yahoo с целью основания нового стартапа казался ему безумным, но при этом амбициозным планом.

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

Я пытался рисовать, но похоже, что у меня не было ни энергии, ни амбиций. Отчасти проблема заключалась в том, что я почти никого не знал в Калифорнии. Я усугубил ее, купив прекрасный дом в Калифорнии с замечательным видом, который находился за много миль от моих любимых мест. Я продержался несколько месяцев, а затем в отчаянии вернулся в Нью-Йорк. Вы будете удивлены, если не знаете о том, как организован контроль за арендой жилья в Нью-Йорке, потому что квартира была запечатана и похожа на гробницу моей старой жизни. По крайней мере, Идель все еще была в Нью-Йорке, и там были и другие люди, которые пытались рисовать, хотя я никого из них не знал.

Когда я вернулся в Нью-Йорк, я начал жить по-прежнему, только теперь я был богат. Это было именно настолько странно, как и звучит. Я делал все как раньше, хотя появились и новые возможности. Если я уставал от пеших прогулок, мне нужно было лишь поднять руку (если не шел дождь), чтобы меня подобрало такси. Теперь, когда я проходил мимо очаровательных ресторанов, я мог зайти и заказать обед. Какое-то время это было захватывающе. Рисование стало получаться лучше. Я экспериментировал с новым методом рисования натюрмортов: сначала я рисовал картину как обычно, затем фотографировал ее, распечатывал, размещал ее на холсте, а затем использовал как подмалевок для второй картины, написанной с этих же объектов (которые, как я надеялся, не сгнивали за это время).

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

Примерно в это же время, весной 2000 года, у меня появилась идея. Из нашего опыта с Viaweb стало ясно, что будущее за веб-приложениями. Почему бы не создать веб-приложение для создания веб-приложений? Почему бы не дать людям возможность редактировать код на нашем сервере через браузер, а затем размещать в сети получившиеся приложения? [9] Пользователи могли бы запускать на серверах всевозможные сервисы, которые эти приложения могли бы использовать просто с помощью запросов к API: совершение и прием звонков, обработка изображений, прием платежей с кредитных карт и т.д.

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

Хм. Что ж, значит мне предстояло все сделать самому. Я нанял Дэна Гиффина, который работал в Viaweb, и двух студентов, которые искали работу на лето, и мы взялись за дело. Теперь ясно, что наш проект впору разбить на 20 компаний и несколько проектов с открытым исходным кодом. Язык для разработки приложений, конечно, был диалектом Лиспа. Впрочем, я не был настолько наивен, чтобы полагать, что смогу продвинуть Лисп среди широких масс. Мы скрывали скобки, как это делал Дилан.

К тому времени Viaweb можно было назвать провайдером прикладных услуг (ASP). Это название прожило недолго, его заменили на Software as a service (ПО как услуга), но новую компанию я все равно назвал Aspra.

Я начал работать на конструктором приложений, Дэн занимался сетевой инфраструктурой, а двое старшекурсников работали над первыми двумя сервисами (для изображений и звонков). Примерно в середине лента я понял, что на самом деле не хочу управлять компаний особенно небольшой, которая, как казалось, такой и должна быть. Мне больше не нужны были деньги, так зачем я это делал? Если мое видение должно было быть реализовано в виде компании, то к черту это видение. Я бы создал его небольшую часть в виде проекта с открытым исходным кодом.

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

В итоге проект с открытым исходным кодом, которым я занимался, стал новой версией Лиспа, скобки которой и скрывать не хотелось. Многие люди, пишущие код на Лиспе, мечтают создать новый Лисп. Отчасти дело в том, что одна из отличительных черт этого языка заключается в множестве его диалектов, а отчасти в том, что где-то в нашем сознании существует платоническая форма Лиспа, от которой идут все диалекты. К концу лета мы с Дэном взялись за работу над новым диалектом Лиспа, который мы назвали Arc, в новом доме, который я купил в Кембридже.

Следующей весной прогремел гром. Меня пригласили выступить на конференции по Лиспу, я рассказывал как мы писали на нем в Viaweb. Я разместил постскрипт этого выступления на paulgraham.com, который создал задолго до Viaweb, но совсем не использовал. Однажды страница с выступлением набрала 30 000 просмотров. Что, черт возьми, произошло? По URL-ссылкам стало ясно, что кто-то разместил мое выступление на Slashdot [10]

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

Все это было возможно с 1993, но никто об этом не задумывался. Я был тесно связан с развитием инфраструктуры интернета, писал тексты, но даже мне понадобилось 8 лет, чтобы прийти к этой мысли. Затем мне потребовалось еще несколько лет, чтобы осознать последствия. Это значило, что грядет новое поколение эссе [11]

В эпоху печати каналов для публикации эссе было очень мало. За исключением нескольких общепризнанных мыслителей, ходивших на правильные вечеринки в Нью-Йорке, публиковать эссе разрешалось только специалистам, пишущим о своей деятельности. Многие эссе так и не были написаны из-за отсутствия каналов для их публикации. Канал появился, и я собирался писать. [12]

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

Я знал, что поначалу сфера онлайн-эссе будет маргинальной. В социальном плане эти тексты больше походили на тирады психов с GeoCities, чем на благородные и красиво набранные тексты из The New Yorker. Но к этому моменту я знал достаточно, чтобы это обнадеживало, а не пугало.

Одна из самых заметных закономерностей, которые я замечал в своей жизни это то, насколько хорошо (по крайней мере для меня) работать над тем, что не считается престижным. Натюрморт всегда был наименее престижным видом живописи. Когда мы начинали, всем казалось, что Viaweb и YCombinator никому не нужны. Незнакомцы до сих пор удивляются, когда я говорю, что пишу эссе и собираюсь опубликовать его на своем сайте. Даже Лисп, который считается интеллектуально престижным (примерно как латынь) кажется просто модным.

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

В течение нескольких следующих лет я написал множество эссе на самые разные темы. O'Reilly издали их сборник под названием Хакеры и художники, после одного эссе о них. Также я работал над фильтрами спама и продолжал рисовать. Я приглашал друзей на ужин по вечерам в четверг, что научило меня готовить для группы людей. Позже я купил в Кембридже еще одно здание, бывшую леденцовую фабрику (и как позже оказалось, бывшую порностудию) для использования в качестве офиса.

Однажды в октябре 2003 года у меня дома проходила большая вечеринка. Это была отличная идея моей подруги Марии Дэниэлс, она однажды приходила на ужин в четверг. Три разных хозяина приглашали гостей на вечеринки. Таким образом, на каждого гостя две трети других гостей будут незнакомцами, которых те хотели бы узнать. Одним из гостей была незнакомая мне девушка, которая мне очень понравилась: Джессика Ливингстон. Пару дней спустя я пригласил ее на свидание.

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

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

Один из моих приемов для написания эссе выступление с докладом. Перспектива встать перед группой людей и рассказать им о чем-то, что не потратит их время зря, была большим стимулом для воображения. Когда Гарвардское компьютерное сообщество (компьютерный клуб бакалавров) попросил меня выступить с докладом, я решил, что расскажу им о создании стартапов. Может быть, им удастся избежать худшей из ошибок, что мы сделали.

Итак, я выступил с этим докладом. Я сказал, что лучшими источниками финансирования для стартапов могут быть основатели успешных стартапов, поскольку они также могут помочь советом. Тогда казалось, что все слушатели выжидающе смотрят на меня. В ужасе от перспективы, что мой почтовый ящик будет завален бизнес-планами (если бы я только знал), я выпалил: Но только не я! и продолжил доклад. Но потом мне пришло в голову, что стоит перестать откладывать это дело и стать бизнес-ангелом. Я хотел заняться этим еще во времена нашей сделки с Yahoo, с тех пор прошло 7 лет, а я не сделал ни одной инвестиции.

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

Когда мы с Джессикой шли домой после ужина 11 марта на углу улиц Гарден и Уокер, эти три нити сошлись. К черту венчурных инвесторов, которые так долго принимали решение. Мы решили открыть собственную инвестиционную фирму и воплотить в жизнь идеи, о которых говорили. Я профинансировал бы эту компанию, а Джессика могла бы уйти со своей работы и начать работать с нами, а Роберт и Тревор стали бы нашими партнерами. [13]

Незнание снова сработало в нашу пользу. Мы понятия не имели как быть бизнес-ангелами, а в 2005 еще не было Рона Конвея, у которого можно было бы учиться. Мы просто сделали очевидный выбор, а некоторые из наших решений оказались новыми.

YCombinator состоит из нескольких компонентов, и мы не сразу сформулировали их все. В первую очередь мы стали фирмой-ангелом. Тогда эти два слова не стыковались. Тогда были венчурные фирмы, чья работа заключалась исключительно в инвестировании, но они делали только крупные инвестиции в миллионы долларов. И были ангелы, которые делали небольшие инвестиции, но это были люди, которые обычно были сосредоточены на других вещах и инвестировали на стороне. Никто из них не мог достаточно помогать основателям в начале пути. Мы знали, насколько беспомощными могут быть основатели, потому что помнили как сами были беспомощны. Например, Джулиан в свое время сделал то, что казалось нам волшебством основал компанию. Мы прекрасно писали ПО, а законное оформление, акции и прочее что это вообще такое? Мы собирались заниматься не просто посевными инвестициями, мы хотели делать все то, что Джулиан сделал для нас.

YC изначально не был фондом. Компания была не слишком затратной, так что мы финансировали ее собственными средствами. У 99% читателей это вопросов не вызовет, а профессиональные инвесторы подумали Вау, значит они забрали себе всю прибыль. Опять же, это произошло не из-за проницательности с нашей стороны. Мы не знали как устроены венчурные фирмы. Нам никогда и в голову не приходило собрать фонд, а если бы пришло, то мы бы не знали с чего начать. [14]

Главная отличительная черта YC это пакетная модель, Мы финансировали сразу несколько стартапов два раза в год, а затем три месяца пытались интенсивно им помогать. Это получилось не только неявно, но и явно из-за того, что мы мало знали об инвестировании. Нам нужно было получить опыт. Мы подумали что может быть лучше, чем финансировать сразу несколько стартапов? Мы знали, что летом студенты получают временную работу в технологических компаниях. Почему бы не организовать летнюю программу, где вместо этого запускали бы стартапы? Мы не чувствовали себя виноватыми в том, что в некотором смысле являемся фальшивыми инвесторами, поскольку они в том же смысле являлись фальшивыми основателями. Вероятно, нам не предстояло заработать на этом много денег, но мы могли попрактиковаться в инвестициях, а ребята, с которыми мы будем работать, проведут лето интереснее, чем работая в Microsoft.

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

Мы знали, что студенты решают вопрос о летней работе за считанные дни, так что мы придумали летнюю программу для основателей. Я разместил объявление о ней на своем сайте и приглашал студентов подавать заявки. Я никогда не думал, что написание эссе позволит создать поток сделок, как это делают инвесторы, но все сработало. [15] В итоге мы получили 225 заявок на участие в Летней программе для основателей и обнаружили, что многие из подавших заявки либо закончили учебу, либо вот-вот заканчивали. Вся эта история с летней программой стала казаться более серьезной, чем мы предполагали.

Мы пригласили 20 из 225 групп на очные собеседования, и в 8 из них мы решили инвестировать. Это была впечатляющая группа. В первый поток вошли Reddit, Джастин Кан и Эммет Шир, которые впоследствии основали Twitch, Аарон Шварц, который уже помог написать спецификацию RSS и через несколько лет станет мучеником за открытый доступ, и Сэм Альтман, который позже стал вторым президентом YC. Не думаю, что первый поток был хорош только благодаря удаче. Нужно было проявить смелость, чтобы записаться на такую программу вместо работы в солидном месте вроде Microsoft или Goldman Sachs.

Сделка для стартапов была основана на сочетании сделки, которую мы заключили с Джулианом (10 тысяч долларов за 10%), и того, что, по словам Роберта, получили аспиранты Массачусетского технологического института на лето (6 тысяч долларов). Мы инвестировали 6 тысяч долларов на основателя, что в среднем означало 12 тысяч в обмен на 6%. Это должно было быть справедливо, потому что это вдвое лучше сделки, которую мы заключили в свое время. Плюс то лето действительно жарким, и Джессика организовала основателям бесплатные кондиционеры. [16]

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

С ростом YC мы начали замечать и другие преимущества роста. Выпускники стали сплоченным сообществом, они стремились помогать друг другу и стартапам в нынешних группах, потому что помнили каково было им самим. Мы также заметили, что стартапы становились клиентами друг друга. Раньше мы в шутку говорили о ВВП YCombinator, но теперь в этом все меньше и меньше шутки. Теперь многие стартапы получают первых клиентов среди своих товарищей по группе.

Изначально я не планировал делать YC своей основной и полноценной работой. Я собирался заниматься тремя вещами: писать код, писать эссе и работать в YC. По мере роста YC, я все больше вовлекался в его дела, и в итоге он стал отнимать больше трети моего внимания. Но первые несколько лет я мог спокойно заниматься другими делами.

Летом 2006 года мы с Робертом начали работу над новой версией ARC. Она была довольно быстрой, поскольку компилировалась в Scheme. Чтобы проверить работоспособность этого языка, я написал на нем Hacker News. Изначально это должен был быть агрегатор новостей для основателей стартапов, он назывался Startup News, но уже через несколько месяцев я устал читать исключительно о стартапах. К тому же, мы не хотели обращаться к основателям стартапов. Мы хотели достучаться до будущих основателей. Так что я изменил название на Hacker News, а темой могло стать все, что интересовало интеллектуальное любопытство.

NH, безусловно, был полезен для YC, но он стал большим источником стресса для меня. Если бы мне нужно было только выбирать основателей и помогать им, жизнь была бы очень легкой, Но это значило бы, что HN был ошибкой. В то время я был похож на человека, испытывающего боль во время марафона не из-за усталости и напряжения, а из-за волдыря от неподходящей обуви. Когда я сталкивался с неотложными проблемами во времена работы с YC, они с вероятностью 60% относились к HN и 40%, что ко всему остальному вместе взятому. [17]

Помимо HN, я написал все внутренне ПО для YC на Arc. Но пока я продолжал писать на Arc, я постепенно перестал работать над самим языком. Отчасти из-за нехватки времени, а отчасти из-за того, что от него зависела инфраструктура. Так что теперь у меня было два проекта: эссе и YC.

YC не был похож на работу, которой я занимался раньше. Я больше не мог выбирать над чем работать, проблемы сами приходили ко мне. Каждые 6 месяцев появлялась новая партия стартапов, и их проблемы (какими бы они ни были) становились нашими. Это было увлекательно, поскольку их задачи были разнообразны, а хорошие основатели были очень продуктивны. Если бы вы хотели узнать о стартапах как можно больше в сжатые сроки, то способа лучше просто нет.

Были и части работы, которые мне не нравились. Споры между соучредителями, попытки выявить ложь, борьба с людьми, грубо обращающихся со стартапами и так далее. Но я много работал и над тем, что мне не нравилось. Мне преследовала мысль Кевина Хейла: Никто не работает больше, чем начальник. Это была и описательная мысль, и предписание, и меня пугала вторая ее сущность. Я хотел, чтобы YC был успешен, а если то, как я работаю, описывает верхнюю планку работы всех остальных, то мне лучше работать очень усердно.

Однажды в 2010 году в Калифорнию приезжал Роберт Моррис, и он сделал нечто удивительное дал мне непрошеный совет. Я такое от него помню лишь однажды. Однажды в Viaweb я согнулся пополам из-за камня в почке, и Роберт решил, что ему стоит отвезти меня в больницу. Именно такие поводы нужны были Роберту для того, чтобы дать непрошеный совет. Так что я очень хорошо запомнил его слова: Знаешь, ты должен убедиться, что YCombinator не последнее твое крутое дело.

Тогда я не понимал что он имел в виду, но скоро до меня дошло, что он советует мне уйти. Этот совет казался странным, поскольку у YC все шло отлично. Если что-то и случалось реже, чем непрошенные советы от Роберта, то это его ошибки. Это заставило меня задуматься. Действительно, на той траектории YC стал бы последним моим делом, потому что он сам отнимал очень много моего внимания. Он уже поглотил Arc и начал поглощать эссе. Либо YC должен был стать делом моей жизни, либо мне нужно было уйти. И я решился.

Летом 2012 года у моей мамы случился инсульт, причиной которого стал тромб, вызванныф раком прямой кишки. Инсульт уничтожил ее равновесие и мы поместили ее в дом престарелых, но она хотела выбраться из него и вернуться домой. Мы с сестрой были полны решимости помочь ей в этом. Я часто летал в Орегон, чтобы навестить маму, и на этих рейсах у меня было много времени для размышлений. На одном из них я понял, что готов передать YC кому-то другому.

Я спросил Джессику не хочет ли она стать президентом, но она отказалась, так что мы решили нанять Сэма Альтмана. Мы поговорили с Робертом и Тревором и договорились о полной смене караула. До этого момента YC контролировался LLC, основанным нами вчетвером. Мы хотели, чтобы YC жил долго, а значит нельзя было отдать управление основателям. Так что если Сэм согласится, то мы дали бы ему возможность реорганизовать YC. Мы с Робертом ушли бы на пенсию, А Джессика и Тревор стали обычными партнерами.

Когда мы спросили Сэма хочет ли он стать президентом YC, он сперва ответил отрицательно. Ох хотел запустить стартап по производству ядерных реакторов. Я продолжал настаивать, и в октябре 2013 он наконец согласился. Мы решили, что он возьмет на себя управление, начиная с потока зимы 2014 года. До конца 2013 года я передавал Сэму все больше полномочий отчасти, чтобы он мог освоить эту работу, а отчасти, потому что я был сосредоточен на своей матери, у которой вернулся рак.

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

Я продолжал работать в YC до марта, чтобы помочь стартапам добраться до демо-дня, а затем проверял результаты (я все еще общаюсь с выпускниками и новичками, работающими над тем, что меня интересует, но на это уходит всего несколько часов в неделю).

Что мне делать дальше? В совете Роберта ничего об этом не говорилось. Я хотел заняться чем-то другим, так что вернулся к рисованию. Я хотел увидеть чего смогу добиться, если сосредоточусь на этом. Итак, на следующий день, после ухода из YC, я начал рисовать. Я был не в форме и мне потребовалось время, чтобы ее вернуть, но это было увлекательно. [18]

Большую часть 2014 года я провел за рисованием. Мне никогда не удавалось работать так непрерывно, и я должен был стать лучше, чем раньше. Я был не слишком крут, но все же лучше. Затем в ноябре, прямо посреди работы над картиной, я выдохся. До этого момента мне всегда было интересно увидеть какой получится картина, над которой я работал, но внезапно завершение этой показалось мне рутинной работой. Я перестал работать над этой картиной, почистил кисти, и больше этим не занимался по крайней мере, пока.

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

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

Отличительная черта Лиспа заключается в том, что его ядро это интерпретатор языка, написанный на нем самом. Изначально он не задумывался как язык программирования в привычном понимании. Он должен был быть формальной моделью вычислений, альтернативой машине Тьюринга. Если вы хотите написать интерпретатор для языка, какой минимальный набор предопределенных операторов вам нужен? Лисп, который изобрел (или, вернее, открыл) Джон Маккарти, является ответом на этот вопрос. [19]

Маккарти не понимал, что этот Лисп можно было использовать для программирования на компьютерах, пока это не предложил его студент Стив Рассел. Рассел перевел интерпретатор Маккарти на машинный язык IBM 1704, и с этого момента Лисп стал языком программирования в привычном понимании этого слова. Но его происхождение как модели вычислений придало ему силу и элегантность, с которыми другие языки не могли сравниться. Именно это привлекало меня в колледже, хотя я не понимал почему.

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

Теперь же они достаточно мощны. Вы можете использовать аксиоматический подход Маккарти, пока не определите полноценный язык программирования. И покуда ваши изменения, вносимые в Лисп Маккарти, сохраняют принцип того, что он был открыт, а не изобретен, вы можете создать полноценный язык с этим качеством. Сделать это конечно сложнее, чем говорить, но если это возможно почему не попробовать? Я решил попробовать. На это ушло 4 года, с 26 марта 2015 года по 12 октября 2019. К счастью, у меня была четко определенная цель, иначе трудно было бы этим так долго заниматься.

Я написал новый Лисп, названный Bel, на Arc. Может показаться, что тут есть противоречие, но это показатель того, что мне пришлось прибегнуть к хитрости, чтобы заставить все работать. С помощью ряда уловок, мне удалось написать нечто максимально близкое к работоспособному интерпретатору языка, написанному на этом же языке. Он не слишком быстр, но достаточно быстр для тестов.

Большую часть того времени я запрещал себе писать эссе, иначе я никогда бы не закончил, В конце 2015 года я выделил 3 месяца на написание эссе, и когда я вернулся к работе над Bel, я едва мог понимать код. Не потому, что он был плохо написан, просто программа была запутанной. Когда вы работаете над интерпретатором для языка, написанным на этом же языке, сложно отслеживать что и на каком уровне происходит, ошибки могут быть зашифрованы до момента их получения.

Так что я больше не писал эссе, пока не закончил работу над Bel. В эти годы могло казаться, что я ничего не делаю, хотя я работал больше, чем когда-либо. Иногда после нескольких часов борьбы с жуткими багами я заходил на HN или в Твиттер и видел посты вроде А пол Грэм еще пишет код?

Работа над Bel была сложной, но она приносила удовлетворение. Я работал над ним так интенсивно, что у меня в голове постоянно были куски кода, и я мог писать больше и больше. Я помню как в солнечный день в 2015 году ходил со своими мальчиками на пляж и думал как решить проблему с продолжениями, наблюдая как ребята играют в волнах прибоя. Я помню этот момент, потому что был встревожен его новизной. Хорошо, что в следующие несколько лет у меня было больше таких моментов.

Летом 2016 года мы переехали в Англию. Мы хотели, чтобы наши дети получили опыт проживания в другой стране, а поскольку по рождению я был гражданином Великобритании, этот выбор был очевидным. Мы хотели побыть там всего год, но нам так понравилось, что мы решили остаться. Большая часть Bel была написана в Англии.

Осенью 2019 я закончил работу над Bel. Как и оригинальный Лисп Маккарти, это скорее спецификация, чем реализация, и как и Лисп Маккарти это спецификация, выраженная в коде.

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

Примечания


[1] В моем опыте пользования ПК пропущена одна эпоха: машины с разделением времени и интерактивными ОС. Я перешел от перфокарт сразу к микрокомпьютерам, что сделало последние менее захватывающими.

[2] Значение итальянских слов, обозначающих общие понятия, можно предсказать по их английским аналогам (за исключением ловушек вроде Polluzione). Различаются только повседневные слова. Если вы свяжете какое-то количество общих понятий и простых глаголов, вы сможете немного продвинуться в изучении итальянского.

[3] Я жил на Пьяцце Сан-Феличе 4, так что мои прогулки до Академии проходили по всей старой Флоренции: мимо Питти, через Мост, мимо Орсанмикеле, между Дуомо и Баптистерием, затем по улице Виа Риказоли до площади Сан Марко. Я видел улицы Флоренции в самых разных состояниях: от темных зимних вечеров, когда они были пусты, до жарких летних дней, когда улицы заполнены туристами.

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

[5] Interleaf была одной из многих компаний, у которой были умные люди, которые создавали крутые технологии, но все это было раздавлено законом Мура. В 1990-ые экспоненциальный рост мощности процессоров (например, от Intel) сковал компании, выпускающие специализированное программное и аппаратное обеспечение.

[6] Искатели фирменного стиля из Род-Айлендской школы дизайна не обязательно наемники. Все дорогое становится крутым, а все, что кажется крутым, вскоре станет дорогим.

[7] Технически, аренда у квартиры не контролировалась, а была стабилизирована, но все эти вещи понятны только жителям Нью-Йорка. Суть в том, что она была очень дешевой, ниже половины от рыночной стоимости.

[8] Большую часть ПО можно выпускать после завершения разработки, но если вы работаете над конструктором интернет-магазинов и у вас нет пользователей, то все не так просто. Перед публичным запуском нам пришлось провести частный запуск, то есть набрать ограниченную группу пользователей и убедиться, что они получают приличные магазины.

[9] У нас был редактор кода в Viaweb, который позволял создавать свои собственные стили страниц. Пользовали этого не знали, но под капотом они редактировали выражения на Лиспе. Но это не был редактор приложений, поскольку код запускался при создании сайтов продавцами, а не при их посещении покупателями.

[10] Это был первый пример такого опыта, который позже стал привычным. То же самое произошло, когда я прочитал комментарии и обнаружил там множество разгневанных людей. Как я только мог утверждать, что Лисп лучше других языков? Разве они не были Тьюринг-полны? Люди, которые видят реакции на мои эссе, порой говорят, что им меня жаль. Я не преувеличиваю, когда говорю, что так было с самого начала. Все это приходит с распространением. Эссе рассказывают людям о том, чего они еще не знают, а людям это не нравится.

[11] Конечно, в 90-е люди много чего выкладывали в интернет, но выложить в интернет и опубликовать это разные вещи. Публикация подразумевает, что вы рассматриваете интернет-версию как основную.

[12] Есть один общий урок, который мы извлекли из опыта работы с YCombinator: обычаи будут ограничивать вас долгое время после того, как исчезнут вызвавшие их условия. Когда-то обычные практики венчурных инвестиций, как и приемы написания эссе, были основаны на реальных ограничениях. Запускать стартапы стоило дороже, а потому это происходило редко. Теперь они могли быть дешевыми и распространенными, но обычаи венчурных капиталистов отражали порядки старого мира, так же как обычаи написания эссе по-прежнему отражали обычаи старой эпохи печати.

Все это значит, что люди с независимым мышлением (то есть менее подверженные влиянию обычаев) будут иметь преимущество в быстро меняющихся областях (где обычаи будут с большей вероятностью устаревать);

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

[13] Название YCombinator не было изначальным. Сначала мы назвали компанию Cambridge Seed. Мы хотели избавиться от названия с региональной привязкой на случай, если кто-то из Кремниевой Долины нас скопирует, так что мы переименовали компанию в честь одного из самых классных приемов в лямбда-исчислении: Y-комбинатора.

Я выбрал оранжевый как наш основной цвет, потому что он теплый, и потому что его не использовали другие венчурные фонды. В 2005 все венчурные фонды использовали строгие цвета: темно-бордовый, темно-синий и зеленый, потому что они пытались привлечь внимание ограниченных партнеров, а не основателей. Логотип YC это внутренняя шутка. Логотип Viaweb представлял собой белую букву V в красном круге, так что я логотип YC это белая буква Y в оранжевом квадрате.

[14] Начиная с 2009 года, YC пару лет был фондом, но потом он настолько разросся, что я больше не мог финансировать его самостоятельно. Впрочем, после покупки Heroku, у нас было достаточно денег, чтобы вернуться к самофинансированию.

[15] Мне никогда не нравился термин поток сделок, потому что он подразумевает, что количество новых стартапов в любой момент времени фиксировано. Это ложь, и цель YC опровергнуть это утверждение, помогая основывать стартапы, которых в противном случае не существовало бы.

[16] Джессика рассказывала, что все они были разных форм и размеров, потому что был огромный спрос на кондиционеры, а ей нужно было найти все, что можно было. Все они были тяжелее, чем она могла бы нести на себе.

[17] Еще одна проблема HN странный краевой случай, который возникает, когда вы пишете эссе и ведете форум. Когда вы ведете форум, предполагается, что вы видите если не все беседы вообще, то все беседы с вашим участием. Когда вы пишете эссе, люди постят на форумах весьма вольные и неверные их интерпретации. По отдельности эти явления утомительны, но терпимы, а вместе губительны. На неверные интерпретации нужно реагировать, потому что предположение о том, что вы присутствуете в разговоре, подразумевает отказ от ответа на неверное толкование, ставшее популярным, и означает признание его правильности. С другой стороны, это ободряет: любой, кто захочет сразиться с вами, будет чувствовать, что у него есть шанс.

[18] Самое печальное в уходе из YC было то, что больше мы не работали с Джессикой. Мы работали над YC почти все время, что были знакомы, и мы не пытались и не хотели отделять эту работу от нашей личной жизни. Этот уход был похож на вырывание глубоко укоренившегося дерева.

[19] Один из способов разделить концепции изобретения и открытия поговорить о пришельцах. Любая достаточно развитая инопланетная цивилизация наверняка знает о теореме Пифагора. Верю (хоть и с меньшей уверенностью), что они слышали о Лиспе из статьи Маккарти 1960 года.

Но если это и так, то нет оснований предполагать, что это предел известного им языка. Вероятно, пришельцам будут нужны числа, ошибки и ввод/вывод. Так что существует по меньшей мере один вариант того, что Лисп Маккарти был открытием.

Спасибо Тревору Блэквеллу, Джону Коллисону, Патрику Коллисону, Дэниелу Гаклу, Ральфу Хазеллу, Джессике Ливингстон, Роберту Моррису и Харджу Таггару за чтение черновиков этого текста.



Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы


Подробнее..

Я никогда не научусь верстать и другие мифы о разработке

24.02.2021 14:21:40 | Автор: admin
За 15 лет я успел забыть, что и так можно былоЗа 15 лет я успел забыть, что и так можно было

Могу честно сказать я побаиваюсь CSS. За последние годы он неслабо разросся, но вместе с этим пришла и монструозность (ну то есть чего вы всерьёз не можете сделать на CSS? Машину времени?). Мне сложно смотреть даже на селекторы, а из-за угла уже манят флексы с гридами и говорят псс, не хочешь немного сеток и бессоных ночей?. Больно думать о позиционировании текста на бесконечном холсте, когда всю жизнь расставлял кнопки мышкой на форме.

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

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

Миф 1. Веб-разработка не для меня

У некоторых языков действительно очень высокий порог входа не всегда даже понятно, с чего начать. Вспомнить хотя бы тот прекрасный текст про изучение JavaScript в 2016.

Слушай, это легко. Пиши весь код в TypeScript. Все модули, использующие Fetch компилируй в ES6, транспайль их с Babel с stage-3, и загружай с SystemJS. Если у тебя нет Fetch, используй polyfill, или Bluebird, Request или Axios, и обрабатывай промисы с await.

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

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

Миф 2. Страшно сделать ошибку

Негативный опыт хороший учитель.

Когда мы получаем штраф, хочется исправиться и больше не повторять. Так что можно даже сказать, что чем больше ошибок в начале, тем лучше. Когда я писал свой первый код на Visual Basic, у меня уже был интернет, но я принципиально им не пользовался, потому что неспортивно. Сейчас, конечно, так бы не стал, но кто слушает тридцатилетних себя из будущего в 13 лет?

Миф #24149. Картинки из xkcd делают статью о программировании лучшеМиф #24149. Картинки из xkcd делают статью о программировании лучше

Что делать. Разрешите себе пробовать снова и снова. Что самое страшное может случиться? Ну, зависнет страничка, и придётся перезагрузить компьютер. В крайнем случае переустановите свою Windows 98. Это не сложно, зато можно продолжать попытки.

Миф 3. Ошибка конец света

В начале кажется, что если в коде ошибка, то сломано вообще всё. Обычно это не так. Я хотел бы посчитать, сколько времени потратило человечество на исправление ошибок в один символ в каком-нибудь PHP. Или хотя бы я сам, когда писал сортировки массивов на Паскале. Хотел бы, но не могу.

Что делать. Научиться отлаживать код. Если после добавления какого-то блока, программа сломалась, закомментируйте этот блок. Убедитесь, что дело именно в нём, потом добавляйте его в код по одной строчке и смотрите, что изменилось. Полезные навыки тестирование собственного кода и работа с инструментами разработчика.

Миф 4. Сложно сделать первый проект

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

Что делать. Разберите программу на фичи и составьте список. После этого берите каждую фичу и спрашивайте себя что сделать, чтобы она заработала?. Одно действие одна задача. Когда закончите, можно взять первую задачу в работу и начать потихоньку делать. Не торопитесь лучше разобраться в каждой мелочи, чем потом не понимать, как работает ваш код.

Одна из моих первых наивных попыток разбить что-то на фичи. А потом придумать им стильное названиеОдна из моих первых наивных попыток разбить что-то на фичи. А потом придумать им стильное название

Миф 5. Код можно никому не показывать

Этот миф распространён среди тех, кто представляет себе программистов в виде злобных капюшонистых хакеров в тёмном подвале.

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

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

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

Чтобы было проще, объединяйтесь с другими новичками. Придумайте общий проект и пилите его вместе (а то мы джва года ждём). Вы научитесь командной работе, будете поддерживать друг друга, спорить, обмениваться мнениями. Вместе расти проще, чем в одиночку. А ещё, если не лень, можно скинуться на ревьюера кода, чтобы было выгоднее.

Все мы знаем, зачем нужен GitВсе мы знаем, зачем нужен Git

Миф 6. После курсов платят по 200 тысяч

Этот миф пошёл из рекламы некоторых курсов, но на практике такое практически не случается. 200 тысяч зарплата синьора в большом городе, но никак не джуна после курсов. Можно через годик-другой добраться до 100 тысяч в месяц, но для этого придётся многому научиться. Курсы только одна из ступеней к большой зарплате, и всё зависит от мотивации и желания постоянно развиваться. Это тот случай, когда план развития важнее прочитанной когда-то теории.

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

Миф 7. Невозможно научиться самостоятельно

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

Что делать. Придумайте себе проект и потихоньку сделайте его. Если сложно выбрать, возьмите проблему из внешнего мира: приложение, которое напоминает пить лекарства или ведёт финансы. Если это скучно, напишите игру. Главное, чтобы было интересно решать вот эту конкретную задачу. Тогда вы не бросите проект, даже если будет очень сложно.

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


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

1 марта в HTML Academy начинается очередной марафон по вёрстке. За три недели вы разберётесь в основах HTML и CSS, сверстаете сайт по макету и выложите его в интернет. В программе 28 тренажёров, которые обычно платные, но для участников марафона будут доступны бесплатно. Ещё разыграем одно место на курсе HTML и CSS. Профессиональная вёрстка сайтов.

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

Подробнее..

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

25.02.2021 14:18:30 | Автор: admin

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

Иногда мне приходит в голову, что программирование в силу необходимости навязчивая идея. В наших головах так много деталей я не уверен, что можно, в принципе, программировать без навязчивости. Программирование, как пишет в Smarter Than You Think, требует внимания к деталям и способности думать обо всём как о сериях процессов. Но оно требует не просто какого-то там внимания к деталям, оно требует интенсивного внимания к деталям. Одна шальная точка с запятой может поставить на колени миллионы строк и привести к чудовищному краху. Единственная функция с неврным возвратом сломает всю вашу внимательно прописанную логику. Как такая работа может требовать чего-то кроме навязчивости до такой степени, чтобы забывать пообедать?



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

Когда я ложусь в кровать, я всё так же вижу код. Мне снится код. Функции, классы, управляющие структуры. Иногда утром я просыпаюсь с решением упрямой проблемы, которая решалась в моей голове: я программирую, даже когда сплю!

Тем, кто пишет код, это знакомо. История возникновения Facebook, сколь бы неприятной она ни была, рассказанная в постах Цукерберга и в фильме Социальная сеть, о том, как мужчина провёл ночь над проблемами в коде (понятно, что его задачей было собрать изображения девушек с сайта колледжа, чтобы унизить их, но мы не можем винить в этом PHP). Код часто пишут одержимые.

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

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

Скриптинг скромное определение. Оно останавливает меня от идей выше моего положения. Код это скрипт, которому должен следовать компьютер. Он заставляет компьютер делать вещи, которые можно в теории сделать вручную. Мы можем спросить водителя Uber рядом с нами, где он, и отметить его положение на карте. Приложение Uber с помощью скрипта автоматизирует ручные операции. Даёт компьютеру набор инструкций, чтобы он следовал им, участвовал в качестве точного до буквальности исполнителя. Скрипт описывает процесс, который у человека может занимать часы, но который может быть рассчитан компьютером за миллисекунды.

Я пишу, когда другие едят, из-за того, что можно назвать потоком: я на подъёме, в ударе, на своей волне. Погружён в задачу и поглощён ею. Часы пролетают, превращаясь в строчки кода.

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

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

Торвальдс создатель Linux, основы большинства современных серверов. Торвальдс также написал git, и эта система используется почти всеми инженерами-программистами, чтобы хранить код (обе разработки названы в его честь: первая по фамилии, вторая по натуре). Торвальдс печально известен в технических кругах не только благодаря интеллекту, но и благодаря ругани из-за кода, который ему не нравится. Он наугад выбирает тему из публичных обсуждений и говорит, и говорит, что код дерьмо, самый натуральный мусор и он написан неправильно. Многие разработчики боятся, что Торвальдс как-то получит их код и предложит посмотреть на него. Иногда я задаюсь вопросом, не является ли Торвальдс единственным инженером-программистом, который не страдает синдромом самозванца. Он архетип разговаривающего начистоту (читайте: грубого) программиста, который заявляет, что его интересует только качество кода. Я замечаю людей, пытающихся подражать ему. Это постыдно. Софтверной индустрии не нужны люди, которые дают хорошие советы в дурной манере.

Сегодня я управляю командами. Моя работа составление бюджетов, управление и утверждение, а не объекты, функции и инкапсуляция. Я работаю скорее с PowerPoint, чем с PowerShell. Но уметь программировать значит, уметь говорить на другом языке. Это умение останется с вами. С помощью кода становится возможным то, что не сделаешь руками.

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

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

Когда я начинаю программировать, моя команда стонет: Босс снова взялся за дело кому-то приятно, что я свой. Другие, возможно, радуются, что я понимаю раздражение, преследующее программиста день за днём.

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

Код бросает ошибки, он подвержен авариям, перестаёт работать; делает то, чего я не ожидаю, по причинам, которых я не понимаю. Если я пишу variable вместо Variable, компьютер разводит руками, не понимая, о чём я говорю ему. Хм правда, компьютер? Со всем вашим кремнием, чипами, терафлопсами, неужели вы не можете разобраться?

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

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

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

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

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

image
Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодом HABR, который даст еще +10% скидки на обучение:

Подробнее..

Поваренная книга Quarkus Cookbook, бесплатный Developer Sandbox for OpenShift и руководство CentOS Project

25.02.2021 12:15:55 | Автор: admin

Мы собрали для вас короткий дайджест полезных материалов, найденных нами в сети за последние две недели. Оставайтесь с нами станьте частью DevNation!

Начни новое:

Качай:

  • Бесплатный Developer Sandbox for OpenShift
    Это ваш личный OpenShift в облаке, всего за пару минут и без какой бы то ни было инсталляции. Среда создана специально для разработчиков и включает в себя Helm-диаграммы, builder-образы Red Hat, инструменты сборки s2i, также CodeReady Workspaces, облачную IDE с веб-интерфейсом.

Мероприятия:

Подробнее..

Люди как новая нефть ОАЭ готовы предоставить гражданство иностранцам

24.02.2021 20:16:16 | Автор: admin

Разговор в автомобиле на трассе из Дубая в Шарджу 31 июля 2020 года:

- Город-стройка. Сколько всего возводят Но для кого? Кто будет здесь жить? Тем более после такого кризиса. Дубай экспо переносят, резиденты покидают страну, многие потеряли работу или бизнес: даже авиакомпания Эмирейтс сократила тысячи сотрудников, в число которых попал мой друг пилот.

- Почему бы правительству не инициировать создание специальных условий для того, чтобы привлекать сюда самых умных и талантливых специалистов из разных стран мира?! Так и поднимут экономику, грамотно аккумулируя у себя лучшие умы и таланты. Для этого все есть, в том числе тысячи квадратных метров нового жилья. Вот такие люди здесь бы и жили, а виды строительных кранов выглядели бы повеселее на фоне пустыни.

Заголовок в новостях 31 января 2021 года, ровно спустя семь месяцев:

ОАЭ впервые в истории предоставляет иностранцам право получить гражданство.

Эмираты, и особенно Дубай, в течение длительного периода времени стремились сократить зависимость от нефти, используя другие стимулы для экономического роста страны. И вот теперь претендовать на эмиратский паспорт могут инвесторы, изобретатели, ученые, художники, врачи и их семьи.

При этом необязательно отказываться от имеющегося гражданства: в ОАЭ допускается иметь двойное.

Для каждой категории продуманы определенные требования:

1. Инвесторы обязаны владеть на территории ОАЭ недвижимостью; или получить как минимум один патент, который будет одобрен Министерством экономики.

2. Врачи, инженеры и другие квалифицированные специалисты должны работать в сферах, в которых заинтересованы ОАЭ; вносить свой вклад в исследования, имеющие научную ценность, а также иметь опыт работы по специальности от десяти лет.

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

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

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

Население ОАЭ более чем на 80% состоит из иностранцев-резидентов: страна привлекательна для жизни, работы, ведения бизнеса и отдыха одновременно. В ОАЭ готовы высоко ценить талантливых людей, обеспечивать им стабильность и большие перспективы в будущем.

Обращений, заинтересованных в получении эмиратского паспорта, ждут в Federal Authority for Identity and Citizenship

http://ica.gov.ae/

https://u.ae/en#/

Контактный телефон +971 600 522222

Если вы обнаружили себя в тех категориях, которые могут претендовать на гражданство ОАЭ или не уверены в этом до конца, рекомендую составить подробное письмо, уточнить интересующие вопросы: что требуется в вашем конкретном случае.

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

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

Подробнее..

Советы начинающему GameDeveloperу

24.02.2021 00:19:22 | Автор: admin

Недавно довелось заниматься поисками джуна на позицию Unity Developerа. В процессе, выяснилось, что у большинства кандидатов плюс-минус одни и те же пробелы в знаниях. Дабы каждому не накидывать одни и те же сообщения срекомендациями, возникла идея данного поста.

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

Ресурсы, популяризирующие GameDev

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

Книги

Фильмы

Youtube-каналы

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

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

В целом, данного конфига мне хватает, пробовал вариант с бОльшим количеством каналов, но тогда количество дублирующей информации просто зашкаливает (хотя те же самые XYZ и DTF часто ссылаются на GDC)

Ресурсы по геймдизайну

Книги

Youtube-каналы

Ресурсы по разработке

Книги

Дельных книг по Unity не встречал, да и смысла в них особого не вижу, поскольку, Unity очень быстро развивается и информация в книгах успевает устаревать с выходом каждой последующей версии Unity. Лучшего ресурса, чем Unity Learn, думаю не найти - присутствует хорошее разделение по уровням знаний и темам

Youtube-каналы

Unity-сообщества

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

Советы

  • Наличие GitHub аккаунта повышает вероятность положительного ответа, главное не забывать подробно расписывать README-файл.

  • Неплохо бы иметь аккаунт на итче, в идеале, чтобы как раз GitHub вел на итч: так можно будет потрогать игру ничего не скачивая и не собирая (делайте web-билды).

  • Также приветствуется наличие выпущенных тайтлов в сторы.

  • Не лишним будет участие во всевозможных хакатонах/гейм-джемах (хорошая возможность познакомится с единомышленниками и положить проект в копилочку).

  • Геймдев-встречи в Random Coffee - отличный способ узнать много нового, а главное побороть страх общения с незнакомыми людьми.

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

  • Старайтесь не делать однотипные проекты - у каждого второго в портфолио игра астероиды и код Ctrl-C, Ctrl-V под копирку (к вопросу про курсы выше).

Надеюсь, данная статья принесла вам пользу, планирую дополнять ее по мере поступления новой информации. Если зайдет, то возможно будет пост посвященный вопросам собеседования на позицию Unity-джуна.

Ну и самое главное - любите игры

Подробнее..

Я в прямом эфире, но я не кот 3 самые большие ошибки презентаций в Zoom

19.02.2021 22:06:58 | Автор: admin

Возможно, что мы наконец (наконец!) начинаем видеть крохотный лучик света в конце тёмного тоннеля этой затяжной утомительной пандемии. Но увы, это совсем не говорит о том, что приближается конец эпохи презентаций и переговоров в Zoom.

В 2010 году Билл Гейтс правильно предсказал, что нас всех ждёт пандемия.

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

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

Это делает недавний пост Брайары Голдберг коуча по подготовке спикеров, выступающих на конференциях TED бесценным. В нём она описывает наиболее распространённые ошибки, которые она всё ещё наблюдает, когда люди выступают в Zoom, и предлагает простые и полезные советы, чтобы исправить их.

Первая ошибка: вы смотрите на собеседников, а не в камеру

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

Единственный способ установить зрительный контакт с вашими виртуальными слушателями это смотреть прямо в объектив вашей камеры. Поверьте мне: поначалу это будет действительно странно. соглашается Голдберг, - но если хотите, чтобы ваша аудитория оставалась внимательной и вовлечённой, вам придётся пожертвовать своим желанием посмотреть на их лица.

Стремитесь смотреть на этот маленький кружок в верхней части вашего ноутбука (или в другое место, смотря, где в вашем устройстве находится объектив) в течение полных 90% времени вашей презентации.

Вторая ошибка: вы либо читаете прямо с экрана, либо импровизируете

Когда дело доходит до презентаций и подготовке к ним, вы стремитесь найти компромисс: вы не хотите записывать всё и читать как робот, но вы также не хотите спотыкаться на каждом слове, сопровождая звуками гм и ах весь свой материал. Уважайте время своей аудитории, практикуясь немного заранее, советует Голдберг.

То, что вы можете превратить свой ноутбук в телесуфлёр, совсем не означает, что вы должны это делать, - подчёркивает она.

Третья ошибка: вы позволяете всем выключать видео

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

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

Не воспринимают вас серьезно? - Обернитесь!

Среди безумных месяцев заточения в онлайне, связанных с коронавирусом, я нашла светлый лучик в Twitter - Room Rater. Если вы еще не знакомы с этим веселым аккаунтом, то поясню: там оценивается обстановка за различными спикерами по шкале от 1 до 10. Естественно, эти оценки сопровождаются едкими замечаниями и советами по улучшению.

Какой в этом всём смысл? Может нужно быть более продуктивным и перестать отвлекаться на бессмысленные (хоть и забавные) твиты?

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

Эстетика видеозвонка имеет огромное значение

В недавнем обзоре на Harvard Business Review соучредитель фирмы Ноа Зандан и директор по взаимодействию Хэлли Линч объясняют, что ровно как и наш внешний вид, так и фон во время видеоконференций имеют огромное значение. Опрос 500 профессионалов, использующих удаленный формат работы, по поводу эстетики видеозвонков дал неожиданные результаты - респонденты имеют твёрдые убеждения на этот счёт.

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

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

Единственным исключением были только те случаи, где спикеру нужно было передать своё творчество. Здесь можно использовать свой естественный декор комнаты, но даже в этом случае следует избегать виртуального фона.

По всем исследуемым направлениям виртуальные фоны набрали в среднем всего 7,5% голосов, что говорит о том, что их следует сохранить до следующего виртуального свидания, а не для следующей рабочей встречи, - заключает пост.

Мы в ITSOFT были за прямолинейность, открытость и против "официоза" еще до пандемии. На встречах не требовался особый стиль или дресс-код, а сами они могли проходить за пределами переговорок: в парке или кафе. Потому при переходе на удаленку никто не использовал фоны, фильтры или белые стены в Zoom, ведь можно быть собой и никто не осудит.

Заключение

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

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

Подробнее..

Смена профессии. Путь из никуда в QA

22.02.2021 16:14:10 | Автор: admin

Когда пора увольняться

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

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

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

Принимаем решение

Ok, наверное надо что-то менять, найти новую работу и уйти со старой. Но как решиться, если одолевают сомнения, а перемены вызывают не очень приятные чувства?

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

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

Условия созданы, начинай действовать - работай, учись, ищи. Не бойся удлиннить свой путь, разбить на этапы; достигай промежуточных выгод. Ошибки быть не может, ты бьешь точно в цель, получаешь выгоды уже в процессе. Теперь уже и решаться не надо.
Когда будешь готов, уходи.

Первые шаги

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

Нам понадобится:

  1. Определить цель. Зачем это всё. Куда хотим прийти, в какую сторону расти и как развиваться.

  2. План составить, сроки определить. Время на всё это дело заложить.

  3. Начать учиться. Можно самостоятельно, можно где-то или с кем-то, тут кто как больше любит.

  4. Вступить в профессиональные сообщества. Общаться, задавать вопросы, интересоваться.

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

  6. Готовить резюме. Тут с ходу не разберёшься - постепенно корректируя детали, добавляя полезное, удаляя лишнее, доводить до совершенства.

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

Цель

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

А дальше, целеполагание.

- Какую проблему ты решаешь?
- Почему ты хочешь решить проблему таким способом?
- Сколько часов в день ты готов выделять?
- Когда решится проблема?

Ну хорошо, проблема решилась, зарплата выше, коллектив хороший, работа удалённая и развиваться дают.
А куда развиваться?
Зачем всё это?
Может менеджером стать или в код погрузиться. Стартап запустить.
Может эмигрировать?
Чего ты хочешь достичь через год? Два года? Пять лет? Десять? Надо знать. Сразу.

И подчинить главной цели все остальные.
Тогда сразу понятно будет зачем всё. И вопроса такого не встанет. Любое событие, любое действие или отдаляет от цели или приближает к ней.
Наметь дату. Определи критерии. Составь план. И вот уже цель стала ближе. Осталось немного.

План

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

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

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

Обучение

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

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

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

Ты вступил в профессиональные сообщества, выполняешь практические задания, берёшь учебные проекты, анализируешь рынок, уже можешь поспорить с кем-то из твоей будущей сферы деятельности. Готов ли ты сейчас? Рано ещё.

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

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

Нет предела ступеням мастерства.
Но нужно начать идти.

Сообщества

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

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

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

Подготовил резюме? Даже отправил в пару мест? Никто не зовёт? Проблема.

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

Резюме

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

Зачем вообще нужно резюме?
Оно должно продавать. Тебя должны звать на интервью, если же нет - всё плохо, как бы ты не оправдывался, если собеседований нет - твоё резюме пробило дно.

Что делать?

1. Формат
Красивое оригинальное оформление поможет поможет, если ты хочешь быть например дизайнером - тебя как раз не позовут в тестирование и придётся поискать что-то ещё. Если всё таки в QA - делай нормальное консервативное резюме формата самых больших площадок вакансий.

2. Фотка.
Выбери нормальную фотку, без комментариев.

3. Позиция.
Как тебя будут искать, так ты и должен писать название искомой должности. И не надо писать, что ты Junior, это я как работодатель там сам разберусь. Ты - специалист.

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

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

6. Обо мне.
Напиши почему ты здесь. Напиши почему именно ты. Напиши так, что бы я поверил.

И теперь открой своё резюме всем. Обновляй каждый день. Откликайся на всё. Рассылай всем. Каждый день.

Интервью

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

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

Не про тебя? Рассылаешь резюме со скоростью 100 штук в секунду? Интервью распланированы на недели вперед? Супер!
Получил отказ, второй, третий, пятый? Превосходно. Ты всё ближе к заветной работе!

Ты грамотно планируешь время собеседований, готовишься к каждому, узнаешь про компанию, у тебя появляются вопросы.
Ты внимательно слушаешь на интервью, записываешь, что спрашивают. Ты вообще, всегда всё записываешь.
Снова отказ? Грустно? Нет конечно. Это твой звездный час, ты теперь точно знаешь, что делать! Что ещё учить, какие вопросы задавать, какие задачи решать, о чем говорить.

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

И вот тебе сделали оффер. Ты же этого хотел?
Тогда начни уже ходить на собеседования.

Страхи

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

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

Это сложная работа, надо быть очень умным, ты не сможешь. Ты там будешь лишним. Может, если будешь долго и усиленно учиться - возможно, но когда? Столько дел.

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

У тебя никогда ничего не получится.

День за днём, снова и снова всё это опровергают люди, успешно прошедшие собеседование на позицию Junior Tester, люди, получившие предложение о работе в IT компании, которые с драйвом рассказывают теперь о своих трудовых буднях.

У них были те же сомнения, такие же страхи, похожие проблемы, как у тебя.
Они смогли, сможешь и ты.

Каждый, кто захотел, каждый, кто начал идти, кто проделал работу, каждый кто освоил, кто получил оффер - каждый достоин.

Ты не можешь только одно.
Ты не можешь не идти по пути.
Так иди же!

Подробнее..

Parallels это не только Windows на Мас

25.02.2021 00:07:45 | Автор: admin

В последний раз мы беседовали с Николаем Добровольским, сооснователем и старшим вице-президентом Parallels, ровно два года назад. С тех пор, компания успела стать частью Corel, приятно порадовать пользователей версией Parallels Desktop 16 для Apple M1 и Chromebook-ов, а еще вместе со всей страной отправиться почти на год в режим удаленки. Что нового в бизнесе и какие планы у команды на ближайшее время в интервью под катом.


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

З.. Кстати, список открытых вакансий в Parallels доступен здесь.
Подробнее..

Стоит ли инженерной команде с продуктовыми амбициями заниматься аутсорсингом?

25.02.2021 12:15:55 | Автор: admin
Делегируйте и доверяйте инженерам, не мешайте им творить!Делегируйте и доверяйте инженерам, не мешайте им творить!

Если бы я основатель дизайн-центра электроники Promwad начинал свой бизнес сейчас, то не выбрал бы аутсорсинговую бизнес-модель. Это не значит, что всем командам с продуктовыми амбициями нужно обходить ее стороной. Временная работа в таком формате может стать отличным инструментом для достижения своих целей. Важно только действовать осознанно и понимать, как это работает.

Когда я только начинал работать в отрасли электроники в начале 2000-х и мечтал создавать серийные устройства на острие технологий, то мог рассчитывать только на собственные ресурсы. Не было доступа к западным рынкам свободного капитала, менторов, хабов и акселераторов всего того, что сейчас формирует hardware-экосистему, да и доступ в интернет в те времена только недавно заработал без Dial-Up :-).

Самым логичным выходом из ситуации для меня было такое решение: разрабатывать и производить устройства на заказ, работая с клиентами, у которых был бюджет и конкретные требования к решению для целевого рынка. Так мои амбиции по созданию собственного продукта трансформировались в работу по сервисной модели вместе с инженерной командой Promwad. Хотя на самом старте мы создали аппаратную платформу на базе новейшего процессора по тем временам, но все равно это не было полноценным продуктом. Где-то в далеком видении я отмечал про себя, что когда мы научимся круто разрабатывать, а затем производить серийную электронику, можно будет использовать эти навыки для трансформации в продуктовую бизнес-модель. Но это оказалось не совсем так

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

Конечно, есть бизнесмены, которые осознанно запускают аутсорсинговые компании: они с самого начала мыслят категориями роста и операционной эффективности, относительно быстро преодолевают планку в 200500 сотрудников и выходят на новые рынки. В этом состоит их цель и самореализация. Но есть и те, кого просто занесло в эту гавань в силу обстоятельств: обычно такие компании работают в составе 50200 сотрудников с несколькими миллионами оборота и годами остаются на этом плато.

На менторских сессиях я вижу, как молодые инженерные команды, которые искренне любят свое дело и хотят работать над собственным продуктом, вынуждены зарабатывать на работе по контракту. Они сомневаются, стоит ли им браться за заказные разработки, не станет ли это отказом от мечты. Но надо сделать свой выбор!

Этапы развития сервисной модели и точки для разворота

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

Так когда надо сворачивать?!

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

  • Предпринимательская: главный по продажам, главный конструктор/инженер/архитектор.

  • Административная роль: главный по проектам, главный по операционной работе.

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

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

То, что я имею в виду под ролями, очень похоже на то, о чем пишет в своих работах Ицхак Адизес. Вот его код PAEI: P производитель результатов, A администратор, E предприниматель, I интегратор.

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

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

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

На этом этапе свернуть обратно к продуктовой модели будет почти нереально без трансформации всего бизнеса.

Что делать?

В случае когда пройден третий этап, вместо разворота разумнее сохранить компанию в неизменном формате и сделать следующее:

  1. Передать управление и предпринимательскую роль кому-то из своих партнеров внутри и позволить им свободно принимать ключевые решения вместо вас.

  2. Очертить свою новую роль в компании. Например: я остаюсь в качестве владельца и обозначаю стратегический вектор развития компании.

  3. Переключиться на продуктовую модель в рамках новой компании, опираясь на весь свой накопленный опыт и хватать за хвост новые идеи. :-)

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

Выводы: триггеры на пути к мечте и что дает аутсорсинг

Вернемся к тем, кто только стартовал, и для создания своего первого капитала и приобретения бизнес-опыта вступил на путь сервисной бизнес-модели. Итак, если вы только начинаете и готовы преодолевать препятствия на пути к своей продуктовой цели, то вполне можно посвятить 1-2-3 года работе по сервисной модели, но помнить о риске застрять в этой модели надолго и обращать внимание на важные триггеры, которые подскажут, что пора поворачивать к своей мечте:

  1. Собралась крепкая команда профессионалов из 1020 сотрудников с высоким уровнем доверия друг к другу. Соответственно, дальнейший рост в текущей бизнес-модели будет только усложнять разворот к продуктовой модели.

  2. Роли стали трансформироваться в функции и должности в компании это знак того, что нужно переключаться на продуктовую модель либо целенаправленно сохранять аутсорсинговую компанию.

  3. Третий триггер, наверное, самый главный удовольствие от своего дела. Если нет драйва и вы не видите смысла в росте и масштабировании, то есть риск остаться в нише середняков в аутсорсинговой модели в будущем.

А тем основателям и владельцам, у кого аутсорсинговая компания надолго застряла на плато в 50200 человек, пора задуматься: Своим ли делом вы занимаетесь?

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

  • получить нужные компетенции, первый бизнес-опыт и знания об отрасли;

  • собрать и сработаться с командой;

  • развить свой нетворк сеть бизнес-контактов.

Выбор как всегда за нами! А вы в какой лиге сейчас? Давайте вместе решим, что делать дальше!

Подробнее..

Воспоминания бумера Америка в эпоху дот-комов

19.02.2021 14:12:20 | Автор: admin

Прилет

В начале марта 2000 года я ступил на американскую землю.

Вышло это очень дорого, так как виза стоила в те времена 500 долларов. Напоминаю, что дело было вскоре после 1998 года, когда рубль упал в три раза. А мне надо было еще оплатить еще и визы жене и сыну, которые прилетели позже, когда я уже снял квартиру.

В Бостоне меня встретили мои два работодателя, которые оказались бывшими русскими. Интервью по телефону я проходил по-английски, а акцентов еще не чувствовал, так что я даже не подозревал, что они прекрасно говорят по-русски. У них в фирме я оказался employee N1 (я немного напрягся), а сама фирма была классическим бодишопом. Впрочем, меня поселили бесплатно в квартиру к их знакомому, где я ждал SSN и проходил интервью по телефону.

С житейской точки зрения у меня было все хорошо - на первоначальном bench мне не платили, но жил я бесплатно. Тем временем на форуме privet.com ходили жуткие рассказы про ужасную фирму GLOBAL. GLOBAL массово завозила народ и поселяла программистов в некоем здании. Там новички должны были все время заниматься языком и IT. Их кормили и сверх всего давали одно яблоко и один апельсин - в день или в неделю, не помню. Также у них было право на один телефонный звонок в неделю домой (IP телефония только начиналась и звонили по специальным картам).

Культурный шок

Те, кто прилетал в Америку из СССР, испытывали шок от обилия видов колбасы и клубники, которая появлялась в пять утра (но как позже выяснилось, не имела ни вкуса, ни запаха). Современный мир так глобализован, что нашего брата айтишника особо не удивляет ничего по большому счету: конечно, всегда что есть рассказать по быту и бюрократии, но господа, это ни в какое сравнение не идет с впечатлениями эммигранта из СССР от магазина - им казалось, что они попали в рай!

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

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

Однако:

Сейчас, впрочем, все вернулась снова к этому состоянию у нас и во всем мире.

При поиске апартмента в одном из мест, которые я смотрел, менеджер, женщина лет 50 извинилась, что она всего не знает, так как работает первый день - переехала из Флориды. Позже я спросил знакомую шефа, которая тогда была со мной - "надо же, под конец жизни переехала в другой штат". Не забуду круглые глаза этой знакомой: "Что??? Какое - под конец жизни? ей 50!"

Очень мне понравилось кабельное телевидение. Тогда в России не было столько каналов. Было много милых передач, но только в Америке я впервые увидел серии StarTrek, Buffy, и даже Симсонов. В России смотрели боевички, и все сильно многосерийное не укладывалось в формат видеокассет и видеосалонов. То, что в телевизоре были субтитры, мне очень помогало на первых порах.

Позже мой босс сказал мне выбрать машину, обязательно новую. Я зашел на сайты дилеров в интернете и попал в ступор. Машины я любил, но в России тогда не было дилеров вообще - выбор машины для покупки - это поездка на рынок у Энергетиков, где можно выбирать из того что есть, прогуливаясь по заставленным пригнанными машинами парковкам. Вспомнилось самое гениальное, 21 путешествие Йона Тихого: "на смену ужасу былых ограничений пришел ужас остсутствия каких либо ограничений".

Впрочем, оказалось чуть позже, выбора у меня и не было - босс просто сдал меня первому дилеру, который согласился дать машину в лиз человеку без кредитной истории. Машиной была VM Jetta, по нашему - Bora. Мой выбор был только в том, чтобы взять ее с механикой. Это очень помогло моей жене - при сдаче на права коп простил ей все за то, что она сдает на механике - и трогание с третьей передачи, и проезд на красный свет. "Теория" же не была проблемой вовсе - из 20 вопросов надо было правильно ответить на 13. Вопросы примерно такие:

От чего зависит степень опъянения?

  1. От города

  2. От времени суток

  3. От количества выпитого

  4. От марки машины

Показать правильный ответ

Вы серьезно?

Первый контракт

Он был в Janesville, WI. Все - отель, еда, рент машины оплачивалось работодателем. Но вначале, приземлившись в аэропорту Madison, WI и рентанув на российские права машину, я отправился искать фирму, где я должен работать. Город найти было тривиально по бумажной карте, а вот где находится большое здание фирмы я намеревался спросить у прохожих - навигаторов не было. Да, сейчас. Прохожих я не обнаружил. Вообще.

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

Кстати, об аэропортах. В те благословенные времена, до 9/11, аэропорты были почти как автобусные остановки - особенно в маленьких городах. Чуть позже, когда уже прилетела жена с ребенком, я перепутал и приехал в грузовой аэропорт Springfield вместо пассажирского. Пока разбирался в ситуации, время шло, мы отчаянно опаздывали и появились на парковке за 20 минут до вылета. на посадку мы пришли за 10 минут до вылета - и еще имели наглость купить выпечки и соков в самолет!

Ночь в лесу

Контракт подходил к концу, и мне надо было искать апартмент под Бостоном. Перелет туда и обратно оплачивал работодатель. Вернувшись на последние 2 недели в WI, я был должен взять такси и проехать 50 миль в Janesville в отель. (общественного транспорта нет, а самолет прилетал в 11 вечера). Утром я был должен взять такси и ехать к 7 утра назад в Rent-a-car в Madison, рентануть машину и ехать снова 50 миль - уже на работу.

Разумеется, когда я прилетел в полночь (самолет немного опоздал), я подумал - нафиг это надо, посплю до 7 утра в кресле. Примостился и заснул. Но проспал я не долго - меня разбудил коп со словами что он закрывает аэропорт. Аэропорт был маленький, и когда я вышел в дверь, он натурально закрыл за мной дверь на ключ.

Ночь. Никого. Сотового телефона нет. Подумаешь! решил я, это даже интересно - приключение. Я решил спать в лесу, расстелив куртку на земле. Больше всего я боялся полицейских, поэтому тщательно проверил, что меня не видно. Мне удалось поспать часов до четырех утра, когда температура опустилась ниже нуля. Я стал все больше замерзать и о сне уже речи не было. К счастью, в 6 утра открыли аэропорт, и я вбежал греться и пить горячий кофе.

Работа в dot-com

По возвращении в Бостон area я стал работать в стартапе Softlock, который продавал PDF. В PDF можно было прочитать перу первых страниц, а заплатив и получив ключ - весь документ. Интересно, что стартап располагался по адресу Maynard, MA вот в этом самом здании старой фабрики:

Да. Когда в институте я работал на СМ ЭВМ и читал документацию на синьке, то она всегда начиналась со слов - digital equipment corp., Maynard, MA. Думал ли я, что окажусь там?

Как образовалась вакансия DBA? Взлет Softlock совпал с продажей книги Стивена Кинга "Riding the bullet" в формате PDF за символический 1 доллар через Softlock. В час X должна пойти реклама. Разумеется, за несколько недель до часа X программисты днюют и ночуют на работе. За пять минут до рекламы DBA вносит самое последнее изменение. В команде DELETE он забывает WHERE и удаляет все данные в важной таблице. Бэкап! кричит он. Поздно, мы в эфире - говорят ему. Как идут продажи? спрашивают менеджеры.

Короче, кое что им удалось подправить, наделав кучу костылей. DBA все исправил, но, не выдержав позора, покинул фирму. Я же разгребал его костыли вместе с коллегами из страны, где очень любят петь и танцевать. Один коллега, например, хранил суммы таблице varchar() примерно так: '$123.45'. Я спросил его - зачем? Он пояснил, что это очень удобно, когда сумму отображаешь для пользователя, то не надо делать никаких преобразований.

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

Бодишоп меня заблаговременно перевел в Osram Sylvania - то был мой первый опыт big Enterprise. А через два месяца Softlock накрылся и всех уволили. Мне было их жаль, но все же я чуствовал некое удовлетворение: как оказалось, деньги все таки надо зарабатывать, так называемая "новая бухгалтерия" это bullshit, а дважды два все таки четыре.

Лес, прогулки, встреча с копом

Я с детства люблю дачу, прогулки, покатушки на велосипеде, лес. К своему удивлению, со всем этим были проблемы. Начнем с того, что нельзя просто так взять и остановиться у обочины. Дороги, как правило, выглядят вот так:

То есть на обочине просто так не встать - машина сразу будет всем мешать. Иногда даже пройти невозможно из-за бортиков/рельс по краям:

Да, есть специальные места где можно остановиться, чтобы войти в лес. Там часто написано что parking is closed after sunset. Нет, я не собираюсь гулять в лесу ночью, но природа не имеет часов работы. Почему я должен смотреть на часы? Прогулка в лесу - это не бизнес, у него не может быть часов от и до.

Мы с женой после посещения Ниагарского водопада ехали вдоль великого озера и так и не смогли к нему выйти. То ряд домов, то закрытый выход с надписью 'private property', а единственный общественный парк с выходом к озеру был 'closed for a season'.

Один раз я решил погулять ночью около дома. Наползал туман и я решил, что будет красиво посмотреть с моста на highway - как машинки едут сквозь туман. Вскоре я увидел полицейскую машину, которая развернулась и поехала ко мне. Коп ослепил меня своим фонарем и спросил, что я тут делаю. Я ему рассказал про туман и машинки. Он отъехал, но через пару минут развернулся и снова вернулся ко мне. "Но ты точно не чувствуешь себя depressed? Потому что люди из этого neighborhood звонили в полицию, что один человек ходит около моста". Я произнес гневную тираду про Европу, где люди гуляют ногами и это нормально. Коп махнул рукой и уехал.

Отъезд и как я бросил машину

Ситуация в экономике ухудшалась, и когда закончился контракт с Sylvania, то я решил не искать ничего нового а вернуться. Но мне пришлось бросить машину, и вот почему.

Машина была в лизе и принадлежала банку A. В какой то момент я решил ее выкупить и превратить лиз в лоан у банка B. Это было легко, и банк B прислал инструкции, что мне надо его, банк B, вписать как lienholder (владелец залога) в title (свидетельство о регистрации). Вот только эта инструкция была правильна для рефинансировании другого loan, но не лиза! В итоге я получил уникальную ситуацию: владелец машины банк A, а lienholder - банк B, а я не при делах.

Я начал разруливать эту ситуацию, сидя на звонках и слушая музыку от поддержки обоих банков. Банк A все обещал мне прислать новый тайтл, но так и не прислал, и только когда я сказал, что уезжаю, то title был прислан срочной почтой. Правда, через день после моего отлета. Я же сделал машине surrender: отвез ее в банк B и отдал ключи.

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

Предыдущие части:

Путь в IT, воспоминания бумера - программируемые калькуляторы, перфокарты, ДЗ-28

Путь в IT, воспоминания бумера - институт, СМ ЭВМ (PDP-11)

Воспоминания бумера - VAX/VMS

Что случилось после этого:

Жесть после переезда в другую страну

Дальше пока писать воспоминания не стоит - события не успели 'настояться' хотя бы лет 15.

Подробнее..

Экономим ресурсы и успеваем в срок зачем подключать QA-инженера в начале работы над фичей

19.02.2021 18:05:42 | Автор: admin

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

А в чем собственно проблема? Зачем тестировщику проявлять еще какие-нибудь качества помимо качеств мануального тестировщика?

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

Так зачем переделывать задачу и факапить сроки, если можно предотвратить большинство ошибок? Есть один вариант: QA-инженер. Специалист который будет влиять на качество процессов и продуктов на каждом этапе работы над фичей и служить связующим звеном между всеми этапами и подразделениями. В итоге вы получите качественный результат.

*Что мы подразумеваем под качественным результатом?

  1. Мы смогли решить проблему конечного пользователя и закрыли его потребность вовремя.

  2. Мы добились адекватного соотношения затраченных ресурсов и пользы, которую принесли бизнесу.

Чтобы прийти к качественному результату, нужно, чтобы QA участвовал на каждом этапе разработки фичи при:

  • поиске оптимального подхода к реализации функционала;

  • утверждении дизайна интерфейса;

  • выставлении сроков.

Почему этим связующим элементом гипотетически должен стать QA?

Приведем несколько аргументов:

  • У QA хорошо прокачаны софт-скиллы.

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

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

  • Если этого всего недостаточно, есть еще один аргумент: QA достаточно хорошо знаком как с технической стороной продукта, так и с интерфейсной. Короче говоря, он может подружить аргументы программиста, дизайнера и менеджера, если они не будут матчиться.

Давайте рассмотрим гипотетический процесс, на каждом этапе которого, предположим, участвует QA.Ремарка: это состояние идеального газа. Конечно, может быть много вариаций, в зависимости от специфики продукта, структуры компании и много чего еще.

История разработки одной фичи

Шаг 1. Знакомство команды разработки с новой фичей

На этом этапе фича еще может не иметь никаких очертаний. Задача QA включить одну из своих субличностей пользователь, чтобы осознать всю его боль и неудобства и контрибьютить идеями совместно с другими членами команды. QA будет предлагать идеи на стыке дизайна, разработки и пользовательского опыта, чтобы помочь команде увидеть картинку чуть более цельно.

Зачастую это может поменять видение менеджера на то, как нужно решать проблему. Фича может приобрести совершенно другой вид.

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

Шаг 2. Обсуждение UX/UI-решения

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

Когда перед глазами у тестировщика есть UX/UI-решение, он может увидеть все белые пятна в пользовательских сценариях. Этот вклад QA позволяет выявить те места, где в будущем появятся дополнительные требования. Те самые "доп.требования", из-за которых часто сдвигаются сроки релиза. Надо зарелизить фичу в срок и минимизировать затраты бизнеса.

Будьте готовы к тому, что UX/UI-решение возможно придется переделать. Это может быть кнопка, текст на кнопке или вся фича целиком. Этап может повториться несколько раз, пока команда не придет к лучшему возможному решению.

Совет: Чтобы к QA начали прислушиваться, покажите пример улучшения фичи, которую сделали без QA на этом этапе и расскажите, что история могла сложиться иначе. Найдите, как можно улучшить какой-нибудь user story в какой-нибудь уже реализованной фиче или задаче, которую вы тестируете сейчас.

И еще один совет: разберите базовые вещи об UX/UI науке. Изучите простейшие критерии качественного интерфейса.

Шаг 3. Декомпозиция задачи и оценка сроков

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

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

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

Роль QA проговорить еще раз каждую подзадачу с разработчиком и пропустить все это через тест-кейсы и user story. Найти оставшиеся подводные камни. Отловить нотки неуверенности в голосе разработчика, которые показывают, достаточно ли изучили задачу, чтобы выставлять срок.

Также QA нужно определить глубину и объем затронутого новым функционалом кода, который предстоит тестировать перед релизом.

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

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

Шаг 4. Обсуждение подводных камни и поиск компромиссов

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

  • увеличить ресурсы, например, выделить больше времени или добавить разработчиков в команду;

  • упростить функционал;

  • ну, или смириться с реальностью.

Гипотетический результат от гипотетического внедрения этого подхода:

  1. Сроки становятся более предсказуемыми.

  2. Качество продукта повышается.

  3. Стоимость разработки снижается за счет устранения ошибок и возможных доработок еще до начала процесса разработки.

Ну и несколько тривиальных советов QA-специалисту, который хочет быть полезен на каждом этапе работы над фичей:

  • Знать идею продукта, фичи.

  • Иметь представление о пользователе.

  • Иметь понимание, что бизнес хочет от пользователя.

  • Иметь понимание, что пользователь хочет от продукта.

  • Иметь понятия об UX/UI.

  • Иметь базовое понимание в программировании.

Подробнее..

Что написать в резюме, если нет опыта работы

20.02.2021 16:15:19 | Автор: admin

Люди меняют профессию по разным причинам надоело, босс не очень или платят мало. Да и мало ли ещё что. Важно, что у всех есть вероятность однажды оказаться перед пустой формой для резюме вообще без опыта работы.

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

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

Напишите, кто вы

Если вы ищете работу в России, то имя и фамилия должны быть заполнены по-русски.

Укажите место проживания. Эта информация важна, чтобы работодатель понимал, сможете ли вы ходить в офис, или в каком часовом поясе вы находитесь, если работа удалённая. Явно укажите, готовы ли вы работать удалённо или рассматриваете только офис. Если готовы переехать так и напишите.

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

Загрузите фотографию

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

Есть несколько правил к фото в резюме:

  • не должно быть лишних людей,

  • желательно на однотонном фоне

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

Определитесь с должностью

Пишите по делу и что-нибудь одно это самый хороший вариант. После курсов по разработке вполне рабочие версии такие:

  • HTML-верстальщик

  • Фронтенд-разработчик

  • РНР-разработчик

  • Веб-разработчик

Если вы ищете работу продавцом утюгов и одновременно фронтенд-разработчиком, то создайте отдельное резюме для каждой должности. Объединять не стоит если кандидат сам не может понять, чем он хочет заниматься, то и работодатель вряд ли станет тратить на это время.

Напишите, сколько хотите денег

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

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

Вспомните всё, что было похоже на опыт

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

Например, прохождение стажировки в настоящей компании тоже считается опытом, даже если денег за это не платили.

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

Рассказывает Екатерина Новографская, HR-менеджер компании iBrush:

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

И нетленная классика: выберите адекватное фото, где вас хорошо видно, добавьте рабочую почту (немного странно отправлять предложение о работе на почту kiska94735@mail.ru), перечислите списком ваши навыки. И не забудьте написать пару слов о себе: чем увлекаетесь, какие у вас интересы и цели. Также можете указать нюансы, касаемые графика работы, если имеются.

Расскажите о себе

Этот раздел важно заполнить правильно, если совсем нет опыта работы. Здесь важнее то, чего вы хотите достичь, чем то, что уже было.

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

Напишите, что умеете из новой профессии

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

Например, средняя вакансия для верстальщика выглядит так:

  • Умеет делать адаптивную кроссбраузерную оптимизированную вёрстку, совместимую с современными браузерами. В вёрстке использует SVG.

  • Идеально знает CSS. Использует препроцессор Sass. Знает флексы. Умеет делать CSS-анимации и использует БЭМ. Знает библиотеку Bootstrap.

  • Знает HTML. В работе использует Canvas. Шаблонизирует HTML с помощью PUG.

  • Использует Git. Умеет работать в GitHub.

  • Может натянуть вёрстку на CMS: Bitrix и Wordpress.

  • JavaScript пишет с помощью jQuery, но не чурается ES6.

  • Умеет автоматизировать свою работу с Node.js, npm-скрипты, Autoprefixer, Gulp или Webрасk.

  • Уверенно владеет Photoshop и Illustrator или знает Figma или Sketch.

  • Имеет своё портфолио, инициативный, готов пройти испытательный срок

Конечно, для новичка здесь много непонятных слов и аббревиатур. Ничего страшного. Предположим, вы уже неплохо знаете HTML и CSS, работали с SVG и немного понимаете, как устроен JavaScript. Значит эти навыки и нужно указать, а некоторые пункты, о которых только слышали, перенести в план развития (тем более, выучить их всё равно придётся).

Рассказывает Назир Хасавов, основатель и арт-директор Студии NKH

Очень важен опыт вёрстки. Даже если человек только прошёл курсы, то можно указать в резюме учебные проекты. И обязательно прикладывать ссылки на GitHub и GitHub Pages, чтобы можно было посмотреть на код. Также важно запомнить, сколько времени ушло на проект такой сложности.

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

Напишите, где учились

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

Хороший объем две страницы А4

Вообще без опыта сложно наскрести и столько, но если вдруг получилось, то держите в голове следующий факт.

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

Напишите хоть какое-нибудь сопроводительное

Хорошее сопроводительное письмо суперсила. Здравствуйте, прошу рассмотреть моё резюме на вакансию тупик.

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

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

95% выпускников профессий HTML Academy устраиваются на работу не только из-за хорошего резюме. Они учатся профессиональной вёрстке и программированию, прокачивают скорость работы в Акселераторе и проходят оплачиваемую стажировку в Лиге А.. Ещё мы помогаем выпускникам найти работу даже в небольших городах то есть делаем всё, чтобы студенты могли заниматься новым любимым делом. Присоединяйтесь, старт профессии React-разработчик 27 апреля.

Как составить резюме, если нет опыта работы

  1. Честно напишите, кто вы имя, возраст, город

  2. Фотка с улыбкой сила

  3. Должность должна быть одна. Никаких маркетолог-мясник

  4. Напишите, сколько хотите денег. Даже если сумма с потолка

  5. Если нет никакого опыта, сгодится любой похожий

  6. План развития важнее пятёрок в школе

  7. Чем больше навыков совпадёт с вакансией, тем лучше. Остальное пойдёт в план развития

  8. Образование важнее, чем кажется, но не критично

  9. Не больше двух страниц на всё (но растягивать и лить воду тоже не нужно)

  10. Сопроводительное письмо помогает. Прошу рассмотреть резюме нет


Подробнее..

Эксперимент допуск или как студентов уму разуму научить

24.02.2021 08:04:01 | Автор: admin

Чем еще заняться в период пандемии и удаленки, как ни разглагольствованием о великом? У всех нас появилось много свободного времени, которое теперь не обязательно тратить на дорогу, и если кому-то не жалко тратить это время на просмотр сериалов, инстаграм и борьбу с диваном, то мне за первый месяц все это порядком поднадоело и захотелось чего-то продуктивного.

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

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

Почти четыре года назад мне довелось стать преподавателем двух предметов в Новосибирском Государственном Университете на Факультете Информационных Технологий. Потом из-за нехватки времени появилось желание отказаться от преподавания одного из них, но лектор попросил оставить хотя бы одну группу. Предмет, на мой взгляд, бесполезный, а введен он был для галочки.

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

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

  1. Git

  2. Jira\Redmine\Trello

  3. Code review

  4. Unit-тестирование

  5. CI\CD

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

На что вообще клюют студенты-перваки? Надо чтобы было драйвово, интересно, понятно, стильно, модно, молодежно. Кстати, многие аутсорс-компании тоже делают на этом акцент, и мне не верится, что это случайность. Теперь информатика это предмет все обо всем, этакий окружающий мир для программистов.

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

  1. Отменяем лабы и домашки. Пусть все делают на самих парах. Я буду показывать, а они повторять

  2. Оценка должна быть за посещаемость. Иначе вообще никто ходить не будет

  3. Все работы делаются вubuntu. На выбор студентов можно установить ее себе на ноут, можно пользоватьсяVirtualBoxилиWSL

  4. Все, что делают студенты должно быть наглядно. Им это нравится. Круто же когда ты увидел не чиселки в консоли, а открыл самостоятельно настроенный сайт в браузере. Магия должна быть видна невооруженным взглядом

  5. Стоит сделать акцент на таких вещах какNPMиyeoman, они просты и в то же время позволяют делать сложные вещи, это опять же должно повысить интерес к самому процессу и приучить ребят работать в консоли

  6. Часть заданий нужно сделать в группах, это повысит ихSoftSkills

Лайфхак. Если хочется расположить людей к себе, их нужно накормить. Для голодных студентов это актуально вдвойне.

Каждую пару я захожу в одну из кофеен, расположенных в универе, и покупаю себе кофе. Я стал периодически покупать большой ЭмЭмДемс и оставлять его на первой парте. Все желающие могли угоститься. И теперь в девять утра полная аудитория довольных студентов. И нет, мне не платили за рекламу m&m's. Да и в принципе за преподавание платят смешные деньги хватает в аккурат заправить полный бак моего крокодила.

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

ПоднимаемGitlabна локальной машине.Тогда автору показалось это не слишком сложным (инструкция на сайте есть, команд всего несколько), зато очень впечатляющим, круто, когда на твоей машине поднялся огромный сайт с кучей кнопочек и настроек. Плюс ко всему это хорошо коррелирует с рассказом проGitиCI\CD. Здесь был мой первый промах - студентам оказалось сделать подобные вещи сильно сложно. Задача осложнилось тем, что студенты устанавливали себе разные дистрибутивы, и у кого-то все взлетело сразу, а у кого-то вообще никак не стартовало. В общем, они долго плевались и делали это с неохотой. В следующем году это задание будет выброшено, уж слишком сложно получилось. В следующем году планирую сделать определенный образ убунты вVirtualBox, чтобы выполнив все действия по инструкции, все заработало.

УстанавливаемDockerи делаем то же самое в доккере. Это всего одна команда, и тут ребята должны были понять, для чего этот самый докер нужен, и как сильно он упрощает жизнь (не кидайтесь помидорами, я знаю, как он может усложнить жизнь, но они же пока маленькие, не стоит их сразу пугать.) Надо сказать здесь ребятаточно также разбились на два лагеря: те у кого личные ноутбуки с успехом поддерживаютDocker(это либо те, у кого поддерживаетсяHyper-Vили либо же те, кто пользуетсяUbuntuкак основной системой) и те, кому пришлось долго возиться сDockerToolboxиVirtualBox. Я разрешил тем ребятам, у кого не удалось настроить окружение, просто забить на это задание и посмотреть, как это должно выглядеть у той половины, которой все удалось настроить. Задание с докером не хотелось бы выбрасывать особенно потому, что оно отлично вписывается в рассказ про облачные сервисы на подобииAzureиAmazon.Добиться цели, конечно, удалось, ребята увидели, что множество команд можно заменить одной, если вDockerесть уже готовое решение. Но само задание надо будет доработать напильником.

Создаем проект наApacheCordova.Используем тот жеyeoman, комплим и заливаем результат на телефон. Благо, сейчас это можно сделать достаточно просто и даже без проводов. Здесь снова акцент идет на наглядность. Менять в самом проекте ничего не нужно, ну разве что поиграться с какими-нибудь названиями или заголовками. Это было первое задание, когда у студентов действительно загорелись глаза. В следующем году это задание будет передвинуто в самое начало для большей мотивации.

Создаем проект наAngular. Мы создавали обычныйHelloWorld. Суть в том, чтобы показать студентам процесс создания проекта. Хотелось, чтобы они увидели разные подходы и не испугались, когда их попросят сделать что-то подобное на работе или в универе. Помню, как сам впадал в ступор, когда приходилось делать подобные вещи, потому что в универе привыкаешь к тому, что как правило надо открытьVisualStudio(илиIdea) и нажать кнопочку наGUI-интерфейсе Создать проект. Но не для всего естьGUIинтерфейс, да и не всегда он нужен. Вроде простая истина, но процесс ее осознания достаточно сложный, а для того, чтобы облегчить эту учесть достаточно всего один раз об этом рассказать.

Последние два задания потребовали наличияNodeJsи это хорошо коррелировало с рассказом про консольные скрипты и что их можно писать не только наbashилиpowershell, но такжеpythonили дажеjs. Просто для каждого языка есть свой интерпретатор. Это опять же не делает их знатоками в данных областях, но расширяет их кругозор.

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

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

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

Подводя итоги

Было бы нечестно сказать, что все прошло гладко, скорее здесь был первый блин комом.Я взял достаточно высокую планку, многие вещи студентам были не понятны. Пришлось на ходу переобуваться и менять задания, но думаю в следующем году получится найти баланс между сложностью и заинтересованностью, при котором все будут довольны. Позитивно сказалась работа в группах, индивидуально ребята не могли все осилить, а когда в группе есть 1-2 человека более сильных, то процесс идет лучше. Тут главное не допустить ситуации, когда только эти двое работают, а остальные сидят в телефонах. Еще один прием, который я взял на вооружение, дать ребятам разные задания, а затем сделатьswapи заставить их научить друг друга. Все это повышаетSoftSkills, которые обязательно пригодятся в жизни.

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

А еще не так давно пара студентов с четвертого курса попросились ходить на пары по тому же ООП. Я опять же не против и добавил этих ребят в общий чатик в ВК, и вот какой получился у них диалог. Все-таки приятно, когда старания не проходят даром!

Касаемо ООП все осталось как и раньше, ничего лучше я придумать не смог. Мы все так же играем в реальную работу, заливаем код вGit, двигаем задачи вTrello, создаем пул-реквесты, используемIoC-контейнеры и пишемUnit-тесты. Подробно об этом я писал в прошлой статье.

Еще как оказалось, если взять ребят, которых я уже учил, им гораздо легче рассказывать про сложные вещи. Они уже более или мене подготовлены, они знают что-то в теории и теперь им можно показать, как оно работает на практике. Можно быть уверенным, что ребята имеют некоторый бэкграунд. В общем, это круто, когда можно не учить с нуля, а продолжить их обучение. Получается, что это уже не два отдельных предмета, а целая система, в которой прошлые школьники вначале получают полезную и легко воспринимаемую информацию, а по мере их взросления коэфициент ответственности растет, и на втором курсе им уже придется пыхтеть изо всех сил. Разве не так и должно быть все устроено в жизни? И мне бы хотелось дать им такие знания и возможности, при которых, если не все, то большая часть дверей для них будет открыта. Опыт оказался весьма интересным, и нужно развивать такие подходы в дальнейшем. Когда удастся все сбалансировать, думаю, будет полезно посмотреть в сторону развития в студентахSoftSkills, но пока это только перспективы. А пока, было бы очень полезно получить фидбек от читателей на тему того, что они думают на этот счет.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru