А как Вы попали на собеседование в такие компании? Обычно ведь представители компании приглашают на собеседование. Если женщин не берут, то зачем звать то..
Это называется позитивной дискриминацией, и часто она бывает не менее обидной для человека, чем негативная.
Так а без этой позитивной дискриминации у девушки будет ощущение, что есть негативная дискриминация… Мужчины же друг с другом не любезничают. И стажёр-парень может с гораздо большей вероятностью, чем стажёр-девушка, услышать, что он на совещании только для того, чтобы доску протирать… Тут даже не важно в шутку или всерьёз это скажут. Для мужчины услышать такое — повод прокачивать навыки, а для женщины — повод обидеться на дискриминацию.
Много будет не библиотек, а "личных экспериментов начинающих разработчиков".
Я для себя вывел правило больше не публиковать пакеты, которые я сам не использую в реальных проектах на production. Имхо, от соблюдения этого правила всем будет только лучше.
Имхо, это всё слегка надумано… Более 90% программистов не пишут библиотеки, а те, кто пишет, разберутся с публикацией по официальной документации без проблем.
Всякие обучающие статьи и лабораторки на эту тему не нужны от слова "совсем". Они только стимулируют помойку аля npm.
В этом плане vozhd99 правильно отметил, что хоть в названии статьи указана "дистанционная работа", по факту статья про предпринимательскую деятельность.
Со схемой "работаю по трудовому договору из дома" и так всё понятно, там просто фикс.зарплата за вычетом 13%. Отпуск, праздники, больничные и т.д. — всё оплачивается и на net не влияет.
Для предпринимательства всё по другому, и там net = 0.6 * gross, а не 0.87, но зато gross существенно выше.
Есть разные варианты. Если у Вас обычный рабочий день, только дома, то Вы — дистанционный наёмный сотрудник. Так можно работать с российскими компаниями, а зарубежные Вас в штат брать не будут и оплата будет либо попроектная (для мелких типовых заказов), либо почасовая (только время, потраченное на решение задач).
У патентов есть ограничения в зависимости от региона пребывания.
А в целом Ваш расчёт неплох. Единственное, что Вы забыли — это вынужденный простой, допустим когда один проект закончился, а второй ещё не начался… или даже внутри одного проекта такое бывает… или вообще из-за собственной прокрастинации. Это ещё около 10% в минус. Так что диапазон я бы указал 50-70%, а мат.ожидание: net = 0.6 * gross
И поскольку в России принято указывать именно net-зарплату правильно писать так:
"что соответствует рейту от 30 до 50$/час ($3000-5000 в мес.)" ;-)
Клиент понимает сценарий, разработчики понимают сценарий.
Дальше эти блоки встают в таскменеджер и все едет.
Имхо, это не по ТЗ, это BDD называется :-)
Систему сдали, в эксплуатацию ввели, акты подписали, деньги получили. И тут через полгода пользователи такие решили ее использовать и нашли невыловленные баги.
У вас просто какая-то особая специфика.
Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты?
Если понимаете, то должны также понимать что все эти параллели — это медвежья услуга новичкам, ну и соответственно вред всему Elixir-сообществу.
Во-первых, пытаться тащить привычки из Ruby в Elixir — это самый сложный путь.
Тем, кто хочет изучить Elixir, эффективнее всего будет отложить все знания, связанные с Ruby, на отдельную полочку и не вспоминать про них пока программируешь на Elixir.
Во-вторых, библиотеки по кальке скопированные с Ruby только привносят проблемы с пониманием того, как работает Elixir и какова его область применения. Этому надо противостоять по мере сил и поддерживать идиоматичные для Elixir библиотеки.
Также повторюсь, что сейчас проводится чёткая параллель между Elixir и Ruby
Это очень хреновая параллель, т.к. языки не имеют ничего общего, кроме отдалённо похожего синтаксиса и частично совпадающих названий функций в stdlib. По факту Elixir имеет в сотни раз больше общего с Erlang и с Lisp, чем с Ruby.
Хуже параллель проводить только между Phoenix и Rails, там вообще принципиально разная идеология в архитектуру заложена.
Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух).
И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.
И клиент получает что-то работающее по опыту через неделю-две.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
С потоком внезапных, срочных, и важных тикетов на суппорт по прошлым проектам
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Притом что они получают мусор?
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
"тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут"
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
Реализация — это не API. API — это описание параметров и результатов. Подкреплённое тестами, в идеале.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Устраивать рефакторинг не имея представления что ваш фрагмент кода делает и когда он используется — кончается слезьми.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
Но стараться «сохранить жизнь» программе когда она уже «слетела с катушек»
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
Судя по описанию, имелся в виду StackOverflow.
А как Вы попали на собеседование в такие компании? Обычно ведь представители компании приглашают на собеседование. Если женщин не берут, то зачем звать то..
Так а без этой позитивной дискриминации у девушки будет ощущение, что есть негативная дискриминация… Мужчины же друг с другом не любезничают. И стажёр-парень может с гораздо большей вероятностью, чем стажёр-девушка, услышать, что он на совещании только для того, чтобы доску протирать… Тут даже не важно в шутку или всерьёз это скажут. Для мужчины услышать такое — повод прокачивать навыки, а для женщины — повод обидеться на дискриминацию.
Много будет не библиотек, а "личных экспериментов начинающих разработчиков".
Я для себя вывел правило больше не публиковать пакеты, которые я сам не использую в реальных проектах на production. Имхо, от соблюдения этого правила всем будет только лучше.
Один мусорный пакет вреда особо не наносит, но если их много, то получается помойка, как в npm.
Как следствие, затрудняется поиск нужных пакетов.
Имхо, это всё слегка надумано… Более 90% программистов не пишут библиотеки, а те, кто пишет, разберутся с публикацией по официальной документации без проблем.
Всякие обучающие статьи и лабораторки на эту тему не нужны от слова "совсем". Они только стимулируют помойку аля npm.
В этом плане vozhd99 правильно отметил, что хоть в названии статьи указана "дистанционная работа", по факту статья про предпринимательскую деятельность.
Со схемой "работаю по трудовому договору из дома" и так всё понятно, там просто фикс.зарплата за вычетом 13%. Отпуск, праздники, больничные и т.д. — всё оплачивается и на net не влияет.
Для предпринимательства всё по другому, и там net = 0.6 * gross, а не 0.87, но зато gross существенно выше.
Может быть. Хотя какой юзкейс у песочницы? Всё равно ведь ничто кроме здравого смысла не остановит от публикации в основной репозиторий пакетов.
Зачем Вы "это" запихнули в hex? Не превращайте его в файлопомойку.
Есть разные варианты. Если у Вас обычный рабочий день, только дома, то Вы — дистанционный наёмный сотрудник. Так можно работать с российскими компаниями, а зарубежные Вас в штат брать не будут и оплата будет либо попроектная (для мелких типовых заказов), либо почасовая (только время, потраченное на решение задач).
У патентов есть ограничения в зависимости от региона пребывания.
А в целом Ваш расчёт неплох. Единственное, что Вы забыли — это вынужденный простой, допустим когда один проект закончился, а второй ещё не начался… или даже внутри одного проекта такое бывает… или вообще из-за собственной прокрастинации. Это ещё около 10% в минус. Так что диапазон я бы указал 50-70%, а мат.ожидание: net = 0.6 * gross
И поскольку в России принято указывать именно net-зарплату правильно писать так:
"что соответствует рейту от 30 до 50$/час ($3000-5000 в мес.)" ;-)
Имхо, это не по ТЗ, это BDD называется :-)
У вас просто какая-то особая специфика.
Программист.
Если понимаете, то должны также понимать что все эти параллели — это медвежья услуга новичкам, ну и соответственно вред всему Elixir-сообществу.
Во-первых, пытаться тащить привычки из Ruby в Elixir — это самый сложный путь.
Тем, кто хочет изучить Elixir, эффективнее всего будет отложить все знания, связанные с Ruby, на отдельную полочку и не вспоминать про них пока программируешь на Elixir.
Во-вторых, библиотеки по кальке скопированные с Ruby только привносят проблемы с пониманием того, как работает Elixir и какова его область применения. Этому надо противостоять по мере сил и поддерживать идиоматичные для Elixir библиотеки.
Это очень хреновая параллель, т.к. языки не имеют ничего общего, кроме отдалённо похожего синтаксиса и частично совпадающих названий функций в stdlib. По факту Elixir имеет в сотни раз больше общего с Erlang и с Lisp, чем с Ruby.
Хуже параллель проводить только между Phoenix и Rails, там вообще принципиально разная идеология в архитектуру заложена.
И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.