Pytanie:
Czy warto zadać pytanie, jeśli wiesz, że odpowiedź brzmi „nie”?
Lord Farquaad
2017-08-04 20:11:27 UTC
view on stackexchange narkive permalink

Jestem stosunkowo nowym programistą (2 miesiące) w stosunkowo małej firmie. Otrzymałem zadanie znalezienia rozwiązania problemu, który mieliśmy, i pomyślałem o dwóch sposobach rozwiązania tego problemu.

Opcja A jest dość przeciętnym rozwiązaniem. Naprawdę nie ma w tym nic specjalnego, ale wykonuje swoją pracę.

Opcja B również wykonuje swoje zadanie, ale jest znacznie sprytniejsza. Jest trochę szybszy i działa tylko dlatego, że wykorzystuje kilka sposobów konfiguracji naszego systemu. Problem polega na tym, że musielibyśmy dokonać niewielkiej zmiany, aby opcja B zadziałała (taka, której nie mogę samodzielnie wprowadzić).

Ponieważ jestem nowy, problem jest podejście nie jest zbyt znaczące w ogólnym planie, więc szczerze mówiąc nie ma wielkiej korzyści z używania B zamiast A. Zmiana, którą musielibyśmy wprowadzić, jest również dość nieistotna, ale ponieważ żadne rozwiązanie tutaj naprawdę nie oszczędza zbyt wiele firmy czas / zasoby, prawdopodobnie nie warto wprowadzać zmian. Bardziej sensowne jest wybranie opcji A.

Jednak gdybym właśnie zrobił A, to zgłosiłbym szefowi „problem został rozwiązany, zrobiłem bla bla bla…” i nie robię tego Myślę, że jego postrzeganie mnie w ogóle się zmieni. Co niekoniecznie jest złe, ale też nie jest dobre.

Wiem na pewno, że gdybym zwrócił się do niego i zapytał „Wymyśliłem dwie opcje rozwiązania problemu, A i B. B jest lepsze, ale musielibyśmy zmienić cokolwiek, „powiedziałby, żeby po prostu zrobić A. Ale czuję, że daje mi to okazję do nieco naprężenia moich„ mięśni mózgu ”, a także do pokazania, że ​​wychwytuję szczegóły dotyczące konfiguracji naszego systemu. Trochę się popisuje, ale nie sądzę, żeby to było oczywiste, i szczerze mówiąc, nie wiem, czy odrobinę popisywanie się przed szefem jest po prostu złą rzeczą. Zwłaszcza w przypadku nowych pracowników, w których ludzie wciąż próbują zrozumieć, co wiesz.

Czy warto pytać o B, mimo że wiem, że mój szef powie „nie”?

Jako bardziej ogólne pytanie: czy warto zaproponować rozwiązanie, o którym wiesz, że zostanie odrzucone, jeśli pokaże to, co wiesz (lub nauczyłeś się)?

Czy więc opcja B jest obiektywnie lepsza niż opcja A?Widzę, że mówisz, że jest sprytniejszy i odrobinę szybszy, ale mądrzejszy niekoniecznie oznacza lepszy.
Oto kolejne pytanie: która opcja jest bardziej zrównoważona w przyszłości?Tak jak w przypadku [jeśli jutro uderzył cię autobus w drodze do pracy] (https://en.wikipedia.org/wiki/Bus_factor), czy ktoś inny mógłby wesprzeć opcję B?I czy opcja B ograniczy / zmieni sposób podejścia do problemów na drodze?
Nie powinieneś pozwalać, aby kod był do bani tylko po to, aby pokryć scenariusz „uderzenie autobusem”.Dopóki jest to uczciwy standardowy wzór, który wymaga tylko kilku zmian (i może trochę wiedzy), warto się temu przyjrzeć.Gdybyśmy wszyscy napisali najłatwiejszy do odczytania i utrzymania kod, cały nasz kod byłby do niczego i nigdy byśmy nie byli lepsi (wystarczy pomyśleć o zespole, który nadal używa .Net 2.0 bez LINQ, ponieważ metody rozszerzające i zapytania w kodzie są „przerażające”.)
Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/63464/discussion-on-question-by-lordfarquaad-is-it-ever-worth-asking-a-question-if-ty).
„Sztuczka”, która polega na kilku sposobach konfiguracji systemu, ma szczegółowy opis: „Kruchy”.Rzecz nie w stworzeniu czegoś, co działa.Sztuczka polega na stworzeniu czegoś, co nie przestaje działać.
Czternaście odpowiedzi:
#1
+100
Neo
2017-08-04 20:16:49 UTC
view on stackexchange narkive permalink

Czy warto pytać o B, mimo że wiem, że mój szef powie „nie”?

Powiedziałbym, że tak, warto, bo jeśli nic innego nie jesteś budowanie reputacji w organizacji. Ćwiczysz również swoje umiejętności miękkie, co przyniesie Ci dużą korzyść w przyszłości.

I wreszcie, kto wie na pewno, czy odpowiedź będzie NIE , dopóki nie zapytasz . Jeśli nie poprosisz, nigdy nie dostaniesz.

Aktualizacja na podstawie komentarzy :

Są całe książki o tym, jak prosić o to, czego chcesz. Powiedziałbym, że powinieneś zastosować podejście oparte na faktach , aby uzasadnić to, o co prosisz. W rzeczywistości możesz zastosować to podejście do praktycznie wszystkich swoich profesjonalnych żądań.

Niektóre spostrzeżenia oparte na moim doświadczeniu obejmują:

  1. Zrozumienie swojego szefa (lub osoby, od której czegoś chcesz) oraz jego potrzeb i ograniczeń.
  2. Upewnij się, że potrafisz wykazać, dlaczego to, o co prosisz, jest dobre.
  3. Uwzględnij wszelkie dane branżowe lub pomocnicze, aby utworzyć kopię zapasową wniosku.
Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/63463/discussion-on-answer-by-mister-positive-is-it-ever-worth-asking-a-question-Jeśli ty).
#2
+37
Bernhard Barker
2017-08-04 20:35:59 UTC
view on stackexchange narkive permalink

Warto omówić swój sposób rozumowania ze swoim szefem:

  • Powiedz, że możesz wymyślić 2 sposoby rozwiązania tego problemu.
  • Wyjaśnij kompromisy każdego jeden.
  • Powiedz mu, z którym planujesz się wybrać.
  • Zapytaj, czy to ma sens, albo się zgadza.

To pokazuje, że:

  1. Masz wiedzę techniczną, aby wymyślić A i B.
  2. Rozumiesz kompromisy (w tym stronę finansową), aby samemu podjąć najlepszą decyzję.

NIE pytaj, czy powinieneś zrobić B, czy też powinieneś zrobić A lub B, ponieważ pokaże to punkt (1) powyżej, ale może wysłać przeciwny komunikat dotyczący punktu (2). Nawet jeśli zapytasz, do którego wybrać, przedstawiając zalety i wady każdego z nich (w przeciwieństwie do pytania, czy zgadza się z tym, który planujesz wybrać), może to nadal pokazać, że tak naprawdę nie jesteś w stanie samodzielnie podjąć takiej decyzji .


O ile nie przesadzisz, uzyskanie drugiej opinii lub zatwierdzenia na temat tego, co planujesz zrobić, nie powinno być zbyt krzywdzące i ogólnie byłoby to postrzegane jako siła (ponieważ nikt nie chce luźnej armaty, która zrobi wszystko, co uzna za najlepsze, bez konsultacji z nikim innym).

Prawie to, co bym powiedział.Przedstaw opcje i ich kompromisy.Może się okazać, że Twój Szef dostrzega przewagę w czymś, o czym Ty (jako nowy programista) nawet nie zdawałeś sobie sprawy.
„Nie jesteś w stanie samodzielnie podjąć takiej decyzji” - cóż, osoba pytająca nie jest * upoważniona * do podjęcia tej decyzji.Albo raczej jest upoważniony do decydowania o A, ale nie jest upoważniony do decydowania o B. Uzyskanie B wymaga delegowania w górę!
@SteveJessop Jasne, ale nawet podczas delegowania w górę chcesz pokazać, że masz wiedzę, aby samodzielnie podjąć decyzję (nawet jeśli nie masz na to pozwolenia), aby Twój szef czuł się bardziej komfortowo, dając Ci większą odpowiedzialność w przyszłości.
#3
+12
Denis de Bernardy
2017-08-04 20:22:55 UTC
view on stackexchange narkive permalink

Opierając się na twoim opisie, opcja B może powodować komplikacje w skądinąd stabilnym oprogramowaniu, więc powinieneś spodziewać się niechęci do ryzyka, jeśli ma niewielką wartość.

To powiedziawszy, nie ma nic złego w wspominaniu o tym mimochodem. Podaj kilka korzyści, które widzisz, wady i dlaczego podejrzewasz, że nie warto tego robić.

Z tego, co wiesz, Twój szef i Twoi współpracownicy mogą przewidzieć inne korzyści, pomyśl o potencjalnych skutkach ubocznych z ich perspektywy, i zdecyduj, że tak naprawdę jest lepiej.

#4
+10
Alex
2017-08-04 20:32:09 UTC
view on stackexchange narkive permalink

Ujmę to nieco inaczej. Powiedziałbym coś w stylu: „Mam dwa potencjalne rozwiązania. B ma pewne zalety, ale myślę, że A jest bardziej praktyczne. sposób, w jaki przekazujesz liderowi wszystkie posiadane informacje i dajesz mu znać, jaką decyzję byś podjął. Dobry trop albo się z tobą zgodzi, albo wyjaśni, dlaczego tak się nie dzieje.

Przy okazji, nie ma potrzeby uważać tego za popisywanie się. To, co robisz, to przekazywanie tego, czego się nauczyłeś, i udzielanie rekomendacji. Zakładając, że to nie jest test, czyli lider jeszcze się nie zdecydował, właśnie tego powinni szukać w juniorach.

#5
+7
RDFozz
2017-08-05 00:40:35 UTC
view on stackexchange narkive permalink

Jest w tym ważny czynnik, którego nie sądzę, aby jakakolwiek z dotychczasowych odpowiedzi dotyczyła; jesteś nowy w firmie.

Generalnie byłbym skłonny powiedzieć, że (zakładając brak różnicy w wydajności między tymi dwiema opcjami) opcja jest „sprytna” i wykorzystuje sposób, w jaki system jest skonfigurowany, prawdopodobnie nie jest najlepszym rozwiązaniem, po prostu dlatego, że jest sprytny (a zatem prawdopodobnie nie jest czymś, co następny facet, który przyjrzy się rzeczom, od razu intuicyjnie zrozumie) i ponieważ wykorzystuje to, jak jest skonfigurowany system (co oznacza, że ​​jeśli my zdecydujemy się zmienić sposób konfiguracji systemu za kilka miesięcy, możemy mieć małą bombę zegarową, jako część rzeczy, na które nie spodziewalibyśmy się wpływu, ale która przestaje działać, gdy system zostanie zaktualizowany).

Ale - jesteś nowy . Nie wiesz , czy istnieją powody, dla których system jest skonfigurowany tak, jak jest. Niekoniecznie wiesz, czy firma rozważała znaczące zmiany i czy Twoje pomysły byłyby sprzeczne z tym, czy też się z tym zgadzają.

Więc to nie jest tylko okazja dla Ciebie pokazać szefowi, że chodzisz nieszablonowo - to także okazja, aby poznać więcej historii.

Znajomość historii projektu może pomóc Ci zrozumieć, dlaczego podjęto pewne decyzje, dlaczego ludzie mogą być niechętni w pewnych kierunkach lub zmianach i może dać wyobrażenie o tym, dokąd może zmierzać w przyszłości. Może to być niezwykle przydatne. Byłem w sytuacjach, w których zwykła znajomość historii systemu była w stanie zapobiec potencjalnym katastrofalnym zmianom.

Podchodząc do tego nie tylko „moglibyśmy zrobić to na dwa sposoby, i myślę, że ta droga jest najlepsza ”, ale„ Czy w ten czy inny sposób lepiej / gorzej pasuje do nadchodzących planów / pomysłów? ” pomaga w zmniejszeniu tego, jak mądry jesteś i jak świetnie pasujesz, a więcej na temat rozwijania głębszego zrozumienia systemu.

Ostatecznie prawdziwa rozmowa może nie toczyć się z szefem, ale oczywiście z innymi członkami zespołu. Od Ciebie zależy, czy warto najpierw porozmawiać z nim, czy z szefem. Jeśli ktoś działa jako mentor, może to być osoba, do której należy się zwrócić.

#6
+2
Anne Daunted GoFundMonica
2017-08-05 18:31:25 UTC
view on stackexchange narkive permalink

Proponuję inne rozwiązanie:

Nie pytaj. Ale ... wspomnij o tym mimochodem

Mówisz, że Twoim zadaniem było znalezienie rozwiązania i jest to opcja A. Po poinformowaniu przełożonego o opcji A, możesz wtedy wspomnieć o Opcji B, np.

„Zauważyłem, że jeśli nastąpiłaby zmiana X w systemie, rozwiązanie takie jak Opcja B mogłoby działać i przyniosłoby następujące korzyści ...”

Nadal pokazałbyś, że wymyśliłeś kreatywne i sprytne rozwiązanie. Jeśli twój przełożony uważa, że ​​warto spróbować, może ci o tym powiedzieć (lub przynajmniej pomyśleć o tym). Jednak nie musi nawet odpowiadać, gdyby się nad tym nie zastanawiał (więc żądasz od niego mniej, niż gdybyś zadał mu pytanie). Więc osiągasz to samo, ale przy mniejszym ryzyku uzyskania odpowiedzi „Nie”.

To jedyna odpowiedź, jaką widzę, która faktycznie w pełni odpowiada na pierwotne pytanie - wszystkie inne wydają się działać przy założeniu, że @LordFarquaad rzeczywiście chce zaimplementować „B”.Nie sądzę, że to prawda - wygląda na to, że poprawnie zidentyfikowali A jako najbardziej pragmatyczny wybór, ale chcą również uzyskać wszelkie korzyści, jakie mogą uzyskać, biorąc pod uwagę B w ramach swojej analizy.Zrobiłbym coś więcej niż tylko „wspomnieć o tym mimochodem”, ale poza tym jest to właściwe podejście.
#7
+1
Streltsov
2017-08-04 20:32:09 UTC
view on stackexchange narkive permalink

Po pierwsze, nigdy nie można być całkowicie pewnym, co ludzie powiedzą lub pomyślą. Może twój szef uzna, że ​​pomysł B to świetny pomysł. Może dzięki swojej bardziej zaawansowanej wiedzy o twoich systemach odkryje, że korzyści / wady metody B są większe niż się spodziewasz.
A może nie wybierze zamiast tego A, ale przedstawienie innych opcji nie zaszkodzi Twoja reputacja, wręcz przeciwnie.

Pokazuje, że przemyślałeś problem, a z tego, co mówisz, pokazuje, że przyswoiłeś sobie, jak sprawy mają się również w twoim nowym miejscu. W związku z tym pokazuje niektóre z twoich cech szefowi, który tak naprawdę nie wie, co jesteś w stanie zrobić.
Nie popisuje się, o ile nie podkreślasz zbytnio, jak „sprytny pomysł” może się to zdarzyć, gdy przedstawisz to swojemu szefowi.

Radziłbym przedstawić obie opcje, zachowując fakt.
„Oto rozwiązania, które wymyśliłem, aby rozwiązać problem: opcja A i opcja B. Myślę, że B przyspieszyłoby sprawę, ale jej wdrożenie wymagałoby od nas zmiany X ”.
Decyzję o tym, czy zmiany konieczne dla opcji B są tego warte, pozostaw swojemu szefowi.

#8
+1
Michael
2017-08-04 20:32:43 UTC
view on stackexchange narkive permalink

Dla mnie osobiście zawsze pytam, ponieważ najgorsze, co może się zdarzyć, to mój szef mówiący „Nie”. Większość moich najlepszych projektów, które uważałem za nieosiągalne (ze względu na status, doświadczenie, politykę itp.), Stało się rzeczywistością, ponieważ o to poprosiłem.

#9
+1
Karl Bielefeldt
2017-08-04 23:37:57 UTC
view on stackexchange narkive permalink

Jeśli masz pewność, że pomysł zostanie odrzucony, musisz zadać sobie pytanie, dlaczego. Menedżerowie generalnie nie są przyzwyczajeni do odrzucania pomysłów, które są uczciwie korzystne dla firmy. Oceń przyczyny i wyeliminuj je lub złagodź, jeśli możesz, zanim udasz się do szefa. Często najlepszym podejściem jest powiedzenie czegoś takiego:

Rozważałem zrobienie tego w ten sposób, ale myślę, że z tych powodów nie jest to najlepszy sposób działania ...

Czasami może to wywołać u współpracowników pomysły na sposoby, aby to zadziałało lub alternatywne / kompromisowe rozwiązania, które nie przyszły ci do głowy. Czasami wszystko, co możesz zrobić, to zaplanować powolną migrację ze starszego rozwiązania. Osoby pracujące razem mogą wymyślić lepsze rozwiązania niż osobno.

#10
  0
HLGEM
2017-08-04 20:45:00 UTC
view on stackexchange narkive permalink

Z politycznego punktu widzenia często dobrze jest pokazać szefowi swój proces myślenia, nad czym się zastanawiałeś i jak dokonywałeś wyborów. Więc tak, idź na to, nawet jeśli myślisz, że nie spodoba mu się jedna lub więcej opcji. Jeśli masz zamiar to zrobić, będziesz wyglądać lepiej dla swojego szefa, jeśli będziesz przekonujący. Przedstaw je więc w sposób zrozumiały dla kierownictwa.

Kiedy mam dwie lub więcej możliwych opcji, opisuję to jako formalną analizę decyzji i przedstawiam w ten sposób. W ten sposób osoba może zobaczyć zalety i wady każdej opcji, a co ważniejsze, zobaczy, że przemyślałeś możliwe rozwiązania.

Generalnie polecam opcję z najlepszym wynikiem liczbowym, ale jeśli nie zgadza się z moją punktacją, możemy dostosować ją na bieżąco i zobaczyć, co się stanie.

Jak to zrobić kwestią jest analiza decyzji. W arkuszu kalkulacyjnym ustawiasz czynniki decyzyjne. To są podstawy do podjęcia decyzji, która opcja jest najlepsza. Każdy czynnik otrzymuje współczynnik ważenia, który wskazuje, jak stosunkowo ważny jest ten czynnik. Następnie każda opcja jest umieszczana na górze. Każda opcja jest oceniana liczbowo według każdego czynnika rankingowego. Następnie pomnóż współczynnik ważenia i wynik liczbowy, aby uzyskać sumę dla tego współczynnika dla każdej opcji. Następnie zsumuj je, aby zobaczyć, który z nich jest najlepszy.

Przykład pokazany poniżej: enter image description here

W przypadku problemu na małą skalę, takiego jak ten, który opisuje @LordFarquad, sugerowałbym, że tego typu analiza wymaga zbyt wiele czasu i wysiłku.Gdybym zlecił młodszemu pracownikowi zadanie „Czy możesz naprawić 'A'?”a oni wrócili z dynamicznym, dostrajalnym arkuszem kalkulacyjnym, nie byłbym pod wrażeniem.
@Beejamin: Podejrzewałbym mocno, że junior również wprowadził fałszywą precyzję.Przykładowy arkusz kalkulacyjny powyżej może być dobrze przemyślaną wagą różnych problemów lub może być post-hoc racjonalizacją oceny: „bezpieczeństwo danych jest niezbędne w tym projekcie, a B i C są niepewne”.Jeden test brzmi: gdybyśmy mogli ulepszyć Plan C, aby uzasadnić przyznanie mu 2/5 za bezpieczeństwo danych (dopasowanie B), czy to wystarczyłoby, aby zastosować C zamiast A?Ktoś, kto nie może odpowiedzieć „tak” na to pytanie, nie ma żadnego interesu w przedstawianiu tej konkretnej macierzy :-)
... i zamiast tego powinien przedstawić matrycę z szybkością i rzetelnością ocenianą na niewielki ułamek oceny bezpieczeństwa, aby zapewnić, że działają one jedynie jako rozstrzygające rozstrzygnięcia dla równie bezpiecznych propozycji.Ale łatwo jest stracić dyscyplinę w tej kwestii i tylko oceniać bezpieczeństwo danych (lub wszystko to, co jest najważniejsze dla twojego prawdziwego projektu) „wystarczająco”, aby dać „poprawną” odpowiedź, wiedząc, jakie propozycje są przed nami.Aby proces był niezawodny, wszystko musi być odpowiednio wyważone, aby poradzić sobie z każdą propozycją, która może zostać dodana później.
#11
  0
MaurolepisDreki
2017-08-06 00:20:58 UTC
view on stackexchange narkive permalink

Uważam, że potrzebujesz trzeciej opcji. Jak zdajesz się rozumieć, firmy nie lubią wprowadzać zmian poza bezpośrednim projektem, a Twój szef może nawet nie mieć nic do powiedzenia w tej sprawie, niezależnie od tego, czy jest to najlepszy sposób zrobienia czegoś. Ma to związek z logiką biznesu (polityka, finanse itp.), W przypadku którego nie jestem w stanie doradzać bezpośrednio. Dlatego, jeśli opcja A nie jest tak dobra i opcja B zostanie odrzucona ze względów logiki biznesowej, wówczas powinieneś potrzebować opcji C, która jest lepsza niż opcja A i bardziej biznesowa niż opcja B. Bez opcji C chciałbym przedstaw najpierw opcję B, ponieważ wydawałoby się to lepszym rozwiązaniem, gdyby zostało zatwierdzone i można było dokonać zmian zewnętrznych. Opcja A byłaby wówczas rezerwą na wypadek, gdyby wszystko inne zawiodło. Przedstawienie opcji A jako pierwszej lub obok opcji B spowoduje, że opcje inne niż A nie będą brane pod uwagę, ponieważ opcja A wydaje się być najłatwiejszą ścieżką. Takie było moje doświadczenie w podobnych sytuacjach.

Jak wskazałem w poprzedniej odpowiedzi, pamiętaj, że „mądry” niekoniecznie oznacza „lepszy”. Korzyści, takie jak skrócony czas przetwarzania, mniejsze zużycie pamięci, kod, który można konserwować, czas wdrożenia, łatwość konserwacji w przyszłości, utrzymanie się w ramach budżetu i zmniejszenie liczby roboczogodzin to rzeczy, które sprawiają, że rozwiązanie jest „lepsze”. Zrób to szybko, dobrze, a zdobędziesz swój prestiż.

Scotty's Secret to being a Miracle Worker

#12
  0
Damon
2017-08-07 17:28:03 UTC
view on stackexchange narkive permalink

Prawdopodobnie nie jest błędem wspomnienie, że znasz bardziej sprytne podejście, ale zdecydowałeś się go nie stosować. Nie pytałbym jednak z dwóch powodów.

Po pierwsze, będąc raczej nowym, możesz być zmuszony zadawać pytania przy innych okazjach. Nie jesteś jednak facetem, który zawsze pyta o najbardziej błahe rzeczy, tj. Facetem, który jest całkowicie niezdolny do zrobienia jednej rzeczy samodzielnie. Jako programista potrafisz rozwiązywać problemy, idź je rozwiązywać.

Po drugie, „sprytny” jest zwykle mniej ważny niż wykonanie zadania i ogólność lub przenośność. W rzeczywistości większość rozwiązań biznesowych wcale nie jest sprytna, są fatalne. Jednak dopóki działają wystarczająco dobrze, aby nie było żadnych reklamacji, to nie ma znaczenia.

Wspomniałeś, że A będzie „po prostu działać”, podczas gdy B będzie działać tylko dla twojego konkretnego systemu, a mimo to wymagałoby to niewielkiej modyfikacji. To jest coś, co prawie na pewno wywoła negatywną reakcję. Przy odrobinie szczęścia dostaniesz cytat z Tony'ego Hoare'a. Jeśli masz mniej szczęścia, dostaniesz coś mniej uprzejmego.

Rozwiązanie, które działa tylko na jednym systemie, jest zwykle nie do przyjęcia. Optymalizacja tam, gdzie nie ma pilnej potrzeby, również zwykle nie jest możliwa.

#13
  0
JFA
2017-08-10 02:42:05 UTC
view on stackexchange narkive permalink

Jest wiele dobrych odpowiedzi, ale pytanie tytułowe brzmiało: „Czy warto zadawać pytanie, jeśli wiesz, że odpowiedź brzmi„ nie ”? Odpowiedź na to brzmi: „Tak”. Jest wiele powodów, dla których warto zadać pytanie, nawet jeśli uważasz, że odpowiedź brzmi „nie”. Może to być cel dokumentacyjny (CYA) lub może to być po to, aby wszyscy wiedzieli, jakie zasady dotyczą określonego problemu.

Bardziej szczegółowe pytanie: czytelny kod> sprytny kod. Ale jeśli masz lepsze rozwiązanie niż to proponowane, to powinieneś je wdrożyć lub przynajmniej przedstawić swoją rację. Steve Jobs napisał kiedyś dowód, że skrócenie czasu uruchamiania z 30 sekund w rzeczywistości uratowałoby życie. Co najważniejsze, powinieneś się uczyć, a Twoja firma chce, abyś się uczył, abyś pozostał użyteczny, niezależnie od tego, czy o tym wie, czy nie. Znalezienie najlepszego rozwiązania, które wiesz, jak ważne jest dla Twojego rozwoju.

Ponadto, przedstawiając swoją sprawę, nie mów „to nie pomoże, ale ...” sposoby, w jakie to pomoże. Oszczędność godzin pracy firmy w ciągu roku może zaoszczędzić dziesiątki tysięcy dolarów, w zależności od tego, na kogo wpłynie kod.

@JoeStrazzere Wow, jesteś wszędzie na tej stronie.Co tak naprawdę się wydarzyło, brzmiało: „Gdyby to mogło uratować ludzkie życie, czy znalazłbyś sposób na skrócenie o dziesięć sekund czasu rozruchu?”- zapytał [Jobs]. Jobs podszedł do tablicy i pokazał, że gdyby było pięć milionów ludzi korzystających z Maca, a włączanie go codziennie zajmowało dziesięć sekund, to w sumie daje to około 300 milionów godzin rocznie, a ludziesave, co było odpowiednikiem co najmniej 100 żyć w ciągu roku. ”
„[Inżynier Larry Kenyon] był pod odpowiednim wrażeniem, a kilka tygodni później wrócił i uruchomił się dwadzieścia osiem sekund szybciej” - wspomina [Bill] Atkinson.https://www.fastcompany.com/1790791/steve-jobs-biographer-apple-founder-was-driven-simplicity-mystical-thinking-and-occasional-l Więc tak, udowodnił, że skrócenie czasu rozruchu uratuje życie.
#14
-1
TOOGAM
2017-08-06 11:16:26 UTC
view on stackexchange narkive permalink

Czy umiesz zrobić jedno i drugie?

bool bBeClever = false;

if (bBeClever)
imponującyWay ();
else
boringWay ();

Jeszcze lepiej, zamiast tworzyć całkowicie różne funkcje imponująceWay i boringWay (), czy możesz utworzyć jedną funkcję, która może to zrobić, w oparciu o wartość logiczną (najlepiej zmienianą w czasie wykonywania za pomocą przekazanego parametru lub innego zmienna)?

To moja rada, która wydaje się raczej dostosowana do tego konkretnego pytania (o programowaniu komputerowym). Dalej, oto kilka myśli, które z większym prawdopodobieństwem będą przydatne w innych scenariuszach (w innych biznesach).

Jeśli podejścia są tak fundamentalnie różne, że naprawdę musisz zrobić tylko jedno lub drugie, prawdopodobnie dlatego, że nie masz wystarczająco dużo czasu na programowanie, aby zrobić jedno i drugie, po prostu zrób to, co jest najmądrzejsze (to znaczy: najłatwiejsze do utrzymania w możliwie zmieniających się okolicznościach, najprawdopodobniej zostanie zatwierdzone przez przełożonych itp.), ale udokumentuj drugą opcję. Nawet jeśli nie otrzymasz uznania za wykonanie drugiej opcji, Twój spryt może przetrwać każdy, kto czyta komentarze do kodu i / lub dokumentację. Sporządzenie takiej notatki może również zapewnić wartość, pozwalając ludziom pamiętać, że istnieje ta dostępna metoda optymalizacji, którą można zastosować, jeśli zmieniają się określone potrzeby / priorytety. Mam nadzieję, że twój szef powinien docenić taką wartość dodaną.

Wiem, że kiedy otrzymywałem wynagrodzenie za programowanie, mój przełożony bardzo doceniał wiele pomysłów, które mi przekazałem, nawet te, które nie zostały wdrożone natychmiast.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...