Expliquez en quoi consiste votre métier

Histoire d'aider les étudiants en detresse

a marqué ce sujet comme résolu.

Salut,

Étant un étudiant en informatique au tout début de sa formation, j’ai encore une vision un peu flou des métiers de l’informatique.

Du coup je m’étais dis que ça pourrait être sympa si certain décrivait leurs métiers, journée type etc…

N’hésitez pas à rentrer dans le détail.

Bonne journée

+7 -0

À propos des interviews, j’ai complètement changé de boulot depuis la mienne :)

SpaceFox

Ça ne serait pas une excuse pour en fait un second ça ? (:

Je suis dans le même cas que l’OP, début de formation (bon, école d’ingé dans mon cas donc j’ai encore le temps pour choisir ma branche et ma spé dans cette branche mais je pense très fortement aller en info) et donc j’ai le même flou qui entoure ces boulots. Je me demandais en particulier l’impact de la taille de la structure. Est-ce que l’environnement des les grosses entreprises correspond à tout le monde ?

+0 -0

Ça ne serait pas une excuse pour en fait un second ça ? (:

Ça me me dérangerait pas, mais pas tout de suite, que je sois installé dans mon nouveau taf.

Est-ce que l’environnement des les grosses entreprises correspond à tout le monde ?

Ça je peux déjà te répondre que non. Et même plus précisément qu’il y a pas mal de gens (dont je fais partie) qui ont énormément de mal avec les grosses entreprises (testé et désapprouvé). Mais j’en connais d’autres qui ont du mal avec les petites entreprises, ça dépend de ce que tu cherches.

+2 -0

Non seulement la taille de la boîte compte, mais aussi :

  • sa "nationalité" (sa culture),
  • son "époque" (le point où elle en est dans son cycle de développement)

Perso je sais que je préfère les petites, startups, à la française, qui ont fait au moins une levée de fonds, parce que c’est des boîtes souvent malléables (si t’as une bonne idée, on t’écoute et tu as l’opportunité de la mettre en place) et avec un état d’esprit moderne/dynamique, sans pour autant être en mode big bang où tout est à faire immédiatement, y compris ce qu’on ne sait pas faire.

Cela dit je comprends que d’autres adorent les variations d’adrénaline du mode big bang, ou bien recherchent une place plus pépère dans une boite déjà bien installée et hiérarchisée.

+2 -0

Après, pour ceux qui ne connaissent pas trop le monde « pro », en informatique il y a beaucoup (beaucoup) de sociétés de service aka SSII.

Ces sociétés là présentent l’avantage de pouvoir effectuer plusieurs missions dans des secteurs différents assez facilement, ça peut être bien pour se faire de l’expérience. La plupart du temps, on est placé dans des grands groupes. L’inconvénient, c’est tout le reste, notamment le fait d’être la « marchandise » de l’entreprise, les avantages au rabais, le lien d’appartenance à la boite pas toujours clair. Ça peut aussi être bien si tu veux te mettre au droit du travail ! :D (N.B : je suis actuellement en SSII)

Mais si tu veux travailler dans un grand groupe, c’est très rare qu’ils embauchent autrement qu’en étant passé prestataire.

Pour les avantages petite structure vs grande structure, je connais principalement les grandes structures. L’inconvénient, c’est que pour changer quelque chose, c’est souvent un paquebot à déplacer. Réussir à convaincre son chef, qui va convaincre son propre chef, jusqu’à que ça redescende. C’est long, pas impossible, mais long. Après, tu as plus de sécurité, tu peux tomber sur des projets de plus grandes envergure (quoique pas toujours vrai). À toi de voir ce que tu veux, mais le mieux reste peut-être d’essayer.

+0 -0

À propos des interviews, j’ai complètement changé de boulot depuis la mienne :)

SpaceFox

Moi aussi…

Concernant la taille des boîtes : pour le moment j’ai fais "moyen-petit" (50 personnes, 25 techs) et "très petit" (5 personnes, 2 tech, dont moi). Je vais bientôt commencer plus gros (100 personnes, 40 techs).

Globalement, même si il n’y a pas que la taille qui compteTM, plus la boîte est petite, plus tu as de l’importance dans la boîte : ton avis va être plus entendu, tu peux plus facilement faire bouger les choses et l’influencer mais aussi plus ton travail sera attendu (quand tu es que deux devis, si tu fais rien de la semaine, ça se voit). Perso les petites boîtes me vont mieux je pense (même si j’ai pas vraiment d’expérience dans un grand groupe) car j’aime être actif et avoir un impact direct sur le produit. Mais ça demande une certaine énergie et volonté : dans ma boîte précédente, quand mon chef était en vacances, il n’y avait que moi pour tout gérer donc "d’astreinte officieusement" pendant le weekend et prudent la semaine. En contrepartie j’avais une grande liberté dans mon travail et une total confiance de mes chefs, et des remerciements réguliers des usagers sur des choses que j’avais créé ou mit en place.

Je changerai peut être d’avis avec l’âge ceci dit, l’avenir nous le dira…

Pour répondre au PO, je vais donner un exemple de lundi type dans ma précédente boîte (donc très petite) :

  • 9h, j’arrive au boulot, je suis le premier (ou le deuxième), je me fait un café et je consulte mes mails. Généralement pas grand chose à part des mails autos.
  • petite boîte oblige, le support "technique’ c’est mes devs qui s’en occupent. Donc si c’est une journée ou c’est toi qui doit t’en charger, passage "de support" : répondre à des messages des utilisateurs qui pensent avoir un bug ou on des suggestions ou des questions. Réponses direct et, pour les bugs, correction du code dans la foulée. Cela prend de 2 min à 4h en fonction de l’activité et des problèmes.
  • 10h ou 11h, réunion hebdomadaire de l’équipe, la boîte en entier. Tout le monde raconte ce qu’il fait de sa semaine et ce qu’il prévoit de faire (techs, commerciaux, marketing, etc.) : C’est l’avantage d’une petite boîte, tout le monde peu suivre le boulot de tout le monde et ça permet de savoir ce qui se passe. En général suivi par une partie "discussions" ou tout le monde débat sur une idée/suggestions.
  • 12h, tout ceux comme moi qui n’ont rien prévu à manger vont acheter un truc avant qu’il n’y ai trop de monde dans les trucs du quartier.
  • 12h30, on mange ensemble sur la table de réunion, grand et long débats existentiel sur la vie dans l’espace et son rapport avec les chansons de Jul. D’autres startup de l’immeuble viennent profiter de notre grande table et de nos débats pour manger. Les motivés terminent sur quelques parties de Bomberman sur l’écran géant du boulot.
  • 14h, tu va coder ta grosse tache du moment, tu es content ça prend forme, tu envoie un mail au reste de ma boîte pour leur demander leur avis et tu te rends compte qu’il y a encore du boulot.
  • 15h les commerciaux gueule que tu ne leur a pas réglé un truc (fusion d’objets de la dB) qu’ils t’ont demandé la semaine dernière, tu règle le problème et tu code un truc pour ne plus avoir à le faire.
  • 16h tu va faire un petit point mensuel avec ton chef pour discuter de la vie, l’univers et le reste.
  • 17h tu fais un peu de review parce que bon les autres dev gueule que tu en fait pas assez.
  • 17h30 tu corriges tes commis en fonction des review de tes collègues : ils pinaillent pour rien mais bon c’est plus rapide de corriger que d’argumenter.
  • 18h les commerciaux partent tôt comme habitude.
  • 18h05, tu va prendre un verre au bar du coin avec les collègues encore présent.
  • 21h tu rentre à la maison après une journée harassante…
+4 -0

Ma journée en tant que développeur Android:

  • 8h30-9h: Arrivé au travail, lecture des mails automatiques remonté par les outils d’intégration continue.
  • 9h-9h30: Relecture de code, mise à jours des dépendances au besoin, tous les trucs fait rapidement qu’on fait jamais car pas le temps.
  • 9h30-9h45: daily scrum avec l’équipe mobile.
  • 9h45-12h: Développement des fonctionnalités demandé pour les différents projets, correction d’anomalies.
  • 12h-12h45: on va chercher à manger, on déjeune avec le reste des autres équipes !
  • 12h45-13h30: Jeux-vidéos ou Jeux de société ^^. Le jeu du moment, Zombicide, je recommande !
  • 13h30-17h30: Alternance des reunions avec les clients, développement des fonctionalités.
  • 17h30-18h00: Review de code, on corrige l’historique du gestionnaire de version avant de push
  • 18h00-18h10: les outils de builds passe avec la ou les PR du jours, petite prière pour que ça passe :D .
  • 18h10: Dobby est LIBREEEEE !
+1 -0

De mon côté ça donne plutôt ça :

  • 09h30: j’arrive à mon poste. Je regarde les mails d’erreur et Sentry pour vérifier que rien n’a crashé dans la nuit. Si on fait de la diffusion en live la veille / pendant la nuit j’essaye de croiser l’équipe prod pour vérifier que tout c’est bien passé.
  • 10h00: Je jette un coup d’oeil aux tickets en cours, vérifie que ça ne manque pas de code reviews sur Github
  • 10h15 stand up meeting entre dev : on discute des sujets de la veille et de ce qu’on va faire aujourd’hui (mise en prod ? besoin de review ? etc.)
  • 10h30 : En général j’attaque le dev sur une fonctionnalité / je traite mes PR déjà ouvertes, je fait le lien avec la QA pour m’assurer que mes tickets seront traités. Je peut aussi lancer une mise en prod si le besoin s’en fait sentir.
  • 13h00 : C’est l’heure de manger ! Dans le quartier on a le choix entre des dizaines de restaurants, en cas de doute on un petit bot pour vous faire des recommandations.
  • 14h00 - 14h30 : Les joueurs de babyfoot sont en place, ça crie "PISETTE !!!"
  • 14h30 - 18h30 : Encore du dev ou de la review en fonction. On se réserve aussi des créneaux d’améliorations techniques où on essaye d’améliorer la codebase : refactoring, couverture de code ou bien de rendre notre workflow plus rapide par exemple.

Ca ressemble pas mal avec ce que fait Hugo par exemple. D’ailleurs vos outils de build ne passent qu’une fois par jour ?

+0 -0

Allez, à mon tour ! :)

  • 08h30 : j’arrive au bureau. Je suis 2e sur 10 personnes. J’allume le PC. Je prends quelques instants pour lire les quelques mails potentiels, et regarder si l’intégration de la nuit s’est correctement déroulée. Si erreur il y a sur la génération, je regarde qui est le coupable. Ouf, c’est pas notre équipe, c’est l’étage du dessous.
  • 08h45 : Je vais prendre un café.
  • 08h50 : je prépare le thé pour toute l’équipe que les gens puissent en prendre en arrivant.
  • 9h00 : je regarde si des nouveaux bugs ont été entrés, juste pour suivre l’avancement du projet.
  • 9h15 : Bon, ben les gens commencent à arriver. On va prendre le thé ensemble, et parler de la pluie et du beau temps. Et parler un peu boulot, histoire de savoir où en est tout le monde.
  • 9h30 : Bon, ben on peut commencer à bosser ! Je continue le développement déjà commencé.
  • 10h00 : Une fois encore, il manque des choses dans les specs, je vais demander au responsable technique son avis.
  • 10h05 : Il me dit qu’il en sait rien, faut envoyer un mail au client.
  • 10h30 : Le client réponds qu’il n’y avait pas pensé.
  • 10h45 : Je propose une solution pour palier le problème, je modifie les specs, et je continue mon développement
  • 11h30-12h20 : Il est l’heure d’aller manger à la cantine ! Oui, on mange tôt, mais la cantine accueillant aussi des étudiants, sinon c’est le bazar. On fait une grande tablée avec la majorité de l’équipe.
  • 12h20-13h30 : On parle de la pluie et du beau temps. On débat politique et problèmes sociétaux. On dit que c’était mieux avant. Lecture de quelques magasines. Et on bois du thé et/ou du café.
  • 13h30-15h30 : Je continue mon développement tranquillement.
  • 15h30-15h45 : Je reprends un café. Je vais voir les autres, je dis 2-3 conneries, on rigole un coup.
  • 15h45 : Le chef me demande de venir le voir. Il faut que je bascule sur une correction de bug plus urgente, il me donne le ticket.
  • 15h35-17h25 : Bon, bah c’était pas grand chose. Encore un boulot mal testé ça. C’est corrigé, j’envoie un patch à l’intégrateur, histoire qu’il valide tout ça, mais c’est tout bon.
  • 17h25 : Je rempli mon suivi hebdomadaire pour dire sur quoi j’ai bossé aujourd’hui. 0.75 jours sur du dev, 0.25 jours sur de la correction de bug. C’est pénible, mais il parait que c’est pour les budgets.
  • 17h30 : On peut rentrer à la maison ! :)

EDIT : J’ai pas mis de contexte, mais je suis développeur Junior, dans une équipe de 10 personnes. On développe un logiciel qui a un certain historique, c’est une suite logicielle : plusieurs équipes qui développent des « modules » différents. On fait du bon vieux cycle en V.

+0 -0

Lu’!

Pour ma part, mon boulot est un peu atypique : je fais de la vérification formelle (comprendre mathématique) de logiciel. Actuellement, ces postes sont peu communs d’autant que cette discipline est assez peu enseignée et la plupart des gens qui ont une expertise sur le sujet sont docteurs. Mais on fait un maximum pour réduire le ticket d’entrée et populariser ces techniques, surtout avec l’importance que prend la sécurité ces dernières années (et le fait que les techniques n’en sont plus à leurs balbutiements).

Pour ma part, je suis en recherche donc une journée commune, ça ressemble à :

  • 7:00 : réveil, comment j’en suis arrivé là ?
  • 8:00/8:30 : arrivée au boulot, un oeil au mailing-lists des outils pour voir s’il y a des questions auxquelles je peux apporter une réponse pertinente, un oeil au mailing-lists du projet de recherche sur lequel je suis pour voir si quelque chose urge d’un point de vue admin/livraison/organisation de meeting,
  • 9:30 : je fais avancer tout ce qui est rapports en synthétisant ce qui a été fait la veille, à tête reposée.
  • 10:00 : j’attaque un problème de la veille (alarme trouvée par une analyse dans le logiciel analysé, preuve qui ne passe pas sur une propriété particulière, …). Généralement, ça implique une longue phase d’investigation.
  • 12:00 : miam time.
  • 12:30/13:00 : généralement j’ai assez d’éléments pour comprendre ce qui ne va pas, donc soit j’essaye de mieux configurer/débugger l’analyseur, soit j’essaye de provoquer l’alarme pour de bon ou de trouver un contre-exemple exécutable à une propriété.
  • 16:00 : souvent toutes les tentatives ont échoué, je commence à me questionner sur le sens de la vie et je songe à changer de métier.
  • 17:00 : je trouve un bout de solution, un truc qui fait avancer, aller un poil plus loin, alors je me dis que c’est pas si mal comme boulot.
  • 18:00 : après avoir mis en place la solution, j’identifie les nouveaux points bloquants, notamment parce que si c’est un sujet traité par un des partenaires du projet, je lui fais immédiatement un mail pour voir s’il a pas déjà un truc dans les placards pour régler ça.
  • 18:30 : FREEEEEEEEDOM.

Alternative à ça : rédaction d’article de conférence, meetings/conf-call avec les partenaires de projets, rédaction de tutoriels (:-°) …

+1 -0

D’ailleurs vos outils de build ne passent qu’une fois par jour ?

En permanence, pour les tests unitaires. Pour les tests d’intégrations comme on travaille avec beaucoups de box différentes, des téléphones, tablettes et autres montres connectés, on les lance manuellement. Les raisons c’est que ça prends plusieurs minutes à passer tous les tests et qu’on aime la planete.

+0 -0

Ces sociétés là présentent l’avantage de pouvoir effectuer plusieurs missions dans des secteurs différents assez facilement, ça peut être bien pour se faire de l’expérience. La plupart du temps, on est placé dans des grands groupes. L’inconvénient, c’est tout le reste, notamment le fait d’être la « marchandise » de l’entreprise, les avantages au rabais, le lien d’appartenance à la boite pas toujours clair. Ça peut aussi être bien si tu veux te mettre au droit du travail ! :D (N.B : je suis actuellement en SSII)

Ça dépend de la taille de la SSII (et éventuellement de l’antenne où tu es). J’ai des amis chez Alten, mais pas au même endroit, l’approche est très différente pour chacun. Pourtant c’est la même boîte, mais le commercial et l’équipe divergent et parfois c’est super, parfois non.

Et comme toute entreprise, des SSII tu en as des petites et des grosses. Actuellement je suis dans une petite SSII (je n’ai jamais bossé dans une grosse) et j’ai un vécu bien différent de la plupart des gens ayant été chez les grosses du secteur. Nous ne sommes que 20-30 consultants avec 2 commerciaux. Et cela se passe très bien.

Déjà, contrairement à la plupart des SSII où tu vois ton commercial trois fois l’an (quand tu es en intercontrat, pour le bilan annuel et la fête de Noël), nous nous voyons toutes les deux semaines le vendredi après-midi. Chacun raconte son travail, ses difficultés lors des deux dernières semaines, on a le droit à un exposé par un employé (cela peut aller sur une techno à la mode, sur le pain, la bière, etc.) pour finir sur un apéro à 17h dans les locaux. C’est très convivial. On s’aide aussi par liste de diffusion commune interne en cas de soucis (nous bossons tous sur du Linux embarqué).

Du coup, l’ambiance est bonne, les commerciaux ne sont pas des bouchers. Ils m’ont aidé par exemple à obtenir plus de télétravail auprès du client. Et comme on se voit tous souvent, on a vraiment la sensation d’appartenir à la même entreprise (ce que beaucoup de mes amis en grosse SSII regrettent, c’est de se sentir plus proche du client que de leur propre boîte).

Personnellement je n’ai pas de journée type, cela dépend du projet, de son stade d’avancement, du jour de la semaine, si je suis sur place ou à la maison (je bosse au moins 3 jours / semaine à la maison), etc.

+0 -0

Perso je ne pourrais pas donner de journée-type parce que je suis dans une situation particulière : je suis à la fois le lead dev (c’est moi qui ai architecturé et développé le plus gros du code il y a plusieurs années, donc je suis responsable de guider les choix techniques) et le scrum master de mon équipe (il faut voir ce poste comme l’équivalent Agile d’un délégué de classe…) et que mes journées peuvent être très différentes selon le moment où on se trouve dans l’itération.

Concrètement :

  • J’absorbe le plus gros des interruptions pour que le reste de l’équipe puisse travailler sans être trop dérangé/déconcentré.
  • Je fais beaucoup de code reviews.
  • Je m’occupe assez peu de développer le produit même, sauf, bien sûr, en cas de coup de bourre. Enfin ça c’est dans l’idée, car dans les faits on est un peu en coup de bourre permanent. :D
  • Je fais le tour des devs de mon équipe, j’identifie leurs difficultés et je fais ce que je peux pour les aider à les surmonter.
  • J’organise, planifie et anime les réunions, en particulier les cérémonies propres à la méthodogie SCRUM (stand-ups, planification d’itérations, démos, rétrospectives…).
  • Je développe des outils pour aider les devs dans leur boulot et améliorer leur efficacité.

En somme, après avoir passé des années à développer, j’ai maintenant un rôle principalement humain/managérial qui permet à mon équipe de rester concentrée sur l’essentiel.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte