Wall Street Programming: The Perils of Tiny Companies

For developers in the earlier stages of their careers on Wall Street, working for small hedge funds may prove to be much more difficult than working for large investment banks.

When choosing to work for one company over another, there are many factors to consider. Some people put full weight on salary. Others tend to consider bonuses, benefits and vacation packages. As your career matures, however, you probably tend to put more emphasis on factors which may, at first, seem inconsequential. These include things such as the amount of time the company has been in business, your estimated commute time, and the size of the company in question.

On Wall Street, developers tend to have a strong preference as to the size of the companies they work for. A firm's size tends to influence intangible things such as the closeness of your interaction with colleagues, the amount of knowledge you need to take a project from start to finish, and even the fun factor of your job.

Some developers recommend working for larger companies, claiming they provide more stability, a well-defined path for advancement, and more opportunity to gain specialized knowledge. Others claim smaller companies allow them to gain expertise faster by immersing them in all aspects of the business. But following such advice without taking your experience level into account is a mistake. For developers in the earlier stages of their careers, working for small hedge funds may prove to be much more difficult than working for large investment banks.

Some small companies are founded entirely by business types, and IT is treated as an afterthought. If you find yourself in one of these places - especially if you're one of the first programmers to be hired - be warned: They are probably only now realizing their growth has been limited by their inability to leverage technology. The situation you're getting yourself into is one where they want the world from you as a developer, but at the same time they don't really know what they want.

A Little Knowledge

Up until you came aboard, their pinnacle of technology was the occasional Excel macro. This doesn't stop them from thinking that they know everything there is to know about programming, the IT world in general, and about the kind of work you do as a programmer specifically. This is where being a young, inexperienced developer can get you in trouble. Even some experienced developers (myself included) have had problems working in companies like these.

The clues begin to trickle in during your initial interview. "What we've been doing so far is writing our orders down on pieces of paper and handing them off to our operations officer...and this has worked great for us. Now we are trying to expand, and what we really need is a fully automated trading system."

This is fantastic, you think to yourself. I get to hack together an entire trading system from scratch with my own design, and when they expand and bring more programmers onboard, I will be master of the domain. I'll have built the entire thing by myself and I'll know it inside and out. This will look great on my résumé!

After the interview, you begin to realize that while all partners agree that they need "a trading system," you've been given seven different descriptions from five different people. One founder wants something simple to handle a few trades, but wants it yesterday. Another founder doesn't care how long it takes, as long as he gets a solid, fully extendible system.

But this doesn't worry you. You accept the position thinking that you'll build the best system out there. Everything will be great!

After a few weeks, one of the partners tells you that they have a better idea of what they want. He's spent the past weekend browsing the Internet for off-the-shelf trading systems and found a few that he likes. He loads up a browser and shows you a few of them. "We want all these features. It has to do this, and that, and keep all history for compliance purposes. How long will it take you to do this?"

Umm....

The Pivotal Point

"A YEAR! It'll take a year at least!" yells the pragmatic programmer inside your head. Everything in your experience tells you this sort of application takes at least a year to design and implement.

But how can you tell your new boss this thing will take a year to write? He'll laugh before throwing you out of the building. These guys think programming only requires a few keyboard clicks.

So you tell them you can have a bare-bones version of something useful within two months or so. It won't do much, but it will swallow up the basic trade types, do some simple validation and store the data in a database.

"But this off-the-shelf system I just showed you from this other company has all these other features. Can you do this as well?"

And you think to yourself: "This off-the-shelf system he just showed me had 30 programmers working on it for over two years, and it sells for $850,000 per license. He must be insane."

But he's not. He just lacks the fundamental understanding of what a single programmer is capable of. He has never worked with developers, and the company has never had an IT department before. The difference between working in a place like this and an investment bank is that here, aside from writing code, your job also includes teaching everyone what is possible and what isn't.

As you start the project, you realize just how much needs to be done before a single line of actual trading system code is written. A database has to be designed and implemented. A logging layer of some sort has to be written. A messaging layer has to be created, because while they may not realize it yet, if one trader submits a trade, all the others should be able to see it on their screens. All of this will take much more time than you think. And after it's all done, you won't have a single widget to display on-screen for the traders, because all of this is foundation work that they won't care about. The trading system in their minds has a screen with buttons they can press to do something.

And this is where you begin to lose them. You know you're doing good work. In fact, you may have surpassed all programming speed records to build this foundation layer. But they don't care. In time, they may begin to realize they had unrealistic expectations and that you, in fact, may be working very hard indeed. But it's too late. You failed to meet the original expectations - no matter how absurd they were. They didn't know at the time that the trading system they wanted would take more than a year to build. And you didn't tell them. Even if they know this now, you're no longer the golden boy they hired.

Maybe you should have taken that cushy cubicle gig at the large investment bank across the street. After all, it's had an IT department for years and its expectations are nowhere as high.

Andrey Butov is the author of the book "So You Want To Be A Wall Street Programmer?" He currently works as the lead developer of Antair Corporation, a software company based in New York City.

Comments on this article? Post your thoughts below.