Pull to refresh
14
0
Send message

Как организовать систему оплаты в компаниях, занимающихся разработкой

Level of difficultyMedium
Reading time16 min
Views6.3K

Любая программная компания рано или поздно сталкивается с проблемой должностей. Некоторые организации довольствуются «плоской» системой, но в отсутствие системы должностей возникают теневые иерархии, что на самом деле хуже. Должности дают чёткую демаркацию ожиданий от конкретного сотрудника. Например, гораздо проще возложить на ведущего разработчика ответственность за техническое руководство, если эта роль чётко определена. Без определений должностей наверх будут подниматься самые громкие, а тихие и вдумчивые останутся незамеченными.

Сложность чёткого определения должностей заключается в том, что люди пытаются обмануть систему (всегда заявляя, что они заслуживают новой должности/повышения зарплаты). Я наблюдал, как для борьбы с этим организации создают всё более длинные определения, позволяющие избегать пограничных случаев. Постепенно определения начинают занимать несколько страниц и перестают умещаться в головах. В процессе сложности системы соблюдение её правил ослабевает, а потом люди просто перестают им следовать. Я считаю, что есть более правильный путь, поэтому предлагаю следующее:

Не платите за то, сколько людей под руководством или сколько строк кода они написали. Платите им за генерируемые результаты.

Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.

В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
Читать дальше →
Total votes 50: ↑46 and ↓4+42
Comments7

CHAD Principles

Reading time1 min
Views2.5K

Наверное, каждый из вас слышал о SOLID, KISS, DRY, DI, HWDP и других популярных наборах хороших практик программирования.

Но позволю себе предположить, что никто не знает принципов CHAD, касающихся хороших практик работы с системами контроля версий и рецензирования кода.

Ну что же, приступим!

Читать далее
Total votes 8: ↑7 and ↓1+6
Comments7

Проблемные личности среди разработчиков

Reading time22 min
Views103K


В пустыне квалифицированных талантов как вода востребованы разработчики программного обеспечения, пусть их носят на руках или оскорбляют, но это факт. Без них не будет индустрии, и им самим это отлично известно. Это приводит к такому захватывающему чувству собственного права, какое редко встречалось в истории человечества. В результате на свет появился целый спектр очень ярких проблемных личностей.

Хороший разработчик может стоить на вес золота — буквально. В немногих профессиях возможны такие доходы. Некоторые из богатейших людей на планете раньше были программистами, поэтому оказаться разработчиком в нужное время в нужном месте — это один из самых простых и прямых путей к огромному богатству.

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.
Читать дальше →
Total votes 93: ↑74 and ↓19+55
Comments179

Инженерная культура в больших корпорациях: дайджест публикаций Хабра

Reading time5 min
Views2.8K

На этой неделе сразу две компании — Meta* и Amazon, — решили внести заметные изменения в свою работу. Meta сломала устоявшуюся структуру и предложила многим менеджерам среднего звена спуститься с командных высот на землю и поработать руками: писать код, заниматься исследованиями, проектировать. В Amazon при приёме на работу на начальные позиции теперь будут рассматривать только студентов и выпускников вузов. Корпорации сразу припомнили её декларации, посвящённые инженерной культуре: о том, как она важна, и как Amazon объявляла о своих устремлениях поднять её на более высокий уровень.

Меня зовут Екатерина, и я куратор потоков менеджмент и маркетинг. Одна из моих задач — «приземлять» на Хабр авторов, готовых писать на эти темы так, чтобы они были интересны сообществу. Поэтому я посмотрела на наши актуальные новости, на наши старые и новые публикации и сегодняшний дайджест решила посвятить инженерной культуре в больших корпорациях. Безусловно, это только первый срез, и если вам есть что сказать на эти темы, пишите мне, пишите сами по себе, главное — пишите для Хабра.

Читать далее
Total votes 24: ↑19 and ↓5+14
Comments0

Одна особенность корпоративной культуры, необходимая для благополучия кодовой базы

Reading time7 min
Views13K


Легко поддерживать корпоративную культуру на словах. Однако лишь немногие компании активно изучают те немногочисленные особенности корпоративной культуры, которые оказывают существенное влияние на производительность, — потому что это самое сложное.


Для команд, создающих программное обеспечение, важнейшим прогнозным фактором инженерного благополучия, несомненно, является владение кодом. В этом практическом руководстве мы проанализируем именно то, как вам внедрить этот принцип в повседневную работу своей команды разработчиков, чтобы благополучие вашей кодовой базы поддерживалось само собой.

Читать дальше →
Total votes 30: ↑30 and ↓0+30
Comments20

Докажи, если сможешь

Reading time13 min
Views7.7K

Есть такой полезный принцип: уверенность в чём-то не должна возникать из ниоткуда. Если вы имеете сильную уверенность в некоем убеждении, то вы обязаны иметь много свидетельств в его подтверждение. Если свидетельств мало, то и уверенность должна быть низкой. Но сегодня не совсем про это.

Если вас спрашивают, почему вы в чём-то так уверены, то вы запаковываете свидетельства для передачи собеседнику. Такие запакованные свидетельства называются доказательствами, про них сейчас и поговорим. Вот четыре типа доказательств про которые пойдет речь: истории, статистика, логика, авторитеты. 

Проверить
Total votes 34: ↑32 and ↓2+30
Comments45

Приручая System Design Interview. Как его организовать и как к нему подготовиться

Level of difficultyMedium
Reading time8 min
Views11K

Эта статья о секции по проектированию систем, которая стала появляться на собеседованиях в российских компаниях. В ней за час предлагается проработать дизайн highload системы по функциональным и нефункциональным требованиям, тем самым предъявив эксперту свои знания сразу из множества областей.

Я поделюсь своими впечатлениями от участия в этом формате, рассмотрю проблемные моменты и предложу, что с ними можно сделать.

Читать далее
Total votes 9: ↑9 and ↓0+9
Comments3

Стоит ли программисту ехать в Корею работать в Samsung (часть II)

Reading time11 min
Views47K
Мне показалось, что в первой части о специфики жизни Кореи я писал слишком негативно. Но затем дал почитать статью друзьям, которые жили или живут в Корее и они сказали, что все ок… Мол, это еще демократично.

Оборачиваясь назад и смотря на мои 2+ года в этой азиатской стране, я в целом считаю их не самыми продуктивными. На ум приходит много печального опыта от ужасного корейского национализма до невозможности получить нормальную задачу на работе. Но стоит отметить, что я очень активный по жизни человек и если бы все было плохо, я бы уехал оттуда через несколько месяцев. Значит, что-то меня там держало.
Читать дальше →
Total votes 49: ↑48 and ↓1+47
Comments25

Information

Rating
Does not participate
Registered
Activity