Czy stworzenie własnego OS to dobry sposób na naukę? Seniorzy odpowiadają

Quora to zbiór ciekawych pytań i jeszcze lepszych odpowiedzi. Dlatego często przeglądamy ten serwis w poszukiwaniu inspiracji do kolejnych artykułów. Poprzednim razem odpowiadaliśmy na pytanie: Dlaczego tak wielu świetnych developerów odchodzi szybko na emeryturę? Dziś poruszamy takie tematy, jak tworzenie własnego OS, niezbędnych umiejętności web developera oraz tego, czy 40, 50 lat to za dużo, by znaleźć pracę w branży IT.

Pytanie #1. Czy stworzenie własnego OS kwalifikuje mnie do “elitarnej” grupy deweloperów?

Odpowiada Nupul Kukreja, były wykładowca Informatyki na Uniwersytecie w Mumbaju:

To samo pytanie zadał mi pewien student, kiedy jeszcze byłem wykładowcą na Uniwersytecie. Niestety, w tamtych czasach Quora jeszcze nie istniała. Zanim odpowiedziałem na to pytanie, zrobiłem krok w tył i spojrzałem na to z innej perspektywy.

Chcesz zbudować OS od podstaw i wiedzieć, czy zakwalifikuje cię ono do “elitarnej” grupy deweloperów? Wyczyn ten zdecydowanie sprawi, że będziesz należał do mniejszości, która wie jak napisać OS oraz ile pracy to wymaga. Jeśli to ci wystarcza, ruszaj do boju. 99% społeczeństwa nie będzie jednak obchodziło to, co zrobiłeś. Budowanie OS od podstaw jest olbrzymim wysiłkiem. Po zakończeniu budowy będziesz czuł się jak w siódmym niebie. Warto wtedy zastanowić się nad tym czego się nauczyłeś / co straciłeś?

Plusy: Bardzo dobra znajomość struktury danych, proces schedulingu, przełączanie kontekstów, threading, zarządzanie pamięcią, dzielenie zasobów (monitor, drukarka itd.), sterowniki urządzenia oraz uczucie silnej euforii. Będziesz miał również powód do chwalenia się.

Minusy: Potrzeba na to dużo czasu. Nikogo to nie obchodzi. Nie ma żadnego praktycznego zastosowania ani żadnej pewności co do tego jak się sprawdzi. Brak aplikacji, która mogłaby na nim działać. Byłbyś jedynym deweloperem.

Jak widać, minusów jest więcej. Owszem, nauczysz się jak bardzo skomplikowane jest budowanie oprogramowania (dla którego możesz nigdy nie znaleźć praktycznego zastosowania), ale tak naprawdę to tyle. Ponadto, sam fakt, że zbudowałeś własne OS nie umieści Ciebie w tej “elitarnej” grupie. O wiele cenniejsza jest twoja wiedza o projektowaniu systemu. A żeby zdobyć tę wiedzę wcale nie musisz budować OS.

Jeśli naprawdę chcesz zbudować własny OS, zadaj najpierw pytanie, co takiego fascynuje cię w OS.

Jeśli nadal potrzebujesz więcej informacji na ten temat, bardzo polecam te trzy książki:

• Operating Systems: Design and Implementation (Second Edition): Andrew S. Tanenbaum, Albert S. Woodhull.
• The Design of the UNIX Operating System: Maurice J. Bach.
• Understanding the Linux Kernel, Third Edition: Daniel P. Bovet, Marco Cesati:.

Powinny zaspokoić twoją ciekawość na temat OS, a może nawet będziesz mógł pobawić się kawałkami kodu.

Za każdym razem, kiedy masz pytanie odnoszące się do tak wielkiego przedsięwzięcia jak np. budowa własnego OS, radziłbym przyjrzeć się temu z ekonomicznej perspektywy. Co ci da to wyzwanie? Za każdym razem, kiedy dostaniesz odpowiedź, pytaj się “i co z tego”, aż do skutku. Tym sposobem upewnisz się, że naprawdę chcesz zbudować własny OS. Pamiętaj też, że zawsze możesz porzucić dany projekt jeśli uważasz, że nauczyłeś się wystarczająco (lub też jeśli jesteś nim zmęczony). Poza tym, aby wiedzieć “jak” zaprojektować OS nie musisz budować własnego systemu; wystarczy, że przeczytasz jedną z powyższych książek.

Powodzenia!

Odpowiada Derrick Williams, absolwent Henley Business School, obecnie pracuje dla Enron:

Wraz z dwójką kolegów z zajęć napisałem system operacyjny jako projekt na Uniwersytecie 1989 roku. Był o wiele lepszy od MS-DOS, które królowało w tamtym czasie na rynku. Inne zespoły w mojej klasie zrobiły to samo.

Jednakże nikt nie wpadł na pomysł, aby uczynić ten system operacyjny open source, podczepić do narzędzi GNU i stworzyć coś w stylu Linuksa. Większość ludzi miało podejście mówiące o tym, że system operacyjny jest czymś, co stworzyłeś z myślą o sprzedaży, jak na przykład SunOS lub też jakikolwiek inny system operacyjny w tamtym czasie. Jeżeli miałeś zamiar stworzyć system operacyjny było to spowodowane tym, że chciałeś być następnym Billem Gatesem.

Umiejętności Linusa Torvaldsa w budowaniu OS są niezaprzeczalne, ale w tamtym czasie istniało wiele innych ludzi o takich samych umiejętnościach. Trudno jednak ocenić, czy to, że projekt Torvaldsa przypadł nam do gustu to kwestia designu czy zupełnego przypadku.

Zatem, aby odpowiedzieć na twoje pytanie, ja też zbudowałem własne OS i mimo, iż myślę, że nie jestem w tym najgorszy, nie uważam siebie za kogoś na “elitarnym” poziomie. Dla mnie “elitarny” deweloper to ktoś, kto widzi rozwiązanie dla jakiegoś problemu w sposób możliwy tylko jemu. Obawiam się, że nawet po zbudowaniu własnego OS nie mam jakiegoś unikalnego podejścia do rozwiązywania problemów.

Pytanie #2. Wymień pięć niezbędnych umiejętności web dewelopera.

Odpowiada Ania Banaszek, Product Designer w SoundCloud:

1. Staraj się panować nad swoim ego i pamiętaj, że nie jesteś swoim kodem. Jedynym sposobem na poprawienie się jest bycie otwartym na feedback od innych oraz odwdzięczanie się konstruktywnym feedbackiem dla innych.

2. Bądź graczem zespołowym. Tworzenie oprogramowania jest sportem drużynowym, a żadna część kodu nie należy wyłącznie do ciebie. Twoim zadaniem jest upewnić się, że cały pakiet działa jak należy i to nie tylko na twoim urządzeniu, ale również na urządzeniu użytkownika.

3. Ucz się. Technologia zmienia się szybko – to co było popularne 5 lat temu, dziś już nie jest najlepszym wyborem, a technologia, która jest dzisiaj uważana za najlepszą 5 lat temu jeszcze nie istniała. Dlatego też wciąż musisz uczyć się nowych rzeczy, w tym języków, bibliotek, wzorów itd.

4. Specjalizuj się w jednym wąskim wydziale, ale miej ogólne rozumienie innych technologii.

5. Bądź zaradny i obrotny. Tym sposobem to do Ciebie będą przychodzić z prośbą o pomoc w rozwiązaniu problemów. Nie musisz mieć odpowiedzi na wszystko, ale powinieneś wiedzieć, gdzie znaleźć odpowiedź na dany problem.

Odpowiada Rick Viscomi, web dev w Google, autor “Using WebPageTest”:

• Bądź na bieżąco

Nie można przewidzieć jak rozwinie się Web Development w przeciągu następnych 5 lat, ale ci którzy podążają za standardami lub przynajmniej czytają blogi technologiczne mają o wiele lepsze rozumienie nadchodzących zmian oraz rosnących trendów.

Nie wystarczy jednak podążać za trendami. Web deweloperzy muszą także rozumieć ich użytkowników i w jaki sposób użytkują produkt. Narzędzia analityczne jak na przykład StatCounter i Google Analytics są moimi ulubionymi narzędziami do zbierania podstawowych metryk interakcji użytkownika. Deweloper powinien wiedzieć np. że jedna trzecia ruchu sieciowego pochodzi z urządzeń mobilnych lub też czy wizytor jest z hiszpańskojęzycznego kraju.

Wymieniam to jako umiejętność numer jeden ponieważ wspomaga ona innych umiejętności. Rzeczy w tej branży nieustannie się zmieniają. HTML5, CSS3, ECMAScript 5, itd. Jeżeli będziesz spodziewał się nadchodzących zmian lepiej i łatwiej będzie ci się na nie przygotować.

Deweloperzy muszą być świadomi stanu rynku przeglądarek oraz do pewnego stopnia nawet rynku OS. Czy wiedziałeś, że użytkownicy Windowsa XP nie są w stanie zaktualizować przeglądarki IE 9? Chcesz zgadnąć jaki jest najbardziej popularny system operacyjny? (wskazówka: to XP). Wiedząc to, uważasz, że dobrym pomysłem jest opuścić wsparcie dla IE 8, mimo iż 9 zostało wypuszczone? Może dla twojej bazy użytkowników byłby to dobry pomysłem. Moim argumentem tutaj też fakt, że powinieneś wiedzieć, gdzie znajdują się wszelkie pionki na szachownicy zanim podejmiesz swoją decyzję.

• Programowanie

Web developerzy powinni potrafić kodować. Efektywny web developer musi umieć napisać poprawny kod w HTML czy CSS.

• Testowanie

Wszyscy web developerzy powinni być w stanie przetestować kod w licznych przeglądarkach. Łatwo jest testować dla naszej osobistej przeglądarki i ignorować resztę, ale w internecie chodzi o różnorodność, a wybór przeglądarek jest ogromny.

Testowanie kodu napisanego w JavaScript również zalicza się do tej kategorii. Deweloperzy muszą używać narzędzi do wykrywania i debugowania błędów w skrypcie. Chrome, Safari, oraz Internet Explorer wszystkie mają wbudowane narzędzia deweloperskie, które pozwalają przejść przez JavaScript i przeprowadzić kod w interaktywnej konsoli.

Jeśli masz zamiar napisać kod, musisz upewnić się, że działa.

• Dostępność

Developerzy muszą być w stanie pisać kod, który może zostać użyty w różny sposób. Wyszukiwarki oraz czytniki ekranu dla niewidomych to dwa przykłady maszyn interpretujących w twój kod. Strony pełne Flasha lub obrazków mają tendencję do zwieszania się.

W dostępności tak naprawdę chodzi o jej użytkowość. Czy użytkownik jest w stanie korzystać z twojego produktu? Web developerzy muszą wiedzieć o wszelkich przeszkodach pomiędzy użytkownikiem a produktem, aby lepiej go zaprojektować. Czy ten produkt jest użytkowy na małych ekranach jak na przykład na telefonach komórkowych lub starszych monitorach? Czy użytkownicy wiedzą, że należy kliknąć na poszczególny guzik, aby kontynuować do następnej strony? Może strona jest trudna do zrozumienia?

A co z użytkownikami, którzy zablokowali obrazki cookies lub JavaScript? Co jeśli używają bardzo starych wersji przeglądarki? Co możesz dla nich zrobić?

Znaj swojego użytkownika, wyznacz limity tego, co będziesz wspierał i czego nie będziesz. Zastosuj rozwiązania kompatybilne z różnymi urządzeniami i testuj je.

• Bezpieczeństwo

O tym mówię na samym końcu, ale tak naprawdę jest to największy priorytet. Każdy web developer musi wiedzieć w jaki sposób ludzie o złych zamiarach mogą wykorzystać ich produkt do atakowania stron internetowych lub też innych użytkowników.

Jeśli web developer posiada umiejętność nr 1 powinien być też zaznajomiony z kwestiami bezpieczeństwa w tej branży oraz powszechnych sposobach obrony.

Pytanie #3. Czego hakerzy mogą nauczyć web developerów w jedną minutę aby zmienić sposób, w jaki myślą?

Odpowiada Tony Brix, koneser programowania, zatrudniony w UziTech:

Podejmę się próby odpowiedzenia na to pytanie:

• Zawsze używaj śmiesznie długich haseł dla połączeń bazy danych. Używaj również innych użytkowników dla poszczególnych sekcji twojej strony.
• Używaj bezpiecznych połączeń (HTTPS, SFTP, SSH). Prostym sposobem, aby uzyskać dostęp do wszystkiego jest szukanie niezakodowanych połączeń.
• Kiedy jest to tylko możliwe, stosuj parameterized queries. W pozostałych przypadkach używaj white list inputs.
• Zawsze zakładaj, że każdy użytkownik ma złe zamiary i chce zaszkodzić zarówno Tobie, jak i innym użytkownikom.
• Raz na jakiś czas hakuj swoją własną stronę. Zawsze znajdzie się coś, nad czym można popracować.

Opowiada Colin Foster, Freelance, Full-stack Web Developer:

Nie jestem hakerem, ale myślę, że to co mam zamiar powiedzieć nadal będzie adekwatne do tego pytania, bowiem będę mówić o tym, czego sam nauczyłem się o bezpieczeństwie oraz, co umykało mi kiedy przeglądałem kod innych ludzi.

1. Zakładaj, że będziesz popełniał błędy. To, że spędziłeś dużo czasu myśląc o bezpieczeństwie aplikacji i to, że nie możesz znaleźć innego sposobu, w jaki kod mógłby zostać złamany nie ma nic wspólnego z faktem, że tak się nie stanie. Gdyby programiści byli w stanie dostrzec własne błędy, żadne oprogramowanie nigdy nie zostałoby naruszone.

2. W bezpieczeństwie chodzi o warstwy. Żadna pojedyncza warstwa nie gwarantuje bezpieczeństwa. Spójrz na podpunkt numer jeden — tylko dlatego, że zamknąłeś przednie drzwi i postawiłeś przed nimi uzbrojonego strażnika nie znaczy, że powinieneś zostawić inne drzwi otwarte.

3. Z perspektywy twojej aplikacji użytkownik oraz haker wyglądają dokładnie tak samo. “Nie ufaj użytkownikowi” jest powszechną mantrą przy budowie systemów bezpieczeństwa aplikacji.

4. Ujawniaj jak najmniej informacji o twoim systemie jak to tylko możliwe. Pozwalanie twojemu serwerowi na ujawnianie jakichkolwiek informacji tylko ułatwia hakerom pracę. Spraw, aby twój system był na tyle trudny do zrozumienia, że hakerom po prostu nie będzie się chciało nad tym pracować i ruszą do ataku na inny system (Oczywiście nie wystarczyłoby to gdybyś był czyimś celem — od momentu, w którym zostałeś namierzony uniknięcie zhakowania jest olbrzymim wysiłkiem). Ponadto: im dłużej hakerom zajmuje włamanie się do systemu, tym większa szansa, że ktoś zauważy ich obecność.

5. Podam konkretnym przykład, ponieważ nie mogę uwierzyć jak wiele razy się z nim spotkałem: Jeżeli używasz sequential ID sprawdź proszę czy obecnie zalogowany użytkownik powinien mieć dostęp do records 124, 125, 126… Tylko dlatego, że użytkownik jest zalogowany do “ich” konta nie znaczy że powinni widzieć dane innych użytkowników ( Łączy się to z podpunktem w trzecim: “Nie ufaj użytkownikowi!”)

Pytanie #4. Jaka jest różnica pomiędzy różnymi rolami software development?

Odpowiada Quincy Larson, nauczyciel na FreeCodeCamp.com:

Jaka jest różnica pomiędzy lekarzem, a doktorem? Prawnikiem a adwokatem? Chodzi głównie o to, że jedno z nich brzmi bardziej prestiżowo niż drugie. Idąc za tymi przykładami, software engineer również brzmi bardziej prestiżowo niż deweloper lub programista.

Zapisujesz software engineer na swoim resume, ale na imprezie, kiedy ktoś pyta się co robisz odpowiadasz, że jesteś deweloperem lub programistą. Tak to działa.

Zauważ, że możesz spotkać ludzi, którzy będą ci powtarzać, aby przestał nazywać się Software Engineer jeśli nie masz czteroletniego dyplomu z inżynierii. Jednak znam mnóstwo ludzi pracujących dla Google, Minecrafta oraz innych znanych firm, którzy studiowali biznes lub nauki humanistyczne, a w tytule pracy nadal mają “software engineer”. W praktyce nie ma to więc znaczenia.

W skrajnych przypadkach zdarzają się również ludzie, którzy mówią, że nikt nie powinien nazywać siebie software engineer ponieważ nie jest to prawdziwa inżynieria. Nie są w stanie pojąć złożoności oprogramowania i myślą, że pisanie solidnego oprogramowania nie powinno być trudniejsze niż zaprojektowanie solidnego mostu. W praktyce oprogramowanie jest często o wiele bardziej skomplikowane (Google wynosi dwa miliardy linijek kodu).

Nie słuchaj tych ludzi.

Jeśli płacą ci za budowanie oprogramowania, to możesz (a nawet powinieneś) umieścić “software engineer” na swoim resume.

Opowiada Aideen Nasiri Shargh, absolwent Shariff University of Technology, były pracownik Google:

• Jeśli wiesz, jaki masz problem oraz jak można go rozwiązać oznacza to, że potrzebujesz kodera, który zakoduje wszystko w odpowiednim języku.
• Jeśli wiesz jaki masz problem, ale nie wiesz jak można go rozwiązać, zatrudnij programistę, który pomoże ci znaleźć rozwiązanie, a potem wszystko zakoduje.
• Jeśli masz przeczucie, że istnieje jakiś problem, ale nie możesz go zdefiniować oznacza to, że potrzebujesz dewelopera — pomoże on wskazać problem, a potem się z nim uporać.
• Jeśli masz problem i wiesz, że jest to tylko początek wielu innych problemów i nie jesteś w stanie przewidzieć co się stanie, ale chcesz być przygotowany na każdy scenariusz, potrzebujesz architekta.
• Jeśli nie masz pojęcia, co jest potrzebne i nie obchodzą cię szczegóły, wtedy pozyskaj konsultanta.
• Jeśli chcesz napisać email do któregokolwiek z powyższych, ale zapomniałeś tego breakdownu, po prostu nazywaj ich inżynierami.

Jeśli chcesz wiedzieć więcej, polecam ten diagram: A Coder, a Programmer, a Hacker, a Developer, and a Computer Scientist walk into a Venn Diagram.

Pytanie #5. Czy software engineering naprawdę jest pracą bez perspektywy dla osób w wieku 35-40 lat?

Odpowiada Connor Stricklan, Software Engineer:

Do pewnego software dewelopera, którego znam zadzwonił rekruter z Google. Chciał wiedzieć jaka stawka skusiłaby go do pracy dla nich.

Ten deweloper już wcześniej pracował dla Google, ale odszedł około 5 lat temu, aby poświęcić się innym projektom i nie chciał mieszkać w żadnym z miast, w którym firma miała siedzibę. Mimo iż nie miał dyplomu z informatyki, ani nie ukończył żadnego kursu z OOP, musiał im bardzo zaimponować, gdyż przez te wszystkie lata trzymali go na ich liście rekrutacyjnej. Rekruter, który się z nim skontaktował zasugerował, że może byłby zainteresowany rozmową z zespołem Project Loon w Singapurze.

Developer wydał z siebie zdławiony chichot i zapytał rekrutera: Zdajecie sobie sprawę z tego ile mam lat? Rekruter potwierdził, że owszem, data jego urodzenia widnieje w folderze, oraz że Google nie bierze pod uwagę wieku podczas ich procesu rekrutacyjnego. Developer zgodził się zatem zastanowić nad tą ofertą i razem z rekruterem uzgodnił, że skontaktują się za tydzień.

Ten 66-letni deweloper to mój ojciec. Spełniał się zawodowo poprzez prowadzenie własnej firmy, udzielanie konsultacji oraz bycie czyimś pracownikiem. Dokonał kontrybucji podczas wczesnych etapów licznych technologii jak na przykład TCP networking, USB protocols, 802.11b mplementation, and military GPS. Kiedy został zatrudniony przez Google w 2008 roku, kiedy miał 58 lat. Podczas pracy w Google pisał w Javie, a język ten został wynaleziony, kiedy ten facet miał 45 lat.

Jedną ze wspaniałych rzeczy o software development jest fakt, że głównie chodzi o pasję do nauki. A widać to po karierze mojego ojca i karierach tysięcy innych developerów. Jeśli masz pasję oraz umiejętności, wtedy nie jest to praca bez perspektywy po 40, 50, czy nawet 60.

Opowiada Steven Ussery, M.S. Computer Science, Texas A&M University:

Jestem 65-letnim software engineerem, który pracował dla Apple, Adobe, eBay, Microsoft, VMware, Cisco, FileMaker, Xo Communications, 2Wire, Egnyte, Nexsan, oraz dwóch innych startupów. W trakcie mojej kariery zostałem zwolniony pięć razy, jednak nową pracę zawsze znajdowałem w przeciągu trzech do czterech tygodni, nawet podczas recesji. Cztery razy pracowałem w Indiach i Chinach.

Kocham to co robię i na ten moment nie planuję przejść na emeryturę. Jestem w tym dobry raczej nie dlatego, że jestem jakimś geniuszem, ale raczej dlatego, że software developmentem zajmuję się już od bardzo długiego czasu i wiele nauczyłem się z własnych błędów. W rzeczywistości nie istnieje język komputerowy, w którym nie potrafiłbym programować. Nie ma też platformy OS, która sprawiałaby mi kłopot. Ponadto poza USA pracowałem w fabrykach Apple w Chinach oraz Irlandii. Nauczyłem się mówić po hiszpańsku oraz włosku i znam 10 fraz po mandaryńsku.

Tego wszystkiego udało mi się dokonać w trakcie 40 lat małżeństwa. Wychowałem dwójkę dzieci (jedno z nich jest software engineer dla Netfliksa), a teraz mam pięcioro wnucząt. Według ostatniego raportu ubezpieczenia społecznego, które otrzymuję co roku od rządu, mój całkowity życiowy przychód do tego dnia wynosi ponad trzy miliony dolarów, a jeszcze nie skończyłem pracować.

Powiedziawszy to wszystko muszę przyznać, że dyskryminacja wiekowa oraz outsourcing jest powszechna w Dolinie Krzemowej. Przed 45. rokiem życia miałem lepszą szansę na zatrudnienie już po jednym spotkaniu. Teraz w wieku 64 lat zajmuje mi to około dziesięciu rozmów kwalifikacyjnych. Ponadto, musiałem nauczyć się tolerować fakt, iż wywiady te często przeprowadzane są przez aroganckich i uprzywilejowanych młodych lalusiów, którzy w większości myślą, że z jakiegoś powodu są lepsi niż ja.

Czy wraz z wiekiem trudniej jest dostać następną posadę? Oczywiście, że tak. Ale co z tego jeśli kochasz to co robisz. Wszystko czego potrzebujesz to determinacja. Nigdy się nie poddawaj.

Autorką artykułu jest Zuzanna Filipiuk. Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z