В продолжении вчерашней статьи про мифы и реальность в программировании. На мой взгляд, есть три основы эффективности. Это простые житейские правила, которые удивительным образом применимы и в профессии программиста, и в любых других жизненных сферах.
По сути своей, программирование это такая же точно профессия как и любые другие. В первые несколько лет это романтично, потом обычно, а потом прагматично. Спустя какое-то количество лет опыта, 3 золотых правила логически выводятся вполне естественным образом. И вероятно, если Вы присмотритесь к привычному делу, которым занимаетесь последние годы - то обнаружите подобные принципы собственной эффективности.
Правило №1. «В программировании не бывает чудес»
Любая непонятная ситуация имеет логическое объяснение. Даже если происходящее кажется невероятным, непостижимым, невозможным. Даже если перепробовал все методы и нет очевидного решения. Даже если потратил 4 дня на поиски проблемы, а ответа всё еще нет. Вот даже во всех этих случаях - всегда существует ответ. Просто на текущий момент он не виден. Или ты пытаешься решить задачу более высокого порядка, находясь в более низком слое опыта.
Внутри компьютера нет ничего чудесного. Там пластиковые платы, много проводов, ещё больше транзисторов и прочей электроники. Всё это связано между собой, настроено и налажено. Потом поверх этого написан программный код, который работает достаточно точно и предсказуемо. Не бывает ситуаций, когда компьютер делает что-то "от себя", вопреки здравому смыслу и многолетнему опыту программиста. А вот несогласованность личного опыта и попытка заставить компьютер сделать что-то неправильным образом - это как раз бывает.
Когда человек смотрит на ситуацию с точки зрения "чуда", то он перекладывает ответственность на третье лицо. Виновата программная среда, плохой компьютер, неправильная документация, и кто угодно ещё. Когда человек смотрит на ситуацию с точки зрения логики, он берёт ответственность на себя. Взяв на себя личную ответственность, происходит эффективный рост - как специалиста, так и человека, его личности.
Но! Я хочу заметить, что в жизни (в отличие от программирования) чудеса иногда случаются. По крайне мере, со мной случались. Но рассчитывать на чудеса как на базовый жизненный сценарий, подходит далеко не всем.
Правило №2. «В любой непонятной ситуации ищи ответы»
В мире сотни языков программирования и десятки стилей написания кода. Миллионы готовых программных библиотек и модулей, всяческих шаблонов и утилит. Кто-нибудь может переварить такой объем информации и не поехать кукухой? Возможно! Но я точно не один из этих людей.
Создавая новый проект или расширяя существующий код, всегда возникает необходимость поиска и изучения информации. И здесь нет золотой пули вроде «спроси у более знающего» (особенно когда сам являешься этим более знающим). Для меня лично, и для многих известных мне программистов, есть очень простой метод, и это искать ответы в поисковых системах. То есть, в любой непонятной ситуации, заходим в поисковик и простыми словами пишем «Как решить такую-то проблему» и читаем результаты. При отсутствии полезной информации с первого раза, перефразируем запрос и повторяем процесс до получения успеха.
Найти готовый ответ гораздо проще, чем перебирать все возможные варианты и ставить личные эксперименты. И тем более лучше, чем зацикливаться на самоедстве на тему "как плохо что я этого не знаю".
В школе нам говорили, что списывать плохо. И наверное это действительно было не очень конструктивно. Но. По личному опыту - я не знаю ни одного программиста, который бы не искал информацию, каждый день. Такой вот казус, программисты это сообщество списывающих друг у друга специалистов.
Правило №3. «Не усложняй»
Создавая любой продукт, нужно стремиться к упрощению. Решая любую задачу, нужно стремиться к упрощению. Помните второй закон термодинамики? Вот там такое написано: «Любая система стремится к уменьшению свободной энергии и устойчивому состоянию, которому соответствует состояние с наименьшим значением свободной энергии». Иначе говоря, любая система сама стремится к самому простому и ресурсосберегающему состоянию. Вот так же нужно делать и с программным кодом, интерфейсом программ и технической документацией.
Любая программа состоит из множества модулей, большая часть которых - уже готовые части программы, написанные кем-то до тебя. И лучше, если программист умеет находить и использовать готовые модули. Лучше, если количество программного кода, который пишет программист "от себя" - минимально. Как говорится, лучший дизайн - это отсутствие дизайна. Лучшая кнопка в машине - это кнопка которой нет.
Старайся делать программы таким образом, чтобы их смог использовать даже ученик 5-го класса средней школы. Старайся писать код таким образом, чтобы спустя 2 года ты сам смог разобраться в нём за 15 минут. На моей практике, этот подход оправдал себя многократно. О количестве сэкономленных этим подходом денег можно только догадываться.
Сложно ли устроено колесо? Нет. А водопровод? А спички? А хлеб? Как говорится, "Все гениальное - просто!". Такие дела.
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Для тех, кто хочет не просто читать о программировании, а начать свой путь джедая прямо сейчас, приглашаю на Boosty! Там эксклюзивный обучающий материал по программированию для любого уровня подготовки. А ещё там можно посмотреть, как автор выглядит в жизни. Жми сюда и полетели!🚀
P.S.2 У меня ещё есть Telegram-канал. Там посты чуть попроще, и чуть повеселей. Ссылка
