Пол Грэм: «Будьте неустанно находчивы» (relentlessly resourceful)

image
На фото — Терри Фокс, пробежал 5 373 км за 143 дня, без перерыва.

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

Оригинал — Relentlessly Resourceful
(За перевод спасибо Andrew Tchernov)

Пару дней назад я наконец-то нашел способ описать хорошего основателя стартапа: неустанно находчив (relentlessly resourceful).

До этого лучшим, что мне удавалось сформулировать, это свести противоположные качества к одному – несчастный. Большинство словарей говорят, что это значит отсутствие успеха, удачи. Но словари не сослужат хорошей службы в данном случае. Команде, которая обыгрывает своих соперников, но проигрывает из-за судьи, не повезло, но она не несчастная. Этот термин скорее подразумевает пассивность, быть несчастным значит быть размазанным обстоятельствами — прогнуться под окружающий мир, когда нужно идти по своему пути.[1]

К сожалению, нет антонима к слову несчастный, и это мешает объяснить основателям стартапов к чему они должны стремиться. «Не будь несчастным» это что-то больше похожее на крик безысходности.

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

К сожалению это всего лишь метафора, причем бесполезная для большинства людей за пределами США. «Будь подобен бегуну спиной вперед», не лучше чем «Не будь несчастен».

Но, наконец, я придумал, как выразить это качество. Я писал речь для инвесторов, и мне надо было объяснить, на что надо обращать внимание в организаторах стартапов. Каким должен быть человек в противоположность несчастному? Неустанно находчивым. Не только неустанным. Этого недостаточно чтобы заставить события развиваться согласно вашему плану, ну может кроме пары неинтересных ситуаций. В интересной же – сложности будут нестандартными. Что значит, что вы не сможете просто пробиться через них потому, что вы изначально не знаете насколько они сложны; вы не знаете, где будете пробиваться через кусок пены, а где – через гранит. Поэтому вы должны быть находчивы. Вы должны стараться находить новые решения.

Будьте неустанно находчивы.
(далее…)

10 ошибок, которые мы неосознанно совершаем, используя язык тела

image

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

Все врут, а ты не ври, или Развенчание мифа о запоминании

Сколько человек запоминает после пройденного им обучения? Обучаемый в среднем запоминает 10% прочитанного, 20% услышанного, 30% увиденного … 90% того, что сделал сам. Многие сталкивались c этими цифрами. Они приводятся отдельно или часто совмещаются с так называемой пирамидой обучения или конусом опыта. И все было бы хорошо и замечательно, если бы этими цифрами не был заполнен весь интернет, а сами они не являлись обманом и мистификацией.

Все врут, а ты не ври, или Развенчание мифа о запоминании - 1
(далее…)

О том, что убивает продуктивность разработчиков

О том, что убивает продуктивность разработчиков - 1

В свете того, что Мегамозг вновь воссоединился с Хабром, теперь можно ожидать, что аудитория обоих порталов также объединилась. Логично будет предположить, что Хабр будет привлекать большее внимание менеджеров, которым не чужд мир современных технологий. Поэтому наша команда SmartProgress решила подготовить статью на перепутье разработки и управления проектами.

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

Gchat был мессенджером будущего, но Google этого не понял

Gchat был мессенджером будущего, но Google этого не понял - 1
Эх, старые добрые дни

В последнее время все говорят о Slack. Приложение для чата, которое нацелено главным образом на офисное использование и продуктивность, простое, хорошо спроектированное, удобное в использовании и мощное. Slack — это ещё и компания, по которой все сходили с ума в 2015 году (компания года по версии журнала Inc.). Нравится вам их программа или нет, но пришло время признать одну вещь: Slack — это в точности Gchat.
(далее…)

Должны ли стартапы фокусироваться на прибыли?

Очень полезная статья как для инвесторов, которые проводят оценку молодых компаний для финансирования, так и для предпринимателей, которые хотят привлечь венчурный капитал и превратить свою компанию в крупную корпорацию. Марк Састер, партнер Upfront Ventures, раскладывает по полочками экономику стартапа и объясняет, как оценить прибыльность проекта.

image

Марк Састер:

Меня поражает, когда журналист пишет статью о перспективном стартапе (например, готовящемся к публичному размещению акций), и презрительно выдает: «Они даже не приносят прибыли!». (далее…)

Как доводить до конца долгосрочные цели

Данная статья является продолжением к самым важным советам по повышению продуктивности: «Личная продуктивность (только проверенные на себе подходы)».

В прошлых статьях мы говорили о том, как правильно поставить перед собой долгосрочные цели, — назовем это уровнем стратегии. Мы уже поговорили о том, как эффективно проводить микроменеджмент своих задач и доводить проект до конца. Назовём этот уровень тактическим. Сегодня я хочу рассказать о том, как правильно связать эти уровни между собой, чтобы то, что делается на тактическом уровне, связалось со стратегическим уровнем. Очень часто именно этот аспект подкашивает молодых адептов моих советов. Кажется продуктивность выросла и долгосрочные цели стоят правильные, но почему-то в конце квартала/года понимаешь, что сделано намного меньше, чем хотелось. Если вам это знакомо, то сегодня я расскажу почему так происходит и как с этим бороться.

Для примера я взял ОЧЕНЬ упрощенный кейс (личный давний опыт), который мне помог найти мою первую работу в большой международной компании на позиции Android-разработчик.

Данная статья подготовлена на базе нащего скринкста комманды Java Hexlet, выпуск №3. Посему, если вы слушали скринкаст, то можете смело проигнорировать статью.
(далее…)

Как стать самым продуктивным инженером в команде

Данная статья является продолжением к самым важным советам по повышению продуктивности: «Личная продуктивность (только проверенные на себе подходы)».

В прошлых статьях мы говорили о том, как правильно поставить перед собой долгосрочные цели, — назовем это уровнем стратегии. Мы уже поговорили о том, как эффективно проводить микроменеджмент своих задач и доводить проект до конца. Назовём этот уровень тактическим. Сегодня я хочу рассказать о том, как правильно связать эти уровни между собой, чтобы то, что делается на тактическом уровне, связалось со стратегическим уровнем. Очень часто именно этот аспект подкашивает молодых адептов моих советов. Кажется продуктивность выросла и долгосрочные цели стоят правильные, но почему-то в конце квартала/года понимаешь, что сделано намного меньше, чем хотелось. Если вам это знакомо, то сегодня я расскажу почему так происходит и как с этим бороться.

Для примера я взял ОЧЕНЬ упрощенный кейс (личный давний опыт), который мне помог найти мою первую работу в большой международной компании на позиции Android-разработчик.

Данная статья подготовлена на базе нащего скринкста комманды Java Hexlet, выпуск №3. Посему, если вы слушали скринкаст, то можете смело проигнорировать статью.
(далее…)

Система финансирования и управление Dash

image

Когда интегрированная система само-финансирования криптовалюты Dash была впервые представлена публике, создатель Dash (Эван Даффилд) назвал её “Децентрализованное управление с помощью блокчейна” или “DGBB”. Это отличное название, но так ли это на самом деле? Является ли система бюджетирования способом управления?

Прежде всего, я думаю, что бюджетное финансирование невероятно важно. Насколько я знаю, Dash является единственной криптовалютой, которая сама финансирует свои собственные разработки без привлечения пожертвований (которые редки и непостоянны) или централизованного финансирования (такие организации, как Blockstream и MIT, играют значительную роль в разработке Биткойна). Так так Dash стал самофинансируемым проектом, то можно быть уверенными в том, что он неподконтролен чьим-либо сторонним интересам. Более того, можно быть уверенными в том, что он продолжит стабильно развиваться. Все разработчики Dash — хорошие люди и специалисты (это моё мнение), но они все в конечном итоге хотят получить вознаграждение за свою работу. Некоторое вознаграждение может сформироваться за счёт удорожания их инвестиций в проект, но это может занять многие годы. Выплачивая разработчикам Dash “зарплату” (хоть пока и маленькую), Децентрализованная Система стимулирует их продолжать разработку, а кроме того — она становится привлекательной для новых разработчиков.
(далее…)

Таких не берут в программисты: «реверс-инжиниринг» личности

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

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

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

Справедливости ради предлагаем поискать альтернативные пути, мнения и рецепты. Возможно, это натолкнет на определенные инсайты людей, ищущих истину или испытывающих трудности в данный момент. (далее…)