Onboarding with Fibonacci Web Studio

Joining Fibonacci Web Studios, I was immediately surrounded by tools I’d never used: DDEV, Pantheon, PHP, and Backdrop CMS. Coming from Python and C in university projects, this was my first experience with the PHP/CMS ecosystem.

Getting My Bearings

I spent my first week learning the ropes from my project manager, and getting hands on with the tech stack: setting up local development environments with DDEV (a Docker-based tool for managing site containers and MySQL databases), exploring Backdrop’s module system, and understanding how client sites are structured. Some concepts translated well—Docker fundamentals, database queries, version control—other concepts were entirely new.

The biggest adjustment was getting accustomed to how not everything works out nicely. The codebase I was working in was not handcrafted by a teacher to neatly anticipate the necessary fix – neither was it, like in personal projects, my own design that I know inside and out.

The Challenge: Missing User Account Data

My first task was building a “download report” feature for a client website. Users needed to download customized reports based on their user accounts data. There was an immediate hiccup, because the required user authentication fields weren’t being captured.

With my mentor, I traced the issue to the OpenID Connect module, which handles user authentication but wasn’t exposing the fields our report needed. My experience on the first day of debugging encapsulates something entirely different from academic projects:

I was running the Pantheon ‘dev’ instance of the client site, testing different login edge cases, when I noticed something strange: even after logging out, deleting the test_user account, and verifying it was absent in the MySQL database, using the same email would automatically log me back in.

What was happening? Even in ‘dev’, the SSO provider was adding the email to its production records. Worse, logging into ‘dev’ immediately redirected me to the production instance of the site.

To actually test in dev, I discovered I had to: Log out in production Log backtrack to the dev site Log out in dev Log in with a proxy email “user+test2025@gmail.com”

I went to my mentor the next day, wary of the roundabout solution I’d used to get testing off the ground. I mentioned my hunch about the SSO provider and the proxy emails, and remarked on the certain picky order I had to follow — to which she replied “very good” and happily informed me that in the world of real software development there is always a certain picky order.

Debugging and Fixing the Module

Debugging was not linear:

1. Read through the OpenID Connect module code and identified where data was being dropped during the authentication pipeline
2. Wrote a submodule of OpenID Connect to specifically handle the client’s site’s needs
3. Found a less PHP-verbose solution using Backdrop GUI config window
4. Removed the submodule
5. Added in custom filtering logic to preserve the required attributes and correctly map them into the user account
6. Tested locally on the dev branch of the client site, and verified that the fix worked end-to-end

And with that, I submitted my first PR and completed my first production level code review! —which I found similar to code reviews in Berkeley’s operating systems class. I incorporated the feedback, and my fix was merged into the 1.x-1.0.0 release of the Backdrop OpenID Connect module.

What I Learned

Real-world software development is unintuitively constrained. In personal projects you have all of the degrees of freedom to move. In school projects you often have only a handful. In production environments with large codebases, there seem to be a million ways to proceed when you want one, and only one when you want a million.

Mentorship matters. My project manager was invaluable—she knew when to let me struggle through a problem and when to point me toward the right resources. Fibo set a high bar for quality leadership—I’m super grateful for that.