Это работает на моем компьютере [перевод]

KJ Jones поднял достаточно важную тему, осмыслить которую самостоятельно сложно. Читая заметку я узнавал себя в каждой строке. Думаю, многие начинающие разработчики тоже узнают себя. Потому решил перевести и опубликовать ее.

https://medium.com/msc-in-computer-science/это-работает-на-моем-компьютере-перевод-7c7036857e28

Итак. Получилось так, что я подзабил на затею с каналом. Навалились повседневные дела, работа. Переехал в Петербург, сменил работу. И недавно коллега убедил меня вернуться к каналу. Но формат будет несколько другим. Без сложных и длинных заметок. Выводы, сделанные мной из книг, что читаю сейчас. Статьи, которые показались интересными. Возможно, разбор проблем, с которыми сталкиваюсь в работе.

Дисклеймер. Я все еще не претендую на авторитет. Все написанное в канале личное мнение одного не очень умного человека.

Сейчас читаю "Программист-фанатик".

За первую треть книжки больше всего тронула такая мысль.

Следует посчитать, сколько ты стоишь своему работодателю. Не только зарплата. Аренда офиса, амортизация компьютера, печеньки в офисе, да что угодно. А потом подумать, сколько денег ты приносишь ему взамен.

И думать об этом каждый день, когда программируешь программирование. Сколько ты стоил сегодня? А сколько принес компании? Если первое больше второго — значит нужно работать иначе.

Это заставило меня изменить подход к коду. Я хочу чтобы построенные мной приложения были красивыми. Но разве красота приносит деньги заказчику? Нет. Простота поддержки и модификации, скорость работы, отказоустойчивость. Вот что должно быть важно разработчику.

#программист_фанатик

Как посчитать сколько денег ты приносишь не понимая специфики бизнеса?

А никак. Но программист (хороший программист) должен разбираться в бизнесе на который он работает.

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

Тогда и посчитать сколько приносишь денег получиться.

#программист_фанатик

"Нет"

Эта мысль встретилась не только в "Программисте-фанатике", но и в "Идеальном программмсте".

Нужно уметь отказывать начальству.

Это повышает ценность согласия.

Если приходит босс и требует странного, невозможного или глупого, следует сказать ему "нет". Нельзя брать обязательства которые невозможно выполнить или которые повредят продукту.

Программист, который всегда говорит "да" либо очень умён, либо постоянно врёт. Чаще все же врёт. Нужно быть честным. Соглашаться взять на себя обязательства только если уверен, что их можно выполнить в установленный срок.

Компании нанимают специалистов, чтобы получить их знания. Часто разработчик знает лучше, что нужно использовать в конкретной ситуации. И потому иногда на идею босса нужно ответить "нет" и объяснить ему, почему он не прав.

Тонкая грань. Нужно не переусердствовать. Исполнительность важна!

#программист_фанатик #идеальный_программист

Недостаточно быть хорошим программистом. Нужно уметь продать себя заказчику.

#программист_фанатик

Основная идея книги — нужно быть выдающимся программистом.

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

В проекте все собирается ручным трудом программистов? Значит нужно настроить автоматизированные сборки, зафигачить все это на CI и гордиться этим.

В проекте совсем нет тестов? Значит нужно стать евангелистом тестирования и покрыть тестами все, до чего можно дотянуться.

Зависимости проекта не обновляли с 1970 года? Значит нужно пойти и перевести все компоненты на современные технологии и обеспечить работоспособность.

Нельзя делать работу, которой будешь стыдиться.

#программист_фанатик

В "Идеальном программисте" дядя Боб рассказывает о концепции "ката". Упражнения для разработчиков, которые позволяют натренировать пальцы на решения простых повседневных задач.

Хороший ресурс с набором таких упражнений по JS — http://es6katas.org/

#идеальный_программист #js

Часто сталкиваюсь с тем, что свеже-обращенные разработчики считают Redux какой-то магией и отказываются понимать, как он работает. Убежден, что единственный способ понять что-то — сделать это руками.

Отличная статья по теме:

“Изучаем Redux на примере создания мини-Redux” @NTolochny https://medium.com/devschacht/jakob-lind-learn-redux-by-coding-a-mini-redux-d1a58e830514

#js

Самое крутое что случилось с CSS за последние годы — флекс боксы и кастом пропертис.

Простое и короткое введение в CSS-переменные (они же — кастом пропертис):

“Изучите CSS-переменные за 5 минут” https://medium.com/devschacht/%D0%B8%D0%B7%D1%83%D1%87%D0%B8%D1%82%D0%B5-css-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B7%D0%B0-5-%D0%BC%D0%B8%D0%BD%D1%83%D1%82-3a5dc6193857

#css

Наверно, самые большие проблемы в первые месяцы работы разработчики испытывают с гитом.

Не нужно бояться гита! Это простой и надёжный инструмент. Две тематические статьи. Первая — обзорная, вторая — что делать, если "все сломалось".

+ Git снизу вверх: https://habr.com/post/344962/
+ Git: распространненные ошибки и способы их исправления: https://habr.com/post/423015/

#git

Круто быть разработчиком. Не фронтендером, бекендером или верстальщиком.

Не важно в какой области разработки лежит проблема бизнеса — ее нужно решить.

И многие проблемы бизнеса связаны с доставкой приложения до клиента, масштабированием. Последние годы они решаются с помощью докера.

Любому разработчику будет полезно понимать, что это, как этим пользоваться и зачем оно нужно. Ниже тематическая статья.

“Docker для начинающего разработчика” https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d

#docker

Просто посмотрите этот доклад.

https://youtu.be/f4uXBpP_xxY

На ту же тему.

https://www.youtube.com/watch?v=xPFRUM_oDKA

Начал читать "Предметро-ориентированное проектирование" Эванса.

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

#ddd