Ten Things I Learned Going From Finance To Software Engineering

“Without continual growth and progress, such words as improvement, achievement, and success have no meaning.” — Benjamin Franklin

I’m not the type to have FOMO, but I’d be lying if I said I wasn’t a little envious software engineers can take ideas brewing in their minds and bring it to life. For years I’ve wanted to build applications and recently decided to seriously do something about it and jumped head first into software engineering.

My journey into software engineering is still ongoing, but if you’re currently buried in excel spreadsheets and have always wanted to make the jump, hopefully this post sheds some light to what the transition is like. If I can be helpful to at least one person, this post was worth it.

Ten Things I Learned From Going From Finance To Software Engineering:

1. Commit completely. It’s easy to start but hard to finish.
2. Throw out the career path. Embrace the zigzags.
3. You’re not starting from zero. Those excel models surprisingly translate.
4. Focus on what works for you.
5. Leverage the community but also build a foundation.
6. Know your edge.
7. Give back to the community.
8. Interviewing has its quirks.
9. You won’t win everyone over.
10. Every interaction is an opportunity to get better

1. Commit completely. It’s easy to start but hard to finish.

This seems like a no brainer but it took a lot more commitment to ramp up than I originally anticipated. Reality is you have to be completely committed to see meaningful results. The initial journey is fun but as you progress there are definitely moments where persistence is required to bridge the knowledge gap. Luckily if you can power through an afternoon of 10Ks, then you can power through documentation.

The transition from beginner to mid-level knowledge base is probably the toughest part.

There are many ways to make the transition but I decided to enroll in a software bootcamp. Everyone learns differently and I tend to thrive in environments with intense focus and self-imposed deadlines so the bootcamp environment worked really well for me. If bootcamps aren’t your thing, then consider joining some quality local meet ups and seek mentorship.

2. Throw out the career path. Embrace the zigzags.

When I made the jump, I literally had zero idea what would happen or where I’ll be. I still don’t but I’m comfortable with that reality. Software might not be an ideal profession if you can’t handle career ambiguity (especially as a career switcher). The career paths of engineers I’ve met have literally zigzagged all over the place. Most don’t have a neatly formulated path that got them to where they are today.

3. You’re not starting from zero. Those excel models surprisingly translate.

I’ve built a lot of excel models over the years and it was a surprise how much of that experience translated over to software. Many of the core concepts of functional programming will resonate with excel jockeys and any industry analyst will intuitively pick up the big picture goals of implementing OOP.

There’s definitely a learning curve as far as the nuts and bolts of programming but as you get comfortable you’ll begin to notice big picture / architectural similarities between what you’re trying to accomplish on a spreadsheet and what you’re trying to accomplish building an application. It’s an exciting feeling when you realize this.

4. Focus on what works for you.

There’s an extraordinary amount of choice and opinion in software. You can literally paralyze yourself trying to pick the “right” approach. I dabbled in Java, Python, and Ruby (on Rails) before settling on Javascript (which has its own monster set of choices/options). You’ll get a lot of suggestions on what to do but my main advice is focus on what works for you. As long as you focus on the fundamentals everything else will sort itself out.

Honestly, many of the arguments I’ve heard regarding the usage of one technology over another sound very similar to investors debating the merits of using various approaches in their investment process. They are valid discussions but don’t let them sidetrack your progress.

5. Leverage the community but also build a foundation.

Just because Silicon Valley values everything using revenue multiple doesn’t mean you should value everything using revenue multiple without trying to understand what’s going on under the hood.

Software has so many available open source resources available to abstract away every issue you might come across that you run the risk of building a lot without knowing a lot. That’s okay to a certain extent, but if you really want to level up and be a great engineer you need to build a foundation. That doesn’t mean do everything yourself, but at least try to understand why things were done a certain way.

6. Know your edge.

I’m never going to be the smartest person in the room but that doesn’t mean I don’t have an edge. Know your strengths and don’t be afraid to leverage them to become a better engineer. Many concepts you may find common knowledge in finance/investing is not always the case when it comes to software engineering. You might surprise yourself when your views can lead to important architectural adjustments.

Software engineering can occasionally feel like plumbing and putting pipes together (paraphrasing a seasoned engineer/entrepreneur) at times so it doesn’t hurt if you have unique perspective on the building being built.

7. Give back to the community.

Finance is notorious for being proprietary and secretive. Don’t be afraid or embarrassed to give back to the community. I do my best to educate engineers on the business/market side of things when they genuinely want to learn and try to be as helpful as I possibly can.

Also keep in mind that Github is your resume. Positive contributions to the open source community lead to positive results in your career.

8. Interviewing has its quirks.

I thought the finance industry had some quirky interview rituals (many of which are arguably unrelated to the job) until I started seeing how some folks in tech run their process. In many ways the inputs to the interview process have little to do with the outputs they’re hoping to generate. The more engineers I talk to about this the less this perspective seems controversial, but it does magnify the importance of warm intros to help with the interview process.

9. You won’t win everyone over.

This is probably more for the career switchers reading this but you won’t win everyone over. Software folks can be highly opinionated about many things including interview candidates and their background. Keep going and chug along.

10. Every interaction is an opportunity to get better.

Whether it’s an interview or a meetup, every interaction is an opportunity to identify holes to fill. Software engineering is a perpetual process of learning so definitely embrace the fact you don’t know everything and get out there and learn.