IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un ingénieur propose un guide de bonnes pratiques aux développeurs juniors
Afin qu'ils puissent rapidement trouver leurs marques en entreprise

Le , par Stéphane le calme

224PARTAGES

13  0 
Quelles sont les meilleures pratiques qu'un développeur junior devrait avoir ?
Quitter son écran pour essayer de visualiser sur papier
75 %
Reconnaître qu'il n'a pas la science infuse et demander de l'aide
73 %
Prendre des notes
56 %
Partir du principe que ce qui semble compliqué ne l'est pas forcément
35 %
Se lancer à la chasse aux bogues
27 %
Autres (à préciser en commentaires)
2 %
Voter 48 votants
Être un développeur junior peut sembler effrayant : la peur de mal faire, de ne pas être à la hauteur. Il arrive que le stress soit si prononcé que même les notions les plus basiques ressemblent à des tâches dignes de figurer parmi les 12 travaux d’Hercule. Aussi, Per Harald Borgen, un ingénieur logiciel, a proposé de partager quelques points de son vécu qui pourraient s’avérer utiles pour les développeurs juniors.

Acceptez vos lacunes et demandez de l’aide : tout d’abord, il est important de réaliser que vous avez de nombreuses lacunes dans votre base de données de connaissance et qu’il n’y a pas de raison de les cacher. Alors, ravalez votre fierté et demandez de l’aide si le besoin s’en fait ressentir. Si vous ne le faites pas, vous allez perdre trop de temps à cogner votre tête contre le mur. Selon lui, c’est l’une des raisons pour lesquelles il y a des développeurs seniors : pour aider les juniors.

« Je n’ai eu d’autres choix que de poser des questions d’entrée de jeu » va-t-il confier, expliquant que « dès mon premier jour à Xeneta, j’ai eu un MacBook Pro et j’ai eu comme consigne d’effectuer une installation système conformément au fichier LISEZ MOI ». Bien qu’il était habitué à la plupart des étapes qui lui étaient suggéré (créer une instance Ubuntu sur une machine virtuelle, configurer et utiliser un ssh, cloner le dépôt, installer les paquets, vérifier que toutes les configurations sont correctes, lancer le serveur), « je me suis planté magistralement. Alors j’ai du demander de l’aide encore et encore, autrement j’aurais perdu des semaines sur cette installation ».

Prenez des notes : même si certains des collègues plus anciens peuvent se montrer ouvert aux questions, répéter les mêmes questions encore et encore est à éviter. Aussi, Borgen recommande de noter des solutions, ce qui peut s’avérer utile la prochaine fois où vous faites face au même problème ou a un problème similaire. « Il n’y a aucune question stupide. Mais si vous avez déjà posé la même question avant, elle deviendra stupide la seconde fois que vous la posez ».

Partez du principe que des fois cela semble plus compliqué que ça ne l’est en réalité : pour Borgen, c’est un principe qui s’applique au développement logiciel en général ; moins vous en savez sur le sujet, plus il semble compliqué et effrayant. « Prenez AJAX par exemple. Lorsque j’ai commencé à coder, je me souviens que je pensais que JavaScript Asynchrone et XML étaient des procédures bien compliquées. Pourtant, dès lors que j’ai compris qu’AJAX est simplement une technique pour faire communiquer les sites web avec les serveurs, ces notions sont devenus un peu plus abordable. Et une fois que je les ai implémenté pour la première fois, j’ai compris ce que les gens voulaient dire lorsqu’ils assuraient que c’est facile ». Aussi, il recommande de ne pas se laisser submerger par la peur de ce qu’on ne connaît / maîtrise pas.

Si c’est trop complexe, visualisez le : bien qu’il y a de nombreux sujets qui sont plus simples qu’il n’y paraît, en revanche, dans l’ingénierie logicielle, plusieurs autres sujets sont difficiles. Des sujets qui demandent beaucoup de temps et d’efforts pour être assimilés. « Il peut arriver que vous ayez l’impression que quelque chose est trop compliqué, peut-être parce qu’il y a trop de valeurs, classes et fonctions qui interviennent et que vous n’arrivez pas à suivre. La meilleure façon que j’ai trouvé pour aborder ce problème c’est de visualiser en m’armant d’un stylo et d’une feuille de papier ». .

Mettez-vous à la recherche d’un maximum de bogues : Borgen encourage cette procédure, expliquant que « bien que ça soit marrant de créer de nouvelles fonctionnalités, ce n’est pas nécessairement le meilleur moyen de se faire la main sur un large code base. Pour ce faire, il faut aller à la chasse aux bogues qui va vous obliger à vous plonger dans le code base ». Il estime que c’est le meilleur moyen de se familiariser avec l’architecture d’une application, « ce qui est très important pour pouvoir passer au niveau de la productivité ».

Source : billet Borgen

Et vous ?

Qu'en pensez-vous ? Quelles sont les meilleures pratiques qu'un développeur junior devrait avoir ?

Voir aussi :

Un ingénieur raconte comment s'est passé son entretien technique au téléphone chez Google pour le poste de directeur de l'ingénierie

Trolldi : pourquoi les incompétents se croient-ils géniaux ? Avez-vous déjà rencontré ce cas de figure dans votre travail ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de joublie
Membre confirmé https://www.developpez.com
Le 14/11/2016 à 23:16
Un crayon et une feuille de papier peuvent parfois faire gagner un temps étonnant, surtout si l'agacement est venu s'installer à cause de bogues récalcitrants... Papier et crayon sont une manière de se reconcentrer sur la résolution d'un problème, alors qu'à première vue ils semblent être seulement une manière de traiter la complexité. Si ça se trouve, prendre des pauses régulièrement est encore plus efficace.
6  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 10/05/2017 à 16:42
Et si les gens acceptaient que chacun ait ses avantages et ses inconvénients ?

[ceci est bien sûr une carricature]

  • Un jeune dev est plein d'entrain, il croit toujours que tout est simple, il est prêt à tout essayer, à passer sur la dernière API en Béta que-même-le-développeur-il-dit-de-pas-l-utiliser, etc....
  • Un vieux dev est blasé, il voit le mal dans chaque nouveauté qui n'est pas éprouvé, il chiffre toujours en prenant en compte les murs qu'il ne manquera pas de rencontrer, ...


Donc il faut absolument les deux : un jeune pour avancer et prendre quelques nouveautés, et un vieux qui te fera un chiffrage correct dessus, et apportera son expérience sur les écueils simples à éviter
4  0 
Avatar de Florian_PB
Membre averti https://www.developpez.com
Le 14/11/2016 à 9:48
Ne pas oublier les bonnes pratiques qu'il a pu apprendre à l'école, même si dans certaines entreprises elles ne sont clairement pas respectées (dont la mienne) cela lui offrira forcément une méthode de travail lui permettant d'avancer.
Et surtout si jamais il a besoin d'aide aller voir sur dvp.com car quelqu'un aura forcément eu un problème similaire à lui et il y aura toujours une âme charitable pour l'aider.
2  0 
Avatar de 7h0m45
Candidat au Club https://www.developpez.com
Le 09/05/2017 à 12:45
Bonjour,

Merci à tous pour vos témoignages et conseils, ils sont très utiles.

Je voulais soulever un point, qui m'agace lors de ma mission et qui vient principalement de mon manque d'expérience.
(Ingénieur consultant étude et dev depuis maintenant 1 an, dont 6 mois dans ma mission actuelle où je travaille sur de plusieurs langages de programmation qui s'échangent des données (sql, lua, xml, javascript, python).)

Je suis tout seul dans une équipe de techniciens à faire de la programmation, et mon rôle est de faire de l'automatisation de tests (procédures de tests manuelles existante (ou non) à comprendre et programmer en utilisant différents outils spécifique à l'entreprise.
Il n'y a pas de "cadre": cycle en V, agile, ou autre organisation qui m'aiderait à me structurer dans ma façon de coder.
(du coup je fais de l'agile avec moi même, et nous réfléchissons ensemble à la meilleure solution).

Mes questions sont les suivantes :

Comment "bien" évaluer la quantité de temps nécessaire au développement d'une fonction ? (ou un standard sur lequel tout le monde se met d'accord, ie tempsDeDeveloppementRéflechit * facteurDebug = tempsAnnoncéAuChef ?)
Comment faire comprendre à son chef (qui n'est pas du tout "sensible" au fonctionnement de programmes) qui est motivé par un résultat, que la simple fonction demandé ne l'est pas du tout, et qu'il vaudrait mieux "coder proprement" que de créer des POC qu'il présente ensuite comme version finale?

J'aimerai par exemple pouvoir prendre le temps de faire des tests unitaires, qui me permettrait dans 1 mois ou 2, de pouvoir capitaliser sur certaines fonctions, plutôt que de réaliser des prototypes de programmes sur lesquels je m’appuie pour des développements ultérieurs.
Je n'ai simplement pas le temps (ou les compétences pour aller plus vite), de les mettre en place, et je n'arrive pas à lui faire comprendre qu'un jour, je ne serai plus là, et que ça risque d'être moins drôle pour le consultant suivant.
(un exemple parmi d'autres)

En espérant ne pas avoir dis une grosse bêtise.
Très bonne journée

Thomas *PremierPost
2  0 
Avatar de hbomb
En attente de confirmation mail https://www.developpez.com
Le 15/11/2016 à 9:22
J'irai un peu plus loin et j'appliquerai les mêmes principes pour les développeurs de manière générale qui change de société.

Il faut se faire aux outils, aux pratiques en place qui peuvent être totalement différentes d'une société à une autre. Je parle en connaissance de cause, après 10 ans dans un même poste, j'ai changé pour une autre entité et même si globalement cela fonctionne de la même manière, il y a des spécificités que je dois apprendre et connaitre.
1  0 
Avatar de claudebueno
Membre régulier https://www.developpez.com
Le 19/11/2016 à 15:10
Ce sont de bons conseils surtout pour un autodidacte.
Le papier crayon sont souvent bien venus pour poser les choses quelque soit l'étape du projet.
1  0 
Avatar de Claude40
Membre actif https://www.developpez.com
Le 18/11/2016 à 10:30
Prendre des notes oui, mais les transférer le plus rapidement possible dans une petite base de données personnelle et s'en servir comme FAQ.
0  0 
Avatar de Robert_J
Membre à l'essai https://www.developpez.com
Le 19/11/2016 à 9:13
Sujet intéressant pour les jeunes, il ne faut jamais trop hésiter à poser des question. Se constituer une FAQ est également très judicieux et c'est l'occasion de se chiadier un petit moteur de recherche phonétique pour se débarrasser des fautes d'orthographes des textes et des questions
0  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 09/05/2017 à 14:49
salut à la louche pour évaluer le temps d'une tâche c'est pas forcément toujours évident...
si on fait toujours le même type de travail on peut l'évaluer sans trop se tromper.
Maintenant dès qu'une tâche demandée est plus complexe et sort de l'ordinaire eh bien oui logiquement il faut plus de temps..
0  0