L>Дело в том, что обе компании, были образованы в середине 2000-ых. Т.е. на момент найма им было >5 лет. То что одна не промасштабировалась, и не наладила процессы — говорят их рейты, сотрудники и в целом бизнес модель. 2-ая компания может позволить себе сеньоров, за счет модели — подписка на месяц, у первой — фиксед-прайс и толпа индусов в штате.
Тяжело сказать что лучше: с одной стороны первая компания может позволить 3-их человек вместо одного.
Все же склоняюсь к мысли что вторая компания не совсем правильно распределяет свои ресурсы потому что иметь в штате одних 10+ синьоров с точки зрения бизнеса не совсем эффективно, если это не какой то космический софт.
Здравствуйте, licedey, Вы писали:
L>С апворком лучше не шутить, строго все там. По 3 чела с одного акка — низя, теперь то вы знаете.
Его не закрыли, просто акк узурпирован человеком. Год назад организовал новый — на каждый отлик непривычная тишина.
L>Вы хотя бы загляните в раздел rsdn/предложения от работодателей, там куча достойных фирм и удаленки. Вторым вариантом выкладываем резюме на любой hh-подобный сайт,
На рсдне 2 подходящие вакансии в квартал, в большинстве случаев с бомж-зп.
L>с пометкой "удаленную работу". Да сейчас столько всяких сервисов, линкединов всяких, что отговорка может быть только одна — лень.
На хх как раз в основном бомж-зарплаты и говноконторы. На линкедине нужны обычно нормальные нэтивы(знаю, но нэтива изобразить не могу), а ненормальные — привет ХХ.
L>Газпром? Дети гендира? Незнаю таких...
Много, на раннем этапе говнокод не критичен. Т.е. я множество продуктов видел с говнищем внутри, но которое реально приносит деньги тому, кто это написал.
Здравствуйте, landerhigh, Вы писали:
CEM>>Т.е. стартапов нет. Откуда тогда выводы, как надо делать правильно?
L>Надо же, два предложения, два утверждения, и оба абсолютно неправильные.
А я, с теми же доказательствами, говорю, что абсолютно правильные
Не, я не против agile и я использую в работе юнит-тесты и очень рад, они сэкономили мне и другим кучу времени. Меня просто насторожило упорное (заученное?) цитирование "как надо" делать, в том месте, где юнит-тесты не нужны, даже просто из соображений здравого смысла. Поэтому я спросил про реальный опыт стартапов.
Здравствуйте, CEMb, Вы писали:
L>>Надо же, два предложения, два утверждения, и оба абсолютно неправильные. CEM>А я, с теми же доказательствами, говорю, что абсолютно правильные
И где же?
Вот два моих утверждения:
T>Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
Такой стартап закапывать можно сразу.
Это доказательства не требует.
И второе:
Скрам, кстати, без юнит-тестов вообще не работает.
А больше я ничего не утверждал. Особенно в части "как делать правильно".
Ты все сам додумал.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, licedey, Вы писали:
L>>С апворком лучше не шутить, строго все там. По 3 чела с одного акка — низя, теперь то вы знаете.
IT>Его не закрыли, просто акк узурпирован человеком. Год назад организовал новый — на каждый отлик непривычная тишина.
L>>Вы хотя бы загляните в раздел rsdn/предложения от работодателей, там куча достойных фирм и удаленки. Вторым вариантом выкладываем резюме на любой hh-подобный сайт,
IT>На рсдне 2 подходящие вакансии в квартал, в большинстве случаев с бомж-зп.
L>>с пометкой "удаленную работу". Да сейчас столько всяких сервисов, линкединов всяких, что отговорка может быть только одна — лень.
IT>На хх как раз в основном бомж-зарплаты и говноконторы. На линкедине нужны обычно нормальные нэтивы(знаю, но нэтива изобразить не могу), а ненормальные — привет ХХ.
L>>Газпром? Дети гендира? Незнаю таких...
IT>Много, на раннем этапе говнокод не критичен. Т.е. я множество продуктов видел с говнищем внутри, но которое реально приносит деньги тому, кто это написал.
В вас говорит отчаяние, как у меня было неделю назад в ветке "Куда уходят фрилансеры". Отдохнуть надо и видимо поискать что-то другое. Я на том же рсдн'e на 2 интервью уже подписался, в хорошие компании на удаленку.
Да и все аргументы выше, потому что вы вероятно не знаете, что такое хорошая компания, большой рейт и контроль качества на любых этапах.
Здравствуйте, turbocode, Вы писали:
L>>Дело в том, что обе компании, были образованы в середине 2000-ых. Т.е. на момент найма им было >5 лет. То что одна не промасштабировалась, и не наладила процессы — говорят их рейты, сотрудники и в целом бизнес модель. 2-ая компания может позволить себе сеньоров, за счет модели — подписка на месяц, у первой — фиксед-прайс и толпа индусов в штате.
T>Тяжело сказать что лучше: с одной стороны первая компания может позволить 3-их человек вместо одного. T>Все же склоняюсь к мысли что вторая компания не совсем правильно распределяет свои ресурсы потому что иметь в штате одних 10+ синьоров с точки зрения бизнеса не совсем эффективно, если это не какой то космический софт.
Co. #1. 3-х индусов с глючным софтом и потерей репутации как компания. Оборот ~500к $. Системный софт — антималваре.
Co. #2. Может и не совсем правильно, много погоняйла было про бюджет и в какой мы ж.. сейчас, поэтому ушел. Но с точки зрения девелопера, зарплаты — это был отличный кейс. Оборот >60mln$. Софт — обычный энтерпрайз, для малого-среднего бизнеса.
L>Co. #1. 3-х индусов с глючным софтом и потерей репутации как компания. Оборот ~500к $. Системный софт — антималваре.
В системниках обычно зверские отделы QA и там кумарам бессонные ночи обеспечены на 100%.
L>Co. #2. Может и не совсем правильно, много погоняйла было про бюджет и в какой мы ж.. сейчас, поэтому ушел. Но с точки зрения девелопера, зарплаты — это был отличный кейс. Оборот >60mln$. Софт — обычный энтерпрайз, для малого-среднего бизнеса.
Для энтерпрайза качество кода редкость, а плач о бюджетах это своего рода ритуал в бизнесе — так что зря ты ушел.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, CEMb, Вы писали:
L>>>Надо же, два предложения, два утверждения, и оба абсолютно неправильные. CEM>>А я, с теми же доказательствами, говорю, что абсолютно правильные
L>И где же?
Там же где и твои, ты их не привёл, я их тоже не привёл. Почему ты думаешь, что то, что ты говоришь — сразу правда?
L>Вот два моих утверждения: L>
T>>Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
L>Такой стартап закапывать можно сразу.
L>Это доказательства не требует.
Ясно. Ты не прав, и это точно так же доказательства не требует.
И страртапов у тебя не было
L>И второе:
L>
L>Скрам, кстати, без юнит-тестов вообще не работает.
L>А больше я ничего не утверждал. Особенно в части "как делать правильно". L>Ты все сам додумал.
Я ничего не додумывал, у меня не было вопросов к скраму и юнит-тестам, это ты сам додумал.
У меня вопрос был и остался к: "Такой стартап закапывать можно сразу", т.е. такой стартап получается "неправильный"? Почему? Где твой опыт по ведению стартапов, чтобы это утверждать. Априори: чтение и цитирование книг по agile — не есть опыт по ведению стартапов. Что сложного? Я просто прошу пример: "мы делали то-то и так-то, стартап завалился, причина в том, что архитектура менялась каждый день, потому что: <список последствий>".
IT>Функции — это фигня, главное, чтобы по регионам внутри функций было все хорошо разбито. IT>Регионы — это фигня, главное, чтобы по блокам было все хорошо разбито. IT>Блоки — это фигня, главное, чтобы по строчки с пробелами между кодом хорошо разбивали. IT>и тд тп.
Если ты хочешь продолжать работать программистом, то мозги так или иначе напрягать прийдется. Пока что у меня сложилось впечатление, что ты хочешь прийти и начать писать с нуля int main()... В большинстве случаев так не будет.
IT>Уважаемый, я понимаю, что вы — савант и легко держите в уме классы с гигантским контрактом и кучей обязанностей, но большинство людей вроде меня не обладает столь выдающимися способностями.
Читай выше. Более того, у меня опять складывается впечатление, что ты не умеешь сконцентрироваться на какой-то конкретной задаче в рамках существующего кода.
IT>Пожалейте нас. Не пишите так.
Все хорошо в меру. Я там выше привел пример из реального фреймворка где чуваки разбили код, определяющий является ли строка имйелом, как минимум на три класса. Поэтому скажу тебе твоими же словами: пожалей нас. Не пиши так.
L>>>Это доказательства не требует. CEM>>Ясно. Ты не прав, и это точно так же доказательства не требует.
L>Я прав и это знает любой, кто работал на реальных проектах.
На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали) где требования бизнеса часто менялись (писали код считай с колес), а бизнес аналитиков не было (и времени не было) в итоге все сваливалось на программистов (ну ты ж программист!) — могу сказать что было очень сложно работать, но провала никакого не было.
Здравствуйте, turbocode, Вы писали:
T>На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали)
Исходя из даты регистрации, в выделенное поверить сложно.
T>где требования бизнеса часто менялись (писали код считай с колес), а бизнес аналитиков не было (и времени не было) в итоге все сваливалось на программистов (ну ты ж программист!) — могу сказать что было очень сложно работать, но провала никакого не было.
Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли.
Здравствуйте, landerhigh, Вы писали:
CEM>>Ясно. Ты не прав, и это точно так же доказательства не требует.
L>Я прав и это знает любой, кто работал на реальных проектах.
1. Ты видишь разницу между реальными проектами и стартапами? При чём тут реальные проекты? Речь про стартапы.
2. Пока не вижу ни одного человека, работавшего над реальными проектами, который знает, что ты прав. Если найдётся такой человек, я задам ему этот вопрос.
3. Ты не прав, говорю, как человек, работающий над реальными проектами, которые работают на реальных предприятиях.
L>Переходы на личности поскипаны.
Где там переходы на личности? Есть только отсылка к опыту, который к личности отношения не имеет.
Я задал тебе простейший вопрос: приведи пример провала стартапа, где архитектура меняется каждый день? Если такого примера нет, твоё утверждение про то, что такой стартап надо закапывать — ложно и непонятно, на чём основано.
В общем, пока вижу у тебя какие-то отговорки. Не надо ссылаться на любых людей, которые работали над реальными проектами, но ничего про тебя не слышали и эту тему не читали, поэтому мнение их неизвестно. И другие странные доводы тоже не надо. Просто пример, если есть. Если нету примера, скажи: "нету", и у меня не будет вопросов. В чём сложность-то?
Здравствуйте, CEMb, Вы писали:
L>>Я прав и это знает любой, кто работал на реальных проектах. CEM>1. Ты видишь разницу между реальными проектами и стартапами? При чём тут реальные проекты? Речь про стартапы.
Демагогия.
CEM>2. Пока не вижу ни одного человека, работавшего над реальными проектами, который знает, что ты прав. Если найдётся такой человек, я задам ему этот вопрос.
Демагогия.
CEM>3. Ты не прав, говорю, как человек, работающий над реальными проектами, которые работают на реальных предприятиях.
Пальцы. И демагогия.
L>>Переходы на личности поскипаны. CEM>Где там переходы на личности? Есть только отсылка к опыту, который к личности отношения не имеет. CEM>Я задал тебе простейший вопрос: приведи пример провала стартапа, где архитектура меняется каждый день? Если такого примера нет, твоё утверждение про то, что такой стартап надо закапывать — ложно и непонятно, на чём основано.
За доказательством отсутсвия бога — в соседний форум.
За примерами стартапов, пожалуйста, к кодеру с турбонаддувом.
T>>На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали) L>Исходя из даты регистрации, в выделенное поверить сложно.
в те далекие времена здесь можно было писать без регистрации.
L>Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли.
Здравствуйте, turbocode, Вы писали:
L>>Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли. T>Меняли часто но тогда это не казалось трагедией.
Ты перестань называть обычную итеративную разработку с постоянной адаптацией к меняющимся требованиям "изменениями архитектуры" и непонятки исчезнут.
Изменение архитектуры — это когда ввалившийся с мороза тимлид молвит человеческим голосом, что реляционную субд выбрасываем и пишем свою объектную. Впрочем, при правильном изначальном выборе абстракции вам будет пофиг, где данные хранятся.
Или вместо локального Windows UI заказчик резко возжелает вебморду. При правильном подходе архитектура основной части системы не изменится.
Арзхитектуру в корне приходится менять лишь в одном случае — когда полностью провафлили задачу и выбрали изначально неработоспособный подход. Все остальное — мелкие рабочие вопросы.
