-
Data: 2013-02-07 10:34:31
Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
Od: Maciej Sobczak <s...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]W dniu środa, 6 lutego 2013 23:18:56 UTC+1 użytkownik Andrzej Jarzabek napisał:
> >> Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
> >> checkboksów?
>
> > Z refleksji wynika lista checkboksów a z tej listy konkretne
> > rozwiązanie problemu.
>
> Więc liczenie wydaje mi się zbędnym etapem, bo jeśli z refleksji i z
> liczenia wynikają sprzeczne wnioski,
Nie zrozumiałeś. Nie mogą wyjść sprzeczne, bo to są różne etapy jednego procesu.
Refleksja prowadzi do określenia wymagań (checkboksów), natomiast ich liczenie odbywa
się później, przy wyborze konkretnego narzędzia. Nie rozumiem, gdzie tu może powstać
sprzeczność.
> > Jeżeli masz ludzi, którzy nie chcą się rozwijać, to nie będą. Pomyśl
> > o tym już w czasie ich zatrudniania.
>
> Ale też rozwijać można się w bardzo różnych kierunkach. Jako javowiec
> możesz spokojnie rozwijać się w kierunkach, w których zalety Scali nigdy
> nie wypłyną: TDD, refaktoryzacja, design patterns, Spring, CI, cotamjeszcze.
Nie! Nie da się. Nie można wprowadzić Springa czycotamjeszcze, bo... <tu wstaw
wszystkie swoje argumenty, które do tej pory napisałeś>.
> Konflikt przejawia się np. tym, że w twojej metodzie checkboksowej
> pracodawca wpisałby checkboska "trudniej będzie wymieniać programistów"
> po stronie wad, natomiast programista mógłby go wpisać po stronie zalet.
Pracodawca musi się zdecydować, jak widzi rolę swojego biznesu na rynku, np. czy chce
być twórcą rozwiązań, czy ich integratorem, liderem, czy w ogonie, czy chce
podejmować ryzyko inwestując i być może tracąc czy też odwrotnie, itp. Z tego wynika
też różne ryzyko podejmowanych działań a w tym są takie rozważania jak to, czy coś
jest trudno wymienić. Podobnie jak z samochodami - w tych lepszych też różne rzeczy
się trudniej wymienia.
> Dyskutujesz z moją dygresją, że może nie należy pozwolić programiście
> wybierać technologii, bo programista może wybrać to, co go osobiście
> interesuje (jest cool, modne), a nie to, co jest dobre dla projektu.
A skąd wiadomo, co jest dobre dla projektu? A może akurat w firmie, która chce być
liderem branży (albo nawet jakiejś niszy) i chce podejmować ryzyko techniczne,
właśnie większy entuzjazm programisty jest dobry? Kto o tym ma decydować? (hint:
znowu checkboksy, choć na innym poziomie)
> Natomiast
> zauważę, że w wielu instytucjach takie decyzje podejmuje się na
> jakichśtam stanowiskach kierowniczych typu "head of development" czy CTO.
I czy to sprawia, że nie mogą być podjęte? Nadal mogą.
W takim np. Google'u jakiś tam head of developmen nie tylko zdecydował, że można coś
wprowadzić, ale nawet że można w ogóle stworzyć coś nowego (np. Go). Czyli masz
przykład na to, że da się taką decyzję podjąć.
Z jakiegoś powodu ze słowem "lider" bardziej kojarzy mi się właśnie firma Google a
nie np. "Systemy Do Liczenia Kaloszy w Magazynach Sp. z o.o.".
> Cały czas jednak problem w konflikcie interesów - po refleksji dla
> pracownika dobre może być co innego niż dla pracodawcy.
Jak już napisałem, określenie docelowego wizerunku firmy i jej roli na rynku (lub w
jakiejś niszy) jest decyzją strategiczną i faktycznie należy do grupy trzymającej
władzę - ale właśnie od tej decyzji zależą losy np. oddolnych inicjatyw
programistycznych typu używać Scalę czy nie używać. Konflikt, o którym piszesz, nie
musi wystąpić a proces rekrutacji jest tym momentem, kiedy można się wzajemnie
rozpoznać - oczywiście w ograniczonym zakresie, ale jednak.
I tak, np. gdybyś chciał mnie zatrudnić, to oprócz pytania co miałbym robić
zapytałbym też o to, jaki miałbym wpływ na kierunek techniczny.
> > Tak. Wtedy będą robić mniej ciekawe rzeczy w mniej wartościowym
> > projekcie. Nie widzę problemu.
>
> Ale rekrutujesz, bo potrzebujesz programistów do tego akurat projektu.
Albo po to, żeby ogólnie rozwijać firmę. Nie muszę mieć na myśli żadnego konkretnego
projektu.
> Nie chodziło o wielkość projektu, tylko o skalę kumatości, której
> wymagasz. To, że lepiej zatrudniać kumatych nie znaczy, że nie możesz
> strzelić sobie w stopę stawiając poprzeczkę zbyt wysoko (bo np. nikogo
> aż tak kumatego nie uda ci się znaleźć).
Bez przesady. Na razie udaje nam się zatrudniać kumatych pracowników.
Ogólnie mam wrażenie, że kręcimy się w kółko w tej dyskusji, niczego nowego już do
niej nie dodając. Chyba mamy różne doświadczenia z projektów o różnych kulturach ich
prowadzenia.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
Następne wpisy z tego wątku
- 07.02.13 13:24 M.M.
- 07.02.13 23:07 Andrzej Jarzabek
- 07.02.13 23:51 Andrzej Jarzabek
- 08.02.13 05:05 M.M.
- 08.02.13 07:43 firr kenobi
- 08.02.13 08:30 firr kenobi
- 08.02.13 11:20 Maciej Sobczak
- 08.02.13 14:06 M.M.
- 08.02.13 14:12 Stachu 'Dozzie' K.
- 08.02.13 14:22 M.M.
- 08.02.13 17:45 darekm
- 08.02.13 17:49 Andrzej Jarzabek
- 08.02.13 18:14 Andrzej Jarzabek
- 08.02.13 18:52 M.M.
- 08.02.13 18:52 Andrzej Jarzabek
Najnowsze wątki z tej grupy
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-01-13 Zasięg Tesli przy szybszej jeździe
- 2025-01-13 Gdańsk => Application Security Engineer <=
- 2025-01-13 Białystok => System Architect (Java background) <=
- 2025-01-13 Warszawa => Konsultant ds. sprzedaży <=
- 2025-01-13 Warszawa => Key Account Manager <=
- 2025-01-13 Szczecin => Senior Field Sales (system ERP) <=
- 2025-01-13 Rzeszów => International Freight Forwarder <=
- 2025-01-13 Bydgoszcz => Specjalista ds. Sprzedaży (transport drogowy) <=
- 2025-01-13 Poznań => Konsultant wdrożeniowy Comarch XL/Optima (Księgowość i
- 2025-01-13 Warszawa => Staż w dziale Sprzedaży B2B <=
- 2025-01-13 Wydajność klimy w obecnych temperaturach
- 2025-01-13 Błonie => Analityk Systemów Informatycznych (TMS SPEED) <=
- 2025-01-13 Kraków => UX Designer <=
- 2025-01-13 Katowice => Key Account Manager (ERP) <=
- 2025-01-13 Mińsk Mazowiecki => Spedytor Międzynarodowy <=