Interview with Daniela Baron, Staff Engineer at FundThrough

I've never felt more productive or happy than when working with Ruby on Rails. Compared to other frameworks, my experience has been that Rails lets me quickly get to solving the business problems, without having to spend much time on lower level details and re-inventing the wheel. - Daniela

Welcome to the new series on this blog where I interview noteworthy Ruby and Rails developers, especially those who have made significant contributions to the community with their code, writing, or leadership.

In this second post in the series, I interviewed Daniela Baron, a Rails developer who is working as a staff engineer at FundThrough, a leading fintech company in Toronto, Canada. I first came across Daniela via her excellent blog and we have since stayed in touch on LinkedIn.

In this interview, Daniela provides great advice for new developers as well as a ton of quality recommendations for learning resources and tools. I think you'll really love it.

Please enjoy!

Can you tell us a little about yourself?

I'm based in Toronto, Canada. I've been in tech for over 20 years delivering software solutions for product, project and SaaS based companies with a variety of languages and frameworks.

For the past 7 months, I've been working as a Staff Engineer at FundThrough, a leading fintech company accelerating cash flow and enabling growth for small and medium businesses who sell to large customers and wait to get paid. Our tech stack includes Rails, Sidekiq, Postgres, Redis, React, Python, Kafka, microservices architecture, and AWS.

💡

Based in Toronto and operating across North America, FundThrough’s AI-powered invoice funding platform gives B2B businesses fast, customized funding offers to get their invoices paid in a few days – rather than a few months – and get quick access to cash they’ve already earned.

Before that I was a Staff Engineer at Tucows, working primarily on Hover, a domains registrar that offers a user-friendly platform for registering and managing domain names and email. That was built as a Rails monolith with MySQL, React, and the Hashicorp stack (Terraform, Consul, Vault, Nomad).

As a staff engineer, my role extends beyond addressing immediate challenges. It also involves focusing on long-term maintainability, improving developer experience, and having influence. This includes ensuring a comprehensive test suite is maintained alongside the code, fostering effective code reviews, maintaining engineering documentation (and encouraging others to do this as well!), and mentoring.

I also starting blogging in early 2020, sharing insights on problem-solving, learning strategies, and career development.

How did you get into programming?

When starting post-secondary education, I found myself grappling with the age-old question of "What do you want to be when you grow up?"

In pursuit of an answer, I took a range of first-year courses including psychology, sociology, economics, calculus, and an introductory computer course. The computer course covered hardware, software, networking, programming, and theoretical computer science.

I enjoyed the programming assignments so much, I would stay up all night adding extra features just for fun. It was around this time I realized you could get paid to do this and chose to major in computer science.

After graduation I landed a software development job at a retailer, working on their J2EE e-commerce platform. It was at this point I realized my post-secondary education had been long on theory but short on the practical, so there was definitely a lot of on-the-job learning. Having wonderful mentors also helped.

How and when did you came across Ruby and Rails? What do you most like about them both?

I spent the first part of my career working with Java, followed by a brief detour into .NET. Then some Golang, a little Python, and several more years doing fullstack JavaScript with Node.js and various SPA frameworks.

Around 2019, a recruiter reached out to me about a role involving Rails and Ember. It seemed intriguing, so I went ahead with the interview process. Fortunately, it was the kind of company that values a broad range of engineering skills and experience over knowledge of a specific language or framework, and they offered me the role.

I took about a month off in between jobs to take courses, first Ruby to understand the fundamentals of the language, and then Rails. From the first section of the course covering how Rails implements MVC, data migrations, models, validation, and seeding the database, I could see the value right away.

I've been working with Ruby on Rails since then, and have never felt more productive or happy than when working with it. Compared to other frameworks, my experience has been that Rails lets me quickly get to solving the business problems, without having to spend much time on lower level details and re-inventing the wheel. Some of my favorite aspects include:

Conventions: The strong conventions make each project, even at completely different companies and industries look very similar. This supports new people being able to join the project and become productive relatively quickly.
Testing: Testing is a first class citizen in Rails. Including testing with the database and automatic transaction rollback. I like that the tests are setup with the generators so you're on the right path from the very beginning.
Documentation: Really appreciate the care that has gone into the Rails Guides, and the API docs. I often find the solution to a problem I'm facing in the official docs.
Gems: For features that aren't directly provided by Rails (eg: model auditing, schema annotations, profiling, etc.), there's always a gem that can be pulled in and easily integrated. Past lesson learned: Look for gems with decent sized community to increase the chances that they get maintained as new Rails versions are released.

Looking to the future, I'm most excited by the Hotwire stack (Turbo + Stimulus) with its potential to replace (or at least reduce the need for) JavaScript SPA frameworks. I've gone through several tutorials and part of a book using the Hotwire stack.

The idea of having just one router instead of two (server side and client side), and only one source of state management seems like a simpler, more maintainable programming model.

Programming books that meant most to you, and why?

Clean Code: For general principles in naming things and organizing code to make it more legible.

Refactoring: The opportunity to greenfield a new project is quite rare. What's more common is joining a large legacy project, many features of which may have been developed in a hurry to meet a tight deadline, by developers who no longer work at the company. In this case, the teachings in this book have been very helpful for learning how to make gradual improvements to existing code, while avoiding regressions.

This next book I picked up recently and am about half way through. Actually, the majority of my learning has been via screencasts, but recently decided to go back to books to mix things up.

Agile Web Development with Rails 7: This book guides you through the process of building an e-commerce site with Rails, and along the way, explains the details of essential Rails concepts, and web development generally.

The "Playtime" exercises at the end of each chapter are really useful. This is where the most learning takes place, in enhancing what was previously built in the chapter to add new functionality, on your own. Inevitably something will break or not work as expected, and consulting the docs/debugging reinforces the learning.

The following books are next up on my reading list:

I'd also like to share a non-programming book that has significantly improved my productivity and influenced my overall approach to work and life.

When: Scientific Secrets of Perfect Timing: If you've ever found yourself grappling with what should be a simple bug fix, while at other times, you effortlessly breeze through a complex project, timing might hold the key.

This book covers the importance of timing in our daily lives, and the research showing how timing can affect our productivity, decision-making, and overall well-being. It turns out that certain times of day are better for certain types of tasks, and this is strongly influenced by our biological clocks rather than personal preference or habit.

I gave a presentation on some of the learnings from this book and how software engineers can apply it to organize their day. Press s to view the speaker notes alongside the slides.

Who are your programming heroes?

I've been fortunate to have worked with many amazing colleagues throughout the years who have taught me so much. A few standouts:

A colleague who would often introduce the team to new concepts. When I asked him how he knew so much, he would mention the books he had learned from. Up until that point, I thought the only way to use a new tech skill was if your current employer decided to use that particular tool/language/library. Working with this developer made me realize you don't need "permission" from your employer or anyone to learn something new.

A colleague that encouraged me to look beyond the quick answers found on Stack Overflow, emphasizing the importance of also reading the official documentation and digging deeper into source code to gain a better understanding of how something works.

Another experience that greatly influenced me was when an agile coach introduced me to the benefits of writing automated tests and conducting pull request (PR) reviews. These practices haven't always been industry standard. This coach's passion for improving code quality and efficiency through these practices left a lasting impact on how I approach software development.

What does your typical day look like as a developer? What do you like the most about your current work?

I've been working fully remote since ~2020. As someone who needs absolute silence to focus, this is an optimal setup. I've also been experimenting with async work. My working hours are somewhat flexible, I try to get in deep analytical work in the morning, and code reviews later in the afternoon.

A typical day's activities could include:

Analysis of business requirements - make sure I understand why the feature is being added, ask clarifying questions, identify edge cases.
Code analysis - digging through legacy code, identify places where it could be improved, try to find if there already is some code that does the thing being asked for.
Break down business requirements into manageable tasks, finding a way to deliver in smaller increments rather doing a "big bang" release. This results in smaller PRs which are easier to review, and less overall risk.
Identify tasks that can be done in parallel, which would support other developers joining in to build out this feature.
Building the feature - writing code and tests, refactor, iterate.
PR reviews (lots and lots of these).
Helping other developers with their tasks, suggested approaches.
Investigate performance issues.
Identify process improvements, automation opportunities.
Write architectural proposals, sharing discoveries with the team.
Monitor Slack threads for areas of missing documentation - such as when someone asks a "how do you do this on our app" type question, after its resolved I'll pipe in with a suggestion where this could get captured as an engineering doc.
After a problem is solved, try to extract a more generic example that can be shared publicly in a blog post and/or demo Github repo.

The most satisfying part of my work is the process of building something from scratch and delivering a solution that truly helps customers. Additionally, I find great fulfillment in assisting other developers in their tasks, sharing knowledge, and collaborating.

One of the best parts about this career is that it never gets boring as there's always something new to learn. This can be a double-edged sword, as the constant evolution of technology and tools can be overwhelming.

My approach is to use a combination of newsletters and podcasts to maintain awareness of what's happening, but not necessarily jumping on "bleeding edge" tech. Once something has shown to have some staying power, then I'll consider taking a course and/or trying it out in a side project.

Here are my newsletter subscriptions. I file these in a "read-later" folder, then set aside time once a week to catch up:

Podcasts are another fantastic way to keep up-to-date. I can listen and learn while doing mundane chores like folding laundry or meal prepping. Here are the tech podcasts I listen to:

Rails or Ruby:

Front end:

Security:

Other programming and tech:

For course platforms, the style that's most effective for me is screencasts, that can be watched at any time, and on my own pace. I've written about how to get the most out of screencasts. Here are some platforms and instructors I've taken courses from:

I've also experimented with different modalities for learning including formal continuing education, workshops, books, MOOCs, screencasts, and written about the pros and cons of each.

What advice do you have for new programmers?

If you plan to go into web development, learn the fundamentals of HTTP, including the structure of HTTP requests and responses, verbs, status codes, query parameters, and related concepts. So many courses, tutorials, blog posts etc. assume you already have this foundation.

Ask lots of questions. On the business side, it's important to understand why you're being tasked with something, and what the overall business goals are. On the technical side, if someone suggests to use tool X over Y, or to refactor some code you wrote, make sure you understand why this is better.

Tools of the trade - What are some of your favorite software programs in your day-to-day work?

Code editor: VSCode with Night Owl theme.

Database GUI: DataGrip (licensed) or DBeaver (free).

Terminal: iTerm + Solarized Dark + ohmyzsh Agnoster theme: My very first blog post explains how to set this up.

Browser: Chrome. I've considered switching for privacy, but have a very efficient setup with tabs, custom search engine, and bookmark indexing. Moving to a new browser would mean finding alternative solutions for these.

Notes: VSCode with Markdown All in One extension, Apple notes.

Project Management: The majority of the companies I've worked for have used Jira. If I'm starting a new project and have the flexibility to choose, my preference is Github Projects/Issues.

Communication: Slack, Google Meet/Hangouts (or whatever Google is naming their video meeting product these days).

That's a wrap. I hope you found this interview helpful and you learned something new. If you liked it, check out the previous interview with Miles Woodroffe, former global CTO of Cookpad.

As always, if you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I reply to all emails I get from developers, and I look forward to hearing from you.

If you'd like to receive future articles and interviews directly in your email, please subscribe to my blog. If you're already a subscriber, thank you.