本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

Od „byle działało” do „śmiem to zmienić i uruchomić”: miesięczny dziennik programowania nowicjusza

AI2026.04

Na wstępie zaznaczę: nie jestem inżynierem oprogramowania, a wszystko, o czym piszę tu w kwestii programowania, to tak naprawdę tak zwany Vibe Coding — ten rodzaj, w którym idzie się za przeczuciem.

Laptop na biurku wyświetla kod, obok naklejone karteczki samoprzylepne, mała biała tablica z rozpisanym procesem zmian, minutnik pomodoro i odręcznie prowadzony dziennik programowania, a do tego kubek z kotem

Ostatnio, żeby praca szła trochę sprawniej, cały czas rozwijam własne małe narzędzia. Przez ostatnie dwa dni zrobiłem trzy rzeczy: zacząłem robić kopie zapasowe za pomocą systemu Git, poprawiłem kilka błędów (bugów) w logice programu i podłączyłem nowy model AI.

Najtrudniejsza nie jest składnia, tylko „przełożenie tego, czego się chce, na kod”

Po miesiącu największy wniosek jest taki — najtrudniejsza w pisaniu programów wcale nie jest składnia, tylko przełożenie tego, „czego właściwie sam chcę”, na „konkretny kod”.

Na przykład „naprawić buga” brzmi bardzo prosto, ale zanim naprawdę weźmiesz się do roboty, musisz najpierw zadać sobie całą masę pytań:

  • Czy najpierw zapisać?
  • Czy założyć nową gałąź (branch)?
  • Kiedy testować? I jak testować?
  • A po wprowadzeniu zmian — co właściwie znaczy „skończone”?
  • Czy przy okazji nadać numer wersji?

Żadne z tych pytań nie jest tak naprawdę pytaniem o programowanie — to pytania o „nawyki pracy”. Ten cały proces jest w branży być może czymś zupełnie powszechnym, ale dla początkującego w programowaniu to po prostu koszmar.

Kilka drobiazgów, których się nauczyłem

Przez ten miesiąc nauczyłem się kilku drobnych rzeczy, którymi dzielę się z takimi samymi nowicjuszami jak ja:

  1. Najpierw postaw tarczę ochronną, a dopiero potem zabieraj się do grzebania. Jeśli używasz systemu Git do kontroli wersji, to nawet gdy wszystko zepsujesz, w trzydzieści sekund wrócisz do przeszłości — czujesz się tak bezpiecznie jak przy zapisie stanu gry.
  2. Rób tylko jedną rzecz naraz. Broń Boże nie „zmieniaj przy okazji jeszcze jednej linijki” — od tego twoje przyszłe ja będzie chciało walić głową w mur.
  3. Wolno — to normalne. Całe popołudnie na jedną małą funkcję? Tak, to codzienność. Te kursy na skróty w większości cię oszukują.
  4. Pisz notatki dla siebie z przyszłości. Inaczej następnym razem, kiedy tu wrócisz, pomyślisz, że ten program napisał ktoś inny. (No dobra, ten program naprawdę napisała AI.)

Od „byle działało” do „śmiem to zmienić i uruchomić” — tym, co leży pomiędzy, są chyba właśnie te nawyki pracy: z pozoru nieefektowne, a jednak trzeba je uzupełniać jeden po drugim.