[job] Trouver un travail Unix

[Ambrevar]

Bonjour à tous !

Certains d'entre vous travaillent sûrement dans le monde de l'entreprise, aussi je me permets de poser une question à vous autres, Archer : cela ne vous dérange-t-il pas que l'on vous impose des outils qui ne vous conviennent a priori pas particulièrement ? Avez-vous trouvé un travail où vous étiez libre (dans une certaine mesure du moins) du choix de vous outils ?

Si vous aimez Arch, je pense que vous aimez choisir, profiter au maximum de la puissance que peut offrir une bonne configuration logicielle. Perso, j'aime les outils avancés dont il est difficile de se passer tant leur productivité est supérieure (emacs/vim, tiling manager, TeX/LaTeX, scripts, etc.). Je suis un fervent admirateur et défenseur des systèmes Unix et du "KISS principle".
Pour moi, l'informatique est une science qui se respecte, pas un jouet d'apprenti-sorcier sur clicodrome ce qui semble être la tendance aujourd'hui. C'est aussi pourquoi j'aime beaucoup Arch que je range auprès de distros "sérieuses" comme les BSD, Gentoo, etc.

J'avoue que travailler pour le développement d'un tel système m'attire particulièrement, mais à ma connaissance, ce ne sont que des OS communautaires. Je suis à la recherche d'un travail de développement en informatique (programmation) où l'on utilise un Unix "fondamental", des outils puissants, où l'on a une certaine liberté dans sa configuration logicielle. Je ne précise pas le secteur volontairement, car ma question est très générale : un tel poste existe-t-il ?

Merci de partager votre retour d'expérience !

[benjarobin]

Je travail dans une entreprise où tu es assez libre de tes outils. La seule condition c'est le résultat dans les temps et aucune obstruction dans le travail d'équipe : il faux être efficace.
Malheureusement certains projets, sujets imposent de par leur contenu forcément l'outil : Je pense en premier lieu la chaine de compilation et de debug, après libre à toi de choisir l'éditeur de code.

Par contre ton savoir permet de réorienter à ton niveau certains choix en les justifiant bien sûre.

Mais dans la vie il faut savoir faire des concession, tout n'est pas noir et blanc, il faut savoir ouvrir les yeux et être réaliste.
En résumé si tu cherches du travail avec ce genre de critère et par les temps qui cours, et encore le secteur ce porte pas mal, je te souhaite bonne chance

[oktoberfest]

Salut,

malheureusement tout dépend de l'entreprise et du type de travail.
Je fais de l'administration système chez un client d'une SSII et on a les deux approches :
- un côté imposé parce que les choses sont en place et ce n'est pas moi qui vais tout changer Et plus il y a des OS propriétaires (HP-UX, AIX) donc mettre en place des solutions homogènes Linux-AIX-HP_UX imposent des restrictions.
- un côté libre car Linux (RHEL dans mon cas) s'impose petit à petit sur les serveurs et on me laisse beaucoup de latitude dans le choix des méthodes et des outils pour différentes tâches : installation automatisée, annuaire NIS, sauvegarde/restauration système...

Tu te poses la question parce que tu es informaticien, mais peut-être qu'un maçon se pose les mêmes questions en terme d'outils et de matériaux dans son entreprise...

[Ambrevar]

Merci pour vos réponses.

Évidemment, je suis bien conscient que certains outils doivent être imposés. Tout à fait d'accord avec l'exemple des maçons !
Seulement, certains choix peuvent être plus que discutables, et le problème qui peut se poser en entreprise est justement cette "latitude" dont dispose un employé pour pouvoir remettre ces choix en question.

Je suis convaincu que le choix des outils est primordial pour le bon déroulement d'un projet, et aussi pour la qualité du produit final.
Vous dites que vous avez une certaines libertés dans votre travail, mais j'ai vu beaucoup plus restrictif, où tout, absolument tout était imposé à chacun des membres d'une équipe, et des outils plus que pénalisant à mon avis.
Lorsqu'une boîte impose que ses spécifications de développement (projet sous Unix en l'occurence) soient fait sous Powerpoint, je trouve ça dramatique, autant pour l'efficacité de développement que pour la qualité des specs...
On se retrouve à côté de ça avec des outils qui sont parfois étrangement vieux (un Red Hat de 2002 livré avec des outils des années 90...) alors qu'il faut travailler sur un projet "moderne".
Pas très cohérent à mon avis.

Une tendance que j'ai remarqué dans le monde de l'entreprise et qui peut paraître complètement paradoxal par rapport à la vitesse d'évolution du secteur informatique, c'est ce côté "conservateur". Pourquoi ? Justement parcequ'il "ne faut rien changer tant que ça marche". C'est la démarche "il y a de l'argent en jeu, il ne faut pas prendre de risque".
Ça c'est le point de vue "réaliste", je suis d'accord. Mais ce n'est pas parce que c'est "réaliste" dans le monde de l'entreprise -- i.e. ça a fait ses preuves donc c'est la bonne solution -- que c'est une bonne manière de penser. Il peut y avoir meilleure solution. Être réaliste pour une entreprise, c'est aussi choisir Windows pour son parc informatique, pour les raisons que tout le monde connait. Est-ce une bonne chose pour autant ?

C'est un peu comme si les outils échappaient totalement au contrôle des spécialistes de la boîte. Dans ce cas, à quoi bon embaucher un personnel compétent ? Peut-être que le problème est justement là : si le personnel n'est pas suffisamment compétent.

Mais oui, c'est la dure réalité : on ne fait pas ce qu'on veut dans n'importe quelle boîte. Faut tomber sur la perle rare, je suppose. Donc par rapport à votre expérience, j'en déduis que
-soit on a la chance de tomber sur une boîte assez évolutive et flexible ;
-soit on se contente de ce qu'on nous impose.

[oktoberfest]

La vie est faite de compromis. Si tu es en couple (ou quand tu le seras) tu comprendras Et vu que c'est déjà compliqué à deux, alors imagine dans une société de 10, 100 ou 10000 personnes.

[tuxce]

C'est aussi pourquoi j'aime beaucoup Arch que je range auprès de distros "sérieuses" comme les BSD, Gentoo, etc.

Je sais pas ce qu'inclue "etc.", mais si tu n'y inclus que des distributions qui demandent un investissement utilisateur, c'est un raisonnement très court

Si 99% de ton choix de l'outil est la liberté de celui ci, effectivement, ça va être dur de trouver un boulot qui te convient.
Par contre, des outils efficaces et pertinents, ça se trouve un peu partout et heureusement.

On se retrouve à côté de ça avec des outils qui sont parfois étrangement vieux (un Red Hat de 2002 livré avec des outils des années 90...) alors qu'il faut travailler sur un projet "moderne".

Il faut relativiser, un projet initié en 2000, qui a aboutit a un écosystème (softs / materiels / protcoles ...) viable et utilisé tous les jours, tu ne vas pas l'attaquer avec que des outils de 2012.
Si le projet a pris x années pour aboutir, tu le mets à jour dès sa mise en production ?
Sans compter qu'une mise à niveau demande de jongler avec bien plus de critères que juste la dernière version emacs/vim, gcc, java etc.

Lorsqu'une boîte impose que ses spécifications de développement (projet sous Unix en l'occurence) soient fait sous Powerpoint, je trouve ça dramatique, autant pour l'efficacité de développement que pour la qualité des specs...

Je ne sais pas pourquoi cette boîte ci imposerait cela, mais cet exemple permet de mettre en évidence un point très important, l'interopérabilité des documents qui malheureusement n'a strictement rien à voir avec des standards ou normes, et qui se limite très souvent à:
- le destinataire de tes documents doit pouvoir les lire
Et pour peu que le destinataire soit ton client, qu'il ne connaisse rien à l'outil informatique (ou ne veut pas se prendre la tête, etc.), eh ben, s'il te dit qu'il veut du powerpoint, tu lui en donnes un ou tu t'assois sur le projet
Je prends powerpoint parce que t'en a parlé, mais ça dépasse le cadre des "outils", perso, on me demanderait un document .tex, ça me poserait des soucis, et on peut éventuellement créer un powerpoint avec des outils "libres" (si le but est d'utiliser du libre)

Perso, j'aime les outils avancés dont il est difficile de se passer tant leur productivité est supérieure (emacs/vim, tiling manager, TeX/LaTeX, scripts, etc.).

Un autre point qui n'est pas si simple à trancher, là tu parles d'environnement utilisateur (en dehors d'un éventuel projet), sauf, qu'il faut multiplier ça par x utilisateurs puis imaginer la tâche d'un service informatique qui doit gérer tout ça !
Je suis pas sûr que la productivité gagne à intégrer le temps de débogguage par utilisateur

Enfin bref, oktoberfest a bien résumé tout ça:

La vie est faite de compromis.