Что я понял после 10 тысяч часов в разработке

Согласно распространенному убеждению, если чем-то заниматься 10 тыс. часов, то станешь в этом мастером. Так ли это, узнал разработчик Мэтт Рикард. Он программировал в течение 10 тыс. часов и поделился своими размышлениями.

Автор уточняет, что его размышления — это не советы по карьере, они, скорее, о том, как стать хорошим программистом.

В течение своих 10 тыс. часов Мэтт Рикард: 

• Работал инженером в Google Kubernetes и частной инвестиционной компании Blackstone;
• Писал программы для собственных проектов;
• Запускал ботнет на RuneScape;
• Работал над крупными проектами с открытым исходным кодом;
• Поддерживал подпроекты;
• Разрабатывал приложение для перевода на латынь для iPhone;
• Создавал веб-клиппер. 

Вот какие выводы сделал автор:

1. Посмотреть в источнике почти всегда быстрее, чем найти ответ на Stack Overflow.

2. В основном на то, над чем вы работаете, не бывает ответа в интернете.

3. Сокращайте код настолько, насколько сможете.

4. В основном синтаксический сахар вредит коду.

5. Писать просто — сложно.

6. Имейте в арсенале широкий выбор инструментов и знайте, какие из них использовать в работе.

7. Освойте такие команды, как git и bash, rebase и merge.

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

9. Учитесь только у лучших.

10. Если код выглядит небрежно, скорее всего, в нем ошибка.

11. Если вам нужно написать комментарий, который не является строкой документации (docstring), его, вероятно, следует отредактировать. Каждая новая строка комментариев увеличивает эту вероятность.

12. Если вы не понимаете, как работает ваша программа в производственной среде, вы не понимаете саму программу.

13. Правило выше касается и разработки по типу конвейера.

14. Используйте чужой код с осторожностью.

15. Потому что большая часть чужого кода ужасна. Иногда проще самому написать с нуля.

16. Никогда не полагайтесь на небольшую библиотеку, которую можно легко переписать, или большую библиотеку, которая могла бы быть небольшой.

17. Знайте, когда можно нарушать правила.

18.Важно разбить код на модули, пакеты и функции. Знать, где материализуются границы API, — это искусство.

19. Старайтесь использовать наиболее эффективный и подходящий для выполнения задачи инструмент, но также опирайтесь на то, что знаете. Например, Arch Linux — самая эффективная операционная система (ОС) для современного разработчика? По словам автора, для него — да, но для большинства, вероятно, нет.

20. Избегайте цикломатической сложности. Начинающие программисты могут даже не подозревать, что запутали граф зависимости, пока не станет слишком поздно.

21. Избегайте глубокого уровня вложенности  условных выражений.

22. Назвать переменную правильно — это искусство.

23. Редко, но иногда проблема все же бывает в компиляторе, в противном случае — дело всегда в DNS.

24. Используйте малоизвестные языковые функции только тогда, когда это действительно нужно.

25. Технологии не распространяются одинаково. Например, фронтенд-разработчики могут многому научиться у низкоуровневых инженеров. В то же время есть функции UX и юзабилити, которым JavaScript-разработчики могут обучить облачных инженеров.

26. Поэтому разные инженеры по-разному воспринимают мир.

27. Некоторые программисты в 10 раз эффективнее других.

28. Хороший программист — не обязательно хороший сотрудник (иногда, скорее, наоборот).

29. Хорошие API-интерфейсы просты в использовании, и их трудно использовать неправильно.

30. Цикл конфигурации идет от жестко запрограммированных значений к переменным среды, к флагам CLI, к файлу конфигурации, к шаблонному файлу конфигурации, к DSL, к общему сценарию bash и обратно к жестко запрограммированным значениям.

31. Все уровни абстракции преодолимы. Если наткнетесь на стену — можно спуститься на уровень абстракции ниже. Вы не ограничены одной поверхностью.