Здравствуйте, cppguard, Вы писали:



C>Очень похоже на мантру, которую любят повторять стартаперы: "Нам некогда проектировать, нам нужно скорее выйти на рынок". Но тогда со своей стороны я тоже могу спросить:
К сожалению это так, потому что количество времени ограничено. Особенно разработка ПО когда времени проектировать практически нет, пока будешь проектировать — уже другие сделают прототип или технологии на которых ты проектируешь станут не самыми конкурентными. Стартап — это считай ежемесячный хакатон, где нужно быстро показывать интересный результат, причем ты не один — у инвесторов в поле зрения еще куча проектов и тебе нужно практически постоянно быть лучшим, условно занимать на этом соревновании 1-3 места не по качеству кода, а по результату, чтобы привлечь очередные инвестиции и дать тебе же денег — бесплатно ты врятли согласишься поработать полгода чтобы хорошо написать код.


C>1. Зачем меня нанимать, если не уверен, что я смогу написать нормальный код вовремя?
C>2. Кто сказал, что переписать, работая по 8 часов, будет дольше чем говнокодить по 10 часов? Мой опыт говорит обратное.

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

Опять же ваш код лучше — это субъективно, например вы переписали чей-то говнокод, но человек уже привык к той структуре "где что лежит". Или вы добавили какой-то подход или библиотеку которая вам кажется удобной. А другой человек не знаком с ней, ему работать с ней не удобно. В итоге прийдя на работу вместо того чтобы двигаться дальше он сталкивается с тем что уже все поменяли и нужно снова разбираться с новой структурой — потеря времени. Особенно если это делать перед очередным показом инвесторам.

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

C>3. Почему ограничение — 10 часов? Почему не работать по 12 часов? 14 часов? Так ведь быстрее.
Нет так не быстрее. Мозг устает, отдыхать нужно иначе можно раньше времени сойти с дистанции.
Дело тут не уже в качестве кода, а в качестве отдыха и здоровья.

Здравствуйте, VladiCh, Вы писали:

VC>В небольших стартапах обычно не так. Во многих переработки по сути являются частью нормальной работы
VC>(это не говоря о том что в США для программистов на зарплате вообще нет понятия "оплачиваемые переработки").

Ну, в РФ "оплачиваемые переработки" тоже исчезающе редки, но дело не в них.
Дело в том, что руководство профакапило и переложило ответственность на рядовых. То есть кто-то наверху принял решение, что-то пошло не так — и теперь надо перерабатывать.
Это в корне не верно!
Вот если я налажаю — то это моя ответственность + ответственность вышестоящего руководства.
Если налажает мой падаван — то я, как джедай, несу часть ответственности. Но не наоборот!

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

Здравствуйте, Gradiens, Вы писали:

G>Ну, в РФ "оплачиваемые переработки" тоже исчезающе редки, но дело не в них.
G>Дело в том, что руководство профакапило и переложило ответственность на рядовых. То есть кто-то наверху принял решение, что-то пошло не так — и теперь надо перерабатывать.
G>Это в корне не верно!
G>Вот если я налажаю — то это моя ответственность + ответственность вышестоящего руководства.
G>Если налажает мой падаван — то я, как джедай, несу часть ответственности. Но не наоборот!

G>Если же в компании бойцы должны исправлять за свой счет ошибки генералов — ну ее нафиг.

В США в корне другой подход. Им с детства прививают мысль, что ошибаться нормально. Отчасти это правильно, потому что тогда люди не боятся пробовать браться за что-то неизвестное. Но есть и побочный эффект — они перестают думать критически, и могут совершить невероятно идиотский поступок, которого можно было бы легко не совершать, подумай они заранее. И в рабочем коллективе эти традиции сохраняются, поэтому работники косячат легко и непринуждённо, а расхлёбывают все. Но сказать вслух, что всей проблемы можно было бы избежать, если бы мистер Х немножко подумал головой и предпринял необходимые меры, нельзя — табу. Такого сразу считают токсичным и антиколлективным, хотя по-честному в США каждый сам за себя, и вертел он коллектив на одном месте. Например, один из бывших коллег по робопроекту устроился работать в Amazon, поработал там неделю, а потом ушёл в Facebook, потому что там больше предложили. И ему было всё равно на то, что в Amazon его приняли в команду и начали процесс планирования задач. Такая вот с(т)ранная Америка.

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

C>Я много раз думал про Москву, но всегда задаю себе один и тот же вопрос: это всё равно будет эмиграция со всеми её минусами, хоть и язык тот же, так почему бы тогда не обратно в США, где среди прочих детям и супруге комфортней живётся? Кто касается Гугла — от многих слышал противоположные отзывы. Более того, я слышал, что там нешуточные подковёрные игры. И вообще — после работы на другого гиганта в корпоряцию уже не тянет. Там как в болоте — сам того не желая, начинаешь покрываться тиной.

Я глядя на флаг решил, что ты в Штатах
Я бы посоветовал искать "русские" компании
Это, конечно, неквалифицированный совет — я никогда не работал в Штатах, и могу что-то упускать, но вот обратная комбинация — американская компани с отделом(или с одним из отделов) разработки в Москве — это прям отлично. Проверял на разных компаниях. Надеюсь, что такой микс похожим образом работает и в Штатах.
Может, кстати, есть еще какие-то народности с подходящей культурой — но тут уж я ничего не подскажу.

Здравствуйте, cppguard, Вы писали:

C>После этой работы я то ли подгорел, то ли утратил интерес к работе программистом и пытаюсь разобраться в себе. Что делать — искать нормальную работу, где люди компетентные и несут ответственность за код, который пишут, или смириться с тем, что soft skills захватили мир, и теперь кукушка хвалит петуха за то, что хвалит он кукушку?

Ты еще не работал с мудаками и психопатами владельцами бизнеса напрямую, а не ч/з буфер постановщиков, по контракту с начальником, который боялся что его подсижу.
В общем радуйся что распрощался с мудаками и САМ!!! выбирай тех с кем хотел бы работать, а негативный опыт, это опыт, что бы не наступать на грабли дважды.

Здравствуйте, cppguard, Вы писали:

C>Но этим я только заработал токсичную репутацию.

Точно не этим

C>И вот вопрос сообществу: что я делал не так? Ведь я:

Ты привел только некоторые факты, которые касались дела. А мягкие навыки это то, как ты отстаивал свою позицию, насколько внимательно слушал, насколько корректно критиковал или аргументировал.

C>А самое главное, я всем сердцем был за проект.

Часто бывает, что в одном человеке уживаются самые разные черты, через запятую.

C>После этой работы я то ли подгорел, то ли утратил интерес к работе программистом и пытаюсь разобраться в себе. Что делать — искать нормальную работу, где люди компетентные и несут ответственность за код, который пишут, или смириться с тем, что soft skills захватили мир, и теперь кукушка хвалит петуха за то, что хвалит он кукушку?

Софт скилы это как ты выстраиваешь рабочие отношения:
1. как ты берешь ответственность
2. как ты относишься к коллегам, команде, другим командам
3. как ты относишься к руководству, заказчику
4. как ты коммуницируешь, аргументируешь, критикуешь, относишься к аргументами, критике и тд

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

То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

Здравствуйте, goto, Вы писали:

mgu>>Если причина левая, то и проблема не в вас. Встречаются случаи, когда ожидают, что новый человек облажается.

G>Ну, тогда они за сомнительное равлечение заплатили неплохую по тогдашним меркам сумму — компенсацию за весь испытательный срок.

Так заплатили же не из своего кармана.

G>Я плохо представляю, как можно брать кадр с целью поиздеваться.

Некоторые любят "опускать" ещё на собеседовании.

G>Даже если такие прикольные садюжки встречаются, то, по логике, они должны как можно раньше начать кидаться говном, а при расставании вообще плеснуть от души. Конечно, в описываемом случае ничего подобного не было. В чем или ком там была проблема, я могу только предполагать, но не знаю и не узнаю, поэтому остается вспоминать это как курьез.

Причины могут быть самыми странными, включая "шеф не любит бородатых". Курьёз-то курьёзом, и хорошая работа находится, но осадок остаётся.

Здравствуйте, cppguard, Вы писали:

C>После этой работы я то ли подгорел, то ли утратил интерес к работе программистом и пытаюсь разобраться в себе. Что делать — искать нормальную работу, где люди компетентные и несут ответственность за код, который пишут, или смириться с тем, что soft skills захватили мир, и теперь кукушка хвалит петуха за то, что хвалит он кукушку?

Имхо, ты залез в не свою область ответственности.

Тебя наняли на процесс, а ты полез делать результат. Оно понятно, что ты хотел сделать как лучше. А им не нужно было как лучше, им можно было с той скоростью, с которой сами основатели в состоянии двигаться и пилить свой бюджет. То есть все что они говорили про "быстрее, выше, сильнее" можно было делить на 10.

Еще как вариант — могли подумать что уж слишком ты хорошо работаешь, щас научишься всему и запустишь стартап конкурент (кстати, вполне годная идея и предпочли распрощаться превентивно.

Здравствуйте, cppguard, Вы писали:

G>>Да, конечно, может получиться так что новый этап просто не получится реализовать из-за слишком накопившегося долга. Но альтернатива что сфейлиться можно прямо сейчас, что еще хуже.

C>Я вот прям прочитал это голосом своего босса. Но каким образом можно сфейлиться прямо сейчас, когда денег ещё хватает на два года? Инвесторы же не могут отозвать свои деньги.

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

Здравствуйте, Ikemefula, Вы писали:


I>То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

C>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

Это смотря что считать "решением". Можно вообще ничего не понимать в технике, зато нежно нанять cppguard, и он сделает, всей душой болея.

Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, Ikemefula, Вы писали:


I>>То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

C>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

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

Здравствуйте, cppguard, Вы писали:

C>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.
Решить-то может и можно, только без софтскилз об этом решении никто не узнает.

Здравствуйте, cppguard, Вы писали:

I>>То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

C>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

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

А вот без технических скилов — можно делегировать. Делегирование — софт скилл которым большинство вообще говоря не обладает. Управление — снова софт скилл.

Итого — без технической составляющей ты можешь делегировать. Без "мягкой" — вообще ничего, без вариантов.

Здравствуйте, Dym On, Вы писали:

C>>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.
DO>Решить-то может и можно, только без софтскилз об этом решении никто не узнает.

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

Хохма — буквально вчера товарищ привел кейс — работали вдвоём, но один из них об этом не знал

Здравствуйте, okon, Вы писали:

O>Здравствуйте, cppguard, Вы писали:

C>>Здравствуйте, Ikemefula, Вы писали:


I>>>То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

C>>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

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

То ли обсуждение сваливается в какой-то абсолют, где или все умеют находить общий язык со всеми, то ли я неправильно понимаю мягкость навыков. Умение обсудить задачу, составить план для меня не soft skills. Вот правильно подбирать слова, чтобы не ранить тонкую душу молодого разработчика, вместо прямого "вот тут, тут и тут будут проблемы в этом и в том случае — переписывай или бери на себя ответственность, если вдруг всё поломается" — то, как я понимаю современные soft навыки.

Здравствуйте, cppguard, Вы писали:

O>>Для того чтобы ты был дееспособен в такой ситуации требуется наличие "интерфейса" и правильной реализации взаимодействия с оружающими, если этого нет — то получается что толку от hard skills нет — их не возможно применить в проекте, т.к. взаимодействие с другими людьми начинают вызывает исключения и не работают.

C>То ли обсуждение сваливается в какой-то абсолют, где или все умеют находить общий язык со всеми, то ли я неправильно понимаю мягкость навыков. Умение обсудить задачу, составить план для меня не soft skills.

Вероятно у тебя своё понимание софт-скилов Умение обсуждать, планировать — софт скилы. Если ты не нашел общий язык с коллегами, как понять, что ты именно приносишь пользу а не наоборот?

> Вот правильно подбирать слова, чтобы не ранить тонкую душу молодого разработчика, вместо прямого "вот тут, тут и тут будут проблемы в этом и в том случае — переписывай или бери на себя ответственность, если вдруг всё поломается" — то, как я понимаю современные soft навыки.

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

Вопрос в том, как именно ты критикуешь. Например твоя фраза выше, что в кавычках, ощущается как неприятная. Ты руководитель, что бы говорить коллеге "переписывай" ?

Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, okon, Вы писали:

O>>Здравствуйте, cppguard, Вы писали:

C>>>Здравствуйте, Ikemefula, Вы писали:


I>>>>То есть, софт скилы это и есть профессионализм. Техническая часть — это малая часть профессионализма.

C>>>Очень спорное утверждение. Без технического профессионализма задачу не решить в принципе. Без soft skills — вполне возможно.

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

C>То ли обсуждение сваливается в какой-то абсолют, где или все умеют находить общий язык со всеми, то ли я неправильно понимаю мягкость навыков. Умение обсудить задачу, составить план для меня не soft skills.

Умение выразить мысль — это есть у всех этому учат еще в школе，это hard skill — знание слов, грамматики，умение строить предложение.

Умение донести мысль так чтобы не вызвать отторжения и не породить конфликт — вот это есть софтскиллс.

Здравствуйте, Ikemefula, Вы писали:

I>Вероятно у тебя своё понимание софт-скилов Умение обсуждать, планировать — софт скилы. Если ты не нашел общий язык с коллегами, как понять, что ты именно приносишь пользу а не наоборот?

Как он может найти с ними общий язык, если TC нацелен на "результат" — т.е. стремление сделать нормальный/годный продукт, а его "коллеги" нацелены на "процесс" — т.е. стремление получения бабла, а там уж как получится?

I>Вопрос в том, как именно ты критикуешь. Например твоя фраза выше, что в кавычках, ощущается как неприятная. Ты руководитель, что бы говорить коллеге "переписывай" ?

Это очень мягкие слова, в приличных конторах, где цель сделать недорого, но достаточно быстро и вполне качественно используется совсем другая лексика, и не просто так.
Например: "если ты это г..но сейчас не перепишешь, нашей конторе завтра 3.14здец!", как следствие человек сам всё прекрасно понимает, и если хочет работать в этой конторе, принимает соответствующие меры.

Я вижу это тяжело объяснить людям ориентированным на "процесс", коих сейчас наверно в IT процентов 99%, которые "пилят" хрен знает что, для хрен знает кого, и им главное побольше нежности в коллективе, да и про смузи надо не забыть.

Здравствуйте, 4058, Вы писали:

4>Здравствуйте, Ikemefula, Вы писали:

I>>Вероятно у тебя своё понимание софт-скилов Умение обсуждать, планировать — софт скилы. Если ты не нашел общий язык с коллегами, как понять, что ты именно приносишь пользу а не наоборот?

4>Как он может найти с ними общий язык, если TC нацелен на "результат" — т.е. стремление сделать нормальный/годный продукт, а его "коллеги" нацелены на "процесс" — т.е. стремление получения бабла, а там уж как получится?

Годный продукт и код который кажется тебе правильным — это две перпендикулярные оси.
Можно написать говнокод и продукт будет годным, можно написать код который тебе кажется правильным — но продукт будет говно в итоге.

4>Это очень мягкие слова, в приличных конторах, где цель сделать недорого, но достаточно быстро и вполне качественно используется совсем другая лексика, и не просто так.
4>Например: "если ты это г..но сейчас не перепишешь, нашей конторе завтра 3.14здец!", как следствие человек сам всё прекрасно понимает, и если хочет работать в этой конторе, принимает соответствующие меры.
Обычно наоборот — проблема не в том что код г-но и из-за этого конторе завтра 3.14здец, а проблема в том что код работает, а его кто-то хочет переписать правильно — и вот часто происходит конторе 3.14здец т.к. код стал красивым но порой не учитывает все ньюансы которые были в говнокоде. И потом пользователи сталкивают с проблемой который творитель добра не тестировал, т.к. не учитывал эту ситуацию. Даже при наличии автотестов риск остается.

4>Я вижу это тяжело объяснить людям ориентированным на "процесс", коих сейчас наверно в IT процентов 99%, которые "пилят" хрен знает что, для хрен знает кого, и им главное побольше нежности в коллективе, да и про смузи надо не забыть.
Процесс — это как раз красивый код, а результат — это чтобы работало правильно.