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

Если вы когда-нибудь просматривали должностные инструкции людей, занимающихся написанием кода, вы часто замечали несоответствие в том, как посты создаются в разных компаниях. Большую часть времени вы увидите название должности, в котором говорится, что компания ищет на работу «программиста», «разработчика» или «инженера». Чаще всего это не так: эти посты сделаны кем-то из HR, который часто не занимается какими-либо техническими аспектами работы — и на самом деле не думает о коннотации, которую дает каждое слово.

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

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

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

Программист

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

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

Однако это не означает, что программисты «некомпетентны». Иногда вам не нужно масштабируемое и чрезвычайно расширяемое решение — вам может понадобиться что-то просто работающее. Решение может перестать работать, может быть, через 6 месяцев, но решение, на создание которого ушло 10–20 минут и которое повысило производительность или сэкономило время на 6 месяцев, по-прежнему является бесценным достижением; и способность создавать это — впечатляющее умение.

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

Разработчик

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

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

SDLC: жизненный цикл разработки программного обеспечения

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

Так зачем вам нужен инженер, если вы можете просто нанять разработчика? Ответ прост, разработчику нужно последовательное техническое направление. Часто вам нужно ясно указать, чего вы хотите от программного обеспечения. Например, допустим, вы хотите создать веб-сайт для продажи DVD людям по всему миру. Они скажут вам «нет проблем», создайте приложение для реагирования, подключите / создайте какой-нибудь бэкэнд и получите веб-сайт, который позволяет людям щелкнуть нужный DVD, а затем отправить его им. Затем вы посмотрите на это в телефоне и спросите: «Почему это выглядит так». Ну, это потому, что вы не сказали, что хотите, чтобы он был мобильным.

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

Инженер

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

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

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

Разработчикам программного обеспечения нравится идея масштабируемости. Если вы когда-нибудь послушаете инженера-программиста, предлагающего идею, и спросите его: «А масштабируема ли она?» вы, скорее всего, увидите, как они на мгновение остановятся, а затем дадут вам несколько способов масштабирования и до какой степени. Им не нужно запоминать функции и методы языка, потому что они точно знают, как им нужно манипулировать структурой данных, с которой они работают, и они точно знают, как найти этот метод в документации по языку.

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

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

Я могу бесконечно говорить о широте и глубине талантов и обязанностей программиста, но я бы предпочел поговорить о недостатках работы с инженером-программистом, а именно: они дороги! Как они должны быть; это люди, которые могут воплощать идеи в бесконечно масштабируемую и расширяемую инфраструктуру. Разработка с инженером-программистом может быть намного медленнее, особенно в начале. Со временем инженер-программист может создать для вас такую ​​прочную техническую инфраструктуру, которая может увеличить скорость разработки до скоростей, которые шокируют даже акционеров.

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

Подведение итогов

Если оставить в стороне странный перевернутый треугольник, я надеюсь, что смог эффективно выразить свои мысли о различиях между этими ролями. Хотя HR может иметь вас в качестве кода работы, который не отражает ваших способностей, мы надеемся, что вы можете использовать этот треугольник, чтобы определить, где вы находитесь и где вы хотели бы быть. Я также надеюсь, что эта статья может дать хорошую перспективу, чтобы помочь любому, кто хочет найти кого-то, кто «напишет код». Определенно есть эффективные варианты использования для каждого слоя треугольника. Нам также действительно не нужно начинать стыдить людей, если они не знают разницы.