Jak być leniwym, głupim i odnieść sukces

Oryginalny post: How to be Lazy, Dumb, and Successful

Autor: Jeff Atwood

Philipp Lenssen zgadza się z tym, iż natchnione lenistwo jest pożądaną cechą u programisty:

.. tylko leniwi programiści będą chcieli napisać narzędzia, które mogą ich w końcu zastąpić. Tylko leniwy programista będzie unikał pisania monotonnego, powtarzalnego kodu. Narzędzia i procesy natchnione lenistwem przyspieszają produkcję.

Niemniej jednak Philipp dodaje jedno zastrzeżenie: naprawdę nieźli programiści nie tylko są leniwi. Są również głupi:

Programiści, którzy wiedzą, że są mądrzy

a) przestają się uczyć
b) przestają być krytyczni wobec tego co tworzą

W niekończącej się bitwie pomiędzy programistą a kompilatorem, poddaj się wcześnie i przyznaj, że to zawsze Twoja wina, a nie kompilatora.

Nikt nie jest na tyle bystry, by programować komputery. Jedyna droga do osiągnięcia sukcesu jako programista wiedzie przez pokorę i koncepcję Zen zwaną umysłem początkującego: podchodzenie do wszystkiego tak, jakby widziało się to po raz pierwszy. Co oznacza brak obaw przed zadawaniem głupich pytań:

.. podczas konfrontacji z problemem zadanym przez kierownictwo, dobry programista przyjmie postawę głupiego. Zacznie zadawać najprostsze, dziecinne pytania, ponieważ nie przyjmuje on parameterów, które według kogoś stanowią problem.

Niestety, często napotykam na programistów, którzy boją się zadawać podstawowe pytania w obawie o to, iż wyjdą na głupich. Może to nasza programistyczna kultura macho mądrzejszego-od-Ciebie. Posiadanie odwagi do zadawania podstawowych pytań jest, o ironio, wystarczającą cechą charakterystyczną najlepszych programistów, z którymi kiedykolwiek pracowałem.

Bycie leniwym i głupim to nie tylko dobra zawodowa rada: to również klucz do prowadzenia cieszącego się powodzeniem biznesu związanego z oprogramowaniem. Tak jak Mark Cuban zaznacza, każdy jest przynajmniej tak leniwy i głupi jak Ty:

To Aaron Spelling, jak sądzę, powiedział, że "telewizja jest ścieżką najmniejszego oporu od całkowitej nudy". Co innymi słowy oznacza, iż łatwiej jest oglądać telewizję, niż siedzieć i nic nie robić.

Co dokładnie oddaje to, jak ludzie dokonują większości wyborów w ich życiu. Idą na łatwiznę. Obierają ścieżkę najmniejszego oporu.

Istnieją określone rzeczy w życiu, które wszyscy musimy robić. Istnieją pewne rzeczy w życiu, które robimy z wyboru. Oraz istnieje cała reszta. Rzeczy, które robimy dla zabicia czasu. W każdym przypadku, wybieramy ścieżkę najmniejszego oporu.

Zrozumienie tej idei jest kluczem do podejmowania dobrych biznesowych decyzji.

Innymi słowy, jedynym sposobem na tworzenie doskonałego oprogramowania jest czynienie rzeczy najprostszymi jakimi się da dla użytkowników.

Data publikacji oryginału: 26 sierpnia, 2005

Mosty, inżynieria oprogramowania i Bóg

Oryginalny post: Bridges, Software Engineering, and God

Autor: Jeff Atwood

Bazując na tym, ile razy spotkałem się z tym porównaniem podczas mojej kariery, mogłoby się wydawać, iż budowanie mostów oraz tworzenie oprogramowania są ze sobą w jakiś sposób powiązane:

[..] mój ojciec, który jest "prawdziwym" inżynierem, przyjechał do mnie z wizytą na parę dni. Rozmawialiśmy dziś wieczorem o istocie prawdziwej inżynierii i staraliśmy się zrozumieć czy tworzenie oprogramowania zbliża się do takiego poziomu dojrzałości, jaki osiągnęły na przykład inżynieria mechaniczna czy chemiczna. (Brad Abrams)

[..] tworzenie oprogramowania jest niedojrzałą dziedziną inżynierii, która jawi się tym, iż nie potrafimy stworzyć gotowych rozwiązań z prawdziwego zdarzenia. "Klasyczna" inżynieria, jak na przykład budowa mostów, zapór i innych struktur, opanowała technikę specyfikowania komponentów do tego stopnia, że potrafią być one opisane jedynie kilkoma parametrami. W sztuce inżynierii oprogramowania jeszcze tego nie wynaleźliśmy. (Kees Leune)

"Nasze standardy zostały nieodpowiednio obniżone poprzez nasze codzienne doświadczenia", powiedział Ken Jacobs, wiceprezes strategii produktu firmy Oracle. "Musimy doprowadzić inżynierię oprogramowania do takiego stopnia dojrzałości, jaki posiadamy w przypadku budowania mostów i budynków. Nie oczekujemy tego, że każdego dnia może runąć jakiś budynek."

Uważam takie dyskusje za maksymalnie frustrujące, ponieważ nie sądzę, iż budowanie mostów ma cokolwiek wspólnego z tworzeniem oprogramowania.* To zwodnicze porównanie. Tworzenie oprogramowania jest niczym budowa mostów, jeśli budujesz most na Jowiszu, z nowych materiałów, używając narzędzi, które nie istniały pięć lat temu.

butterfly bridge

Tradycyjne rodzaje inżynierii, typu budowa mostów, opierają się na bożych zasadach -- fizyce. Zasadach, które są niezmienne od milionów lat. "Inżynieria" oprogramowania oparta jest natomiast na tym, co zostało wymyślone na początku lat '80 przez paru kolesi, którzy uważali, że mieli dobry pomysł. Nie posiadamy luksusu pracy w dobrze znanym wszechświecie. Bóg nie wynalazł platformy x86. To czyni, iż porównanie z tradycyjną inżynierią jest co najwyżej mizerne. Więcej niż połowa rzeczy, które znam będzie nieaktualna w przeciągu dziesięciu lat; czy jakikolwiek inżynier lądowy może tak powiedzieć?

B. Jacobs, w artykule "Informatyka" to nie nauka oraz "inżynieria oprogramowania" to nie inżynieria, przedstawia, iż oprogramowanie jest bardziej jak matematyka:

Tak więc jeśli inżynieria fizyczna jest nauką stosowaną, a projektowanie oprogramowania nie podąża tym samym schematem, to czym jest projektowanie oprogramowania? Być może jest matematyką. Matematyka nie jest nieodłącznie związana ze światem fizyki. Niektórzy spornie twierdzą, iż jest inaczej, ponieważ niekoniecznie musi to być prawdą w hipotetycznym bądź prawdziwym, alternatywnym wszechświecie, który może posiadać reguły o wiele dziwniejsze, niż możemy to przewidzieć, ale z przyczyn praktycznych możemy ogólnie założyć niezależność od znanych praw fizyki, natury, biologii, itd.

Najbardziej użyteczną rzeczą w matematyce jest możliwość tworzenia niemal nieograniczonych modeli. Mogą one odzwierciedlać znane prawa natury, bądź prawa wymyślane przez matematyków. Matematyka posiada magiczną własność tworzenia alternatywnych wszechświatów wraz z alternatywną rzeczywistością. Jedyną zasadą jest to, że te modele muszą być wewnętrznie spójne: nie mogą być sprzeczne samym sobie. (Cóż, może mogą, ale zazwyczaj wtedy są mniej użyteczne, tak jak programy, które się wywalają.)

Oprogramowanie bardzo przypomina matematykę i być może oprogramowanie jest matematyką zgodnie z niektórymi definicjami. Fakt iż za pomocą oprogramowania możemy tworzyć alternatywną rzeczywistość jest wyraźny w świecie gier. Gry dostarczają rozrywki poprzez tworzenie wirtualnej rzeczywistości, która w różnym stopniu odzwierciedla prawdziwą rzeczywistość, ale również nagina ją niekiedy w interesujący sposób. Popularnym przykładem jest gra The Sims, która symuluje społeczne interakcje, a nie tylko fizykę, która jest obecna w większość gier "akcji".

Założenie iż oprogramowanie jest matematyką jest bez wątpienia bardziej wiarygodne. Ale tak jak Rory, nie jestem przekonany, iż matematyka i oprogramowanie są podobne:

Gdy dorastałem, pamiętam jak ludzie mówili: "jeśli lubisz programowanie, to z pewnością pokochasz matmę". Zawsze myślałem, że ci ludzie byli całkowicie stuknięci. O ile jest coś wewnętrznie podobnego w pewnych rodzajach matematyki i programowania, o tyle obie dziedziny różnią się w dużo większej mierze niż są do siebie podobne.

Dzięki matmie, i nie mówię tu o szalonej filozofii teorii liczb typu "Czy liczby w ogóle istnieją?", ale o praktycznych zastosowaniach, otrzymujemy konkretne odpowiedzi. Dostajesz albo poprawny wynik albo nie.

Jeśli chodzi o kodowanie, najlepsze na co możesz mieć nadzieję, to zrobić coś dobrze. Z tak wieloma możliwościami osiągnięcia tego samego efektu określenie, czy osiągnąłeś cel, zależy bardzo od wrażliwości prawej półkuli mózgowej, ponieważ nie ma nikogo (poza [kolejnym bardziej doświadczonym programistą]), kto mógłby Ci powiedzieć, czy zrobiłeś coś dobrze czy nie.

Jeśli zignorujesz swoją prawą półkulę mózgową, i mówię tu tylko ogólnie o abstrakcji i estetyce, to możesz naklepać jakiś kod, który może działać, ale piekłem może okazać się jego utrzymanie. Jeśli skupisz się tylko na prawej półkuli, możesz mieć coś, co działa, ale jest całkowicie nieefektywne i specyficzne, i jesteś jedyną osobą na Ziemii, która rozumie ten kod i potrafi go utrzymać.

W przeciwieństwie do matematyki, poprawność oprogramowania nie może być obiektywnie oraz formalnie zweryfikowana. Ani nawet jakość rozwiązania.

Tworzenie oprogramowania bez wątpienia jest profesją, ale nie sądzę, abyśmy mogli się zbyt wiele nauczyć od matematyki czy tradycyjnej inżynierii, jak to się zazwyczaj zakłada. Natomiast możemy się wiele nauczyć od siebie nawzajem. Naszym największym wyzwaniem jest rozprzestrzenianie dobrych praktyk wśród innych programistów, a nie dostosowywanie procesów z niepokrewnych branż. Polecam przejrzenie ostatniego wywiadu ze Stevem McConnell'em w celu poznania jego myśli na temat tego, jak branża tworzenia oprogramowania poszła do przodu w ciągu ostatnich 10 lat -- i jak ją ulepszać.

* Niemniej jednak, fajnie jest budować mosty za pomocą oprogramowania!

Data publikacji oryginału: 22 maja, 2005

Obycie technologiczne jest niewystarczające

Oryginalny post: Being technologically savvy isn't enough

Autor: Jeff Atwood

Nie zdawałem sobie sprawy, że Dan Appleman znów pisze bloga! W jednym z jego ostatnich wpisów, porusza doskonały temat, który jest powiązany z moimi ostatnimi wpisami na temat różnic umiejętności w programowaniu oraz o byciu dobrym w tym, co się robi: czasami, to nietechniczne umiejętności czynią z Ciebie lepszego programistę niż kogoś z Indii. Mocy prezencji osobistej nie da się przecenić:

I nawet jeśli produktywność nie jest problemem, to będą nim nieuchronne wahania gospodarki. W pewnym momencie swojej kariery będziesz miał do czynienia z ciasnym rynkiem pracy. I wtedy właśnie, to nie Twoje technologiczne umiejętności będą miały znaczenie czy odniesiesz sukces.

Będą się liczyć Twoje zdolności personalne. Jak dobrze radzisz sobie z komunikacją? Powinieneś wiedzieć, jak zaprezentować swoje pomysły zarówno pojedynczym osobom jak i małym grupom. Czy potrafisz pisać jasno i, w pewnym stopniu, poprawnie gramatycznie? Czy jawisz się jako osoba pewna siebie i swoich umiejętności? Czy posiadasz umiejętności przywódcze (które często przekładają się na umiejętności w zakresie zarządzania)? Czy jesteś odpowiedzialny? Czy jesteś osobą, którą miło jest mieć obok siebie (albo przynajmniej nie tak bardzo odpychającą)? Owszem, istnieją ludzie, którzy są tak technologicznie doskonali, że mogą nie dbać o nic innego, ale dla większości z nas te inne umiejętności są istotne.

Tak więc jeśli studiujesz, nie pozwól, aby zajęcia z przedmiotów technicznych zdominowały Twoją edukację. Zapisz się na zajęcia z pisania. Zaangażuj się w aktywności, które wymagać będą od Ciebie publicznych wystąpień. Weź udział w wystawieniu jakiejś sztuki bądź improwizacji. Dołącz do klubu. Zgłoś się do wolontariatu. Nauczaj. Ten rodzaj doświadczenia ma w dalszej perspektywie więcej korzyści, niż może Ci się wydawać.

To właśnie z tego powodu polecam programistom książki typu Jak Zdobyć Przyjaciół i Zjednać Sobie Ludzi. Niestety, o wiele łatwiej jest doskonalić umiejętności techniczne niż personalne -- kluczem jest, co zaznacza Dan, świadome wybieranie sytuacji, które będą stymulować rozwój Twoich umiejętności interpersonalnych. Tak jak większość programistów jestem introwertykiem, tak więc muszę się nieustannie zmuszać do sytuacji, których normalnie bym unikał

Data publikacji oryginału: 12 października, 2004

Pozłacanie

Oryginalny post: Gold Plating

Autor: Jeff Atwood

Jednym z 36 klasycznych błędów projektów programistycznych według McConnell'a jest pozłacanie. Powtarza się nawet dwa razy na liście, tak więc myślę, iż ryzyko złapania się w tę pułapkę jest dwa razy większe:

#28: Pozłacanie wymagań. Niektóre projekty mają zbyt wiele wymagań na początek. Kwestia wydajności jest stawiana jako wymaganie częściej, niż jest to potrzebne, a to może wydłużać harmonogram prac. Użytkownicy zdają się być mniej zainteresowani złożonymi funkcjonalnościami niż marketing i programiści, a złożone funkcjonalności nieproporcjonalnie przekładają się na harmonogram.

#30: Programistyczne pozłacanie. Programiści są zafascynowani nowymi technologiami i czasem pragną wypróbować nowe funkcjonalności ich języka bądź środowiska, albo stworzyć własną implementację schludnej funkcjonalności, którą widzieli gdzieś indziej -- bez względu na to, czy jest ona potrzebna w ich produkcie. Nakład pracy potrzebny na zaprojektowanie, implementację i utrzymanie niepotrzebnych funkcjonalności wydłuża harmonogram.

Według definicji McConnella, pozłacanie oznacza dodawanie niepotrzebnych, frywolnych funkcjonalności bądź wymagań. Jest to opisane w książce Rapid Development. Pozłacanie to doskonała metafora na dodawanie sztucznej wartości, tak jak tanio wyprodukowana biżuteria.

Jednakże, jeśli chodzi o pisanie kodu, nie jestem pewien, czy pozłacanie zasługuje na przezwisko "klasyczny błąd". W najczystszej formie, to refaktoryzacja jest pozłacaniem. Mianowicie, zużywa dodatkowy czas projektu i nie daje w rezultacie materialnych korzyści użytkownikom. Ale bez okresowych i agresywnych refaktoryzacji, nie jesteśmy w stanie wyprodukować rozsądnego i łatwego w utrzymaniu kodu. Gdzie kończy się refaktoryzacja, a zaczyna pozłacanie? Może jestem wypaczony, ale nie mogę sobie przypomnieć ostatniego czasu, kiedy to przesadnie pozłacałem oprogramowanie, poprzez uczynienie go prostszym i łatwiejszym w utrzymaniu.

Mam również trudności z krytykowaniem kliku programistów, którzy na pierwszym miejscu troszczą się o pozłacanie swojego kodu. Jak to zostało zasugerowane we wpisie Dana Applemana -- w stylu Joela Spolsky'ego -- wielu nawet nie próbuje:

Z jednej strony mamy osobę, która rozwiązuje problemy. Kiedy ma ona zadanie bądź cel i napotka na przeszkody, rozwiąże je, pokona, ominie, opracuje obejście, nawet jeśli oznaczałoby to przedefiniowanie problemu na coś równie dobrego bądź lepszego niż oryginalne zadanie bądź cel. Moim zdaniem, taka osoba byłaby tym, kogo Joel nazywa "rosh gadol".

Po drugiej stronie mamy osobę, która zatrzymuje się na pierwszej wymówce. Innymi słowy, jeśli taka osoba ma wytłumaczalny powód na zaprzestanie poszukiwań rozwiązania, to na tym kończy. Mimo iż może to być zamierzone (tutaj ma miejsce sytuacja z przykładu Joel'a - niewykazywania inicjatywy), to zazwyczaj jest to częścią ich natury. Taka osoba byłaby określona mianem "rosh katan".

Z przykrością stwierdzam, iż tych drugich jest o wiele więcej niż tych pierwszych.

Jako iż z pewnością istnieje wiele przekombinowanego i pozłoconego oprogramowania, znacznie bardziej powszechne jest posiadanie.. czystego ołowiu. Jeśli masz programistę, który jest w stanie dać z siebie więcej i popozłacać trochę, zalicz siebie do szczęśliwców. W końcu, z odpowiednim ukierunkowaniem i skupieniem, mógłbyś mieć programistę produkującego prawdziwe złoto. A to, w rzeczy samej, jest rzadkie.

Data publikacji oryginału: 7 grudnia, 2004

Related Posts with Thumbnails