Pennylane (Senior Software Engineer freelance)

Presentation

Pennylane is a French financial platform that combines accounting software and financial management tools for businesses. It connects accountants and companies through a shared system, centralizing invoicing, expenses, and real-time financial data. The platform is built with a strong focus on API integrations and background processing to ensure reliable synchronization and efficient handling of financial operations across multiple services. It's a Monolith.

I joined Pennylane as a Senior Backend Engineer in the IAM Squad (authorization and permissions). I was initially the only senior in a newly created squad responsible for a specific scope within a large monolith (with more than 300 developers actively working on it). The context was particular. Pennylane is a very successful company with growing revenue. As such, the company invests heavily, providing access to many advanced AI tools. I got to work with the latest Claude models, Dust with already set up agents, as well as Datadog and Sentry. I also experimented with the challenges of scaling a monolith, discovering the use of merge queues and the Packwerk gems.

The company had very well-defined processes, with squads grouped into larger structures and a precise team organization including developers from Junior to Staff level, Engineering Managers, and Product Managers. Each member had a specific role based on their position and seniority, and coordination between teams was ensured through processes, a fairly advanced CI and Git hooks system, as well as a review process based on CODEOWNERS.

The main goal of my squad was to create a new permissions system based on CanCanCan to replace the old one, which was based on a legacy solution that had become difficult to maintain and scale. The new system was designed to be more flexible and scalable, allowing for better management of permissions across the platform. I was responsible for leading the development of this system, which involved designing the architecture, implementing core features, and ensuring seamless integration with the existing monolith, with various constraints around migration and data organization. I also collaborated closely with other teams to ensure that the new system met the needs of stakeholders and provided a solid foundation for future growth. I was also active in the Sidekiq fellowship (transverse team) on the side and performing smaller task in Kanban.

Personal impression

This experience brought its share of challenges and learnings. It made clear that my Ruby and Rails skills are at a Senior, possibly Staff level, but that I still had a lot to learn from the team organization and large-scale processes. It was a B2B company, and I worked on authorization and permissions, impacting every user. I had to be extremely careful due to SLAs and the risks of affecting production users. I discovered the Packwerk gem from Shopify, widely used to help scale a monolith across teams with limited interaction. It redefines the concept of ownership, where each file is owned by a squad, which changes the way code is structured and maintained. I also worked with very experienced people, which was motivating.

As the world evolves, I also had to adapt. I started using AI in my daily development, not only for code completion but also in agent mode. I had the chance to learn coding without it, which allows me to challenge AI outputs, but I cannot ignore the productivity gains it brings in some contexts. When properly trained and documented, AI makes fewer mistakes, can follow RuboCop rules and coding guidelines, and can even help detect misuse. This was a real shift in my developer experience.

Overall, it was a valuable experience. I led a major project that is still ongoing. I spent an entire week working on an RFC and was recognized by several peers for my engineering approach and my ability to break down complex problems into milestones, as well as to lead and mentor other developers on the project. There were also downsides. I had never experienced so much friction in development. It was difficult to commit changes due to strict hooks rules and RuboCop constraints. It was also hard to challenge them, as changes could impact many files. The guidelines were somewhat rigid and difficult to evolve. The merge queue was often stuck, and the monolith approach showed its limits with a growing number of developers. This was very different from my previous startup experience, where iteration was much faster.

Skills