Czy każdy programista powinien prowadzić dziennik „Lessons Learned”? [Zamknięte]

Za każdym razem, gdy kończę projekt, zawsze jest coś, czego się nauczyłem (w przeciwnym razie nie wydaje mi się to bardzo motywujące). Ale nie pamiętam wszystkiego i znacznie później mogę natknąć się na ten sam problem, który napotkałem w poprzednim projekcie, ale już nie w jaki sposób go rozwiązałem (a przynajmniej jakie podjąłem próby).

Czy dobrze byłoby zapisać to w jakimś czasopiśmie? Wiem, że zapisywanie rzeczy przypomina pisanie dokumentacji (co nie wszyscy lubią robić) i mam nadzieję, że nasza pamięć posłuży nam w razie potrzeby. Ale mając to udokumentowane, można je udostępnić innym programistom i dowiedzieć się, czego się nauczyli.

Więc co o tym myślisz?

Blog techniczny byłby tutaj świetnym wyborem, aby uzyskać skonsolidowane doświadczenie. Nawet to pomoże innym na całym świecie uczyć się na własnych błędach :)

Dobrym pomysłem wydaje się przejrzenie tego, co zostało zrobione pod koniec projektu i napotkane problemy, oraz sprawdzenie, co spowodowało te problemy i jak ich uniknąć. Dobrym pomysłem jest także zapisanie go w dzienniku, ponieważ ułatwia późniejsze przywołanie i uniknięcie tych samych problemów.

Z drugiej strony, dzielenie się musi być wykonywane ostrożnie. Oczywiście jest to pomocne dla innych programistów i kierowników projektów, ale jeśli pracujesz z klientami i ci klienci mogą przeczytać o problemach, które miałeś w przeszłości, będą mniej skłonni do rozpoczęcia / kontynuowania współpracy z tobą, ponieważ:

• Będą czuć, że masz więcej problemów z projektami niż z innymi ludźmi (nawet jeśli jest to źle),
• Nie chcą, abyś publikował informacje o ewentualnych problemach napotkanych w ich projektach.

Mam dziennik Elder Scrollsy, w którym zapisuję rzeczy za każdym razem, gdy uczę się czegoś nowego. Jak możesz sobie wyobrazić, stało się dość duże i pełne informacji.

W rzeczywistości zastanawiałem się nad stworzeniem oprogramowania, które pozwala mi pisać notatki i oznaczać je podobnie do tego, co strony SE robią z pytaniami.

Byłbym w stanie:

• Szukaj postów według daty.
• Szukaj postów według tagów.
• Szukaj postów według trudności.

Byłoby to dla mnie bardzo pomocne.

Próbowałem tego raz, z codziennym dziennikiem rzeczy, które zrobiłem, zastanawiając się, co mogło pójść lepiej i co powinienem wypróbować innym razem. To nie były rzeczy techniczne - chodziło o interakcje z innymi ludźmi w zespole, decyzje podejmowane na spotkaniach i tak dalej (tak, ta firma miała wystarczająco dużo spotkań, że miałem coś do pisania na co dzień!).

W końcu odkryłem, że czasopismo jest pamięcią tylko do zapisu: może pisanie go pomogło mi uporządkować myśli lub ocenić, co zrobiłem, ale po około sześciu tygodniach odkryłem, że nigdy nie wróciłem i sprawdziłem, co zrobię napisane, więc przestałem to przechowywać.

Jeśli chodzi o uwagi techniczne, tak naprawdę nie przechowuję ich, chyba że muszę przedstawić się na konferencji lub kliencie. W przeciwnym razie zestaw zakładek w Pinboard.in wystarczy mi.

Absolutnie należy prowadzić dziennik wyciągniętych wniosków i wyciągniętych wniosków. Ten pierwszy konsoliduje najdroższy rodzaj nauki, który uzyskano dzięki bezpośredniemu doświadczeniu. Ten ostatni wymaga / pobudza proaktywne uczenie się, które jest niezbędne, aby nie ssać.

Kronikowanie jest jednym z najstarszych znanych narzędzi samorozwoju i skłania do refleksji (własnej), która jest jeszcze starszą metodą. Trzeba obu.

Absolutnie. Prawdziwa historia: wkrótce po przeczytaniu tego pytania napotkałem problem, o którym wiedziałem, że go wcześniej rozwiązałem (problem z konfiguracją, jeśli ma to znaczenie). Przejrzałem notatnik „Lessons Learned” (wersja papierowa i długopis) i znalazłem rozwiązanie: skopiuj plik a do lokalizacji b.

Ten notatnik pomaga mi na dwa sposoby: po pierwsze, zapewniając miejsce na znalezienie odpowiedzi na wcześniej zadane pytania i rozwiązane problemy, a po drugie, wzmacniając wiedzę, zapisując ją (coś w rodzaju wyjaśnienia komuś innemu).

Oczywiście od czasu do czasu zgubiłem ten zeszyt ...

Do tego służy system zarządzania projektami / problemami, taki jak TRAC, Jira lub do czego masz. W pracy umieszczam szczegółowe komentarze, procedury, zależności w naszym TRAC i Jira, więc gdy napotkamy wcześniej widziany problem, proste wyszukiwanie daje nam odpowiedź.