Obiecałem przy okazji startupów i korporacji, że zmianę myślenia „z programisty na przedsiębiorcę” opiszę osobno. To jest ten wpis.
I od razu uprzedzę: to była dla mnie trudniejsza zmiana niż nauka DDD czy zderzenie z korporacyjnym kodem. Bo tamto było uczeniem się nowych rzeczy. To jest oduczanie się starych odruchów.
Programista pyta „jak”, przedsiębiorca pyta „czy”
Jako programista miałem prosty, satysfakcjonujący świat: jest zadanie, jest kod, jest poczucie dobrze wykonanej roboty, gdy wszystko działa i ładnie się czyta. Im dłużej w tym siedziałem, tym lepiej mi szło — i tym mocniej wierzyłem, że dobry kod to cel.
Budowanie własnego produktu rozbiło ten obrazek. Bo nagle przed pytaniem „jak to najlepiej napisać” pojawia się inne, niewygodne: „czy to w ogóle warto pisać — teraz, w tym tygodniu, zamiast czegoś innego?”. Kod, który jest perfekcyjny, ale rozwiązuje problem, którego nikt nie ma, jest po prostu drogim sposobem na zmarnowanie czasu.
Kod to ułamek roboty
Drugie zderzenie: jako programista odpowiadałem za swój kawałek. Jako założyciel odpowiadam za całość — i okazuje się, że kod to mniejsza część tej całości, niż myślałem. Jest jeszcze: po co to komu, jak o tym powiedzieć, ile to kosztuje, co jest legalne, co robić najpierw, a czego nie robić wcale.
Żadna z tych rzeczy nie wygląda jak commit. A często są ważniejsze od commita.
Decyzje bez pełnej informacji
W kodzie zwykle da się dojść do „dobrej” odpowiedzi — jest dokumentacja, są testy, można sprawdzić. W biznesie najczęściej nie ma „poprawnej” odpowiedzi z tyłu książki. Decydujesz przy niepełnych danych, świadomy, że możesz się mylić — i i tak musisz wybrać, bo brak decyzji to też decyzja, tylko gorsza.
Dla kogoś przyzwyczajonego do kompilatora, który mówi wprost „tu jest błąd”, to był dyskomfort nie do przecenienia.
Napięcie, którego nie da się wyłączyć
Nie chcę udawać, że przeskoczyłem na drugą stronę i już. Wciąż jestem inżynierem, który lubi robić rzeczy porządnie — pisałem skąd u mnie ta potrzeba DDD. To napięcie — „zrób dobrze” kontra „zrób to, co teraz potrzebne” — jest we mnie codziennie i pewnie już zostanie.
Najuczciwiej mogę powiedzieć tyle: nauczyłem się je świadomie rozstrzygać, zamiast automatycznie wybierać „dobrze”. Czasem fundament robię solidnie, bo wiem, że będzie nośny. Czasem klepię najprostszą wersję, bo ważniejsze jest, czy ktokolwiek tego użyje. Sztuka jest w tym, żeby wiedzieć, który to przypadek — i tu wciąż się uczę.
Mój własny mózg gra przeciwko mnie
Najboleśniejsze jest to, że ta sama cecha, która robi ze mnie przyzwoitego programistę, przeszkadza mi jako przedsiębiorcy. Kiedy się w coś wgryzam — proces twórczy, trudny problem — potrafię odpłynąć na dwie godziny w totalnej alienacji. Nic nie istnieje poza tym, co mam przed sobą. Dla pisania kodu to supermoc.
Dla kogoś, kto prowadzi wszystko sam, to pułapka. Bo w tym samym czasie czekają maile, trzeba sprawdzić, czy wszystko działa, odpisać na komunikatorze, pomyśleć „co dalej”. Mam tendencję do kompletnego zapominania o wiadomościach i spotkaniach, gdy wejdę w tryb skupienia. Programista może się w nim schować. Przedsiębiorca nie może — i ja wciąż się z tym mocuję, codziennie.
To proces, nie przełącznik
Jeśli DDD zrobiło ze mnie programistę „1.0”, a korporacja „2.0”, to ta zmiana — z inżyniera w kogoś, kto myśli kategoriami firmy — jest gdzieś w trakcie. Nie mam jej zaliczonej. Codziennie łapię się na starym odruchu „a może bym to jeszcze ładniej…” i codziennie pytam sam siebie: „dobra, ale czy to jest dziś najważniejsze?”.
Nie przestałem być programistą — i nie chcę. Po prostu przestał mi wystarczać sam kod jako miara tego, czy dzień był dobry.
To wpis z tych bardziej osobistych — i będę do tego wątku wracał, w miarę jak sam się w nim odnajduję. Bo szczerze: ucząc się tego na żywo, sam nie wiem jeszcze, gdzie jest meta.