7 lat programowania, brak doświadczenia komercyjnego. Jak teraz szukać pracy?

0

Cześć wszystkim,

Od 7 lat tworzę aplikacje mobilne (iOS), wcześniej android (rok). Cały czas na własnej działalności: początkowo freelancer, od ponad 3 lat na kontrakcie w większym ale nie rozwijającym projekcie. Jestem oczywiście po studiach informatycznych.

Obecna praca mnie nudzi i zaczynam się rozglądać za nową (etat) i tutaj pojawia się problemy bo:

  • nie mam doświadczenia komercyjnego (agile, scrum, praca w zespole, jira itd.)
  • znajomość GIT (na zasadzie push and pull, bo jak pracuję nad projektem sam to mi wystarcza)
  • stosowanie wzorców projektowych (nie stosuję)
  • słaba jakość kodu (porównując do kolegów pracujących w firmie).

Potrafię szybko i dobrze pracować (opinia klientów), dostarczyć produkt ale jak analizuję oferty pracy (iOS developer) to z obecnym doświadczeniem i umiejętnościami mogę mieć problemy żeby się załapać do dobrej pracy. Nie mam zamiaru aplikować na stanowisko juniora w wieku 32 lat bo przez te 7 lat jednak coś się nauczyłem i byłoby to niepoważne.

Co doradzacie? Szukać pracy czy poświęcić pół roku na opanowanie rzeczy, których nie znam i dopiero wtedy atakować? w jakie firmy celować?

0

Pójdź na regulara i szybko podpatrzysz kolegów?

1

nie mam doświadczenia komercyjnego (agile, scrum, praca w zespole, jira itd.)

a jaki problem zapoznać się z narzędziami i metodykami? jeden dzień i masz ogarnięte, serio to nie jest jakaś wielka filozofia

znajomość GIT (na zasadzie push and pull, bo jak pracuję nad projektem sam to mi wystarcza)

To samo co wyżej. Pobaw się gitem bardziej przez 1-2 dni, to wystarczy bo zrozumieć prace na kilku branchach, rozwiązywanie konfliktów itp

stosowanie wzorców projektowych (nie stosuję)

Czasem nie wiesz, że stosujesz

słaba jakość kodu (porównując do kolegów pracujących w firmie).

No cóż... jak piszę coś sam na szybko i nie mam tego rozwijać to też nie skupiam się nad kodem, ale w robocie ci płacą za czysty kod więc po prostu go rób, co za problem?

0

Brakuje ci doświadczenia w pracy w teamie więc zdobąć je jak najszybciej.

3

stosowanie wzorców projektowych (nie stosuję)

Wzorce projektowe nie są po to, żeby stosować, tylko, żeby je znać i ewentualnie, być może zastosować, jeśli będzie taka potrzeba.

A stosuje się to, co jest potrzebne w danej chwili. A i tak masę wzorców jest nieopisanych. Wszystko może być wzorcem. Te najpopularniejsze wzorce po prostu ktoś kiedyś opisał. A potem ludzie zrobili wokół tego cargo cult.

słaba jakość kodu (porównując do kolegów pracujących w firmie).

Co to znaczy słaba jakość kodu? Czym to się objawia? Ktoś ci to powiedział, czy sam to widzisz?
Pytam, bo "jakość kodu" to takie słowo wytrych i nie wiadomo, czy ktoś ma na myśli:

  • dobrą architekturę, stosowanie się do zasad SOLID czy innych, "utrzymywalność" projektu, pisanie testów itp., czyli taka "twarda jakość kodu" - jak będzie niska to projekt się rozsypie, będą bugi, proste rzeczy będzie się implementować tygodniami itp.

  • trzymanie się do standardów w branży (np. entery we właściwych miejscach, stosowanie się do nazewnictwa itp.). - czyli "miękka jakość kodu", która nie ma wpływu na działanie aplikacji, natomiast może mieć duży wpływ na pracę zespołową. Np. pisząc samemu projekt ze zmiennymi po polsku możesz nawet duży projekt napisać i będzie ok. Ale jeśli miałbyś ten projekt napisać na spółę z obcokrajowcem, i każdy by pisał zmienne w swoim języku, to byłaby kasza. Dlatego standardem jest pisanie wszystkich zmiennych po angielsku, mimo, że nie ma to wpływu na działanie aplikacji.

Stosowanie obu rzeczy jest ważne, tym niemniej warto pamiętać, że to pierwsze jest obiektywne (bo wynika z tego w jaki sposób się zachowują systemy/części systemów w trakcie developerki) i wiele ludzi dochodzi do tych zasad samemu, w ten czy inny sposób sformułowanych. A to drugie jest subiektywne, czasem nawet zależy od widzimisię danego zespołu ("taby czy spacje").

0

Dzięki wielkie za Wasze odpowiedzi.

Odniosę się do tego co pisaliście w jednym wpisie bo kilka kwestii się powtórzyło w powyższych wpisach.

  • praca w zespole (agile, scrum)
    Racja, tworząc apki też działałem zwinnie i miałem swoje sprinty a to, że nie było przy tym tej całej otoczki to raczej nie problem.

  • GIT
    Zgadzam się, spokojnie to można ogarnąć samemu, kwestia przećwiczenia rozwiązywania konfliktów.

  • wzorce
    Część używam a nie wiem o tym, tu się zgadzam bo czytając książkę o wzorcach to zauważyłem, Rozwiązania pewnych problemów czasem samo się narzuca (jest naturalne) a to że ktoś to jakoś wcześniej nazwał to inna sprawa.

  • słaba jakość kodu
    Tu może trochę przesadziłem bo nikt nigdy go nie krytykował, zaczynając od uczelni a kończąc na ludziach, którzy coś zmieniali w moim projekcie.
    Oczywiście dbam o porządek w projekcie, odpowiednie nazewnictwo (ang), spacje, tabulacje (tu wszystko się zgadza), bardziej chodziło mi o te wzorce i zasady pisania kodu gdy nad projektem pracuje więcej osób.

Biorę się za siebie i koło marca-kwietnia szukam pracy na etacie.

Ktoś pytał czy da się wyżyć z pracy na własny rachunek, da się ale zaczynam się martwić co będzie za 5-10 lat. Bez wspomnianego komercyjnego doświadczenia, odpowiednich standardów (kod, technologie) może być ciężko o dobrą pracę więc przerwa na etat wydaje się być koniecznością.

6

Czy wy wszyscy piszący o "braku doświadczenia komercyjnego" przy pracy X lat na włąsny rachunek robicie sobie jaja, czy co?

0
Błękitny Taran napisał(a):

Czy wy wszyscy piszący o "braku doświadczenia komercyjnego" przy pracy X lat na włąsny rachunek robicie sobie jaja, czy co?

Miałem na myśli doświadczenie korporacyjne: praca w zespole, bardziej wymagające projekty i standardy panujące w firmach, które ciężko wprowadzić działając w pojedynkę.

Pracując jako freelancer czy kontraktor dostaje się pieniądze za efekty (działający produkt), nie ma czasu na dopieszczanie kodu czy kilkudniowe rozmyślanie nad architekturą.

1

Pracując jako freelancer czy kontraktor dostaje się pieniądze za efekty (działający produkt), nie ma czasu na dopieszczanie kodu czy kilkudniowe rozmyślanie nad architekturą.

Bo w firmach zawsze jest na wszystko czas. Ciekawe więc skąd tak duża liczba osób, które się żali na tym forum, że mają gówniany kod w pracy i nie mogą nic zrobić, bo "nie ma czasu na testy" a pomysł refaktoringu zostaje zjechany jako fanaberia.

Miałem na myśli doświadczenie korporacyjne: praca w zespole, bardziej wymagające projekty

Otóż to. Każdy powinien zasmakować trochę pracy w zespole. Z braku laku można robić wspólnie projekty na studiach, pomagać przy projektach open source, brać udział w kole naukowym, ew. popracować w innej branży, gdzie się pracuje zespołowo, bo praca zespołowa jest i tak wszędzie podobna, bo ludzie są podobni.

Nie mam zamiaru aplikować na stanowisko juniora w wieku 32 lat bo przez te 7 lat jednak coś się nauczyłem i byłoby to niepoważne.

Z jednej strony rozumiem, ambicja i te sprawy, ale z drugiej to jakakolwiek praca w grupie, to okazja, żeby się poduczyć trochę pracy zespołowej, czyli właśnie tego czynnika, którego nie nauczysz się samemu (w zasadzie trochę się nauczysz, bo rozmowy z klientem to też praca zespołowa, jakby nie było).

No i jakakolwiek praca przy programowaniu to kontakt ze światkiem programistów, więc od razu wiesz, co jest modne, co nie, słyszysz plotki o frameworkach, uzyskujesz feedback, przekazują ci know-how. No i co najciekawsze i najtrudniejsze - uczysz się komunikacji w zespole i rozwiązywania konfliktów.

Czasem warto być juniorem (szczególnie, że i tak każdy jest czasem juniorem, to nie wstyd), a jak jesteś dobry technicznie, to podłapiesz trochę miękkich skilli i zawsze będziesz mógł uderzać na mida w kolejnej firmie.

standardy panujące w firmach, które ciężko wprowadzić działając w pojedynkę.

Standardy akurat prościej wprowadzić w pojedynkę niż próbować do nich przekonać resztę teamu.

0

LukeJL pełna zgoda.

W firmie się po prostu pracuje inaczej: większe projekty, rozwój itd.

Boję się o tego juniora a jak mam być ze sobą szczery to nie wiele więcej potrafię. Ktoś może się dziwić jak to możliwe po tylu latach? No cóż jak się wykonuje stosunkowo proste projekty lub siedzi lata w nudnym projekcie to jest to możliwe.

Dość marudzenia ogarniam teraz tak dużo jak to możliwe by na rozmowie się jak najlepiej sprzedać, czas pokaże.

Jak się gdzieś załapie koło marca - kwietnia to dam znać.

2

a sposób na doświadczenie jest prosty

1 użytkowników online, w tym zalogowanych: 0, gości: 1