A co by było, gdybyś sporządził listę „ogólnych wskazówek rozwojowych”? Wtedy możesz podzielić się nim ze wszystkimi raz, zamiast ciągle udzielać niechcianych porad.

Możesz również przekazać go przyszłym uczniom i miejmy nadzieję, że dobrze rozpoczną od pierwszego dnia

Czy Twoja grupa badawcza ma cotygodniowe spotkania? Jeśli tak, możesz poświęcić 5–10 minut na początku każdego spotkania na hacki dotyczące przepływu pracy / programowania, które Twoim zdaniem byłyby pomocne. Jeśli Twoja grupa nie ma okresowych spotkań, warto je zrealizować choćby tylko w tym celu. Na początku studentom może się to nie podobać, ale wzrost wydajności netto będzie korzystny dla wszystkich. Nie będziesz też musiał wskazywać wielu uczniom indywidualnych nieefektywności (przynajmniej nie tak często).

Wdrażam coś podobnego, gdy uczę, ale jest to bardziej ukierunkowane na studia licencjackie. Omawiam takie rzeczy, jak jak / gdzie ubiegać się o stypendia i staże, wskazówki dotyczące dostania się do szkoły średniej, poruszanie się po polityce miejsca pracy, a także od czasu do czasu kilka prostych rzeczy związanych z przepływem pracy. Studenci skomentowali, że jest to bardzo korzystne.

Podoba mi się pomysł @Nate'a Eldredge'a, aby stworzyć listę ogólnych wskazówek dotyczących rozwoju, ale myślę, że samo to może mieć pewne wady. Napisanie czegoś naprawdę wysokiej jakości, obejmującego wszystko, może być czasochłonne. Niektórzy uczniowie mogą nawet tego nie przeczytać (ale ci uczniowie prawdopodobnie też nie będą zwracać uwagi na nic, co powiesz podczas spotkania). Inni uczniowie mogą nie zrozumieć twoich sugestii, dopóki nie zobaczą ich w praktyce. To faktycznie przydarzyło mi się pewnego dnia. Wiedziałem o Trampie Emacsa, ale nigdy nie rozumiałem, jak go wdrożyć. Widziałem tweeta z animowanym plikiem .gif pokazującym, jak to działa i od tamtej pory używam go codziennie. Być może omawianie tych rzeczy na spotkaniach i tworzenie listy wskazówek rozwojowych z czasem może się sprawdzić.

Możesz także określić wymagania grupowe, które ułatwią Ci życie. Na przykład możesz wymagać, aby Twoja grupa korzystała z Dropbox (lub czegoś podobnego) do udostępniania dokumentów, a także w procesie, który może zachęcić ją do wykorzystania go do własnych materiałów. (Na początek możesz zachować dokument ze wskazówkami programistycznymi w folderze udostępnionym w Dropbox!) Myślę, że warto osobiście wskazać nieefektywność, ale zdecydowanie musiałbyś wybierać swoje bitwy i robić to tylko od czasu do czasu.

EDIT”

Niektóre komentarze wskazywały, że kilka zaleceń PO jest „obiektywnie błędnych”, ale myślę, że pomija to punkt. Jeśli starszy badacz widzi sposoby, dzięki którym jego / jego grupa może być bardziej wydajna, prawdopodobnie warto się nimi podzielić, nawet jeśli nie ma idealnego przepływu pracy. Udostępnianie kodu przez Dropbox może nie być najlepszym rozwiązaniem, ale z pewnością byłoby lepsze niż przesyłanie plików e-mailem w tę iz powrotem. (Nie jestem nawet pewien, czy OP sugerował, że kod udostępniania grupowego na Dropbox; to tylko przykład). Możliwe jest również, że uczniowie mogą mieć sugestie dla grupy (lub nawet przywódcy grupy), a te można rozwinąć, zbierając wszystkich razem.

Jeden komentarz sugerował również, aby nie wdawać się w świętą wojnę Vima / Emacsa ... ale czy uczniowie wiedzą przede wszystkim o Vimie, Emacsie, innych edytorach / IDE i ich możliwościach? Z pewnością nie wiedziałem o nich jako student studiów magisterskich, a rozwijanie umiejętności z edytorem pomogłoby mi ogromnie (nie jestem w dziedzinie STEM, więc te narzędzia są rzadkie; nie jestem pewien co do dziedziny OP, ale znowu, to tylko przykład). Z pewnością można omówić cechy i możliwości bez wdawania się w świętą wojnę. Samo ujawnienie może być niezwykle korzystne.

Moje podejście byłoby znacznie bardziej subtelne w porównaniu z metodą João. Zamiast mówić im, co mają robić, pokazałem im mój przepływ pracy, odpowiadając na podobne pytanie. Upewnij się, że robisz to na swoim komputerze, nie jeździj na czyimś komputerze.

Przykładem może być pokazanie im swojej „metody programowania” z dużym oknem kodu. Używaj skrótów lub interfejsu wiersza polecenia, gdy obserwują, co robisz. Możesz powiedzieć coś w stylu „foobar oszczędza mi dużo czasu”, ale nie za dużo. Uczniowie, którzy chcą większej wydajności w swoim przepływie pracy, w naturalny sposób zauważą to, co dla nich działa.

„Możesz doprowadzić konia do wodopoju, ale nie możesz zmusić go do picia”

Osobiście to właśnie mówię moim studentom na początku ich pracy, a moje uzasadnienie w nawiasach.

1. Użyj Dropbox / GDrive / co masz do tworzenia kopii zapasowych (jeśli stracisz pracę na tydzień przed przesłaniem, masz spieprzone).

2. Skonfiguruj wiki do dokumentacji projektu na serwerze wydziału (jeśli nie robisz później notatek, nie wiesz, co napisać w rozprawie).

3. Użyj Mendeleya do zarządzania referencjami (poświęć czas na pisanie .bib lub pisanie rozprawy, do wyboru).

4. Skonfiguruj LaTeX i napisz w nim swoją rozprawę (Word jest dobry dla maksymalnie 3 -page dokumentów).

5. Używaj maszyn wirtualnych w ich środowisku pracy i regularnie wykonuj kopie zapasowe (nie trać czasu na ponowne konfigurowanie).

6. E-mail do obu przełożonych w CC i zawsze używaj opcji „Odpowiedz wszystkim” na e-maile związane z pracą (nie mogę Ci pomóc, jeśli nie wiem, co robisz).

7. Często przychodź do laboratorium (rozmawiając ze starszymi naukowcami, nauczysz się najszybszych i najmądrzejszych sposobów osiągania swoich celów).

8. Wysyłaj mi raporty z postępów często (jeśli yo nie pytaj o recenzje Nie mam pojęcia, czy Twoja praca jest na nie gotowa).

(Opcjonalnie)

1. Uzyskaj SSD do laptopa, jeśli ich na to stać (cierpliwość jest warta więcej niż pieniądze).

Jeśli chodzi o powstrzymywanie się od wskazywania wszystkiego, to jest łatwe: to ich praca i ich wybór zrobić dobry, czy nie. Mówiąc słowami Morfeusza: „Mogę tylko pokazać ci drzwi. To ty musisz przez nie przejść”.

Wybierz kilka ważnych rzeczy i zalicz je do „najlepszych praktyk” (rozsądne podejście lub posiadanie pewnych standardów dotyczących nazw plików i zmiennych wydaje mi się o wiele ważniejsze niż rozmiar okna edycji lub skrótu klawiaturowego). Podaj kilka zasad lub przykładów, które pokazują wytyczne w działaniu, i śmiało, bądź trochę wybredny.

Inne rzeczy - (użyj większego okna edycji, skrótu) naprawdę nie są „ważne” jako najlepsza praktyka. Stanie nad ramieniem ucznia i mówienie: naciśnij ten klawisz itp., Jest naprawdę irytujące i może być przytłaczające, jeśli rzuca się w niego zbyt wiele informacji / szczegółów. (Który szczegół jest ważny, po prostu ty jesteś pomocny?) I po pewnym czasie mogą mieć całkiem uzasadnione powody, aby zrobić to inaczej (mogą znaleźć inne skróty, które lepiej pasują do ich „stylu” lub które uznasz za przydatne, jeśli obserwuj ich.

Jednak to powiedziawszy - prawdą jest, że techniki oszczędzania czasu, które oszczędzą im frustracji, nie są od razu oczywiste dla nowicjuszy. Odkryłem, że najlepszym sposobem jest pozwolenie komuś na zabawę najpierw narzędzia, aby mogli napotkać niektóre frustracje. Ale przede wszystkim po prostu odpowiedz na podstawowe pytania, a jeśli jest konkretne pytanie o „łatwiejsze” sposoby, to powiedz im. Później - zrób to sam jeden, aby pokazać, jak wykonałbyś to zadanie, wskazując własne praktyki i jak unikają one konkretnych frustracji. Jednak w tym momencie po prostu pozwól sobie wybrać sposób, w jaki uznasz to za najlepszy. Nie warto sugerować tego za każdym razem pomagasz im.

Chociaż nie jestem zaangażowany w szkolenie studentów w zakresie codi ng, musimy szkolić początkujących użytkowników na sprzęcie, który jest nieco trudny i wymaga długiego okresu szkolenia, aby stać się ekspertem, więc proces ma pewne podobieństwa.

Wybierz aspekty, które są prawie niepodlegające negocjacjom, ponieważ są ważne. Nie przejmuj się zbytnio, gdy nowicjusze wciąż ignorują wskazówki, które im dałeś, a które opierają się na tym, co eksperci zwykle uznawali za „przydatne” strategie ułatwiające sobie życie.

@haff zasugerował w komentarzu:

Jeśli Twoja grupa badawcza ma cotygodniowe spotkania, możesz również poświęcić około 5 minut na początku każdego spotkania na zademonstrowanie hacków dotyczących rozwoju / przepływu pracy.

Ciekawy pomysł! Teraz trochę zmienmy:

Poświęć trochę czasu na spotkanie w grupie (niekoniecznie tylko 5 minut i niekoniecznie na każdym spotkaniu) na chodzenie w kółko, dając uczniom możliwość podzielenia się własnymi hacki dotyczące przepływu pracy ze sobą .

Powiadom ich w e-mailu z wyprzedzeniem, aby mogli pomyśleć o tym, jakie zmiany by chcieli udostępniać lub prezentować. Innymi słowy, nie zaskakuj ich. I pozwól poszczególnym osobom zdecydować, że nie będą się czymś dzielić.

Ponadto możesz zorganizować kilka spotkań warsztatowych, podczas których ktoś zgłosi się na ochotnika do zajęcia stanowiska demonstracyjnego, tworzenia kodu lub testowania jak mistrzowska klasa w dziale muzycznym. Następnie poproś uczniów, aby konstruktywnie skomentowali, tak aby każdy z nich znalazł coś, co mógł pochwalić. Jeśli chcą przedstawić konstruktywne sugestie, jak skuteczniej lub wydajniej debugować, to w porządku, ale głównym celem powinno być nauczenie się dostarczania pozytywnej opinii rówieśnikom .

To jest niezwykłe, o ile skuteczniejsze są wskazówki i poprawki ze strony kolegi ucznia , w porównaniu z tym, że wszystkie pochodzą od profesora .

Nie widzę nic złego w przedstawianiu sugestii. W końcu ich uczysz i nie wydaje się nierozsądne udzielanie porad, jak ulepszyć ich sposób pracy, zwłaszcza jeśli sugestia ma na celu uczynienie czegoś obiektywnie bardziej efektywnym.

Całkowicie się zgadzam, że zmuszanie uczniów do pracy w określony sposób może nie być dobrym rozwiązaniem, jeśli naprawdę nie ma to dla nich sensu. Z pewnością z mojego doświadczenia wynika, że ​​jedną z najbardziej przydatnych rzeczy w pracy z kimś doświadczonym (czy to w formalnym środowisku nauczania, czy nie) jest to, że zna wiele użytecznych sztuczek, które niekoniecznie są intuicyjnie oczywiste.

Po przedstawieniu sugestii możesz pozostawić to im, czy chcą podjąć działania, czy nie, ale przynajmniej wtedy mają informacje.

TL; DR: Rozróżnij „wskazówki i triki” od „wskazówek / dobrych praktyk”. Podaj wskazówki dotyczące pierwszego i spróbuj wymusić drugie.

Jeśli jest to możliwe w Twojej sytuacji, możesz zorganizować małą prezentację. Coś w rodzaju „wskazówek i sztuczek EditorX”. Gdzie możesz podzielić się z nimi kilkoma wskazówkami i sztuczkami dotyczącymi lepszego korzystania z edytora, bez zwracania szczególnej uwagi na żadnego ucznia.

Nie różni się to zbytnio od branży. Pracuję jako inżynier oprogramowania i co tydzień prowadzimy rozmowy, podczas których możemy zaprezentować coś interesującego w tej dziedzinie. Co kilka tygodni ktoś będzie pokazywał kilka wskazówek i trików. Zachęcamy do tego wszystkich.

Dla mnie zaletą tego podejścia jest to, że dzięki małej wersji demonstracyjnej inni ludzie zobaczą korzyści (na przykład szybszy rozwój). Zaciekawią ich też, jak znaleźć więcej porad i wskazówek, którymi mogą się podzielić.

Mówiąc o wskazówkach i trikach, są też inne rzeczy, które nie są po prostu wskazówkami i trikami, ale raczej wskazówkami i dobrymi praktykami, których należy przestrzegać. To, czy używasz skrótu, czy nie, jest całkowicie opcjonalne, lub gdy zdasz sobie sprawę, że w IntelliJ (IDE) jest ustawienie Zero Latency Typing i chcesz go użyć. Jednak z drugiej strony mamy takie rzeczy, jak kontrola wersji, rozsądne nazwy zmiennych, przechowywanie pewnej dokumentacji, którą naprawdę powinni robić. Sposób, w jaki go używają, jest ponownie w części „wskazówki i triki”, ale powinni przynajmniej znać korzyści z jego używania i być do tego mocno zachęcani.

Sposób, w jaki to robiłem, gdy nauczałem (w środowisku akademickim), polegał na wymuszaniu używania tych rzeczy. Nie jestem pewien, czy możesz wyegzekwować to na swoim stanowisku, ale jeśli to w ogóle możliwe, zrobię to. Czy możesz ustawić „wytyczne” dla swojej grupy? Jeśli tak, zastosuj wytyczne dotyczące kodowania i poproś o ich udokumentowanie. Umieść w tym dokumencie wszystko, co istotne, na przykład jeśli chcesz etui węża lub etui na wielbłąda. Podaj kilka wskazówek, jak wymyślić dobre nazwy zmiennych i klas. Wymuś wypychanie do git (svn, ..) i pokaż przykłady dobrych komunikatów o zmianach.

(Sposobem na wymuszenie dobrego stylu kodu może być użycie narzędzia, które sprawdza składnię, wzorce nazw zmiennych itp. Istnieje kilka dobrych linterów dostępnych dla wielu języków)

ci, których uczyłem, nie zawsze widzieli korzyści z tych rzeczy - ale w końcu obrócili się o 180 stopni. Ucieszyło mnie, że wytyczne są przestrzegane, a uczniowie rzeczywiście dostrzegają z tego korzyści.

Zgadzam się, to jest proces, ale jeśli nie wskażesz „błędów”, skąd oni mieliby wiedzieć, że można je poprawić?

Osobiście czepiam się wszystkiego i jak na razie działa dobrze. Chciałbym też wyjaśnić dokładnie tę kwestię i pamiętać, aby pogratulować im, gdy faktycznie zrobią coś od razu za pierwszym razem (w przeciwnym razie wydaje się, że zbytnio skupiasz się na negatywnych opiniach).

Oczywiście, tak jest Należy pamiętać, że ostatecznie to nie jest Twoja decyzja. Przedstawiasz wszystkie strony, zalety i wady, a oni decydują. Inaczej mówiąc, o każdej rzeczy wspominasz najwyżej trzy razy :)

Proponuję, abyś podszedł do tej części nauczania sztuki programowania, jakbyś był reżyserem teatralnym.

Powiedz swoim uczniom, że poświęcisz trochę czasu na obserwację każdego z nich podczas pracy, a następnie dasz im notatki.

Obserwuj ucznia i rób notatki. Zachowaj ciszę podczas obserwacji.

Po obserwacji „zrób notatki”: przeprowadź rozmowę, podczas której przedstaw uczniowi swoje spostrzeżenia dotyczące ich pracy i zaproponuj sugestie dotyczące ulepszeń. W ten sposób proponujesz swoje sugestie w uporządkowany sposób i nie będziesz ich dręczyć. Pamiętaj, aby powiedzieć im, że nie są z tego oceniani ani oceniani.

Możesz ich również zachęcić, aby zrobili to za siebie.

Spróbuję odpowiedzieć na pytanie, które faktycznie zadajesz - tj. pytania o ciebie , a nie o twoich uczniów:

Jak powstrzymać się od ingerowania w nieefektywną, ale niezłą pracę uczniów?

... i ...

Czy istnieje dobry sposób, aby [...] ale nie denerwować się, jeśli uczniowie ich nie używają?

(A moja odpowiedź dotyczy wyłącznie rady, o którą nie proszono, jak w twoim przypadku. Nic z tego oczywiście nie ma zastosowania, gdy twoi uczniowie pytają cię , jak możesz poprawić.)

Niestety, masz do czynienia z bardzo głębokimi pytaniami. Są dwa fakty, które mogą sprawić, że ludzie tacy jak ty (lub ja), którzy mają bardzo wydajne techniki robienia rzeczy , będą bardzo nieszczęśliwi, gdy zobaczysz, jak inni idą niezmiernie wolno - z jakiegokolwiek powodu, niekoniecznie związanego z w ogóle ich inteligencja.

1. Nie każda technika (używania edytora, narzędzia do przesyłania plików lub czegokolwiek innego) działa tak samo dla każdej osoby. To, co może wydawać się bardzo oczywiste (np. Skasowanie większości skrótów klawiszowych Emacsa, możliwość wyobrazenia sobie dobrego makra klawiatury przesyłanego w locie bezpośrednio z palców podczas edycji itp.) Może być całkowicie niemożliwe dla innych. Przyszedłeś do swoich technik, myśląc o nich bardzo długo i intensywnie lub intuicyjnie znajdując coś, co pasuje do sposobu, w jaki Twój mózg jest podłączony. To niekoniecznie dotyczy innych osób. Stąd wojny VI / Emacs, Windows / Linux, PC / Mac itd.
2. Nie każdy jest w stanie skorzystać z porady, nawet jeśli jest to dobre intencje, i zastosować ją w swojej pracy z różnych powodów. W rzeczywistości, z mojego doświadczenia we wszystkich dziedzinach życia (uniwersytet, praca, rodzina, przyjaciele) było bardzo, bardzo niewiele osób, które w ogóle były w stanie skorzystać z każdej porady, o którą nie poproszono cokolwiek.

Teraz. Nie będę wchodził w konkretne przyczyny tych dwóch faktów, ponieważ jest ich wiele i to nie ma znaczenia. Na przykład: dla „1”. druga osoba może po prostu o tym nie wiedzieć; jego „procedury myślowe” mogą po prostu nie pasować do tego, jak działa redaktor i tak dalej. W przypadku „2.” możesz po prostu nie być w stanie wytłumaczyć tego słowami, które muszą usłyszeć, mogą być zablokowane przez dumę itp. Może być wiele innych powodów, ale moja odpowiedź wcale nie dotyczy tych powodów. Jasne, dla wielu z nich jest sposób na obejście tego. Ale zawsze skończysz w pozycji, w której będziesz odczuwać ból, ponieważ tak bardzo chcesz pomóc , ale oni po prostu tego nie rozumieją.

Jak się powstrzymać

Po prostu zrób to. Siedź cierpliwie, gdy robią swoje nieefektywne rzeczy. Tak. Oczywiście możesz pokazać im, jak pracujesz, ale szczerze mówiąc, widzą to po prostu obserwując cię, jeśli pracujesz w środowisku rówieśniczym. Nie musisz robić z tego „rzeczy”. Są studentami i powinni używać swojego mózgu; jeśli zobaczą, że pracujesz niesamowicie szybko, podczas gdy oni zajmują dłuuuuugo czasu, powinni być w stanie zorientować się, że coś się dzieje. Chodzi o to, że to nie ty musisz coś zrobić. To nie ty jesteś tutaj odpowiedzialny.

Jeśli zobaczą, że pracujesz szybko, mogą

• poprosić Cię o wyjaśnienie, jak to robisz.
• Źle z tego powodu i ćwiczyć w domu.
• Usiądź razem z przyjaciółmi i „porównaj notatki”.
• Kup jakąś książkę i poczytaj o niej, cokolwiek to jest.
• Pobierz narzędzia, z których korzystasz, i sprawdź je.
• Albo nie przejmuj się tym wcale i trzymaj się ich powolności.

I prawdopodobnie inne rzeczy.

Jak nie denerwować się, jeśli nie korzystają z twoich wskazówek

Sekretem, jak się nie denerwować, jest przemyślenie tego z góry i usunięcie pomysłu, że można w jakiś sposób zmienić kogoś innego od razu. Nie możesz zmienić innej istoty, nigdy. Możesz ich namawiać, zmusić, dawać przykład lub cokolwiek innego, i możesz cieszyć się sytuacjami, w których rzeczywiście się poprawiają, ale tak naprawdę nie możesz zmusić ich zmiany.

A więc, czysta logika, nie ma sensu denerwować się. To jest przypadek, gdy nie widzisz rzeczywistości taką, jaka jest. Jeśli zaakceptujesz, że rzeczy są takie, jakie są, z pewnością zmniejszysz się zdenerwowanie.