Во-первых для начала наверное стоит прочитать Ильяхова про его правила деловой переписки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
И самые лучшие способы добиться того чтобы люди были тебе не рады:
Звонить или кидать встречи без предупреждения или согласования
К сожалению не найду ссылку на исследование, но суть такова:
Первое впечатление, которое интервьюер формирует за 10-15 минут (иногда больше, если кандидат рассказывает о себе общими словами), в 8 из 10 случаев оказывается верным. То есть мнение интервьювера брать-набрать, формируемое в первой четверти собеседования в 8 из 10 случаев не меняется в конце. Все описанное в статье в итоге даст не более 20% уверенности в решении.
В другом исследовании видел, что сама по себе точность угадывания продуктивности и длительности работы будущего сотрудника во время собеседования крайне мала.
Стоит оно того - решать вам.
Я последнее время склоняюсь к мысли, что техническое интервью, если оно не формализовано, это просто "позадавать вопросы, чтобы выяснить уровень владения технологиями, которые придется использовать". И это занимает ту самую четверть времени.
А остальные три четверти вы продаете свою вакансию\команду\компанию кандидату. Об этом забывать не стоит.
Если уже есть какая-то база, то даже не стоит вопрос о выборе. Если конкретной базы нет (а её чаще всего нет), то postgres. MySQL тупо слабее и требует лицензирования для коммерческого использования.
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
ни во сколько. если вам прделагают как ИП заключаться, то договаривайтесь или на высокую почасовую ставку, ну уровне фриланс бирж, или на гонорар за фиксированный объем
В обоих случаях это и более честно и более правильно с точки зрения закона.
Не понимаю в чем функция тимлида, если есть еще и техлид. А если есть еще ПМ, ПО, начальник отдела и еще куча менеджеров, то тем более.
Я наверное слишком стар, но все еще живу по модели команды, описанной Бруксом - "бригада хирургов". В ней есть главный хирург (тимлид), который отвечает за успех операции в целом, несколько специалистов в своих областях и медсестры, которые подают инструменты и накладывают повязки.
При этом бригада не выбирает сама кого лечить и от чего лечить. Хотя главный хирург (тимлид) может быть также лечащим врачом (архитектором решения), а может и не быть.
1) У работника в штате гарантированно месяц отпуска. То есть работает он 11 месяцев, а получает 12. А если вы увольняетесь не отгуляв отпуск, то получите компенсацию.
2) Работника в штате очень сложно уволить если вдруг работник стал не нужен. С ип можно разорвать контракт максимум через месяц и без компенсацию, больше никто в контракте не пропишет. Чтобы уволить работника если вдруг у работодателя кончились проекты можно только через сокращение, а это 2-3 оклада на руки.
3) Работник получает ЗП регулярно, а если вдруг не получает, то может не работать, а за время простоя ему все равно деньги выплатят. Оплату ИП можно тянуть долго, даже если через суд вы чего-то добьетесь, то это займет много времени, которое никто не оплатит.
Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
Как говорилось уже выше, главный плюс спецификаций в том, что логика получения данных теперь находится там, где она должна быть - на уровне домена.
А что в этом хорошего? На какие потребительские характеристики это влияет? Как влияет на совокупные трудозатраты и стоимость поддержки кода? Желательно в примерах.
ваше приложение будет более гибким
Как расположение кода в проекте влияет на гибкость?
А должно быть грустно. Вы не осознаете проблему, которую создаете себе и другим.
Продолжайте в том же духе и скоро заметите как все «срочные вопросы», от которых что-то зависит, пойдут мимо вас.
Так он потом скажет что не видел эти протокол и вообще не говорил такого.
Почему же?
Во-первых для начала наверное стоит прочитать Ильяхова про его правила деловой переписки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
И самые лучшие способы добиться того чтобы люди были тебе не рады:
Звонить или кидать встречи без предупреждения или согласования
Писать письма крупным или красным шрифтом
Везде добавлять руководителя в переписку
Верно
Гори в аду
Гори в аду
Гори в аду
Это как вообще? кто и или что кого должно ограничить?
А зачем протокол без ответственных? Это не просто стандартная практика, а это единственное осмысленное действие в протоколе
Очень сомневаюсь что от количества "пожалуйста" хоть что-то зависит
Игнорят письма, потому что людям есть чем заняться вместо ответов на тупые вопросы.
Посоветую бросить работы в ИТ, поискать гденить в другом месте.
К сожалению не найду ссылку на исследование, но суть такова:
Первое впечатление, которое интервьюер формирует за 10-15 минут (иногда больше, если кандидат рассказывает о себе общими словами), в 8 из 10 случаев оказывается верным. То есть мнение интервьювера брать-набрать, формируемое в первой четверти собеседования в 8 из 10 случаев не меняется в конце. Все описанное в статье в итоге даст не более 20% уверенности в решении.
В другом исследовании видел, что сама по себе точность угадывания продуктивности и длительности работы будущего сотрудника во время собеседования крайне мала.
Стоит оно того - решать вам.
Я последнее время склоняюсь к мысли, что техническое интервью, если оно не формализовано, это просто "позадавать вопросы, чтобы выяснить уровень владения технологиями, которые придется использовать". И это занимает ту самую четверть времени.
А остальные три четверти вы продаете свою вакансию\команду\компанию кандидату. Об этом забывать не стоит.
В РФ сейчас негде взять "подороже и с саппортом", поэтому Postgres.
Раньше в банках везде был оракл, а кто поменьше - MS SQL, а теперь везде пострегс, или будет постгрес в ближайшее время.
Если уже есть какая-то база, то даже не стоит вопрос о выборе. Если конкретной базы нет (а её чаще всего нет), то postgres. MySQL тупо слабее и требует лицензирования для коммерческого использования.
Разве есть сейчас альтернатива postgres для любых транзакционных данных?
я первые 5 мин серьёзно читал
TS изначально, а JS примерно в 2017 получил классы и наследование, как в других C-подобных языках
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
А сколько людей у вас в подчинении?
В понимании текущего рынка труда тимлид в ит - это руководитель небольшой команды, без функций управления бюджетом и стратегией.
Ну когда мы говорим об одном человеке, то для компании это не проблема. А если это команда, то уже серьезные затраты.
Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
ни во сколько. если вам прделагают как ИП заключаться, то договаривайтесь или на высокую почасовую ставку, ну уровне фриланс бирж, или на гонорар за фиксированный объем
В обоих случаях это и более честно и более правильно с точки зрения закона.
Не понимаю в чем функция тимлида, если есть еще и техлид. А если есть еще ПМ, ПО, начальник отдела и еще куча менеджеров, то тем более.
Я наверное слишком стар, но все еще живу по модели команды, описанной Бруксом - "бригада хирургов". В ней есть главный хирург (тимлид), который отвечает за успех операции в целом, несколько специалистов в своих областях и медсестры, которые подают инструменты и накладывают повязки.
При этом бригада не выбирает сама кого лечить и от чего лечить. Хотя главный хирург (тимлид) может быть также лечащим врачом (архитектором решения), а может и не быть.
Что-то вы забыли три важных момента
1) У работника в штате гарантированно месяц отпуска. То есть работает он 11 месяцев, а получает 12. А если вы увольняетесь не отгуляв отпуск, то получите компенсацию.
2) Работника в штате очень сложно уволить если вдруг работник стал не нужен. С ип можно разорвать контракт максимум через месяц и без компенсацию, больше никто в контракте не пропишет. Чтобы уволить работника если вдруг у работодателя кончились проекты можно только через сокращение, а это 2-3 оклада на руки.
3) Работник получает ЗП регулярно, а если вдруг не получает, то может не работать, а за время простоя ему все равно деньги выплатят. Оплату ИП можно тянуть долго, даже если через суд вы чего-то добьетесь, то это займет много времени, которое никто не оплатит.
по вечерам, выходным итд
А ты что думал?
Классическая путаница.
Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
А что в этом хорошего? На какие потребительские характеристики это влияет? Как влияет на совокупные трудозатраты и стоимость поддержки кода?
Желательно в примерах.
Как расположение кода в проекте влияет на гибкость?