Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Sondage : quels sont les conseils pour débuter en tant que développeur de logiciels ?
    Sondage : quels sont les conseils pour débuter en tant que développeur de logiciels ?
    Partagez votre expérience

    Existe-t-il une méthode universelle ou une méthode pratique pour réussir ses débuts en tant que développeur de logiciels ? Beaucoup de bouquins vont dans sens, mais chaque développeur finit par se faire son propre avis après quelques années d’expérience dans le domaine de l’ingénierie. En fait, il en vient à dresser une liste de quelques habitudes qui, d'après lui, permettent de grandir plus vite et de manière ciblée, et qu’il aurait aimé connaître dès ses premiers pas en tant développeur professionnel de logiciels. Voici une liste de règles recueillies dans la communauté.

    Lire au moins deux livres par an sur le génie logiciel

    Il y a un très grand nombre de livres de génie logiciel, et ce, dans un nombre très élevé de langages de programmation. Selon les personnes à l’origine de cette recommandation, chaque fois qu’ils ont donné de leur temps pour lire lentement et complètement un livre conseillé sur l'ingénierie logicielle, cela les a fait progresser. Il ne s’agit pas en effet de lire des bouquins pour se constituer un palmarès. Mais ils conseillent qu’en lisant, il faille prendre des notes, discuter des chapitres, griffonner des paragraphes, essayer des choses, et si possible revenir en arrière pour relire certaines choses.

    Dans le choix des livres, il faut éviter les livres datés et surtout, vous devez rechercher des livres qui vont plus loin que ce que vous savez maintenant. Il peut s'agir d'un bouquin sur une technologie spécifique ou sur les pratiques du génie logiciel. Ils déconseillent aussi de lire des livres via des blogues, des vidéos, etc. Selon eux, ces canaux sont juste complémentaires aux livres. Ils sont des formats courts qui parcourent la surface, contrairement à un livre qui va en profondeur. D’après eux, les livres sont des connaissances approfondies et bien organisées. Enfin, il y a une dernière étape.

    Elle consiste à rédiger des critiques sur un livre une fois que vous avez fini de le lire. Cela vous aide à développer votre sens critique, mais aussi vous permet de trouver d’autres alternatives à la résolution d’un problème, qui peuvent parfois se révéler meilleures que les conseils du livre. Notez bien, il ne faut pas être ambitieux, un seul livre tous les six mois suffit.

    Apprendre le langage que vous utilisez au bureau en profondeur, vraiment en profondeur

    Pour ceux qui recommandent cette approche, plusieurs développeurs n’ont qu’une maîtrise partielle des langages qu’ils prétendent connaître ou ne les connaissent qu’en surface, ce qui n’est pas un avantage. D’après eux, connaître en profondeur le langage que l’on utilise au travail est l’une des meilleures décisions qu’un ingénieur peut prendre afin de donner un élan décisif à sa carrière. En outre, ils recommandent aussi de ne pas hésiter à plonger dans les langages très populaires, notamment ceux qui reviennent tous les ans dans le top 3 des index.

    Sur cette position qu’ils adoptent, ils estiment que, plus en connaissez et plus vous êtes à même de juger de leurs forces et de leurs faiblesses. De même, plus vous connaissez de langage et plus vous pouvez en choisir facilement de nouveaux et migrer plus facilement d’un langage à un autre.


    S'associer plus souvent à d’autres développeurs

    Le jumelage est-il aujourd’hui démodé ? Ceux-ci pensent que c’est le cas. Selon ces derniers, le jumelage contribue pourtant à donner naissance à de grands programmeurs. D’après eux, c’est cette approche qui donne lieu aux plus grands sauts professionnels, ajoutant que ces sauts se révèlent parfois plus significatifs que la lecture de n’importe quel livre. Ainsi, quand vous exposez vos idées sur un problème ou lorsque vous exposez votre code, requérez des commentaires, etc., vous apprenez beaucoup et vous devenez beaucoup plus performant avec le temps.

    Écrire des tests unitaires et les exécuter en CI

    Cette quatrième approche recommande d’écrire des tests unitaires et de les exécuter en CI (continuous integration - intégration continue). D’après ceux-ci, les tests unitaires permettent de sauver votre équipe d’ingénieurs et évitent que vous introduisiez dans votre code des erreurs graves, qui pourraient coûter cher à votre organisation. Ils permettraient également de se préparer à des changements majeurs à l’avenir.

    S'habituer au refactoring et maîtriser ses outils

    Le refactoring ou le réusinage de code est une technique disciplinée de restructuration d'un code existant, qui consiste à modifier sa structure interne sans changer son comportement externe. Le but est de faire une série de petites transformations qui préservent le comportement. Chaque transformation (refactoring) fait peu de choses, mais une séquence de ces transformations peut produire une restructuration importante. Comme chaque refactoring est petit, il est moins probable qu'il se produise des erreurs. Le système continue à fonctionner après chaque remaniement.

    Cela réduit les risques qu'un système soit gravement endommagé pendant la restructuration. Selon cette recommandation, s’habituer au refactoring vous aide à devenir un expert dans la réduction de la taille du code, dans l’amélioration des performances d’un système, y compris sa vitesse… Cela permet également de savoir extraire une méthode d'un code, renommer une variable, passer à une constante... Enfin, maîtriser les outils du refactoring consiste à avoir une parfaite connaissance de ses EDI et les extensions servant au refactoring que vous avez ajouté à ces derniers.

    Chercher à avoir beaucoup d’expérience

    L’on estime qu’une bonne ingénierie logicielle est le résultat de beaucoup d’expériences, vous devez donc en obtenir assez. La plupart des ingénieurs ont tendance à se laisser influencer par les séniors, car ces derniers ont l’air de tout savoir ou d’avoir réponse à tout. Selon cette recommandation, l’on peut remédier à cela en étudiant les profondeurs de plusieurs langages, en travaillant avec les autres ingénieurs, en recherchant des opportunités de travailler sur différents piles, domaines et projets stimulants. Il ne faut pas non plus avoir peur de changer d’équipe à mi-chemin d’un projet.

    En outre, ils recommandent aussi de se porter volontaire pour travailler sur de nouveaux projets et essayer de nouvelles technologies.

    Enseigner ce que vous apprenez

    Cette recommandation suit le dicton qui dit que : « la meilleure façon d’apprendre une chose est de l’enseigner ». L’approche consiste à parler de ce que vous apprenez ou ce sur quoi vous travaillez, en public devant d'autres ingénieurs et développeurs. La prise de parole en public vous oblige à correctement vous préparer, ce qui vous amène à étudier en profondeur les rouages de votre sujet de présentation. Cette approche est également connue sous le nom de “Learn in public”, et fonctionnerait très bien. Cela vous transforme en bon enseignant et mentor.

    Et vous ?

    Selon vous, quels sont les conseils pour débuter en tant que développeur de logiciels ?

    Voir aussi

    Sondage : l'échéance des tâches oblige-t-elle les ingénieurs IT à faire des heures supplémentaires gratuitement ? Partagez votre avis sur le sujet

    Sondage : quelles sont les pires erreurs à éviter dans le cadre d'un entretien d'embauche dans la filière informatique ? Partagez vos avis

    Sondage : quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ? Partagez vos avis
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent
    Des conseils un peu en bazar, tout de même. Certains sont fonction des habitudes de chacun (livre vs. recherches internet), d'autres sont spécifiques à un contexte (bureau vs. perso), méthodes (refacto, tests), généralités (expérimenter, enseigner).

    Seuls conseils généraux à prodiguer : pratiquez et trouvez ce qui vous plaît !

    Pratiquer permet d'une part de renforcer l'expérience et donc gagner en rapidité, et d'autre part de découvrir de nouvelles choses et donc d'augmenter les chances de trouver des choses qui plaisent. Une fois qu'on a trouvé ce qui nous plaît il faut se focaliser dessus et pratiquer, encore et toujours, en essayant de se mettre dans une situation qui permette de le faire et d'obtenir des retours constructifs sur ce qu'on fait. Dès lors qu'on a la motivation pour s'améliorer, la situation qui le permet, et qu'on pratique dans ce sens, le reste vient tout seul.

    Dans la liste, les deux seuls que j'appuie clairement sont donc avoir de l'expérience et enseigner ce qu'on apprend (plus généralement présenter sa façon de faire). Peu importe le contexte, pratiquer et partager ses connaissances permet de se forger. S'associer à d'autres dévs va dans le même sens que l'enseignement, mais ça peut se faire de bien des manières (pair/group programming au bureau, contributions aux projets open source, projets persos avec des connaissances) et il y a des tas de raisons pour que ça ne marche pas (personnes laxistes, tendance à suivre l'avis du groupe, etc.). Il ne faut pas s'associer à des développeurs en vue d'obtenir des connaissances (ça arrive souvent mais pas forcément tout seul), mais plutôt dans l'objectif de proposer des solutions nous-même qui pourront être challengés par les autres. A contrario, l'expérimenté profitera plus de ce genre de pratique en laissant les autres proposer des solutions et les challenger en posant les questions qui vont bien.

    Lire des livres, c'est bien quand on a ce qu'il faut pour en avoir et pour en lire. Mais l'important est surtout de savoir chercher l'information, et internet suffit bien. C'est d'ailleurs le plus à même de recommander des livres le cas échéant, mais sinon partir d'une page Wikipédia et parcourir les liens, y compris les liens externes amenant à des sites spécialisés, ça aide déjà beaucoup. Les livres sont une source d'information parmi d'autres, complémentaires.

    Apprendre le langage en profondeur, à prendre avec des pincettes. Je n'utilise pas qu'un seul langage dans mon boulot, et je ne vais certainement pas tous les creuser à 100%. Par contre, quand on cherche à résoudre un problème, il est important de réfléchir par soi-même à comment on le résoudrait avec ce qu'on connaît déjà (et à accepter qu'on n'en sait rien si c'est le cas), puis chercher (e.g. demander aux collègues, internet) comment d'autres l'ont résolu dans le langage qui nous intéresse. Il faut ensuite mettre en pratique ce qu'on a trouvé pour confirmer que ça fait bien ce qu'on a lu, jouer avec pour confirmer qu'on a bien compris comment ça fonctionne, et prendre la solution qui satisfait le mieux notre besoin parmi ce qu'on a trouvé.

    Cette notion de challenger ce qu'on a compris et ce qu'on a fait est à la base de l'amélioration. C'est en confrontant nos connaissances à des cas pratiques qu'on les confirme ou les corrige, augmentant ainsi leur quantité et leur qualité, et donc notre expertise. Les tests unitaires partagent ce point : il s'agit de confirmer qu'on a bien fait ce qui est attendu. Les préserver dans une CI permettra de ne pas régresser.

    S'habituer au refactoring fait partie de l'amélioration continue. Il est important d'avoir à l'esprit qu'on fait rarement (jamais ?) bien du premier (deuxième, troisième...) coup. Les méthodes agiles ne sont pas populaires pour rien : dans un domaine où on découvre les besoins au fur et à mesure, il faut (i) faire au mieux avec les infos du moment et (ii) revenir dessus quand c'est nécessaire. Le refactoring est cette étape intermédiaire qui permet de préparer (ii), sans quoi le jour où on revient dessus on ne comprend plus rien et il faut tout refaire.

    Donc conclusion : pratiquez et trouvez ce qui vous plaît !
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  3. #3
    Membre expérimenté
    Les sites web il faut savoir faire le tri, il y a énormément d'articles type medium ou quora ou les mecs te font un historique de l'informatique pour conclure un truc bateau et en effet c'est une perte de temps. Par contre il y a des pépites, personnellement j'ai énormément appris en lisant le blog de Martin Fowler que je recommande chaudement (pour les anglophones).

  4. #4
    Expert éminent
    Citation Envoyé par Mrsky Voir le message
    Les sites web il faut savoir faire le tri
    Ça fait partie de l'expérience. Il y a les classiques, comme StackOverflow, il y a les spécifiques, comme Baeldung pour Java et Spring, il y a les auteurs de renom, comme Martin Fowler ou oncle Bob, etc. Une bonne partie dépendra des intérêts de la personne, donc oui faut faire le tri mais on atteint vite les limites des recommandations.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  5. #5
    Expert éminent sénior
    Citation Envoyé par Bill Fassinou Voir le message

    Le jumelage est-il aujourd’hui démodé ? Ceux-ci pensent que c’est le cas.
    qui affirme cela ?
    La double lecture de code source sur un projet c'est une quasi obligation.
    Une personne qui est expérimentée repère très vite des erreurs.
    Citation Envoyé par Bill Fassinou Voir le message

    Enseigner ce que vous apprenez
    c'est bien pour cela que dans certaines entreprises à l'anglo-saxonne est organisé en interne des "master-classes"
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  6. #6
    Membre éclairé
    Personnellement, les trois plus gros problèmes à résoudre que je constate chez la majorité des dev juniors sont :


    • Apprendre à prendre son temps : Trop souvent, le Dev va vouloir répondre à un problème en copiant la première solution trouvée sur le net et passer à autre chose. De la même manière, je vois souvent des dev ne pas lire les stackstrace et juste copier-coller les solutions StackOverflow en boucle en espérant que cela va fonctionner. Chaque solution demande d'être comprise et testée pour être implémentée correctement. Et cela est formateur. Coper-coller du code, n'apporte rien. Il faut donc prendre le temps de lire en détail la documentation du langage/framework pour comprendre comment il marche et quelles sont ses fonctionnalités.
    • Apprendre à définir ou va quoi : Je vois trop souvent des problèmes parce que les rôles des composants/classes ne sont pas respectés. La vue qui fait des appels BDD, un couplage fort entre chaque composant, etc. Savoir qui fait quoi et comment séparer les composants en réduisant les adhérences est pour moi fondamental. Pour cela Uncle Bob en parle très bien.
    • Maitriser son environnement de dev : Je vois trop de développeurs utilisant leurs IDE comme un bloc note ou ne maitrisant pas git, ne sachant pas la différence entre un rebase ou un merge. Dans le premier cas, c'est une perte de temps. Dans l'autre, un manque d'autonomie pour le travail en équipe.


    Une fois cela maitrisé, le Dev est à mon sens quelqu’un d'autonome sur qui je peux me baser pour travailler. Le reste viendra tout seul avec l'expérience. Mais si le dev ne maitrise pas cela rapidement ( ~1-2 ans max ), sa carrière va en prendre un sacré coup.

  7. #7
    Membre expérimenté
    Expérience et passion
    1) La première nécessité c'est d'aimer l'informatique et la programmation.
    2) Ce choisir 1 langage de prédilection assez simple si possible mais structuré et utile aujourd'hui comme demain. Ne pas se limiter au langage du bureau (VB n'est pas un bon langage). Je conseillerai Python ou mieux Julia. Toutefois, si on a un besoin, c'est évident que l'on va choisir le langage de ce besoin même si ce n'est pas le meilleur pour commencer car c'est ce projet qui nous motivera.
    3) Il faut apprendre par soit même avec des tutoriel sur internet. Investir dans des cours ou même un livre est un très mauvais plan au départ. Ce serait trop abstrait. Faire des programme encore et encore est vraiment utile. Se renseigner auprès de quelques développeurs si possible.
    4) C'est dans après avoir pris goût et avec une connaissance de base que l'on peut s'acheter un livre pour comprendre les concept informatique et appréhender les subtilité du langage que l'on connaît un peu.
    5) Pour approfondir un peu il est bon d'aller dans un programme Open-Source et d'essayer de le comprendre voir mieux d'y contribuer.
    6) Une fois que l'on a commencé avec un langage un peu "facile" (Python, Julia, JavaScript) on peut aller vers un langage plus efficace et plus complexe (Rust, C/C++). C'est une étape importante si l'on veut vraiment faire du développement de manière professionnel (même si on ne se destine pas à une carrière de développeur bas niveau).
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  8. #8
    Membre expérimenté
    Citation Envoyé par scandinave Voir le message
    Personnellement, les trois plus gros problèmes à résoudre que je constate chez la majorité des dev juniors sont :
    Oui mais ça ce n'est pas pour apprendre à développer. C'est vrai une fois que tu connais l'informatique, pour devenir un bon dev.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  9. #9
    Membre expérimenté
    Créer un programme et le maintenir pendant au moins quelques mois en l'améliorant me semble être un bon conseil pour débuter, et peu importe le programme que ce soit un driver d'imprimante ou un front web. L'idée c'est de découvrir le cycle de vie d'un programme par l'expérience : design, architecture, implémentation, versions, tests, etc.

    Devoir mettre à jour un programme met en lumière l'utilité des tests et de l'importance d'un code bien organisé et pas inutilement complexe. Quel débutant n'est pas tombé dans le piège d'une solution élégante et super dynamique qui gère tous les cas, sauf celui qui doit être implémenté dans 6 mois parce qu'on y avait pas pensé, et qu'il faut changer une grosse partie du code ?

  10. #10
    Membre éclairé
    1) faire preuve d'humilité. On n'est pas parfait, on commet des erreurs: et certains de nos collègues ont une meilleure connaissance/expérience que nous.
    2) ne jamais arrêter d'apprendre: l'informatique évolue vite, il ne faut pas rester à la traîne
    3) ne jamais mettre tous ses oeufs dans le même panier. Il faut connaître plusieurs langages :
    • un langage performant et vendeur: Java, C# ou C/C++
    • un langage qui sert à tout: comme Python
    • un langage ayant de l'avenir: style Rust qui pourrait remplacer C ou C++

    4) avoir l'esprit critique: percevoir les qualités et les défauts des codes que l'on lit (les siens ou ceux des autres); cela permet d'apprendre et de s'améliorer.

  11. #11
    Membre éprouvé
    Apprendre un langage en profondeur. Mais c'est un peu hardcore je trouve, surtout pour débuter. Quand on debute on devrait commencer petit. J'ai vu des seniors qui étaient nul dans leur langage informatique qu'il utilisent au quotidien alors pourquoi on demande a des développeur débutant sa.

    Je lui conseillerais d'abord de faire des petits choses pour éveiller sa curiosité et sa logique.

    Aussi con soit-t-il, je lui conseillerais le web. Il peut commencer avec des cours en ligne sur Udemy, sur Skillshare, sur Microsoft learning, sur Open Classroom. Les cours sont bien fait je pense si on est bon en anglais. Commencer par HTML, CSS et Javascript. Le web c'est très facile, il suffit juste d'un notepad et d'un navigateur, le seul truc qu'on peut faire sur un chomebook.

    Apres 1 - 2 mois, qu'il a construit un peu sa logique, manipuler les outils. La on peut aller dans le hardcore. Pour les développeur web, je préconise un freecodecamp. Pour les développeur d'applications lourd c'est de suivre un cours sur Udemy (j'ai pas trouver plus simple et complet en meme temps).

    Oublier les bonne pratiques, oubliez les choses hardcore, codez juste des trucs pour l'instant. C'est comme ca qu'on commence. On bidouille d'abord et on se perfectionne ensuite. Évangélisez-vous quand vous aurez de la bouteille, de l'experience en code et en travail. Par contre ce que j'aurais voulu savoir quand j’étais débutant c'est que le langage d'expertise va determiner son avenir donc choisissez bien, migrez a 360 degrés dans les technologies coûtent en temps et investissement surtout que tous les eco-système sont maintenant gigantesque.

    Il y a pas de langages meilleurs que d'autres mais seulement des technologies qui sont rechercher localement. Surtout consolider les bases qui sont les types de variables, if/else, while/for/do (notions de boucle et d'iterations), les fonctions (sa c'est précieux), les classes et objets. Apprendre les patterns connues comme MVC, Component Style, MVVM, ce sont des styles que vous retrouvez dans les frameworks web, logiciel qui vont avoir de l'influence sur la structuration de vos projets. Je pense que ces bases sont pas mal et permet déjà des bases pour trouver un boulot. Apres je ne suis pas recruteur, si je devais recruter, je ne demanderais que ces bases. Mais le marche est dure et veulent des moutons a 5 pattes surtout en France.

    Donc maîtriser les technos d'un seul langages après avoir conquis ces bases après avoir conquis les bases.

    Et prenez juste conscience que l'informatique est gigantesque, car je ne vous ai pas encore parler de base de données, et de design pattern et d'analyse d'un besoin, de cloud, de big data, d'AI, ... Devops, ... Ah, je vous ai parle des softskills qui faut avec ... Vous inquiétez pas, vous débuter. J'ai déjà enseigne a des débutants et l'informatique peut être simple ou mega-dure selon le profil, je conseillerais de se faire guider si possible par un mentor dans des cas de doutes. Par exemple, sur les cours ne lignes, il y a des communautés, je prends par exemple freecodecamp qui a discord qui permet de se faire évaluer ces projets, n’hésite pas a voir ces communautés qui vont te donner des feedback que ce soit ton projet web ou ton logiciel. Les feedbacks sont important pour avancer et les communautés sont nombreuses.

    Si tu as le syndrome de l'imposteur a moment donne, tu n'es pas le seul.

    Ah surtout être développeur de competition ne te mene pas a l'emploi directement. Focus ton attention sur les projets qui sont plus parlants. Surtout ne croit pas tout les youtubeurs, passe plus de temps sur le code que leur postcast ou chaine youtube/twitch.

    Lis la doc officiel avant et va ensuite sur stackoverflow si trouve vraiment pas et dans le dernier des recours n’hésite pas poser des questions (issues) sur le projet github de la technologie que tu utilises.

    Voila ce que je dirais a un débutant, commencer par du web et ensuite passer a du C# winform, tout simplement. Plus simple est le debut, plus loin est l'apprentissage.

  12. #12
    Expert éminent sénior
    Les miens?
    Apprenez à découvrir ce que veux le demandeur, et à lui faire confirmer.
    Vous n'imaginez pas à quel point lui-même ne le sait pas vraiment. Quand il demande quelque chose, c'est parce qu'il pense que ca facilitera ce qu'il veut vraiment faire. C'est ce vraiment qu'il faut comprendre, pour pouvoir y répondre convenablement. Le demandeur s'imagine avoir des connaissances sur le code, ou en expérience utilisateur. C'est votre métier, pas le sien.

    Lisez la documentation.
    De chaque outil, chaque commande.
    Vous imaginez un boulanger qui ne saurait pas régler son four?
    Vous devez savoir à quoi sert chaque option, chaque paramètre que vous utilisez. C'est spécialement vrai pour le compilateur (ou l'interpréteur), et le gestionnaire de version (git), mais aussi pour grep, sed, jira, jenkins ou gitlab. En fait, chaque outil.

    Apprenez à ralentir.
    Le mieux est peut-être l'ennemi du bien, mais il ne faut pas non plus confondre vitesse et précipitation.
    Ne négligez pas la qualité.

    Ne généralisez pas à outrance.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  13. #13
    Membre habitué
    c'est toujours le même conseil
    pour les débutants mon conseil, c'est de pratiquer en s'amusant, sur un objectif concret: un programme ou un service que vous utiliserez vraiment.
    Le reste viendra tout seul.

    Et surtout n'attendez personne, n'attendez pas de faire des études ou d'avoir un diplome, n'attendez pas de savoir ceci ou cela,
    n'attendez pas que qqn vienne vous dire que c'est bien ou mal ... juste faites le.

  14. #14
    Membre régulier
    Pour débuter on m'a proposé de faire des applications style calculatrice, jeux pendu etc... J'ai trouvé ça nul, je voulais rendre service, donc j'ai demandé à des collègues leurs contraintes et j'ai regardé comment y répondre via une app ou juste un script, je trouve cela beaucoup plus formateur que de faire des app que personne ne verra-jugera

  15. #15
    Membre éprouvé
    pour moi, seulement 2 conseils :
    - aimer ce qu'on fait
    - comprendre en profondeur chaque ligne qu'on ecrit

  16. #16
    Responsable
    Office & Excel

    Salut.

    il me semble que l'on mélange deux trucs qui n'ont pas grand chose en commun: Développeur de logiciels et programmeur. Ici, je lis plein de conseils sur "devenir un bon programmeur" (commencer petit, utiliser tel langage plutôt que tel autre) sans de réels arguments techniques pour étayer ses dires.

    Débuter en tant que développeur de logiciels ne veut pas dire développer en programmation. La programmation, c'est une partie du développement du logiciel, et dans cette partie, l'écriture de code, surtout si on s'appuie sur des frameworks, constitue une part de plus en plus petite du boulot.

    Lire "il vaut mieux commencer par le web" ou "le VB est un mauvais langage" sans aucun argument technique me donne plutôt envie de passer à un autre sujet.


    Citation Envoyé par epsilon68 Voir le message
    pour moi, seulement 2 conseils :
    - aimer ce qu'on fait
    - comprendre en profondeur chaque ligne qu'on ecrit
    100% d'accord avec ces deux assertions! Et encore, car c'est vrai pour "le codeur", mais développer un logiciel, ce n'est pas que coder. Il faut comprendre, en profondeur, le besoin de l'utilisateur, connaître plusieurs techniques pour se diriger vers celle que l'on pense être la meilleure pour résoudre les problèmes de l'utilisateur grâce au logiciel que l'on développe, etc.

    Dès lors il faudrait définir d'abord ce qu'est un "développeur de logiciels". Quelqu'un qui adapte un wordpress, c'est un développeur de logiciel? Quelqu'un qui utilise Symfony, c'est un développeur de logiciel? Quelqu'un qui personnalise une "plateforme Odoo", c'est un développeur de logiciel?

    Dans une ancienne vie, j'étais boulanger. J'ai appris à faire du pain, des éclairs au chocolat, de la crème pâtissière, de la pâte feuilletée... Aujourd'hui (enfin, depuis au moins 35 ans), on peut réaliser tout cela sans être boulanger. Il suffit d'acheter des "mix" et de suivre le mode d'emploi (mélanger 200 gr de poudre avec un litre d'eau froide, mélanger jusqu'à ce que ça épaississe et hop, on sait "faire" de la crème pâtissière. Sortir les croissants congelés, les laisser lever, les cuire et hop, on sait "faire" des croissants, etc). C'est pareil en informatique. On trouve des créateurs de "sites web Wordpress" qui sont des presse-boutons (en plus, il vous le facture bien cher), on crée des "applications" en quelques clics et on se dit "développeur de logiciels".

    Pourrait-on définir ce qu'est "un développeur de logiciels"?

    Pour moi, le "développeur de logiciels" doit répondre à deux questions:
    • Quels sont les besoins de l'utilisateur?
    • Mon logiciel facilitera-t-il la vie de l'utilisateur pour répondre à ce besoin?



    Et ça n'a que très peu avoir avec tel langage, telle techno, lire x livres par mois, ...
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Une fois pour toutes, je donne mon avis. Je ne vais pas le répéter à chaque message...
    Si je propose une solution générique sur votre solution spécifique, c'est parce que, fainéant de nature, je privilégie le réutilisable...
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  17. #17
    Expert éminent
    Le plus important, comprendre que l on ne confiera jamais un probleme neuf a un junior, donc des solutions existent déjà. Le bon dev, quelque soit son niveau cva estimer plusieurs solutions et choisir celle qui est la plus pertinente.

    Un dev à qui on demande d ouvrir un serveur ftp et qui commence à le coder n à pas sa place dans mon équipe. Qu il y arrive ou pas.
    Celui qui me développe depuis 0 des lib python de base non plus.

    Bref, ayons tous dans notre métier l humilité de reconnaître que 99% des problèmes ont été résolu pas des gens plus intelligent que nous et essayons de comprendre les solutions possible et comment les départager. Sans prétendre faire mieux.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev senior python / Cloud sur Toulouse sud.
    Nous diffusons de la presse digitale à bord des avions avec les plus beaux partenaires !

    Envoyez moi un mp

  18. #18
    Nouveau Candidat au Club
    Citation Envoyé par pmithrandir Voir le message
    Le plus important, comprendre que l on ne confiera jamais un probleme neuf a un junior, donc des solutions existent déjà. Le bon dev, quelque soit son niveau cva estimer plusieurs solutions et choisir celle qui est la plus pertinente.

    Un dev à qui on demande d ouvrir un serveur ftp et qui commence à le coder n à pas sa place dans mon équipe. Qu il y arrive ou pas.
    Celui qui me développe depuis 0 des lib python de base non plus.

    Bref, ayons tous dans notre métier l humilité de reconnaître que 99% des problèmes ont été résolu pas des gens plus intelligent que nous et essayons de comprendre les solutions possible et comment les départager. Sans prétendre faire mieux.
    Pas d'accord, c'est le meilleur moyen de ne pas comprendre les différents modules utilisés, et le jour où la lib nest6plus maintenue tu fais comment ? Tu attends que les gens plus intelligents sortent une nouvelle lib ?

  19. #19
    Expert éminent
    Les deux arguments se valent : il est important de mettre les main dans le cambouis pour comprendre les détails, mais important de réutiliser l'existant pour ne pas "perdre" du temps. Un bon compromis étant d'utiliser une lib pour une fonctionnalité dont on n'a pas l'habitude, et mettre les mains dedans de temps en temps pour apprendre à la maîtriser et voir s'il faut la remplacer, la recoder le cas échéant.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  20. #20
    Expert éminent
    J'ai bien dit, lib de base.

    Vous les connaissez tous ces dev qui se croient plus malin que els autres, qui vont te pondre 10 jours de code pour refaire un truc mille fois fait dans le monde.

    En général, ca donne :
    - du code pourri
    - pleins de problématiques non prises en compte, une sécurité pas au niveau
    - du code à maintenir (a l'inverse d'une libraisie dont le code est maintenue pas la communauté).

    Pour ma part je n'ai pas souvent vu de lib utiles qui peurt. Et si on doit refaire, autant ajouter une pull request et faire avancer le projet communautaire plutôt que de faire sa tambouille dans son coin.

    De mon coté, peu m'importe que les mecs de mon équipe comprennent 100% du code des lib que l'on utilise. De toute manière, personne dan la boite ne maintiendra le code qu'ils auront pondu 5 ans plus tot...
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev senior python / Cloud sur Toulouse sud.
    Nous diffusons de la presse digitale à bord des avions avec les plus beaux partenaires !

    Envoyez moi un mp

###raw>template_hook.ano_emploi###