Andy Carroll recently left Twitter, where he was a staff software engineer in the social-media company’s live video group, to become the chief architect at LiquidityBook, a financial technology firm specializing in trading software. He’s gone from being the tech lead on Twitter’s live-streams of the NFL’s Thursday Night Football games to being in charge of the IT architecture of LiquidityBook’s software-as-a-service (SaaS) platform.
Going into fintech is a return to form of sorts. Carroll got his start as a financial software engineer when a close high school friend got a job working at Australian Bank, and given how few developers there were back then, he was able to pretty easily get Carroll in as well via referral. The bank became an incubator for tech talent. From there, he took on a project building a speech-recognition system to capture bid/ask quotes for the Sydney Futures Exchange comparable in performance to the existing human process on the open-outcry trading floor.
Carroll believes there are golden rules to follow if you want to make it into fintech – or any kind of tech role.
1. It’s not about the small things
For those looking to break into the industry, always think about the big picture of what you’re building, Carroll says.
“Keep a roadmap in your head of where the system has to evolve to, then build the absolutely smallest possible portion of it and ship that,” he says. “Try to ensure that what you build today can be reshaped over time into what you ultimately need, but never build more than you have to in any given release.”
Listen to your users, but keep in mind that they might not be correctly articulating what they need, Carroll advises.
2. Talk, and learn from your colleagues
Team work makes the dream work. Cliched, but true.
“Do your job, but strive to maximize the total output of your team,” Carroll says.
“It’s rare for an engineer to be exceptional developing the front-end, back-ends and middleware, but all are crucial,” he says. “It’s important to recognize when some aspect of the system should be built by someone else, then collaborate with them.”
3. Test, test, test
Get in the habit of unit-testing software. Test, test and test again.
“I cringe when someone says ‘unit-tests slow me down,'” Carroll says. “Unit-tests only slow you down when you have none and thus there’s a ton of tech debt to back-fill them.
“There’s no comparing the pace at which you can evolve a code base that has had tests versus one that hasn’t,” he says. “Bite the bullet, embrace tests – there’s no looking back.”
4. Brainstorm in advance.
“I’m a big fan of code reviews, but I don’t like development practices where a dev cranks out code and the first anyone else sees of it is a review,” Carroll says. “Similarly, I don’t like the notion of a ton of docs up front for trivial things.”
Broad collaboration must start from the get go.
“As soon as a dev dives into something they should bounce the idea off a colleague,” he says. “Nothing formal, just always try to have some degree of collaboration. It gets many of the benefits of pair programming but at no cost.”
5. Understand your industry
Pay strict attention to all engineering details but also ramp up on the domain knowledge, Carroll advises. There are many books that cover the financial domain.
“I recently stumbled across a box tucked away in my office that had a whole bunch of books on esoteric topics like option pricing, foreign exchange and capital markets that I’d read in the ’80s and ’90s, and it reminded me of how much time I spent back then trying to learn the business side of this industry,” he says. “Fintech is great because there are so many specialized books on the industry’s various niches.
“Obviously having the necessary development chops is first and foremost for any technologist, but be sure to also pay close attention to the big picture around what business problem your project is ultimately trying to solve.”
Photo credit: hocus-focus/GettyImages