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

$187 млрд — именно в такую сумму оценивают состояние основателя Amazon. Его путь вряд ли можно повторить, но на его ошибках и решениях можно учиться. Семь лет без прибыли и прогнозы аналитиков о скором банкротстве — но предпринимателю удалось преодолеть трудности и построить компанию стоимостью больше $1,6 трлн.

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

Дальше — прямая речь из его книги, выходящей в 2021-м.

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

В начале 2020 года специалисты сервиса по поиску работы «Работа.ру» провели социальный опрос и выяснили, что в следующие 12 месяцев 74% россиян хотят заняться вопросом нового трудоустройства. 53% респондентов рассказали, что недовольны текущим уровнем заработной платы. Но почему в итоге ничего не происходит?

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

Сложность

Привет, Хабр!

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

В языках вечно не хватает чего-то простого — лямбда-функций, именованных объединений, кастомных примитивных типов. Я лезу в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются — им не хватает того же, чего и мне. Но обсуждения почти всегда заканчиваются одинаково: нужная фича не появится, потому что главный дизайнер языка и члены его команды нужной ее не считают.

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

Но сейчас я понимаю — это полная чушь.

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

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

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

Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.

let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));

• АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
• АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

Никакой свободы врагам свободы

Informative

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

Внимание! Перед тем, как рассказать аудитории Хабра об этих проблемах, мной были предприняты попытки сообщить о них разработчикам через платформу HackerOne. Разработчики посчитали это все “не багами”, а репорты были закрыты в статусе “informative”, дважды!