Есть ли менее технически сложная работа для инженера-программиста? [закрыто]

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

Я хотел бы спросить, есть ли другие менее технически сложные должности для кого-то с приличным пониманием интерфейса/сервера/SDLC, который также является хорошим коммуникатором?

уточнить; Я не против обучения. Я хочу использовать свои технические навыки и продолжать расширять свои знания. Но мне любопытно, есть ли, возможно, больше совместных должностей, где объем необходимых знаний относительно определен, вместо того, чтобы сейчас я провожу весь день каждый день, пытаясь изучить и применить новые технологии/концепции.

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

Ответы (3)

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

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

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

На самом деле я много слышал о COBOL, и я думаю, что кривая обучения, чтобы узнать это с нуля, будет довольно крутой. Хотя вы правы, все, что использует COBOL, довольно устроено по-своему, ха.

Также могут быть компании, где не нужно постоянно учиться.

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

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

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