4 года назад я решила уйти из маркетинга и начать работать фронтенд-разработчиком. Расскажу о том, как искала первую работу, как жила на 30 тысяч в Москве, как обучалась, как устроилась фронтом в Prequel и что сделала бы иначе, окажись в той же ситуации. Также всем желающим могу рассказать, как выровнять блок по вертикали))

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

Как все начиналось

В далеком 2007 году я заканчивала экономический факультет Тверского университета, у нас был курс информатики на семестр, где 3-4 занятия были посвящены html и css. Преподаватель объяснила основы табличной верстки, без адаптива, на уровне “Цвет текста можно поменять вот так, а картинку вставить вот так”. Далее в голодные студенческие годы я начала заниматься фотографией и для поиска клиентов сделала свой первый сайт на Joomla. Отсутствие способностей к дизайну, несколько лекций по табличной верстке и случайно купленная книжка с маркетинговым названием “Как сделать сайт, продвинуть его и начать зарабатывать” дали свой ужасающий по стилю, но вполне работающий результат.

Вычитанные в этой книге советы по SEO сработали, удалось продвинуться по некоторым средне- и низкочастотным запросам, например, “деловая фотосессия”, помогло еще и то, что я жила в городе на 400 тысяч человек с умеренной конкуренцией в фотографии. Однако после универа и переезда в Москву заниматься фотографией стало сложнее – отработать полную неделю в Москве, а на выходных встать в 5 утра на съемку свадьбы было тяжеловато физически. В одну из суббот, отсняв армянскую свадьбу на 200 человек, я осознала, что с фото пора завязывать.

Дальше была попытка работать по специальности, однако я снова пришла к SEO и 2,5 года отработала в агентстве SEO-шником, но со временем меня перестало устраивать, что в оптимизации сложно отследить точное влияние своих действий на результат. Одновременно вокруг росло количество курсов, обещающих, что ты станешь Senior Java Developer за 2 недели (нет) и друзей-программистов, обещающих 150к уже через полгода (нет, нет, нет).

Я самоуверенно решила, что верстку и так знаю, купила книгу по JavaScript и начала читать и делать упражнения. Дополнительно посмотрела пару уроков на Youtube “Как сделать сайт за 2 часа”, повторила за авторами, получила несколько лендингов. Через пару месяцев отправилась на поиски работы, сайтики с видео-уроков представила как свое портфолио, но не скрывала, что сделаны по обучающим видосам.

Здравствуйте! Меня зовут Иван Давыдов, я занимаюсь исследованиями производительности в Яндекс.Деньгах.

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

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

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

Материалы статьи провалидированы и обновлены автором 26.05.2023

// создаем объект user
const user = {
    name: 'Harry Heman',
    age: 29,
    job: 'developer'
}

// преобразуем объект в строку, используя стандартный метод toString(), и выводим результат в консоль
console.log(user.toString()) // [object Object]

console.log(JSON.stringify(user)) // {"name":"Harry Heman","age":29, "job": "developer"}

Несколько лет назад я услышал от одного коллеги историю. Он в то время работал начальником отдела технической документации в IT компании. Дело было на собрании, посвященном знакомству с новым техническим директором. Тот, пожав моему коллеге руку и узнав о его роли, пошутил: “Документация? Так ее же не читает никто! Двадцать первый век на дворе”.

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

Впервые я задумался об этаком “soft skills starter pack” около года назад. Гугление дало списки из 10-15-20 навыков без пояснений, как их внедрять, и почему список именно такой. Апофеозом для меня стала книга “12 soft skills для 21 века”, которая является кратким изложением 12 других книг. 

С трудом верится, что все эти навыки нужны разом. Если на собеседовании я буду проверять кандидата на 15 навыков, я вообще кого-то найму? За сколько лет я разовью их сам? Эмоциональный интеллект – пару лет? Системное мышление – еще пару лет? Окей, хотя бы со скольки навыков я могу считать себя пригодным к работе в команде? А к роли лидера? В общем, "программу-минимум" я тогда не нашел.

Но как тимлид я слышу множество карьерных историй: на собеседованиях, на 1-to-1 с коллегами, просто консультируя пришедшего с вопросом – везде я узнаю истории успехов и ошибок. А в обмен я стараюсь дать структурированную и понятную обратную связь. Постепенно из этих историй и обратных связей сложился набор минимально необходимых soft skills. Они будут полезны хоть инженеру, хоть лидеру. Вообще говоря, они будут полезны не только IT-специалисту и не только в карьере.

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

• Откровения трезвого инженера
• Откровения пьяного старшего инженера

Пишите хорошо

Виды документации

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

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

Как подготовить митап для команды или любой внешней аудитории?

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

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

У нас проблемы с промисами

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Ремарка от автора
Это статья новая, но она не о новых возможностях. Она о core, то есть о платформе и о том что многие кто просто используют grunt, или webpack могут не подозревать, так скзать about fundamentals.

Более подробно читайте:

комментарии rumkin:
habrahabr.ru/company/mailru/blog/283228/#comment_8890604

комментарии Aiditz:
habrahabr.ru/company/mailru/blog/283228/#comment_8890476

комментарии Suvitruf:
habrahabr.ru/company/mailru/blog/283228/#comment_8890430

1. Цикл событий: освежаем ключевую концепцию, позволяющую реализовать неблокирующие операции ввода/вывода.
2. Глобальный объект и процесс: как получить больше информации.
3. Эмиттеры событий: интенсивное введение в событийную модель (event-based pattern)
4. Stream’ы и буферы: эффективный способ работы с данными
5. Кластеры: форкай процессы как профессионал
6. Обработка асинхронный ошибок: AsyncWrap, Domain и uncaughtException
7. Аддоны на C++: внесение своих наработок в ядро и написание собственных аддонов на С++