Zwalczanie efektu Einstellung [zamknięte]

Einstellung Effect odnosi się do „predyspozycji danej osoby w celu rozwiązania danego problemu w specyficzny sposób, mimo że nie są«lepsze»lub bardziej odpowiednie metody rozwiązywania problemu.”

Jako programista z przyzwoitym doświadczeniem, jak można zwalczyć tę tendencję do ciągłego rozwiązywania problemów z „wypróbowanych i prawdziwych” ścieżek z poprzednich doświadczeń?

Aby podać dwa bardzo konkretne przykłady, buduję aplikacje internetowe od dłuższego czasu, wystarczająco długo, aby wyprzedzić szerokie zastosowanie frameworków Javascript (np. JQuery) i lepszych frameworków aplikacji internetowych (np. ASP.NET MVC). Jeśli mam pracę z klientem, w której mam problemy z sytuacją lub pilne problemy związane z domeną problemów lub regułami biznesowymi, zazwyczaj używam tego, co wiem, aby spróbować znaleźć rozwiązanie. Dotyczy to bardzo brzydkich rzeczy takich jak

document.getElementById 

lub używając ASP.NET z kontrolkami związanymi z szablonami (DataList / Repeater) zamiast zastanawiać się, jak ponownie zarchiwizować rzeczy za pomocą ASP.NET MVC.

Jedną z technik, które stosowałem w przeszłości, są osobiste projekty, które istnieją po prostu w celu eksploracji tych nowych technologii, ale jest to trudne do utrzymania. Jakie inne podejścia można zalecić?

To świetne pytanie. I myślę, że to nie tylko starsi programiści, którzy wpadają na to - wczesne zajęcie się tym może być świetnym sposobem na przyspieszenie rozwoju umiejętności.

Istnieją dwie strony tego problemu - jedna jest zła, a druga jest naprawdę dobra .

Źle - wybranie niewłaściwego rozwiązania

Oto przykład - jak niedoświadczony programista, można mieć tylko naprawdę rozwiązać dwa problemy przed, problemy A i B . W tym momencie wiesz, że istnieją problemy, których nie znasz, ale biorąc pod obiektyw własnego doświadczenia, dużo, co widać wygląda jak to może być lub B .

Nadchodzi nowy problem. Do was, to nowy problem wygląda jak problemu A , więc go rozwiązać tak, jak zwykle rozwiązać A . Coś jest nie tak, a to trwa dłużej, a podczas pracy w efekcie realizacji jest to nowy problem, C . To odmiana A , o której istnieniu nie wiedziałeś.

Co więc robisz, aby nie popełnić tego błędu ponownie? Dwie rzeczy:

1. Dowiedz się, co różniło się w tym nowym problemie. Dowiedz się, jakie podejścia mogły działać inaczej i dlaczego.
2. Skataloguj ten problem i przejdź do rozwiązywania kolejnych nowych problemów.

Powinno to pomóc w naturalny sposób rozwiązać ten problem. Kiedy masz 10 lat doświadczenia, znasz problemy od A do Z, a twój repertuar rozwiązań jest obszerny.

Dobra - wydajność

W prawdziwym świecie, z terminami i ograniczonymi zasobami, korzystanie z tego, co wiesz, nie zawsze jest złe:

1. Na początku procesu rozwiązywania problemu porównujesz nowy problem ze wszystkimi znanymi problemami.
2. Spróbujesz rozpoznać znaki i zdecydować, który zestaw problemów to wygląda.
3. Jeśli nie uda się dopasować w 100%, doświadczony programista zważy ryzyko spędzenia więcej czasu na odkrywaniu na ryzyko potencjalnie wadliwego wykonania. Jeśli ryzyko zmarnowanego czasu jest zbyt wysokie, po prostu kontynuuj z tym, co wiesz.

To nie jest złe - wykorzystuje analizę ryzyka, aby wybrać wydajność ponad 100% dokładności. Robi się to każdego dnia i wszyscy bylibyśmy związani rzeczami, które nigdzie nas nie doprowadziłyby, gdybyśmy tego nie zrobili.

Tak więc, aby odpowiedzieć na twoje pytanie:

Jako programista z przyzwoitym doświadczeniem, jak można zwalczyć tę tendencję do ciągłego rozwiązywania problemów z „wypróbowanych i prawdziwych” ścieżek z poprzednich doświadczeń?

1. Szukaj i kataloguj nowe problemy
2. Lepiej wybierz właściwe rozwiązanie problemu; zamiast po prostu wiedzieć, które rozwiązanie, dowiedz się, dlaczego tak jest.
3. Ćwicz i doskonal swoje umiejętności decyzyjne. Czasami wydajność jest właściwym wyborem, a poprawa rozpoznawania tamtych czasów przyniesie wymierne korzyści w świecie rzeczywistym.

Przeznacz 20% swojego czasu pracy na doskonalenie umiejętności / robienie rzeczy właściwie zamiast szybko. W przeciwnym razie powoli zaczniesz pozostawać w tyle. Może to oznaczać, że wykonasz mniej pracy w krótkim okresie, ale w dłuższej perspektywie ta inwestycja się opłaci.

Najtrudniejszą częścią jest opieranie się naciskowi, aby ciąć na tym zakręty. Dopóki nawyk nie zostanie zakorzeniony, po prostu nie rób tego kąta. Gdy znajdziesz się w punkcie, w którym uznajesz tę inwestycję w swoje umiejętności za „normalną”, możesz następnie od czasu do czasu przyspieszyć projekt. W międzyczasie nie uważaj tego czasu za opcjonalny i odpowiednio określ swoje prognozy.

Moim zdaniem rozwój oprogramowania nie zawsze polega na znalezieniu absolutnego * najlepszego * rozwiązania, ale na załatwieniu sprawy. Może więc, jeśli nie zawsze rozwiążesz problem w najlepszy sposób, to nie koniec świata.

Jeśli jednak uważasz, że robienie rzeczy w najlepszy sposób jest ważne, myślę, że najlepszy zakład zostałby opracowany jako część zespołu. Omów projekt i zrób recenzje kodu ze współpracownikami. Ponieważ ludzie zwykle mają różne pochodzenie i preferencje, od dwóch do trzech osób, powinieneś mieć kilka różnych podejść do problemów i rozwiązań.

Jako programista z przyzwoitym doświadczeniem, jak można zwalczyć tę tendencję do ciągłego rozwiązywania problemów z „wypróbowanych i prawdziwych” ścieżek z poprzednich doświadczeń?

Regularnie refaktoryzuj. Refaktoryzacja wymaga przeanalizowania kodu, który napisaliśmy w przeszłości. Możemy wykorzystać ten czas, aby zobaczyć stary kod ze świeżą perspektywą. Dopóki nadążasz za głównymi zmianami technologicznymi, możesz wprowadzać aktualizacje, które uznają za konieczne.

Jeśli mam pracę z klientem, w której mam problemy z sytuacją lub pilne problemy związane z domeną problemów lub regułami biznesowymi, zazwyczaj używam tego, co wiem, aby spróbować znaleźć rozwiązanie.

Dobry. Koncentrujesz się na potrzebach klienta, a nie na własnych celach. Tak trzymać.

Dotyczy to bardzo brzydkich rzeczy takich jak

document.getElementById

lub używając ASP.NET z kontrolkami związanymi z szablonami (DataList / Repeater) zamiast zastanawiać się, jak ponownie zarchiwizować rzeczy za pomocą ASP.NET MVC.

W formularzach internetowych nie ma nic złego. MVC nie ma zastępować formularzy internetowych. To nie jest czas na naukę nowej technologii. Pamiętaj o trójkącie. Refaktoryzuj, kiedy masz czas. Zobacz także pierwsze zdanie.

Jedną z technik, które stosowałem w przeszłości, są osobiste projekty, które istnieją po prostu w celu eksploracji tych nowych technologii, ale jest to trudne do utrzymania. Jakie inne podejścia można zalecić?

Co jest trudne do utrzymania? Mam nadzieję, że nie utrzymujesz projektów, z których możesz się uczyć. Jeśli tak, wyrzuć przykładowe projekty. Nie ma nic złego w tworzeniu jednorazowych projektów do celów edukacyjnych. To bardzo dobra rzecz. Zobacz pierwsze zdanie.

Próbowałem i prawda! = Źle. „Efekt Einstellunga” został tutaj nieco wyjęty z kontekstu. Testy dotyczą osób optymalizujących „otwieranie słoika”. Ludowe metody „otwierania słoika” są ograniczone i z czasem nie ulegają ulepszeniu (z wyłączeniem jakichkolwiek filmów science fiction). W oprogramowaniu najlepszy sposób na „osiągnięcie zadania X” zmienia się z czasem.

Coś, co pomaga myśleć nieszablonowo, ma faktyczną praktykę w tym zakresie. Edward De Bono napisał wiele książek o myśleniu bocznym i powiązanych tematach.

Ale w danym punkcie decyzyjnym najważniejsze jest ocena ryzyka i uwzględnienie go. Walc z niedźwiedziami autorstwa De Marco i Listera to jedna z najlepszych książek na ten temat, jeśli jest stosowana do tworzenia oprogramowania.

Ekstremalne programowanie i inne zwinne metodologie proponują, aby po prostu rutynowo eksperymentować z nowymi rozwiązaniami (skokowymi). Eksperymentuję z różnymi technologiami podczas uruchamiania projektów, co kilkakrotnie uratowało mnie przed zakochaniem się w prawdziwych i wypróbowanych, a czasem odkryciu nowego technologicznego klejnotu.

Jako zespół możesz zmienić grupę, rozpoznając niesamowitą przełomowość. Często używam do tego nowych ludzi, ponieważ nie są załamani na normalny sposób robienia rzeczy. Jest to nieco menedżerska odpowiedź - ale nawet jako doświadczony inżynier myślę, że możesz zdać sobie sprawę, że czyjaś opinia może być mniej tendencyjna, więc rozważ to z rankingiem co najmniej tyle samo ważnym, co twoja opinia (może nawet więcej).

Czy jesteś pewien, że nie chodzi tylko o to, co zamiast dokumentu document.getElementById jest naprawdę stratą czasu, bez względu na to, jak bardzo jesteś do tego przystosowany?

Edycja: Właśnie zdałem sobie sprawę, że oba twoje przykłady dotyczą narzędzi, może to być spowodowane tym, że uważasz zmianę narzędzi za największy kamień milowy w rozwoju twoich umiejętności. Dobry programista potrzebuje niewiele więcej niż kompletny język Turinga, aby móc zdziałać swoje cuda, to znaczy, że narzędzia nie są ważne, ale to, czego już używasz, nie jest kompletnym zestawem narzędzi. Jeśli przejście z jednego narzędzia do drugiego jest największym postępem, jaki możesz sobie wyobrazić, być może zatrzymałeś się w mniej wymiernych obszarach.

Jako programista z przyzwoitym doświadczeniem, jak można zwalczyć tę tendencję do ciągłego rozwiązywania problemów z „wypróbowanych i prawdziwych” ścieżek z poprzednich doświadczeń?

Samoświadomość

Bądź świadomy swoich tendencji, swoich słabości i swoich mocnych stron.

Świadome decyzje

Podejmuj decyzje jasno i świadomie. Nie skacz, aby coś zrobić bez świadomego zastanowienia się, jak to zrobisz.

Ucz się i aplikuj

Kontynuuj naukę nowych technik i zastanów się, gdzie można je zastosować. Po napotkaniu sytuacji, w której można go zastosować, wykonaj analizę kosztów i korzyści. Czasami korzyść z wypróbowania czegoś nowego przewyższa korzyść znanego rozwiązania.