Newly promoted to Tech Lead, Giovanni Marchese leads the development team, manages the technical processes, and builds the back-end for complex digital platforms such as Dutch Design Week. We talk to him about peer coding, finding the best solutions for intricate problems, and his best coding practices.
When did you start at Verve?
When I just finished my studies, I applied for a job at Verve (Vruchtvlees at the time) when the team consisted of just five people. I have always liked art, film and design, so I really liked the colourful design work I’d seen. They were initially looking for a full stack developer, but I have always been more interested in back-end development. Two years later, I saw they had an open vacancy for a back-end developer, so I applied again and got the job. Now, I live just a 5 minutes walk from the office – I can listen to one song on the way there.
What is it about back-end development in particular that you find interesting?
As a back-ender you’re on the last line, so you get to see everyone’s work. And you don’t have to worry about pixels or screen sizes, you’re working with just one server. I’m interested in finding solutions for complex problems. For Dutch Design Week, for example, we connected several external systems to make the user experience seamless for designers and visitors, driven by Salesforce. Often, CRM systems are really bulky and ugly, because they have so many features and use cases. I like building the layer in between the two platforms, to make them manageable.
What tools do you use?
We recently moved to a new CMS solution, Statamic. It was a win-win situation, as the CMS gives us plenty of options to customize and build upon, while not having to allocate all of our time to developing a whole CMS from scratch. We have a live editor now, which splits your screen, and allows you to see your live actions. Our clients really love that it’s so user friendly, and for us, it’s more scalable and allows us to focus on the important things.
Working in multidisciplinary teams encourages cross-pollination, and makes everyone more engaged in other people's work.
How do you collaborate as a team to get the best results?
As the tech lead, I host the bi-weekly development meetings and take care of the processes with the team together with our digital producer Yira. We used to do development stand-ups with just our developers, but nowadays, we include our UX team too. Working this way encourages cross-pollination, and makes everyone more engaged in other people's work.
Working in multidisciplinary teams made collaboration easier and streamlined our processes. For example, design is now done by UX designers only. Previously we had brand designers work on websites too, and they came up with really creative ideas, but sometimes their designs turned out to be impossible to implement on a technical level. We have a dedicated UX team now, that closely works together with the development team. Now we can have a brand identity designed by a brand designer, implemented in a website design by a UX designer, and coded by our in-house development team.
How did COVID-19 impact working together?
Ha, recently we discussed this at the office. Working from home actually benefited working together as a development team. It was easier to communicate with each other. Before, if you had a problem, you had to get up, walk to someone’s desk, and interrupt them. But when we started working remotely, we often called each other via Slack, shared our screens, and peer programmed together – and without noticing half an hour has passed.
These peer programming sessions are really helpful. When I’m the teacher during a session, I’m explaining things to someone else, but it also allows me to see how the other person implements my solutions in code. You learn a lot from that, and when it’s the other way around I learn just as much. It’s fun to see how someone else solves problems, and it makes collaboration easier. That was funny, as we didn’t necessarily expect that when we started working from home.
It’s fun to see how someone else solves problems, and it makes collaboration easier.
What’s the most important thing to launch a digital project successfully?
You have to truly understand the question of the client. You have to think through their problem, and how it could be solved in the easiest and best way. Sometimes that ends up being something different than the client thought they needed at the start of the process. Next to that, the involvement of UX with the development team and vice versa is really important. Everyone that works on the project, should be kept in the loop and stay up to date.
What technical developments are you interested in further developing?
Using the CMS headless. It means that instead of building multipage-applications (you click somewhere, a new page loads), we’d create single-page applications (no reloads). Technically, it means working with a separate front-end application and a separate CMS – and working with multiple codebases. You can compare it with a phone app like Facebook: when you download it, you don’t download their whole CMS. We already took the first steps for that. Using the CMS headless makes your website more user friendly and scalable in terms of traffic. The only drawback is that it takes a larger time investment.
How do you stay up to date in an ever-changing landscape of technology?
I learn a lot from the peer programming sessions I mentioned earlier. And next to that, I’m an avid lurker on Twitter. There are a lot of developers and companies on there, so I instantly know when new libraries or frameworks are launched, or what else is happening in the development landscape. As a team, we’re not scared to try new technology – we do that often. Livewire, which I mentioned earlier, is an example of that. Someone suggested trying it, and now it’s one of the tools we use daily.
To wrap it up, any best coding practices you’d like to share?
A coding practice I recommend to everyone: try to write as much code in one go as you can, without checking if it works. A lot of people check their browsers after two lines of code, but when you build a functionality or feature, you have to think things through and anticipate.
As a front-end developer, you learn to structure the page from scratch. As a back-end developer, you learn to think through a whole functionality and anticipate potential problems. After coding for an hour or two, you can check if it works. It’s a training method that will make you become a better developer.
When you build a functionality or feature, you have to think things through and anticipate.