Nie jestem pewien, czy myślenie o problemie przed czasem a podejście iteracyjne jest ze sobą sprzeczne. Podobnie jak wiele innych rzeczy, myślę, że powinieneś dążyć do osiągnięcia równowagi między nimi. Jak znaleźć równowagę? To jest coś, czego uczysz się z doświadczeniem i często najlepsze lekcje czasu (tj. Rzeczy, które dają ci doświadczenie), kiedy nie rozumiesz tego dobrze (lub jeszcze lepiej: lekcja: po prostu źle zrozum to źle). Jak już zauważyłeś, jest powiedzenie „szybko wypuszczaj, często wypuszczaj”. Jest jeszcze jeden podobny: „zawodzić wcześnie, zawodzić szybko, zawodzić często”
Myślenie naprzód jest świetne i powinieneś to absolutnie zrobić. Ale z doświadczeniem dowiedz się, kiedy przestać myśleć i po prostu zbudować coś, nawet jeśli nie masz wszystkich danych. Budując go, będziesz w stanie uzyskać lepszy wgląd w dziedzinę problemów i potencjalnie znaleźć znacznie lepsze rozwiązanie. Dlatego polecam nie wykluczać jednego z drugiego, ale uczynić z „iteracyjnej głowy” część swoich iteracji iz czasem myślę, że sam znajdziesz właściwą odpowiedź na to pytanie.
Tylko mały przykład. Pewnego dnia zmagałem się z decyzją dotyczącą projektowania oprogramowania. Z perspektywy czasu było to względnie trywialne, ale miałem dwie alternatywy i wydawało się, że obie będą działać. Ciągle krążyłem z powrotem do zalet / wad każdego z nich, a następnie krążyłem z powrotem i ponownie rozważałem swoje decyzje. Patrząc wstecz, to trochę krępujące, ile czasu spędziłem na myśleniu. Potem powiedziałem sobie: kurwa! I zamiast używać jednego z projektów, po prostu pospiesznie zhakowałem trochę kodu, całkowicie ignorując wszystkie dobre rzeczy, których dowiadujesz się o dobrym projekcie. Uruchomiłem tę funkcję w około 45 minut. Potem wróciłem, spojrzałem na mój kod i przekształciłem go w coś solidnego i coś, czego nie wstydziłbym się po sprawdzeniu kontroli źródła. Zabawne jest to, że po uruchomieniu hacka wymyśliłem „
Kolejną rzeczą, którą poleciłbym szczególnie w przypadku problemów, z którymi się teraz borykasz (tj. Zbliżających się dużych, złożonych zadań). Zamiast robić rzeczy szeregowo, rób to równolegle. Podziel dzień na części, w których prowadzisz badania, a następnie zatrzymaj się, przełącz na chwilę bieg i kod, przynajmniej na części projektu, które nie są kompletnymi niewiadomymi. W ten sposób trzymanie się blisko kodu zapewni lepszą perspektywę i nie wypalisz się, próbując zbyt szybko wchłonąć zbyt wiele informacji. Dla mnie przynajmniej po kilku godzinach badań dobrze jest pozwolić mózgowi trawić rzeczy, zmieniać zadania i robić coś innego przez jakiś czas. Następnie wróć do dalszych badań.