Повышает ли разработка программного обеспечения IQ?

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

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

• 1.- Хорошие практики разработки программного обеспечения, влияющие на ваш образ мышления
• 1.1.- Простота
• 1.1.1.- Почему компьютеры так постоянно ломаются?
• 1.1.2.- Что такое плохой программист?
• 1.1.3.- Как быть хорошим программистом?
• 1.1.4.- Сложнее программировать упрощенным способом?
• 1.2.- Тесты
• 1.2.1.- Компьютерные ошибки произошли из-за отсутствия или неправильного использования программных тестов
• 1.2.1.1.- Неисправность радара детектора ракет
• 1.2.1.2.- Уничтожение Mariner I
• 1.2.1.3.- Therac-25, линейный ускоритель лучевой терапии
• 1.2.1.4.- Корабль Йорктаун (CG-48) и его деление на ноль
• 1.2.1.5.- Процессор Intel Pentium с ошибками разделения
• 1.2.2.- Пример программного обеспечения, близкого к совершенству
• 1.2.3.- Каков текущий ландшафт тестирования программного обеспечения?
• 1.2.3.1.- Ошибки и несоответствия при тестировании программного обеспечения сегодня
• 1.2.3.2.- Формальная разработка как предлагаемое решение непоследовательного тестирования программного обеспечения
• 2.- Как непрерывное обучение приносит пользу нашему мозгу?
• 2.1.- Интеллект основан на нейронной эффективности - Erhan Genç
• 2.2.- Как программирование влияет на наши умственные способности?
• 2.2.1.- Инструменты, которые мы используем для программирования, влияют на наши ментальные модели
• 2.2.1.1.- Почему ИТ-сектор является одним из самых рекомендуемых в 2021 году?
• 2.2.2.- Это здорово для мозга
• 2.2.3.- Во время программирования вы стимулируете до 5 областей своего мозга.

Хорошие практики разработки программного обеспечения, влияющие на ваш образ мышления

Когда у нас уже есть опыт разработки программных проектов, мы уже построили мысленную модель того, каким может быть идеальный программный проект. Но, как правильно разработать программный проект?

Это может показаться не очень сложным, потому что сегодня в Интернете можно найти много информации о методологиях. для разработки проектов, таких как SCRUM или Extreme Programming. Оба предоставляют нам рекомендации, которым мы должны следовать в течение цикла разработки проекта, чтобы гарантировать организацию, наблюдение, оценка времени и / или командная работа.

С нашей точки зрения:

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

Альберт Эйнштейн однажды сказал:

Если вы не можете объяснить это просто, значит, вы недостаточно хорошо это понимаете. Albert Einstein

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

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

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

Простота

Сделайте свой код максимально простым!

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

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

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

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

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

Если посчитать, то только по моему опыту существует 480 различных форм поломок. И это не круто.

Почему компьютеры так постоянно ломаются?

Когда дело доходит до программного обеспечения, причина только одна: плохие программисты.

Лет 5 назад у меня появилось подозрение, что причина в плохих программистах; однако я не был уверен. Теперь, имея еще несколько лет опыта в области ИТ и проконсультировавшись со многими экспертами в их публикациях, я больше не сомневаюсь.

Я могу полностью сказать, что плохие программисты виноваты в бесчисленных компьютерных сбоях.

Что такое плохой программист?

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

Если подавляющее большинство программистов - люди вполне логичные, почему существует программное обеспечение с таким количеством ошибок? Основная причина компьютерных ошибок - это СЛОЖНОСТЬ.

Сборка компьютера, наверное, самый сложный процесс, который я знаю, потому что за каждую прошедшую секунду могут быть выполнены миллионы задач. Кроме того, в нем есть тысячи деталей, которые должны работать синхронно. Одна только операционная система, которую использует компьютер, состоит из десятков миллионов строк кода. Только в Windows 10 более 4 миллионов файлов и более полумиллиона папок. Доказательством этого является следующий захват:

Чтобы дать вам еще более полное представление, ниже я подробно описываю количество строк кода на операционную систему:

Операционная система	Строки кода
Linux 3.1 Kernel	15 миллионы
Windows XP	40 миллионы
Windows 7	40 миллионы
Windows Vista	50 миллионы
Debian 5.0 (базовый код)	67 миллионы
Mac OS X «Lion»	85 миллионы

Оставляю вам дополнительную информацию:

Facebook имеет около 61 миллиона строк кода, а Google - около 2 миллиардов строк кода.. Конечно, это оправдано большим количеством услуг, предлагаемых Google.

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

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

Короче говоря, в этом и заключается суть программирования: «Упростите сложность».

Как быть хорошим программистом?

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

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

Сложнее программировать упрощенным способом?

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

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

Вам просто нужно оглянуться вокруг и понять, насколько СЛОЖНОСТЬ превратилась в программное обеспечение.

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

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

Тесты

Всегда запускайте тесты. Они не являются обязательными!

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

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

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

Компьютерные ошибки произошли из-за отсутствия или неправильного использования программных тестов

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

Неисправность радара детектора ракет.

Это произошло в 1983 году, когда советская система предупреждения о ракетном нападении сообщила, что Соединенные Штаты запустили 5 ракет, и они были запущены.

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

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

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

Оба эти метода являются частью тестирования программного обеспечения.

Уничтожение Mariner I

Произошло в 1962 году и привело к убыткам в размере около 18,5 миллионов долларов США. Mariner I был первой миссией в программе Mariner, которая, к сожалению, безуспешно пыталась пролететь над Венерой.

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

Ошибка позже была определена: формула в коде, которая была запрограммирована неправильно.

Therac-25, линейный ускоритель лучевой терапии

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

С июня 1985 года по январь 1987 года Therac-25 производился компанией AECL (Atomic Energy of Canada Limited). был участником как минимум 6 несчастных случаев и 3 смертей от передозировки радиации.

После расследования был сделан вывод, что Основные причины аварий Therac-25 заключались в следующем::

• Плохая практика разработки программного обеспечения.
• Плохой анализ требований.
• Плохой дизайн программного обеспечения.

И если этого было недостаточно, программное обеспечение, на котором работал Therac-25, было разработано таким образом, что его было почти невозможно идентифицировать. и исправлять ошибки или ошибки автоматически.

Найдены другие причины:

• AECL никогда не отправлял независимую организацию для проверки исходного кода.
• При проектировании не учитывалась функциональность, связанная с управлением рисками.
• Система не позволяла проверить правильность работы датчиков.
• Были переменные-флаги, которые меняли свое значение вместо того, чтобы сохранять постоянные значения.
• Переполнение переменной "class3".
• Среди прочего.

Корабль Йорктаун (CG-48) и его деление на ноль

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

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

Процессор Intel Pentium с ошибками разделения

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

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

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

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

Как вы могли заметить, тестирование - это фундаментальная часть любого проекта. Они не являются обязательными!

Согласно Илен Бернштейн в своей книге: “Практическое тестирование программного обеспечения”, Тестирование программного обеспечения включает 3 основных процесса:

• Разработка тестового случая
• Выполнение тестовых случаев
• Анализ результатов

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

Хорошо сказал Эдсгер Дейкстра:

Тест может показать наличие ошибок в программе, но не их отсутствие Edsger Dijkstra (Премия Тьюринга в 1972 году)

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

Пример программного обеспечения, близкого к совершенству

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

Линия 14 парижского метро полностью автоматизирована. Поезда без машиниста и управляются программным обеспечением. Эта железнодорожная линия введена в эксплуатацию в 1998 году.

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

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

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

Конечно, «Вы не узнаете до своей очереди», как в случае с INTEL, компании пришлось потерять около 350 миллионов долларов из-за ошибки вычислений в программном обеспечении процессора. Ошибка, которая привела к тому, что она стала одной из ИТ-компаний с самым большим бюджетом на исследования по тестированию программного обеспечения.

Каков текущий ландшафт тестирования программного обеспечения?

Путь к разработке программного проекта состоит из 3 четко определенных этапов:

• Specifications
• Дизайн и кодирование
• Валидации

На этапе проверки ответственные инженеры удостоверяются, что программное обеспечение соответствует тому, что запланировано в спецификациях. они делают это путем «тестирования».

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

То, что описано выше, имеет большую проблему несоответствия, я объясню вам это ниже:

Ошибки и несоответствия при тестировании программного обеспечения сегодня

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

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

• получает на вход любое число,
• добавить 10 и
• в результате возвращает значение суммы.

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

Если мы попытаемся быть логичными (как и должно быть, если мы посвятили себя области вычислений), утверждая, что программное обеспечение является правильным после завершения фазы тестирования и не обнаружив ошибок, мы получаем то, что называется: “Призыв к заблуждению невежества”.

В логике аргумент ad ignorantiam, или argumentum ad ignorantiam, также известный как призыв к неведению, заблуждение, которое состоит в подтверждении истинности (или ложности) предложения, утверждающего, что нет доказательств противного, или же заявление о неспособности или отказе оппонента представить убедительные доказательства обратного. Это нетерпение к двусмысленности часто критикуют фразой: «отсутствие доказательств не является доказательством отсутствия», то есть это заблуждение совершено когда истинность или ложность предложения делается на основании существующего незнания о нем. Призыв к заблуждению невежества

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

Просто чтобы дать вам представление:

• Традиционный метод тестирования программного обеспечения включает обнаружение дефектов в программном обеспечении.
• Впоследствии вступает в фазу отладки, то есть просмотр кода, чтобы понять причины сбоев. и, наконец, исправление программных дефектов.
• Работая таким образом, программисты в среднем тратят 49,9% своего времени на отладку собственных ошибок.
• Это означает, что мировые расходы составляют 156 миллиардов долларов в год.

Формальная разработка как предлагаемое решение непоследовательного тестирования программного обеспечения

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

Используя формальный метод разработки наших программных проектов, достоверность свойств и / или функциональных возможностей программного обеспечения гарантируется посредством дедукции, другими словами, посредством математики (p -> q).

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

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

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

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

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

Обучение - это топливо для нашего мозга.

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

Всегда будет чему поучиться.

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

Современные исследования показали, что мозг имеет способность постоянно изменяться и деформироваться (пластичность), и не только у детей, но и у взрослых.

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

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

Для этого исследования IQ был рассчитан по следующим факторам:

• Возможности анализа
• Отражательная способность
• Разрешение проблемы

Вот еще немного информации о рассматриваемом исследовании:

Интеллект основан на эффективности нейронов - Erhan Genç

Команда под руководством Эрхана Генча проанализировала мозг 259 мужчин и женщин в возрасте от 18 до 40 лет, здоровых и здоровых. для измерения дендритов в коре головного мозга, то есть отростков нервных клеток, которые клетки использовали для связи друг с другом при выполнении интеллекта.

Перед исследованием все участники прошли тест на IQ. Изучив дендриты, Было определено, что чем выше IQ, тем меньше дендритов в коре головного мозга.

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

Исследования были проверены на выборке из 500 человек, и были сделаны те же выводы.

Эрхан Генч, ведущий автор исследования, пришел к выводу:

Интеллектуальный мозг характеризуется тонкой, но очень эффективной нейронной сетью. Это помогает достичь высокого уровня мышления при минимизации нейронной активности. Erhan Genç

Как программирование влияет на наши умственные способности?

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

Но как он это делает? Посмотрим.

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

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

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

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

Я упомяну тебя ниже 3 способа воздействия программирования на ваш мозг:

1. Инструменты, которые мы используем для программирования, влияют на наши ментальные модели

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

Дейкстра, один из пионеров в создании распределенного программирования, сказал:

Инструменты, которые мы используем, оказывают глубокое (и изощренное) влияние на наши привычки мышления и, поэтому в нашем навыки мышления. Edsger Dijkstra

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

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

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

Сегодня лучшее время для начала. Посмотрим, почему:

Почему ИТ-сектор является одним из самых рекомендуемых в 2021 году?

По данным Экономической комиссии для Латинской Америки и Карибского бассейна (ЭКЛАК), страны Латинской Америки начнут рост после экономического спада 2020 года.

Ожидается, что к 2021 году рост составит 3,7%, где главными героями будут те, кто предан цифровому миру.

2. Это здорово для мозга

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

Давайте рассмотрим некоторую предысторию, подтверждающую пользу программирования для здоровья мозга:

В 1991 году в ходе исследования изучалось влияние компьютерного программирования на когнитивные результаты и было установлено, что учащиеся в областях, связанных с программированием, набирают на 16 процентильных баллов выше среднего по тестам IQ.

Другое более крупное исследование, проведенное в 1999 году, завершилось подтверждением того, что интеллектуальные занятия служат буфером для предотвращения когнитивного спада.

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

3. Во время программирования вы стимулируете до 5 областей своего мозга.

В 2014 году исследование под названием “Понимание исходного кода Понимание с помощью функциональной магнитно-резонансной томографии” использовали функциональную магнитно-резонансную томографию, чтобы наблюдать активность мозга, когда программисты пытались работать и понимать фрагменты кода.

Был сделан вывод, что задействованы 5 областей мозга:

• BA 6: Средняя лобная извилина (внимание, язык, рабочая память)
• BA 21: Средняя височная извилина (поиск семантической памяти)
• BA 40: Нижняя теменная доля (рабочая память)
• BA 44: Нижняя лобная извилина (рабочая память)
• BA 47: Нижняя лобная извилина (язык, рабочая память)

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

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

Программирование - это самое близкое к сверхспособностям. Drew Houston, Генеральный директор Dropbox