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

Программист должен решать проблемы бизнеса
Программист не должен решать задачи бизнеса

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

Уровни разработчиков

Начну я, пожалуй, с вопросов иерархии и уровней. Раньше я думал, что существует 3 уровня:

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

Добрый день, уважаемые читатели.

Недавно наткнулся на статью Как эксперту IT дополнительно заработать на своих знаниях. В ней описан относительно честный способ отъема денег монетизации технических знаний путем создания «обучающих» роликов.

В интернете кто-то неправ, поэтому я сел писать статью, пока не пропал запал.

Пожалуйста, не делайте видеоролики

Видеоролики это «адское говнище»™. Аргументация — в статье под катом.

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


Ты меня слушаешь, или смотришь на девицу в красном?

Хотите подзаработать на своих знаниях? Скучно сидеть дома? Займитесь консультациями или репетиторством. О консультациях хорошо написал maxfarseer в своей статье Мой опыт консультирования по JavaScript (React/Redux).

Под катом я буду ворчать про формат видеороликов и делиться опытом в репетиторстве «18+».

Краткое содержание:

• Интернет — большая свалка
• Почему вам может понравиться репетиторство
• Почему вам не интересно заниматься видеороликами
• Дополнительные затраты на обучающий ролик
• ROI репетиторства
• Ученики не всегда знают чего хотят

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

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

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

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

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

Бонус в конце: ссылка на каталог приложений для удалённой работы.

Введение от автора обзора

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

Изображение: Unsplash

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

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

Я решил разобраться, так ли это на самом деле или в реальности не всё так просто. Для этого я поговорил с Денисом Неклюдовым, Staff Engineer в компании Lyft (конкурент Uber) и автором DevJobAccelerator. Итак, посмотрим, как на самом деле выглядит карьерный путь разработчиков в Кремниевой долине – от старта до компенсаций в миллионы долларов.

Блог RUVDS на Хабре видел всё: популяризацию JavaScript и крутые переводные материалы, яхтинг, вопросы образования и профессионального развития, бургеры, сыры, пиво и календари с кибердевушками. Задумка поговорить об основах трейдинга и работы на фондовом рынке возникала у нас давно, и вот почему. Большинство компаний, пишущих на биржевую тематику, имею чёткую цель: получить клиентов для своих инструментов и брокерских счетов, а значит, в их статьях инвестирование — исключительно привлекательное занятие, которое должно стать хобби каждого гика. Единственное, что мы можем предложить начинающим трейдерам — это VPS с торговыми платформами, и у нас нет мотивов представлять мир торговли на фондовом рынке как средство разбогатеть. 

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

Компании с правильными дизайн-процессами зарабатывают существенно больше.

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

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

Меня зовут Николай, я дизайн-директор в McKinsey & Company. Одна из моих рабочих задач — показывать и объяснять компаниям, что такое дизайн. Вопреки распространённому мнению, это не «картинка» или «нарисованный интерфейс». Это проектирование, которое ведёт к тому, что будет решаться основная задача бизнеса. А основная задача бизнеса — максимально удовлетворять потребности клиентов, зарабатывая при этом или накапливая какой-то другой ресурс.

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

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

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

Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

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

Статья посвящена такому важному гормону, как тестостерон, и объяснению, почему именно он делает мужчин мужчинами. Также cтатья будет интересна к прочтению прекрасным полом.

Содержание:

• История открытия
• Что такое тестостерон и как он работает в организме
• Нормы тестостерона, диагностика, а также немного о заместительной терапии Т
• Риски избытка и недостатка тестостерона
• Пища для поднятия уровня тестостерона

Часть первая. Конфликт

Среда, 4 марта 2020, полдень

Я отдыхаю дома. Звонит наш техдир Рома:
— Миша, когда ты будешь на работе?
— Я решил сегодня остаться дома.
— Хорошо, я передам руководству
— По ТК есть норма, что если 15 дней задержка, то можно не выходить
(на тот момент я не видел зарплаты больше месяца)
— Да, я знаю
Рома перезванивает мне через 15 мин:
— Во сколько ты можешь приехать за зарплатой?
— Давай уже завтра, как обычно
— Хорошо, тогда до завтра

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

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

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



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

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

Говорят, что можно бесконечно смотреть на огонь, наблюдать за тем, как работают другие, а также изучать DDD (Domain Driven Design, предметно-ориентированное проектирование). Но если у вас есть только 10 минут — можно прочитать эту статью и пройтись по самым верхушкам, а потом с умным видом кивать головой во время светской беседы.

Покрутили и рассмотрели DDD с разных сторон вместе с Андреем Ратушным — техническим директором компании Югорские Интернет Решения.

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

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

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

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

Есть одна очень хорошая компания, одно из самых приятных мест, где я когда-либо работал, сочетание всех вкусностей Valve и Netflix. Люди здесь удивительные, а вам дают почти полную свободу делать всё, что вы хотите. Но как побочный эффект такой культуры, в первый год от них уходит примерно 50% новых сотрудников, некоторые добровольно, а некоторые нет. Абсолютно нормально, да?

Есть компания, которая невероятно скрытно относится к своей инфраструктуре. Например, боится сообщать о багах поставщику оборудования, потому что тогда ошибки будут исправлены, а конкуренты смогут использовать исправления. Этого нельзя допустить. Решение: запросить прошивку и исправить баги самостоятельно! Нормально.

Сингапур, Кипр, Китай, Голландия — государства, которые, первыми приходят на ум, когда речь заходит об офшорах для ИТ-компаний. Но в этой статье я расскажу о стране, которая граничит с Россией и предлагает, на удивление, очень соблазнительные условия для стартап-компаний в сфере информационных технологий. Проверено на себе! Погнали?

Гамарджоба, генацвале!

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

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

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

ЛОЛШТО?

Пожалуйста, не поймите меня неправильно. Я профессиональный разработчик с 30-летним стажем. Я могу читать и понимать почти двадцать языков, полных по Тюрингу. Я могу писать ясный и выразительный код на доброй дюжине из них. В языках, которые я действительно люблю и использую ежедневно — мое имя можно увидеть на доске почета StackOverflow (топ-20 в мире: ruby, elixir). Я по-настоящему люблю писать код, и я отклоняю все предложения «вырасти» по должностной лестнице, будь то руководство проектами, CTO, или что угодно в этом направлении, несмотря на потенциальное увеличение дохода в разы.

— Abraham Willemsens (Metropolitan Museum of Art)

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