Тогда тут, как минимум, в 2 случаях из 3 остаётся радоваться, что так получилось… работать с людьми, которые даже одну страницу текста внимательно прочитать не могут, — сомнительное удовольствие..
Ещё во времена, когда соц.сетей не было, а в интернете царили форумы, на многих IT-форумах в правила включали ссылку на перевод статьи "How To Ask Questions The Smart Way".
Судя по тому, что руководство изначально было написано на английском и переведено на 10+ языков, вопросы от новичков не любят везде. В принципе, те, кто модерировал популярные форумы, и сам знает, что каким бы ты ни был милашкой, отвечать десятки раз на один и тот же по сути вопрос и ни разу не послать в поиск — весьма трудно.
P.S. Как тут не вспомнить англоязычный сервис LMGTFY :-)
А как Вы попали на собеседование в такие компании? Обычно ведь представители компании приглашают на собеседование. Если женщин не берут, то зачем звать то..
Это называется позитивной дискриминацией, и часто она бывает не менее обидной для человека, чем негативная.
Так а без этой позитивной дискриминации у девушки будет ощущение, что есть негативная дискриминация… Мужчины же друг с другом не любезничают. И стажёр-парень может с гораздо большей вероятностью, чем стажёр-девушка, услышать, что он на совещании только для того, чтобы доску протирать… Тут даже не важно в шутку или всерьёз это скажут. Для мужчины услышать такое — повод прокачивать навыки, а для женщины — повод обидеться на дискриминацию.
Много будет не библиотек, а "личных экспериментов начинающих разработчиков".
Я для себя вывел правило больше не публиковать пакеты, которые я сам не использую в реальных проектах на 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.
И клиент получает что-то работающее по опыту через неделю-две.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
С потоком внезапных, срочных, и важных тикетов на суппорт по прошлым проектам
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
Тогда тут, как минимум, в 2 случаях из 3 остаётся радоваться, что так получилось… работать с людьми, которые даже одну страницу текста внимательно прочитать не могут, — сомнительное удовольствие..
Для полноты картины можно ещё коментарии к оригиналу статьи почитать )
Вы забыли добавить "чяднт?" xD
А если серьёзно, то на эту тему даже статья была.
Справедливости ради, Торвальдс — финский швед, т.е. он не является представителем англоязычной культуры.
Ещё во времена, когда соц.сетей не было, а в интернете царили форумы, на многих IT-форумах в правила включали ссылку на перевод статьи "How To Ask Questions The Smart Way".
Судя по тому, что руководство изначально было написано на английском и переведено на 10+ языков, вопросы от новичков не любят везде. В принципе, те, кто модерировал популярные форумы, и сам знает, что каким бы ты ни был милашкой, отвечать десятки раз на один и тот же по сути вопрос и ни разу не послать в поиск — весьма трудно.
P.S. Как тут не вспомнить англоязычный сервис LMGTFY :-)
Судя по описанию, имелся в виду 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.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.