Ponad myślenie o rozwoju

88

Od półtora roku pracuję jako programista aplikacji (nie wiem długo) i właśnie dostałem swój pierwszy duży projekt.

Nie trzeba dodawać, że nie poszło to bardzo gładko, dlatego szukałem porady od starszego programisty zaangażowanego w projekt, jak podejść do tego.

Powiedział, że drastycznie przestałem myśleć o tym zadaniu, i ponieważ nigdy nie zajmowałem się projektem na taką skalę, zanim spędziłem zbyt wiele czasu nad myśleniem o wzorach projektowych. W swoich mądrych słowach powiedział mi: „Kurwa, buduj przyszłość”.

Czy programiści zazwyczaj podążają za takim projektem? Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

Edycja: W świetle debaty, którą to wywołało, chciałbym wspomnieć, że ta sytuacja jest dość ekstremalna: mamy bardzo napięte terminy z przyczyn niezależnych od nas (tj. Rynek, na który dążymy, straci zainteresowanie, jeśli im coś pokazać), a jego rada okazała się bardzo skuteczna w przypadku tego konkretnego zadania.

sf13579
źródło
5
ten wydaje się bardziej związany z kodowaniem niż projektowaniem
Balog Pal
22
I + 1-ed tylko dla „F * ck przyszłości, buduj na teraz”. Jeśli ma ochotę poprzeć to oświadczenie, chętnie mu to wynagrodzę, ilekroć dodam to do dziennika zmian po tym, jak zeskrobię coś, co głupio nadużyłem (co dzieje się o wiele bardziej niż chciałbym).
haylem
13
Przypomina mi starego współpracownika, który zawsze „pozłacał” swoje aplikacje zbyt dużą ilością funkcji, przedawkowywał projekty i rzeczy, których wcale nie wymagał po prostu „popisywać się” lub „przygotowywać się na przyszłość, która nigdy nie nadejdzie” . Bardzo interesujące pytanie :)
Jean-François Côté
8
@Jean: Jedynymi projektami, w których dzieje się „przyszłość, która nigdy nie nadejdzie”, są programy, które są błędami (nawet jeśli projekt został uznany za sukces). Jeśli twój program się powiedzie, oznacza to, że jest używany. Jeśli jest używany, użytkownicy będą chcieli więcej funkcji. Jeśli zastosujesz się do filozofii „buduj na teraz”, uzyskasz obecny stan większości oprogramowania dzisiaj. Całkowite śmieci, trudne do zmiany. Jedynym powodem, dla którego programiści mogą uciec, jest to, że jest tak rozpowszechniony. Programiści, którzy są wykwalifikowani, będą budować systemy szybciej, robiąc to poprawnie na początku i nie skończywszy na śmieciach.
Dunk
55
Takie pytania są jak test Rorschacha. OP nie dostarcza wystarczających informacji, aby wiedzieć, czy jest on w rzeczywistości nadmiernym projektantem, czy jego mentorem jest projektantem zbyt niskim. W przypadku braku wystarczających informacji wszyscy widzą, czego chcą.
PeterAllenWebb

Odpowiedzi:

112

Kapitan Oczywisty na ratunek!

Będę tu Kapitanem Oczywistym i powiem, że można znaleźć jakiś środek.

Chcesz budować na przyszłość i unikać uzależnienia się od wyboru technologicznego lub złego projektu. Ale nie chcesz spędzać 3 miesięcy na projektowaniu czegoś, co powinno być proste, lub dodawaniu punktów rozszerzeń dla szybkiej i brudnej aplikacji, która będzie miała 2 lata użytkowania i prawdopodobnie nie będzie mieć projektów następczych.

Trudno jest znaleźć to rozróżnienie, ponieważ nie zawsze można przewidzieć sukces produktu i jeśli trzeba będzie go później rozszerzyć.

Buduj na teraz, jeśli ...

  • projekt zostanie złomowany
  • projekt ma krótką żywotność
  • projekt nie powinien mieć rozszerzeń
  • projekt nie ma wartości ryzyka (głównie pod względem wizerunku)

Ogólnie rzecz biorąc, na razie należy opracować własne projekty lub coś zbudowanego dla klienta. Pamiętaj, aby mieć proste wymagania i odnosić się do nich w razie potrzeby, aby wiedzieć, co jest potrzebne, a co nie. Nie chcę spędzać zbyt wiele czasu na czymś, co „miło mieć”. Ale nie koduj też jak świnia.

Pozostaw problem ogólny na później, jeśli będzie to kiedykolwiek konieczne i warte wysiłku:

XKCD: Ogólny problem

Buduj na przyszłość, jeśli ...

  • projekt będzie publiczny
  • projekt jest komponentem do ponownego wykorzystania
  • projekt stanowi odskocznię dla innych projektów
  • projekt będzie zawierał kolejne projekty lub wydania usług z ulepszeniami

Jeśli budujesz coś publicznego lub zostanie to ponownie wykorzystane w innych projektach, masz znacznie większe prawdopodobieństwo, że zły projekt wróci, by cię prześladować, więc powinieneś zwrócić na to większą uwagę. Ale nie zawsze jest to gwarantowane.

Wytyczne

Powiedziałbym, że przestrzegaj następujących zasad najlepiej, jak potrafisz, i powinieneś postawić się w sytuacji projektowania wydajnych, elastycznych produktów:

  • wiedzieć, że YAGNI ,
  • KISS ,
  • ilekroć masz ochotę podrapać się na świąd i pomyśleć o dodatku, zapisz go. Spójrz wstecz na wymagania swojego projektu i zadaj sobie pytanie, czy dodatki są priorytetami, czy nie. Zapytaj, czy dodają podstawową wartość biznesową, czy nie.

Wiem, że osobiście mam tendencję do zbytniego zastanawiania się i nadmiernej inżynierii. To naprawdę pomaga spisywać pomysły i bardzo często przemyśleć, czy potrzebuję dodatkowych funkcji. Często odpowiedź brzmi „nie” lub „byłoby później fajnie”. Te ostatnie pomysły są niebezpieczne, ponieważ pozostają z tyłu mojej głowy i muszę zmusić się, żeby nie planować ich.

Najlepszym sposobem na kodowanie bez nadmiernej inżynierii i bez blokowania się na później jest skupienie się na dobrym minimalnym projekcie. Ładnie rozkładaj elementy na części, które możesz później rozszerzyć, ale nie zastanawiając się już, w jaki sposób można je później rozszerzyć. Nie możesz przewidzieć przyszłości.

Po prostu buduj proste rzeczy.

Dylemat

Nadmierna inżynieria

Czy programiści zazwyczaj podążają za takim projektem?

O tak. To znany dylemat i pokazuje tylko, że zależy Ci na produkcie. Jeśli nie, to bardziej niepokojące. Nie ma zgody co do tego, czy zawsze mniej znaczy naprawdę więcej, a jeśli gorzej jest zawsze naprawdę lepiej . Możesz być facetem typu MIT lub New Jersey . Nie ma tutaj łatwej odpowiedzi.

Prototypowanie / Quick-n-Dirty / Less to więcej

Czy to typowy trend, aby jak najszybciej znieść praktyczny przykład?

Jest to powszechna praktyka, ale nie w ten sposób podchodzi się do większości projektów. Mimo to prototypowanie jest moim zdaniem dobrym trendem, ale ze znacznym minusem. Kuszące może być promowanie szybkich i brudnych prototypów na rzeczywistych produktach lub wykorzystanie ich jako podstawy dla rzeczywistych produktów pod presją zarządzania lub ograniczeniami czasowymi. Wtedy prototypowanie może cię prześladować.

Dilbert o wysyłce prototypów bezpośrednio do produkcji

Prototypowanie ma oczywiste zalety , ale także duży potencjał niewłaściwego użytkowania i nadużyć (w rezultacie wiele dokładnie odwrotności wcześniej wymienionych zalet).

Kiedy używać prototypowania?

Istnieją wskazówki na temat najlepszych rodzajów projektów do zastosowania prototypowania :

[...] prototypowanie jest najbardziej korzystne w systemach, które będą miały wiele interakcji z użytkownikami.

[...] prototypowanie jest bardzo skuteczne w analizie i projektowaniu systemów on-line, szczególnie w przetwarzaniu transakcji, gdzie użycie dialogów ekranowych jest znacznie bardziej widoczne. Im większa interakcja między komputerem a użytkownikiem, tym większa korzyść [...]

„Jednym z najbardziej produktywnych zastosowań szybkiego prototypowania do tej pory było narzędzie do iteracyjnej inżynierii wymagań użytkownika i projektowania interfejsu człowiek-komputer”.

Z drugiej strony:

Systemy z niewielką interakcją użytkownika, takie jak przetwarzanie wsadowe lub systemy, które w większości wykonują obliczenia, niewiele korzystają z prototypowania. Czasami kodowanie potrzebne do wykonywania funkcji systemu może być zbyt intensywne, a potencjalne korzyści, jakie może zapewnić prototypowanie, są zbyt małe.

A jeśli masz w pobliżu zielonego potwora, pamiętaj o zachowaniu prototypu w ramach budżetu ...

Dilbert o przedłużeniu okresów prototypowania

Haylem
źródło
1
Nie mogę wystarczająco podkreślić, jak ważne są twoje uwagi na temat prototypowania. Nie sądzę, żeby tak naprawdę chodziło o to pytanie (głównie o to, kiedy można zatrzymać i zaprojektować, zamiast budować tak, jak rozumiem), ale prototypowanie jest zdecydowanie istotną częścią tego procesu. Dobra robota!
Benjamin Gruenbaum
3
Jestem dość zdziwiony, dlaczego otrzymałem tutaj opinię. Proszę, bądź na tyle uprzejmy, aby przekazać informacje na ten temat, abym mógł zobaczyć błędy na moich drogach, sensei.
haylem,
7
Kiedyś współpracowałem z inżynierem mechanikiem, który tak to ujął: Czy chcesz, aby Twój produkt był niedopracowany czy nadmiernie zaprojektowany? To naprawdę jedyne dwie opcje.
Guy Sirton,
1
@SamtheBrand: dzięki za świetną edycję. Dużo lepiej.
haylem
1
@haylem: czasami myślę, że wprowadzenie pomysłów do śledzenia problemów (jeśli twój projekt jest wystarczająco duży, aby go mieć), pozwala mi je usunąć z tyłu głowy. Świadomość, że są one w jakiś sposób widoczne dla innych, sprawia, że ​​czuję, że nie muszę ciągle odwiedzać ich w mojej głowie (chociaż istnieje tam również działanie równoważące =]).
afuzzyllama,
54

Kiedy zaczynasz programować, wszystko jest dowodem koncepcji, nawet jeśli jest to tylko dla ciebie. Są przypadki, gdy pomysł wymaga czegoś szybkiego i brudnego lub prototypu, ponieważ czas jest kluczowym czynnikiem. Ogromny strach wśród deweloperów polega na tym, że interesariusze myślą, że mała aplikacja jest gotowa do produkcji, lub powinieneś móc dodawać funkcje w tym samym tempie na zawsze. Pracujesz nad dużym projektem i okazuje się, że tak nie jest.

Duże projekty zwykle mają bardziej złożone wymagania, więc istnieje pokusa, aby spróbować wdrożyć złożone projekty. Spędzisz dużo czasu czytając, badając i próbując je wdrożyć. Może to stać się wielkim marnotrawstwem czasu, ale jest to część uczenia się i zdobywania doświadczenia. Wiedza, kiedy użyć określonego projektu, jest trudna i zwykle wiąże się z doświadczeniem. Próbowałem „tego” na „tym” projekcie i to nie działało, ale teraz widzę, że powinno działać na „tutaj”.

Musisz dużo planować i planować, ale nie rób tego wszystkiego naraz. Na pewno nie trzeba tego robić na początku. Wolałbym, żeby ktoś stworzył swój pierwszy tak duży projekt:

  1. Zaprojektuj i omów trochę.
  2. Napisz garść kodu, który coś robi.
  3. Rozpoznaj problemy i kod STOP.
  4. Poważnie podchodź do projektowania i przestań martwić się utratą rozpędu lub kodu-mojo i zignoruj ​​kierownika projektu (wyświadczasz mu przysługę).
  5. Przejmij kontrolę nad projektem. Napraw swoje bałagany. Upewnij się, że wszyscy rozumieją plan. Utrzymaj projekt pod kontrolą.

Czasami trafiasz na jedną z tych funkcji, która naprawdę niepokoi Cię, jak zaimplementować ją w istniejącej bazie kodu. To nie jest czas, aby „po prostu sprawić, by działało”. Miałem szefa, który powiedział: „Czasami musisz złapać stołek zamiast młotka”. Powiedział mi to po tym, jak przyłapał mnie na „myśleniu” przy biurku. W przeciwieństwie do wielu bossów, nie przypuszczał, że wygłupiam się i upewniłem się, że rozumiem, że chce, abym zrobił więcej. Geniusz.

Ostatecznie twój kod jest projektem. Wspierają go dokumenty, diagramy, spotkania, e-mail, dyskusje na tablicy, pytania SO, argumenty, przekleństwa, napady wściekłości i ciche rozmowy przy kawie. Jest taki moment, w którym nie możesz już więcej projektować i ryzykujesz, że poświęcisz więcej czasu na projektowanie z powodu wad, które odkryjesz tylko podczas pisania kodu. Ponadto, im więcej kodu napiszesz, tym większa szansa, że ​​wprowadzisz wadę projektową, z której nie da się kodować. Czas znów na stołek.

JeffO
źródło
1
+1 za doing your bosses a favor, nawet jeśli tak nie uważają
superM
2
+1 Świetny post. To naprawdę dobry menedżer, który zdaje sobie sprawę, że dobry projekt wymaga perkolacji - i to niekoniecznie wymaga użycia klawiatury!
Robbie Dee
Argg, jeśli tylko przeczytam tę odpowiedź, zanim zacznę! Dziękuję i za kogoś, kto dopiero zaczyna w tej branży, uwielbiam te szalone kształty uczenia się!
sf13579,
2
+1 zaYou have to plan and plan a lot, but don't do it all at once.
Rafael Emshoff
2
@Geek: mojo, flow, zone ... lub jakikolwiek geeky / trendy / hipster, który można opisać jako stan wydajności.
haylem,
24

Czy programiści zwykle budują coś, co działa teraz, nie myśląc o przyszłości?

Tak.

Czy powinni to zrobić?

Nie.

Na pierwszy rzut oka wydaje się, że „myślenie o przyszłości” narusza ustalone zasady projektowania, takie jak KISS i YAGNI , które twierdzą, że nie należy wdrażać niczego, co nie jest obecnie wymagane.

Ale tak naprawdę nie jest. Myślenie o przyszłości oznacza projektowanie prostego, rozszerzalnego i zarządzalnego oprogramowania. Jest to szczególnie ważne w przypadku projektów długoterminowych. Z czasem wymagane będą nowe funkcje, a solidna konstrukcja ułatwi dodawanie nowych elementów.

Nawet jeśli nie zamierzasz pracować nad projektem po jego ukończeniu, nadal powinieneś go inteligentnie rozwijać. To twoja praca i powinieneś robić to dobrze, przynajmniej po to, aby nie zapomnieć o tym, jak dobra jest praca.

superM
źródło
3
Chociaż to, co mówisz, ma sens, moje osobiste doświadczenia mówią mi coś innego. Zazwyczaj, gdy deweloperzy przechodzą w tryb @ F *** k ... po prostu wysyłają to @, zwykle pojawia się ładunek skopiowanego wklejonego kodu, który rozlewa się po całym miejscu. Wynik końcowy jest całkowicie niemożliwy do utrzymania. Myślenie naprzód to nie tylko rozszerzenia i modyfikacje, ale także konserwacja.
Newtopian
13

Zwinni programiści mają powiedzenie „Nie potrzebujesz go (YAGNI)”, które zachęca do zaprojektowania tego, czego potrzebujesz teraz, a nie tego, co Twoim zdaniem może być potrzebne w przyszłości. Aby przedłużyć projekt do pracy w przyszłości, zalecaną drogą jest refaktoryzacja.

Ważnym aspektem tego jest zachowanie wymagań dotyczących produktu podczas projektowania i upewnienie się, że nie projektujesz szeregu wymagań, które mogą się zdarzyć w przyszłości.

Jest coś do powiedzenia dla programistów, którzy potrafią myśleć o dwóch lub trzech iteracjach - znają swoich klientów lub domenę tak dobrze, że mogą przewidywać przyszłe potrzeby z dużą dokładnością i budować dla nich, ale jeśli nie jesteś pewien, najlepiej nie spędzać zbyt wiele czasu na rzeczach, których ty lub klienci nie potrzebujesz.

użytkownik93143
źródło
1
Są też inne powody, by myśleć przyszłościowo: że rozwijana funkcjonalność nie pasuje do jednego sprintu. Tak więc albo sztucznie go rozbijasz, albo odmawiasz wdrożenia funkcjonalności, której nie możesz ukończyć w ramach jednego sprintu.
Giorgio
+1 za wzmiankę o refaktoryzacji. Nie mogę uwierzyć, że żadna z dotychczasowych odpowiedzi o tym nie wspomina. YAGNI jest opłacalne tylko po dokonaniu refaktoryzacji.
Ian Goldby
7

Czy programiści zazwyczaj podążają za takim projektem?

Podejrzewam, że twój mentor miał na myśli to, że nie powinieneś budować dodatkowej złożoności, która może nie być wymagana przez ostateczne rozwiązanie.

Zbyt łatwo jest myśleć, że aplikacja powinna to zrobić i to i zostać masowo odsunięta na bok.

Jeśli chodzi o wzorce projektowe, warto pamiętać, że są one środkiem do celu. Jeśli z doświadczenia okaże się, że określony wzór nie pasuje pomimo wcześniejszego przeczucia, może to wskazywać na zapach kodu.

Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

Przed rozpoczęciem projektu warto uzyskać kontrolę nad tym, jakie są kamienie milowe i czy będą chcieli zobaczyć wszystko po trochu (pionowy wycinek), czy tylko szczegółowo każdą część podczas jej opracowywania (wycinek poziomy). W ramach wstępnego projektu uważam, że warto wejść na pokład całej aplikacji, więc nawet jeśli kod nie jest napisany, możesz zrobić widok helikoptera na całość lub głęboko zanurzyć się w danym obszarze.

Robbie Dee
źródło
6

Powiedział, że drastycznie przestałem myśleć o tym zadaniu i że ponieważ nigdy nie miałem do czynienia z takim dużym projektem, spędzałem zbyt dużo czasu nad myśleniem o wzorach projektowych. W swoich mądrych słowach powiedział mi: „Kurwa, buduj przyszłość”.

Myślę, że to trochę kowbojska mentalność innego dewelopera. Współczesna wersja twardego kujona, który po prostu „robi to teraz”. Stało się popularnym tematem wśród startupów i nie dziękuję ludziom na Facebooku za rozpoczęcie frazy „lepiej to zrobić niż zrobić dobrze”.

To pociągające. To zachęcające i oferuje wizje programistów stojących wokół konsoli klaszczących w dłonie, gdy uruchamiają swój duży projekt w świat na czas, z ograniczonym budżetem, a wszystko dlatego, że niczego nie zaprojektowali.

To idealistyczna fantazja, a życie nie działa w ten sposób.

Głupiec wpadnie na projekt myśląc, że może po prostu „zrobić to” i zrobić to. Sukces faworyzuje programistę, który przygotowuje się na niewidzialne wyzwania i traktuje swój zawód jak kunszt.

Każdy starszy programista może krytykować, potępiać i narzekać - a większość tak!

Podczas gdy on / ona mówi ci, że „nadmiernie myślisz” o projekcie. Najpierw gratuluję ci „myślenia”. Zrobiłeś pierwsze kroki, aby być lepszym programistą niż ten drugi facet.

Czy programiści zazwyczaj podążają za takim projektem? Na przykład, jeśli poproszono Cię o wykonanie modelu koncepcyjnego, czy typowym trendem jest po prostu zebranie wykonalnego przykładu tak szybko, jak to możliwe?

To właśnie jest dowód koncepcji. Jest to próba zmiażdżenia czegoś tak szybko, jak to możliwe, aby ludzie mogli zrobić krok do tyłu i spojrzeć na to. Ma to na celu zapobieganie błędom, niewłaściwemu kierowaniu i marnowaniu czasu / pieniędzy.

Istnieje wiele różnych rodzajów dowodów koncepcji. Możesz zbudować coś, co zostanie wyrzucone do śmieci po zakończeniu, lub możesz zbudować coś, co stanowi punkt wyjścia dla projektu. Wszystko zależy od tego, czego potrzebujesz i od tego, jak bliska jest koncepcja produktu końcowego.

To także okazja do zademonstrowania swoich pomysłów. Były czasy, kiedy przedstawiałem prototyp, który wzniósł rzeczy na poziom, którego się nie spodziewali.

Reactgular
źródło
1
+1 za wzmiankę o pladze pseudo-mentorów w Internecie
FolksLord,
5

Projekt jest zwykle otwarty, więc zbyt łatwo jest zastosować go za dużo lub za mało. Prawidłową kwotę poznasz dopiero po zakończeniu lub odrzuceniu projektu. A nawet nie wtedy.

Nie ma ogólnej recepty na sukces, ale możesz nauczyć się rozpoznawać skrajności. Kompletny projekt wszystkiego z przodu prawie nigdy nie wychodzi poza banalne rzeczy. Można pozostawić komponenty do udoskonalenia i mieć wrażenie, że da się to zrobić, lub istnieje sposób wczesnego wykrycia problemów.

Możesz sprawdzić, jak działa przyrostowy rozwój, jeśli nie jesteś zaznajomiony. Skuteczne metody zwykle są iteracyjne na jednym lub kilku poziomach, szukają ścisłej informacji zwrotnej i rosną na jakimś szkielecie.

Balog Pal
źródło
3

Jest kilka dobrych powodów, aby słuchać rad, aby przestać planować i zacząć kodować;

  1. Po zaledwie 18 miesiącach pracy jako programista jest mało prawdopodobne, że będziesz w stanie przewidzieć przyszłość na tyle dobrze, aby ją zaplanować, bez względu na GPA. Jest to coś, co jest niezwykle trudne do zrozumienia dla jasnych, ale niedoświadczonych programistów, ponieważ chodzi o to, aby nie wiedzieć tego, czego nie wiesz. Stare ręce mogły rozpoznać tę słabość w twojej wizji i mądrze zachęcały cię, abyś po prostu w nią wpadł i zrobił wszystko, co mógł.

  2. Młodzi programiści mogą mieć obsesję na punkcie doskonalenia projektu, zanim zaczną kodować. Mogą obejmować strach przed napisaniem kodu (lęk przed wydajnością) lub mogą mieć blok kodera (jak blok pisarzy). Są zbieżne w projekcie, ponieważ nie ma wymaganej wydajności pracy. Młody twórca prawdopodobnie zareaguje gniewnie na sugestię, że „boją się” czegokolwiek. Może pod koniec projektu zdadzą sobie sprawę, że tak było. Rada, aby nie martwić się i uzyskać kodowanie, jest jedynym znanym lekarstwem na blok kodera. Stara ręka może mądrze zaoferować tę radę.

  3. W obliczu ostrych ograniczeń harmonogramu szanse na ukończenie projektu są w ogóle ograniczone. Planuj zbyt długo i bez względu na to, jak dobry jest ten plan, nie możesz go wykonać na czas i nigdy nie wejdziesz na rynek. Zacznij hakować od samego początku, a być może będziesz miał szczęście i będziesz miał rację za pierwszym razem. Dostarczasz produkt w cudowny sposób. A może nie masz tyle szczęścia i dostarczysz na wpół upieczony kawałek żużla, ale dostanie się na rynek na czas i nauczysz się czegoś. A może zawiedziesz. Ale „może ci się nie uda” to wciąż lepsze szanse niż „nigdy nie wprowadzać na rynek”, ponieważ planowałeś zbyt długo. Najważniejsze jest to, że twoje szanse są od samego początku ograniczone, więc nic nie tracisz przez hakowanie. Twój menedżer może wiedzieć, że szanse na sukces są niewielkie, i przydzielił młodszy zasób jako ćwiczenie edukacyjne. Uczymy się lepiej z porażki niż z sukcesu. Czy może pytasz: „Kiedy mogę mieć cały projekt?”

Potrzeba dość introspektywnego i wolnego od ego programisty, aby zobaczyć własne niedoskonałości, więc medytuj chwilę przed przeczytaniem reszty, aby nie dać sobie wymówki, by przeoczyć własne słabości ...

Nie każdy programista jest szczególnie dobry w analizie, planowaniu i innych zadaniach wymagających przemyślenia. Myśl jest trudna i niegrzeczna. Wymaga pewnego rodzaju potu psychicznego, który sprawia, że ​​czujesz się niekomfortowo i wykręca się po dniu pracy. To po prostu nie jest tak zabawne jak wchodzenie w stan płynności z dwiema puszkami Potwora i twój kamień stał się głośny i kodował, kodował, kodował. Programiści, którzy nie lubią myśleć, oprą się poglądowi, że planowanie to dobry pomysł. Zalecają metody opracowywania, które nie wymagają planowania z góry. Lubią firmy i menedżerów, którzy nie kładą nacisk na planowanie. Przenikają się one do miejsc pracy, w których koszt nieplanowania nie jest zbyt wysoki. Cenią sobie całonocne sesje kodowania i udostępniają tę poprawkę klientom, których cały biznes nie działa z powodu błędu.

Niektórzy programiści zdali sobie nawet sprawę z tego, że dostanie czegoś działającego wystarczająco dobrze do demonstracji oznacza, że ​​sprawienie, by działało całkowicie i we wszystkich okolicznościach, może zostać odroczone, a może nawet zepchnięte na innego programistę, podczas gdy otrzymają pochwały za „wykonanie zadania” na początku.

Są menedżerowie, którzy sami nie mogą dostrzec trendu, dopóki nie przełamie się na Facebooku. Zamiast znaleźć pracę zarządzającą sklepem z oponami dyskontowymi, ci menedżerowie sprawiają, że Twoim problemem jest konieczność uruchomienia kodu do piątku. Nie chcą słyszeć, że musisz zaprojektować interfejs API lub przetestować, czy Twój algorytm jest skalowalny. To dla nich tylko mumbo-jumbo. Będą zachęcać do kodowania, ponieważ to wszystko, co rozumieli na temat oprogramowania, gdy pisali skrypty Perla, aby pomóc klientom w transferze plików. (Mieli tytuł „inżynier oprogramowania” w swojej pierwszej pracy sprzedażowej. Kto wiedział, że oprogramowanie będzie tak nudne i trudne?)

SeattleCplusplus
źródło
-6

Pokaż mi swój kod, a powiem ci, kim jesteś

Twój kod jest Twoją wizytówką. Jeśli napiszesz niechlujny kod, co powiesz o sobie innym ludziom? Pomyśl o tym. Za każdym razem, gdy znajdujemy w biurze naprawdę zły fragment kodu, zadajemy sobie pytanie, kto go napisał i jak, u diabła, przeszedł przez uniwersytet?

Stajesz się tym, co kodujesz

Twój kod to Twój program na całe życie.

Programista piszący zły kod jest jak tancerz baletowy tańczący w klubie striptiz

Niektórym nie przeszkadza taniec w klubie striptiz. Ale jeśli są utalentowanymi tancerzami, marnują swoje umiejętności. Jeśli jesteś biednym tancerzem, ale masz ładne nogi, możesz rozebrać się dla wielu.

Na koniec powinieneś przeczytać powieść Gogola „Portret” i powinieneś zostać ostrzeżony przez historię głównego bohatera. Twój przyjaciel jest podobny do mężczyzny z portretu. Zwabia cię pieniędzmi, ale zapłacisz za to wysoką cenę.

FolksLord
źródło
4
Nie prosiłem ludzi o osobiste komentarze na temat mojego mentora, zapytałem, gdzie są granice w odniesieniu do przemyślanych wzorców projektowych. „Przyciąganie cię pieniędzmi” jest głupim, nieistotnym założeniem, a tak naprawdę to nie on mi płaci.
sf13579
4
Osądzanie czyjejś inteligencji na podstawie jednego fragmentu jest absurdalne. Nie ma żywego programisty, który nie miałby swojej nazwy w co najmniej jednym bałaganie.
Brian Green