Są sporty, w których walczy się do pierwszej kropli krwi, ale bywają również takie, gdzie walczy się do upadłego. Takim sportem bywa czasami samo życie lub niektóre jego aspekty.

Z tą krwią to oczywiście przesada, jednak czasami nie warto zbyt pochopnie rezygnować z wytyczonego celu, poddając się przy byle niepowodzeniu. Nieraz trudne i zrażające początki przeradzają się w sukces końcowy, jeśli tylko wykazać należyty hart ducha i konsekwencję. Dużo zapewne na ten temat mają do powiedzenia programiści i projektanci oprogramowania (chociaż nie tylko oni), gdy przychodzi im się zmierzyć z zadaniem, wydawałoby się, na pozór nie do wykonania. Programista, który poddałby się w tej rozgrywce intelektualnej, nie byłby w stanie rozwiązać żadnego z bardziej złożonych problemów, na jakie ciągle natrafia w swojej pracy. Nie mógłby, w związku z tym, wykonywać tego zawodu, w którym przecież jedynym efektem jego pracy jest działający produkt końcowy. Nie sposób oddać do użytkowania jedynie tych łatwiejszych fragmentów oprogramowania, trudniejsze pozostawiając nietknięte, tylko dlatego, że się nie potrafiło ich wykonać. Widać z tego wyraźnie, że twórcy oprogramowania muszą mieć odpowiednie cechy charakteru. Poza tym działanie "aż do skutku" przydaje się w wielu innych dziedzinach i nie tylko na zawodowym gruncie. Jak wielką satysfakcję można mieć z samodzielnie wykonanego zadania czy rozwiązania problemu, ten tylko wie, kto tego doświadczył.

Są ludzie, których jedyną zawodową ambicją jest tłumaczenie, dlaczego nie da się czegoś zrobić. Poświęcają oni moc energii i czasu na działania pozorowane oraz na wyszukiwanie sensownie brzmiących pretekstów. Jedyną obroną przed taką postawą jest udowodnienie, że mimo wszystko problem można rozwiązać. Do realizacji tego celu musi jednak być druga osoba o odpowiednich umiejętnościach i odmiennej orientacji mentalnej. W ten sposób można postawić na baczność niemal każdego opornego osobnika. Jeśli jakiś administrator lub serwisant wymiguje się, tłumacząc, że czegoś nie da się zrobić, oznacza to często jego niewiedzę lub lenistwo, a nie obiektywną niemożność. Chociaż, oczywiście, mogą zdarzyć się tu przypadki niewykonalne. Często jednak sprawa urywa się, gdy ktoś z boku udowodni, że daną rzecz można przeprowadzić i to bez sięgania do karkołomnych sztuczek. Nieraz wystarczy takiemu gnuśnemu administratorowi podsunąć odpowiedni fragment dokumentacji do przeczytania i wówczas niemożliwe cudownie zmienia się w możliwe. Kto jednak w realnych warunkach ma dopilnować takiego niezgułę lub lenia? Wynikałoby, że najlepiej zawsze zatrudniać dublera o identycznych umiejętnościach, ale bardziej kreatywnym charakterze.

Z kolei w środowisku programistów, gdzie cechą normalną powinna być kreatywność, sprawa może toczyć się wokół lepszego lub gorszego wykonawstwa. I w tym przypadku jest podobnie - zawsze można udowodnić, że niezbyt wysokich lotów programista mógł zastosować wydajniejszy algorytm lub lepszą metodologię programowania. Podobnie jak w przypadku administratora musi jednak istnieć ta druga osoba, która potrafi zweryfikować jakość i pokazać, że można coś zrobić lepiej. Z innej strony patrząc, programista ma o tyle gorszą sytuację, że w zasadzie nigdy nie może powiedzieć, że czegoś nie da się zrobić. Otrzymuje on założenia i zgodnie z tą specyfikacją ma wykonać fragment kodu. Tak więc w tym przypadku dyskusja może sprowadzać się w zasadzie tylko do jakości kodu programu, a nie do możliwości jego wytworzenia.

No i już z grubsza wiadomo, jaka jest różnica między administratorem a programistą. Ten pierwszy dąży do tego, aby działało bez ponoszenia wysiłku, a ten drugi podejmuje wysiłek za każdym razem, gdy coś ma działać.