| November 2006 |
|
| By Andrey Butov |
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 in their decision making process. As your career matures, however, you probably tend to put more weight on other factors which may, at first, seem inconsequential. These include things such as the amount of time the company has been in business, the 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 company they would work for. The size of the firm tends to influence intangible things such as the closeness of your interaction with your colleagues, the amount of knowledge you must possess in order 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. Other developers claim smaller companies allow one to gain expertise faster by immersing the employee 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 on Wall Street, 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 somewhat of an afterthought. If you find yourself in one of these places – especially if you're one of the first programmers in the business – be warned, they are probably only now realizing that their growth has been severely limited by their inability to leverage technology. The situation you are 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.
Up until you came aboard, their pinnacle of technology was the occasional Excel macro one of them managed to record by keystroke. 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 the 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, since I will 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, while another founder doesn’t care how long it takes, but wants 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 sits down with you and tells you that they have a better idea of what they want. He had spent the past weekend browsing for off-the-shelf trading systems on the internet 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....
And here's 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 that this sort of application takes at least a year to design and implement.
But how can you tell your new boss that this thing will take a year to write? He'll laugh at you before throwing you out of the building. These guys think that programming only requires a few keyboard clicks.
So you tell them you can have a bare-bones version of something useful within 2 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 2 years, and it sells for $850,000 per license. He must be insane."
But he's not insane. 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 such as this, and working in an investment bank, is that here, aside from writing code, your job also includes teaching these folks about what is possible and what isn’t.
As you start the project, you begin to 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 of sorts has to be designed and implemented, because while they may not realize it yet, if one trader submits a trade, all the other traders should be able to see this trade on their screens. All of this will take much more time than you think. And after all of this is done, you won't even have one single widget to display on screen for the traders, because all of this stuff 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 just surpassed all programming speed records known to man to build this foundation layer. But they don't care. In time, they may begin to realize that 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 a 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, they've had an IT department for years, and their expectations are no-where 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? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
