Какой карьерный путь должен выбрать программист, который плохо разбирается в коде, но все же обладает аналитическим складом ума? [закрыто]

Я получил степень CS, немного исследовал и почти 2 года работал разработчиком Django в стартапе.

Из этого предыдущего опыта я узнал, что у меня есть следующие слабости :

  • У меня может быть плохая память / я чувствую себя немного некомфортно или не хочу изучать технические знания в области программирования, такие как версии, особенности языка, реализация и низкоуровневые детали.
  • Я могу быть медленным или могу изо всех сил пытаться доставить. Я склоняюсь к более продуманным / «надежным» (иногда) решениям.

И следующие сильные стороны :

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

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

  1. Какая среда (стартап, фриланс, исследовательская деятельность, крупные компании)/должность может больше подойти такому человеку?
  2. Нужно ли мне пройти обычный жизненный цикл разработчика, прежде чем я смогу занять позицию, которая не требует от меня только написания кода?

Дайте мне знать, если это слишком широко или не по теме.

Спасибо!

Я немного сбит с толку: вам нравится сводить процессы к их основным частям, но вы плохо справляетесь с низкоуровневыми деталями? Точно так же существуют и другие противоречия между вашими самоидентифицированными сильными и слабыми сторонами.
Менеджер программы?
@JonCuster Я имел в виду, что предпочитаю задачи более высокого уровня абстракции, такие как то, что должно выполнять программное обеспечение, и лучшие проектные решения для этого, а не детали реализации (низкий уровень).
Миру ИТ нужно больше таких людей, как вы. К сожалению, он этого не знает, потому что им в основном управляют эти «компьютерщики».
Я должен сказать вам кое-что, что может вас шокировать: возможно, у вас СДВГ. Я такой же, как и вы (по крайней мере, по вашему описанию), я думал, что я просто плохой кодер или глупый. Я часто что-то забывал и иногда забегал вперед. Оказалось, что у меня СДВГ, и я не просто «плохой программист». Вы действительно можете использовать это, чтобы стать лучше, с некоторой профессиональной помощью. Если вы ДЕЙСТВИТЕЛЬНО не хотите кодировать. Тогда я бы предложил руководителя группы или аналитика данных
Просто мысль: были ли какие-то предметы в вашей степени CS, в которых вы были особенно хороши? Это может дать вам некоторое представление о рабочих местах, для которых вы лучше всего подходите.
@ Зевс, это обнадеживает. Надеюсь, я смогу найти место, где я смогу использовать свои сильные стороны и развиваться дальше.
@bibleblade Я нахожу это довольно удивительным. Я просто думаю о том, как у меня могут быть глубокие мысли/идеи, но затем я пропускаю очевидные вещи, из-за чего чувствую себя глупо.
@E.Aigle Я могу вспомнить некоторые из первых этапов любого проекта, где мне приходилось придумывать решение (эти ранние этапы разработки программного обеспечения), проектирование базы данных, определение протокола в сетевых классах и т. д.
Вы должны проверить это. Есть несколько онлайн-тестов, чтобы понять, есть ли у вас СДВГ. Всю свою образовательную жизнь (?) я был очень хорош, но часто терпел неудачу, упуская из виду маленькие вещи, которые были действительно очевидны. Это приводит к таким вещам, как «это было бы пятеркой, если бы вы не забыли это и это, поэтому все, что я могу вам дать, это четверка». Это был один показатель. Я обнаружил это совсем недавно, когда рассказал другу о том, как я начинаю проект, становлюсь гиперсосредоточенным и через месяц или около того полностью теряю интерес и никогда больше к нему не прикасаюсь. Еще один признак, проверил это, и у меня появился СДВГ. Я лечусь, и это помогает

Ответы (3)

Я полагаю, что есть следующие позиции.

1. Инженер-испытатель

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

2. Менеджер по продукту

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

Специалист по данным.

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

Примечание: мой ответ не означает, что я считаю, что вы недостаточно хороши для кодирования. Отнюдь не. Я просто предполагаю, что вы правы в качестве основы для моего ответа.

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

Архитектор программного обеспечения

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

Системный инженер (или аналитик)

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

Анализ требований

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

Документация

Каждая хорошая система нуждается в пользовательской документации.

ОК (надзор)

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