GRAPHISTE VS DEVELOPPEUR

Ahhh les développeurs et les graphistes. Grand débat n’est ce pas ?
Cela fait un moment que j’avais envie d’écrire sur le sujet, non pas pour montrer nos différences mais plutôt à quel point nous sommes complémentaires. Comme je m’inspire d’expériences personnelles, les exemples seront axés dev / graphiste 3D. Mais que vous soyez développeur web, backend ou graphiste print je suis persuadée que vous vous reconnaîtrez dans certaines situations 😉

Développeur…Graphiste…On pourrait croire à première vue que nos métiers viennent de 2 mondes distincts.

Le développeur, ce cartésien qui aime quand tout est carré et bien ordonné. Que son code soit le plus propre et organisé possible à l’image de sa pensée.

Le graphiste, ce créatif un peu lunatique et rêveur, qui éparpille ses fichiers un peu partout sur le serveur, fervent adepte du renommage incrémental type « test-OK-version-finale5 ».

Tout semble les opposer n’est ce pas ? Et pourtant, nous avons bien plus de points communs que nous voulons le penser.

Maître des outils tu seras

Le développeur n’est pas un simple exécutant, mais un véritable créateur à sa manière. Loin des outils traditionnels, c’est à travers des lignes de code qu’il va créer de toute pièce une application ou un logiciel.

Le graphiste 3D réalise le même travail mais à partir de polygones. Un simple cube ou une primitive peut devenir en quelques heures un personnage complet, un environnement ou tout autre objet.

Dans les deux cas l’imagination est notre seule limite.

De l’optimisation tu feras

Prenons un autre exemple.

Le développeur va passer du temps à refactorer son code pour qu’il soit le plus optimisé possible. Plus le code est simple et compréhensible, plus il est facile à maintenir et moins sujet aux bugs.

Le graphiste aussi fait du refactoring, qu’on appelle dans notre jargon la retopologie. Il  travaille parfois sur des fichiers 3D de plusieurs millions de polygones qu’il faut optimiser. Le but est d’enlever un maximum de polygones sans dénaturer l’apparence globale.
Tout comme pour le développeur, cela permet de faciliter la maintenance de l’objet 3D, d’éviter les bugs en ayant le maillage le plus propre possible et alléger le poids du fichier au maximum pour éviter les lags.

Encore un point commun dans nos 2 métiers ! Car même si c’est une tâche rébarbative qui pardonnez moi l’expression nous saoule profondément (comment ? Il y a des masos dans la salle ?), nous avons le même plaisir et la même fierté à voir un travail propre et bien fait (hum, enfin…Quand on nous laisse le faire 🙂 ).

Pour un extraterrestre tu passeras

Qui n’a jamais ressenti ce grand moment de solitude, quand face à un chef de projet ou un commercial nous avons la même difficulté à transcrire en langage « humain » notre jargon technique, ou à expliciter nos idées.

Mais si, vous savez, quand ça donne quelque chose comme:

Non mais la modif est simple, je vais rajouter un chamfer sur les edges et faire un petit extrude sur cette face, le flow des polygones restera smooth en plus

Ou encore :

J’ai pris du retard sur ce ticket, parce que quelqu’un a force push sur le master. Quand on sait pas squash ses commits ou faire un rebase proprement, le push force est INTERDIT ! Maintenant il va falloir que je check le ref log…

Mais au-delà de nous ressembler nous sommes aussi complémentaires !

Il y a un schéma qui se reproduit régulièrement (systématiquement en vérité :P) dans les relations développeur / graphiste en cas de bugs dans une application :

C’est toujours, TOUJOURS la faute du graphiste.

Et quand un graphiste a l’audace de trouver un bug, on lui soutient mordicus que ce n’en est pas un.

Mais dans le fond, malgré tout, nous avons besoin l’un de l’autre.

Le développeur est utile au graphiste pour lui créer de nouveaux outils qui lui feront gagner du temps, un nouveau shader, un outil de check….
Mais il n’oubliera pas les commentaires rédigés pour être compris par un enfant de 7 ans, ou les boîtes de dialogues intempestives qui pop à chaque erreur avec un petit message fleuri et poétique.

De son côté le graphiste a un œil extérieur sur le travail du dév et sera capable de l’épauler dans la création de nouvelles features, ou pour réfléchir aux problèmes techniques.

Il pourra également servir de Rubber Duck Debugger, une oreille attentive quand le dév vient rager sur son soit disant bug « fantôme » et lui faire trouver la solution, sans parfois même ouvrir la bouche (si si je vous jure).

Au-delà du travail, nous rions aux mêmes blagues de geek, avons de longs débats sur quel casque de réalité virtuelle est mieux que l’autre ou encore comment ce studio a pu sortir un jeu aussi mal fait, mon Dieu mais regarde moi ces textures et cette tesselation !

Vous voyez que nous ne sommes pas si différents que ça ! Alors la prochaine fois que vous croisez votre dév / graphiste préféré au bureau ou à la machine à café,  n’oubliez pas de lui rappeler à quel point vous l’aimez 😀