Jak zapewne wszyscy wiedzą, rozpoczęła się rejestracja do kolejnej edycji konkursu „Daj się poznać”. A jeśli nie wiedzą, to trzeba jak najszybciej nadrobić i koniecznie również się zarejestrować. Jeśli nie wiadomo o co chodzi to zapraszam na stronę devstyle, a potem z powrotem do artykułu. W związku z tym wydarzeniem postanowiłem spisać mały „poradnik dsp2017” jak poradzić sobie w tym konkursie. Żeby nie być gołosłownym uderzyłem do zwycięzców poprzedniej edycji z prośbą o rady, co według nich było najważniejsze, co doprowadziło ich tak wysoko. Ciekawi? Zapraszam do lektury 🙂
Zacznijmy może od Piotra Gankiewicza, piszącego tutaj, który zajął w tamtym roku 1 miejsce:
Z mojego punktu widzenia najważniejsze było to, aby pierwsze tygodnie pracy nad projektem poświęcić na dokładne przemyślenie jego architektury. Pozwoliło to na bezproblemowe wdrażanie kolejnych funkcjonalności, które oparte były na wspólnym „rdzeniu” – można by stwierdzić, że kolejne rozszerzenia były produkowane z wykorzystaniem wzorca copiego-pasta. Od strony blogowania zdecydowanie najtrudniejsze, a zarazem najbardziej czasochłonne są pierwsze wpisy, jednakże nie należy się tym w żaden sposób zniechęcać. Osobiście nierzadko spędziłem ponad 2-3 godziny nad pojedynczą notką, aby kilka tygodni później dodawać kolejne artykuły tworzone w ciągu 30-60 minut – sami zobaczycie jak wraz z upływem czasu odnajdziecie swój mityczny „flow”.
Przyznam szczerze, że startując w poprzedniej edycji nie do końca wszystko było przemyślane, nie mówiąc już o architekturze. A co do pisania postów – zgadzam się w 100%, najtrudniej jest zacząć, po pisaniu przez kilka pierwszych tygodni przychodzi nam to o wiele łatwiej i naturalniej. Piotrek podesłał mi też swojego posta dotyczącego tworzenia projektu od idei aż do realizacji, zapraszam!
A oto co odpisała mi Iwona Lalik, znana jako programistka.net:
Praca w pojedynkę jest dużym wyzwaniem. Dlatego też przyda się coś co pozwoli uporządkować pracę. Polecam spisanie sobie, co nasza aplikacja ma robić i podzielenie tego na mniejsze zadania. Ja do tego celu wykorzystałam Trello. Z kolei wpisy gromadziłam w skoroszycie OneNote i zwykle pisałam je iteracyjnie zaczynając od małego szkicu. Później wracałam czasem parę razy i dopracowywałam. Nawet jeśli w tygodniu nie starcza czasu, by spełnić warunki konkursu i napisać dwa posty, weekend jest równie dobry by nadrobić straty w pisaniu i kodowaniu. Może się zdarzyć, że będzie to troszkę kosztem naszych innych zainteresowań, ale satysfakcja z przetrwania trzech miesięcy jest tego warta. Najważniejsze, żeby praca nad projektem przynosiła radość, więc każdy pomysł realizowany w ramach konkursu jest dobry.
Pojawia się tutaj kolejny akcent, który jest na pewno bardzo istotny, oprócz architektury warto również zaplanować sobie to o czym i kiedy będziemy pisać. Innymi słowy chociaż zgrubny plan tematów i tego, dokąd chcemy dojść, nawet jeśli finalnie się zmieni (bo projekt piszemy w technologii której nie znamy, na przykład), może bardzo pomóc. Podobnie jeśli chodzi o samo pisanie postów, ja również robię w ten sposób. Najpierw mam pomysł, który zapisuję jednym, dwoma zdaniami, potem tworzę plan postu, potem piszę nie zwracając uwagi na to, czy zdania naturalnie z siebie wynikają, a najczęściej tak nie jest, bo to tylko bieżący wyrzut myśli. Potem dopasowuję zdania, dopisuję wstęp i zakończenie, finalnie wszystko poprawiam, odstawiam na jeden dzień. Następnego dnia czytam, ewentualnie poprawiam przed publikacją i publikuję. A dokładnie o tym jak to wygląda napiszę niedługo.
O opinię poprosiłem również Justynę Walkowską prowadzącą bloga na miękko:
Jeśli masz pomysł na projekt, ale nie wiesz, czy starczy Ci wiedzy i zapału, ten konkurs jest doskonałą okazją do pozyskania jednego i drugiego. Rywalizacja podtrzymuje morale, a inni uczestnicy są (w większości) przyjaźni i chętnie podzielą się swoją ekspertyzą, np. wskażą technologię lepiej dopasowaną do Twojego celu.
Boisz się, że nie zawsze uda Ci się przygotować aż dwa teksty tygodniowo? Możesz napisać dwa ogólne teksty o swoim projekcie i wybranej technologii i trzymać je w zapasie na czarną godzinę.
To fakt, dzięki temu, że brałem udział w konkursie udało mi się na tyle ogarnąć temat związany z morfingiem w Androidzie, że prelegowałem na ten temat. Pewnie gdyby nie konkurs, nie posiadł bym tej wiedzy. Nie wspominając już o innych uczestnikach, z którymi stworzyliśmy bardzo fajne community. Trzymanie sobie postów na zapas to również świetny pro-tip. Nigdy nie wiadomo co się wydarzy, a w takiej sytuacji mamy przynajmniej jedno zmartwienie mniej, wiedząc, że w razie czego, klikniemy publikuj na czymś przygotowanym wcześniej.
A oto czym podzieliła się z nami Emilia Szymańska, znana jako Emi:
Myślę, że całkiem ważny może być dobry plan. Lista tematów „na czarną godzinę” – kiedy wypadek losowy sprawi, że nie posuniemy się jakoś znacząco w projekcie. U mnie to były na przykład tematy związane z gitem czy też takie bardziej teoretyczne. Bardzo ważne jest też maksymalne uproszczenie procesu wstawiania posta na bloga, gdyż będzie trzeba to robić bardzo często. To jest coś co muszę u siebie znacznie poprawić – przy obecnym modus operandi wstawienie posta (już po napisaniu samego tekstu) zajmuje mi czasem nawet do 2h, co potrafi być mocno uciążliwe. A poza tym – robić projekt którym jesteśmy zajarani i nie robić nic na siłę. To ma być zabawa, coś co robimy tak naprawdę dla siebie. 🙂
Tutaj mamy podobnie jak u Justyny, czyli przygotowanie sobie postów których użyjemy nie tylko w przypadku sytuacji losowej, ale również wtedy kiedy nie będziemy w stanie ukuć żadnych fajnych rzeczy na bloga, bo po prostu będziemy zmęczeni walką z projektem. Dodatkowo rozszerzył bym radę o uproszczeniu procesu publikacji posta do uproszczenia procesu dzielenia się postem z innymi. Bo to również bardzo ważne, jeśli zrobiłeś dobrą robotę, to podziel się – szkoda posta, którego nikt nie przeczyta.
Bardzo ciekawej odpowiedzi udzielił mi też Dawid Kaliszewski z bloga Commit… and run!:
Ja po prostu pisałem teksty w części dotyczące projektu, który rozwijałem, w części zaś różnych zjawisk i błędów, które spotkałem podczas swojej pracy zawodowej. Mój projekt też nie był jakiś wybitny ani modny jak gry mobilne czy IoT. Na dodatek nie ukończyłem go podczas trwania konkursu (ani nawet do tej pory).
W żaden sposób się nie reklamowałem, nie zachęcałem do głosowania na mnie, nawet nie mam konta na Facebooku ani nigdzie, żeby takie rzeczy robić. Sam byłem bardzo zaskoczony, że cokolwiek wygrałem, nie liczyłem na to. Naprawdę nie wiem jak to się stało.
Cóż, jak mogę się do tego odnieść. Jak dla mnie brzmi to jak wyjątek opisujący regułę, że należy promować swoje treści. Z racji tego, że głosowanie było otwarte Dawid w jakiś sposób musiał uzyskać fanów, którzy na niego zagłosowali. Może wystarczyła do tego sama jakość jego postów? Nie wiem, ciężko mi ocenić, nie mniej gratulacje się należą 😉
Kolejna rada pochodzi od Michała Dymla, blogującego w tym miejscu:
To może o angielskim. Jeśli masz możliwość to bloguj po angielsku. Będziesz miał większy zasięg, co przełoży się na większy ruch, a to bardzo mnie motywowało. Nie bój się tez promować swoich treści. Są na świecie ludzie, którzy chętnie przeczytają Twoje wpisy, ale sami ich nie znajdą – pomóż im.
Nie sposób się z tym nie zgodzić. Za każdym razem kiedy korzystamy z wyszukiwarki wpisujemy frazy po angielsku. Po za tym angielski, to język uznany za ogólnoświatowy, specjaliści it korzystają właśnie z niego – chyba nie muszę tego tłumaczyć. Jeśli chodzi o mnie osobiście, to zmiana języka tego bloga jest w planach, ale jeszcze nie w tym momencie. Muszę poprawić umiejętność pisania po angielsku. No i kolejna rada dotycząca dzielenia się treścią, to naprawdę jest bardzo istotne, gigantycznie zwiększa ruch na blogu, oraz Twoją rozpoznawalność. Stety/niestety takie mamy czasy, że dobry produkt sam się nie sprzeda (chyba, że mamy niebywałe szczęście). Umiejętności marketingowe, dzielenie się treścią, są bardzo ważne, w związku z tym konkurs jest świetną okazją na pozyskanie ich, wyjście z cienia, notabene danie się poznać.
Ostatnią osobą którą poprosiłem o poradę jest Sławomir Rudawski piszący w tym miejscu:
Przede wszystkim, warto wybrać temat (technologię), którą się lubi – nie ma znaczenia, czy dopiero chcesz ją lepiej poznać, czy już ją znasz – dopóki jej nie znienawidzisz, posty będą pisać się same. Co do samych postów – staraj się opisywać rzeczy tak, jakbyś chciał je wytłumaczyć dziecku lub komuś, kto się totalnie nie zna na Twoim temacie – zdobędziesz szersze grono czytelników i ograniczysz grupę „meh, to są jakieś super-kombo-smoki, których nie rozumiem i nie mam czasu zrozumieć”. Z drugiej strony – ciężko ominąć bardziej „mięsne” wstawki – nadal ok! Byle nie przegiąć.
Daj znać innym, że powstał nowy post – zapnij twittera do swojego bloga – możesz to robić manualnie, albo skorzystać z jednego z narzędzi typu https://ifttt.com/, nie zapomnij o hashtagach. Chwal się na slacku Devs PL, wrzucaj bloga na #blogreview. Slack jest też źródłem wiedzy tajemnej – w poprzedniej edycji pojawiła się dyskusja, na temat godziny publikacji posta – odpowiedź: rano. Moje były ustawione na 8:00, by załapać się w „poranny przegląd prasy” potencjalnych czytelników. W gronie uczestników #dajSiePoznac drzemie duża porcja inspiracji i wsparcia w walce z samym sobą o… systematyczność!
Czytaj inne blogi #dajSiePoznac. Nie bój się popełniać błędów, ale też – ucz się na błędach innych. Czytając blogi dostrzegamy rzeczy, których nie widać, gdy je piszemy – brzmi znajomo? Zaplanuj sobie czas na pisanie bloga, zrób z tego „rytuał”, by stał się częścią dnia. Jeżeli Ci dobrze idzie i przez przypadek popełniłeś dzieło długością porówywalne do „Pana Tadeusza” – nie popełniaj błędu Mickiewicza – podziel post na kilka. Kiedy mój post jest za długi? Kiedy myślisz sobie: „a, dodam jeszcze tl;dr; na początku…”.
Użyj mechanizmu automatycznego publikowania postów o zadanym czasie. Przydadzą się, gdy niespodziewane rzeczy zajmą Twój czas na bloga. Nie staraj się też pisać na siłę – ciężko się czyta kolejnego posta z serii „To mój [n] post. Nic się nie dzieje.” – jeżeli będziesz systematycznie pracował nad swoim projektem – zawsze wpadnie coś godne opisania – tu pomocą może być commit log, dlatego warto dbać o jego jakość.
Żeby projekt wciągnął czytelników, musi również wciągnąć nas, to fakt. Pisanie wszystkiego, włącznie z podstawami, to także ciekawa rada i faktycznie, może dobrze wpłynąć na odbiór projektu przez osoby nieznające technologii. Zwłaszcza, że nie ma wymagania, że musimy być super-uber pro programistami. Juniorzy, albo osoby zaczynające naukę mogą otrzymać wiele cennych lekcji dzięki temu konkursowi. I tak jak już pisałem powyżej, dzielenie się pracą jest niezwykle istotne. O ifttt coś nawet nagrałem. Co do kanału #blogreview na slacku devspl, to było to miejsce gdzie bardzo dużo się nauczyłem o pisaniu postów. Ostatnio trochę się to rozmyło, ale kiedyś działało właśnie w ten sposób, że wrzucałeś posta i dostawałeś oceny treści, wyglądu, etc.. To było bardzo dobre, mam nadzieję, że na czas konkursu ten kanał dalej będzie do tego służył. Zwłaszcza, że uczysz się tam nie tylko czytając opinie na temat swojego bloga, ale również wystawiając opinię innym.
To by było na tyle, jeśli chodzi o zebrane przeze mnie informacje, cóż, nawet nie zostało zbyt wiele co mógłbym dodać od siebie tworząc ten poradnik. Mogę powiedzieć tyle, że gdyby nie zeszłoroczna edycja, nie czytałbyś pewnie tego bloga, bo nie rozwinął by się w ten sposób. Dlatego w tym roku też startuję i jestem pełen ekscytacji na myśl o tym co uda mi się dzięki temu zyskać 😉 Ile poznam nowych świetnych osób, o które wzbogaci się polska blogosfera it. Ile uda się osiągnąć rzeczy, których w tym momencie nawet sobie nie wyobrażam. Już układam plany i nie mogę się doczekać. Więc jak, mogę na Ciebie liczyć, stajesz w szranki w tym pojedynku, gdzie jedyny możliwy rezultat to win-win? 😉
Pozdrawiam!
