Я получил степень CS, немного исследовал и почти 2 года работал разработчиком Django в стартапе.
Из этого предыдущего опыта я узнал, что у меня есть следующие слабости :
И следующие сильные стороны :
Думаю, я не единственный. Должны быть миллионы «некомпьютерных» программистов, которые тратят свою жизнь на кодирование от посредственного до приличного, так и не догоняя других программистов, которые просто лучше подготовлены для кодирования (не говоря о гениях, просто о лучших кодерах). Так,
Дайте мне знать, если это слишком широко или не по теме.
Спасибо!
Я полагаю, что есть следующие позиции.
1. Инженер-испытатель
Я не говорю о разработчиках программного обеспечения в тестировании, которые разрабатывают тестовое программное обеспечение или автоматизированные тестовые наборы. Я говорю об инженерах-испытателях, которые строго пишут и выполняют планы тестирования, не разрабатывая и не поддерживая никаких тестовых программ.
2. Менеджер по продукту
Если у вас есть высокий уровень понимания продуктов и рабочих процессов, и вы можете эффективно общаться как с внешними клиентами, так и с командами разработчиков программного обеспечения, чтобы определить требования, проекты и реализации продуктов, тогда эта должность может вам подойти. .
Специалист по данным.
Ваши сильные стороны очень хорошо подходят для роли специалиста по обработке и анализу данных. Ученые по данным все еще кодируют, но требования к их кодированию не высоки, скорее, они достаточно хороши, чтобы выполнить задачу на уровне.
Примечание: мой ответ не означает, что я считаю, что вы недостаточно хороши для кодирования. Отнюдь не. Я просто предполагаю, что вы правы в качестве основы для моего ответа.
Архитектор программного обеспечения
Человек, который определяет программное обеспечение в более широком масштабе — что это за модули, как они будут взаимодействовать друг с другом и так далее.
Системный инженер (или аналитик)
Человек, который просматривает программное и аппаратное обеспечение, определяя, что будет делать система в целом, а не углубляясь в детальное кодирование.
Анализ требований
Превращение первоначального запроса от клиента в надлежащий формальный набор требований. Затем это можно разбить на требования подсистемы. Это также порождает набор тестовых процедур, чтобы показать, что требования выполняются.
Документация
Каждая хорошая система нуждается в пользовательской документации.
ОК (надзор)
Под этим я подразумеваю человека, который проверяет, что все сделано правильно, в отличие от инженера-испытателя. К сожалению, они оба называются «QA». Вы должны быть методичными и быть готовыми просмотреть проектную документацию, выявляя неправильные вещи.
Джон Кастер
Джим Клэй
Сэмюэл АР
Зевс
библейский клинок
Э.Эйгл
Сэмюэл АР
Сэмюэл АР
Сэмюэл АР
библейский клинок