Pragmatisme et ingénierie en équipe
Quand il s’agit de faire n’importe quel type de développement – peu importe si c’est pour le web, pour mobile ou pour une autre plate-forme – il y a beaucoup de livres, de cours en ligne, etc. qui rendent incroyablement facile d’apprendre quoi que ce soit c’est que vous voulez apprendre.
Pour être clair, je ne touche à aucun des moyens disponibles pour apprendre non plus. Après tout, nous apprenons tous de différentes manières, n’est-ce pas? Et qui suis-je dire quel chemin est meilleur que n’importe quel autre moyen surtout compte tenu du fait que j’écris quotidiennement sur des sujets ici sur et sur d’autres sites?
Mais je peux définitivement dire pour moi – quelqu’un qui a aimé apprendre à la fois par l’éducation formelle, les tutoriels, les cours, etc. – la meilleure façon d’acquérir de l’expérience dans cette industrie a été double :
- travailler avec d’autres personnes,
- casser des choses et apprendre à les réparer.
Est-ce que je veux dire le faire dans cet ordre spécifique ? Non. Cela signifie-t-il que j’ai une longueur d’avance sur les autres ? C’est risible.
Mais comme j’ai eu le plaisir de travailler avec d’autres sur plusieurs projets, de parler avec d’autres via Twitter, des conférences, etc. et d’avoir vécu à la fois le bien et le mal, c’est quelque chose que je pense que tout le monde devrait avoir l’occasion de faire à un moment donné.
Si je devais résumer, je dirais qu’il s’agit de trouver un équilibre entre pragmatisme d’équipe et ingénierie. Pourquoi, cependant, si rien de ce qui précède n’est nouveau (étant donné que les éditeurs de logiciels existent depuis des décennies), est-ce que je prends la peine d’écrire à ce sujet maintenant ?
Pragmatisme et ingénierie en équipe
Je pourrais probablement proposer une longue liste de raisons pour lesquelles je trouve ce sujet particulier important, mais il y a trois choses spécifiques que j’aimerais mentionner dans cet article. Et, pour des raisons de longueur (lire: temps), je ferai ce que je peux pour les garder courts.
En fait, le TL; DR de ce dont je vais parler a à voir avec le pragmatisme et les compétences en ingénierie. À l’origine, j’allais également inclure une perspective sur les affaires en général, mais cela a pris le message général un peu hors sujet.
1 Pragmatisme
J’ai déjà écrit sur l’équilibre entre l’ingénierie et le pragmatisme . Donc je n’ai peut-être pas grand-chose à offrir en termes de nouveautés, mais je commence à changer un peu mon point de vue.
Autrement dit, à un moment donné, il s’agissait strictement de trouver un équilibre entre trouver une solution qui fonctionne pour la coutume, qui est bien construite et qui résout son problème. Et j’y souscris toujours.
Et, bien sûr, il y a quelque chose à dire sur la façon dont le code est organisé pour qu’il puisse être maintenu dans le temps. C’est la clé. Mais la façon dont le code est construit est écrit et la solution est construite est là où les choses peuvent devenir un peu plus floues en ce qui concerne le pragmatisme.
C’est-à-dire qu’il est facile d’écrire du code orienté objet de base, de le documenter, de faire appel à quelques classes ou fonctions, de se connecter à WordPress, puis de l’appeler un jour.
2 Compétence en ingénierie
Mais est-ce que ce niveau d’équilibre entre l’expédition de la solution et l’architecture de la solution est une ligne fine à parcourir. Je crois, cependant, qu’il y a un danger à essayer d’être trop pragmatique: si vous visez à rester aussi pragmatique que possible tout le temps et laissez vos compétences en ingénierie à un niveau particulier, vous risquez de ne pas progresser en tant que développeur.
Bien que je préfère utiliser la programmation orientée objet dans le type de travail que je fais, je ne suis pas du genre à entrer dans une guerre de religion ou à entrer dans quelle version de quel langage, quelle technologie, ou si fonctionnel, procédural ou orienté objet la programmation est meilleure.
En termes simples: il s’agit du niveau général de compétences que vous pouvez atteindre tout au long de votre carrière.
Et lorsque je travaille avec des développeurs qui ont travaillé sur des projets de compétences différentes, qui ont été formés de différentes manières et qui ont résolu différents types de problèmes, j’apprends constamment de nouvelles choses.
Cela ne veut pas dire qu’il n’y a pas de conversations sur des choses que nous pouvons mettre en œuvre en équipe ou en partenariat, mais cela peut empêcher de bloquer le potentiel de croissance en tant que programmeur.
Je pourrais continuer à ce sujet, mais en bref: si vous allez travailler avec d’autres, assurez-vous qu’ils ont de l’expérience, qu’ils aiment utiliser le même type de paradigmes que vous, qu’ils sont ouverts à une conversation réfléchie et qu’ils apportent un variété d’expérience à la table.
En fin de compte, cela peut aider à améliorer à la fois vos capacités et la qualité de ce que vous et votre équipe apportez à la table.
Il y a toujours plus
Comme je l’ai dit plus tôt dans le post, il y a toujours plus. Je parlerai probablement plus de l’aspect commercial de celui-ci dans les prochains articles.
Pour l’instant, cependant, je vais laisser ce que j’ai écrit là où il se trouve et j’irai à partir de là plus tard.