My first challenge. Working at AVIV Group as a Frontend Developer!
It was day 1 as a Frontend Developer, working for the leading PropTech company in Europe, AVIV Group, and the number 1 property valuation site in France, Meilleurs Agents. It felt surreal and exciting, but I was genuinely nervous, just like anyone starting a new job.
Having a job as a Developer means there are many things to discover! Among all the questions that came to me that day, the most pragmatic was: “What do I have to do?”…
I imagined that such a big tech department involved a lot of organisation. To tame it, there’d be many hours, days and even weeks of looking for the correct information, the right benchmarks and the appropriate reflexes before I was operational. This made me believe that onboarding might be a bit scary. But guess what? It was anything but daunting.
I don’t think these nerves and feelings are specific to me. Every developer who joins a new team will have a period of discovery and adaptation to the processes and tools.
At AVIV Group, the team works in CI/CD (Continuous Integration/Continuous Delivery) and other interesting tools I had never used before. For non-tech readers, that means we continuously develop, integrate and test the new features/code before delivery to production. Some organisations prefer to work differently, but as a Developer, this is much more stimulating, rewarding and effective.
So! Let me explain my first ticket as a Frontend Developer at AVIV.
1. First ticket assignment from our Jira Kanban
Each team comprises Backend and Frontend Developers, a UX Designer, 2 Products Managers and an Engineering Manager. As a new team member, I have 2 mentors (mine are Senior Frontend Developers) available whenever I need assistance.
After familiarising myself with the working environment, the tools, the codebase and the platform — my mentors and manager allowed me to work on a topic prepared by our colleagues from the product team: adding fields relating to the Energy Performance Diagnostics (EPD) to the listing creation/modification form.
I will take care of the form on MyPro (a platform reserved for real estate professionals), whilst 2 of my colleagues will take care of the listings displayed on the public website. We collaborate through any doubts I have, and I take the opportunity to discover how the team interacts with Product Managers, UX Designers and Developers.
2. Pair Programming with mentors and daily meeting
As a new member of the team, I split my time between independent work sessions and pair programming sessions with one of my mentors.
We have a daily meeting which allows everyone to detail what they are working on to the rest of the team and to ask questions. Here, you would present the project, the wording and the mockup. Everyone shares their opinion, their remarks, and observations. We organise several meetings with our Backend colleagues, who work in parallel on integrating of the new data submitted to the form.
3. Unit Tests
Completing the integration of the new fields led me to a task I had never done yet: writing the unit tests covering the code that I wrote.
I spent much time working through the internal and external documentation relating to unit tests. I immersed myself and understood the logic that underpins each test and its relevance. Again, I alternate work sessions alone or with one of my mentors.
4. Pull Request and Jenkins’ discovery
When all the tests pass, I push my work on GitHub and open a Pull Request. The pull requests are taken very seriously at AVIV Group. The reviews, especially at my level, are great for development (for the record, I completed the ticket with almost 100 review comments)!
I retrieve the Docker image from Jenkins to make it available to the product team in our integration environment. In parallel with QA, I modify and improve my code according to the instructions of my reviewers. The Product team provides feedback quickly, we do the docking with the backend and my colleagues release the public website listing display.
The first part of my contribution to an epic task comes to an end.
5. Pre-production, second QA and end-to-end tests
An important step is deploying my work on “staging”, our pre-production. The staging environment is almost identical to production, making it possible to check that everything is okay in the global ecosystem.
To do this, I have to ask Serge (our bot) to reserve a specific token to merge my branch (previously cleaned — a mandatory condition to enable merging). At staging, I run the functional tests. These must also be enriched to cover the new form fields. If the tests pass, we are getting closer to the goal!
A second QA must be done, and since I don’t know the platform well yet, several of us, including the product team, check that everything is going well. It’s great to be in a team who are readily available and willing to collaborate!
6. Delivery and monitoring
The deployment on production is frighteningly simple, which scared me the most.
Inevitably, as it’s my first time, there’s a lot of pressure — we always want to believe that we’re doing the right things and that we anticipated all the scenarios. Still, despite that, it remains an unnerving event.
However, it’s made easier by the process we follow and the knowledge in the team. It reduces the risk of bugs in production (of course, there will always be bugs no matter what), and I discovered a convenient tool for monitoring: Sentry.
I participate in monitoring meetings, during which the frontend team reviews the bugs reported by the tool.
7. Presentation to product managers & tech rituals
There are several recurring meetings for the teams to present their work to their colleagues.
For instance, Tech & product meet to explain the objectives and detail the related actions. A demo accompanies this.
I took care of the demo by completing the form fields related to the EPD and experienced my first ticket from A to Z. At the end of the presentation, a few minutes are dedicated to questions and answers. It is a great opportunity to congratulate and recognise each colleague involved and celebrate the work done.
A work process is an organic, living thing: specific to each structure and a specified time. At each iteration, it changes according to the needs, the people and the context. It is refined and strengthened, and the tools are replaced over time. Still the intention remains: to produce, maintain, improve and deliver to the user, in ideal conditions for developers.
I’ve had such a brilliant experience integrating into the AVIV Group team. And I’m super excited about the next challenge!
Learning by doing is the best!
