Sposób pracy programisty

0

Witam wszystkich.
Mam pytanie odnośnie pracy programisty.
Jeśli programista pisze program to czy on korzysta z dokumentacji danego języka?.
Bo przecież chyba nie jest w wstanie wszystkich funkcji zapamietać. I czy w wielkich korporacjach i firamch które tworzą oprogramowanie koderzy tez wspomagają sie zawsze jakąś dokumentacją/książką?
Za odpowiedzi dziękuje.
Pozdrawiam

0

Oczywiscie. Programista nie jest od pamietania wszystkiego na blache tylko do takiego wykorzystania swoich umiejetnosci, zeby powstal dobry produkt. Jesli czytanie dokumentacji przyspiesza i usprawnia tworzenie produktu (a tak wlasnie jest) to nikt przy zdrowych zmyslach tego nie zabroni w zakladzie pracy.

0

Pytanie troszeczkę retoryczne.
Tak się składa że pracuje w firmie jako programista i czytanie dokumentacji (może nie tyle do samego języka programowania ale do funkcji systemu operacujnego, funkcji bazy danych itd.) jest na porzadku dziennym. Bez sensu jest zapamiętywanie wszyszystkich funkcji jakie posiada dane narzędzie programistyczne. Inna sprawa że z czasem człowiek chcąc nie chcąc sam zapamiętuje różnego rodzaju funkcje biblioteczne itd. Na rynku ciągle pojawiają się nowe technologie z którymi warto by się chociaż troszeczkę zapoznać.

0

A czy dokumentacje są dostarczane przez firme do danego projektu lub też programista używa własnych pomocy ? Czy może używa się MSDN ?

0

Zależy w czym programujesz. Ludzie piszący aplikacje pod Windows/.NET nie wyobrażają sobie życia bez MSDN, ludzie od PHP nie mogą się rozstać z pl.php.net. A do specjalnych bibliotek/narzędzi zwykle także dostarczane są konkretne API oraz dokumentacja.

0

W myśl powiedzienia: "nie sztuką jest pamiętać wszystko, tylko wiedzieć gdzie szukać". Pracodawca chce mieć działający soft. Jeżeli dokumentacja+Twoje pomoce się do tego przyczynią to kto Ci zabroni?

0

Dobre IDE (np. Eclipse) z podpiętą dokumentacją API i auto-podpowiadaniem bardzo przyspiesza proces kodowania. Nie wyobrażam sobie, by mogli tego zabronić, kiedy to przyspiesza pracę chyba ponad dwukrotnie względem ręcznego sprawdzania wszystkiego w dokuementacji. A bez dokumentacji to w ogóle byłaby masakra.

0

MSDN + unixowy man do bibliotek standardowych działa wyśmienicie. Poza tym google Twoim przyjacielem...

0
Kokeeno napisał(a)

MSDN + unixowy man do bibliotek standardowych działa wyśmienicie. Poza tym google Twoim przyjacielem...

Nie rozumiem tego '+'... używasz tych dokumentacji jednocześnie ? ;-P

poza tym man jako dokumentacja do bibliotek śmierdzi. I na szczęście GTK i Qt mają swoje dokumentacje w HTMLu.

0

Ja jak piszę program w C pod linuxa, to korzystam z dokumentacji libc:
http://www.gnu.org/software/libc/manual/html_node/

Wszystko jest dobrze podzielone na działy. Często są też przykłady.

Kiedy natomiast np. znam nazwę funkcji, ale zapomnę kolejność argumentów, to korzystam ze standardowych manów.

Gorzej jest z javą. Moim zdaniem javadoci są po prostu nieczytelne.

0

moim zdaniem tez.. wszystko przez organizacje taka jak pakiety w kodzie. zadnego overview, zadnej logiki wyzszego rzedu. ale w kodzie wygalda ok

0

<font size="3">A</span> jak sie uczyć żeby większość przyswoić skuteczne.
Proszę o rady, ponieważ uczę sie programowania i nie moge znaleźć dobrego pomsłu na nauke.
Prosze o rady i pomysły przesycone doświadczeniem.

Pozdrawiam.

0

Pisać, pisać, pisać.. Tylko tworzyć rzeczy potrzebne i interesujące, a nie ciekawe z punktu kodowania (bo takie zawsze trafiają na dno 'szuflady')

0

i zaczynać od małych projeków bo z dużymi i tak sobie nie dasz rady - za dużo potrzeba wiedzy, czasu i chęci żeby dokończyć projekt...

0
Szczawik napisał(a)

Tylko tworzyć rzeczy potrzebne i interesujące, a nie ciekawe z punktu kodowania (bo takie zawsze trafiają na dno 'szuflady')

Większej bzdury nie słyszałem.

Jak najbardziej pisać proste i "ciekawe z punktu kodowania" rzeczy które uczą programowania. Co z tego że trafią do szuflady liczy się zgobyta przez to praktyka i umiejętność pisania dobrego kodu. Takie pisanie na pewno zaowocuje w przyszłości przy prawdziwym "porzebnym" projekcie.

0

Ciężko będzie gościowi znaleźć dobrą pracę jak do pokazania będzie miał tylko "ciekawe z punktu kodowania" popierdółki.

0
Gość napisał(a)

Jak najbardziej pisać proste i "ciekawe z punktu kodowania" rzeczy które uczą programowania. Co z tego że trafią do szuflady liczy się zgobyta przez to praktyka i umiejętność pisania dobrego kodu. Takie pisanie na pewno zaowocuje w przyszłości przy prawdziwym "porzebnym" projekcie.

Eee, tam.. gadanie. Chcesz wiedzieć ile takich programików 'ciekawych z punktu kodowania' mam na dysku z czasów, jak uczyłem się programować, czyli sprzed około 5 do 10 lat? Jakieś 3GB. Każdy zajmuje może maksymalnie pół megabajta, nie więcej - czasem to tylko kilka, kilkadziesiąt kilobajtów samego kodu, czasem pliki projektu i jeszcze plik wykonywalny.

Tak naprawdę sięgam po może tuzin z nich, bo jest tam coś konkretnego, a rzeczy interesujące z punktu kodowania dziś potrafię napisać o niebo lepiej i najzwyczajniej nie potrzebuję tamtych źródeł.

SiNuS napisał(a)

Ciężko będzie gościowi znaleźć dobrą pracę jak do pokazania będzie miał tylko "ciekawe z punktu kodowania" popierdółki.

Dokładnie.. Już to widzę: rozmowa kwalifikacyjna, pytanie o ciekawe oprogramowanie stworzone.. i co, odpowiedź w stylu:

Kandydat (K) - Widzi pan, mam taki kod na rekursyjne algorytmy kompresji blokowej
Szef (S) - Ale do tego używamy standardowej kompresji LZW..
(K) - Tutaj mogę zaprezentować stworzony przeze mnie renderer softwarowy scen trójwymiarowych
(S) - W firmie jednak wykorzystujemy DirectX
(K) - Niegdyś stworzyłem program do szukania najkrótszej ścieżki w grafie
(S) - Ale my wykorzystujemy gotową bibliotekę
(K) - Mam tu jeszcze kod do wyciągania informacji o partycjach dysków z binarnej informacji na dysku
(S) - Ale my tego nie potrzebujemy..

No bez żartów. Sam bym kogoś takiego nie przyjął bojąc się, że nie jest w stanie dokończyć podjętego projektu, skoro całe jego osiągnięcia to jedynie kawałki kodu, nie tworzące żadnej całości.

0
Szczawik napisał(a)

Eee, tam.. gadanie. Chcesz wiedzieć ile takich programików 'ciekawych z punktu kodowania' mam na dysku z czasów, jak uczyłem się programować, czyli sprzed około 5 do 10 lat? Jakieś 3GB. Każdy zajmuje może maksymalnie pół megabajta, nie więcej - czasem to tylko kilka, kilkadziesiąt kilobajtów samego kodu, czasem pliki projektu i jeszcze plik wykonywalny.

Sam widzisz ze pisanie prostych programików pomogło ci w nauce programowania. I właśnie to chciałem powiedzieć wcześniej. Warto pisać i starać się wymyślać same algorytmy bo to uczy myślenia i programowania. Jasne że można zacząć od pisania "przydatnych projektów" ale z doświadczenia wiem że takie projekty bedą napisane "kiepsko" jeśli programista nie będzie miał doświadczenia w samym kodowaniu które zdobywa się nie inaczej niż przez pisanie prostych (znaczy się małych bo niekoniecznie muszą być łatwe w implementacji) programików które w większości trafią do szuflady.
No chyba że powiesz mi że te twoje 3GB "danych" to śmieci które cię niczego nie nauczyły.

A co do twojej przykładowej rozmowy o pracę to wszystko zależy od tego jakiego rodzaju zadania będziesz wykonywał. Rola programisty nie kończy się na pisaniu aplikacji biznezowych w Javie czy C# gdzie (może trochę przesadze) programista spędza 2/3 czasu projektu na szukaniu bibliotek (bo przecież do wszystkiego można znaleźć bibliotekę - pytanie kto je pisze :)). Równie dobrze można trafić do zespołu projektującego gry komputerowe gdzie napisanie dobrego enginu wymaga naprawde niezłej wiedzy właśnie z algorytmiki (oczywiście zaraz usłyszę że engin można kupić co jest prawdą - no ale zawsze może się zdarzyć że to właśnie my jesteśmy częścią zespołu która musi ten engine zaprojektować i napisać). No i w końcu może się zdażyć że programista trafi do firmy gdzie sam będzie pisał biblioteki czy całe systemy operacyjne do jakiś nowych urządzeń dowolnego typu.

SiNuS napisał(a)

Ciężko będzie gościowi znaleźć dobrą pracę jak do pokazania będzie miał tylko "ciekawe z punktu kodowania" popierdółki.

Tak jak napisałem wyżej te małe programiki nie są po to żeby się nimi chwalić tylko po to żeby się nauczyć programowania. Przecież równie dobrze w między czasie można uczestniczyć w jakiś większych projektach którymi można się pochwalić przed pracodawcą - zresztą tak właśnie było w moim przypadku.

0

Pytanie podstawowe, ileż można się uczyć tego programowania? :)

Problem należy raczej postawić inaczej: co sprawia, że ludzie zostają programistami? Czy nie przypadkiem (w przeważającej większości) chęć stworzenia własnego programu, którym będzie się można pochwalić niekoniecznie tylko i wyłącznie rodzeństwu i dziewczynie?... Każdy kto odpowie twierdząco na to pytanie, każdy kto szlifował swoje programiki na podstawie opinii i sugestii obcych osób wie, że to jest jak w reklamie MasterCard - cośtam kosztuje tyle, cośtam kosztule 2xtyle, a zadowolenie użytkowników jest bezcenne... [green] zaczynając powolutku, od przydatnych pierdółek, należy z każdym projektem stawiać sobie poprzeczkę co raz to wyżej, wykorzystywać kolejne cegiełki - napisałeś coś z XML-em? Ok, to teraz bierzesz się za XSL, itp., itd.. Na naukę algorytmów i wykorzystania polimorfizmu klas zawsze się znajdzie czas. Na zjadanie zębów na synchronizacji wątków już nie.
Programy pisze się dla ludzi, a algorytmy?
Co sprawia, że jedni zarabiają 2000 brutto, a inni 5000 netto?
Czym różnią się ogłoszenia o pracę?... terminologią, na której - że użyję znowu tego określenia - zjada się zęby.

0

SiNuS w pełni się z tobą zgadzam. po prostu troszeczkę się nie zrozumieliśmi. Mi nie chodzi o naukę jakiś gotowych algorytmów typu (quick sort, przeszukiwanie drezw itd. itd.) te algorytmy zostały już "odkryte" i je się po prostu implementuje. Mówiąc o uczeniu się pisania algorytmów chodziło mi o własne pomysły czyli jak np. napisałeś właśnie takie coś jak synchronizacja wątków - przecież taka synchronizacja to wcale nie musi być jakiś użyteczny program, najważniejsze jest to że człowiek uczy się danego tematu. I tak samo to można prównać do innych technologi, nie wiem np. "relacyjno obiektowe mapowanie" w Javie + servwry aplikacji - przecież nie trzeba Od razu pisać Bóg wie jakiej aplikacji wykorzystującej 100 tabel. Wystarczy operować na 2, 3 tabelkach które mogą mieć po 2 rekordy i być z punktu widzenia innych użytkowników w ogóle bezużyteczne - bo jakie to ma znaczenie - najważniejsze że ty uczysz się nowej technologi - co z tego że taki programik pujdzie do szafy ? Jak sam napisałeś liczy się doświadczenie które jest "bezcenne". Na CV zawsze możesz później napisac "znajomość TopLink, Hibernate, oc4j".
W tym sensie chodzi mi o to że pisanie takich małych (jak już powiedziałęm wcześniej niekoniecznie prostych) bardzo pomaga w nauce programowania, projektowania kodu - czyli projektowania algorytmów ale własnych a nie już wymyślonych, no i oczywiście poznawania nowych technologii.

0
SiNuS napisał(a)

Co sprawia, że jedni zarabiają 2000 brutto, a inni 5000 netto?
Czym różnią się ogłoszenia o pracę?... terminologią, na której - że użyję znowu tego określenia - zjada się zęby.

2000 brutto zarabiają właśnie tacy, co się nauczyli jakiejś konkretnej technologii z ogłoszenia i potrafią niemal bezmyślnie klepać kod. Trochę więcej zarabiają Ci, którzy znają jakąś niszową, trudną technologię, ale im z kolei trudniej znaleźć pracę. Naprawdę dużo płaci się za to tym, którzy potrafią myśleć, a nie tym, którzy znają API [tu wstaw jakiś skrót z ogłoszenia] na pamięć. Oczywiście doświadczenie z konkretną technologią jest zwykle atutem, ale to jest sprawa drugorzędna, jeśli delikwent umie samodzielnie myśleć i szybko się uczy. Technologie się pojawiają i odchodzą. Za 10 lat być może będzie się programować w czymś innym niż Java, C++ i PHP. Natomiast dobre przygotowanie podstawowe nie traci na wartości. Takowe w zasadzie można zdobyć jedynie na studiach wyższych, chyba że ktoś jest geniuszem.

Wracając do tematu: jak najbardziej trzeba pisać różne programy, nawet o niewielkiej użyteczności praktycznej, ale ciekawych, przy których można dużo się nauczyć. Należy starać się pisać dobry kod, zgodnie z zasadami inżynierii oprogramowania, poznawać coraz lepsze techniki programowania, uczyć się rozpoznawania i stosowania wzorców projektowych. Dobrze jest poznać przynajmniej kilka języków programowania i zrobić kilka większych projektów zespołowo. Więcej takich rad jest w świetnym tutorialu jak być dobrym programistą:

http://samizdat.mines.edu/howto/HowToBeAProgrammer.html

0

Mam nadzieję, że nie urywam się z choinki, ale mam małe zastrzeżenie:

Natomiast dobre przygotowanie podstawowe nie traci na wartości.

Dokładnie.

Takowe w zasadzie można zdobyć jedynie na studiach wyższych, chyba że ktoś jest geniuszem.

Tu niestety trochę przesadzasz. Faktycznie, chcąc zgłębić jak najwięcej idzie się z wygody na studia- profesorowie wykładają informację wręcz jak kawa na ławę. W dodatku można się od nich czegoś dowiedzieć osobiście. Są również i inni studenci(i o ile jest się na porządnym wydziale) z którymi można na temat wiedzy(ogólnie) porozmawiać.
Jeżeli jednak kogoś by interesowało głównie programowanie to ja osobiście nie widzę nic złego w byciu samoukiem. W internecie/księgarniach jest multum książek związanych z różnymi dziedzinami. Nie dotyczą one tylko i wyłącznie wiedzy stricte praktycznej leczi również teorię(nie mówię tutaj o książkach 100stronnicowych mówiącej o algorytmach, strukturach danych w jednym). Dobrze szukając można trafić na wiele skryptów uczelnianych bądź wykładów z których można się samemu wiele nauczyć. Inna sprawa to oczywiście motywacja- niektórym trudno jest się zebrać w sobie aby się czegos nauczyć(i to jeszcze w dużych ilościach).

0
walec51 napisał(a)
Kokeeno napisał(a)

MSDN + unixowy man do bibliotek standardowych działa wyśmienicie. Poza tym google Twoim przyjacielem...

Nie rozumiem tego '+'... używasz tych dokumentacji jednocześnie ? ;-P

poza tym man jako dokumentacja do bibliotek śmierdzi. I na szczęście GTK i Qt mają swoje dokumentacje w HTMLu.

Pracuję i pod win i pod unixem. Czasami nie mam dostępu do dokumentacji win (która w zasadzie nie dotyczy przecież Unixa). Wtedy pozostaje man, które jest bardzo przydatne, o ile ktoś wie, jak tego użyć. Tak, jak i vi :-D

0
Krolik napisał(a)

Takowe w zasadzie można zdobyć jedynie na studiach wyższych, chyba że ktoś jest geniuszem.

Zgadzam się z kmfk - przesadzasz. Jeżeli twierdzisz, że książki nie umieją uczyć, to się grubo mylisz. Sam mam 16 lat, i nigdy większych projektów nie robiłem, w zasadzie sam nie potrafię ocenić swojej wiedzy na temat programowania. Ale... mam kuzyna, który uczył się z książek, a teraz jest poważanym pracownikiem w swojej firmie.

0

Tu niestety trochę przesadzasz. Faktycznie, chcąc zgłębić jak najwięcej idzie się z wygody na studia- profesorowie wykładają informację wręcz jak kawa na ławę.

z tym sie troche nie zgodze, gdyz "profesorowie", nie zawsze znaja odpowiedzi na pytania [przynajmniej na moje nie znali], nie wiedzieli np nic na temat wzorcow aplikacji, metody agile, projektowania oprogramowania [chociaz byl taki przedmiot]. czesto ich wiedza jest straszna, np to, ze zawsze konstruktor klasy musi byc publiczny, nie wiedza czemu w c++ powstaly referencje, etc. a mowie o kadrze, jednej z najlepszych uczelni panstowych [pierwsza piatka]

natomiast co do ksiazek, to oczywiscie, cos z ksiazki mozna sie nauczyc [skladni jezyka, zasad jakiejs technologi], natomiast sposobu wykorzystania dajmy na to np wzorcow projektowych, to juz czysta praktyka. wg mnie ksiazki sa dobre na poczatek, zeby wiedziec jak ugryzc jakis temat potem, to juz wszsytko we wlasnym zakresie, badz wymiana zdan z osobami lepszymi od nas.

0

Nikt nie jest doskonaly. Profesorowie nie znaja odpowiedzi na wszystko, moglo im sie tez po prostu nie chciec wdawac w dyskusje. Znam takich, ktorzy zadaja 'dziwne' pytania (zeby nie powiedziec durne), na ktore pytany po prostu macha reka - co zostaje zinterpretowane jako niewiedza ;)

Ksiazki jak ksiazki. Jednemu bardziej odpowiada uczenie sie z ksiazek, innemu w ogole. Wiedzy w nich zawartej nie da sie zaprzeczyc, ale kwestia jak komu sluzy przyswajanie jej.

0

Ja sie nie zgadza rowniez ze zdaniem ze tylko na uczelni wyzszej mozna sie nauczyc peogramowac. Z autopsji wiem ze jesli ktos chce to sam sie wiele nauczy - ja jestem ekonomista z wyksztalcenia, a programowac zaczalem na 3 roku studiow bo mi sie spodobal assembler :-/ i to ze mozna samemu sprawic ze costam sie dzieje na kompie. Po roku dostalem prace w wielkiej polskiej firmie informatycznej jako programista i nikt sie mnie nawet nie pytal skad umiem i nie krzywil sie slyszac na jaka uczelnie uczeszczam, poniewaz wczesniej mialem test znajomosci: algorytmow, zagadnien baz danych, kilka jezykow programowania ogolnie i 2 szczegolowo, i jeszcze jakies inne zagadnienia. Wiec jak sie chce to mozna, a i ciesze sie ze nie poszedlem na uczelnie techniczna poniewaz znam siebie i wiem ze jakby mi profesor kazal cos napisac to bym sie tylko denerwowal i byc moze tak jak (niestety) wiekszosc moich znajomych z polibudy niewiele umial.
Uczenie sie z ksiazek i tutoriali w necie, uczeszczanie w dyskusjach na forach itp daje bardzo duzo. Co do tutoriali to niestety trzeba wiedziec ktore warto czytac a ktore omijac, ba sa albo przestarzale albo czesto bzdurne.
Pisanie malych aplikacji - jak najbardziej uwazam ze warto, mimo ze nikomu nie przydadza sie - przeciez nie bedzie nikt pisal quake tylko po to zeby sie zabawic grafika 3d, nikt nie bedzie pisal od razu trybu multiplayer tylko po to zeby zobaczyc jak to jest jak sie pisze aplikacje sieciowe, nikt nie bedzie wymyslal nie wiadomo jakich aplikacji tylko po to zeby sie poduczyc synchronizacji w aplikacji wielowatkowej itp...
Co do rozmowy z szefem - bylem na kilku rozmowach i tak na prawde nikogo nie obchodzilo co i czy cos duzego napisalem - napisalem ze znam Hibernate - nie pytali sie co napisalem, tylko zadali mi jakies pytania dotyczaace konfiguracji itpm ogolnie o znajomosc - a tego mozna sie nauczyc piszac aplikacje z 3 tabelkami ktore maja jakies relacje miedzy soba, oraz majac dobry podrecznik i duzo czytajac, prawda? Tak jest praktycznie z wszystkim.
Pozdrawiam.

0

Ile mieliście lat kiedy zaczeliście programować ? Ja mam 15 lat i umiem bdb. podstawy c#.

0

Pierwszy program napisałem w wieku 41 lat, 10 lat później bardzo dobrze znałem już podstawy pascala.

0
pikseloza napisał(a)

Ja sie nie zgadza rowniez ze zdaniem ze tylko na uczelni wyzszej mozna sie nauczyc peogramowac. Z autopsji wiem ze jesli ktos chce to sam sie wiele nauczy - ja jestem ekonomista z wyksztalcenia, a programowac zaczalem na 3 roku studiow bo mi sie spodobal assembler :-/ i to ze mozna samemu sprawic ze costam sie dzieje na kompie. Po roku dostalem prace w wielkiej polskiej firmie informatycznej jako programista i nikt sie mnie nawet nie pytal skad umiem i nie krzywil sie slyszac na jaka uczelnie uczeszczam,

Nie twierdze, że tylko na uczelni wyższej, ale uczelnia dużo daje, jeśli ktoś tylko chce się przyłożyć. Moim zdaniem tak jest łatwiej stać się dobrym programistą / projektantem / analitykiem itd. Pozostaje też kwestia właśnie jakości "programisty". Jak wiadomo, programiści potrafią się różnić produktywnością typowo nawet 10-krotnie, a i spotkałem takich o ujemnej produktywności. Ogólnie programować "coś tam" można nauczyc się w kilka dni z książki. Do wielu zadań wymaganych w firmach (zwłaszcza w Polsce) taka wiedza wystarczy. Nie oszukujmy się, większość firm programistycznych w Polsce zajmuje się mało ambitnym tworzeniem kodu przekładającego dane z jednego miejsca w drugie, typowo CRUD, zwykle opartego o gotowe rozwiązania pisane przez dobrych programistów. Firm prawdziwie innowacyjnych jest bardzo mało, o ile w ogóle jakieś są (eee... Google? Comarch? może). Firmy mające R&D z prawdziwego zdarzenia można policzyć na palcach (btw. ta, w której pracuję, się do takich nie zalicza). Od napisania sklepu internetowego, czy aplikacji okienkowej wyswietlającej formularz na podstawie kwerendy z bazy danych jeszcze daleko do bycia dobrym programistą.

1 użytkowników online, w tym zalogowanych: 0, gości: 1