Czy martwisz się czasem, że bardziej martwi Cię to, jak coś jest budowane, niż to, co faktycznie budujesz?

Jako programista mam wrodzoną irytującą irytację na moje narzędzia, kod innych ludzi, mój kod i cały świat. Zawsze chcę to poprawić. Więc refaktoryzuję się, jestem na bieżąco z najnowszymi technikami. Próbuję uczyć się wzorców, próbuję używać ram, aby nie wymyślać koła na nowo. Mogę napisać specyfikację techniczną, która zdmuchnie twoje skarpetki z ilością wzorów, które mogę wcisnąć.

Jednak ostatnio wydaje mi się, że wiem więcej o narzędziach, których używam, niż o tym, jak wdrożyć udane oprogramowanie.

Wydaje mi się, że brakuje mi umiejętności ludzkich i wierzę, że sukces inżyniera oprogramowania wymaga czegoś więcej niż znajomości najfajniejszych frameworków. Myślę, że potrzebuje również niektórych z poniższych zestawów umiejętności.

• Projektowanie interakcji
• Doświadczenie użytkownika
• Marketing

Mam trochę tego, czego nauczyłem się od ludzi, z którymi pracowałem i świetne projekty, nad którymi pracowałem, ale nie wydaje mi się, żebym „posiadał” te umiejętności.

Czy mam rację? Czy powinienem starać się dalej rozwijać te umiejętności, czy też należy je pozostawić osobom, które je wykorzystują w trakcie kariery?

W jaki sposób upewniasz się, że nie przywiązujesz się zbytnio do tego, jak coś robisz i że „sprawisz, że użytkownicy będą niesamowici”?

Czy ktoś wie o dobrych zasobach do nauki tych umiejętności z punktu widzenia programowania?

Moja rada: rozmawiaj z użytkownikami tak często, jak to możliwe. Nie wiem, czy jesteś w dużej firmie i jesteś na innym kontynencie niż twoi użytkownicy, czy jesteś na stanowisku freelancera, ale jeśli to możliwe, po prostu porozmawiaj z użytkownikami.

Wiem, że wiele razy muszę siedzieć i pamiętać, że moim zadaniem nie jest tworzenie największego kodu, jaki kiedykolwiek widział świat, ani tworzenie funkcji, która wykorzystuje najmniejszą liczbę cykli i zajmuje najkrótszy możliwy czas technologicznie, ale aby zrobić wszystko, czego potrzeba użytkownikom do wykonywania swoich zadań. I w tym celu uważam, że poza zwykłymi możliwościami technicznymi (dla mnie zresztą) najlepszymi 2 cechami, które można mieć, są dobra znajomość działalności biznesowej użytkowników i dobre relacje robocze z nimi.

Pracuję w małej firmie (~ 50 osób) i lubię chodzić do czyichś kostek i rozmawiać o najnowszych rzeczach, które dla nich stworzyłem / naprawiłem. Absolutnie najlepsze uczucie, jakie kiedykolwiek miałem z pracy, kiedy słyszę, jak rozmawiają o swojej pracy, i sugerują coś, co rozwiąże problem, o którym nigdy nie zdawali sobie sprawy, że może istnieć rozwiązanie techniczne. Nie byłoby to możliwe, gdybym nie rozumiał ich interesów i nie mógłbym z nimi swobodnie rozmawiać.

Powiedziałbym, że to zależy od tego, gdzie pracujesz i do jakiego rodzaju firm widzisz siebie w przyszłości - to naprawdę otwarta dyskusja.

W mniejszych firmach możesz nosić wiele czapek (choć nie jestem pewien, dlaczego marketing znajduje się na tej liście, chyba że zamierzasz sprzedawać własny produkt).

W większych firmach mogą mieć ludzi, którzy koncentrują się na tych sprawach.

Tak naprawdę chodzi o to, dokąd idziesz i potencjalnie otwierając dla ciebie więcej drzwi.

Dla każdego wiersza kodu, który piszesz, wprowadzasz szansę na błąd.

Zatem najlepsze projekty minimalizują ilość wprowadzanego kodu - być może dzięki zasadzie DRY (Don't Repeat Yourself). Jednak start- upy preferują podejście YAGNI (You Ain't Gonna Need It), które znacznie szybciej prowadzi do MVP (produktu minimalnego).

Jeśli Twoim celem jest stworzenie czystego, łatwego w użyciu produktu, który robi dokładnie to, czego pragną Twoi użytkownicy, to YAGNI jest twoim najlepszym wzorcem projektowym. Wyrzuć wszystko, co nie przyczynia się bezpośrednio do działania kodu. Obejmuje to purystyczne procesy budowania i obsesyjne stosowanie wzorców.

Niektóre materiały do ​​czytania

Możesz przeczytać „ Nie każ mi myśleć ”, która jest doskonałą książką na temat projektowania interfejsu użytkownika. Ponadto, każda z serii książek Gitomer (szczególnie The Little Green Book ) pomoże ci w twoich umiejętnościach sprzedaży, nawiązywania kontaktów i marketingu.

Myślę, że pewna wiedza na temat projektowania interakcji i wiedzy o użytkowniku jest bardzo przydatna nawet w dużej firmie z jednego powodu: Ty jako programista jesteś pierwszą osobą, która faktycznie korzysta z interfejsu na tygodnie, a nawet miesiące, zanim będzie on w stanie użytecznym przez tester do przetestowania.

Na początku bardzo przydatne może być wskazanie interfejsu, który nie jest tak łatwy w użyciu, jak planowano, lub pewnej zasady projektowania, która mogła zostać przeoczona. Te rzeczy mogą czasem być trudne do zobaczenia, zanim będziesz mieć coś konkretnego do pracy, i zawsze jesteś pierwszą osobą, która ma coś konkretnego do pracy.

Mogę napisać specyfikację techniczną, która zdmuchnie twoje skarpetki z ilością wzorów, które mogę wcisnąć.

Samo to stwierdzenie prowadzi mnie do przekonania, że ​​musisz pracować nad innymi aspektami tworzenia oprogramowania.

Chociaż możesz nigdy nie być odpowiedzialny za każdy aspekt oprogramowania swojej firmy, posiadanie szerokiego zakresu wiedzy na wiele tematów może być niezwykle cenne. Jeśli nic więcej, to więcej rzeczy, które możesz rzucić w wywiadzie, dzięki czemu możesz kontynuować karierę.

Jeśli nie masz wystarczających wyzwań w niektórych obszarach swojej pracy, rozpocznij własny projekt w domu, aby zrobić coś, co uważasz za interesujące. Lub zaangażuj się w projekt open source.

Nie, nie wiem, nie moim zadaniem jest martwić się tym, co buduję, ale raczej budować go zgodnie ze specyfikacją określoną przez mojego klienta / pracodawcę. Wiedzą już, czego chcą i ode mnie zależy, czy je odpowiednio wdrożę, aby można było to utrzymać. Udzielę porady, gdy pojawi się szansa, jeśli mogę powiedzieć, że nie są do końca pewni, jak najlepiej wprowadzić funkcję do oprogramowania

Prawdopodobnie w pewnym momencie będę chciał stworzyć własny projekt i martwić się tym, co buduję, ale myślę, że rozpoczynając karierę programistyczną, ważne jest ciągłe dążenie do nauki właściwego sposobu robienia rzeczy.