A bit about me
Get to know a little bit about the author of this site
Brief introduction
I am a backend developer, working since 2016, born in south of France. I have experience in various languages, with various business areas, but essentially in big structures (more than a hundred developers). In this last element I mean that my opinions are forged by the fact that I always worked with a lot of teammates, and might not be adapted for early stage startups or so.
Favorite topics
My main focuses (or obsessions) when working are code maintainability, automated delivery and flawless communication. Let's go through those one by one:
- Code Maintainability: I mean here everything that will help the code
of a company to be consistent, easy to dive in, and able to receive new functionalities.
- Of course, you need a good pack of unit test and integration tests, which must be automated. I tend to be a bit extremist on this and put some coverage measurements in pull requests' checks. I know that sometimes pull requests might be a bit time sensitive, but a UT is not so much to ask, and should be part of any healthy development phase.
- I mentioned it previously, and it should be an absolute standard, you need to have a peer review system enabled. Anyone can make errors, even the most seniors of us, and anyway two or more brains are always more efficients than one. Pushing straight into a repo without peer check should grind any developer's teeth.
- Linting or coding convention is also something I classify as code maintainability. When coding in a specific company, you don't want to adapt to a specific convention for every team's (or worst, for every developer's) code. It should be identical, so anyone in the company can check any code easily.
- Automated Delivery: This one may be my favorite. When achieved
correctly, it makes any developer's life so easier and allow everyone to focus on what we all love: coding a product.
- It goes with the absolute need for a CI/CD tool. Jenkins, Teamcity, Circle CI, GitHub Actions... anything that can run your tests automatically, package your software, and push it where you want. Those tools might take a bit of time (or even a full working team) to set up, but the time to deliver features will be incredibly improved, as well as the stability of your application.
- Frequent production releases is also something that I would put as good for automated delivery. The most changes you put in a release, the highest probability to fail you have. To avoid having to roll back a good part of your releases, the best is to release as soon as the code is stamped ready by the CI/CD tool. Releases to production can be automated as well, but here I think it's a matter of maturity of your product and of your development team.
- Last thing I would put in this topic is automated infrastructure management. If your company can release in production automatically, you need your infrastructure to adapt accordingly. And even if your changes need new backends, or I don't know what, it will always be better for every one to have an "infrastructure as code", in terms of maintainability and knowledge transfer.
- Flawless communication: This is definitely the weirdest one. I am
myself surprised that it is in my top topics, but thinking about it, I think I got shocked in my first years by the
avalanche of emails and meetings invitations you receive on a daily basis when working in big companies. Also, I think
developers' job need a lot of concentration, and being interrupted really decrease your productivity, so this is why
this topic is important.
- Over using instant messaging application is one of my mottos. Even when working with someone right next to you, a ping on IM to check if you can bother him/her is common courtesy, and might avoid the person to get out of focus. You can also expose complex problems in IM, allowing the person to either give you small hints, or to talk to you directly or by phone. I discovered that this habit had a rubber duck effect on me sometimes: writing down your problem might help you to solve it without sending the message. To me IM is really an underrated tool.
- I also try to keep the number of emails to a bare minimum. I will use a dumb analogy: try to picture your email box as a real mailbox. If you receive a hundred letters every day, would you really mind to open all of them, knowing that you have a job on the side? Never. You would just probably check the sender address and open the ones you expected to receive. It's the same with emails. If you send a lot, a lot won't get read.
- So if you don't email, you still need to pass information. That's where you use channel based communication. Every topic in a company should have a channel, and users should be able to join it when interested in this topic. Slack, teams, a lot of enterprise chat applications offer this kind of feature that will allow the info to be passed to the people that are interested in them. This is crucial for a good communication in the workplace.
- Having a strong discipline during meetings is essential. They start on time, they finish on time. The agenda is set beforehand, everything that is out of it is not discussed before the end. As a meeting organizer, you must interrupt people that are out of topic, or running in circles. You must decide what can be decided now, what needs more digging up. There is no shame to send back people to their desks after 10 minutes if you realise a lot of information is missing to have the meeting running properly. People don't realise how a meeting is expensive regarding the number of people involved. That's why at the moment a meeting starts being uncertain, out of purpose, or that you have to dig information in real time, you should not hesitate to end it. A meeting must be well-prepared and well arbitrated, and the organizer is the sole owner of those responsibilities.