Technologiczno-narzędziowa zasada Pareto

Reguła Pareto jest ciekawą i dość znaną obserwacją. Mówi o tym, że większość rezultatów ma swoje źródła w mniejszości przyczyn. Na przykład w 1989 roku na najbogatsze 20% populacji przypadało 80% światowego PKB. Innymi słowy – to co z pozoru niewielkie zwykle wiele znaczy. To zaś co dominujące często nie jest aż tak ważne.

Jakiś czas temu rozpocząłem współpracę z nowym klientem. W kwestii używanych technologii nie różni się od innych – te same frameworki, języki i charakter pracy. To co go wyróżnia to podejście do narzędzi. Zamiast przeciętnego laptopa z Windowsem i mnóstwem korpo-oprogramowania konsumującego zasoby – MacBook. Zamiast siermiężnych Teamsów – Slack. W miejsce Outlooka – Google Workspace.

Wydawać by się mogło, że 80% wyniku powinny dawać technologie. Tymczasem okazuje się, że narzędzia, które zdają się być tymi paretowskimi dwudziestoma procentami – potrafią zabić lub ożywić produktywność programistów.

Z pozoru niewielkie spowolnienie powodowane przez ociężałe, niedostosowane do wymagań działów IT korporacyjne proxy, antywirusy i innego rodzaju oprogramowanie monitorujące jest w stanie ograniczyć wydajność programisty – moim zdaniem – nawet o połowę. Coś co w normalnych warunkach zajmuje 2 minuty może w takim środowisku zająć minut 10, a to już wystarczająco, by deweloper się zirytował i rozproszył. 2 minuty pozwolą pozostać we flow, a 10 minut frustracji przerodzi się w wizytę w kuchni albo chill-roomie, a następnie w kolejne kwadranse spędzone na powrocie do skupienia.

Podobnie sprawa ma się w zasadzie ze wszystkimi narzędziami. Oczywiście wybór dramatycznie złej technologii może mieć nawet poważniejsze konsekwencje – zastanówmy się jednak, czy tak naprawdę mamy wybór? Rynek pracy w ostatnich latach jest zdecydowanie rynkiem pracownika. Rekruterzy piszą już nawet ogłoszenia wierszem i ogłaszają się na egzotycznych portalach, byle tylko zachęcić koderów do zmiany pracodawcy. To trendy rynkowe decydują obecnie o wyborze technologii, a nie rozsądna, chłodna, inżynierska analiza. Mało kto będzie dziś na tyle odważny by prowadzić projekt np. w Ext JS. O narzędziach jednak decydować wciąż można. I często decyduje się zdecydowanie wbrew preferencjom programistów. A choć gazety lubią się w sensacyjnym tonie rozpisywać o ich rozpieszczeniu, to jednak ich sympatie względem pewnych narzędzi wynikają po prostu z tego, czy są one wygodne, czy nie. Wygodne, czyli pozwalające sprawnie wykonywać pracę. A mało co potrafi być tak irytujące jak codzienne pytanie na daily – czy coś cię blokuje – gdy wiemy, że są to narzędzia, których firma nie ma ochoty zmienić.

Dlatego warto przemyśleć, jakie narzędzia lubimy, które uważamy za najlepsze. Jeśli zarządzamy i decydujemy – dobrze słuchać w tej materii koderów. Jeśli zaś programujemy – warto przed zmianą pracodawcy lub klienta zapytać, z jakich narzędzi będziemy mogli korzystać? Może to być o pytanie o wiele ważniejsze niż mogłoby się wydawać…

Comments

  1. Pingback: dotnetomaniak.pl

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *