Reprise du message précédent :
 
oui sur le papier mais les dans les faits...

+1

 
Great minds think alike
 

T'auras toujours une couche d'abstraction qui est de l'ingénierie, ce qui tu dis est que le métier de technicien d'aujourd'hui rejoint celui de l'inge d'hier.

Ou alors, le constat fondamental à faire est que si le nombre d'ingé a été multiplié par 10 ou 100 dans le monde ces dernières années/décennies c'est parce que le besoin en nombre de dev sw a explosé.
 
Et qu'en fait à iso définition du boulot d'ingé dans le temps, de loin pas tous ces dev sw ne font des boulots d'ingénieurs.

 
Dans les faits aussi, que tu le veuille ou non

ouais t'as très bien compris ce que je voulais dire par prestataire
bah tu peux bien me parler de ton secteur, sans doute également sous perfusion des sociétés de service d'ailleurs mais par rapport au CA du secteur auto/aéro/ferro, vous êtes une poussière d'étoile
 
et les différents niveaux de ssii, oui tout à fait le marketing est ultra bien fait

 
L'erreur est la!

ok, c'est quoi ta valeur ajoutée d'ingénieur sur ta spécialité qu'est le logiciel ?

perso, j'avais fait une super rencontre une fois avec un ingé de TRT à palaiseau, les mecs envoyaient du bois pour le coup

c'était pas les mêmes problématiques que mes chers équipementiers aéronautiques des ulis et d'élancourt...

 
La conception/l'organisation/la réalisation de projet de manière générale (au passage, je ne suis pas ingénieur, enfin j'ai le titre mais pas le diplôme ).

Clairement, l'industrialisation des processus de développement, test, déploiement et maintenance de l'application.
 
Et aussi, plus techniquement, savoir organiser le code pour que les processus pré-cité soit facile à réaliser et efficace. Sans parler même de l’aspect collaboratifs du développement.
 
Encore une fois, coder un algo. de calcul seul dans son coin c'est facile. Coder un logiciel qui sera commercialiser et maintenu c'est déjà autre chose.

 
Aucun rapport.

 
C'est peut être pour ça que les devs en SV sont plus payés

 
soyez plus précis, c'est intéressant
sinon, vous êtes à combien, ça vous intéresse le 78 ?

 
C'est marrant parce que de mon point de vue le codage de banc de test c'était pas vraiment une activité "noble"...  
 
Pour le côté un "peu différent de l'info", c'est justement tout le bonheur de ce genre de discussion on confond les collègues de youmou qui font du dev d'appli web en ruby, ceux de dante qui font de la prod pour les assurances, ceux de janitor qui font un intranet, les miens qui font des systèmes embarqués en une grand entité nommé "informaticien"  

 
Ils ne sont probablement pas sur les fonctions critiques.

tu serais surpris

 
Mais tu veux qu'on soit précis sur quoi? Tu ne sais pas ce qu'est une phase de conception/plannification/realisation sur un projet informatique?
Tu ne sais pas comment s'organise des projets informatiques? Tu ne sais pas qu'un tech peut faire de la conception et un ingénieur peut coder?
 
Encore une fois, je pense que l'image que tu as de l'inge était valable il y a une décennie ou 2, mais ça a bien change depuis.  
 

 
J'ai l'impression que tu ne maîtrise pas trop ton domaine donc mieux vaut éviter  

Moi de toutes façons je considère qu'un engineer ça fait des engines.
 
Donc chez Airbus y en a pas, vu qu'ils achetent les moteurs.

 
Qu'on augmente artificiellement la taille d'une équipe, certes. Est ce qu'ils sont décisionnaires ?

nan mais explique mieux
 
nan mais tu connais les yvelines ?

Le simple fait que daaadou tente de recruter Janitor en dit long sur les compétences en SSII

des fois malheureusement, oui

 
T'es entrain de te transformer en youmou?
Je t'invite a aller voir sur google les définitions d'ingenieur, celle de conception, d'organisation et de réalisation de projet. Je ne peux pas faire grande-chose de plus pour toi.

 
On dit la même chose du coup  

partner in crime forever  

 
Petit laïus cours pour donner une idée.
 
En gros, tu va mettre en place des outils pour augmenter la qualité de ton produit :
- analyse statique de code => avoir un code qui respecte nos standard et voir les erreurs manifestes (syntaxe pourri, variable pas déclarée etc.) => en gros on veux du code qui respecte la nomenclature et sans warning.
- tests unitaires => ton code fait ce pour quoi tu l'a écrit
- tests fonctionnels/intégration => le produit fait ce qui a été spécifié/n'a pas de régressions
=> tu couple tout ça a une intégration continue pour avoir les informations en temps réels
 
Mettre en place ça, coûte du temps et ne se fait pas en 5 minutes.
 
Et je parle pas du versioning du code, de la gestions de anomalies/tickets hotline, de la gestion de configuration (branchement entre les versions, version de maintenance etc.)
 
Bref, tu industrialise, et cible la qualité de code.

 
Vu comment il maitrise son sujet, ça fait peur effectivement  

Lire ça m'a filé la nausée.

j'ai l'impression que ça abonde dans mon sens ptain

merci, c'est fort instructif, ça t'embête que je note tout ça ?
 
et tu peux nous expliquer agile, cycle en v ?

Quoi tu préfères faire de la merde

Tu essayes d'avoir une discussion sur la sémantique du mot ingénieur avec Janitor.

je suis dans le 15ème en train d'attendre depuis ce midi pour faire une irm

J'ai arrêté à la ligne 2

Ben franchement oui.

Tu es pardonné.    
Rien de grave?

Une fois que c'est en place tu bosse au bas mot 2x plus vite et n'est quasi jamais dans l'urgence. Donc en vrai c'est mieux pour tout le monde.
 
Faut juste souffrir quelques semaines/mois pour la transition.
 
Après ouai faut bosser chez un éditeur de logiciel pour sentir le gain direct de faire du logiciel dans les règles de l'art et pas seulement au plus vite pour maximiser les profits de sa SSII.