In our “Meet the Proxyclickers” blog series, we’re sitting down and catching up with our team to understand their background, their role, how they’re striving for improvement, and what keeps them motivated for success.
In this second edition (see our debut edition here), we’re meeting Thomas Mouchart, our Engineering Manager. Thomas is a Proxyclick veteran and has been working on the product for years. When he’s not coding, you’ll find him in cross-departmental knowledge sharing sessions, or killing it mid-gaming session with Proxyclick colleagues.
Here's what Thomas has to say about life on the Product team at Proxyclick.
Q&A with Thomas Mouchart, Engineering Manager
Let’s start by having you introduce yourself. What’s your role at Proxyclick, and what do you like best about it?
Thomas: My name is Thomas, I’m a full-stack developer and Engineering Manager on the Product team at Proxyclick. I studied engineering and specialized in IT engineering and artificial intelligence. It was fun, I got to play with robots.
I like the fact that I’m involved in everything, from the conception and implementation of the product and that I can quickly develop, deploy, and apply fixes. We are very autonomous and we can have a lot of impact on customers directly. The full-stack part is great, too: when I build features, I’m involved from start to finish and I can really see my impact.
Another thing that I like is that we are very connected to other teams. We speak to the customer success team, to the marketing team, to the sales team...even now that we are growing, it’s great to see we still have this culture.
Why did you decide to join Proxyclick?
Thomas: Right after my studies, I joined a big company in the banking industry. It was very different from Proxyclick; we had lots of protocols and procedures, and long release cycles. And as developers, we never saw or talked to customers - we were only working behind the scenes.
After 5 years, I wanted to work for a smaller company in order to have a bigger impact on the organization. I found Proxyclick, where I met Gregory (our CEO), JB (our CTO), and Geoffroy (our CPO), and we clicked right away. I’ve now been working here for four years and I’ve been involved in all facets of the Proxyclick apps: servers, front-end development, back-end development, and integrations.
I was convinced that I wanted to work in the web industry. It didn’t make sense to me to work for an on-premise or desktop software company. Proxyclick is a SaaS cloud solution, and I always believed that services communicating with each other was the future.
We don’t have to do everything or be the best at everything when we take an integration approach: we simply have to connect to third-party services and let them do what they do best.
For example, to send emails, we don’t have to develop the emails ourselves. Instead, we just connect to a third-party solution like SendGrid. The world of connected apps and software are the future, and that’s where I wanted to be.
Honestly, I didn’t really care about visitor management. In my opinion, the most important is not the end goal of the company, but how the company wants to achieve this goal, and with which technologies.
Thomas (on the right) is pretty serious about knowledge transfer and regularly
does technical training sessions for other teams.
What do you like about working at Proxyclick?
Thomas: Everyone is open. There are no silos, we can work and have fun together. In pre-coronavirus times, we had a hot-desking system in the office where every morning, you’d choose to sit wherever you wanted and next to whoever you felt like. I didn’t have to sit with developers or members of the product team. We keep this connection with everyone in the company, which is super fun and important.
We still have that small startup vibe where we play ping pong, PlayStation, darts, Crokinole…I mean, when we were all still in the office. I really miss all of that.
So, tell us, how is the Product team organized?
Thomas: At the moment, the team is organized into 3 squads: the Mobile Squad, the Identity Squad, and the Core Squad.
I’m on the Core Squad, which is the biggest one and includes developers, designers, testers, and product owners. We deal with everything related to visitor management. We work in a full-stack mode, which means we split the work by features and not by the level of the stack.
These squads are subject to change with our business needs.
Can you give me an overview of our stack?
Thomas: Let’s start with the Core Squad. We work with a central database in MySQL, and we have a core engine written in Adobe ColdFusion. We consider it a legacy language, so we are moving away from it.
For the back-end, new features are developed in Node.js and all these microservices communicate with each other via a messaging system called Apache Pulsar. It gives us consistency with the messages in the queue. It also allows us to replay messages, and it’s a very powerful tool for the distributed systems that like us. For the front-end, we try to always work with the latest version of Angular.
The Mobile Squad works in Xamarin, a framework where you code in C# which allows you to span from the same code base for iOS, Android, and Windows.
The Identity Squad works in C#.net, and for the front-end, they use Angular.
How is work organized in the Core Squad?
Thomas: We work in an Agile fashion with two-week sprints, and the scrum master is different every sprint. Sometimes it’s a designer, sometimes a developer, sometimes a product owner, sometimes a tester. We hold daily stand-ups where everyone has a chance to speak and mention if they’re blocked on anything. If they are blocked, the scrum master has the responsibility to unblock the issue, be it with internal members of the squad, or with external members. We also have weekly grooming sessions where we discuss issues.
If someone junior needs coaching from a more senior member of the team, we organize Peer Programming sessions where we sit together (or screen share if we are working remotely), and work together to make sure the junior team member can progress. When they are comfortable, they can continue on their own.
When the task is done, they create a merge request, which means they present their work to a senior member of the team, who will review the code. The senior developer will give feedback if any, and the junior developer takes these into account, reworking their code if needed. We keep going back and forth until it’s considered good enough by the senior developer. It then goes into a test environment. The Quality Assurance (QA) team tests the feature and alerts us of any bug they find. When code passes QA team criteria, it’s ready to be deployed into production.
We have a strong Continuous Integration and Continuous Delivery (CI/CD), which allow us to deliver code changes more frequently and reliably.
From left to right: JP, Danny, Thomas, JB, and Philippine in the back
How do QA and testing processes work at Proxyclick?
Thomas: The QA team tests our features end-to-end. Before starting the test, they look at the cards and write scenarios and use cases. Then, they go through each scenario and use case and make sure that the behavior is as expected.
They also have automated regression tests: they have software that is programmed to perform a certain behavior, and a certain response is expected. Those automated tests are running all the time in the background. We receive a report every night to see what failed and what we should work on. Thanks to these regression tests, we can be sure we don’t break old features when we push new ones.
Testing is not only made by the QA team, but it’s also done by the developers.
We do unit testing for new services that we put in place. We thrive to have 100% coverage, which means that every line of code needs to be tested.
We isolate functions and behaviors and test them with dummy data. We also mock all the external services that we have so our tests are not dependent on the configuration of a server. That’s called white box testing.
A developer is not allowed to push code if the coverage fails. The coverage limit needs to be achieved for the merge request. You have to write your test or you won’t be able to push your code.
How often do you have a release?
Thomas: It depends on the components.
For ColdFusion, we have one release every two sprints, so one release every four weeks with everything that’s been worked on and ready in this timeframe. Only the big components like the Dashboard or the servers have specific release time. We are working to reduce this frequency and to remove these static release timeframes. We want to be able to push anytime. We are almost there!
For smaller services and integrations that are independent (this is the concept behind microservices), we push them to production as soon as they’re ready. Just because we have two-week sprints doesn’t mean we are waiting for the end of a sprint to release something. Releases can happen anytime during the sprint.
How much autonomy does a developer get?
Thomas: We are very autonomous in the way we approach problems. We don’t impose a specific solution or a way of solving something on someone.
Here’s how it works: we have a set of tasks in our backlog that must be done during the sprint, but we don’t assign them to anybody. Each developer picks the tasks they think they should work on and we work together to meet our squad goals.
What’s important is that the task is only a description of the problem, it’s not a solution. As a developer, you are free to come up with your own way of tackling the problem. You’re completely autonomous.
If you need help, you can always ask for it from your manager as well as your peers.
What is your biggest challenge at work right now?
Thomas: The biggest challenge for me right now is finding the right balance between coding versus coaching.
When I started, we were in a “cowboy mode.” That is, if something has to be done, you do it - you always go forward and you don’t have to transfer knowledge. We were only 2 or 3 developers and we were very autonomous. Now, we have a bigger team with more junior developers, which means we have to transfer knowledge and make it sustainable and easy to reproduce. We have to take more time to do things well.
How do you approach that problem?
Thomas: I don’t like rules where you have to commit to timeframes. It doesn’t work for me. I prefer organized chaos: I work on an ad-hoc basis and based on how I’m feeling. Some weeks are more about coaching, some about coding.
Why do you think a developer or tech person should join Proxyclick team over other companies?
Thomas: For me, the biggest reason is the impact you have: you will work on a software that is used by thousands of people every day. What we do is very visible.
You can start at Proxyclick and be put in charge of a feature on your own very quickly, and do something that will change the lives of a lot of people within their offices. We are not afraid to give responsibilities and opportunities to team members so they can do what they do best.
On top of that, we have the freedom to work how we want - we are very open to discussion and brainstorming. We’re always improving upon Proxyclick’s ecosystem, and you are welcome to come up with your own solutions.
Something that comes up a lot is that junior devs tend to be really happy with the short response time of senior devs. When someone has an issue, one of the senior developers will be there to help. We are a nice balanced team of juniors and seniors, which means there is good knowledge transfer or a good flow of information among team members. We reserve time to help each other - it’s even part of sprint planning.
Finally, we use state-of-the-art technologies and languages. We don’t use legacy code or tools. We use Gitlab, which is the best tool on the market, for continuous integration, code review, and to work together as a team.
We also do unit tests, coverage, automated tests…in my opinion it’s hard to find a company that does all of that. Many companies are nowhere near such a high-quality developer ecosystem.
Interested in joining the tech team?
Check out our job openings here.