There are currently 17 threads in response to this question. None have taken the architectural angle, one that can be well introduced with the
Rule of Least Power which states
Use the least powerful language possible for a given problem. Prefer declarative languages over procedural. Now think for awhile about what that is actually saying...
Could it be that the heart of a secure system has little to do with process-oriented thought, and much to do with declarative policy?
In fact, in a well designed system, that should be the case. Unfortunately, there are bugs in all systems, so process-oriented thinking will always have a place. But in big picture terms - the 'heart' of a security stance - you really do need to be thinking in this way, particularly at design time, and generally also as an attacker.
Unfortunately, a declarative (policy-driven) architecture is essentially useless unless you ensure the system actually follows policy... for instance, by actually generating it largely from policy. This degree of rigor is rare in practice, but highly desirable in theory.
If you want to ensure your skills target big picture, are applicable to building things and not just tearing them to pieces (which in the security world often decays in to a range of puerile one-upmanship as visible at most prominent industry events), you could consider specializing in this area. In that case, you would do well to learn about declarative DSLs (domain-specific languages) and learn some of the more common ones. Then, practice generating things (documentation, functional code, application-level proxies, protocol test suites, policy compliance test suites) from those definitions... the generation could be done in any language, though using something simple with lots of libraries would be smart (possibly go, ruby, python, even perl or php).
Just thought it was worth contributing a different perspective here.