Ключ к ускорению ваших навыков программирования Перескок “точки перегиба” и становление самостоятельным программистом

Когда вы учитесь программировать, есть момент, когда всё начинает меняться. Назовём это “точкой перегиба”.

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

Цель — не просто научить вас писать код, как создавать веб-приложения или как писать тесты. Основная цель — ускориться после “точки перегиба”, чтобы вы смогли решить любую проблему, с которой вы сталкиваетесь. Возможность решить проблему самостоятельно — бесценный навык, и этот метод обучения позволит вам намного больше, чем просто научиться создавать набор приложений.

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

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

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

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

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

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

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

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

Маленький секрет программирования ...

Вы никогда не узнаете всё, что вам нужно знать, чтобы решить все ваши проблемы в один щелчок. Пройдя обучение(будь-то университет, bootcamp,курсы и т.д.), вы, вероятно, предположите, что в конечном итоге узнали всё, что вам нужно, и лавочка закрыта. Этот момент никогда не наступит.

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

Вы будете готовы перейти на следующий этап своего “путешествия”, когда:

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

Точка перегиба

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

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

Во время фазы перегиба вы будете кодировать в 10-20 раз медленнее, чем на предыдущей фазе.

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

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

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

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

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

Некоторые программные инженеры остаются в своей зоне комфорта. Это тип программистов известен как “программисты по обслуживанию” — не то, к чему вам надо стремиться. Вместо этого вы должны стремиться расти каждый день. Самая распространенная причина, по которой программисты покидают свои рабочие места, состоит в том, что «это рутина, так как я решил всё самое интересное».

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

В веб-разработке есть две точки перегиба, которые приходят вместе.

Точка перегиба веб-разработки — это момент, когда вы становитесь способным создавать любое приложение, управляемое базами данных, которыми хотите. Это означает возможность создания веб-приложения со многими страницами, которые хранят и извлекают информацию из простой базы данных. Веб-разработчики называют это: « CRUD мастер». На этом этапе вы также сможете интегрироваться с любой сторонней библиотекой, просто следуя документации, предоставленной в GitHub.

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

Люди, “завоевавшие” точку перегиба алгоритмов и структур данных, смогут:

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

Вкратце, как только вы пройдете эту точку перегиба, вы освоите манипуляции с данными и поймете влияние производительности на ваши решения. Традиционные степени в области компьютерной науки сосредоточены исключительно на том, чтобы студенты прошли мимо точки перегиба алгоритмов и структур данных. Многие университеты преподают это с помощью языков программирования, которые обычно не используются в промышленности, таких как Scheme, Racket или LISP.

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

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

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

Последствия точки перегиба

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

В конечном счете, что действительно важно:

У вас есть четкое понимание структуры веб-разработки У вас есть полное понимание написания алгоритмически сложного кода на любом языке программирования

Хедхантеры хотят, чтобы разработчики обладали как навыками веб-разработки так и навыками алгоритмов и структур данных.

Не распыляйтесь. Многие люди скажут такие вещи, как «AngularJS в тренде в эти дни», «JavaScript на подъеме» или «последняя причуда ...» и т.д.

Ваш ответ на это должен прозвучать: «и что?». Когда вы учитесь программировать, вашей единственной целью должно быть найти точку перегиба и уничтожить ее. Как только вы это сделаете, изучение какой-либо новой тенденции не составит труда.

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

Это не означает, что вы сразу же «узнаете» всё,а, что всё теперь возможно.

Навыки, которые вы приобритете во время перегиба

Для программный инженер, лучший справочный материал — это аналогичный код, который вы уже написали. Когда вы полностью понимаете код, который вы написали, вам не нужно передавать все данные в память. Это означает, что первым вопросом, который вы должны задаться при создании новой функции, является следующее: «Я уже построил что-то подобное раньше?» Если да, верните тот код и пройдитесь по строкам. Объясните себе, что он делает, и спросите себя: «Можно ли сейчас использовать тот же подход?».

Предположим, вы хотите интегрироваться с API Карт Google. Как только вы испытаете это однажды, для открытия кода в GitHub может потребоваться меньше минуты, скопируйте код и вставьте его в новый проект.

Стратегии прохождения точки перегиба как можно более эффективно

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

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

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

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

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

Поймите, что это сложный процесс. Кроме того, установите реалистичные ожидания. Вы не можете сравнить скорость «сверхчеловека», который прошел через всё это, с вашей «улиткой» — скорости обучения предмета самостоятельно. Имейте в виду, что вы много учитесь, но на этом этапе вы изучаете новый навык, позволяющий самостоятельно разобраться в новых вещах. Вы работаете над уверенностью в себе, знайте, что то, что вы чувствуете, абсолютно нормально. Продолжайте работать. Если вы дошли до точки кипения, попробуйте поговорить с тем, кто недавно прошел точку перегиба. Он сможет понять ситуацию, в которой вы находитесь, и заверить вас, что то, что вы переживаете, является временным. Работайте последовательно, но не перегружайте себя. На этом этапе “игры” знайте, что вы можете быть продуктивным только в течение 6 часов в день максимум. Работа на пределе только продлит время, затрачиваемое на преодоления точки перегиба.

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

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

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

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

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

Вдохновение, чтобы написать об этом, пришло от Kelsey Hightower, который прекрасно рассказал о саморазвитии приложений Kubernetes. https://www.youtube.com/watch?v=XPC-hFL-4lU Рекомендую к просмотру.

Вот вам и TLDR; myapp --kubernetes --replicas=5

myapp сам статирует для Linux, монтирует себя и развертывает себя в кластер Kubernetes с 5 репликами. Никаких файлов конфигурации не требуются.

Я подумала, что это было бы очень круто, и тут же отправился проверять Kubernetes, чтобы посмотреть, могу ли я добавить что-то подобное Pilosa( https://github.com/pilosa/pilosa). В документации Kubernetes есть такая страница, посвященная «выбору правильного решения», которая имеет более 40 различных способов общения с Kubernetes, ни один из которых не «запускал этот двоичный файл». Я не хочу копаться в сомне страниц документации только для одного маленького быстрого эксперимента! Я знаю что Kubernetes это отличное программное обеспечение, и я готова поспорить, что скоро мы будем развертывать Pilosa в нашем собственном кластере Kubernetes. Однако в этот конкретный момент меня действительно поразила идея «саморазвертывания приложений», а не рутинная часть «на Kubernetes».

На самом деле я осознала, что уже проделала определенную работу в этом направлении для бенчмаркинга Pilosa. Первоначальная идея заключалась в том, чтобы создать инструмент, который с помощью одной команды смог бы: Предоставлять облачную инфраструктуру различным провайдерам Устанавливать и запускать кластер Pilosa на удаленных хостах Позволит определить высоко настраиваемые тесты Устанавливать и запускать тесты на удаленных «агентовских» хостов Собирать результаты тестов Собирать метрики хоста (процессор, память и т.д.) Хранить все данные каждого теста в согласованном формате Готовить и подавать вкусняшки(шутка) В любом случае мы фактически достигли некоторых из этих целей с помощью нового инструмента Pi. Pi — это инструмент, специально предназначенный для бенчмаркинга Pilosa, но я думаю, что он содержит некоторые многоразовые библиотеки, которые могут быть полезны для сообщества с открытым исходным кодом в целом (с возможностью его улучшения).

Это всё хорошо, но давайте вернемся к развертыванию приложений. Давайте отложим часть предоставления ресурсов из облака на данный момент, и скажем что у нас есть набор свежих, чистых, Linux-хостов, к которым есть ssh-доступ, и мы хотим непосредственно протестировать Pilosa. Допустим у вас есть локальная кодовая база Pilos (в вашем GOPATH), а также мифический инструмент Pi. Какова минимальная сумма работы, которую вы могли бы ожидать, чтобы запустить тест против кластера Pilosa и собрать результаты? Как насчет запуска одной команды на вашем ноутбуке в каком-нибудь переполненном кафе?

pi spawn --pilosa-hosts=<...> --agent-hosts=<...> --spawn-file=~/my.benchmark

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

Имейте в виду, что до того, как вы запустили Pi, этот пул удаленных хостов знать не знает о Go, Pilosa, Pi или о чем либо еще. Это были просто изображения Linux с AWS или GCP или что-то подобное. Как мы это сделаем? Давайте разобьем процесс на этапы: во-первых, нам нужно иметь возможность подключаться к удаленным хостам через ssh изнутри программы Go. Приятный сюрприз, оказывается у Go есть довольно большой пакет ssh(https://godoc.org/golang.org/x/crypto/ssh), который обрабатывает большую часть этого вместо нас.
Как только мы подключаемся к удаленным хостам, мы можем выполнять команды в оболочке как с терминала! Мы получаем стандартные интерфейсы Reader и Writer для получения данных в этих командах и из них, поэтому всё очень хорошо. Но что мы собираемся запустить? У этих хостов нет установленных Pilosa или Pi, которые нам понадобятся, если мы хотим запустить кластер и протестировать его. Ну, давайте просто запустим dog — у этих хостов определенно есть это, не так ли? В частности, мы будем запускать dog > pilosa — помните про Writer? Это на самом деле io.WriteCloser, и он идет прямо на stdin dog. Поэтому мы просто пишем весь бинарный файл Pilosa прямо там, закрываем его, и данные магическим образом переносятся в файл на удаленном хосте! «Подождите», скажете вы. «Какой бинарный? Мой ноутбук в этой кофейне не имеет бинарного файла Linux для Pilosa.» Как вы, возможно, догадались, Go экономит день, сделав его легким для перекрестного компилирования для других платформ. Теперь я знаю, что вы думаете: «Он собирается импортировать пакеты для компилятора Go, строить новый диск Pilosa непосредственно в памяти и передавать его прямо в dog, работающую на удаленном хосте. Я НЕ МОГУ ЖДАТЬ! " Да, нет, извините — это тот самый парень, который не мог потрудиться, чтобы запустить виртуальную машину, чтобы испытать Kubernetes. Я посмотрела на источник для инструментальной цепочки в течение минуты и решила использовать os / exec для запуска сборки go в подпроцессе.

com := exec.Command("go", "build", "-o", "someTempFile", "https://github.com/pilosa/pilosa") Ах да нам ведь нужно настроить среду, чтобы убедиться, что мы всё это дело создаем для Linux: com.Env = append(os.Environ(), "GOOS=linux")

Откройте временный файл dog,поместите его на удаленный хост, с помощью chmod, чтобы сделать его исполняемым, и … работаем! Давайте уделим минутку для обдумывания того как много Go помогло нам там — не только придал легкость перекрестной компиляции, а еще учтем тот факт, что мы можем скомпилировать автономный бинарный файл, который довольно легковесный, и это пожалуй всё, что нам нужно для запуска нашего приложения на другом хосте. Никакой JVM, никакого переводчика — это действительно просто очень освежает — как добротный лимонад. Хорошо, бинарный файл Pilosa на своем месте. Мы можем создать файл конфигурации и скопировать его таким же образом или просто запустить Pilosa с аргументами командной строки. После того, как он будет запущен, мы сможем передать любые логи обратно нам или оставить их в файле на удаленном хосте.

Теперь настало время обратить внимание на поставленную задачу — бенчмаркинг. Говоря формально, мы еще не создали самораспространяющееся приложение, мы создали приложение для развертывания Pilosa — помните, что это Pi, который делает всё это дело. Но нам нужно запускать Pi на удаленных хостах, потому что у Pi есть все инструменты для бенчмаркинга, и нет никакой причины, по которым этот кросс-компиляционный dog не будет работать так же, как в исходном коде самой программы, которая его запускает. Мы перекрестно скомпилируем Pi, копируем его на каждый из «агентов» и выясним, какие тесты мы должны запускать, и запускаем их! Бенчмаркинг Pi сообщают о своих результатах в формате JSON на stdout, который мы счастливо собираем. Это немного странно, но опять же, мы обязаны за предоставленные нам модели параллелизма, которые делает всё очень простым. Мы запускаем несколько разных программ на нескольких удаленных хостах, которые бросают огромные объемы данных друг на друга и делают массовые вычисления. И всё это из одной программы на одном обычном ноутбуке с хиленьким Wi-Fi-соединением. Не говоря уже о том, что мы передаем потоки и объединяем результаты всех этих удаленных программ в единую сплоченную структуру результатов, которая полностью описывает бенчмаркинг. Это было бы кошмаром наяву для большинства языков! Вот, у вас на руках самораспространяющееся приложение без использования Kubernetes. Всё, что вам нужно, это куча хостов, к которым у вас есть доступ через SSH, и вы тоже можете создавать сложные флоты самораспространяющихся программ. Изучите исходный код для Pi (особенно пакеты build и ssh) и прочитайте документацию, если вы действительно хотите их использовать. Возможно, вы тоже сможете подкинуть пару патчей проекту.

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

Как объясняет Тайлер Коуэн, «с начала 2005 года производительность труда растет в среднем на 1,3 процента ежегодно, по сравнению с 2,8 процента в год за предыдущие 10 лет». Его статьи желательны к прочтению всем, кто интересуется программной инженерией и компьютерной области в целом.

Программное обеспечение повысило производительность по всем направлениям для некоторых отраслей, таких как производство, но для многих других отраслей только определенные компании смогли сделать выгоду. Исследование, проведенное в 2003 году, показало, что в то время как Wal-Mart и Kmart инвестировали в ИТ, Wal-Mart лучше справлялся с изменением остальной части своего бизнеса на работу с технологией, и, следовательно, добился более высокого уровня производительности..

ПО не является инертным капиталовложением. Компания не может просто сбрасывать Microsoft Excel на свои ноутбуки и ожидать, что дополнительные деньги придут в прибыль. Ей необходимо нанять или же обучить сотрудников, которые хорошо разбираются в Excel, и изменить свои процессы, чтобы в полной мере использовать программу. Фактически, любой достаточно опытный пользователь программы Excel будет выполнять работу, очень похожую на разработчика программного обеспечения: создание внутреннего программного обеспечения (хотя и в сильно ограниченной среде). Компания, которая видит прирост производительности от использования Excel, уже наняла инженеров квази-программного обеспечения, но в названии должности, которую они занимают, с большей вероятностью будет содержать слово «аналитик», чем «инженер».

Excel и подобные программы — мощные части общего программного обеспечения. Квалифицированные пользователи могут создавать с их помощью мощное программное обеспечение, ориентированное на бизнес. Проблема в том, что для любого достаточно сложного бизнес-приложения Excel далеко не лучший инструмент для его создания. Образ, который приходит на ум, это кто-то, делающий стол с помощью швейцарского армейского ножа — это возможно, но потратить слишком много времени, и результат будет неудовлетворительным. Говоря о трате времени, чтобы доказать, что это возможно, Том Вильден Хайн построил машину Тьюринга с помощью Powerpoint. Эти общие программные приложения по своей природе ограничивают возможности создания внутреннего программного обеспечения, а также заставляют пользователей решать и даже определять свои проблемы на условиях, установленных этими самыми ограничениями. PowerPoint является самым известным “преступником” в этом отношении, он взорвал Колумбийский космический корабль и представляет собой экзистенциальную угрозу для американских военных.

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

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

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

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

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

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