Proces programowania jest powolny

Co to jest programowanie?

Programowanie to nie pisanie kodu. To proces rozwiązywania złożonych problemów, który wymaga analizy, planowania, testowania i podejmowania decyzji przed oraz po napisaniu kodu.

Samo pisanie kodu jest tylko częścią całego procesu. Duża część pracy odbywa się poza edytorem, bo podczas poznawania problemu, projektowania rozwiązania i sprawdzania, czy obrana droga ma sens.

Dlaczego tak jest?

Odpowiedź jest prosta: programowanie to przede wszystkim proces zdobywania wiedzy, a nie proces produkcyjny.

Można go przyspieszyć lepszymi narzędziami, doświadczeniem czy dobrą dokumentacją. Nie da się go jednak skalować tak samo jak pracy fizycznej, ponieważ w pewnym momencie dodatkowa osoba zaczyna wymagać więcej koordynacji, niż wnosi realnej wartości.

Co dokładnie mam na myśli?

Wyobraź sobie, że projektujesz budynek. Możesz zatrudnić więcej architektów, użyć gotowych elementów konstrukcyjnych albo szybciej tworzyć prototypy. Wszystko to pomaga.

Nie unikniesz jednak czasu potrzebnego na zrozumienie, co właściwie budujesz, jakie obciążenia musi wytrzymać konstrukcja, jak rozplanować instalacje, gdzie powinny znajdować się wejścia i jakie ograniczenia trzeba uwzględnić.

Możesz podzielić pracę między dziesięciu architektów, ale jeśli nikt jeszcze nie rozumie dokładnie problemu, powstanie po prostu dziesięć różnych wersji tego samego nieporozumienia.

Ten sam mechanizm opisuje prawo Brooksa: dodanie kolejnych programistów do opóźnionego projektu często powoduje jego dalsze opóźnienie.

Nie oznacza to, że większe zespoły są zawsze gorsze. Przy dobrze podzielonych zadaniach współpraca realnie przyspiesza pracę. Problem pojawia się wtedy, gdy największym wyzwaniem nie jest samo wykonanie zadania, ale zrozumienie problemu i podjęcie właściwych decyzji.

W takiej sytuacji każda nowa osoba musi najpierw zdobyć wiedzę, którą posiada obecny zespół. A zdobywanie tej wiedzy kosztuje czas.

Jest jeszcze jeden powód, dla którego programowanie bywa wolne: informacja jest droga.

Zanim napiszesz dobre rozwiązanie, musisz odkryć, czego naprawdę potrzebuje użytkownik, jak działa istniejący system, jakie są ukryte ograniczenia i jakie decyzje będą miały sens za rok.

Największym kosztem w programowaniu często nie jest napisanie rozwiązania. Jest nim skuteczne uniknięcie napisania złego rozwiązania.

A żeby tego uniknąć, trzeba najpierw zdobyć wiedzę, której na początku po prostu nie masz.

Mój przykład

Mogę to potwierdzić na własnym przykładzie. Swój side project zacząłem w maju. Jest sierpień, a ja nadal nie mam nawet MVP.

Na papierze projekt wyglądał prosto. Gdybym miał tylko pisać kod według pierwszego pomysłu, prawdopodobnie skończyłbym go w kilka weekendów.

Problem w tym, że większość czasu nie spędzam na pisaniu kodu, tylko na podejmowaniu decyzji:

Czy to dobre podejście?
Czy ta struktura ma sens?
Czy za pół roku nie będę musiał wszystkiego przebudować?

Kilka razy zaczynałem część projektu od zera, ponieważ w trakcie pracy lepiej rozumiałem problem niż na początku.

To nie oznacza braku postępu. Częścią programowania jest właśnie odkrywanie, co powinno zostać zbudowane.

Czy da się to poprawić?

Częściowo tak, ale nie istnieje jedno rozwiązanie, które nagle sprawi, że programowanie stanie się kilka razy szybsze.

• Lepsze narzędzia mogą przyspieszyć techniczną część pracy — autouzupełnianie, generowanie boilerplate’u czy AI-asystenci pozwalają szybciej tworzyć kod. Nadal jednak rozwiązują tylko część problemu.
• Doświadczenie pomaga podejmować lepsze decyzje. Doświadczony programista szybciej rozpoznaje wzorce, unika ślepych uliczek i wie, kiedy nie warto poświęcać czasu na przedwczesną optymalizację.
• Jasność problemu jest często największym przyspieszeniem. Im lepiej rozumiesz, co właściwie chcesz zbudować, tym mniej czasu tracisz na późniejsze zmiany i przebudowy.

Nie da się zamienić procesu myślowego w linię produkcyjną.

Można jednak sprawić, że będzie przebiegał sprawniej, dzięki lepszym decyzjom, większej wiedzy i odpowiednim narzędziom.

Programowanie nie jest wolne dlatego, że programiści piszą kod za wolno. Jest wolne dlatego, że dobre rozwiązania wymagają zrozumienia problemu.