А налоговая как на это смотрит? ну т.е. будет один и тот же платеж с одинаковой суммой каждый месяц, они нормально такое пропускают?
и еще вопрос — как проходите этап согласования договора и валютный контроль, пользуетесь какими-то сервисами?
Чето статья ни о чем, открываем апворк и ищем по кобол. www.upwork.com/search/profiles/?q=COBOL
С 10+ годами опыта от 11 баксов в час полно предложений. о каком кризисе вообще речь?
Ну им нужен был пакетный менеджер(написано же). Структура и как его встроить в корпорацию, поддерживать и прочее была непонятной. Наверное решили это по быстрому сделать, пригласив его.
Но он стал задавать вопросы(а какая структура, его роль и пр.), т.е. им пришлось это продумывать. Как только продумали, наверняка возник вопрос — а зачем вообще автор, технически МС это и само может сделать, само ПО не очень сложное.
Ну вообще по деньгам можно было понять свою позицию в корпоративной лестнице
Откуда они сами то могли знать роль? Продукта то еще не было. Какие люди нужны для его поддержки и весь процесс тоже был непонятен. Как бы очевидно что ответ был — «как пойдет». Будет пользоваться спросом, будет команда, не будет — закроют проект.
Вообще интерестно как обсуждалась зарплата(этож главное по сути)
Вроде как идея Егора была раньше — что скоро будет оплата только за результат. Т.е. да, все что вы написали оплачивать не будут, есть код нужный для компании, проходит оплата. Нет кода — нет оплаты.
Что-то я не понял — а зачем вы ушли с первой работы? Ну т.е. деньги платили, особо не загружали, зачем уходить. или платили мало? Надо было просить прибавки:)
Если было свободное время можно ведь заниматься саморазвитием, вступить в какой-нибудь опенсорс прожект или подобное
Классификация странная. Т.е. вначале все же надо определиться с платформой(сейчас по сути выбор — Windows и стек Microsoft и «не Windows и другой стек»). В зав-ти от этого все как бы кардинально меняется
Подборка книг забавная Сонмез с Кнутом. Я вот не видел никого кто прочитал Кнута, но правда и алгоритмы разрабатывал только в институте.
Сам недавно прочитал Джона Сонмеза «The Complete Software Developer's Career Guide», вот это могу порекомендовать каждому, подойдет на любом уровне. Единственная мысль — почему я не прочитал книгу раньше
Советы немного странные — ну т.е. допустим 2. — вам просто зададут ответный вопрос — а какой класс ты посоветуешь? Далее тупо поправят на это и любая любая ошибка будет на ваш счет
или «7. Обоснуйте ваши предложения» —
Когда вы научили коллегу новому подходу
вы как бы автоматически ставите себя выше коллеги. это будет работать если это действительно так и он сам с этим согласен, но если руководство подразумевает что вы на одной ступени, то такие «учения» сразу ставят вопрос — «кому следующему поднимать зарплату» не в его пользу
Совет 11 вообще непонятен — ну т.е. вы что-то предлагаете, коллеге это влом делать, возникает вопрос — мы коммитим код в основную ветку или нет? за кем финальное слово? типовой ответ будет — «ну да, я знаю что неоптимально, но сделал так ибо..»
или еще хуже — он с вами начнет обсуждать как лучше, какие варианты, в итоге 2 человека будут заниматься ерундой вместо решения задач проекта. По идее проектный менеджер, если у проекта ограниченный бюджет должен такое пресекать на корню.
Насколько я понимаю основной рекомендацией работы с системой контроля версий и стратегий бранчей является — выбрать самый простой вариант, и усложнять его только если это действительно нужно проекту. Если вы в этой стадии усложнения дошли до команд которые не поддерживаются популярными клиентами, то может быть надо остановиться и пересмотреть стратегию?
Я что-то не понял зачем разработчику вообще что-то гуглить. Флоу кода(какие бранчи использовать, куда коммитить, что делать с кодом который надо отложить и пр..) и все возможные варианты вообще должны описаны до начала кодирования и согласованы внутри команды. В каком случае то понадобиться что-то гуглить? все ж должны работать одинаково.
Вот вроде 2020 год, насколько вообще продуктивно использовать эти команды? Есть уже пару отличных клиентов, почему бы не рассматривать их(Fork как я понинимаю лидер, но он стал платным, GitHub desktop для гитхаба )
Ну если мощные ноутбуки или они включены постоянно то да. Но если ноут включается редко, то при включении надо будет прямо ждать, пока все поставится. или специально его включать для установки. При чем что меня добило — что часть обновлений нужно подтверждать, нельзя просто оставить его включенным — «типа нажмите ок, чтобы перегрузить компьютер». и дальше ноут уходит на 10-20 минут в ребут, в течении которого ты просто сидишь и ждешь. Т.е. в какой-то момент время ожидания обновлений было больше чем непосредственно время использования.
Самое главное чего не хватает — Нужно построить наконец-то дата центр Azure в России, или запартнериться с кем-то на предмет предоставления таких услуг(как в Китае я понимаю). Это по сути сейчас самый главные недостаток Microsoft
и еще вопрос — как проходите этап согласования договора и валютный контроль, пользуетесь какими-то сервисами?
www.upwork.com/search/profiles/?q=COBOL
С 10+ годами опыта от 11 баксов в час полно предложений. о каком кризисе вообще речь?
Но он стал задавать вопросы(а какая структура, его роль и пр.), т.е. им пришлось это продумывать. Как только продумали, наверняка возник вопрос — а зачем вообще автор, технически МС это и само может сделать, само ПО не очень сложное.
Ну вообще по деньгам можно было понять свою позицию в корпоративной лестнице
Вообще интерестно как обсуждалась зарплата(этож главное по сути)
Если было свободное время можно ведь заниматься саморазвитием, вступить в какой-нибудь опенсорс прожект или подобное
Сам недавно прочитал Джона Сонмеза «The Complete Software Developer's Career Guide», вот это могу порекомендовать каждому, подойдет на любом уровне. Единственная мысль — почему я не прочитал книгу раньше
или «7. Обоснуйте ваши предложения» —
вы как бы автоматически ставите себя выше коллеги. это будет работать если это действительно так и он сам с этим согласен, но если руководство подразумевает что вы на одной ступени, то такие «учения» сразу ставят вопрос — «кому следующему поднимать зарплату» не в его пользу
Совет 11 вообще непонятен — ну т.е. вы что-то предлагаете, коллеге это влом делать, возникает вопрос — мы коммитим код в основную ветку или нет? за кем финальное слово? типовой ответ будет — «ну да, я знаю что неоптимально, но сделал так ибо..»
или еще хуже — он с вами начнет обсуждать как лучше, какие варианты, в итоге 2 человека будут заниматься ерундой вместо решения задач проекта. По идее проектный менеджер, если у проекта ограниченный бюджет должен такое пресекать на корню.