When you look at the development world from a security angle, you learn very quickly that you need to look deeper than a developer normally does. You need to understand how things occur, how the black magic works, and how things happen 'under the hood'. This makes you a better developer.
Studying in detail allows you to learn in an accelerated way. In a way, your brain does not learn well when it observes behaviour, but not cause. If you are only dealing with behaviour, you don't learn why something is happening, or the root causes of certain choices that were made in the app or the framework.
Security requires and encourages you to look deeper, to find ways to learn the technology, to understand how the technology works, and how to test it. I have a very strong testing background because I spend so much time trying to replicate things, to make things work, to connect A to B, and to manipulate data between A and B.
What interests me is that when I return to a development environment, I realize that I have a bigger bag of tricks at my disposal. I always find that I have greater breadth, and depth, of understanding of technology than a lot of developers.
I might not be the best developer at some algorithms, but I often have a better toolkit and a more creative way of solving problems than more intelligent and more creative developers. The nature of their work means that their frames of reference are narrower.
Referencing is important in programming because often, once you know something is possible, you can easily carry out the task. But when you don't know if something is possible, you must consider how you investigate the possibilities, how long your research will take, and how long it might be before you know if something will succeed or not. Whereas, if you know something is possible, you know that it is X hours away and you can see its evolution, or if it is a lost cause.
Having those references makes a big difference because when you look at a problem it is important to know which rabbit holes you can follow and which ways will create good and sound solutions and which ones don't. This is especially important when we talk about testing the app: there tends to be a lot of interesting lateral thinking and creative thinking required to come up with innovative solutions to test specific things.
My argument is that when you do application security, you become a better developer. Your toolkit expands, your mind opens, and you learn a lot. In the last few months alone, I had to learn and review different languages and frameworks such as Golang, Spark, Camel, Objective C, Swift and OpenIDM.
After a while learning new systems becomes easier, and the ability to make connections makes you a better developer because you are more skilled at observing concepts and technologies.
(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)
