🚀 go-pugleaf

> (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