3 ms·

I have had a similar experience working with financial engineers and traders turned programmers (I am a programmer). They don't seem to value software the same

by kjdal2001 11y ago

I have had a similar experience working with financial engineers and traders turned programmers (I am a programmer). They don't seem to value software the same way as programmers. They seem to view their ideas as the most important aspect of their work, and writing software is only a way of expressing their ideas. The problem with this is that if you don't feel that their are non purely functional requirements worthy of your time, pretty soon your code base will be impossible to work on. Ive seen some bad stuff, including thousand line methods and production software whose source code is nowhere to be found. But the biggest forehead slap that I think I've encountered is when working on an automated trading system. I had just started working on the system when the original trader who had developed the algo quit. I saw him after work at a bar a couple weeks later and made some comment about how difficult it was to work on that codebase. He said that he made some of the trading logic purposefully difficult to understand so that it would be difficult for someone to read the code, get a job elsewhere, and replicate his work for a different company. Thats an insane way to write software. It assumes that all of the value is in the idea itself (and this algo was hardly rocket science by the way) rather than in a functional piece of software that is easy to modify and debug.

p4wnc6 11y ago
The other problem with it is that they don't appreciate that probably more than 90% of all code (including the code that touches their ideas) is for unsexy reporting purposes only. The domain expertise accounts for probably 1% to 5% of any business's code, and generally it's the easiest code to design, test, and change later on because it follows very tightly with well-worn practices in scientific computing. You might invent a great new trading strategy, but implementing it is still just the same old vector math and efficient algorithms stuff everyone's been doing for decades. But with the logging, reporting, parameter management, data provenance, data resource management, etc., etc., the actual creative design of the code matters much more, and a failure to make it extensible is way more expensive to fix down the road than tweaking some O(n^2) scientific algorithm. As an aside, this is one reason that I think algorithmic brain teasers are a really stupid thing for interviews or predicting positive business impact. With brainteasers, you are testing for rote memorization of a set of optimization techniques (data structure implementations) that maybe touches 1%-5% of your easiest-to-optimize-from-textbooks-or-wikipedia code, whereas the other 95% can almost always be assumed to rely on library implementations of these kinds of structures, and the high-level design of components, particularly optimizing it so that the addition or refactoring of features later is not expensive, is the dominant concern for adding actual business value. It's just another status game like everything else. Programming labor is asserted to be a commodity item to the company, so that managers can justify lower wage, worse working conditions, etc., for programmers than for business domain experts who are supposedly less easily replaced. But the reality is that a reasonably smart programmer can probably pick up the domain expertise to a high level, even to the same level as a Ph.D. researcher, in a short time, whereas for some reason because of some kind of status-based mental block or lack of curiosity, the domain experts seem incapable of picking up legitimate programming skills. When most of the code is for reporting, designing the reporting system is a huge priority. But when domain expertise carries political status, the importance of system design is often neglected in favor of campaigning for the supposed critical importance of the favored domain area.
- kjdal2001 11y ago
  Im not sure its a 90-10% split between the importance of infrastructure to business logic code in our case, but I don't think you necessarily need to make the distinction. Something that I've run into a few times is when an FE will come up with a proof of concept that needs to be built out into something more robust, and it takes longer to build it out than to come up with the concept in the first place. This is often because the original POC is more or less a direct translation from pure math, while the real application needs to be worked into a multithreaded program for performance reasons. That often comes with significant changes to the way the business logic gets executed. Software isn't merely a concrete implementation of pure mathematics. It is a logical system that bears some resemblance to math, but has a number of details (hierarchal memory model, network latency, etc...) that make it act quite differently. I think you can iterate on an idea faster and with fewer bugs if you treat it as a software problem from the get go rather than working on the idea and the software separately. For example, I once had a frustrating argument with an FE about why a program he was working on wasn't working correctly. He thought I didn't understand the normal distribution and how the tails never quite reach zero. What he didn't understand is that the computer doesn't care what a normal distribution is supposed to be, if you try to deal with numbers on the order of 1e-100 in a float in c++, it might as well be zero.

p4wnc6 11y ago

The other problem with it is that they don't appreciate that probably more than 90% of all code (including the code that touches their ideas) is for unsexy reporting purposes only. The domain expertise accounts for probably 1% to 5% of any business's code, and generally it's the easiest code to design, test, and change later on because it follows very tightly with well-worn practices in scientific computing. You might invent a great new trading strategy, but implementing it is still just the same old vector math and efficient algorithms stuff everyone's been doing for decades. But with the logging, reporting, parameter management, data provenance, data resource management, etc., etc., the actual creative design of the code matters much more, and a failure to make it extensible is way more expensive to fix down the road than tweaking some O(n^2) scientific algorithm. As an aside, this is one reason that I think algorithmic brain teasers are a really stupid thing for interviews or predicting positive business impact. With brainteasers, you are testing for rote memorization of a set of optimization techniques (data structure implementations) that maybe touches 1%-5% of your easiest-to-optimize-from-textbooks-or-wikipedia code, whereas the other 95% can almost always be assumed to rely on library implementations of these kinds of structures, and the high-level design of components, particularly optimizing it so that the addition or refactoring of features later is not expensive, is the dominant concern for adding actual business value. It's just another status game like everything else. Programming labor is asserted to be a commodity item to the company, so that managers can justify lower wage, worse working conditions, etc., for programmers than for business domain experts who are supposedly less easily replaced. But the reality is that a reasonably smart programmer can probably pick up the domain expertise to a high level, even to the same level as a Ph.D. researcher, in a short time, whereas for some reason because of some kind of status-based mental block or lack of curiosity, the domain experts seem incapable of picking up legitimate programming skills. When most of the code is for reporting, designing the reporting system is a huge priority. But when domain expertise carries political status, the importance of system design is often neglected in favor of campaigning for the supposed critical importance of the favored domain area.

kjdal2001 11y ago
Im not sure its a 90-10% split between the importance of infrastructure to business logic code in our case, but I don't think you necessarily need to make the distinction. Something that I've run into a few times is when an FE will come up with a proof of concept that needs to be built out into something more robust, and it takes longer to build it out than to come up with the concept in the first place. This is often because the original POC is more or less a direct translation from pure math, while the real application needs to be worked into a multithreaded program for performance reasons. That often comes with significant changes to the way the business logic gets executed. Software isn't merely a concrete implementation of pure mathematics. It is a logical system that bears some resemblance to math, but has a number of details (hierarchal memory model, network latency, etc...) that make it act quite differently. I think you can iterate on an idea faster and with fewer bugs if you treat it as a software problem from the get go rather than working on the idea and the software separately. For example, I once had a frustrating argument with an FE about why a program he was working on wasn't working correctly. He thought I didn't understand the normal distribution and how the tails never quite reach zero. What he didn't understand is that the computer doesn't care what a normal distribution is supposed to be, if you try to deal with numbers on the order of 1e-100 in a float in c++, it might as well be zero.