Écrire des réponses à des articles est facile et amusant. Vous n'avez pas à vous pencher sur la structure de l'article pendant des heures, il suffit de suivre le plan de quelqu'un d'autre et d'exprimer clairement vos pensées sur papier. Néanmoins, j'ose suggérer qu'un regard critique «de l'autre côté» sur les questions soulevées dans l'article «
Peur et dégoût en informatique » par les
eugene_crabs respectés sera toujours intéressant. Aujourd'hui, je suis l'avocat du diable, qui défend le système inhumain.
Contrairement à lui, je ne porte pas de glands de sénateur, et j'ai quelques années d'expérience en développement en moins, et je n'ai pas d'éducation spécialisée, pour être honnête. Mais je n'ai eu aucun problème avec un intérêt fondamental pour le travail, et il me semble que la raison en est une perception légèrement différente de la réalité.
Un article pour un large Ă©ventail de lecteurs.
OBJET: Complexité excessive
Section originaleLorsque j'ai travaillé sur les glandes, j'ai vraiment aimé la propriété que je vois à travers le fonctionnement de cette chose - quels octets se déplacent, dans quelle zone de mémoire cela se produit et comment le compilateur a géré le code. Il y avait un sentiment de calme et de contrôle. Lorsque je suis passé au développement backend un peu plus tard, j'ai gloussé sur des configurations xml sans fin pour EJB ou le même ressort. Je saurais ce qui m'attend à l'avenir. Maintenant, je ne comprends tout simplement pas (et je désespérais déjà de comprendre) ce qui se passe à l'intérieur de mon attachement simple. Un tas de couches d'abstractions, des conteneurs dans des conteneurs, des tonnes de manuels, scripts, outils, versions, fichiers de configuration. Je n'ai toujours pas compris comment le projet est déployé, sur lequel je travaille depuis six mois maintenant. Et bien sûr, vous ne pouvez pas faire un monolithe, au moins dans la première étape. Assurez-vous de tout diviser immédiatement en microservices, car c'est très bien (lors de la conférence, ils ont dit qu'ils le faisaient dans l'entreprise X). Et bien sûr, nous ne pouvons pas utiliser le bon vieux client HTTP Apache pour accéder au service dont nous avons besoin toutes les quelques minutes, car ce client n'est pas asynchrone, et il n'a pas de limiteur de débit intégré, de mécanisme de contre-pression ou d'autres choses à la mode. A ma question, "Pourquoi est-ce que tout cela est nécessaire pour un chargement de 1 requête / min?" Je ne reçois qu'un regard de reproche de mes collègues, sur le front duquel brille l'inscription "Ici tu es stupide".
Un autre sujet est M. Javascript avec ses innombrables cadres. Honnêtement, je ne comprends pas comment tant de choses pourraient être inventées pour un outil qui a juste besoin de dessiner des formulaires sur des pages Web et d'envoyer de temps en temps une demande de backend. Heureusement que je fais le backend.
Sur l'exemple du frontend (et pas seulement), nous pouvons voir clairement comment nous marchons en rond: exécutons toute la logique côté serveur -> et maintenant côté client -> et maintenant encore sur le serveur et ainsi de suite à l'infini. Écrivons le frontend et le backend dans une seule langue -> et maintenant, allons dans différentes langues -> et recommençons dans une seule. Faisons des schémas pour les formats de données -> schémas uniquement pour les anciens -> et non, les schémas sont tout de même nécessaires. Un de mes acolytes vers le haut de sa bibliothèque open source de yaml au xml, tout simplement parce qu'il y a des schémas là -bas et c'est génial lorsque vous gloussez une énorme configuration, et un IDE connaissant XSD peut faire la moitié du travail pour vous. Le problème suivant découle de ce qui précède.
Bien sûr, il est agréable de manipuler des systèmes simples. Je comprends cette magie lorsque vous comprenez comment cela fonctionne dans les moindres détails: lorsque vous descendez au niveau de l'assembleur et du code machine, et lorsque vous allez encore plus loin - où le processeur est une série de portes logiques.
La situation actuelle est telle que les développements traditionnels dans les logiciels et le matériel des processeurs sont déjà très loin d'une compréhension cristalline de la façon dont cela fonctionne par une seule personne: les processeurs sont pleins de logique générée, de cache à plusieurs niveaux et de prédicteurs de branche à tel point que les bogues qu'ils contiennent ne le sont pas ils ne sont pas remarqués, ni même assumés, par des équipes de développement entières, et fleurissent si violemment qu'ils percent leurs effets au niveau de l'utilisateur. De plus, nous sommes obligés de traîner un énorme bagage d'anciennes fonctions, assurant ainsi une compatibilité descendante, sinon nous gagnerons en vitesse et en simplicité, mais perdrons dans le travail pour lequel il a été initialement conçu.
La situation est la même avec les logiciels: la compréhension, et plus encore l'écriture d'instructions d'assemblage, ne reste que dans des domaines étroitement spécialisés, et les cadres et les couches d'abstraction règnent en maître dans ce qui vit et tourne au voisinage immédiat de l'utilisateur.
Du point de vue d'une personne qui veut contrôler son code et sa machine, c'est mauvais. Du point de vue de l'utilisateur - bon, car il simplifie la compréhension, le travail et le cheminement de l'idée au produit. Le prix que nous payons pour ce désir des utilisateurs est que les capacités croissantes des processeurs sont immédiatement consommées par la complexité des programmes, ce qui, semble-t-il, n'est justifié par rien et ne présente aucun avantage (alimentation, comme ils le disaient sur mon précédent lieu de travail).
Cependant, si vous creusez plus profondément, il s'avère que nous modifions ces ressources pour augmenter l'audience en simplifiant l'interaction.
Auparavant, les terminaux de billets d'avion exigeaient la connaissance des abréviations, la compréhension du fonctionnement des compagnies aériennes et la capacité de travailler avec un terminal texte, maintenant tout utilisateur se rend sur les Aviasales conditionnelles et prend un billet bon marché sur un itinéraire difficile sans beaucoup d'hémorroïdes.
Vous ne pouvez pas rendre l'interface compréhensible pour la personne moyenne sur un terminal texte, car la clarté de l'interface est la résolution du moniteur, et de belles images qui ne font pas peur au cerveau, et de belles polices et des conseils qui apparaissent lorsque vous survolez le bouton et l'interface tactile.
Et aussi, la possibilité de tester toutes ces puces, en se concentrant sur le comportement des utilisateurs. En travaillant sur la cascade, vous déployez une version une fois par an, collectant des commentaires sur la version actuelle toute l'année. Jusqu'à un certain stade de l'interface, vous passez dix ans, dix versions. En déployant des corrections mineures et en les testant sur place, vous arriverez au même stade dans un an et demi. Mais un tel travail nécessite un rythme différent, d'autres outils et technologies, et le rejet de certaines choses. En toute honnêteté, de lécher du code: tout devrait fonctionner maintenant, car cela nécessite un processus de ce rythme.
En échange, cette course folle pour de nouvelles fonctionnalités nous donne une base d'utilisateurs croissante: plus les boutons sont pressés, plus les gens peuvent les appuyer, et la base d'utilisateurs croissante apporte de l'argent non seulement à vos salaires, mais aussi au développement de nouveaux matériels. Plus les gens pourront utiliser le smartphone de manière productive, plus ils l'achèteront, meilleur sera le matériel dans la prochaine version. Le fait que nous échangeons immédiatement ce fer non pas pour des vols vers Mars, mais pour un public croissant ... eh bien, cela peut être comparé à une entreprise qui investit tous ses revenus dans le développement, et non dans les dividendes et les bénéfices dans le rapport annuel. Seulement maintenant, pour une raison quelconque, vous justifiez quand Musk et Bezos le font, mais vous ne pouvez pas justifier l'industrie.
Pour le meilleur ou pour le pire, on peut argumenter. D'une part, la qualité des logiciels, d'autre part - des progrès constants dans le matériel, le public et des salaires élevés dans l'industrie. Je choisirai peut-être le second (même si je préférerais ralentir), mais je comprends les gens qui choisissent le premier.
Mais une chose va nous unir - nous ne pouvons rien y faire.
RE: Trop de choses
Section originaleOutils, langages, livres, conférences, cadres, etc. Longtemps derrière ces jours où, pour le développement de logiciels, il suffisait de connaître un PL, quelques bibliothèques, et c'est tout. Maintenant, nous attendons des centaines de frameworks, avec une douzaine de langues (même dans le cadre d'un projet), à la mode et pas trop de SGBD, des courtiers de messages omniprésents, des centaines de kilomètres carrés de râteaux répartis et d'autres amusements. En règle générale, un programmeur moyen n'a pas le temps d'étudier tout cela au travail (à l'exception des outils qui sont déjà utilisés dans ses projets), car vous devez y travailler. Beaucoup de gens doivent passer du temps personnel à étudier ces technologies, bien que 90% des personnes étudiées ne seront probablement jamais utiles. J'ai moi-même cinq cents articles dans ma poche, un tas de vues vidéo invisibles de conférences, et chaque appel à Habr présage une visite obligatoire à McConaughey.
Mais même travailler dur avec une langue spécifique ou, par exemple, un SGBD dans votre entreprise ne vous permet parfois pas de rester dans la tendance, car les technologies deviennent obsolètes avant de pouvoir être appliquées. Même java sera désormais publié à la vitesse de Firefox.
Grâce au flux infini de connaissances en croissance rapide, beaucoup d'entre nous se sentent comme des étudiants ou des imposteurs éternels, quel que soit le nombre de systèmes que vous avez réellement construits. Et cela est très bénéfique pour les RH et les employeurs - vous pouvez facilement faire tomber votre demande de propositions avec quelques questions délicates. Ce genre de course de rats HR est politiquement correct appelé auto-développement.
Le fait qu'il existe de nombreux outils est une suite logique du paragraphe précédent. Lorsqu'il y a beaucoup d'énergie dans la région, cela vous permet de dépenser plus d'énergie pour tester des hypothèses, dont certaines échoueront, d'autres se tariront, mais d'autres formeront la base de nouvelles normes de l'industrie. Les plaintes concernant le chaos sont similaires aux plaintes concernant l'inefficacité de l'évolution, qui, pour une raison quelconque, a créé un groupe d'espèces, dont la grande majorité s'est éteinte tranquillement, et même la majorité n'a pas beaucoup de succès et vit dans une fourchette étroite. Est-il vraiment impossible de créer immédiatement une personne qui peut survivre même au pôle nord, même dans le désert, malgré le fait qu'il est lui-même plutôt fragile - il ne court pas vite, il n'y a pas de griffes, ses dents sont petites et ternes, l'angle de vision est petit.
Il est bon de regarder le résultat de l'évolution de côté et de se demander combien de temps il a fallu pour créer un avantage tout à fait évident - un doigt flexible et un cerveau développé.
Mais au tout début du voyage, le résultat n'était pas aussi clair: les dinosaures régnaient également une fois sur la terre, et s'il y avait des analystes d'échange en leur temps, peu mettraient des rats sur certains mammifères contre ce favori évident.
Les déchets sous forme de «mauvais» outils sont un compagnon constant du chemin qui mène au sommet.
RE: Le programmeur doit ĂŞtre un analyste d'affaires et des entrevues d'emploi
Section originaleRécemment, j'ai observé une tendance à imposer l'autorité d'un département commercial aux développeurs. Maintenant, en plus d'accomplir ses tâches principales, un développeur doit comprendre le sujet au niveau d'un bon analyste et penser généralement aux affaires. Laissez-moi tranquille, je ne sais pas comment augmenter votre taux de conversion.
Entretiens d'embauche
Il s'agit de la discipline spéciale la plus importante et la plus appréciée. En effet, cela dépend si vous dormirez sur un vieux canapé écrasé dans une odnushka louée quelque part en dehors du périphérique de Moscou, ou si vous devrez vous cacher dans du carton allongé sur une canalisation principale sous un pont. Si au début de ma carrière l'interview était un peu une conversation de cœur à cœur, elle ressemble plus à un examen. Peut-être que cela est dû au fait qu'à cette époque, il n'y avait pas de salaires et d'énormes foules qui voulaient se lancer dans l'informatique ou simplement dans la mode, je ne sais pas. Mais le fait est que lorsque vous venez à un entretien pour le poste de développeur senior, avec une forte probabilité, vous rencontrerez des tâches assaisonnées de questions de quiz. «Eh bien, résolvez un problème sur un morceau de papier que nous avons volé hier avec leetetcode. Mauvais sur une unité dans la condition aux limites? Fuuuuu goof! Vous ne savez pas comment fonctionne% methodName% dans le% frameworkName% le plus en vogue. Qui l'a mis ici du tout? La sécurité! "Personne ne se soucie plus que votre tête soit arrangée différemment et vous ne pouvez pas souligner le regard méprisant et condescendant des nerds au nez haut rapidement et sans erreurs pour envelopper l'algorithme pour une tâche à laquelle vous n'avez pas encore eu le temps de penser. Comme le nombre de kilomètres de code et de systèmes de production derrière vous. Eh bien, au moins les questions du puzzle sont mortes, et merci pour cela.
Non, je ne devrais pas, bien sûr. Mais dans les conditions de nécessité d'un test d'hypothèse rapide, il est beaucoup plus productif de le faire dans la même tête qui prend des décisions sur l'architecture, tout simplement parce qu'il y a moins de frais généraux: vous devez délibérer pendant deux jours et réfléchir pendant une heure. Vous savez travailler dans un domaine - bien joué, dormez sur un canapé écrasé. Si vous ne savez pas comment, ils vous attendent dans les domaines où la fiabilité est plus importante que le progrès: espace, médecine, militaire, systèmes de communication de signaux. Ces domaines le sont et ils ne sont pas moins importants. Certes, ils paient moins. Un tel biais sur le marché, que je voudrais corriger, mais c'est quelque chose qui est plus élevé que non seulement une personne, mais la plupart des entreprises.
Soit dit en passant, ce même facteur vous permet de regarder les RH avec des questions délicates, jusqu'à "Je ne sais pas avec quoi je suis coincé, parlons déjà au rédacteur technique." Vous ne voulez pas être analyste, mais vous voulez écrire du code sur un savoir traditionnel léché? Voir ci-dessus - d'autres domaines pour vous: de bons programmeurs qui ne font pas d'erreurs et mettent en œuvre les savoirs traditionnels de manière efficace et compétente sont également très nécessaires.
RE: IT people
Section originaleNous analyserons ici quelques sous-espèces de cette population, avec lesquelles nous devons le plus souvent faire face.
Développeurs et sympathisants. Contrairement aux stéréotypes - pour la plupart pas des nerds orthodoxes, mais des gars tout à fait normaux. Mais en règle générale, il n'y a rien à leur dire. Toutes les conversations en dehors des heures de travail se résument au travail. Mais sinon, si vous êtes obligé d'apprendre tout ce technomuth 24 heures sur 24? Mon conseil est de rester loin des gars en chemises à carreaux avec des sacs à dos, sinon vous pouvez gagner une dose mortelle d'ennui. Beaucoup d'entre eux vont travailler non pas pour travailler, mais pour jouer à des jouets. Réinventons la roue, fixons un nouveau cadre (et nous ratissons l'enfer de la nourriture la nuit) et nous laisserons certainement tout tomber à mi-chemin, car ce jouet est fatigué et ils en ont apporté de nouveaux. Mais ensuite, nous nous ferons sauter les joues et dirons lors de conférences comment nous avons vaincu le problème que nous avons nous-mêmes créé. PROFIT! Ces personnes sont tout aussi facilement conduites à toutes sortes de déchets, comme des «tâches intéressantes» et des «systèmes complexes» (il est impossible de construire une calculatrice sans une douzaine de microservices dans la culture informatique), ce qui signifie en termes humains ramasser dans la merde aigre d'un mammouth, mais pour moins d'argent, réduisant ainsi les salaires de l'industrie. Comme dans une blague "- Papa, qu'est-ce qu'on va manger aujourd'hui?" "Rien, mon fils, je travaille sur des tâches intéressantes dans une équipe amicale."
Chefs de projets. Honnêtement, pendant 10 ans, je n'ai pas compris qui sont les chefs de projet et pourquoi ils sont nécessaires. Dans des bureaux complètement différents, cela ressemblait à ceci: il y a un tas de tâches, triez ce qui est là et comment, et faites-le avant une telle date. Et je suis allé chercher un café au lait des hipsters au premier étage et écrire sur Instagram quelle journée difficile c'est aujourd'hui. Ce n'est qu'une fois que j'ai vu un mec qui a construit tous ces horaires ennuyeux, jonglé avec les tâches et était notre assistant, et pas seulement un gars cool qui ne pouvait pas programmer, mais je veux vraiment un ITP.
Serveurs. Chèrement aimé par de nombreuses catégories. Grâce à leur dumping, les joons sensés et idéologiques ne peuvent pas entrer dans l'industrie - à la recherche d'un long rouble, de nombreux travailleurs mobiles sont prêts à travailler gratuitement.
Nous garderons le silence sur le reste.
Des développeurs ennuyeux qui ne parlent que de travail? Étrange, il me semble ennuyeux qui veut couper tranquillement le code selon les savoirs traditionnels finis de 9 à 18. Nous avons tous les deux tort, mais je parle d'autre chose: une telle organisation de l'esprit, dans laquelle la tâche tourne constamment dans la tête, donne un coup de pouce significatif à la vitesse de développement et test d'hypothèse. Un peu sur le bord, et l'épuisement professionnel se profile là -bas, mais il s'agit de contrôler la santé mentale. Ce qui ne nie pas le fait que certaines entreprises (nous ne pointerons pas du doigt ceux qui paient des employés de taxi après 22 heures, en les encourageant à rester au travail) se rendant compte qu'un employé qui brûle fonctionne mieux, fournissent toutes les conditions pour cette combustion.
Des projets? Vous ne savez tout simplement pas comment les cuisiner. Un projet est un outil universel: d'une part, il prend sur lui des coups de magie pour les programmeurs (un programmeur, laissé à lui-même, passe à faire des choses drôles pour sa bien-aimée), et d'autre part, les architectes et les chefs d'équipe peuvent se débarrasser de la part du lion du travail organisationnel sur celui-ci organiser des réunions, maintenir la pertinence du planning, des rapports sur le travail effectué, une communication de routine avec le client, etc.
RE: Affaires
Section originaleLe logiciel dans le monde moderne ne se fait pas simplement parce qu'il est amusant (bien que cela semble parfois). Cela se fait le plus souvent pour gagner des préposés - directement ou indirectement. Et en relation avec ce fait, nous pouvons diviser les gens en 2 catégories.
Ceux qui se soucient de la façon dont tout à l'intérieur est beau et correct.
Ceux qui se soucient de ce que sont ces gens qui se soucient de l'essence du produit qu'ils fabriquent.
En règle générale, le développeur contient ces deux catégories, juste dans des proportions différentes.
Pour les deux, j'ai une triste nouvelle.
Pour la première catégorie - du point de vue de faire de l'argent, peu importe comment la bonne architecture est choisie et la beauté du code. Tout comme toute votre sécurité, les meilleures pratiques, etc. Vous pouvez coller des béquilles, gagner des grands-mères, puis le manager qui a fait tout cela saute sur le bateau voisin "pour acquérir une nouvelle expérience", et l'équipe racks les écuries la nuit.
Pour la deuxième catégorie - 90% d'entre vous font ce que d'autres ont fait il y a longtemps. À de rares exceptions près, tous vos produits sont profondément secondaires. Néanmoins, des hommes d'affaires rusés tentent de donner une «idéologie» au prochain système de paiement, aux services bancaires en ligne et autres. J'ai vécu tout cela moi-même, et je dois dire qu'il est beaucoup plus facile de travailler lorsque vous avez une réponse claire à la question "pourquoi est-ce nécessaire?" “” - , , . , , . “ , ” . , HR, , 146% - “ , , ”.
Il se trouve qu'un homme a trouvé de l'argent. Ils ne l'ont pas fait dans la génération actuelle, et même pas il y a cent ans. L'argent s'est avéré être un excellent outil pour organiser une société hétérogène avec différents concepts de beauté et différents désirs des gens qui y sont inclus.Vous pouvez essayer d’inventer autre chose, mais jusqu’à présent vous n’avez rien trouvé de fondamentalement meilleur. Il y a, bien sûr, une motivation telle que le soutien social et l'esprit d'équipe, mais le premier est un dérivé de l'argent que l'État a digéré, et le second est l'assaisonnement, pas le plat principal. Dans une pincée, dessert.Vous êtes payé pour votre travail. Si votre travail ne rapporte pas d'argent - je suis désolé, les entreprises n'en ont pas besoin. Rude, je sais. Essayons plus doucement.. — , . , — , , . , , , , . , : - , , , — . 16% ? ! , 5%? !
Si une entreprise ne peut pas justifier une révision du code parce que son code dure trois mois, après quoi il est remplacé par un nouveau, puis s'enfuit, que faites-vous là ? Il existe un grand nombre d'entreprises pour lesquelles la révision et la refactorisation du code sont des éléments importants du processus. Et la première entreprise se concentre sur les tests d'hypothèses, pas sur le codage: cela est également normal et vous permet de trouver un nouveau créneau dans lequel vous pouvez grandir, mûrir, accumuler des graisses et commencer à pratiquer la révision et la refactorisation., , : , — , . , , , , .
RE:
, , ( ) . , . , - , . , . , , , . 35+ , “ , 25 ?” “ ?”. — .
, , . , , , , .