Помимо знания 100500 технологий и подходов, которые конечно же тоже важны, есть еще один пункт, который прям необходим, и про который почему-то редко говорят.
Это способность построить в голове модель того, что происходит в создаваемом софте. И помнить ее долго хотя бы в общих чертах.
Вам может быть насрать на выгоды бизнеса (привет, @fillpackart :) ), или вы наоборот упоролись и живете только работой. Вы можете знать или не знать детали реализации gc в jvm и вертеть
Это все неважно, если вы не можете натренировать свою серую нейросеть так, чтобы держать в голове систему в целом. То, что относится к той части софта, за которую вы отвечаете.
Вы можете сами преобразовывать бессмысленное бормотание заказчика в четкую модель или же натравить на это бизнес-аналитика или пиэма, который выдаст документацию.
Но все равно, пока в голове не "щелкнет", не уляжется понимание происходящего в целом, вы будете делать тупейшие ошибки и недоработки. Молча допиливать явную чушь из тз, потому что не поймете, что это чушь. Будете неправильно выделять сущности и абстракции в коде, потому что код - это и есть модель бизнес-процессов, записанная долбанутым компьютерным языком.
Различные подходы типа DDD помогают, но лишь отчасти, потому что без понимания системы, без заданных вовремя вопросов, точно также будут ошибочно выделены bounded contexts и сущности. Потом это придется переделывать, и в системе при этом останется дофига лишних зависимостей и странноватых названий.
Крутые шахматисты могут держать в голове десяток партий на сеансе одновременной игры.
Крутые синьорные программисты отсекут бредовую фичу еще на этапе предварительного обсуждения, задав пару правильных вопросов.
Способных держать модель в голове чаще делают тимлидами, даже если они хуже перформят в строчках кода в секунду.
Еще неплохо бы уметь объяснять происходящее другим: объясняя, лучше запоминаешь и выкристаллизовываешь суть.