znalezione wpisy oznaczone „uczestnicy dramatu”:

rekrutacja

Taka sobie refleksja po krótkiej inspekcji stanu/postępu prac w zespole — warto się upierać przy „głupich” zadaniach podczas przesłuchania kandydatów na programistów. Warto kazać im rozpisywać na kartce problemy, z którymi nigdy się nie spotkają w prawdziwym życiu. Warto pytać i dociekać dlaczego takie a nie inne rozwiązania stosują. Warto sprawdzić czy rozumieją sugestie, czy „chwytają” podpowiedzi i kojarzą.

My i oni

Pracuję w ten branży lat kilka (no... -naście powiedzmy szczerze) i miałem okazję (współ)pracować z różnymi zespołami i szeroką gamą „typów ludzkich”. Parę rzeczy (za dużo) widziałem i wyrobiłem sobie kilka niezmiennych opinii i zapewne niesprawiedliwych uogólnień. Wiele z nich wynika z mojego trudnego sposobu bycia. Jednak nie udało się uniknąć wyraźnego poczucia, że oni są inni. Nigdy nas nie zrozumieją i zazwyczaj mają zupełnie inny pogląd na sytuację i inne cele. Oczywiście pogląd gorszy, a cele sprzeczne. A jednak z jakiegoś zupełnie niezrozumiałego powodu uparcie się ich trzymają...

Granat w szambie

W ramach tego ciągu śmiesznych wydarzeń, który z braku lepszego kandydata służy mi za substytut kariery zawodowej, zdarzyło mi się już pełnić różne role. Na szczęście nie zawsze bez powodu i czasami nawet z powodzeniem. Jednak rola, jaka wynika z aktualnie przydzielonego mi zadania, jest na tyle dziwna, że można poddawać w wątpliwość już nawet nie wybór osoby, ale w ogóle sam fakt istnienia takiej roli wewnątrz zespołu. Zostałem bowiem egzaminatorem...

Mów do mnie obrazami

Luźna uwaga na boku: analiza zawierająca dużo tekstu i mało obrazków nie jest analizą dobrą. Kropka.

Wejdź dwa razy do tej samej rzeki

Krótka myśl na boku: każdy zatrudniony na dowolnym stanowisku powyżej poziomu zero w dowolnej korporacji z branży IT powinien co jakiś czas, powiedzmy raz na rok, przejść rozmowę ... kwalifikacyjną.

Projektowanie parami

W przeciwieństwie do programowania parami, w które wciąż nie wierzę (być może z powodu braku otoczki w postaci reszty metod XP), projektowanie uważam za doskonale nadające się do pracy grupowej.

gdzie ten diabeł?

wychodzi na to, że nawet jeśli faktycznie opis funkcjonalności jest „rozsądnie uogólniony”, to projekt techniczny i tak musi zawierać kilka zupełnie irracjonalnych szczegółów... :-/ Największy diabeł tkwi w tym, co zostało w cytowanym na wstępie tekście ujęte rozbrajająco prostym „oraz ERD”.

guru

Nadal w podobnym duchu pseudofilozoficznego zadumania jak poprzednio...

lepiej późno czy wcale?

Niedawno kolega zadał mi pytanie: „czy ten PL jest faktycznie tak bardzo inny?” Chodziło o porównanie języka PL/I i Javy, a konkretnie o to, czy dzieląca je przepaść może być tak ogromna, że dla niektórych nie do przeskoczenia.

Programiści mają łatwiej - polemika

Kolega Łukasz oczywiście spłyca, jak to profesjonalny analityk, wiadomo ;-) Przede wszystkim mam wrażenie, że popełnia błąd numer jeden wszystkich analityków systemowych wszechświata — nadużycie określenia „programiści”.

Version People Control System

Wybór mechanizmu kontroli wersji i repozytorium kodu dla projektu jest zagadnieniem niebanalnym. Dostępne narzędzia VCS różnią się zarówno wymaganiami jak i możliwościami. Wybór między VSS, CVS czy innym Subversion to dla jednych zagadnienie wyboru platformy lepszej i stabilniejszej, dla innych wybór najwygodniejszego narzędzia, a dla wielu pewnie wybór czysto ideologiczny. Jednak w przypadku VCS wybór narzędzia „najbardziej odpowiedniego” nie zawsze jest wyborem „lepszej” technologii..

jutro to dziś, tylko ma więcej błędów

W zasięgu mojego wzroku pojawiło się w ostatnich czasach kilka mniej lub bardziej humorystycznych artykułów na temat dobrego i złego raportowania błędów — np.: Testers: Are they Vegetable or Mineral?, Every time you submit a bad bug report, god kills a kitten.

Czyj to plan?

Przedsięwzięcie programistyczne, tak jak każdy inny przejaw zorganizowanej działalności zespołowej, nie może się obyć bez konkretnego planu działania. To z pozoru banał. Jednak wniknięcie w szczegóły powstawania planów lub harmonogramów na typowym grzęzawisku ujawnia znacznie mniej oczywiste zależności i konsekwencje.

anioły faktycznie nie istnieją

Kilka dni temu w małym (choć rozwlekłym) świecie blogów zaroiło się od referencji do wpisu „Why specs matter” Marka P. Śmiem podejrzewać, że w większości jest to zainteresowanie typowe dla każdej publicznej wypowiedzi zawierającej zdanie typu:

Primate Programming

O Primate Programming, czyli o antropoidach w roli programistów, mówi się bardzo mało... A szkoda, bo idea jest piękna — skoro usiłujemy nauczyć głupie maszyny pisania kodu za nas, to czemu nie moglibyśmy nauczyć tego samego prawie-tak-samo-jak-my-inteligentne małpy człekokształtne?

zniecierpliwienie i arogancja

Biorąc pod uwagę złożoność [komputerów i programów], to zdumiewające, że ludzie w ogóle tworzą oprogramowanie. Jak rozwinęliśmy umiejętności pozwalające na sterowanie zdecydowanie logiczną maszyną? Niezbędne ku temu zdolności mają niewiele wspólnego z polowaniem, wymykaniem się zdobyczy, czy wabieniem partnera. Niemniej jednak doczekaliśmy czasów, w których oprogramowanie stanowi centralny punkt naszego życia ekonomicznego i kulturalnego i to właśnie programiści są w stanie je stworzyć.

przeanalizujmy to spokojnie

Dowolny klient, odbiorca dowolnego systemu infomatycznego, mimo kilku niezaprzeczalnych zalet ma zawsze jedną podstawową wadę — nie umie powiedzieć czego chce. To jest pewnik, zagwarantowany przez definicję klienta jako takiego — sam z siebie nie umie sformułować wymagań na jakimś zadowalającym poziomie technicznej szczegółowości. A nawet jeśli czasem mu się wydaje, że umie, jeśli na przykład ma swoich informatyków, który zechcą przygotować specyfikację wymagań, to wychodzi to tak, że wszyscy byliby szczęśliwsi gdyby klient takich rzeczy w ogóle robić nie próbował.

architekt

Most people think of architecture as technical, and the architect as a technical person. And absolutely, the architect must be technical. But there's also a social aspect of the architect role that I think is not well communicated or understood. The architect is the person who will say, "This is the way we do things."

programista, a może projektant?

Teoria książkowa aka sformalizowany świat idealny przedstawia taki łańcuch rozbieżnych kompetencji — klient, analityk, projektant, programista, tester. W łańcuchu tym wymagania i uwagi klienta co do funkcjonalności systemu są pieczołowicie zbierane przez analityka i przekazywane projektantowi, który tworzy szczegółowy projekt tego co ma być wykonane. Następnie projekt ten trafia do programisty w celu jego urzeczywistnienia i na końcu do testera dla konfrontacji efektu z założeniami. Taki schemat zakłada separację ról, czyli jest praktycznie wzorowany na kaskadowym modelu cyklu życia projektu informatycznego. I jest równie absurdalny jak sam model kaskadowy.

zapraszam na chwilę do siebie...

Przełożony to niemal z definicji "przeszkadzacz" — weźmy np. takiego kierownika projektu.