В чем отличие между программистом и пользователем
В чем отличие программиста и пользователя
Для современного человека применение компьютера является обыденным делом. Умная техника используется в работе и в быту. Люди, для которых компьютеры стали профессиональным делом, называются программистами. Однако часто в их адрес можно услышать термин «пользователи». В чем же отличие между программистами и пользователями?
В основе деятельности программиста лежит написание непосредственно программ. Данный навык может использоваться в работе как ключевой либо вспомогательный, а также как инструмент решения задач в непрофессиональной сфере. Программисты необязательно имеют профильное образование. Предметом деятельности программистов в науке является решение задач с применением методов прикладной математики и реализацией на ЭВМ.
В развитых странах потребность в специалистах данного профиля чрезвычайно высока. Квалификационные требования и опыт, необходимые для той или иной работы, разнятся, так как программирование применяется в большинстве сфер. Часто специалистам приходится получать дополнительные, более узкие знания, проходить переобучение и совершенствовать знания. Одним из ключевых характеристик любого программиста является умение осваивать новые технологии в короткие сроки.
Программист – это род занятий, в разговорной речи объединяющий инженеров, системных администраторов и других IT-специалистов. В настоящее время широко применяется классификация программистов на прикладных и системных. Деятельность первых отвечает потребностям конкретного пользователя и лежит вне компьютерной среды. Деятельность системного программиста обеспечивает работоспособность компьютерной техники.
Согласно терминологии, пользователь — это физическое лицо или организация, использующее действующую систему для выполнения конкретной функции. С точки зрения информационной безопасности, пользователем является только человек, который при помощи программы выполняет определенные задачи. Сведения о пользователе содержатся в его профиле или учетной записи. Доступ к ресурсу предоставляется только после идентификации пользователя в абонентской системе. Для этого используется предварительно зарегистрированный логин и пароль. Пользователи получают разнообразные виды услуг, предоставляемые прикладными службами.
Выводы:
Менеджер vs Программист
На данный момент существует довольно серьезная пропасть в понимании работы друг друга между программистами и менеджерами. Мы будем постепенно сужать эту пропасть, с обеих сторон. В идеале, конечно, хочется, чтобы граница растворилась вообще, и появилась новая профессия – бизнес-программист, но, будем реалистами, если у нас получится сблизить видение реальности менеджеров и программистов, то жизнь точно станет лучше.
Итак, попробуем разобраться, что общего между программистом и менеджером, а в чем они, на данный момент, различаются.
Программист
Программист, в смысле настоящий программист – это человек, который пишет программы. Для простоты, чтобы не запутаться в бесконечном перечне современных технологий, будем говорить о программистах 1С.
Ключевая функция программиста – внесение изменений в систему. Есть, конечно, второстепенные функции, вроде обучения, внедрения, и иногда, при плохой организации работы, второстепенная работа начинает преобладать над основной, но тем не менее, главное – внесение изменений. Программист создает новый функционал – документы, справочники, подсистемы, отчеты, обработки, обмены, интерфейсы и т.д.
Сегодня пользователи работают с одной системой, с определенными показателями производительности, масштабом функциональности, удобством и т.д. Завтра, после внесения программистом изменений, они работают с другой системой. Она, обычно, становится лучше, быстрее, полезнее и удобнее. Всякое, конечно, бывает, иногда система на короткий промежуток времени становится хуже, но потом программист во всем разберется и все встанет на свои места – система станет лучше.
Программист или не работает вообще, или минимально участвует в системе в качестве пользователя. Понятно, что он, как сотрудник компании, тоже ведет в ней свои задачи, бюджеты, иногда табель. Но основная его работа – улучшение системы.
Плохой программист
Кроме настоящих программистов, есть еще ненастоящие, или плохие программисты. Отчасти это связано с неправильным использованием термина «программист» — например, иногда так называют системных администраторов. Иногда даже они сами себя называют программистами – просто для того, чтобы не объяснять пользователям каждый раз, в чем разница.
Но и среди тех, кто должен быть программистом, встречаются плохие парни. Это те, кому по должности положено вносить изменения в систему, а они занимаются лишь ее администрированием и эксплуатацией. Особенно часто такое положение дел встречается именно среди программистов 1С.
Например, программист занимается закрытием месяца, вместо или вместе с главбухом. Помогает рассчитывать зарплату, готовить отчетность, выполняет выгрузку на сайт, даже занимается автоматической установкой обновлений от вендора. По сути, это не программист, а продвинутый пользователь, который взял на себя самые сложные операции с системой, и этим кормится, не передавая своих знаний пользователям или настоящим администраторам системы.
Ключевое отличие плохого программиста – он не вносит в систему изменений, а только пользуется ей. Для него система, конечно, уже не черный ящик, как для большинства пользователей, но, не зная ее устройства изнутри, а тем более, не имея опыта ее модернизации, он остается пользователем, пусть и продвинутым. Он знает чуть больше, чем остальные пользователи, знаком с несколькими продвинутыми инструментами, в том числе, возможно, с консолью отчетов, но изменений в поведение, функциональность, производительность он не вносит.
Система остается неизменной, что с плохим программистом, что без него.
Менеджер
Менеджер – это человек, который руководит сложной системой. В нее включены люди, автоматизированная система, бизнес-процессы, отделы, система мотивации, цели, система управления, политика, отношения с вышестоящими, горизонтальные коммуникации и т.д.
Настоящий менеджер – это человек, который вносит в эту сложную систему изменения.
Менеджер постоянно мониторит состояние системы, видит (или чувствует), где возникают сбои, понимает причины неудовлетворительных результатов, и вносит соответствующие изменения. Может поменять систему мотивации, чтобы тратить меньше времени на ручное управление, заставив людей самостоятельно хотеть достигать результатов. Может внести изменения в автоматизированную систему (руками программистов), если она не дает нужных цифр или не помогает в управлении. Может поработать с целью системы, если она недостаточно четкая, или не соответствует реальности, не мотивирует и не двигает вперед. Может исправить систему управления, если она расходится с бизнес-процессами, и только мешает своей бюрократией. Может оптимизировать бизнес-процессы, если видит провалы, простои, потери или бессмысленную работу.
Менеджер – это программист бизнес-системы. Он не пишет код, но суть его работы точно такая же, просто методы «внесения изменений» различаются. Программисту нужно писать код, рисовать формы, ковыряться в системе компоновки данных. Менеджеру нужно разговаривать с людьми, создавать регламентирующие документы, ставить задачи, набирать или увольнять сотрудников. Методы другие, цель та же – внесение изменений.
Сегодня люди работают в одной бизнес-системе, с одними правилами, бизнес-процессами, целями, расстановкой мест в кабинете, схемой мотивации. Завтра, после запуска изменений, они попадают в другую систему – и это дело рук менеджера.
Плохой менеджер
Есть на свете и не настоящие менеджеры – те, которые занимаются только руководством вверенной системы. Они не вносят никаких изменений, не особо анализируют показатели, а просто руководят. Распределяют задачи, дают пинка, ставят сроки, ходят на совещания и т.д.
Плохие менеджеры знают несколько «кнопок» в системе, и более-менее умеют ими пользоваться. Но, правильнее сказать, не умеют, а имеют право. Например, могут увольнять и нанимать людей, заставлять выходить на работу в выходные, менять приоритет задач, немного повышать зарплату, выписывать небольшие премии, орать и материться. Никому, кроме плохого менеджера, эти инструменты не подвластны.
Применение этих инструментов не вносит изменений в систему, это вроде вынесенных наружу пользовательских настроек. Такими же настройками пользуется плохой программист. Это несколько рычажков и кнопок, иногда – ползунков, регулируя которые, можно немного менять поведение системы.
Значительных изменений с помощью этих инструментов совершить нельзя. Радикальные изменения кроятся внутри системы, но внутрь плохой менеджер не заглядывает. Он предпочитает имитировать изменения – например, затевая сокращение затрат или персонала. Со стороны это, действительно, выглядит как бурные изменения, но суть системы от этого не меняется.
Наиболее простой и доступный рычаг – это персонал. Потому наиболее популярным способом изменения среди плохих менеджеров считается расширение штата. Если вышестоящее начальство ругает плохого менеджера за недостаточные результаты, он обычно ссылается на персонал. В большинстве случаев – просит добавить штатных единиц.
Плохие менеджеры ничего не могут, не умеют делать с эффективностью, т.е. стоимостью результата, или КПД. Если у него в отделе 3 человека, работающих с определенным КПД, то единственный путь увеличения общего результата отдела – увеличение штата. КПД при этом либо не меняется, либо немного падает из-за проблем с управлением, но общая результативность системы повышается.
Хороший менеджер в такой ситуации может применить усилия, и изменить КПД, тем самым получив аналогичную результативность, но без изменений численности персонала. Плохой менеджер так не может, потому что КПД, или эффективность – это свойство системы, оно внутри, а не снаружи. Нет снаружи системы рычажка с названием «Эффективность», который можно было бы подкрутить.
Точно так же нет в настройках информационной системы рычажка «Производительность», который мог бы отрегулировать плохой программист. Некоторые, псевдорычажки, конечно, имеются, но кардинального влияния на производительность они не оказывают.
Итого
Итак, есть плохие и хорошие программисты, есть плохие и хорошие менеджеры.
На самом деле, оценки «плохой» и «хороший» не важны, их можно выкинуть, если начать называть вещи своими именами.
Если человек следит за состоянием информационной системы, ставит обновления, помогает закрыть месяц, ковыряется в настройках, и даже делает шринк базы, он – не программист. Можно называть его, например, «администратор базы данных». Тогда все становится на свои места, и появляется выбор.
Если бизнесу только и нужно, что поддержание состояния системы в текущем состоянии, то нужен не программист, а администратор. Если нужно кардинальное, или хотя бы заметное изменение в развитии, производительности, функциональности – нужен программист, который умеет вносить в систему изменения.
Если бизнесу только и нужно, что поддержание работы отдела, службы, функции или целой бизнес-единицы в текущем состоянии, то нужен не менеджер, а нянька, или администратор, или диспетчер, или пастух – выбирайте любое название. Если же нужны кардинальные, или хотя бы заметные изменения в какой-то части бизнес-системы, то нужен менеджер, который умеет вносить в эту систему изменения.
Проверить, программист у вас или администратор, легко – просто посмотрите код, который он написал (или попросите его самого показать этот код). Как бы глупо это не звучало, в моей практике несколько раз встречались ребята, называвшие себя программистами, при этом годами не писавшие код.
Проверить, менеджер у вас или диспетчер, тоже несложно – попросите его рассказать об изменениях, внесенных в бизнес-систему, и об их последствиях. Хотя, последствия должны быть очевидны, если вы – вышестоящий руководитель.
Резюме
Как видите, между менеджерами и программистами масса аналогий. И между хорошими, и между плохими.
В процентном соотношении хороший/плохой побеждают, конечно, программисты – просто потому, что их системы проще. Создать таблицу в базе данных, нарисовать для нее форму ввода, и наполнить цифрами – значительно проще, чем заставить сотрудника ежедневно вести план работы.
С менеджерами все значительно хуже – реальными изменениями среди них занимаются единицы процентов. И с этим надо что-то делать.
Какая разница между айтишником и программистом или ее нет?!
Программист — это специалист, который знает языки программирования и пишет при помощи них программы и приложения. С точки зрения IT-сферы, программист — узкая специализация, однако программисты также подвержены собственной градации в зависимости от того, что программируют: игры, приложения для компьютера, программы для мобильного телефона и другое.
Какая разница между айтишником и программистом
Айтишник не является какой-то конкретной специальностью, тако й как программист. Айтишником может называться любой специалист, связан ный с IT, например:
аналитик больших данных;
разработчи к программ или игр под разные операционные системы;
специалис т из сферы кибербезопасности;
системны й администрато р ;
системны й инжене р ;
архитекто р систем;
технически й писател ь ;
и другие специалисты.
Разница между айтишником и программистом у «нас» и у «них»
Пользователи более молодых поколений уже понимают разницу между айтишником и компьютерным мастером. Пользователи более старшего поколения эту грань «замыливают» и считают, что «программист» или «айтишник» легко может починить компьютер, причем может устранить программную и механическую поломку устройства.
если ты «программист», то ты не «айтишник», потому что ты принадлежишь касте «soft engineer» и работаешь в отделе «Software Engineering Depar tm ent»;
если ты занимаешься электронным оборудованием, то ты тоже не «айтишник», потому что ты работаешь в «Hardware Engineering Depar tm ent»;
Заключение
Если вы работаете или планируете работать в американской или просто продвинутой IT-компании в вашей стране, тогда будьте готовы к тому, что под термином «айтишник» будет скрываться конкретный специалист, который работает в IT-отделе. По функциональности он идентичен с «нашим» системным администратором.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Не путайте разработку ПО и программирование
Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!
Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.
Чтобы стать разработчиком, уметь программировать недостаточно.
Научить программировать можно любого — это легко. Писать простые программы, которые работают у конкретных людей на конкретных машинах, может почти кто угодно, но никто не гарантирует, что те же программы будут работать в других условиях.
Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.
Хотите еще аналогий? Пожалуйста:
Программирование в простейшем представлении — это передача компьютеру указаний на совершение некоторых действия с некоторыми входными данными для получения некоторого вывода.
Разработка же программного обеспечения — это проектирование, написание, тестирование и поддержка компьютерных программ с целью решения задач для множества пользователей; это создание надежных защищенных решений, которые выдержат испытание временем и справятся с некоторыми не известными заранее задачами, лежащими в области, близкой к очевидным исходным задачам.
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения, как эти решения ограничены и как они характеризуются с точки зрения конфиденциальности работы с данными и безопасности.
А если кто-то не понимает задачу, ему нельзя давать разрабатывать для нее решение.
Ориентированный на решения подход
«Умные решают проблемы — гении же их предотвращают».
— Альберт Эйнштейн
Для сложных задач приходится писать несколько программ. В некоторых случаях нужны программы, работающие параллельно, в других — запускающиеся последовательно. Иногда для решения задачи достаточно обучить пользователей.
Прежде чем писать код, разработчик задастся следующими вопросами:
Качество кода
В качественных программах код понятен и читается легко, их можно без труда расширять, они отлично взаимодействуют с другим ПО, а их поддержка не превращается в кошмар. Качество кода не должно становиться жертвой компромиссов; использование быстрых, но неаккуратных решений из-за поджимающего срока, излишнего волнения, взбудораженности, раздраженности и т. д. — неприемлемо.
Один из важнейших аспектов разработки ПО — это проектирование с нуля продукта, готового к расширению. Модификация приложений после их выпуска — факт, с которым нужно смириться. Пользователям будет нужно всё больше функционала, они захотят, чтобы пользоваться приложением было еще проще.
Компонент приложения обычно не очень полезен сам по себе. Пользу ПО начинает приносить, когда несколько компонентов взаимодействуют друг с другом, обмениваются данными и совместно работают на задачей представления данных и интерфейсов пользователям.
И с учетом этого нужно разрабатывать программы. Какие сообщения принимает ПО? Какие события отслеживает? Какие сообщения выдает? Как проходит проверка подлинности и авторизация при передаче данных?
Другой важный аспект написания хороших программ — это понятный код, а совсем не количество тестов или число в отчете о покрытии кода. Здесь всё просто. Подумайте: смогут ли другие прочитать код? Или — что еще лучше — сможете ли вы сами, написав код сегодня, понять его спустя несколько недель?
«В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий».
— Фил Карлтон
«У меня не было времени написать письмо короче».
— Блез Паскаль
С любой программой в какой-то момент что-то обязательно пойдет не так. Главный признак хорошего ПО — возможность легко исправить уже выпущенную в работу программу. Если программа во время работы выдает ошибку, об этом должно быть понятное сообщение, которое будет где-то централизованно записано — чтобы ошибки можно было отслеживать. При сообщении о новой ошибке у ответственного за ее исправление должна быть возможность провести отладку, в любой момент времени подключиться к системе и получить сведения о контексте выполнения, а также проверить ожидаемое поведение какого-либо компонента системы.
Рабочее окружение и тестирование
Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах. ПО должно работать на экранах различных размеров и ориентации, в условиях ограниченной памяти и малой вычислительной мощности.
Например, если ПО пишется для веб-браузера, оно должно работать на всех основных браузерах. При создании классического ПО оно в большинстве случаев должно работать на платформах Mac и Windows. Если создаваемое приложение зависит от получения данных, оно должно продолжать работать и в том случае, если подключение к данным медленное или даже некоторое время полностью отсутствует.
Чтобы написать компонент ПО, разработчики пытаются продумать все возможные сценарии, которые только можно себе представить, и планируют их проверку. Начинают с того, что называется сценарием по умолчанию (или «счастливой дорогой» — от англ. «happy path»), в котором не происходит ничего неожиданного, а все возможные на этом пути проблемы — что важно — документируются и для каждой планируется тест. Некоторые разработчики начинают с написания «тестовых случаев», которые имитируют такие сценарии. Затем они пишут функциональный код, который проходит эти тестовые случаи.
Разработчики должны понимать предъявляемые к ПО требования, а ведь те часто бывают неоднозначными и неполными. Мастерство разработчика проявляется не в том, как он напишет решение, а скорее в том, какое решение он посчитает необходимым.
Стоимость и эффективность
В большинстве случаев разработчик может решить задачу быстро. Если вам кажется, что нанимать на работу опытных программистов — затратно, задумайтесь: чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать. А это — меньшие затраты в долгосрочной перспективе.
Кроме того, учитывать следует и «стоимость работы» программы: всякое ПО потребляет ресурсы компьютера, а они не бесплатные. Разработчик напишет эффективную программу, которая не будет использовать ресурсы ПК без необходимости. Для этого он может применить, к примеру, кэширование часто используемых данных, — и это всего лишь один из, наверное, тысяч инструментов и способов, которые помогают повысить эффективность и скорость работы программы.
Возможно, программист-новичок и даст дешевое решение, но работа с этим решением может стоить вам и вашим клиентам намного больше, чем если бы вы сразу наняли опытного разработчика, который в первую очередь стремится найти эффективное решение.
Удобство использования
Хорошее ПО разрабатывается с учетом взаимодействия компьютера с пользователем (UX), и это довольно обширная тема, по которой проведено множество исследований и получено немало результатов. Чем больше выводов из этих исследований учтено, тем лучше будет ПО в использовании.
Позвольте я приведу пару примеров, чтобы вы могли прочувствовать, почему это важно:
Надежность, безопасность и защищенность
Пожалуй, самый важный аспект, который отличает разработчиков-профессионалов от программистов-любителей, заключается в том, что профессионалы знают, что они несут ответственность за создание безопасных защищенных решений.
Компонент ПО должен быть устойчив к «плохим» данным, неправильным состояниям и неверному взаимодействию. Добиться такой устойчивости ОЧЕНЬ сложно — именно поэтому мы постоянно читаем о том, как кто-то умер из-за ошибки ПО.
Пользователи будут вводить в ПО «плохие» и неправильные данные. Кто-то будет делать это намеренно — с целью взломать ПО и добраться до ресурсов, которые представляет данное ПО. Сотрудника, якобы ответственного за брешь в безопасности американского бюро кредитных историй Equifax, которой воспользовались злоумышленники, обвинили в том, что он не выполнил свою работу: он должен был обеспечить устойчивость к «плохим» и вредоносным данным во всём ПО, открыто публикуемом от имени компании.
Задача обеспечения безопасности связана не только с «плохими» и вредоносными данными, но и с обычными. Например, если пользователь забыл пароль, сколько раз он может попробовать его ввести? Блокировать ли его после исчерпания попыток ввода? Что, если кто-то умышленно пытается заблокировать пользователя? Давать ли пользователям возможность отправлять пароль по незашифрованному соединению? Что делать, если кто-то пытается войти в учетную запись из необычного места? Что предпринять, если возникает подозрение, что вход в систему осуществляется автоматически?
Как защитить своих пользователей от межсайтовых сценариев и подделки межсайтовых запросов, атак «злоумышленник посередине» и простого социального фишинга? Как разработать стратегию резервного функционирования в случае DDoS-атаки на сервера? Перечисленные вопросы — лишь малая толика из множества вопросов, которые нужно учитывать при проектировании.
Защищенные программы хранят конфиденциальные сведения не в виде обычного текста, а как односторонне зашифрованные данные со сложно взламываемыми алгоритмами. Это — резервная защита на случай взлома ПО и несанкционированного доступа к данным: хакерам достанутся зашифрованные данные, которые в большинстве случаев будут бесполезны.
Приложение может перейти в состояние ошибки, и его нужно будет исправить: даже в самых лучших программах возникают неожиданные проблемы. Если вы не учитываете это при планировании, вы — не профессиональный разработчик, а просто кодер с небезопасными программами.
Программные дефекты выявить сложно. Наш ум ограничен в своей способности прогнозировать и предотвращать известные дефекты. Поэтому разработчики ПО ценят хорошие инструменты, которые помогают писать правильный код и создавать безопасное ПО.
Используемые инструменты
Очевидно, что нам нужно больше инструментов и нужны инструменты лучше. В разработке ПО инструменты имеют большое значение, но их часто недооценивают.
Представьте на минутку, что для развертывания нам по-прежнему нужно было бы использовать FTP! Представьте отладку сети и выявление проблем производительности без браузерных инструментов разработчика! Представьте себе, как упадет эффективность написания JavaScript-кода, если не использовать ESLint и Prettier!
Если в JavaScript-разработке вы почему-то вынуждены оставить только один плагин для редактора кода, выбирайте ESLint.
Отличным дополнением будет всякий инструмент, который сокращает цикл обратной связи при написании кода. Мысль Брета Виктора об изобретении мгновенных визуальных представлений того, что мы создаем, открыла мне глаза. Использование и совершенствование инструментов — один из способов приблизиться к этому светлому будущему. Если вы еще не видели выступление Брета — обязательно посмотрите его.
Когда я нахожу отличный инструмент, я сожалею лишь о том, что не пользовался им раньше. Чем лучше инструмент, тем лучше с его помощью пишутся программы. Ищите, используйте и цените их, а если можете — и совершенствуйте.
Выбор языка — важен. Безопасность типа — важна. Лучшее, что произошло с языком JavaScript, — это TypeScript (и Flow). Статический анализ кода важнее, чем вам кажется. Если вы его не используете, вы, в сущности, становитесь уязвимы для возможных неизвестных проблем в будущем. Не пишите код без системы статического контроля типов. Если в выбранном языке нет статического контроля типов, нужно либо сменить язык, либо найти для него транскомпилятор: сегодня они уже достаточно умны, чтобы работать по комментариям в коде, и мне кажется, что для языков, не поддерживающих статический контроль типов, транскомпиляторы вскоре станут стандартным инструментом.
Становление разработчика ПО
Невозможно научиться разрабатывать ПО за пару месяцев, полгода и даже за год. На курсах программирования из вас не сделают разработчика. Я начал учиться 20 лет назад — и продолжаю учиться сегодня. С достаточной уверенностью я смог назвать себя опытным программистом только после десяти лет обучения, в течение которых мне пришлось спроектировать, создать и обеспечить поддержку приложений, используемых тысячами пользователей.
Разработка программного обеспечения — занятие не для всех, но каждый должен научиться решать собственные задачи с помощью компьютеров. Если вы можете научиться писать простые программы — сделайте это. Если можете научиться использовать несложные программные сервисы — сделайте это. Если можете научиться использовать ПО с открытым исходным кодом, в ваших руках окажутся мощные инструменты.
Задачи с течением времени меняются, поэтому меняется и разработка ПО. Задача этой профессии в будущем — дать возможность обычным людям использовать компьютеры, не тратя при этом на обучение полдюжины лет. Нужно дать пользователям простые и понятные инструменты, с помощью которых они будут самостоятельно решать простые задачи. А затем разработчики перейдут к созданию лучших инструментов, решению более масштабных известных задач и сделают все возможное, чтобы предотвратить появление неизвестных проблем.
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.