4 ms·

I don’t know if it is specific to banks but there is a common pattern I have seen among internal developers: not only a complete lack of curiosity to understand

by cm2187 7y ago

I don’t know if it is specific to banks but there is a common pattern I have seen among internal developers: not only a complete lack of curiosity to understand finance, the underlying business, but an active resistance to any attempt to explain them. They want the numbers to be data, and don’t want to have to know anything about this data, and be told exactly what to do with it and they will code it up. I am sure there are exceptions, but my point is if you talk to someone who understand what is going on in a bank, you would be extremely lucky that this person also can code. This is slowly changing as I see an increasing number of junior bankers who are also interested in picking up coding skills. They won’t be developers per se but will certainly become technically literate interlocutors. But it will take some time.

ownagefool 7y ago
As a counter, I've contracted for a bank and big business generally, and they are activly resistent to allowing you to interface with the business in any meaningful way. There's several reasons for this, but at the end of the day people don't take kindly for your making them redundent and there's a lot of fiefdoms going around. Why would any developer who wants a deeper look stick around?
urban_winter 7y ago
That is profoundly untrue in my experience (13 years of working as a Dev manager at UBS and BofAML). The knowledge of how the business really works sits largely with the long-served IT and Operations staff. This is certainly the case in the back office (clearing and settlement) and in the regulatory space. I can't speak so much for the front office, but it seemed that the developers with successful careers were those who understood the business and therefore could talk to traders and desk heads in their own language (far more successful than the developers who were actually any good at producing maintainable software, but that's a different rant). There are lots of things wrong with technology in large banks but the business knowledge of developers is pretty low on the list. I left banking a few months ago, so I am no apologist for the sector.
__MatrixMan__ 7y ago
I've seen that pattern too, and perhaps I'm a little guilty of it. But if you say: > we want to encrypt this field with your public key before sending it to you and they respond: > yeah, we can handle that and then contracts with deadlines and penalties are signed... Wouldn't you expect there to be somebody on the other end that is willing/capable to generate a GPG keypair? At what point is it worth holding their hand through the technical bits, and at which point would it be better to replace them?

by cm2187 7y ago

ownagefool 7y ago

As a counter, I've contracted for a bank and big business generally, and they are activly resistent to allowing you to interface with the business in any meaningful way. There's several reasons for this, but at the end of the day people don't take kindly for your making them redundent and there's a lot of fiefdoms going around. Why would any developer who wants a deeper look stick around?

urban_winter 7y ago

That is profoundly untrue in my experience (13 years of working as a Dev manager at UBS and BofAML). The knowledge of how the business really works sits largely with the long-served IT and Operations staff. This is certainly the case in the back office (clearing and settlement) and in the regulatory space. I can't speak so much for the front office, but it seemed that the developers with successful careers were those who understood the business and therefore could talk to traders and desk heads in their own language (far more successful than the developers who were actually any good at producing maintainable software, but that's a different rant). There are lots of things wrong with technology in large banks but the business knowledge of developers is pretty low on the list. I left banking a few months ago, so I am no apologist for the sector.

__MatrixMan__ 7y ago

I've seen that pattern too, and perhaps I'm a little guilty of it. But if you say: > we want to encrypt this field with your public key before sending it to you and they respond: > yeah, we can handle that and then contracts with deadlines and penalties are signed... Wouldn't you expect there to be somebody on the other end that is willing/capable to generate a GPG keypair? At what point is it worth holding their hand through the technical bits, and at which point would it be better to replace them?