Ну вот я такой инженер. Я радостно и незамутнённо, воззрев, внедрял TDD, BDD, Docker, CI, ELK, DevOps, микросервисы, бессерверную архитектуру, impact mapping, в самые неподходящие проекты на самых неподходящих стадиях. Разработчиков проектов было чаще всего... 1.
С Docker-ом я бегал еще во время версии 1.5, kubernetes раскопал когда он еще только вылупился из Гугла, docker cloud разворачивал, когда он еще был tutum.
Сколько реально нужных фич не было выпущено, сколько метрик не собрано, рекламных кампаний сорвано из-за опозданий с релизами? Немеряно.
Психологическое основание: «если все сделать правильно, то всё будет хорошо». И чем больше знаешь о том, как можно сделать правильно, как сделано «у больших», на которых ты равняешься — тем больше замахиваешься.
Крч, с точки зрения продуктовой разработки — золотые слова.
Опасайтесь инженеров с мышлением "крупной компании" — на любой стадии работы над стартапом. Такие люди нужны уже когда компания вырастает из понятия стартап, т.е. когда найден пресловутый product-market fit и нужно закладывать надёжный каркас.
А хороший инженер, это тот, кто может сделать работающую систему из спичек и желудей и с любым количеством ресурсов. Плохой же начнёт сразу крутить велосипеды и всё развалится ещё до MVP.
Фишка в том, что до поиска product/market fit программировать бы вообще надо по минимуму. Это очень сложно было в себе отдирать, но не надо. Надо быстро проверять гипотезы и разговаривать с клиентами, и научиться доставать клиентов
Вы не просто капитан-очевидность, вы прямо таки адмирал - ясен х#й.
Но тем не менее большое вам спасибо, за краткое и емкое изложение.
Комментарий недоступен
Зря вы так - в подборке известных фактов есть определенная ценность! Даже авторское право защищает сборщиков БД
1/ Опасайтесь хороших инженеров.Опасайтесь категоричных утверждений, использующих неясные термины.
Ну вот я такой инженер. Я радостно и незамутнённо, воззрев, внедрял TDD, BDD, Docker, CI, ELK, DevOps, микросервисы, бессерверную архитектуру, impact mapping, в самые неподходящие проекты на самых неподходящих стадиях. Разработчиков проектов было чаще всего... 1.
С Docker-ом я бегал еще во время версии 1.5, kubernetes раскопал когда он еще только вылупился из Гугла, docker cloud разворачивал, когда он еще был tutum.
Сколько реально нужных фич не было выпущено, сколько метрик не собрано, рекламных кампаний сорвано из-за опозданий с релизами? Немеряно.
Психологическое основание: «если все сделать правильно, то всё будет хорошо».
И чем больше знаешь о том, как можно сделать правильно, как сделано «у больших», на которых ты равняешься — тем больше замахиваешься.
Крч, с точки зрения продуктовой разработки — золотые слова.
> 1/ Опасайтесь хороших инженеров.
Опасайтесь инженеров с мышлением "крупной компании" — на любой стадии работы над стартапом. Такие люди нужны уже когда компания вырастает из понятия стартап, т.е. когда найден пресловутый product-market fit и нужно закладывать надёжный каркас.
А хороший инженер, это тот, кто может сделать работающую систему из спичек и желудей и с любым количеством ресурсов. Плохой же начнёт сразу крутить велосипеды и всё развалится ещё до MVP.
Фишка в том, что до поиска product/market fit программировать бы вообще надо по минимуму. Это очень сложно было в себе отдирать, но не надо. Надо быстро проверять гипотезы и разговаривать с клиентами, и научиться доставать клиентов