Que se passe-t-il si vous ne parvenez pas à résoudre un problème?
Je suis à un an de mon diplôme universitaire et j'ai vraiment hâte de résoudre des problèmes pratiques. Surtout non triviales qui nécessitent un peu de recherche et beaucoup de réflexion.
Mais en même temps, c'est aussi ma plus grande peur - être confronté à un problème que je ne peux pas résoudre, peu importe mes efforts. Et avec la pression de fournir du code dans les délais imminents juste au coin de la rue, cela semble un peu effrayant lorsque vous le regardez depuis les terrains de jeu sûrs sur uni (où la pire chose qui puisse arriver est que vous devez refaire un cours ou un examen).
Donc, pour ceux qui sont dans l'industrie depuis plus longtemps, que se passerait-il si on vous demandait de résoudre un problème que vous ne pouviez pas? Est-ce arrivé, et si oui, que s'est-il passé? Est-ce qu'ils l'ont juste laissé tomber et ont dit "Oh bien, je suppose que nous pouvons nous contenter d'autre chose"? Y a-t-il eu des conséquences? Avez-vous été réprimandé ou même renvoyé?
Tout d'abord, votre peur est très saine et normale. Voici mes réflexions après environ 15 ans dans l'industrie du logiciel.
Voici quelques questions à vous poser:
- comprenez-vous le problème?
- Savez-vous que le problème est insoluble (dans les limites de votre temps/budget)?
- Vous ne savez tout simplement pas comment résoudre le problème?
- Votre client/patron demande-t-il l'impossible?.
- Est-ce que ça vaut le coup? (ROI)
- Est-ce un problème RÉEL ?
1) Tout d'abord, assurez-vous de bien comprendre le problème. Il n'y a pas de questions stupides. Comprenez-vous ce que votre client/patron vous demande par rapport à ce dont il a besoin?
2) Cela se produira. "Construisez-moi un pont d'ici demain" . Assurez-vous de savoir avec certitude qu'un problème est insoluble dans les limites de vos contraintes. Votre client/patron peut être flexible sur le temps/budget et ceux-ci peuvent être modifiés pour vous donner plus de temps/budget.
3) Si le problème est compréhensible et que les contraintes sont raisonnables, et qu'il existe une technologie qui peut résoudre le problème, mais vous n'en savez tout simplement pas assez ... c'est à cela que StackOverflow et Internet sont destinés. Assurez-vous de faire vos recherches en premier. Essayez de poser des questions explicites qui ont des réponses quantifiables. Demandez à vos pairs. Organisez une session de conception.
4) Ceci est une variante de la réponse numéro 2. Il semble comme si votre client/patron demande l'impossible. Fais quelques recherches. Ne dites jamais que le problème est insoluble, sauf si vous savez exactement pourquoi et que vous pouvez clarifier.
5) ROI signifie Return On Investment. Il s'agit d'un investissement en temps. Ton temps!. Le problème est-il suffisamment important pour être résolu pour garantir le temps qu'il vous faudra pour rechercher et résoudre le problème? Discutez-en avec votre client/patron
6) Est-ce un vrai problème. Les clients comprennent souvent ce qu'ils veulent, mais ne comprennent pas nécessairement ce dont ils ont besoin. Essayez de comprendre ce dont votre client/patron a réellement besoin et discutez-en avec lui.
J'espère que ces directives vous aideront.
Deux choses à retenir si vous êtes coincé avec un problème apparemment insoluble:
Faites savoir aux autres que vous êtes coincé dès que possible. Cela les aidera à ajuster l'estimation à temps avant qu'il ne soit trop tard.
Si vous voyez qu'une façon de résoudre un problème ne fonctionne pas, laissez-la tomber avant d'avoir perdu trop de temps. Demandez de l'aide ou essayez une approche différente. Il ne s'agit pas de se montrer dur et intelligent, il s'agit de faire avancer les choses.
Je vais à StackOverflow ;)
Mais blague à part, ne craignez pas l'inconnu. Toute votre carrière sera confrontée à l'inconnu, car si vous l'avez déjà résolu, ce ne sera pas un problème la prochaine fois.
Je vais devoir aller avec une réponse simple: je demande de l'aide. Tout comme les autres me demandent parfois de l'aide lorsqu'ils sont coincés à essayer de trouver une solution à quelque chose.
Edit: je dois mentionner que je trouve souvent la solution simplement en décrivant le problème à un collègue, ou parfois même lorsque je commence à poster une question sur des sites comme StackOverflow.
Regardez sous différents angles
Je l'ai rencontré plusieurs fois, généralement ce qui se passe est:
- Vous avez un problème, vous avez d'abord une idée en tête comment le résoudre.
- Lorsqu'il s'agit d'implémenter réellement votre solution, il s'avère que cela ne fonctionne pas (probablement en raison du modèle faible du problème réel).
- Après avoir eu du mal à résoudre le problème, que ce soit plus de recherche ou demander aux autres. Rien de tout cela fonctionne, la pure frustration!
Enfin, vous optez pour ce que vous ne vouliez pas faire ->
"Le sale hack"
Cela fonctionne, mais vous vous sentez sale ...
Cela dépend de la raison pour laquelle vous ne pouvez pas ...
logiquement impossible: discutez-en avec celui qui a rédigé les exigences, il y a peut-être un malentendu. Exemple: à un moment donné, la spécification dit que l'application doit avoir l'air et se sentir native sur toutes les plates-formes (Windows/Linux/Mac), et à un autre endroit, elle dit que le programme doit être exactement identique sur toutes les plates-formes
techniquement impossible: réévaluez les outils avec lesquels vous travaillez, ils ne sont peut-être pas appropriés. Discutez du problème avec vos pairs et le chef de projet. Exemple: exigences en temps réel difficiles dans un environnement où la récupération de place peut arrêter l'exécution pour une durée indéterminée
performances insuffisantes: vous utilisez peut-être le mauvais algorithme ou le problème est trop difficile (par exemple NP-difficile) et les exigences ne prennent pas cela en compte. Réévaluez l'algorithme que vous utilisez, il existe peut-être un moyen plus rapide. Discutez du problème avec vos pairs et le chef de projet. Envisagez de passer à une heuristique suffisamment bonne au lieu d'un résultat parfait. Exemple: optimisation de chemin avec des dizaines voire des centaines de nœuds
vous ne savez tout simplement pas comment faire: demandez à vos pairs, demandez à stackoverflow, recherchez sur Internet. Contactez le support de l'outil/lib que vous utilisez. Discutez-en avec le chef de projet.
il devrait fonctionner, mais ne fonctionne pas, et vous n'avez aucune idée pourquoi: Refactorisez le programme pour le rendre plus testable. Tenez compte des conditions de concurrence, elles sont souvent à l'origine de bogues difficiles à trouver. Demandez de l'aide à vos pairs, quatre yeux en voient plus de deux. Vérifiez sur Internet les bogues connus dans les outils/bibliothèques que vous utilisez.
Habituellement, je reçois quelqu'un de plus intelligent que moi pour le réparer. Il le fait et c'est mon patron. Je me sens stupide. Nous continuons.
Je pense que d'autres personnes montrent bien comment y faire face de manière professionnelle. Je voudrais dire comment gérer le sentiment personnel comme la frustration, la peur.
En fin de compte, vous serez FINE même si vous ne résolvez pas les problèmes en temps opportun. La vie continue.
Parfois, le calendrier était repoussé. Le projet serait réussi ou échoué. Vous pouvez être renvoyé et avoir un excellent travail. On ne sait jamais.
Ne vous méprenez pas. Cela ne signifie pas qu'il est OK de laisser le problème persister. Tout ce que nous pouvons faire, c'est faire de mon mieux et laisser tomber.
Parfois, je pense que la frustration, la peur de ne pas résoudre le problème est ma vie de développeur moyen.
Je ne suis pas sûr de dire que je n'ai pas pu résoudre un problème, mais il y a eu des cas où j'ai renoncé à essayer de résoudre un problème. Après avoir consacré de nombreuses heures à essayer de corriger un bogue ou d'implémenter une fonctionnalité dont je n'ai aucune idée de la façon de le faire, je peux dire à quelqu'un de mon équipe, chef d'équipe ou manager: "Je suis coincé là-dessus. voulez-vous que je fasse? " afin qu'ils sachent où je suis. Ils pourraient dire: "Continuez, nous pensons que vous l'obtiendrez" ou "Passez à autre chose qui n'est pas si important", ou quelques autres choses, puis je saurai ce que je dois faire.
J'ai eu des bugs que je n'ai pas résolus et certaines fonctionnalités qui n'ont pas été faites, bien sûr. Bien que je puisse essayer de faire quelque chose, tout n'est pas en mon pouvoir pour résoudre dans un délai raisonnable. Un point clé à cela est d'avoir une communication pour que vos supérieurs sachent où vous êtes.
Cela dit, j'ai eu quelques fois où j'ai rencontré des circonstances plutôt spéciales:
Pendant que je travaillais dans une grande banque canadienne à Toronto, on me demandait de faire toutes sortes de choses que je ne savais pas faire quand on me confiait la tâche. Par exemple, on m'a demandé de tester cette méthode pour sécuriser les ordinateurs portables où les touches "Esc" et "Entrée" ont été échangées au démarrage et avec la bonne séquence de touches, l'ordinateur portable serait à nouveau utilisable, ce qui semblait bizarre pour essayer de comprendre out, "Est-ce que cela fonctionnerait? Comment puis-je savoir que cela ne serait pas correct avec les utilisateurs?" Il y avait d'autres tâches que je n'avais tout simplement pas le matériel ou les autres ressources pour le faire. En même temps, c'était plutôt éducatif car cela m'a donné beaucoup de choses à noter sur toute future situation d'emploi pour éviter les ennuis. Des choses comme s'assurer quand je suis payé, comment mon temps est suivi, et d'autres problèmes de communication m'ont été illustrés avec beaucoup de détails que je n'ai pas vraiment oubliés.
Pendant que je travaillais chez un fournisseur de services d'application à Calgary, on m'a donné ce projet d'essayer de créer une copie d'un autre site Web dans notre application interne que nous avons vendu en tant que service. Un point clé ici est que je n'ai pas reçu de calendrier ni de suggestions sur la partie à faire en premier, juste des recherches générales et un mois plus tard, on m'a demandé une démo tout comme j'avais une mauvaise réaction à certains médicaments contre la douleur. Cette réaction a duré une semaine où j'ai soudainement arrêté de travailler, puis la semaine suivante, je suis allé à un événement Microsoft qui était en quelque sorte la dernière goutte, car j'ai été licencié le lendemain. Quelque chose à noter ici est la façon dont j'ai eu une relation plutôt mauvaise avec mon patron, car à chaque fois qu'il s'approchait de ma région, ma pensée immédiate était: "Maintenant, qu'est-ce qui ne va pas?" ce qui avait tendance à ne pas être une chose plutôt saine à avoir en réaction à quelqu'un plusieurs fois.
Comme d'autres l'ont dit, la communication est essentielle - faire savoir aux gens (qui seront touchés) quand vous êtes coincé: votre patron, les membres de l'équipe, les clients, etc.
Un collègue acharné m'a inculqué une fois que le succès a ses racines dans deux choses:
- Des relations
- Attentes
Avoir une bonne relation, je suppose, est fonction d'une bonne communication et de la définition des attentes.
Je suis le principe de Polya:
"S'il y a un problème que vous ne pouvez pas résoudre, alors il y a un problème plus facile que vous ne pouvez pas résoudre: le trouver."
George Polya
La beauté du principe est qu'à un moment donné, il y aura un problème suffisamment petit et que vous pourrez résoudre ce qui, espérons-le, si vous avez bien fait les choses, vous permettra de bootstrap une solution au problème d'origine. Ce principe ne m'a pas encore fait défaut.
Ma séquence de résolution de problèmes (chaque spet suivant est effectué uniquement si le précédent n'a pas fonctionné):
- Essayez de google
- Demande à quelqu'un
- Rechercher SO directement (en contournant Google)
- Pense
- Fumée (== tête claire)
- Poser une question sur SO
- Attendez jusqu'au matin (== tête claire encore plus)
- Utilisez ce hack sale et mal à l'aise :(
Les problèmes désagréables sont résolus aux étapes 5-6.
Les problèmes vraiment très graves nécessitent généralement un certain temps (l'étape 7 est LA solution à la plupart des problèmes qui semblent ne pas pouvoir faire quoi que ce soit). Et je le pense - passez à une autre tâche pour le reste de la journée et essayez de résoudre le problème dès le matin. Cela fait des merveilles.
Et alors seulement vient l'étape 8.
Les réponses " chercher de l'aide " sont définitivement correctes. Il est très peu probable que vous soyez la première personne à rencontrer un problème particulier.
Mais comme une expérience bien que, s'il n'y a pas d'aide? Et si vous devez résoudre le problème par vous-même? La capacité de résolution de problèmes la plus importante est la capacité de identifier et contester vos propres hypothèses . Si vous pouvez énumérer vos hypothèses sur un problème un par un et les éliminer à tour de rôle, vous finirez par tomber sur l'hypothèse erronée et de nouvelles possibilités de solution s'ouvriront en conséquence.
(Soit dit en passant, c'est également la meilleure approche lorsque vous ne voyez pas de réponse à un problème que vous rencontrez lors d'un entretien d'embauche. Énumérez verbalement vos hypothèses, déterminez laquelle est erronée, puis réattaquez le problème. Presque toutes les "questions pièges" sont basées sur des hypothèses naturelles mais erronées).
Demander de l'aide est vraiment la meilleure réponse, mais voici un peu plus qui peut être utile.
Donc, pour ceux qui sont dans l'industrie depuis plus longtemps, que se passerait-il si on vous demandait de résoudre un problème que vous ne pouviez pas? Cela s'est-il produit et si oui, que s'est-il passé? Est-ce qu'ils l'ont juste laissé tomber et ont dit: "Eh bien, je suppose que nous pouvons nous contenter d'autre chose"? Y a-t-il eu des conséquences? Avez-vous été réprimandé ou même renvoyé?
Oui, ça m'est arrivé, et non, je n'ai jamais été réprimandé ou renvoyé pour ça, parce que ...
Dans l'industrie, il s'agit de savoir si vous résolvez les problèmes à temps et dans les limites du budget, et les gestionnaires décents comprennent que ce n'est pas toujours possible.
Ce qui se passe vraiment, c'est que votre manager dit: "J'aimerais que vous fassiez X, que pensez-vous que cela prendra?" Et vous pouvez donner beaucoup de réponses. Les bons comprennent:
- J'ai fait quelque chose de vraiment similaire à cela, donc je pense que cela prendra trois semaines et 3 000 $ de tests de matériel.
- J'ai quelque chose de généralement similaire à cela. Alors laissez-moi y réfléchir et vous revenir cet après-midi.
- Je n'ai jamais rien fait de tel. Alors laissez-moi le rechercher et vous contacter demain.
- Personne sur la planète n'a jamais fait cela. Si vous voulez vous y pencher, il me faudra deux semaines pour faire suffisamment d'expérimentation pour faire une estimation.
C'est au manager de décider si et comment procéder. S'ils choisissent de continuer, c'est votre travail de répondre à vos estimations, ou d'informer le gestionnaire s'il y a un obstacle. Tant que vous faites cela, dans une entreprise raisonnable, il n'y aura pas de conséquences négatives.
Bien sûr, il existe également des entreprises déraisonnables qui ne vous donnent pas le temps ou les ressources pour faire votre travail. J'ai travaillé sur certains d'entre eux, et tout le monde a été confronté à des problèmes qui ne pouvaient pas être résolus dans les limites de l'entreprise. L'un d'eux a licencié environ 98% du personnel de programmation en huit mois, et c'était certainement une conséquence, mais cela ne m'a pas été personnellement adressé, et je considère toujours mon patron et son patron à partir de là comme de bons amis.
Il y a beaucoup de types de problèmes différents sur lesquels vous serez confrontés, et beaucoup ont différentes manières de les gérer.
Un type de problème consiste à implémenter quelque chose que vous n'avez jamais vu auparavant comme une étrange API sonore ou quelque chose. Dans ce cas, je demanderais à SO, sérieusement.
Un autre est un très gros problème à résoudre. Ce type de problème peut être abordé de manière itérative. Ils vous disent "Implémenter Humongous". Vous l'examinez et écrivez autant d'étapes que possible. Ensuite, vous décomposez les étapes compliquées en étapes plus petites. Lorsque vous êtes obligé de penser à des étapes plus petites, elles deviennent plus claires. Si vous rencontrez un problème technique, essayez une implémentation de test et demandez ici si nécessaire.
L'un des problèmes les plus ennuyeux est les demandes mal spécifiées. Ils veulent juste une chose qui fait "x" et ne vous disent pas comment faire. Pour ceux-ci, une bonne approche consiste à prototyper une interface (généralement une interface graphique) et à laisser quelqu'un jouer avec.
Il y a ensuite des contraintes de temps qui ne peuvent pas être respectées. Cela implique souvent de modifier les attentes et de livrer des prototypes fonctionnels.
Vous trouverez généralement votre chemin à travers les choses d'une manière ou d'une autre. C'est effrayant, mais une fois que vous y êtes, vous pouvez presque toujours trouver un chemin.
Votre meilleur pari peut être de simplement peindre les mots "ne paniquez pas" à l'extérieur de votre ordinateur portable. Et n'oubliez pas votre serviette.
D'après mon expérience, un nouveau diplômé n'est pas jeté dans les profondeurs. Au lieu de cela, vous ferez probablement partie d'une équipe qui comprend également des développeurs expérimentés.
Mon conseil serait: faites-en usage. Lorsque vous ne savez pas comment résoudre un problème, ou si vous voulez savoir si votre solution va dans la bonne direction, discutez-en avec eux. Et si vous vous sentez coincé quelque part, prenez l'un des gars expérimentés et expliquez votre problème et demandez de l'aide.
Le plus souvent, expliquer simplement votre problème révélera une solution et expliquer votre solution peut également révéler des défauts.
Cela se produit souvent parce que vous n'avez pas défini le problème correctement et avec précision. Peut-être que vous essayez de résoudre une solution préconçue au lieu du problème lui-même.
Le problème est seulement ce que vous observez, pas ce que vous imaginez.
"Ma voiture sanglante ne démarre pas" est un problème. "La batterie est à plat." est une solution préconçue au problème de démarrage de voiture. Même le test de la batterie ne prouve pas qu'elle est la seule cause du problème. À moins que vous n'ayez réellement rechargé ou remplacé la batterie et réussi à démarrer la voiture, vous n'avez aucune preuve que la batterie est la cause du problème.
Simplifiez et continuez de simplifier. Décomposez-le en petites parties. Si vous ne pouvez pas résoudre ces problèmes, brisez-les. Vous vous sentirez mieux. Décomposez-le ensuite en différentes petites parties. Chacune de ces parties doit être un phénomène observable.
Je n'ai pas entendu parler de quelque chose comme ça. Tout d'abord, on ne vous donne jamais un problème qui ne peut pas être résolu du tout. Le problème peut être difficile et peut prendre du temps à résoudre. En cas de problème, vous devrez dire que c'est le temps dont j'ai besoin. Si, dans vos recherches, vous pensez que ce problème ne peut vraiment pas être résolu, vous devez lever le drapeau et dire à votre responsable que ce problème prendra plus de temps ou est vraiment difficile à résoudre. Tout dépend du calendrier. Si vous promettez quelque chose et que vous ne serez pas en mesure de le faire, c'est un problème. Mais si vous continuez à dire votre statut et vos préoccupations, il est de la responsabilité du gestionnaire de s'en occuper. Il devrait vous rediriger vers la bonne personne qui peut vous aider ou ajuster le calendrier.
Il y a quelques bons conseils ici! Ma valeur de deux cents est; Ne soyez pas submergé par le GRAND problème, n'oubliez pas que la partie passionnante et stimulante de la résolution d'un problème le décompose en une série de sous-problèmes gérables et plus compréhensibles, qui à leur tour se décomposent encore et encore en plus petits sous-problèmes. Tout bon programmeur le fera généralement minute par minute pendant qu'il crée du code (en utilisant des fonctions, des méthodes, des sous-routines, etc. pour aider à réduire la complexité globale d'une section de code) et cette méthodologie s'applique généralement à n'importe quel GRAND problème que vous face à la vie (pas seulement au travail).
Cela dépend évidemment du problème spécifique. Mais la réponse peut être:
- Trouver une solution de contournement/substitution
- Achetez une solution commerciale qui correspond à ce que vous voulez
- N'abandonnez pas et continuez à y travailler tant que vous en avez besoin jusqu'à ce que vous réussissiez.
Le numéro 3 peut avoir besoin de s'absenter du problème et de le réexaminer des semaines ou des mois plus tard. Cela aide souvent.
Dans mon expérience, il y a parfois des problèmes que vous ne pouvez pas résoudre, du moins en termes de restriction de temps. Donc, chercher de l'aide dès que possible, après l'échec de certains efforts de résolution.
Rappelez-vous la règle générale: regardez toujours la raison pour laquelle le patron vous engage. Faites tout ce que vous pensez pouvoir faire pour obtenir le meilleur résultat de travail, et parfois c'est un rapport d'échec précoce (bien meilleur qu'un rapport tardif).
En bref, si vous pensez que vous pouvez trouver la solution, n'hésitez pas à essayer, mais donnez à votre patron une estimation du risque et du temps. C'est leur problème maintenant.
Si des projets de cent millions de dollars peuvent échouer même avec des personnes expérimentées, vous ne devriez pas vous inquiéter de l'échec de votre formation, car vous êtes encore étudiant. J'ai eu un problème sur lequel travailler et j'ai trouvé que si c'est quelque chose sur lequel vous êtes coincé - vous devez enregistrer chaque tentative que vous avez faite pour le résoudre.
Qui aide:
- Preuve des tentatives effectuées pour résoudre un problème.
- L'enregistrement de ce type d'échec est important, vous pouvez donc en tirer des leçons et ne pas recommencer quelques jours plus tard en pensant que cela fonctionnera.