Chez Meeko, nous appelons nos développeurs Ingénieurs. Cela peut surprendre, mais nous considérons que, même s’ils n’ont pas fait une école d’ingénieur, c’est un travail qui demande les compétences et la rigueur que l'on attend d'un ingénieur :
Chez Meeko, nous faisons confiance à nos ingénieurs. Chacun a une grande autonomie dans son travail et peut proposer des améliorations, expérimenter de nouvelles approches ou challenger l'existant.
Chaque ingénieur, quel que soit son niveau, contribue à l’amélioration du produit, collabore avec les équipes Support, Produit et Design et peut être sollicité pour apporter son expertise sur des décisions stratégiques.
Nous favorisons une approche full-stack. Cela signifie que nous ne cloisonnons pas strictement le backend et le frontend : chaque ingénieur est encouragé à comprendre et à intervenir sur l’ensemble de la stack.
Cela facilite le développement, réduit les blocages et renforce la collaboration. Chacun a bien sûr ses spécialités, mais nous valorisons l'apprentissage continu et le partage de compétences pour faire progresser l’ensemble de l’équipe.
Nous croyons que les meilleures solutions émergent d’une collaboration efficace. Chez Meeko, nous fonctionnons en équipe et encourageons la communication ouverte. Un ingénieur ne travaille jamais seul dans son coin : il partage ses connaissances, sollicite des retours et s’assure que les décisions techniques sont bien comprises par ses pairs.
Nous valorisons aussi l’entraide et la transmission des connaissances. Chacun est responsable de la progression de l’équipe, que ce soit par du mentoring, des revues de code constructives ou simplement en partageant des bonnes pratiques.
Chaque ingénieur est responsable des systèmes qu’il construit. Un bon code, c'est un code qui peut être maintenu et amélioré dans le temps.
Un bon ingénieur laisse toujours le code qu'il modifie dans un meilleur état que celui dans lequel il l'a trouvé.
Chez Meeko, la refactorisation fait partie intégrante du développement. Nous n’allouons pas de "temps spécifique" pour cela, car c’est une habitude quotidienne. Cependant, nous savons prioriser : si un refactoring n'apporte pas d’impact utilisateur ou ne facilite pas le développement futur, il n’est pas une priorité.