Nie znalazłem nigdzie konkretnej odpowiedzi, jak powinno wyglądać portfolio programisty. Co powinno się tam znaleźć ? Jakie programy, co one muszą sobą reprezentować ? Czy to może być prosty program do kompresji z ciekawym algorytmem, a może kolejny klient jaberra ? A może prosta aplikacja, np. do planowania zadań, notatek, która będzie działać na wielu urządzeniach, przy b.małych wymaganiach. Co ? Co warto umieszczać na blogu ? Czy artykuły dla początkujących też ? Jak na to patrzy pracodawca ? @bswierczynski jakbyś miał czas, to napisz coś w tym temacie, bo wiem, że jesteś bardzo obyty w tych sprawach.
5
11
Portfolio napisał(a)
jak powinno wyglądać portfolio programisty. Co powinno się tam znaleźć ? Jakie programy, co one muszą sobą reprezentować ?
Zakładam, że chodzi o porfolio, które ma ułatwić Ci zatrudnienie w jakiejś firmie, na etat czy na kontrakt. Gdzieś, gdzie oceniać Cię będą ludzie techniczni (w dobrych firmach tak jest -- na CV patrzą nie tylko HR-y!).
Jeśli otworzysz kod źródłowy swoich programów z portfolio -- a to się opłaca! -- to funkcjonalność może być naprawdę dowolna. Wielkość... w zasadzie też, przynajmniej w bardzo szerokim zakresie.
Wyobraź sobie, że z Twojego CV nie wynika nic konkretnego. Tak się faktycznie dość często dzieje. Nie ma aż tak wielu firm o renomie, która pozwalałaby powiedzieć: "o, pracował tam X lat, to na pewno jest dobry". Jest pełno firm praktycznie anonimowych. Nawet jeśli gdzieś pracowałeś, nie oznacza to, że to Ty byłeś osobą ciągnącą projekty, w których uczestniczyłeś -- mogłeś być tym słabym programistą, który robił najmniej, a jakieś tam laury zgarnął.
Na liczbę lat doświadczenia też nie ma co patrzeć. Przykład z autopsji. Programista, zwany teraz zresztą "ninją", miał ledwie 2 lata doświadczenia. Na rozmowy kwalifikacyjne przychodzili też "tacy kolesie", którzy mieli za sobą wiele firm -- czasem niby znanych i uważanych za dobre -- i 5 czy nawet 10 lat doświadczenia. Ninja kandydował na bardziej specjalistyczne stanowisko od tamtych kolesi, wymagające znacznie głębszej wiedzy w pewnej dziedzinie. Po rozmowie z wieloma "tamtymi kolesiami", za każdym razem byłem od razu pewien, że się nie nadają. Po rozmowie z ninją od razu byłem przekonany, że go bierzemy. I był to dobry wybór.
Nie muszę chyba mówić, że ukończona uczelnia ma praktycznie jeszcze mniejsze znaczenie...?
Tak więc wyobraź sobie, że z CV niemal nic nie wynika.
Super cenny jest link do porfolio ze zwykłą zachętą: oto moje projekty. Zerknijcie w mój kod.
Dla mnie wystarczająco znamienite będzie zobaczenie praktycznie dowolnych kilkuset linii kodu, które napisałeś. Jeśli będzie to dobry kod, zostaniesz zaproszony na rozmowę.
Technologie są ważne. Odpowiedni język programowania to podstawa. Jeśli robisz w tym frameworku, co mój team, to bardzo dobrze. Ale jeśli nie... to jeszcze nie wyrok. Jeśli zobaczę, że stosujesz się do zasad pisania "czystego kodu", to będzie dobrze. Małe funkcje. Dobre nazwy identyfikatorów. DRY. SOLID. Może prawo Demeter. Dobre komentarze -- żadnych durnych, redundantnych. Odpowiednia architektura. Podział problemów na podproblemy.
Będziesz się wyróżniał, jeśli do kodu będą testy automatyczne. Jeśli kompletne, to super. Jeśli dołączysz opis architektury oprogramowania w formię jednej czy kilku perspektyw, to uolaboga. Możesz wręcz opisać motywację czy problemy, jakie widzisz w kodzie.
W ten sposób nawet ktoś z naprawdę niewielkim doświadczeniem komercyjnym i nie posiadający na koncie dużych projektów, może błysnąć w porfolio. Cóż, może wtedy portfolio to trochę szumna nazwa -- takie małe projekty mające pokazać Twoje podejście i umiejętności można nazwać po prostu "demami" :). W takich demach nie ma wielkiego znaczenia, co tak naprawdę robią. Choć jeśli będzie to mała, ale użyteczna aplikacyjka, starannie zrobiona i wygodna w użyciu, to tym lepiej.
Czy to może być prosty program do kompresji z ciekawym algorytmem, a może kolejny klient jaberra ? A może prosta aplikacja, np. do planowania zadań, notatek, która będzie działać na wielu urządzeniach, przy b.małych wymaganiach.
Jeśli pytasz o specjalizację, to musisz ją dobrać do miejsca, gdzie aplikujesz. Czego po Tobie oczekują? Jakie aplikacje tworzą? Czy do głównych atrybutów jakościowych tych aplikacji należy wydajność, bezpieczeństwo, przenośność, czy modyfikowalność? A może funkcjonalność (usability)?
Nawet w przypadku aplikacji do notatek możesz się skupić czy to na przenośności, czy to na szybkości (choć to akurat mało sensowne -- ciężko napisać taką appkę tak, by działała wolno), czy na użyteczności.
Co warto umieszczać na blogu ? Czy artykuły dla początkujących też ? Jak na to patrzy pracodawca ?
Ja bym patrzył przede wszystkim na jakość.
Również na styl pisania. Na to, by artykuł miał ręce i nogi. Żeby spacje były po przecinkach ;-). Żeby kod z przykładów był dobry -- a to trudna sprawa (powinien być krótki, prosty, ale możliwie konkretny, raczej bez funkcji o nazwie "blabla" ;) ).
Umiejętność przekazywania wiedzy jest cechą fajną i pożądaną. Cenne jest, gdy ktoś wie, że forma też się liczy. Nie chodzi o super fancy theme w WordPressie -- lepiej żeby był prosty. Ale ja bym nawet zarejestrował takie rzeczy jak typografię, szerokość linii (nie za duża), krój pisma (prosty). Ewentualny podział na sekcje z nagłówkami czy pogrubienie słów kluczowych (choć ja akurat za tym jakoś super nie przepadam).
Jeśli robisz coś dla newbies, zrób to przystępnie i ciekawie, ale jednocześnie unikaj niezgrabności w stylu "no, aby pokazać tę jedną prostą rzecz, używam jeszcze dziesięciu innych, których jeszcze nie wytłumaczyłem, ale na razie je zignorujcie". Upraszczanie, upraszczanie.
Na bardziej zaawansowanym poziomie jest to wciąż aktualne. Szkopuł w tym, żeby trudną rzecz pokazać w jak najprostszy sposób.
Na wszystkich poziomach ważna jest też formalna poprawność. Raczej bez ściem i bez pomijania wyjątków -- niech przykłady po prostu unikają takich sytuacji.
Sam styl też jest ważny. Ma nie być gimnazjalny. Można pisać ciekawie i nawet całkiem na luzie, ale wciąż z klasą. Im bliżej nieformalnej książki, tym lepiej. W książkach beletrystycznych zdarzają się przecież i przekleństwa, i dowcipy, a jednak nie ma tam emotikon, nie ma (nieświadomych) niezgrabności językowych. Fajnie jest do czegoś takiego dążyć, choć wiadomo, że programista pisarzem beletrystyki nie jest. Ale pisarzem, w pewnym sensie, jakimś jest!
Bardziej zaawansowane artykuły na blogu są oczywiście pożądane. Ale nawet te dla newbies, szczególnie zdarzające się od czasu do czasu, mogą dać Ci przydatne punkty.
Zobacz, jak pisze np. Jeff Atwood: http://www.codinghorror.com/blog/ . Albo ten pan, twórca JavaScriptu, a całkiem luźny gość: http://brendaneich.com/ . Albo Uncle Bob: http://blog.8thlight.com/uncle-bob/archive.html .
Wg mnie niemal wszystko jest dobre, jeśli jest... dobre. Jeśli przyłożysz się do bloga i artykuły wypolerujesz na połysk, to będą plusem. Jeśli to będzie kolejny blog geeka, który tłumaczy koślawo jakieś arty zza granicy, to... no cóż.
Staranność to też pożądana umiejętność miękka u programisty. Ale trudno cokolwiek wypolerować tak, by błyszczało. Dlatego jeśli bym widział, że piszesz nawet artykuły o prostych rzeczach, ale są to dobre artykuły, to nie uznałbym, że straciłeś na swój blog czas. A jeśli miałbyś kiepskiego bloga, to w pewnym sensie (ale tylko w pewnym sensie) lepiej, żeby go w ogóle nie było: straciłeś na niego X czasu, ale wyszło bardzo przeciętnie i pewnie niczego się przy tym nie nauczyłeś.
1
@bswierczynski wielkie dzięki za konkretną odpowiedź, bardzo mi pomogłeś :)
bswierczynski napisał(a):
Jeśli otworzysz kod źródłowy swoich programów z portfolio -- a to się opłaca! -- to funkcjonalność może być naprawdę dowolna. Wielkość... w zasadzie też, przynajmniej w bardzo szerokim zakresie.
Czyli OpenSource się opłaca. A w jaki sposób publikować kod, źródła ? Na naszej stronie, w ten sposób, że można ściągnąć samego exe'ka, albo instalator, a można też razem ze źródłem ? Czy może w inny sposób ? Pastebin lub coś innego ?
bswierczynski napisał(a):
Technologie są ważne. Odpowiedni język programowania to podstawa. Jeśli robisz w tym frameworku, co mój team, to bardzo dobrze. Ale jeśli nie... to jeszcze nie wyrok. Jeśli zobaczę, że stosujesz się do zasad pisania "czystego kodu", to będzie dobrze. Małe funkcje. Dobre nazwy identyfikatorów. DRY. SOLID. Może prawo Demeter. Dobre komentarze -- żadnych durnych, redundantnych. Odpowiednia architektura. Podział problemów na podproblemy.
Jeśli chodzi o technologie, to trzeba iść z duchem czasu, ale najważniejsza jest chyba zdolność do korzystania z dokumentacji i umiejętność w miarę szybkiego uczenia się. W kwestii 'czystego kodu', to chyba warto wziąć do ręki książkę http://helion.pl/ksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykod.htm
bswierczynski napisał(a):
Będziesz się wyróżniał, jeśli do kodu będą testy automatyczne. Jeśli kompletne, to super. Jeśli dołączysz opis architektury oprogramowania w formię jednej czy kilku perspektyw, to uolaboga. Możesz wręcz opisać motywację czy problemy, jakie widzisz w kodzie.
Będę musiał trochę poczytać o tych testach, bo nie do końca wiem, o co chodzi. Czy z tym 'opisem architektury', to chodzi o UML ? 'Możesz wręcz opisać motywację' - tego też nie rozumiem. Chodzi o to, dlaczego napisałem program X ?
bswierczynski napisał(a):
Wg mnie niemal wszystko jest dobre, jeśli jest... dobre. Jeśli przyłożysz się do bloga i artykuły wypolerujesz na połysk, to będą plusem. Jeśli to będzie kolejny blog geeka, który tłumaczy koślawo jakieś arty zza granicy, to... no cóż.
Oczywiście myślę o blogu, na którym będę zamieszczał, być może w języku polskim i angielski, swoje własne artykuły. Żadnego tłumaczenia innych blogów, nie taki jest mój cel. W rzeczy samej, od czasu do czasu, można chyba zamieścić post, w którym poda się linki do jakichś interesujących artykułów znalezionych w Internecie.
2
A w jaki sposób publikować kod, źródła ?
Może być paczka z kodem źródłowym do ściągnięcia, ale ostatnio modny jest GitHub. Można dać linki do repozytorium i tyle.
W kwestii 'czystego kodu', to chyba warto wziąć do ręki książkę
Tak, jest bdb.
Czy z tym 'opisem architektury', to chodzi o UML ?
Niekoniecznie. Możesz użyć sformalizowanej notacji, ale nie musisz. Pamiętaj, że architektura to struktura wysokopoziomowa, nie wdająca się w szczegóły -- to nie opis każdej klasy!
Pogooglaj o architekturze oprogramowania.
Opis może być w formie diagramów -- formalnych lub nieformalnych -- czy nawet czystego tekstu. Jakie są warstwy w programie? Na jakie atrybuty jakościowe postawiłeś? Które moduły mają prawo korzystać z których?
'Możesz wręcz opisać motywację' - tego też nie rozumiem. Chodzi o to, dlaczego napisałem program X ?
Raczej nie o to chodzi. Raczej chodziło mi o to, żebyś opisał, czemu skorzystałeś z pewnych rozwiązań. Czemu kod wygląda tak i tak. Nieraz możesz nawet opisać i jego słabe strony -- i wytłumaczyć, że zrobiłeś je właśnie tak, bo chciałeś osiągnąć X (np. wydajność), co niestety musiało się odbyć kosztem Y (np. modyfikowalność, czytelność).
Przy czym nie polecam akurat poświęcać czytelności/modyfikowalności w takim demku ;-).
1
bswierczynski napisał(a):
Pogooglaj o architekturze oprogramowania.
http://helion.pl/ksiazki/architektura-oprogramowania-w-praktyce-wydanie-ii-len-bass-paul-clements-rick-kazman,aropw2.htm czy w tym temacie, to dobra pozycja ?
Przynajmniej teraz nie zajmuje się stronami www, sklepami internetowymi, bardziej aplikacjami desktopowymi, ewentualnie webowymi, ale nie tworzeniem całych serwisów. W związku z tym najlepszym wyjściem będzie chyba postawić to na Wordpressie. Czy są jakieś 'złote zasady' jeśli chodzi o estetykę takich rzeczy jak portfolio czy blog ?
0
Odswiezam temat.
Ktos moze powiedziec jakie projekty nadają się do portfolio? Chodzi o jave albo androida. Obecnie raczej daleko mi do tego etapu ale pewnie podsuneloby mi to pare pomyslow. No i kompletnie nie wiem co sie nadaje do takiego portfolio. Z gory thx.