21 идея для разработчика

Написал и опубликовал Тим Маринин
и поставил теги разработка, табуретка.

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

  1. Задача программиста не «писать код», задача программиста — решать бизнес-задачи, и «поиграться с новым фреймворком» зачастую не решает бизнес-задачу.
  2. Мы работаем с людьми, и только иногда пишем код, поэтому отношения между людьми — важная часть работы.
  3. Разработчики тоже люди, и подвержены всем тем же когнитивным ошибкам, что и все остальные. Стоит почитать про когнитивные ошибки, FAE, и книгу Канемана в отдельности.
  4. Постоянно сменяющиеся фреймворки появляются потому, что у нас нет идеального решения проблем, которые стоят перед фронтенд-разработчиками. Каждый следующий успешный фреймворк — шаг в интересном направлении в сторону идеала, стоит относиться к ним с точки зрения «что интересного этот фреймворк/библиотека привносит в мою работу».
  5. Разработчики не просто «пишут код», они участвуют в бизнес-процессах. Если в компании принят Аджайл, то нужно относиться к этому если не серьёзно, то как минимум с уважением.
  6. Код-ревью — важная часть процесса разработки. Нельзя быть хорошим разработчиком, но относиться к код-ревью халатно.
  7. Как программисты, мы несём ответственность за то, что деплоим. В том числе, и моральную. Не стоит делать неэтичные вещи.
  8. Пользователи — живые люди. Наши продукты и ошибки могут напрямую влиять на их жизнь, стоит осознавать последствия наших действий.
  9. Люди отличаются друг от друга, люди думают по-разному: что нам кажется сложным, бизнесу может казаться тривиальным — это создаёт конфликт, который приходится разрешать.
  10. Нужно нести ответственность за свои дедлайны, и если не укладываешься — идти передоговариваться.
  11. У задач есть два вида сложности: внутренняя и внешняя сложность. От первого вида сложности не избавиться, он есть в задаче изначально; второй привносим мы, городя неуместные архитектуры и изобретая велосипеды. Надо следить за тем, чтобы внешняя сложность не была больше внутренней.
  12. Когда при написании кода или проектировании архитектуры разработчик выбирает простое решение вместо правильного, он создаёт технический долг. По долгам придётся платить.
  13. Код других людей почти всегда кажется непонятным или криво написанным, не всегда причина в том, что код действительно криво написан. Иногда эти другие люди — это мы полгода назад.
  14. Иногда задача решается без изменения кода вовсе.
  15. Смелость менять то, что нужно менять, безразличие к тому, что изменить невозможно, и мудрость отличить одно от другого.
  16. Случается так, что тривиальное для разработчика бизнесу чрезвычайно полезно и ценно — это хорошая ситуация, не стоит от неё бежать.
  17. Редкая компания заинтересована в твоём росте: если бы её не устраивал твой текущий уровень, тебя бы не взяли.
  18. Конференции, митапы и прочее полезны в первую очередь людьми, которые пришли, и во вторую — докладами.
  19. Собеседование — это игра на двоих, не только компания смотрит на тебя, но и ты — на компанию.
  20. Мы приходим в профессию, потому что нам это интересно, но платят нам за пользу, которую мы приносим. Стоит почитать про cost center и profit center, и понимать, где ты находишься сейчас.
  21. Когда работаешь фрилансером, заказчик нанимает тебя ради скиллов, которых у него нет — он не может указать тебе на плохой код, а ошибки, которые ему видны, описывает своим языком.

Написать мысли насчёт, кхм, списка мыслей можно на mt@marinin.xyz или в твиттере: я там @marinintim.

this-references Канеман