Уже писали что с введением любых символов юникода получается новый вектор обхода проверки объявлений на дубли? Теперь можно спрятать аудио наркотики за символами которые будут обходить черный список. Про аналитику по тексту объявлений тоже можно переживать. Как с этими моментами решили поступить?
Наткнулся на видос про везение и отношение везунчиков к остальным. Про то как везунчики после везения принижают заслуги и упорство других которым не повезло https://youtu.be/iqgNOcfBSTY видос около 10 минут, рекомендую. И все же если перестать стараться то точно никуда не вырвешься в системе ты или нет
Согласен со статьей и в ходе комментариев поймал мысль с везением, которая потом проскачила в ютубчике https://youtu.be/iqgNOcfBSTY на Дарт Вайдер канале. Все же не имея наследства есть шанс. Также от обратного если сидеть и перестать стараться точно не получится ничего
клиент, он же браузер
сервер, он же бизнес-логика, он же БЛ
база, она же… база"
где-то меня здесь обманывают… Клиент в трехзвенке это не браузер, а слой отвечающий за взаимодействие с браузером или мобильным телефоном или десктоп приложения (АРМ) ещё чем-то. Сервер это не бизнеса логика, а сервер. Бизнес логика это такой же слой приложения как и клиентский слой.
Вчитайтесь в строчку из Википедии, которую Вы приложили, пожалуйста: Трёху́ровневая архитекту́ра (трёхзве́нная архитекту́ра, англ. three-tier) — архитектурная модель программного комплекса… ПРОГРММНОГО. Это не про железо.
отличная аллегория!
Все же вопрос рождается сам собой: откуда берутся руководители? откуда появляются лиды? почему разработчики становятся синьорами? Как Рокфеллер становится Рокфеллер? Как Тинькоф становится Тинькофф? Федор Овчинников становится Додо Пиццей?
много людей которые много и усердно работают, и что, они все стали богатыми?
мне не известны другие способы кроме того что бы работать больше. Потому что везение это когда из 100 случаев два выигрышных и я пробовал 99. Если комментарий с точки зрения богатства, именно про деньги, то нужно ставить в приоритет зарабатывание. Например, когда у вам нужно заработать денег, вы можете работать программистом и пытаться растить экспертизу что-бы увеличивать свою зарплату. Можно поступить по другому и можно работать программистом и играть на бирже что бы реально зарабатывать. Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса. В первом случае ты не масштабируешся и всегда будешь работать ради работы, а во втором можно экстраполировать подход и зарабатывать. Все зависит от того какой смысл ты вкладываешь. От смысла зависит то какой шаг делать дальше
видел людей которые херачили, и сам таким был, а повышали других
пробовали проанализировать почему так происходило?
Что значит сделать то, что не ожидали? У вас так плохо с планированием, что вы не знаете, что вам нужно?
Если Вам интересно то есть роадмап и майлстоуны, есть цели краткосрочной и долгосрочной перспектвы. Есть спринта. Есть цель спринта. В рамках ежедневной работы вы можете делать задачи и делать их в срок. Быть не больше и не меньше середнячком. Если постараться то можно в процессе текущих задач также настроить CI получше, обновить либу, запилить прототип сервиса, зафиксить проблему рядом с тем местом где вы делали правки (а не забивать на нее), покрыть тестами то что не ложилось в задачу и тд
Уже не помню в какой книге (что-то про профессионального программиста) приводили пример человека который внимательно слушал проблемы, озвученные своим руководителем и постепенно решал их. Таким образом когда о таких проблемах заговаривали снова, выяснялось что они уже были решены. Это и есть быть проактивный. Не быть посредственностью, середнячком.
И если это сделал разработчик, почему его стоит наградить, если другие работали по плану и в соответствии с ожиданиями?
Работать по плану это значит отбивать те деньги которые и так тратиться на сотрудника. Если зарплата «по рынку» зачем платить больше если человек не стримится ни к чему и плывет по течению. Все пытаются экономить. Такая модель будет работать до тех пор пока сотрудник создаёт добавочную стоимость своей работой. Когда выйдет новый фреймворк или работа упростится так что ее можно будет делать в два раза быстрее и у сотрудника не будет возможности перенять такой опыт он станет нерентабельными. Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
что именно вам кажется ошибкой выжившего
указание трёх компаний с их процессами как личного опыта. В мире миллионы компаний и везде по разному.
По поводу непрозрачности и отсутствия пользы (вреда) не соглашусь:
мне как разработчику важно знать и понимать как и что мне делать что бы расти профессионально и материально. Если в компании нет процессов которые бы четко эти моменты описывали я это учитываю в плане своего развития и смотрю в перспективу нескольких лет, что придется искать новую компанию. Если процессы есть, но модель не описана или имеет неявные результаты, то стоит заявить о своих желаниях. В плане профессионального роста, каждый инженер может найти почти все необходимые материалы чтобы составить карту компетенций, определить свой реальный трейд и найти себя на пути развития джун-мидл-сеньер-лид-сто и тд. Далее при понимании несоответствия своего уровня и текущего грейда, идём на рынок и находим правильную компанию которая также вас оценивает. С деньгами тоже самое. Если на рынке есть предложения лучше, почему бы ими не воспользоваться? Другое дело как инженеру вам хочется получить признание за заслуги и усилия, результаты труда. Тогда никакие перформанс ревью не помогут. Можно делать опенсурс и зарабатывать звёзды от других разработчиков, производя реальную пользу, которую на текущем месте никто не может оценить или такую пользу не придумать если ты не в мейнстриме.
мне как руководителю нужны инструменты которые бы помогали разделять материальную часть на людей действительно заслуживающих этого, что бы подогреть интерес, чтобы не ушли, чтобы был пример и тд. Собирать оценку за год или полгода мне нужно отмечать моменты когда инженер сделал полезную вещь для команды, проекта, компании, когда от него этого не ожидали. Собирать оценку удовлетворенности от заказчика. Собирать оценку соответставия заявленным умениям в том числе выполнению целей карты развития самого инженера и тд. Далее можно делать своднную статистику что у инженера получается, а что нет. Все эти аспекты обсуждаются на ревью. Они достаточно прозрачные. Что бы не ошибиться с решением я могу попросить оценить инженера по сводным данным другого руководителя. Если инженер хромает или не мотивирован, или страдает синдромом студента и пытается за неделю до ревью наверстать что-то, значит будут соответствующие выводы. Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы.
Многие описанные вещи выглядят как история получившаяся на эффекте "выжившего". Не обязательно во всех компаниях происходит так как это происходило у вас. Где то бывают перекосы и перегибы. Как практика сама по себе, перформанс ревью не несёт вреда. Любой инструмент можно испортить если не понимать как правильно его готовить.
Потом вы сами принимаете условия игры, также как и можете предложить свои.
Уже писали что с введением любых символов юникода получается новый вектор обхода проверки объявлений на дубли? Теперь можно спрятать аудио наркотики за символами которые будут обходить черный список. Про аналитику по тексту объявлений тоже можно переживать. Как с этими моментами решили поступить?
Наткнулся на видос про везение и отношение везунчиков к остальным. Про то как везунчики после везения принижают заслуги и упорство других которым не повезло https://youtu.be/iqgNOcfBSTY видос около 10 минут, рекомендую. И все же если перестать стараться то точно никуда не вырвешься в системе ты или нет
тех лид :) ну и до сто может быть архитектор
Согласен со статьей и в ходе комментариев поймал мысль с везением, которая потом проскачила в ютубчике https://youtu.be/iqgNOcfBSTY на Дарт Вайдер канале. Все же не имея наследства есть шанс. Также от обратного если сидеть и перестать стараться точно не получится ничего
"классической трехзвенки:
клиент, он же браузер
сервер, он же бизнес-логика, он же БЛ
база, она же… база"
где-то меня здесь обманывают… Клиент в трехзвенке это не браузер, а слой отвечающий за взаимодействие с браузером или мобильным телефоном или десктоп приложения (АРМ) ещё чем-то. Сервер это не бизнеса логика, а сервер. Бизнес логика это такой же слой приложения как и клиентский слой.
Вчитайтесь в строчку из Википедии, которую Вы приложили, пожалуйста: Трёху́ровневая архитекту́ра (трёхзве́нная архитекту́ра, англ. three-tier) — архитектурная модель программного комплекса… ПРОГРММНОГО. Это не про железо.
отличная аллегория!
Все же вопрос рождается сам собой: откуда берутся руководители? откуда появляются лиды? почему разработчики становятся синьорами? Как Рокфеллер становится Рокфеллер? Как Тинькоф становится Тинькофф? Федор Овчинников становится Додо Пиццей?
мне не известны другие способы кроме того что бы работать больше. Потому что везение это когда из 100 случаев два выигрышных и я пробовал 99. Если комментарий с точки зрения богатства, именно про деньги, то нужно ставить в приоритет зарабатывание. Например, когда у вам нужно заработать денег, вы можете работать программистом и пытаться растить экспертизу что-бы увеличивать свою зарплату. Можно поступить по другому и можно работать программистом и играть на бирже что бы реально зарабатывать. Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса. В первом случае ты не масштабируешся и всегда будешь работать ради работы, а во втором можно экстраполировать подход и зарабатывать. Все зависит от того какой смысл ты вкладываешь. От смысла зависит то какой шаг делать дальше
пробовали проанализировать почему так происходило?
Если Вам интересно то есть роадмап и майлстоуны, есть цели краткосрочной и долгосрочной перспектвы. Есть спринта. Есть цель спринта. В рамках ежедневной работы вы можете делать задачи и делать их в срок. Быть не больше и не меньше середнячком. Если постараться то можно в процессе текущих задач также настроить CI получше, обновить либу, запилить прототип сервиса, зафиксить проблему рядом с тем местом где вы делали правки (а не забивать на нее), покрыть тестами то что не ложилось в задачу и тд
Уже не помню в какой книге (что-то про профессионального программиста) приводили пример человека который внимательно слушал проблемы, озвученные своим руководителем и постепенно решал их. Таким образом когда о таких проблемах заговаривали снова, выяснялось что они уже были решены. Это и есть быть проактивный. Не быть посредственностью, середнячком.
Работать по плану это значит отбивать те деньги которые и так тратиться на сотрудника. Если зарплата «по рынку» зачем платить больше если человек не стримится ни к чему и плывет по течению. Все пытаются экономить. Такая модель будет работать до тех пор пока сотрудник создаёт добавочную стоимость своей работой. Когда выйдет новый фреймворк или работа упростится так что ее можно будет делать в два раза быстрее и у сотрудника не будет возможности перенять такой опыт он станет нерентабельными. Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
указание трёх компаний с их процессами как личного опыта. В мире миллионы компаний и везде по разному.
я был разработчиком и прошел всю эту кухню. Сейчас я становлюсь как руководитель
Интересная статья. Было приятно читать. Спасибо.
По поводу непрозрачности и отсутствия пользы (вреда) не соглашусь:
Многие описанные вещи выглядят как история получившаяся на эффекте "выжившего". Не обязательно во всех компаниях происходит так как это происходило у вас. Где то бывают перекосы и перегибы. Как практика сама по себе, перформанс ревью не несёт вреда. Любой инструмент можно испортить если не понимать как правильно его готовить.
Потом вы сами принимаете условия игры, также как и можете предложить свои.