J'ai une question qui a été soulevée par mon dernier emploi (plutôt stagiaire).
Juste pour mettre les choses en contexte - j'ai 21 ans et j'ai terminé ma deuxième année d'université avant que j'ai eu environ 2 ans d'expérience dans des emplois d'administrateur système / AQ et, fondamentalement, je peux dire que j'ai vu à quel point différent Secteurs informatiques exploités. Revenons à l'heure actuelle et voici que je décroche un stage dans l'une des premières institutions de recherche au Royaume-Uni.
Ce que je dois faire, c'est créer des outils internes en utilisant un mélange de technologies - principalement AWS / Java / Bash - vous obtenez l'image. Tout va bien, je fais mon travail MAIS je ne suis pas content. Pourquoi est-ce parce que je suis censé travailler dans une affaire ponctuelle. C'est créer des choses rapidement, sans passer de temps à concevoir. Mon directeur a explicitement dit qu'il devait "se précipiter" à travers les problèmes à mesure qu'ils surviennent et nous essentiellement. En conséquence, il s'est avéré que les choses devaient être refaites et remaniées et elles ne sont toujours pas parfaites. En ce qui concerne les tests - gardez-le au minimum, tant qu'il semble fonctionner, c'est OK.
Suis-je en faute pour être en désaccord avec cette façon de travailler? Est-ce mal de vouloir penser le système dans son ensemble, puis se concentrer sur les différents composants et voir comment ils pourraient interagir, pour se concentrer sur différents "points clés" qui pourraient s'avérer problématiques à l'avenir? Est-ce un crime de vouloir faire un bon travail et non un "travail rapide"? Est-ce une erreur ou une mauvaise attitude de vouloir rechercher les structures de données applicables à un problème afin que vous puissiez choisir le meilleur en fonction d'un ensemble de problèmes particulier? Au mieux de ma compréhension, le bit "Ingénierie" dans "Génie logiciel" doit faire exactement cela - recherchez votre domaine de problème et trouvez une solution éclairée puis affinez si nécessaire?
Je suis allé à une entrevue dans un bureau d'Arm au Royaume-Uni et ils m'ont montré leur chambre SCRUM et il semblait qu'ils avaient une assez bonne idée de la façon de gérer leur projet - ils avaient un carnet de commandes, ils avaient des mesures quant à la durée de chacun le problème pourrait prendre à résoudre - les choses habituelles pour SCRUM - complètement différentes de la façon dont les choses sont exécutées "ici"
Ai-je construit une mauvaise idée de l'industrie du logiciel en général? J'aimerais entendre vos commentaires à ce sujet. Je veux dire que je suis "entré" dans le développement de logiciels uniquement parce que je veux créer des choses - simples et simples, mais je veux créer des choses de qualité. Je veux voir mon logiciel utilisé dans divers scénarios, je veux le voir à l'épreuve des balles - n'est-ce pas la force motrice de tous les ingénieurs logiciels? Je pense que tout le monde peut être programmeur / codeur en apprenant simplement la syntaxe, mais pour moi, où le vrai plaisir commence, c'est quand vous devez réellement trouver un design réalisable dans le monde réel.
J'avais l'habitude de faire mes travaux universitaires en les regardant simplement et en commençant directement le codage et je pouvais facilement obtenir des notes supérieures à 75% et je n'ai jamais vraiment apprécié le module "cycle de vie du développement logiciel". Mais maintenant, quand j'ai vu dans le monde réel à quel point il est mauvais de travailler sans aucun processus formel et la frustration inhérente à une situation où vous ne savez pas si les exigences vont changer demain (oh, ai-je dit que nous ne avez pas d'analyse des besoins clairement définie?)
J'aime vraiment croire que je viens de décrocher une position où certaines personnes avaient juste besoin d'un singe de code pour faire leur sale boulot et ce n'est pas le cas de la façon dont le monde du logiciel fonctionne dans son ensemble.
because I'm expected to work in an ad-hoc matter. That is create things quickly, without spending time on designing
- Bienvenue dans The Real World ™, où il y a des délais et où les entreprises devraient produire des résultats.