• Маленькие задачи, а доверия ещё меньше

    • Translation


    Почему делегирование обязанностей лучше, чем распределение задач


    Доверие — высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

    Стивен Р. Кови, «Семь навыков высокоэффективных людей»

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

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

    «Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
    и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M».

    Самое важное здесь то, что A и B были крупными задачами, например, целыми продуктами или большими системными библиотеками. На их создание и поддержку уходило всё твоё время. Они были делегированной ответственностью, а не просто задачами. Было просто при этом и управлять людьми. Если ты не справляешься, то начальник тебе об этом скажет.
    Читать дальше →
    • +43
    • 7.4k
    • 8
  • Когда за повышением зарплаты каждый месяц ходит робот



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

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

      Разработчики традиционно пользуются способом №2: сначала проходят где-то несколько собеседований, собирают офферы и приходят с ними к руководителю. «Смотри, вот тут мне предлагают на 20% больше, но мне у нас нравится, повышай на 15%, а то я перейду». Это уже предмет обсуждения. В банальном случае проще повысить и сохранить ценного сотрудника, но это обеспечит проигрыши в связанных играх. То есть создаст прецедент. Поэтому решение принимается (в упрощённой модели) с некоторой долей рандома.

      У нас у многих математика в анамнезе. Рассматривая эту игру дальше, можно сделать простой вывод, что такой диалог для сотрудника всегда стрессовый, и он случается в момент после кризисного. То есть сначала человек беспокоится, потом делает потенциально невыгодные действия (проходит собеседования в других местах), потом приходит. Части надо повышать, части не надо. Следующий вопрос: можно ли найти функцию, которая обеспечит справедливую оценку? Будет ли эта функция снимать вот эти стрессовые ситуации?

      Регулярная переиндексация каждый год — вариант такой функции. Условно, если в договоре прописано, что зарплата каждый год растёт на уровень инфляции — наверное, можно не беспокоиться. Но Вадим придумал более интересную фишку — привязать это к оценке полезности действий сотрудника для компании. Но как адекватный человек, без KPI.

      Читать дальше →
    • Хроники пэйджинга

      Вот и меня посетило желание что-нибудь написать для читателей Хабра. Чем же ещё заняться в отпуске?


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

      Читать дальше →
    • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код


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


        Я подумал — ну окей, так, наверное, бывает не всегда. С тех пор прошло лет 5, я не раз менял работу, но везде и всегда созвоны были пустой тратой времени.

        Читать дальше →
      • Тёмная тема vs Светлая тема: что лучше?

        • Translation


        Примечание переводчика: тёмная тема в дизайне интерфейсов к 2020 году стала чуть ли не обязательной. Вслед за Apple и Android на поезд Dark Mode «впрыгнули» и другие крупнейшие игроки рынка (например, Google, What’s App, Instagram). Тёмную тему любят по нескольким причинам:

        1. Она экономит расход батареи;
        2. Считается, что она снижает напряжение глаз, и с ней легче работать при слабом освещении;
        3. Некоторым она просто больше нравится.

        Но, оставив в стороне рассуждения об эстетике тёмной темы, так ли уж она полезна для глаз? На самом ли деле тёмная тема повышает продуктивность работы с текстом? Ралука Будиу (Raluca Budiu) из Nielsen Norman Group даёт исчерпывающие ответы.
        Читать дальше →
      • Хакерский фольклор

        • Translation

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

        Бо́льшая часть статьи взята из Википедии, но найти пояснения не так-то просто, если не знаешь, что искать.
        Читать дальше →
      • Пора на свалку


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


          Я тут на днях смотрел на свою RSS-читалку и заметил, что под тегом «C++» у меня где-то три сотни непрочитанных статей. Я не прочитал ни одной статьи по плюсам с прошлого лета, и мне офигенно. Я не написал ни строчки осмысленного кода на плюсах за последние три месяца, с тех пор, как распустили отдел, где я работал, и мне просто супер. Я позволил себе хотеть больше никогда не писать на плюсах, и у меня появились крылья.


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


          Короче, да, я выгорел. И я не знаю, что делать дальше.

          Читать дальше →
        • Нормализация девиантности. Как неправильные практики становятся нормой в нашей отрасли

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

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

          Есть компания, которая невероятно скрытно относится к своей инфраструктуре. Например, боится сообщать о багах поставщику оборудования, потому что тогда ошибки будут исправлены, а конкуренты смогут использовать исправления. Этого нельзя допустить. Решение: запросить прошивку и исправить баги самостоятельно! Нормально.
          Читать дальше →
        • Как SEO-оптимизация и алгоритмы Google уничтожили настоящий интернет

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



          Как SEO-оптимизация уничтожила интернет


          В промежутке между 1998 и 2003 годом поиск в Google был просто волшебным. Я помню, как вводил какую-то смутную комбинацию, типа «oil mother's milk» и в итоге попал на страницу Wired с интервью Томаса Голда, астрофизика, который рассказывал о том, что залежи углеводородов (oil) пополняются за счет давления внутри геологических пластов.

          Если вы сегодня ищете что-то техническое, конкретное, академическое или вообще — некоммерческое, то удачи вам. Лучшая в мире информационно-поисковая система превратилась в нечто, напоминающее Digg эры 2006 года: индексы популярности контролируются небольшим количеством финансово мотивированных игроков. Они называют себя «оптимизаторами».
          Читать дальше →
        • Кластер Elasticsearch на 200 ТБ+


            С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?


            Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.

            Читать дальше →
          • Что такое I в ACID или взгляд с другой стороны

            Прочитав этот пост, написанный farwayer, сначала хотел просто оставить комментарий, но, подумав пару десятков минут, решил, что тема глубокая, и мне есть что сказать на целый пост. Все таки, с одной стороны, я один из тех, кто на собеседованиях не смотрит на код и кого разочаровывает незнание оценки сложности поиска по индексу в реляционных СУБД, с другой, считаю, что могу дать понимание того, как мыслит достаточно большой кластер интервьюверов, зачем они поступают (на первый взгляд) нелогично и деструктивно, и какие проблемы сами хотят этим решить. Есть надежда, что понимание картины мира «врага» само по себе ответит на множество вопросов.
            Читать дальше →
          • Коты в коробочках, или Компактные структуры данных

            image


            Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?


            В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.


            А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
            [səkˈsɪŋkt]?

            Читать дальше →
          • Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина

              Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.


              Читать дальше →
            • Как оформлять коммиты, чтобы потом не было больно

              • Translation
              Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.
              Читать дальше →
            • Название имплементации и название результата

              • Translation


              Я хотел написать этот пост ещё в июле, но никак не мог, о ирония, решить, как его назвать. Удачные термины пришли мне в голову только после доклада Кейт Грегори на CppCon, и теперь я наконец могу рассказать вам, как не надо называть функции.


              Бывают, конечно, названия, которые вообще не несут информации, типа int f(int x). Ими пользоваться тоже не надо, но речь не о них. Порой бывает, что вроде бы и информации в названии полно, но пользы от неё абсолютно никакой.

              Читать дальше →
            • Чтобы пацанам было не стыдно показать

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

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

                Вот это главное качество: пытливый ум.
                Читать дальше →
              • Доказательное планирование

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

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

                Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»
                Читать дальше →
              • Большое интервью про Big Data: зачем за нами следят в соцсетях и кто продает наши данные?

                  Disclaimer. Специалист по Big Data, Артур Хачуян, рассказал, как соцсети могут читать наши сообщения, как наш телефон нас подслушивает, и кому все это нужно. Эта статья — расшифровка большого интервью. Есть люди, которые экономят время и любят текст, есть те, кто не может на работе или в дороге смотреть видео, но с радостью читает Хабр, есть слабослышащие, для которых звуковая дорожка недоступна или сложна для восприятия. Мы решили для всех них и вас расшифровать отличный контент. Кто всё же предпочитает видео — ссылка в конце.



                  Каждый день мы что-то пишем, разыскиваем и выкладываем в интернете, и каждый день кто-то следит за нами по ту сторону экрана. Специальные программы сканируют фото, лайки и тексты, чтобы продать наши данные рекламным компаниям или полиции. Можно назвать это паранойей или научной фантастикой, но телефон, круг общения, переписка или ориентация — больше не секрет.
                  Читать дальше →
                • Хороший разработчик мудр, а не гениален

                  • Translation


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


                  Хороший код выразителен, а не впечатляющ.

                  Я помню, как услышав это спросил «А в чём разница?», и получил ответ.


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


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


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


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


                  Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.

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




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


                  Читать дальше →
                • Сайзинг Elasticsearch



                    — How big a cluster do I need?
                    — Well, it depends… (злобное хихиканье)

                    Elasticsearch — сердце Elastic Stack, в котором происходит вся магия с документами: выдача, приём, обработка и хранение. От правильного количества нод и архитектуры решения зависит его производительность. И цена, кстати, тоже, если ваша подписка Gold или Platinum.

                    Основные характеристики аппаратного обеспечения — это диск (storage), память (memory), процессоры (compute) и сеть (network). Каждый из этих компонентов в ответе за действие, которое Elasticsearch выполняет над документами, это, соответственно, хранение, чтение, вычисления и приём/передача. Поговорим об общих принципах сайзинга и раскроем то самое «it depends». А в конце статьи ссылки на вебинары и статьи по теме. Поехали!
                    Читать дальше →