Last month I finished working at DRW Trading after nearly 4 years there. DRW has a fantastic technical organization on both the Software Engineering (SE) and IT Operations side, from the leaders (CTO Lyle Hayhurst, COO Seth Thomson and Director of SE Derek Groothuis) down. In many ways I expect this will be one of the best jobs I ever have – my technical colleagues were fantastic (especially Jay Fields, my right hand man for the last 18 months), my team had complete management and implementation control of our projects, I didn’t have to deal with much in the way of politics at all, and yes, the pay was good!
So the obvious question is why leave? As usual in such cases it’s not a simple answer. I’m going to go on something of a tangent before I give a couple of reasons.
With software development jobs where the goal is producing a product, that product is not an end in itself for the customer [1]. The product is a tool that will be used by the customer to do something. Compare this with doctors or actors – in the first making people healthier is the sole end goal, in the second entertaining is the sole end goal [2].
(Good) software developers have some understanding about what the thing they’re making is going to be used for. Compare this time with structural engineers responsible for building a bridge – they know they’re building a bridge but they’ve no idea what the final destination is of the people traveling over that bridge.
I think most software development roles in some ways resemble being a lawyer (hear me out!) As a lawyer the principle aim, in the context of litigation at least, is to win the case, but you’re always doing so for a particular type of case. You might be a criminal lawyer, patent attorney, etc.
Most lawyers I know are interested not just in the practice of law itself, but also to some extent in their more specific field. A non-profit housing lawyer (to use an example very close to me, thank you Sara) might not just be interested in winning cases, but in helping less privileged tenants in having a fair voice against landlords with far more means.
And so we come back to software. There’s no doubt that as ‘software people’ we are interested in making stuff. We all have parts of ‘making’ we’re more interested in, whether it be the technical design, the project process, the user interface, etc. But I would describe these all as second-order goals.
The first-order goal is the actual thing that will be useful to the customer. Again, I’ll say what I did above – good developers have an understanding about the first-order goal (in other words they have what Martin Fowler calls Customer Affinity.) Excellent developers for the long term have not just an understanding, but an active interest, of the first-order goal (otherwise known in our field as the domain.)
For most of the time I was at DRW the second-order problems I was solving were fascinating to me. With a very small team we built and maintained a large, solid, well-appreciated application. Furthermore I was making good inroads into understanding the domain (commodities trading). Once we’d solved a lot of the second-order problems though what remained was understanding, and appreciating, the domain.
The problem was that I don’t find trading very interesting. To me it’s ‘just’ math and moving money around. Trading in some ways has a lot in common with gambling : assessing financial risk and making positions (‘bets’) based on what you currently see in the slice of the world around you. I’ve never been particularly interested in gambling and I think the 2 are linked. I know many excellent developers who are truly interested in trading (Jay being one of them) – I don’t have a problem with them, I just don’t share their enthusiasm for this particular domain.
Further though, I think to be an excellent developer in the long term not only must you appreciate / have passion for what the users of the software want to do with the software, you also need to have empathy for the users themselves. Martin says this at the end of the first paragraph in the link above : “[Customer Affinity] is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.” (emphasis mine).
This leads to a second reason I left DRW – I didn’t empathize with many of the traders I worked with. Note that I’m absolutely not saying I thought they were wrong, they’re certainly far more financially successful than I am at least, what I’m saying is that my approach to work and their’s didn’t meld in the general sense. I don’t think it’s useful to get too specific here, and probably this is something you wouldn’t know either way until you’ve been in trading for some time, but I think there’s a general lesson worth taking from this beyond just trading.
One thing I’m happy about is that I realized these things before they started to make an impact on my work. Being able to leave knowing you’ve done your best, but that you wouldn’t be doing your best if you stayed, is a very satisfying position to be in.
The reasons I give for my leaving sound negative, but I’m picking specifically the reasons I left, not the many, many reasons I stayed for nearly 4 years. Of the financial services companies I’ve worked with I enjoyed being at DRW by far the most, I don’t regret my time there at all, and I absolutely appreciate the opportunity I had (and am grateful to the leadership of DRW for giving it to me.) For developers wanting to join, or continue in, the trading industry I would recommend joining DRW wholeheartedly.
—
Of course, there’s an obvious postscript here. What am I doing now? I’m taking time off! I’ve never taken extended leave in my life, not ever since school, and I’m fortunate to be able to do so now. I have a few ideas of what I might do and I look forward to updating this blog as some of them (and others!) come to fruition.
[1] There are other types of software development jobs, e.g. programming language research, training, and ‘pure’ consultancy (as opposed to ‘body shopping’). The difference with consulting is that you’re not building a product – the end goal is to help other people build a product. I would even consider going back into finance as a ‘pure’ consultant.
[2] Maybe I’m over simplifying here, but I don’t think I’m too far off the mark
Mike Roberts