Rozumiem, że w firmie tworzycie tylko i wyłącznie jeden software i nie ma możliwości abyś testował coś, czego nie piszesz.
0
0
Możesz jaśniej? Pracuję w jednym projekcie i jestem programistą. Mam stawiać komuś z innego projektu własne wymagania? Podaj przykłady takich zachowań z własnego doświadczenia.
0
Poużywać ich softu i dać feedback.
Oczywiście twoja perspektywa w 100% nie oddaje przeciętnego klienta, ale nadal jest lepsza niż kogoś, kto piszę w tym projekcie od 800h.
0
W firmie używam tylko softu, którego jestem klientem końcowym oraz systemu, który tworzę z zespołem (klikamy dla testów). Dla przykładu:
- narzędzia dla programisty: Jira (wcześniej było Rational Team Concert), GitHub, TeamCity, Pivotal Cloud Foundry, etc
- narzędzia dla korpoludka do raportowania czasu pracy, urlopów, etc
Żeby potestować systemy tworzone przez inne zespoły musiałbym mieć u nich konto, a ot tak mi nie dadzą, bo chcę sobie poklikać. Podobnie działa to w drugą stronę - nasz system jest otwarty tylko dla mnie i reszty programistów z zespołu, biznesu (stawiającego wymagania) oraz klientów końcowych (których perspektywę powinien znać biznes, bo to jego brocha).
0
fajnie, ale co to ma do rzeczy? Jeżeli ktoś tworzy projekt, którego beneficjentem w znacznej większości są kobiety, to dlaczego pracodawca miałby się wahać z zatrudnieniem programistki?
To jest banalne:
Jeżeli miałbym zorganizować konferencję dla programistów to wiedziałbym jakie
a) jakie persony zaprosić
b) jakie tematy przyciągną ludzi od hype-driven-development, a które egzotyczne lepszych gości
c) jakie easter eggi / żarty z php / javy przygotować
Ale jeżeli miałbym zorganizować konferencje dla nastolatek, fanek anime to kompletnie nie mam pomysłu.
0
fajnie, ale co to ma do rzeczy? Jeżeli ktoś tworzy projekt, którego beneficjentem w znacznej większości są kobiety, to dlaczego pracodawca miałby się wahać z zatrudnieniem programistki?
Nie pisałem o jakimś wahaniu, ale o zysku samym w sobie z zatrudnienia programistki. Poza tym: jakoś tak się składa, że serwisy do wstawiania słit foci są zaprogramowane przez facetów.
To jest banalne:
Jeżeli miałbym zorganizować konferencję dla programistów to wiedziałbym jakie
a) jakie persony zaprosić
b) jakie tematy przyciągną ludzi od hype-driven-development, a które egzotyczne lepszych gości
c) jakie easter eggi / żarty z php / javy przygotowaćAle jeżeli miałbym zorganizować konferencje dla nastolatek, fanek anime to kompletnie nie mam pomysłu.
Tu akurat stawiasz siebie w roli osoby stawiającej wymagania (jakie tematy będą się nadawać), a nie osoby je realizującej (przedstawiającej dany temat).
Ja jako programista nie stawiam wymagań biznesowych w projekcie. Co najwyżej je analizuję i proponuję zmiany, które ułatwią implementację, zmniejszą negatywny wpływ na wydajność systemu, itp Są to zmiany oparte o doświadczenie w programowaniu, a nie w branży w której specjalizują się klienci.
1
W ogóle to jaki ciemnogród tu się odprawia.
Jak śmiecie używać w ogóle kategorii płci skoro jest ich tak wiele lol
0
Chodziło o przedstawienie pewnej oczywistości, a mianowicie, że pewne osoby rozumieją / nadają się do pewnych rzeczy bardziej.
Jeżeli masz dwóch kandydatów o tych samych skillach itd, ale różni je wiedza w zakresie danego zagadnienia, to dlaczego miałbym wybrać tą ze słabszą wiedzą z tego zagadnienia?
np. pisząc soft do jakichś rozliczeń finansowych i mam do wyboru:
A) Absolwenta/Absolwentkę Informatyki oraz ekonomii
B) Absolwenta/Absolwentkę Informatyki oraz AiR
A wydaje się być oczywistym wyborem.
Ja jako programista nie stawiam wymagań biznesowych w projekcie. Co najwyżej je analizuję i proponuję zmiany, które ułatwią implementację, zmniejszą negatywny wpływ na wydajność systemu, itp Są to zmiany oparte o doświadczenie w programowaniu, a nie w branży w której specjalizują się klienci.
Jeżeli jesteś ekspertem w dziedzinie X, a twój klient właśnie w niej działa i jesteś w stanie mu doradzić, że jego pomysł nt. Y jest słaby, to mu będziesz próbował doradzić (założenie).
A jeżeli nie jesteś, to mu nie doradzisz i później klient na tym straci.
0
Jeżeli masz dwóch kandydatów o tych samych skillach itd, ale różni je wiedza w zakresie danego zagadnienia, to dlaczego miałbym wybrać tą ze słabszą wiedzą z tego zagadnienia?
Racja - programista z dodatkową wiedzą biznesową szybciej załapie wymagania biznesowe niż programista z samą wiedzą techniczną o programowaniu i to jest oczywisty atut. Nie zmienia to jednak faktu, iż:
- stawianiem wymagań co do systemu zajmują się nie programiści, a osobny zespół, czyli biznes
- lepiej by osobą która pośredniczy między programistami, a biznesem by analityk biznesowy, a nie pół-programisto pół-analityk (no chyba, że ktoś stosuje zasadę "specialization is for insects", ale to wybitnie niekorporacyjne podejście)
Jeżeli jesteś ekspertem w dziedzinie X, a twój klient właśnie w niej działa i jesteś w stanie mu doradzić, że jego pomysł nt. Y jest słaby, to mu będziesz próbował doradzić (założenie).
A jeżeli nie jesteś, to mu nie doradzisz i później klient na tym straci.
Jestem odizolowany od klientów spoza tzw biznesu. To biznes ma się zajmować zbieraniem wymagań od klientów. Jest wyraźny podział odpowiedzialności, tak jak na korporację przystało. HSBC to nie startup bym był człowiekiem orkiestrą.
0
Znajomość tematu w żaden sposób nie czyni z ciebie gorszego programisty, a biznes nie zawsze przemyśli wszystko co się da. Oczywiście z tym nie ma przecież problemu, bo Don't fuck your customers ;)
lepiej by osobą która pośredniczy między programistami, a biznesem by analityk biznesowy, a nie pół-programisto pół-analityk (no chyba, że ktoś stosuje zasadę "specialization is for insects", ale to wybitnie niekorporacyjne podejście)
To raczej zweryfikuje rekruter i to on uznaje czy 5 punktów mniej w wyimaginowanej skali umiejętności programowania jest rekompensowane przez 10 pkt w skali znajomości tematu jest opłacalnym kompromisem.
Jestem odizolowany od klientów spoza tzw biznesu. To biznes ma się zajmować zbieraniem wymagań od klientów. Jest wyraźny podział odpowiedzialności, tak jak na korporację przystało. HSBC to nie startup bym był człowiekiem orkiestrą.
To teraz ludzi mających predyspozycje/doświadczenie/wiedze/umiejętności do danych zadań nazywamy człowiekiem orkiestrą? :D
To, że wolałbym mieć ludzi ogarniających temat klienta wcale nie oznacza, że będę ich wysłał do klienta.
0
Programista w trakcie kariery nabywa zarówno wiedzę biznesową (z zakresu funkcjonalności produktu, który rozwija) jak i techniczną (szlifuje sztukę programowania). Ważne jest jedno i drugie, ale programista jest rozliczany z tego, czy zbuduje wydajny, bezpieczny, stabilny i tani w utrzymaniu system (bo biznes mu nie powie jak to zrobić, bo sam nie wie), a nie czy dogada się z klientami.
W moim przypadku (finanse, bankowość) utrzymywanie wysokiego poziomu wiedzy biznesowej przez programistę jest w zasadzie niemożliwe. Zbyt dużo jest zewnętrznych systemów z którymi się komunikujemy i które ewoluują, regulacji które się zmieniają i produktów, które są oferowane, by za tym wszystkim nadążyć i jeszcze podpowiadać biznesowi co można poprawić. Chociaż z drugiej strony, jeśli dostanę wymagania i wyłapię w nich błąd, bo coś mi się nie będzie zgadzać to oczywiście postaram się to z biznesem wyprostować.
Mamy analityka biznesowego, który potrafi czytać większość kodu Scalowego, który mamy w projekcie, a nawet czasem coś prostego w Scali zaklepie (bo nie chce czekać, aż programiści się wygrzebią ze swoimi dużymi zadaniami). On ma bardzo dużo czasu i okazji by poznawać nasz system oraz powiązane systemy od strony zarówno biznesowej jak i technicznej (bo wie jak korzystać z i do czego służy SFTP, SCP, JMS, Kafka, REST, bazy danych, chmury obliczeniowe, dyskowe, etc) oraz negocjować z biznesem wymagania co do naszego systemu. Jesteśmy bardzo zadowoleni, że mamy takiego analityka i możemy się zająć porządnym kodowaniem, a nie mozolnym dogadywaniem się z biznesem.
1
No widzisz, czyli ten analityk jest taką osobą xD
Tyle, że zamiast bycia programistą* z jakąś wiedzą z X
To jest ekspertem z X, który ma jakąś wiedzą z programowania i nikt nie broni aby to działało w dwie strony, bo przecież nie każda firma i projekt to HSBC | Banking.
W moim przypadku (finanse, bankowość) utrzymywanie wysokiego poziomu wiedzy biznesowej przez programistę jest w zasadzie niemożliwe.
Pisanie bez wiedzy biznesowej też jest niemożliwe, a jeżeli masz dwie takie same skillowo osoby, a jedna już byłaby w jakimś stopniu wdrożona i zaznajomiona, to wybór oczywisty
Nikt nie sugeruje, że musisz dogadywać się z biznesem. Po prostu masz rozumieć jak to działa i jest to twoja karta przetargowa w porównaniu do innych rekrutujących.
0
No widzisz, czyli ten analityk jest taką osobą xD
Tyle, że zamiast bycia programistom z jakąś wiedzą z X
To jest ekspertem z X, który ma jakąś wiedzą z programowania i nikt nie broni aby to działało w dwie strony, bo przecież nie każda firma i projekt to HSBC | Banking.
- programistĄ, a nie programistOM
- Nikt też nie broni by chodzić na rękach, ale trzeba zachowywać się sensownie. Jeśli mamy skomplikowany problem to lepiej rozdzielić go na podproblemy i mieć wyspecjalizowanych pracowników, niż każdemu zlecać zajmowanie się wszystkim po łebkach.
Kiedyś napalałem się na algorithmic trading. Myślałem, że algorytmami zajmują się programiści. Niestety - algorytmy wymyślają kolesie ledwo klepiący w Pythonie czy R, a potem prawdziwi programiści mają zadanie przepisać to na C++ czy Javę, optymalizując przy okazji wydajność. Taki podział sprawił, że straciło to dla mnie swój urok, bo chciałem prowadzić sprawę od początku do końca.
Pisanie bez wiedzy biznesowej też jest niemożliwe, a jeżeli masz dwie takie same skillowo osoby, a jedna już byłaby w jakimś stopniu wdrożona i zaznajomiona, to wybór oczywisty
Z tym już się przecież zgodziłem.
0
Jeśli mamy skomplikowany problem to lepiej rozdzielić go na podproblemy i mieć wyspecjalizowanych pracowników, niż każdemu zlecać zajmowanie się wszystkim po łebkach.
ale jakich łebkach? o czym ty mówisz? :D
Masz po prostu dobrych SE, którzy dodatkowo mają praktyczną i teoretyczną wiedzę dotyczącą zagadnienia które kodują, tyle.
Z tym już się przecież zgodziłem.
Zatem tutaj wypadałoby zakończyć, bo o to chodziło.
0
ale jakich łebkach? o czym ty mówisz? :D
Masz po prostu dobrych SE, którzy dodatkowo mają praktyczną i teoretyczną wiedzę dotyczącą zagadnienia które kodują, tyle.
Siłą rzeczy każdy programista w zespole ma jakąś wiedzę biznesową. Jeśli z nią nie przychodzi to nabywa ją w pierwszych kilku miesiącach pracy. Bez tego ciężko samodzielnie pracować. Jednak wiedzę biznesową na tyle dużą, by sugerować biznesowi poprawki w wymaganiach biznesowych ma tylko nasz analityk.
0
W twoim przypadku tak, ale nie w każdym.
Zresztą, wiedza z danego zagadnienia nie służy tylko i wyłącznie aby doradzać klientowi, a głównie jest po to, aby lepiej napisać soft.
0
Zresztą, wiedza z danego zagadnienia nie służy tylko i wyłącznie aby doradzać klientowi, a głównie jest po to, aby lepiej napisać soft.
No przecież post wyżej napisałem, że pewien zasób wiedzy biznesowej jest niezbędny by samodzielnie pisać kod. Jednak by osiągnąć zasób wiedzy biznesowej na tyle duży, by sugerować poprawki biznesowi to trzeba poświęcić dużo czasu na jej zdobywanie. Kto dostaje na to czas w pracy? Widziałeś kiedyś by jakiś programista założył sobie zadanie w Jirce typu "a teraz będę 5h czytał o X", a w następnym tygodniu "a tez będę 5h czytał o Y". Żeby być na bieżąco z wiedzą biznesową trzeba się na bieżąco doszkalać.
0
Podkreśliłem, że głownie chodzi o napisanie softu lepiej, bo mając wiedze z danej dziedziny inaczej możesz patrzeć na problemy niż totalny newbie. Doradzanie klientowi to już bardziej na zasadzie "fajnie jakby się dało", ale daleko od tego, aby ktoś oczekiwał tego od ciebie.
Niepotrzebnie komplikujesz i rozbijasz na jakieś dziwne przypadki
jeżeli masz dwie takie same skillowo osoby, a jedna już byłaby w jakimś stopniu wdrożona i zaznajomiona, to wybór oczywisty
O to chodzi
0
Czyli wszystko sprowadza się do tego, że zatrudnienie programisty mającego już jakąś wiedzę biznesową skraca czas jego wdrożenia?
0
oraz to, co wrzuciłem w 1 poście.
0
Dużo osób pisze że płeć nie ma nic do rzeczy. Mam odmienną opinię. Zdarzało się już kilkakrotnie, że moje koleżanki ze studiów IT, które posiadały nikłą wiedzę dostawały pracę bez problemu, gdy znajomi którzy naprawdę byli ogarniaczami nie dostawali się. Co więcej sama rozmowa kwalifikacyjna była prowadzona w zupełnie inny sposób. Nie mówię, że to zachowanie występuje wszędzie, ale niektóre firmy działają w ten sposób aby "dobić" dziewczynami do jakiegoś tam poziomu zatrudnienia, co wydaje się żałosne.
0
@marmite:
Ogarniacze mają własne zdanie, własną koncepcję pracy i wyrobiony własny styl. To nie jest dobry materiał na pracownika zespołowego.
Dlatego niektórzy pracodawcy wolą zatrudnić kogoś bez pomysłu na siebie, bo zrobi dokładnie to, co mu się każe i będzie miał niższe wymagania finansowe. Tutaj pojawiają się pół-ogarnięte dziewczyny IT jako idealny kandydat.
1
Przerzućmy wszystko do Indii.
0
3
U mnie dziewczyny na roku (Informatyka) to rak.
W większością nie da się nie pogadać, notatek taka nie pożyczy, za to puszy to się jak paw na wybiegu.
Nie dość że, będzie rozwalała zespół swoimi foszkami, to wątpliwe żeby była kompetentna.
0
Wibowit napisał(a):
Kiedyś napalałem się na algorithmic trading. Myślałem, że algorytmami zajmują się programiści. Niestety - algorytmy wymyślają kolesie ledwo klepiący w Pythonie czy R, a potem prawdziwi programiści mają zadanie przepisać to na C++ czy Javę, optymalizując przy okazji wydajność. Taki podział sprawił, że straciło to dla mnie swój urok, bo chciałem prowadzić sprawę od początku do końca.
w firmach typu hsbc, ubs cz goldman rzeczywiscie tak bylo, ale nawet oni zauwazaja ze jest to skrajnie nieefektywne. bardzo czesto dochodzi do sytuacji ze quanci okazuja sie tak samo bezuzyteczni jak biznes analitycy i algo traderzy dogaduja sie bezposrednio z programistami. w mniejszych firmach w ogole research jest gdzies tam z boku i bardziej zajmuje sie robieniem wody z mozgu klientom i kompilowaniem raportow post trade czy transaction cost analysis po to zeby dac wskazowki algo developerom ktorzy wiedza lepiej co zrobic zeby bylo dobrze.
2
Wydaje mi się, że taka nawet na siłę promocja różnorodności może mieć sens, żeby w danej organizacji rozcieńczyć przewagę "troglodyckiego" myślenia (brogrammers itp.). W konsekwencji może osoby z mniejszości będą się czuły w takiej organizacji lepiej. Chodzi po prostu o zwiększenie puli potencjalnie wybitnych jednostek, które będą w niej przez dłuższy czas produktywne, bo rekrutacja jest tylko początkiem. Co z tego, że ktoś zostanie zatrudniony, jak potem atmosfera w firmie szybko skłoni tę osobę do odejścia. Zgaduję, że im większa organizacja, tym korzyść może być większa, aż do poziomu całej ludzkości. Tu podrzucę dość rzewny cytat ;), który jednak trochę daje do myślenia.
I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops.
― Stephen Jay Gould, The Panda's Thumb: More Reflections in Natural History
1
Co jakiś czas widzę jak ktoś martwi się tym marnowaniem potencjału nieodkrytych geniuszy. Po pierwsze, geniusz nie zawsze jest potrzebny i pożądany. Po drugie, znalezienie takiego niedocenionego geniusza może być znacznie kosztowniejsze niż jakiekolwiek zyski z niego. Ważniejsze od odkrywania każdego niedocenionego geniusza z osobna jest zwiększenie efektywności tych, którzy już są w odpowiednim miejscu.
Wydaje mi się, że taka nawet na siłę promocja różnorodności może mieć sens, (...). Chodzi po prostu o zwiększenie puli potencjalnie wybitnych jednostek
Promocja różnorodności na siłę to zatrudnianie kiepskich jednostek. Zamiast uzbierać punkty z samych umiejętności, kandydat/ kandydatka dostaje ekstra punkty za różnorodność. Wygląda na to, że nie przeczytałeś tematu.
PS: w praktyce, w socjalizmie na stanowiskach decyzyjnych są głąby.
0
Wibowit napisał(a):
Ważniejsze od odkrywania każdego niedocenionego geniusza z osobna jest zwiększenie efektywności tych, którzy już są w odpowiednim miejscu.
Ja to dobrze rozumiem. Miejsce akcji: Polska, klepanie CRUD-ów i - niech będzie - ETL-i i raportów w outsourcingu, pilnowanie ciepłych stołków. ;)
Ale są jeszcze inne miejsca akcji na świecie.
Promocja różnorodności na siłę to zatrudnianie kiepskich jednostek.
Akurat wyciąłeś kluczową część mojej wypowiedzi. Sam użyłem określenia "na siłę", bo nie uważam, że taka rekrutacja z preferencjami jest fair, ale ona jest tylko początkiem procesu, bo przecież jak Google hipotetycznie będzie miało 60 % kobiet, to chyba jednak przestaną je wtedy preferować.
1
Ja to dobrze rozumiem. Miejsce akcji: Polska, klepanie CRUD-ów i - niech będzie - ETL-i i raportów w outsourcingu, pilnowanie ciepłych stołków. ;)
Ale są jeszcze inne miejsca akcji na świecie.
No pewne już podałeś w cytacie: cotton fields and sweatshops. Zdecyduj się co chcesz powiedzieć. W którym kraju i w jaki sposób chcesz robić rewolucję odkrywania niedocenionych geniuszów?
Akurat wyciąłeś kluczową część mojej wypowiedzi. Sam użyłem określenia "na siłę", bo nie uważam, że taka rekrutacja z preferencjami jest fair, ale ona jest tylko początkiem procesu, bo przecież jak Google hipotetycznie będzie miało 60 % kobiet, to chyba jednak przestaną je wtedy preferować.
Bardzo "yntelygentne" podejście. Najpierw zatrudnijmy 60% kobiet, by potem je powoli odsiewać, zamiast odsiewać je na początku tak jak facetów. Widać czysty i namacalny zysk. Tylko w jaki sposób odsiewać już po zatrudnieniu? Czekać aż sama odejdzie?
Zresztą zależy jak liczyć diversity. W HSBC już teraz większość zatrudnionych to kobiety jeśli weźmiemy pod uwagę firmę ogólnie, ale jeśli brać pod uwagę tylko zespoły programistów to jest daleko do 50/50. Prędzej kaktus mi na ręce wyrośnie niż Google będzie zatrudniać 50/50 wśród programistów w Dolinie Krzemowej w krytycznych dla firmy projektach.