Hacking Heroes traktowało programowanie jako coś więcej niż przedmiot techniczny.
Program wykorzystywał kod jako praktyczne środowisko, w którym młodzi ludzie mogli uczyć się badania problemów, testowania pomysłów, pracy z innymi i samodzielności w nauce.
Programowanie jest dla każdego
Deklarowanym celem projektu nie było nauczenie podstaw kilku języków programowania. Było nim przekonanie, że programowanie stało się trzecim językiem — obok języka ojczystego i jednego obcego — który każdy powinien rozumieć na podstawowym poziomie, by pojmować otaczający go świat i zachodzące w nim zmiany.
Ten argument był kierowany w równym stopniu do dorosłych, co do nastolatków. Twórcy mówili wprost, że postrzeganie programowania jako trudnego, specjalistycznego czy niedostępnego jest odtwarzane przez osoby, które go uczą — i że zmiana tego, jak widzi je młodzież, wymaga najpierw zmiany tego, jak widzą je jej nauczyciele.
Nauka przez tworzenie
Uczestnicy uczyli się programowania, używając go.
Zamiast traktować kod jako abstrakcyjny przedmiot, program łączył umiejętności techniczne z pomysłami, które uczestnicy naprawdę chcieli zrealizować. Warsztaty zorganizowano wokół pracy projektowej, a praca projektowa znalazła finał w hakatonie, gdzie pomysły musiały przetrwać zderzenie z prawdziwym zespołem i prawdziwym terminem.
Uczenie się, jak się uczyć
Wiedza techniczna była pierwszą warstwą, a nie celem.
Zakładano, że uczestnicy wyjdą z programu z umiejętnością znajdowania informacji, zadawania lepszych pytań, oceny tego, co znaleźli, i dalszej samodzielnej nauki. Obaj założyciele byli samoukami — jeden z nich wprost, budując karierę na książkach, konferencjach, warsztatach i praktyce — a program odzwierciedlał przekonanie, że to umiejętność, której da się nauczyć, a nie cecha charakteru.
Dzielenie pracy na części
Uczestnicy ćwiczyli dzielenie złożonych problemów na mniejsze zadania, a następnie rozdzielanie tych zadań między ludzi.
To zwykła praktyka zawodowa, której niemal nigdy nie uczy się w szkole. W Porto przestała być ćwiczeniem: czteroosobowe zespoły miały pięć dni, co wystarcza na zbudowanie czegoś tylko wtedy, gdy pracę podzieli się sensownie.
Współpraca i wspólna odpowiedzialność
Ponieważ zespoły były międzynarodowe, współpracy nie można było zakładać z góry. Trzeba ją było zorganizować — w drugim języku, między osobami, które poznały się kilka dni wcześniej.
Projekt traktował wynikające z tego tarcia jako część programu, a nie przeszkodę w jego realizacji.
Kultura open source
Uczestników wprowadzono w oprogramowanie open source: czym jest, jak z niego korzystać i jak się w nie angażować. Chodziło o to, by zobaczyli oprogramowanie jako coś tworzonego przez ludzi, do których mogą dołączyć, a nie jako gotowy produkt podany z góry.
Materiały samego projektu miały działać tak samo — udostępnione na otwartej licencji, by inni edukatorzy mogli je rozwijać.
Błędy i eksperymentowanie
Program oparty na tworzeniu rzeczy jest z konieczności programem, w którym rzeczy się nie udają. Warsztaty ułożono tak, by „nie działa” było normalnym stanem niedokończonego projektu, a nie dowodem błędnej odpowiedzi.
Wsparcie dla osób uczących
Obok warsztatów dla młodzieży projekt przeprowadził dwudniowe warsztaty metodyczne dla nauczycieli i osób pracujących z młodymi ludźmi oraz przygotował materiały, z których mogą dalej korzystać.
To była ta część projektu, która miała go przetrwać. Warsztaty objęły szesnaścioro młodych ludzi w Kaliszu i porównywalną grupę w Espinho; praca metodyczna była skierowana do wszystkich, których ci edukatorzy będą jeszcze uczyć.