>> Skąd taki pomysł, żeby dobry inżynier zostawał, w imię "awansu",
>> kiepskim kierownikiem?
>
> http://www.chrabja.art.pl/element3.html
>
> poszukaj hasla "NIEKOMPETENCJA POTENCJALNA"
>
> Bardzo madry tekst ;-)


Fajny tekst, ale nie tłumaczy, dlaczego powszechnie uważa się, że bycie
kierownikiem jest bardziej ambitnym zadaniem, niż programistą. Ja np.
zrezygnowałem z kierownictwa na rzecz szeregowego programowania. Żyję
spokojniej, jestem zdrowszy i praca sprawia mi więcej radości.

--
Lukasz

do góry

Hello Kapsel,

> Mon, 26 Nov 2007 08:05:00 +0100, MPA napisał(a):
> Zależy w jakich językach programujesz. Bo np. takie PHP jest bardziej
> powszechne niż assembler ;P
>

Moze i jest, ale znalezc kogos kto mysli przy klepaniu to sztuka ;)

do góry

On 26 Lis, 12:21, "MPA" <m...@n...pl> wrote:
> Użytkownik "Kapsel" <k...@p...onet.pl> napisał w
wiadomościnews:1xwjp361oydpa$.dlg@kapselek.net...
>
> > Mon, 26 Nov 2007 08:05:00 +0100, MPA napisał(a):
>
> >> oza polskim rynkiem, ale obecnie mam juz tego dosc i
> >> chcialbym czegos poszu
>
> > Zależy w jakich językach programujesz. Bo np. takie PHP jest bardziej
> > powszechne niż assembler ;P
>
> Generalnie mysle ze raczej trzeba unikac tego co zbyt powszechne. Np. przez
> to ze znalem PowerBuilder zaproszono mnie ponad 6 lat temu na rozmowe
> kwalifikacyjna az do Hamburga i dostalem posade. Gdyby to byl np. Visual
> Basic czy C++ to z pewnoscia nie bylo by klopotu by znalezc kogos w Hamburgu
> i nikt by sobie nie zawracal glowy jakims Polakiem.
>

kwestia przyjetej strategii. Ja osobiscie wole specjalizacje
popularne, perspektywiczne, dobrze platne, w sektorze finansowych lub
telekomunikacyjnym, acz majace duze bariery wejscia (wiedza +
doswiadczenie!) - na dzis to j2ee, .net, w mniejszym stopniu c++.
Specjalizacje niszowe maja to do siebie, ze sa wlasnie ...niszowe -
maly rynek firm, ciezko zmienic prace. Brak tez presji rynkowej na
wynagrodzenia w firmach.

--

Pozdrawiam,

glos

do góry

On 26 Lis, 12:14, "MPA" <m...@n...pl> wrote:
> > Zadaj precyzyjne pytanie, to masz szanse na sensowna odpowiedz:
>
> > 1. technologia
> > 2. doswiadczenie
> > 3. branza
> > 4. lokalizacja (Warszawa, Krakow czy okolice)
>
> Robilem np. w C, C++ i Visual Basic (w Silicon Valley), ale przez ostatnie
> ponad 5 lat w PowerBuilder w Niemczech i chcialbym sie tego trzymac. Byly to
> duze projekty dla niemieckich instytucji rzadowych i wielkich firm. Obecnie
> chce pracowac zdalnie (w czym mam doswiadczenie), ale tak abym w ciagu paru
> godzin mogl w razie potrzeby dojechac do biura. W moim zasiegu jest zarowno
> Warszawa jak tez Krakow i okolice.
>

masz ladne CV, wiec niekoniecznie musza dotyczyc Cie standardowe
widelki. O ile, oczywiscie, znajdziesz firme, ktora potrzebuje kogos
specjalnego, jak Ty.

Co do standardowych warunkow - odradzam Krakow jako miejsce pracy -
DUZO mniej firm niz w Krakowie, duzo mniejsze wynagrodzenia i duzo
mniejsze perspektywy rozwoju (choc mieszka sie niesamowicie -
mieszkalem 10 lat, wiec wiem i milo wspominam :)) Polecam lekture
postu Jackare: http://www.tinyurl.pl/?Lvj0ox3O .

W warunkach warszawskich - nie wiem, jak wygladaja warunki finansowe
dla programisty powerbuildera, wiem za to, ze marnie wyglada rynek
pracy dla tej specjalnosci, z c++ jest lepiej, choc rynek jest tez
waski (z wiekszych - glownie telekomy), wynagrodzenia to ztcw 6-12k
pln brutto. Visual Basic - na to praktycznie w ogole nie ma rynku,
poza malymi firmami, tym sie zajmuja "analitycy" po roznych firmach
(choc raczej VBA). Zalecalbym przekwalifikowanie sie na bardziej
rynkowe technologie (typu j2ee czy .net), to i rynek wiekszy, i
wynagrodzenia sensowne (ztcw gorna granica widelek jest wyzej niz w c+
+).

Odn zdalnej pracy - czarno to widze. Firmy w Pl wola miec pracownika
na miejscu, zwlaszcza jesli placa mu sporo. Moze ew sprobuj
wspolpracowac zdalnie z (obecna) firma z Niemiec?

Na koniec - zarekomendowalbym Ci skontaktowanie sie z kilkoma firmami
rekruterskimi - tymi powazniejszymi - i omowienie mozliwych
propozycji.

--

Pozdrawiam,

glos

do góry

LukaszS wrote:

>>> Skąd taki pomysł, żeby dobry inżynier zostawał, w imię "awansu",
>>> kiepskim kierownikiem?
>>
>> http://www.chrabja.art.pl/element3.html
>>
>> poszukaj hasla "NIEKOMPETENCJA POTENCJALNA"
>>
>> Bardzo madry tekst ;-)
>
>
> Fajny tekst, ale nie tłumaczy, dlaczego powszechnie uważa się, że bycie
> kierownikiem jest bardziej ambitnym zadaniem, niż programistą. Ja np.
> zrezygnowałem z kierownictwa na rzecz szeregowego programowania. Żyję
> spokojniej, jestem zdrowszy i praca sprawia mi więcej radości.
>

Może i macie rację, natomiast ja uważam, że dobry inżynier powinien
nadzorować pracę młodych inżynierów, mających zadatki na dobrych
inżynierów. Dzięki takiej formule i odpowiednim zaangażowaniu Ci młodzi
inżynierowie uczą się jak być dobrym inżynierem, a dodatkowo ich
młodzieńcza i pełna kiepskich pomysłów praca w skonfrontowaniem z wielkim
doświadczeniem dobrego inżyniera daje efekty pracy właśnie dobrego
inżyniera. Kilka postów temu została wysnuta teoria, z którą się nie
zgadzam w żadnym aspekcie, a mianowicie:

> Skąd taki pomysł, żeby dobry inżynier zostawał, w imię "awansu",
> kiepskim kierownikiem?

Wynikałoby z tego, że dobry inżynier nie powinien budować całego samolotu, a
jedynie hamulec. A dokładniej pomagać przy budowie hamulca. Bo tam też
będzie szef budowy hamulca i kilku młodych którzy mu będą pomagać.

W odniesieniu do programowania, nie jest sztuką zakodować coś, sztuką jest
to zaprojektować, a następnie przeciągnąć projekt w satysfakcjonująco
krótkim czasie do końca tak, żeby był zrobiony porządnie. A tego z reguły
się nie da samemu nie rozciągając tego w czasie, natomiast mając zespół
ludzi, którzy pomagają w realizacji projektu robota idzie kilka razy
szybciej.

Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
byciem programistą, podobnie jak z tym samolotem i jego hamulcem.

do góry

On 27 Lis, 09:22, Herakles <h...@b...pl> wrote:
> Może i macie rację, natomiast ja uważam, że dobry inżynier powinien
> nadzorować pracę młodych inżynierów, mających zadatki na dobrych
> inżynierów. Dzięki takiej formule i odpowiednim zaangażowaniu Ci młodzi
> inżynierowie uczą się jak być dobrym inżynierem, a dodatkowo ich
> młodzieńcza i pełna kiepskich pomysłów praca w skonfrontowaniem z wielkim
> doświadczeniem dobrego inżyniera daje efekty pracy właśnie dobrego
> inżyniera. Kilka postów temu została wysnuta teoria, z którą się nie
> zgadzam w żadnym aspekcie, a mianowicie:
>
> > Skąd taki pomysł, żeby dobry inżynier zostawał, w imię "awansu",
> > kiepskim kierownikiem?
>
> Wynikałoby z tego, że dobry inżynier nie powinien budować całego samolotu, a
> jedynie hamulec. A dokładniej pomagać przy budowie hamulca. Bo tam też
> będzie szef budowy hamulca i kilku młodych którzy mu będą pomagać.
>
> W odniesieniu do programowania, nie jest sztuką zakodować coś, sztuką jest
> to zaprojektować, a następnie przeciągnąć projekt w satysfakcjonująco
> krótkim czasie do końca tak, żeby był zrobiony porządnie. A tego z reguły
> się nie da samemu nie rozciągając tego w czasie, natomiast mając zespół
> ludzi, którzy pomagają w realizacji projektu robota idzie kilka razy
> szybciej.
>
> Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
> byciem programistą, podobnie jak z tym samolotem i jego hamulcem.


czym innym jest sytuacja, w ktorej senior developer pelni funkcje
mentora na juniorow, a czym innym - gdy zabiera sie za managerowanie.
W pierwszym przypadku jego wiedza i umiejetnosci sa wykorzystywane
sensownie (o ile umie i chce przekazywac wiedze), w drugim - startuje
zupelnie od podstaw w nowej dla niego dziedzinie ("gdzie znajde
javadoca do tego gantta?"). Tak sie bowiem sklada, ze manager
potrzebuje calkowicie innych umiejetnosci niz projektant/programista i
wczesniejszy background techniczny czesto moze wylacznie szkodzic (np
dostosowywanie harmonogramu projektu do "fajnej" biblioteki). Praca
programisty nie przygotowuje tez do pelnienia funkcji "dwustronnego
zderzaka", a tym de facto jest manager.

PS. Obecnie jestem projektantem/programista, wczesniej roznie bywalo -
od programisty po szefa it. I zyje spokojniej - podobnie jak LukaszS.
Z podobna kasa :)

--

Pozdrawiam,

glos

do góry

> Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
> byciem programistą, podobnie jak z tym samolotem i jego hamulcem.

Ależ oczywiście. Wszystko zależy od zdolności i osobowości pacjenta. Podniosłem
tylko zarzut, że niesłusznie traktuje się kierownika projektu jako kogoś
wyższego od programisty.

Np. ja jestem indywidualistą. W moim przypadku dobrze szło mi kierowanie
kilkuosobowym projektem i dobrze idzie mi pisanie samodzielnych kawałków od A do
Z. Natomiast próby włączenia mnie do teamu mrówek pracujących pod okiem leadera,
to zwykle porażka i totalna wojna. Taka mam naturę, że za grzebanie w moim
kodzie, albo za zwracanie mi uwagi na kompozycję kodu podcinam gardło.

Inni dobrze się integrują z teamem i praca w grupie pod przewodnictwem lidera
idzie dobrze.
Inni mają talenty przywódcze, ale nie umieją programować.
Jeszcze inni są dobrymi programistami, ale nie potrafią zaprojektować aplikacji
jako całości.

Tak więc, IMHO, są to cechy osobnicze i nie warto generalizować.

--
Lukasz

do góry

> grzebanie w moim kodzie, albo za zwracanie mi uwagi na kompozycję kodu
> podcinam gardło.

To znaczy, że jak ktoś Ci pokaże, że coś możesz gdzieś zrobić lepiej to
podcinasz gardło? Ja tam wolę korzystać z dobrych rad.

Ogólnie we wszystkich kategoriach inżynierki jest tak, że nie ma typowej dla
innych dziedzin, hierarchii typu lider/manager który uprawia propagandę
sukcesu i jak piszesz mrówków wierzących w wielki sukces.
Wygląda to tak, że są zespoły strikte techniczne i mam tu przykłady, właśnie
it, jak i typowa inżynierka materiałowa. I tu i tu hierarchia jest taka
sama czyli jest szef "techniczny" który doświadczonym specjalistą, kieruje
zwykle kilkuosobowym zespołem młodszych specjalistów i razem budują czy to
aplikację, czy to super-wytrzymały pręt. A dopiero nad takim zespołem jest
albo jeszcze jeden specjalista, albo od razu nad nim jest już gość od
zarządzania, który realizuje zarówno potrzeby płacowe jak i sprzętowe.
Nad takim zespołem często też czuwa ktoś(tu chodzi o poszczególne
aplikacje), kto kontroluje co gdzie i kiedy było zrobione i se zapisuje co
w danej wersji aplikacji jest zrobione. A jak to u was wygląda, chętnie się
dowiem.
W każdym razie odnosząc się do meritum, to że po jakimś czasie na stanowisku
technicznym stoi się na stanowisku kierowniczym, czy to na czele zespołu
czy jako mrówka, wydaje mi się oczywistą koleją rzeczy, a nie tempym
awansem.

> Inni dobrze się integrują z teamem i praca w grupie pod przewodnictwem
> lidera idzie dobrze.
> Inni mają talenty przywódcze, ale nie umieją programować.
> Jeszcze inni są dobrymi programistami, ale nie potrafią zaprojektować
> aplikacji jako całości.
>
> Tak więc, IMHO, są to cechy osobnicze i nie warto generalizować.

do góry

>> grzebanie w moim kodzie, albo za zwracanie mi uwagi na kompozycję kodu
>> podcinam gardło.

> To znaczy, że jak ktoś Ci pokaże, że coś możesz gdzieś zrobić lepiej to
> podcinasz gardło? Ja tam wolę korzystać z dobrych rad.

Ależ ja korzystam. Ale najpierw podcinam gardło :))) Za grzebanie w nie swoim
kodzie. A kompozycja (format) kodu, to temat - morze. Jeden lubi nawiasy w
osobnej linii, a inny w tej samej. Jeden stawia średniki za nawiasem, a inny
nie. Jeden stawia podkreślenia przed nazwami parametrów funkcji a inny nie.
Jeśli jeden i ten programista pracuje nad swoim kodem przez 5 lat to ma prawo
tak sobie sformatować, jak lubi. Inaczej, gdy pracuje w teamie, w którym 10 osób
grzebie sobie nawzajem w tym samym kodzie. Podpadłeś.


> Nad takim zespołem często też czuwa ktoś(tu chodzi o poszczególne
> aplikacje), kto kontroluje co gdzie i kiedy było zrobione i se zapisuje co
> w danej wersji aplikacji jest zrobione. A jak to u was wygląda, chętnie się
> dowiem.

Moduły programu są ściśle podzielone z absolutnie minimalnym i niezmienialnym
interfejsem pomiędzy nimi. Ja siedzę nad komunikacją z urządzeniami, kolega nad
interfejsem użytkownika, jeszcze inny nad bazą, jeszcze inny nad interfejsami
wymiany danych z innymi programami itp... każdy odpowiada za swój kawałek. Ich
praca styka się w niewielu punktach. Ponieważ warunki pracy sa niezłe - nie ma
nadmiernej rotacji pracowników, a przy okazji wiele z tym związanej dodatkowej
pracy.
Nad tym wszystkim stoi szef projektu, który określa:
- interfejsy pomiędzy programistami (to tylko na samym początku projektu)
- bieżące zadania do realizacji
- synchronizację zadań pomiędzy programistami
- analizuje potrzeby klientów
itp.

--
Lukasz

do góry

LukaszS wrote:

>>> grzebanie w moim kodzie, albo za zwracanie mi uwagi na kompozycję kodu
>>> podcinam gardło.
>
>> To znaczy, że jak ktoś Ci pokaże, że coś możesz gdzieś zrobić lepiej to
>> podcinasz gardło? Ja tam wolę korzystać z dobrych rad.
>
> Ależ ja korzystam. Ale najpierw podcinam gardło :))) Za grzebanie w nie
Jak dla mnie to jest chore podejście.

> swoim kodzie. A kompozycja (format) kodu, to temat - morze. Jeden lubi
> nawiasy w osobnej linii, a inny w tej samej. Jeden stawia średniki za
> nawiasem, a inny nie. Jeden stawia podkreślenia przed nazwami parametrów
> funkcji a inny nie. Jeśli jeden i ten programista pracuje nad swoim kodem
> przez 5 lat to ma prawo tak sobie sformatować, jak lubi. Inaczej, gdy
> pracuje w teamie, w którym 10 osób grzebie sobie nawzajem w tym samym
> kodzie. Podpadłeś.

A jak się zdarzy, że któryś z was zachoruje i to tak, że nie da rady
popracować, a trzeba coś zrobić i zmieni Ci znaki tabulacji na spacje?
Ja w swoich projektach trzymam kod na pewnym ustalonym poziomie, nauczenie
człowieka, żeby zamiast tabulacji walił 3 spacje, albo żeby dawał nawiasy w
osobnej linii, zajmuje mniej niż tydzień i jak jeden ma pilną sprawę z
innej bajki, to drugi może przejąć jego obowiązki, szczególnie przy
pierdołach, bo przy głębszych sprawach jest już trudniej. Więc rotacji się
nie boję, a i tak rotacji nie ma, bo warunki są jak dla mnie bardzo
dobre(zawsze może być jednak lepiej).
Może zbytni pedantyzm, ale mam pozamiatane.


>> Nad takim zespołem często też czuwa ktoś(tu chodzi o poszczególne
>> aplikacje), kto kontroluje co gdzie i kiedy było zrobione i se zapisuje
>> co w danej wersji aplikacji jest zrobione. A jak to u was wygląda,
>> chętnie się dowiem.
>
> Moduły programu są ściśle podzielone z absolutnie minimalnym i
> niezmienialnym interfejsem pomiędzy nimi. Ja siedzę nad komunikacją z
> urządzeniami, kolega nad interfejsem użytkownika, jeszcze inny nad bazą,
> jeszcze inny nad interfejsami wymiany danych z innymi programami itp...
> każdy odpowiada za swój kawałek. Ich praca styka się w niewielu punktach.
> Ponieważ warunki pracy sa niezłe - nie ma nadmiernej rotacji pracowników,
> a przy okazji wiele z tym związanej dodatkowej pracy.
> Nad tym wszystkim stoi szef projektu, który określa:
> - interfejsy pomiędzy programistami (to tylko na samym początku projektu)
> - bieżące zadania do realizacji
> - synchronizację zadań pomiędzy programistami
> - analizuje potrzeby klientów
A ten szef projektu programuje?

A kto projektuje całość, bo nawet jak każdy z was projektuje te swoje części
to musi ktoś to zebrać do kupy.

do góry