Marek Bryling

Nowy rozdział w życiu

Z końcem roku, po ponad trzy i półrocznej pracy, rozstałem się z Drukarnią Print. Poszedłem na swoje. Razem z Mateuszem pracujemy nad kilkoma projektami, w tym dwoma swoimi. Dzięki niemu nie muszę zajmować się stroną papierkowo-organizacyjną związaną z prowadzeniem projektów i mogę skupić się nad tym w czym jestem naprawdę dobry.

Docelowo ta nasza działalność przekształci się w agencję interaktywną czy inne studio developerskie (i będziemy obrzydliwie bogaci).

Na razie, rozkoszuję się pracą dla siebie. I uprzedzając: Wiem że praca na własny rachunek nie jest mniej stresująca (a często bardziej) niż praca na etat. Mam już za sobą prowadzenie działalności gospodarczej i wiem jak to smakuje. Zapomniałem tylko jak to jest gdy nie musisz siedzieć bezsensownie w biurze by wyrobić godziny.

Jak to bywa na początku: jestem pozytywnie nastawiony i z optymizmem patrzę w przyszłość. I nie musicie trzymać kciuków. Mój sukces zależy w dużej mierze od ilości i jakości mojej pracy więc jestem spokojny.

Pomysły na portfolio dla backend developera

Od kilku lat tworzę backendy (silniki - nie wiem czy to dobre tłumaczenie) dla aplikacji inter/intranetowych. Większość moich klientów to debiutanci w tworzeniu aplikacji webowych, którzy wspierają się jednak ludźmi którzy mają jakieś pojęcie. Nie mają jednak programisty (dla tego przychodzą do mnie). Duża część z nich przychodzi do mnie z polecenia. Tu pojawia się jednak problem. Ludzie muszą złożyć swoje nadzieje i przyszłe zyski (z tymi drugimi wiadomo jak jest) w ręce kogoś, kto nie może pokazać im portfolio z ładnymi obrazkami (tak jak grafik), czy pięknie wyglądającymi stronami (jak frontendowiec).

Ja mogę, pokazać pliki wypełnione wierszami składającymi się z kilku angielskich słów, znaków interpunkcyjnych i liczb. Klient najczęściej i tak nic z tego nie rozumie, czasami ktoś kto się zna na programowaniu jest w stanie ocenić czytelność kodu. W wyjątkowych sytuacjach docenia pokrycie testami. Tutaj zresztą pojawia się inny problem. Na przytłaczającą liczbę projektów mam w umowach zakaz udostępniania kodu innym.

Mogę przyjąć inną strategię. Pokazać serwis który zrealizowałem, zastrzegając że nie robiłem grafiki. Sęk w tym, że w ten sposób nie widać jakości pracy którą włożyłem w dany projekt. W takim przypadku klient i tak ma styczność z pracą innych (front-end). Raz zdarzyło się nawet że serwis który był umieszczony w moim portfolio miał awarię (żeby nie było, to był problem z hostingiem). Poza tym większość z aplikacji które stworzyłem to serwisy działające wewnątrz firm i niedostępne z internetu.

Po kilku mniej lub bardziej udanych spotkaniach wypracowałem sobie taktykę. Proszę żeby przy naszej rozmowie była, jak najbardziej “techniczna”, osoba ze strony potencjalnego zleceniodawcy, często “robi” ona za tłumacza i często łatwiej jest ją do siebie przekonać. Poza tym, skoro jest to człowiek klienta - ufa mu bardziej. Wypracowałem sobie też, w miarę skuteczny, sposób rozmowy: dużo prostych do zrozumienia przenośni, odpowiednia mowa ciała, spokój i zdecydowanie w rozmowie itd.

Jakie wy macie sposoby i pomysły na portfolio dla backend developera?

Udostępnić API czy nie?

Jestem na etapie tworzenia nowego projektu (tym razem zupełnie mojego). I zastanawiam się. Udostępnić publicznie API, czy nie?. A tutaj taki wpis na AntyWebie. Zachęcam do poczytania, zwłaszcza komentarzy. Michuk w komentarzu zauważa, że korzystający z API potrafią pchnąć serwis w zupełnie nieoczekiwaną stronę. Zgadzam się z tym w zupełności. Ale niepokoi mnie jedno. Czy nie spowoduje to odpływu userów w kierunku korzystania tylko z aplikacji wykorzystującej API? W takiej sytuacji odpada możliwość zarabiania na reklamie (bądź znacznie je utrudnia). Z drugiej strony opieranie się w przychodach z serwisu/aplikacji tylko na reklamie nie jest rozsądne. W końcu sam korzystam z adblocka, choć wyłączam jego działanie na stronach które często odwiedzam i które nie mają upierdliwych reklam (z czegoś trzeba mieć na hosting).
Moim zdaniem API ma szansę sprawdzić się wszędzie tam, gdzie konieczność odwiedzenia serwisu przeglądarką nie jest wymagana do zarabiania na nim. Rezygnując z potencjalnych przychodów reklamowych mamy za darmo pomysły na rozwój serwisu/aplikacji.

Potencjał który drzemie w API jest ogromny. Wystarczy spojrzeć na Blipa. Trzeba mieć tylko (lub aż) pomysł jak na tym zarobić. Funkcjonalności która na dłuższy czas przyciągnie (i pozwoli urzymać) ludzi przy serwisie nie da się wymyślić. Musi być ona odpowiedzią na konkretną potrzebę (to banał). Tak samo jest ze sposobem korzystania. Jeden sprawdza pocztę tylko przez interfejs www, inny wykorzysta do tego thunderbirda (tak jak ja). Dając API dajemy wybór, nie musi kosztować to wiele pracy, a użytkownicy to lubią (nawet jeśli 90% z nich będzie korzystać tylko z interfejsu webowego). Dodatkowo tworząc dodatki do serwisu możemy dotrzeć do ludzi do których w inny sposób nie bylibyśmy w stanie skutecznie dotrzeć.

Rozpoczynając tworzenie tego wpisu nie byłem zdecydowany czy opłaca się udostępniać API. W trakcie pisania przekonałem sam siebie że warto.
To są moje spostrzeżenia oparte na moich obserwacjach i doświadczeniach. Nie są one pogłębione żadnymi “badaniami”, przynajmniej na razie, więc mogę się mylić.