Андрей

Я начал в 13, сам. Причем до этого попробовал разные компьютерные игры - не зашло.

В некотором смысле программирование - это авторитарная диктатура. Я диктую машине что делать, а она выполняет моментально и беспрекословно. Или не выполняет, если я натупил... Пёрло меня с этого нипадецки. Плюс никто не объяснил вовремя, что это трындец как сложно. А потом стало получаться...

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

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

Моему сыну сейчас 12 и он вроде как пытается пойти этим путем. Я его не форсирую. Если обращается за помощью - помогаю, но ровно на столько, чтобы он сдвинулся с мертвой точки. За него его работу я не делаю принципиально. Это жизненно важно для программиста - уметь самостоятельно разруливать весьма сложные тупики, разбираться в нетривиальных засадах. Совершенно не факт, что он именно в эту сферу двинет с годами, но некоторые навыки программирования никому лишними не будут в наши времена.

А еще часть клиентов будет отказываться от ряда цепочек, так-что невозможно найти одну-единственную и вариантов будет уйма.

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

Компьютер, это от аглицкого to compute - вычислять, т.е. вычислятор. Все что умеет делать компьютер - это взять биты там, что-то с ними сделать в плане их трансформации в другие биты, причем путем вычислений, и положить это куда-то еще. На этом всё. Занавес.

Казалось бы, при чем тут математика? А при том, что как без нее вычислять?

Поэтому, что бы ни делал компьютер, играет ли он музыку, рендерит ли 3D, ходит ли в интернет, в конечном счете все сводится к вычислениям, а, стало быть, к математике. Дважды занавес.

Во первых необходима годная архитектура приложения. Я за счет жеско opinionated структуры путей в своем нано-фреймворке на 90% снизил оверхед на "подумать" а где у меня что.

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

В третьих иммутабельность. Если ты меняешь в одно месте, а сломалось/упало в другом, то поздравляю, поциент, у вас мутабельность третьей степени и это фатально. Все что можно перевести в pure functions и immutable structures (тут с осторожностью, ибо можно выстрелить себе в ногу и уронить производительность ниже плинтуса).

Опять же, единственный source of truth спасает.

И самое главное, код надо писать так, чтобы он был понятен с первого взгляда, максимум со второго. Не надо в коде выеживаться и быть многословным. Код должен быть простым и лаконичным. Говоря что snake_case более читабельный, чем километровыйКамелКейс. Я, пожалуй, соглашусь, хотя использую в коде последний в основном.

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

По крайней мере в последние годы я с ходу понимаю что я там намудрил в проекте и через месяц, и через 6, и через 2 года. А раньше да, бывало через 3 месяца хотелось убить того ишака, который это написал, а потом вспоминаешь, что это был ты сам... :D

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

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

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

Код надо стараться писать так, словно после тебя с ним будет работать психопат, который знает где ты живешь. :)

Каждое слово имеет несколько смыслов, иногда несколько десятков смыслов. Можно, конечно, учить самые ходовые 2-3, но всегда есть риск упустить тонкие оттенки и нюансы. Я бы рекомендовал учить слова обязательно в контексте.

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

Я всегда учу только самый необходимый минимум, исходя из принципа Парето, что 20% усилий дают 80% результата. Зачастую этих 80% результата за глаза хватает для большинства задач.

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

На холостом ходу, впрок информация у меня лично не усваивается от слова совсем, по этой причине стихи в школе не учил, не запоминались даже при -дцатикратных повторениях...

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

Такой вид деятельности человека, как разработка программ, состоит из нескольких составляющих.

Язык программирования - это инструмент, как молоток. Можно гвозди забивать, а можно по пальцу себе стучать, или на ногу уронить, ну и масса еще менее конструктивных способов применения.

Вот допустим ты раздобыл инструмент и даже пару гвоздей забил им. Хорошо. Теперь перед тобой стоит задача построить сарай, и ты, вдруг, понимаешь, что кроме забивания гвоздей нужно еще кое-что:
1) Нужно определить место, где будет построен сарай
2) Нужно определиться с размерами сарая
3) Нужно набросать некий план устройства сарая (гайдлайн/проект)
4) Нужно прикинуть количество и виды строительных материалов
4.1) Допустим строим самый простой деревяный сарай:
4.1.1) Нужно посчитать брус под опоры (каркас)
4.1.2) Нужно посчитать облицовочный брус
4.1.3) Внезапно сараю нужны ворота
4.1.4) Так же сараю нужна крыша, так-что в пункт 4.1.1 внезапно добавляем брус под каркас крыши
4.1.4.1) Крышу решили облицовывать шифером, так-что закладываем шифер, предварительно посчитав площадь покрытия
4.1.5) Оказалось что с земли строить сарай не удобно, нужна лестница
4.1.6) Брусья оказались весьма тяжелыми, так-что нужна либо лебедка, либо помощники, а лучше то и другое сразу
4.1.7) Опоры оказывается нужно заглублять в землю на полтора метра, иначе получается неустойчивая конструкция - пришлось озаботиться выкапыванием ям под опоры. Ломом это делать оказалось долго и муторно, да и лом пришлось приобрести
4.1.8) Сосед подсказал, что если просто закопать опоры, то они сгниют за два года. Нужно опоры просмолить. пришлось купить бочку смолы и соорудить печь, чтобы смолу разогреть.
4.1.9) Гвозди сотки забивать в доски и опоры простым молотком оказалось неудобно, пришлось приобрести молоток помощнее, но он оказался тяжелым и руки быстро устают. Работа идет очень медленно
4.1.10) Сосед подсказал крепить доски саморезами. Пришлось купить саморезы и шуруповерт
4.1.11) Аккумулятор у шуруповерта оказался слабый, он 10 минут работает и полтора часа заряжается. Пришлось купить еще один, работающий от розетки
4.1.12) Второй шуруповерт За пол-часа разогревается так, что рискует расплавиться. пришлось купить еще одиин и работать ими попеременке
4.1.13) Вот сарай построен, ворота установлены, оказалось что на ворота нужен замок
4.1.14) Еще в сарае очень темно, пришлось провести туда электричество, для этого пришлось вкопать пять столбо ви приобрести 200 метров кабеля, и прочую электрическую мелочь типа выключателей
4.1.15) По дереву монтировать проводку необходимо внавес, чтобы кабель не контактировал с деревом, пришлось заморочиться
4.1.16) Зимой сарай оказался очень холодным, дерево промерзает и сыреет. Пришлось задуматься об утеплении сарая снаружи, но это летом, пока терпим.

Ну и так можно проодлжать до бесконечности.

А теперь, внимание, вопрос - а при чем здесь вообще молоток?

PS: Разумеется когда ты построишь десяток-другой разнообразных сараев, многие из этих вопросов ты будешь обдумывать заранее, стало быть сюрпризов станет гораздо меньше, а сбываемость прогнозов гораздо выше. Тем и ценен опыт - сын ошибок трудных.

Сам там балуюсь по мере свободного времени, сил и желания, чисто для поразмять мозги, т.к. в олимпиадах я участвовал давно, последний раз аж в 1998 году. Пруф: https://www.codewars.com/users/iCoderXXI

У меня не всегда получается сразу понять чего хочет автор задачки, приходится перечитывать раз по десять-дцать, вникать, в принципе как и в реальных боевых задачах в жизни. Всегда стараюсь построить в голове работающую модель процесса, так сказать в динамике, входящие и исходящие сигналы (данные), логику, алгоритмы.

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

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

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

Вообще моё ядро, как программиста, формировалось в условиях жестких ограничений, чего стоит только ограничение по памяти в 64 кб на переменные у паскаля. Конечно я не долго терпел это издевательство, и достаточно быстро разобрался с указателями, кучей, структурами данных, так-что моим программам было доступно до мегабайта и более под данные, хотя конечно логика становилась весьма витиеватая.

Где-то даже сохранился код гипертекстового компилятора и просмотрщика, который я писал в 1997 году по заказу одного юриста. Сейчас оно никому не надо, т.к. есть всякие Консультант+, но по тем временам я считаю был весьма интересный продукт. Кому интересно вот ссылка на гитхаб https://github.com/iCoderXXI/hypertext

Если события поступают достаточно часто, то при успешной обработке писать в поле mictorime(TRUE).
Перед отработкой проверять это поле и текущий microtime(TRUE) и отбрасывать событие, если еще не вышел расчетный таймаут. Для 200 событий в минуту таймаут будет 60/200.

1) Нужно понимать основы, принципы и знать или уметь быстро найти, где почитать про детали, благо нынче с этим проблем вообще никаких.

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

3) Задания лучше получать от платежеспособных заказчиков. Поначалу, если обстоятельства позволяют, можно работать за отзывы, или поискать команду/профи, кто возьмет на обучение в качестве стажера/джуниора.

Главное - иметь светлую голову и прямые руки.

ЗЫ: Я исключительно на практике осваиваю конкретные навыки в необходимом и достаточном объёме для решения конкретных задач. И делаю так уже 20 лет. При этом постоянно для общего развития отслеживаю тенденции, читаю статьи, слушаю выступления на конференциях, благо, опять же, нынче этого добра навалом.

Десктопные приложения я писал очень давно, еще под DOS на Clipper 5.2, а до того вообще на Borland Pascal 6/7. Как только в коде появлялся мало-мальски долгоиграющий расчет, интерфейс зависал и интерактив сводился к нулю.

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

Сегодня актуален JavaScript

Я начал плотно изучать программирование лет в 14, в 16 написал первую коммерческую программу и что-то на этом заработал. Мастерство приходит примерно после 10 тысяч часов адресной практики, количество дней и лет можно посчитать, многое будет зависеть от интенсивности занятий. Я бывало кодил по 12-16 часов в сутки практически без перерывов, так меня пёрло и штырило...

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