Никакой воды в этой статье, только описание конкретного плана действий в случае если вы перегорели, у вас дедлайн, прокрастинация, депрессия, а также методики и советы, помогающие привести этот план в действие.
Пользователь
Джефф Безос: «Как я принимаю самые важные решения в Amazon»
$187 млрд — именно в такую сумму оценивают состояние основателя Amazon. Его путь вряд ли можно повторить, но на его ошибках и решениях можно учиться. Семь лет без прибыли и прогнозы аналитиков о скором банкротстве — но предпринимателю удалось преодолеть трудности и построить компанию стоимостью больше $1,6 трлн.
В отрывке из нового сборника своих работ гендиректор Amazon говорит, что его секрет — в том, чтобы принимать меньше решений, долго думать только о том, что нельзя будет исправить, и планировать на два-три года вперед. Самый богатый человек мира выступает с советами для владельцев и топ-менеджеров компаний.
Дальше — прямая речь из его книги, выходящей в 2021-м.
Здравствуй, дорогой я двадцать лет назад
Жаль, что вряд ли смогу отправить это письмо. А тебе, наверное, было бы интересно узнать, что жизнь и работа у тебя сложились неплохо. А если бы ты это прочитал вовремя, то могли бы сложиться еще лучше. Что касается работы — ты стал вполне приличным специалистом, сегодня тебя уважают, с тобой советуются и некоторые даже благодарны за науку. Очень хочется дать тебе тогдашнему несколько советов. Кое о чем из письма ты и так уже догадываешься, но сегодня я могу точно сказать — оно помогает.
За что получает деньги наемный работник? Не понимаете? Сейчас поймете
«За что я тут корячусь на тебя?» — столь же обычный вопрос работника к работодателю.
Разобраться, за что же действительно работодатель платит деньги наемному работнику, поможет моя собственная теория, закодированная в десять букв – «ПЗП – ПЗС – ПЗПИ»
Как говорить с сотрудниками. 7 аспектов, о которых забывают
И тогда пришло время остановиться и задуматься — какие ошибки люди допускают чаще всего. © Unsplash
Прошёл путь от тестировщика через архитектора и менеджера до руководителя, пусть небольшого, но горячо любимого и созданного с нуля, подразделения, в котором работает порядка 100 человек.
Слишком люблю обмениваться знаниями, потому, после организации различных обучающих активностей внутри Компании, захотелось пойти дальше и обсудить свои взгляды и идеи с более широкой аудиторией (если позволят модераторы).
Это моя первая статья — потому буду крайне рад комментариям и рекомендациям. Спасибо!
6 ошибок мышления, из-за которых вы остаетесь на нелюбимой работе
В начале 2020 года специалисты сервиса по поиску работы «Работа.ру» провели социальный опрос и выяснили, что в следующие 12 месяцев 74% россиян хотят заняться вопросом нового трудоустройства. 53% респондентов рассказали, что недовольны текущим уровнем заработной платы. Но почему в итоге ничего не происходит?
Лишь малая часть из тех, кто планирует сменить место работы, в конечном итоге делает это. Оказывается, в большинстве случаев основная причина бездействия — когнитивные ошибки. Мы решили разобраться, что это и из-за каких именно ошибок в мышлении люди отказываются менять карьеру и добиваться новых высот.
Программисты, ходите на собеседования
Картинка взята из видеоролика с канала «Воинствующие Аметисты»
Около 10 лет я работал системным программистом под Linux. Это модули ядра (kernel space), различные демоны и работа с железом из пространства пользователя (user space), различные загрузчики (u-boot и др.), прошивки контроллеров и многое другое. Даже иной раз случалось пилить web-интерфейс. Но чаще бывало, что приходилось и с паяльником посидеть, да с проектировщиками печатных плат взаимодействовать. Одна из проблем такой работы это то, что достаточно сложно оценить уровень своей компетенции, поскольку одну задачу ты можешь знать очень глубоко, а рядом можешь не знать совсем. Единственный адекватный способ понять куда идти, и какие течения сейчас есть – это ходить на собеседования.
В данной статье хочу обобщить мой опыт похода по собеседованиям на вакансию системного программиста linux, особенности интервью, работы и как по общению с будущим работодателем оценить личный уровень знаний и чего от этого ожидать не стоит.
В статье будет небольшой конкурс с призами.
Введение в анализ сложности алгоритмов (часть 2)
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.
Опубликовано ранее:
Часть 1
Сложность
Из предыдущей части можно сделать вывод, что если мы сможем отбросить все эти декоративные константы, то говорить об асимптотике функции подсчёта инструкций программы будет очень просто. Фактически, любая программа, не содержащая циклы, имеет
f( n ) = 1
, потому что в этом случае требуется константное число инструкций (конечно, при отсутствии рекурсии — см. далее). Одиночный цикл от 1
до n
, даёт асимптотику f( n ) = n
, поскольку до и после цикла выполняет неизменное число команд, а постоянное же количество инструкций внутри цикла выполняется n
раз.Как я стал программистом в 35 и стоит ли оно того?
Привет, Хабр!
Прежде всего хотел бы предупредить, что это нисколько не мотивационный пост в стиле «история моего успеха» или «как удачно я вкатился в программирование».
Для чего я решил написать этот пост? Отчасти поделиться опытом, советами, отчасти меня сподвигла на это статья «Как я не стал программистом в 35 лет», я тоже решил написать свой пост на схожую тему, но в то время у меня не были выполнены два условия: 1. Мне не было 35; 2. Я только устроился на свою первую работу разработчиком, но я считал что не могу называться программистом если не отработал в этой должности хотя бы 1 год. Сейчас все условия соблюдены, если вам интересно прошу под кат.
Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти
Я программирую 16 лет, и перебрал за это время много технических стеков. Изучать языки весело, в начале они всегда как новенькие игрушки, пока месяце на третьем не появляются первые проблемы.
В языках вечно не хватает чего-то простого — лямбда-функций, именованных объединений, кастомных примитивных типов. Я лезу в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются — им не хватает того же, чего и мне. Но обсуждения почти всегда заканчиваются одинаково: нужная фича не появится, потому что главный дизайнер языка и члены его команды нужной ее не считают.
Раньше в эти моменты мне казалось, что это я неграмотный, и чего-то не понимаю. Что создатели языков за гранями приземленной разрабовской критики. Они умны, дальновидны, преисполнены мудрости, и пути их неисповедимы.
Но сейчас я понимаю — это полная чушь.
Вредные советы: как заставить программиста работать лучше
Каждый из нас хотя бы раз в жизни видел программиста (сами себя они предпочитают называть разработчиками). Как правило, программисты довольно замкнутые, очень пугливые и любят подолгу смотреть в монитор. Они – либо следующая ступень эволюции человечества, либо предыдущая. Они плохо умеют разговаривать, но очень хорошо понимают человеческую речь и компьютерные сигналы. В этой статье я хочу рассказать, как заставить ваших разработчиков работать лучше, при этом не доставляя им никакого дискомфорта и не пугая их. А для этого вам необходимо будет запомнить несколько правил.
Я десять лет страдал от ужасных архитектур в C# приложениях — и вот нашел, как их исправить
Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.
Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.
Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.
Как мы воспринимаем цвет. Занимательные факты. Просто об очень сложном
Фото сетчатки в разрезе с электронного микроскопа.
Дорогие читатели, в этой статье о цвете я не буду приводить аналогии с цифровым фотоаппаратом и фотошопом для «лучшего» понимания физиологии зрения, как не делал этого и в прошлой статье «О разрешении нашего зрения». Такой приём, при кажущемся удобстве, только усложнит картину мира и запутает вас. Буду вести рассказ последовательно и в меру сложно.
Дэн Абрамов о замыканиях в JavaScript
Когда вы используете объект, переменную или функцию, вы делаете это намеренно. Вы думаете: «Тут мне понадобится переменная» — и добавляете её в свой код.
А вот замыкания — это уже нечто иное. В то время как большинство программистов начинает осваивать замыкания, эти люди уже, сами о том не зная, пользуются замыканиями. Вероятно, с вами происходит то же самое. Поэтому изучение замыканий — это не столько освоение новой идеи, сколько изучение того, как распознать то, с чем вы уже много раз сталкивались.
Если в двух словах, то замыкание — это когда функция обращается к переменным, объявленным за её пределами. Например, замыкание содержится в этом фрагменте кода:
let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));
Обратите внимание на то, что
user => user.startsWith(query)
— это функция. Она использует переменную query
. А эта переменная объявлена за пределами функции. Это и есть замыкание.Вы, если хотите, можете дальше не читать. Оставшаяся часть этого материала рассматривает замыкания в другом свете. Вместо того чтобы говорить о том, что такое замыкания, эта часть статьи посвятит вас в подробности методики обнаружения замыканий. Это похоже на то, как, в 1960-х, работали первые программисты.
Трюки с SQL от DBA. Небанальные советы для разработчиков БД
Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:
- АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
- АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.
АБД приложений обычно были частью команд разработки. Они обладали глубокими познаниями по конкретной теме, поэтому обычно работали только над одним-двумя проектами. Инфраструктурные администраторы баз данных обычно входили в ИТ-команду и могли одновременно работать над несколькими проектами.
Враги свободы
Никакой свободы врагам свободыКоторый, однако, не всеми был понят в историческом контексте. Поэтому хотелось бы дать развернутое определение в ответ на статью с критикой этого принципа, и предоставить сообществу решить, так ли уж он плох.
Как ухаживать за мозгом
Распределенная трассировка запросов в .NET
В любой системе возникает задача понять, как взаимодействуют компоненты между собой. Особенно важно это в распределённых системах. Как понять, какие компоненты обработали запрос, сколько времени это заняло, какой был порядок обработки. Всё это можно узнать, но нужно добавить немного инфраструктуры.
Егор Гришечко — работал разработчиком в компании Insolar. Команда Егора делает полностью распределенную систему, и поэтому они сталкиваются с большинством проблем, которые присущи распределенным системам. Сейчас Егор трудится в Uber и занимается разработкой инфраструктуры.
Под катом — текстовая расшифровка и видео доклада Егора с конференции DotNext 2019 Moscow. Доклад будет полезен разработчикам микросервисных систем, которые смогут для себя открыть эти технологии. А также будет интересен бэкенд-разработчикам, интересующимся метриками и мониторингом.
Как я два раза подряд искал работу на карантине
Мой бэкграунд: Москва, frontend senior, большой опыт и высокие притязания по зарплате (примерно 10-15% верхних предложений рынка).
«Особенности» Тиндера
Informative
Бывают такие баги, которые, вроде как и угрозу безопасности не несут, но вред все-таки могут причинить. Интереснее всего, когда их и править никто не хочет, но и открыто о них нам не говорят. Часто в таких случаях разработчики утверждают, что это не баг, а фича. Именно о двух таких фичах в Тиндере и пойдет речь в посте.
Внимание! Перед тем, как рассказать аудитории Хабра об этих проблемах, мной были предприняты попытки сообщить о них разработчикам через платформу HackerOne. Разработчики посчитали это все “не багами”, а репорты были закрыты в статусе “informative”, дважды!
Информация
- В рейтинге
- Не участвует
- Откуда
- Харьков, Харьковская обл., Украина
- Дата рождения
- Зарегистрирован
- Активность