Blog: nie przepraszaj, że piszesz

Często korci mnie, żeby na początku wpisu napisać przestrogę typu: „może to nie jest najlepsze rozwiązanie …”, „w sumie to tylko taka mała uwaga …”, „nie jestem ekspertem w temacie …”.

Nie tłumacz się …

Wystarczy tych tłumaczeń. Nie przepraszaj, że żyjesz, programujesz i jeszcze o tym piszesz (dzięki Krzychu za uzmysłowienie tego). Czytelnik sam już sobie oceni czy mu się przyda czy nie. Czy zastosuje w bieżącym kodzie, czy będzie to tylko ciekawostka, albo po prostu szum informacyjny podczas przeglądania RSS’a (liczę się i z tym).

… że nie wiesz wszystkiego

Załóżmy, że nie wiem wszystkiego w temacie. Tak naprawdę pisząc o czymś wiesz MNIEJ* niż ktoś, kto o tym nie napisał. Czas mogłeś poświęcić na zgłębianie tematu, przykłady, uruchamianie, dyskusje z kolegami, czytanie. Poświęciłeś go jednak częściowo na powyższe rzeczy, ale też bardzo dużo poszło na napisanie o tym (chcemy wierzyć, że w zrozumiały i przystępny sposób), niestandardowy przykład, uruchamianie, testowanie, może nawet SEO.

Coś za coś.

Feedback nie jest straszny, jest cudowny

Później ktoś napisze komentarz, że w takim a takim przypadku zastosowanie jest bardzo ograniczone, że istnieje lepsza technologia niż opisana, lub że kod jest do wymiany bo o czymś zapomniałeś. Część osób przeraża taka perspektywa. „Jak to, ja wypuściłem w internet coś, co ma bugi?”. Bycie perfekcjonistą nie jest takie złe, ale w tym przypadku ważniejsze są inne rzeczy.

Pierwszy komentarz, jaki dostałem na blogu, był w stylu„to Ci tak nie zadziała, spójrz jak to powinno wyglądać”. Suuuper, dowiedziałem się co robię nie tak. Jak ja się cieszyłem!
Trzeba się pogodzić z tym, że pisząc wystawiamy się na publiczną (chcielibyśmy wierzyć, że konstruktywną) krytykę. Ale dlaczego od razu krytykę, to należy nazwać raczej pomocą.

Powtórzę: „Nie przepraszaj, że chciałeś pomóc” [pisząc posta dla ludzi].

*) To jest właśnie dyskusyjne. Mój „Reviewer” zwrócił mi uwagę, że powinienem napisać „WIĘCEJ” zamiast „MNIEJ”. Spieszę więc z wyjaśnieniem. Chodzi mi o sytuację gdy jest 8 godzin do zagospodarowania na wdrożenie SignalR w projekcie. Te godziny wystarczają, żeby zrobić bardzo dobry research i zaimplementować. Alternatywy są dwie:

  • Mogę rozkminić co to jest, zakodować, przetestować uznać za gotowe.
  • Mogę część czasu z researchu przeznaczyć na rzeczy konieczne do dobrego posta, a przytoczone wyżej.

Wiem ile czasu zajmuje mi coś z czego jestem zadowolony i wiem, że jest to kosztem „czegoś”.

Advertisements
Ten wpis został opublikowany w kategorii Blog i oznaczony tagami . Dodaj zakładkę do bezpośredniego odnośnika.