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



Под инструментом тайм-менеджмента я подразумеваю некие действия со своими задачами, которые приводят к увеличение свободного времени или сокращению времени на задачу (что суть есть одно и тоже = высвобождение времени).

Несколько вещей гарантированно будут увеличиваться со временем: расстояния между звёздами, энтропия вселенной и бизнес-требования к ПО. Многие статьи пишут «Не усложняйте!», но не пишут почему или как это сделать. Вот вам 10 ясных примеров.

1. Инженерам виднее

Мы, инженеры, считаем себя умнейшими людьми. Ну, поскольку мы создаём разные штуки. И эта ошибка часто приводит к оверинжинирингу. Если вы спланировали и построили 100 модулей — Бизнес всегда попросит у вас 101-ый, о котором вы никогда не задумывались. Если вы соберётесь с силами и решите 1000 проблем — они придут к вам и выложат на стол 10 000 новых. Вы считаете, что у вас всё под контролем, а на самом деле вы даже не представляете, в каком направлении вас завтра поведёт дорога.



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

Мораль: Казино (бизнес) всегда побеждает.

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

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

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.

Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.

Kate: What are they, Billy?
Billy Peltzer: They're gremlins, Kate, just like Mr. Futterman said.

Все помнят этот фильм? Какого черта он делает на Хабре? И вообще что тут делает подобный пост?
Наверное потому, что я считаю главным звеном в IT все таки человека, а точнее его мозги. Я попробую рассказать еще об одной возможности использовать свой мозг чуточку эффективнее. Одна из слабо задокументированных возможностей, которую мы используем каждый день, но не всегда даже об этом вспоминаем. Все описанное проверялось на мне. Если что-то я не пробовал, но рассказать об этом важно буду отмечать особо. Никаких наркотиков, аппаратов и издевательств над собой, только общедоступные легкие методики (короче, лег проспался и вперед, не вставая даже с кровати).
И да… Это до жути реалистично, на столько, что попробовав, вы не сможете не рассказать об этом.

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

Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

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

От переводчика: Это перевод статьи авторства Джоэля Спольски (Joel Spolsky). Через 2 года эта статья уже сможет получить автомобильные права в США, а еще через два — и не только там. Да, ей 14 лет (а точнее 14 лет и 11 дней), но актуальности она не потеряла ни грамма. Я регулярно вижу, как программисты (да и я сам, временами) порываются наступить на эти грабли. Тот факт, что я не нашел ее перевода на Хабре, вполне может свидетельствовать о том, что я плохо искал. Об ошибках перевода прошу сообщать в ЛС

UPD: Оказывается перевод статей Джоэля, в т. ч и этой, есть еще в бумажном издании «Джоэл о программировании»

Наконец выходит первая публичная бета-версия Netscape 6.0. Версии 5.0 не существует. Предыдущий мажорный релиз — версия 4.0 — был выпущен почти три года назад. Три года — это невероятно большой срок в мире интернета. Все это время в Netscape сидели и беспомощно наблюдали за тем, как уменьшается их доля рынка.

Это немного подло с моей стороны критиковать их за столь долгое ожидание между релизами. Они ведь не специально это сделали, правда?

Недостаточно иметь хороший ум, главное правильное его использовать.
Рене Декарт

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

Мозговое шевеление — нелегкое занятие. Часто мы только думаем, что думаем, а на самом деле мы манипулируем фактами, придаем им различные толкования, забываем о факторе времени, расширяем единичные случай на целый класс явлений, выдаем желаемое за действительное, придумываем что-то, чего в действительности нет, и вообще создаем ментальные модели, которые лишь отдаленно напоминают реальный мир. Имея все это многообразие заблуждений в своем воспаленном мозгу — мы принимаем неправильные решение, которые создают новые проблемы, те в свою очередь, искажают обратные связи и приводят нас к еще более дурным суждениям, и с каждым новым витком мы все дальше отдаляемся от истины. Поэтому, каждый из нас, тащит на своем горбу груз ранее принятых решений. Хорошо, когда их можно списать, хуже, когда приходиться за них платить. Платить и каяться:«Боже… как я был глуп!»

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