This is a huge load of bullshit. 99% of the "banking programmers" are some of the worst coders in the world. A vast majority of them just babysit a Bloomberg terminal, barely understanding the supposed math they use all day. Others just babysit an Excel spreadsheet, or worse, develop whole applications in Excel then try to get a real programmer to "build it". The lower echelons are even worse and just make shitty C# and Java web apps that are huge wastes of money.
The supposed "C++ optimizer" guys are some of the worst. They're the guys who go off and make algorithms they think are blazing fast, and sure for one tiny little use maybe, but then when you actually see the code it's a huge convolute mess for nothing. It's usually riddled with bugs, not in source control (Clearcase), only if it is only because the Compliance Dept. told them to, and they refuse to share because they're too damn competitive.
I've even seen projects by some of the top guys that were built by hand. No make file because the dude didn't trust make.
Don't even get me started about these jackasses that think their huge monolithic shitpiles of Java code are somehow superior, yet the only reason their code can actually run is because some bank sunk millions (and maybe billions) into infrastructure just to run that crap even moderately fast. I had one project where the damn process used so much ram per request they had to go buy an Azul box just to make it run even at 2 req/sec. That was their "cream of the crop" coders.
Finally, they constantly do this thing where they say, "Oh man my code is so awesome it's written in C++ and is so fast. No you can't see it. Oh but I make $500k a year!" They equate how awesome their code is by how much they make, but rarely have any idea of what other people's code is like.
Honey, if all you can make from your corrupt financial masters is $500k while they make billions and trillions then you're not a very good coder. And if I can't see your damn code, then you're a damn liar.
Take it from a guy who thought he'd run into some quality in the finance world. There is none, they just have so much money they can't help but make tons of it.
I've worked at both a bank and an HFT firm, so I think I have some perspective you might find interesting.
To make a broad generalization from my experience, "Traders" at a bank are mostly non-technical Excel junkies. It seems like in your experience they also went by the title "Programmer", which I agree is a gross misnomer. Besides that, I think the most important thing to realize is that at banks, non-technical people run the show. The technical people are at the disposal of their non-technical overlords, and thus they spend their every waking hour implementing terrible specs like "do {some incredibly specific task}, and make it fast." Even worse, they are far down on the ladder of responsibility; a "banking programmer" has no feel for the big picture. This all culminates in what you describe: highly specialized/one-off/non-generic piece-of-shit code. But whatever, their MBA overlords don't care about the means, just the ends.
To make another broad generalization, "Traders" at an HFT firm are predominantly go-getter CS majors from top schools. Thus, if they have an idea, they implement it themselves. Any delegation of duty is done with strict specs, and bugs or terrible design in the finished product will get noticed. Incentives abound for writing good code: scalability/genericness is rewarded (have something that averages $1k trading symbol XYZ every day? You're a millionaire if it generalizes to many symbols), speed is rewarded (just the nature of the game), and bugs should lose you money (otherwise they are just unknowingly optimized around).
tldr: banking is like you describe, but there is plenty of quality in the HFT world.
If you look at the serious pieces of infra inside the front offices for pricing and risk however, there are some smart people that have done some good software.
Quite often however those projects are degraded as stewardship of these projects is inconsistent, and long tenure is not always there, so you don't get continuity in terms of engineering talent.
Frequently this is due to the fact that IT is treated as a cost rather than an enabler of profit, and salary increases do not keep pace with the market worth of fulltime employees - leading to job hopping.
For the non-managerial part of the financial developer's career, it is often a better trade to be an independent contractor on a good daily rate with tax breaks, than take the chance upon fluctuating market conditions and bonuses.
As software developer bonuses are not tied to material outcomes like the front office but are generally more qualitatively judged, this leads to insecurity.
The developers that hang around for many years and end up being the stewards of these good systems that slowly rot, are quite often the ones that are incurious about contracting or moving, or have no better options.
We are routinely picking the top few percentile from the best colleges - the banks don't lack talent - but what they lack is management with good engineering discipline, and good projects sometimes turn bad.
For the professional developer who is actually skilled, this provides unbounded opportunities - it is often easier to make a really big impact with relatively little effort by pruning an overrun garden than rebuilding a very large amount of function points from scratch.
Finally, it is incorrect to say that version control systems are not used. Simply not the case.
It is rare these days in my experience - it creates an appropriate separation of concerns to have the management alignment distinct (that can be interpreted to be a Sarbannes Oxley requirement.)
There can be budgeting for specific desk profits in the relative bonus pools decided in IT, but bonus makes up a smaller percentage of developer total comp generally unless you are approaching management.
If you are desk dev and hack Excel and Access for the front office that can help your case in regards bonuses, but this isn't true software development of course.
I am speaking of my last 15 years in London working in derivatives/front office IT, and interviewing for many jobs in front office IT. It is very exceptional to find banks that will organise IT to report into the front office structure - this doesn't occur, and I almost never hear of such a thing when I see job specs.
It's not all of IT, but it's not unusual for quant dev type roles to report to the front-office (either singly or as part of a dual-reporting structure). The reporting doesn't have to be direct for dev bonuses to be tied to PnL either, what I've seen happen at some places is that a certain percentage of the desk bonus pool is assigned to the development team and the development team management than decide how to split that pool among the developers.
Go to efinancialcareers and search for "PnL bonus" if you want to see some examples of job specs mentioning it.
It looks like python, so the semi-colons are unnecessary.
If you want to rid yourself of datetime for whatever reason, implement it as a list, returning name_of_day[x], so that you can start the week on a Sunday(=0) easily if you want to.
Python ships with a standard datetime class which is powerful enough to represent time, and there is a ubiquitous module, dateutil, which extends it to do nearly anything people need to do with dates regularly.
Additionally, one would normally use an array of names and index it:
I have a better one. Project manager replaced enums with strings and instead of the switch statement he put a long list of if-s (without the else-s, too), and a lot of obfuscated crap between the braces.. Guess who had to sort out that mess?
Also, the motivation for that horror was related to how those string parameters were visible in intellisense (because they were made static members in a class). Don't even ask.
It sounds like you had a bad experience at a single team in a single bank and are trying to extrapolate those experience to a sector that employs hundreds of thousands of developers.
Yes, there are plenty of shitty programmers at investment bank, there are also lots of top-tier ones.
And yes how much money your code makes is more important than how well factored it is. It doesn't matter if your code is the most beautiful code in the world if it doesn't work, shitty code that gets the job done is better. Regardless of whether you're working in finance or on a web app.
When you're doing performance optimization, C++ is basically C. You restrict yourself to an almost C subset and maybe end up doing some clever stuff with templates.
Realized this would be a much larger effort than a single HN reply or a single blog post would justify, so I am starting a blog series on this. First post: http://news.ycombinator.com/item?id=2829116
Maybe it's different in London compared to NY. There's plenty of decent makers in Finance in London. There's people who use all the best practice techniques in software development. People who wrote code you use every day.
Funny, I didn't use open source at all in that post. I said, they don't show it to anyone and I meant even other employees at the bank. Some of those dudes guarded their secret sauce like crazy, even when I was asked to help them improve it. When I finally got in to see it, it was a nasty horrible mess.
I've never worked at anything but a company with "closed-source" code, but all engineers within the company had access to all product code via SVN. From reading other comments, it seems the quants are paid relative to their code's performance in the market, and this culture of not sharing code is probably understandable under those circumstances.
In other words, Shaw doesn't seem to be recognizing the competitive nature of the HFT business, even within a given organization, and is more accustomed to a team effort.
I don't know, to cultivate a culture of absolutely not sharing sounds like bad business, to me. Sure it's good for each individual, but aren't you severely limiting the organization's product (let's call HFT software a product for lack of a better word) quality and competitiveness?
I'm not talking about whether or not I'd mind working in such a culture. I'm talking about how ridiculously stupid it is to encourage such a culture.
Isn't there some team of highly motivated, cooperative good engineers who are beating all the solo pilots, right now, somewhere?
I'm sure the same's true in any industry where code contains tradable trade secrets, keeping code on a need-to-know basis makes sense. For example I imagine not everyone at Google has access to the page ranking score algorithm, because a rogue employee could easily sell that information for millions of dollars.
As opposed to no-one having access, a restricted access is a much better idea.
I was not aware that HFT algorithms are that 'personal', now that article makes even less sense! What seems extremely blasphemous is that this person outrightly denies the importance of creativity and innovation that goes into Product designing at (pardon my ignorance, and bias for real tech firms), say, Google.
What I do get from the port is this: HFT people are extremely smart - extremely closed circle. They know algorithms and optimization. Speed is of utmost importance. They know more ways to optimize than I will ever know (Actually I don't even need to. I can very well work on something more significant). And they earn a lot (Well I will earn enough for my satisfaction, so I don't give a flying SegFault).
Given this type of code directly makes or loses money, it's effectiveness for it's intended purpose is already directly measured.
Whether it's "good code" or not from a technical perspective, if one guys pile of crap code works the market 10x better than the other guys, who has "better code"?
I understand that, but not everyone runs around claiming they're awesome seeking validation from Zed Shaw. There are lots of great programmers in every field that involves a computer. There are bad ones too, just like in open-source. To claim that there are no good programmers in any given field is nonsense.
Flippancy aside I'd say if good coders aren't reviewing your code you have a good chance of being a shitty programmer. Open source is a great way to achieve that but certainly code review is prevalent in other places.
The supposed "C++ optimizer" guys are some of the worst. They're the guys who go off and make algorithms they think are blazing fast, and sure for one tiny little use maybe, but then when you actually see the code it's a huge convolute mess for nothing. It's usually riddled with bugs, not in source control (Clearcase), only if it is only because the Compliance Dept. told them to, and they refuse to share because they're too damn competitive.
I've even seen projects by some of the top guys that were built by hand. No make file because the dude didn't trust make.
Don't even get me started about these jackasses that think their huge monolithic shitpiles of Java code are somehow superior, yet the only reason their code can actually run is because some bank sunk millions (and maybe billions) into infrastructure just to run that crap even moderately fast. I had one project where the damn process used so much ram per request they had to go buy an Azul box just to make it run even at 2 req/sec. That was their "cream of the crop" coders.
Finally, they constantly do this thing where they say, "Oh man my code is so awesome it's written in C++ and is so fast. No you can't see it. Oh but I make $500k a year!" They equate how awesome their code is by how much they make, but rarely have any idea of what other people's code is like.
Honey, if all you can make from your corrupt financial masters is $500k while they make billions and trillions then you're not a very good coder. And if I can't see your damn code, then you're a damn liar.
Take it from a guy who thought he'd run into some quality in the finance world. There is none, they just have so much money they can't help but make tons of it.