Инженерные задачи
Программистов много, а инженеров мало. Многие приравнивают программистов и инженеров, но я не согласен с таким упрощением.
Чтобы понять разницу между программистом и инженером надо посмотреть на задачи, которые решают те и другие.
Для программиста стандартная задача сводится к "разработай интерфейс", "сделай компонент", "настрой роутинг", "оптимизируй запрос". С позиции сложности такие задачи вполне могут вызвать взрыв мозга, поэтому однозначно сказать, что все задачи программиста любой может решить не напрягаясь - неправильно.
Можно спорить, что компонент, написанный джуном, будет архитектурно плох, тормозить или еще как-то не так работать, а вот сеньор сделает красиво и безупречно. На практике всем пофиг. Код - есть код. А пользователь давно приучен "программирование - это сложно, ошибки неизбежны".
Сложность у программиста обычно комбинаторного характера - слишком много частных случаев, которые нужно комплексирвоать между собой, трудно найти общее решение, нужно запоминать много частных случаев и т.д.
Для инженера задачи выглядят совсем иначе: "написать утилиту определяющую износ жесткого диска", "разработать библиотеку для анализа таймсириес данных, для поиска корневой причины", "сделать модуль проактивного мониторинга", "разработать модуль коммутации для IP-телефонии" и т.д.
Существенным отличием является то, что поставленная перед инженером задача не имеет готового решения или алгоритма действий. Высокая степень неизвестного (обычно около 50%) , для написания кода требуется получить решение в аналитическом виде, а потом закодировать. На этапе кодирования можно разделить задачу на подзадачи и отдать решение программистам.
Когда я работал над системами мониторинга, большую часть времени я занимался тем, что искал модели корреляции между разрозненными событиями, учился отличать "информационный шум", вырабатывал метрики оптимального потребления ресурсов, решал архитектурные вопрос на уровне системы и т.д.
После имплементации решения занимался тюнингом и проверкой корректности, для этого генерировать разные синтетические наборы данных, чтобы проверить гипотезы и удостовериться в корректности работы разработанной системы. И делать много другой аналитической работы.
Большинство инженерных задач лежат в области работы с данными, моделями, архитектурой, декомпозицией, а не написанием кода. Инженеры используют ЯП ровно для того ради чего они создавались - закодировать описанное решение.
Сейчас многие работы раскиданы по специалистам разного профиля - data-инженеры, QA, кодеры, архитекторы. Но провести абсолютно ровные границы между обязанностями невозможно, поэтому конечное разбиение будет сильно разным от компании к компании.
Мы не можем взять человека на должность программиста, давать ему только задачи на кодирование и надеяться, что он после некоторого количества задач вдруг научится решать инженерные задачи. Это принципиально разные вещи, поэтому инженерное образование и образование программиста нужно рассматривать отдельно.
SOER | PRO | Boosty
Программистов много, а инженеров мало. Многие приравнивают программистов и инженеров, но я не согласен с таким упрощением.
Чтобы понять разницу между программистом и инженером надо посмотреть на задачи, которые решают те и другие.
Для программиста стандартная задача сводится к "разработай интерфейс", "сделай компонент", "настрой роутинг", "оптимизируй запрос". С позиции сложности такие задачи вполне могут вызвать взрыв мозга, поэтому однозначно сказать, что все задачи программиста любой может решить не напрягаясь - неправильно.
Можно спорить, что компонент, написанный джуном, будет архитектурно плох, тормозить или еще как-то не так работать, а вот сеньор сделает красиво и безупречно. На практике всем пофиг. Код - есть код. А пользователь давно приучен "программирование - это сложно, ошибки неизбежны".
Сложность у программиста обычно комбинаторного характера - слишком много частных случаев, которые нужно комплексирвоать между собой, трудно найти общее решение, нужно запоминать много частных случаев и т.д.
Для инженера задачи выглядят совсем иначе: "написать утилиту определяющую износ жесткого диска", "разработать библиотеку для анализа таймсириес данных, для поиска корневой причины", "сделать модуль проактивного мониторинга", "разработать модуль коммутации для IP-телефонии" и т.д.
Существенным отличием является то, что поставленная перед инженером задача не имеет готового решения или алгоритма действий. Высокая степень неизвестного (обычно около 50%) , для написания кода требуется получить решение в аналитическом виде, а потом закодировать. На этапе кодирования можно разделить задачу на подзадачи и отдать решение программистам.
Когда я работал над системами мониторинга, большую часть времени я занимался тем, что искал модели корреляции между разрозненными событиями, учился отличать "информационный шум", вырабатывал метрики оптимального потребления ресурсов, решал архитектурные вопрос на уровне системы и т.д.
После имплементации решения занимался тюнингом и проверкой корректности, для этого генерировать разные синтетические наборы данных, чтобы проверить гипотезы и удостовериться в корректности работы разработанной системы. И делать много другой аналитической работы.
Большинство инженерных задач лежат в области работы с данными, моделями, архитектурой, декомпозицией, а не написанием кода. Инженеры используют ЯП ровно для того ради чего они создавались - закодировать описанное решение.
Сейчас многие работы раскиданы по специалистам разного профиля - data-инженеры, QA, кодеры, архитекторы. Но провести абсолютно ровные границы между обязанностями невозможно, поэтому конечное разбиение будет сильно разным от компании к компании.
Мы не можем взять человека на должность программиста, давать ему только задачи на кодирование и надеяться, что он после некоторого количества задач вдруг научится решать инженерные задачи. Это принципиально разные вещи, поэтому инженерное образование и образование программиста нужно рассматривать отдельно.
SOER | PRO | Boosty