Temat: Cała prawda o programistach
Po to, ze albo ma sie dobre nawyki, albo odwala lipe. Komus, kto pisze czytelny kod, nie robi roznicy, czy klepie w IDE czy na kartce. 'Wielkosc' problemu to tez marne wytlumaczenie. Skad pracodawca ma wiedziec, ze przy wiekszych problemach dalej nie bedziesz pisal belkotu?
A jesli dla pracodawcy glownym czynnikiem przy wyborze programistow jest czas rozwiazywania zadania, to lepiej poszukac sobie innego miejsca pracy. Programowanie to nie kopanie rowow.
Nie zrozumiales sedna sprawy niestety.
Uogolniajac, poza kontekst programistyczny, mozna problem sprowadzic do rownowagi miedzy jakoscia a wydajnoscia. Lepiej w pierwszej iteracji dostarczyc produkt gotowy w 80% *na czas* niz nie dostarczyc produktu gotowego w 100% *nigdy*. Od tego jest SDLC i tym podobne mechanizmy.
Scenariusz moze byc rozny na rozmowie o prace. Ja na przyklad (nie jestem programista) przyjalbym czlowieka, ktory po zadaniu problemu "FizzBuzz" zapytalby o kryteria akceptacji rozwiazania przed jego podaniem, a nie tego, ktory napisal by mi w "ksiazkowy kod" bez mrugniecia okiem. Dlaczego? Bo pierwszy wykazal sie umiejetnoscia analitycznego podejscia do projektu, a drugi jest prawdopodobnie wyrobnikiem piszacym ladny kod.
I tu wracamy do kwestii jaki problem, takie podejscie. Jesli problem jest trywialny a warunki zaliczenia nie sa podane, to rozwiazuje sie go najprostsza/najszybsza z mozliwych w danym kontekscie metod. I dlatego ponad 80% projektow IT nigdy nie konczy sie na czas i w ramach budzetu.