> (Akurat w przypadku deski jestem bez trudu w stanie sobie wyobrazić, że może być
częścią dokumentacji jako referencyjna jednostka długości w jakimś projekcie)

Brawo. Czyli rozumiesz już różnicę pomiędzy artefaktem, który jest na ścieżce
generacji produktu od takiego, który nie jest.
Ta deska referencyjna jest dokumentacją. Ale deska użyta do budowy budy dla psa już
nie jest - dokładnie tak było z diagramami parę postów wcześniej.

Wyprzedzając: tak, można tą deskę referencyjną użyć w innym projekcie jako budulec.
Wtedy przestanie być dokumentacją. Ale to już chyba rozumiesz.

> > Bo medium może być współdzielone. Nadal jednak odróżniam te dwie rzeczy.
> W porządku. Ty odróżniasz. Ale Wikipedia, na którą się powołujesz, nie odróżnia.

Może ktoś kiedyś dopisze. :-D Wikipedia nie jest wykuta w kamieniu.

> Studiowanie kodu źródłowego nie jest formą inżynierii wstecznej.

https://en.wikipedia.org/wiki/Reverse_engineering

Zdumiewająco duża część tego artykułu, w odniesieniu do oprogramowania, dotyczy
właśnie różnych form wyciągania wiedzy z kodu źródłowego. Czytanie kodu źródłowego to
jest właśnie reverse engineering.

> Ale to nie jest jedyny aspekt. Jakiś czas temu zauważyłem, że studiowanie definicji
przychodzi mi z pewnym trudem -- bo definicje są z natury rzeczy raczej abstrakcyjne.
Z tego też względu lubię mieć w kodzie przykłady użycia różnych definiowanych przez
siebie funkcji. W moim doświadczeniu posiadanie takich konrketnych, namacalnych
przykładów jest najefektywniejszą formą dokumentacji, z jakiej do tej pory
korzystałem.

Jak najbardziej.
Ale Knuth w swojej słynnej książce specjalnie podjał najpierw wysiłek opracowania
języka, który nie miał żadnej znanej implementacji, żeby z jednej strony zapewnić
sobie precyzję opisu, ale z drugiej nie sugerować, że te przykłady są fragmentami
konkretnych projektów. W ten sposób chciał zachować czystość narracji.
Już pisałem - w programowaniu medium jest wspólne, więc ludzie nie odróżniają kodu od
dokumentacji. Zwłaszcza jak jej nie mają. Tak czy siak to są jakieś literki, czasem
cyferki.

> No, może problemem jest to, że programowanie nie do końca jest "branżą
inżynierską".

Podobnie, jak nie każda kupa desek to architektura.
To nie jest tak, że "nie do końca", tylko właśnie "szerzej niż". Powszechne
praktykowanie programowania daleko wykracza poza inżynierię. Dlatego mamy masę
projektów, które z inżynierią nie mają nic wspólnego.

> Dla mnie raczej znamienne jest to, że Ty twierdzisz, że branża elektroniczna jest
"technicznie najbliższa naszej".

Tak to widzę. W sensie - tak to pamiętam z lekcji historii. Również w sensie, że te
dziedziny nawzajem się karmią.

> Sądzę też, że raczej nie zaszkodziłoby programistom zapoznanie się z teorią
literatury (zwłaszcza jeżeli mają tworzyć dokumentację).

No właśnie, ciekawą sprawę poruszyłeś. A dlaczego to programiści mają ją tworzyć?
Dawno temu pisaniem dokumentacji zajmowali się zupełnie inni ludzie. Technical
writing to poważna dyscyplina, nie powierzano tego byle komu. Zauważ, że dokumentacja
w odróżnieniu od kodu jest wizytówką firmy (w wielu projektach zleceniodawca nawet
nie jest zainteresowany kodem źródłowym poza celami archiwizacyjnymi, natomiast
dokumentację dostaje uroczyście), więc ma wpływ na postrzeganie marki. Dlatego pisarz
dokumentacji to była wyższa kasta, niż klepacz kodu.

Może problemem jest to, że obecnie za bardzo przeciążyliśmy pojęcie programisty?
Kiedyś programista to był ktoś, kto pisał kod. A dzisiaj programiści zajmują się
wszystkim, łącznie z psychologią i grafiką użytkową.

> W każdy razie pomiędzy programowaniem a projektem hardware'u jest przepaść.
Współcześnie większość programistów nawet nie będzie miała szans powąchać hardware'u,
na którym będzie chodził ich software.

No właśnie. Może to też jest problem?

> Pewnie różni ludzie robią w pracy różne rzeczy.

Tak. W szczególności, większość nie robi dokumentacji. :-D

--
Maciej Sobczak * http://www.inspirel.com